系列：從現場踩坑到 AI 工具 — IT Diagnostic Agent 開發實錄

那個 36% 和 64%

Day 21 開頭提過一個數字：Anthropic 說 Claude 的使用情境裡，軟體開發只佔三成多，剩下六成多是各行各業的跨界應用。

前面三天講的都是那三成多——寫程式、debug、agent 協作。

今天講另外那六成多，而且用的是最貼近的例子：你正在讀的這三十篇文章，是怎麼被生產和管理的。

起點：一份躺在 Google Drive 裡的 docx

這個系列的大綱，最早是一份 Word 檔，放在 Google Drive 一個叫 202608IT邦鐵人賽 的資料夾裡。

我當初是用 GPT 協助整理大綱的（為了避開內容重疊，讓兩邊各出一版來對照）。

所以流程的第一步是：把 Drive 授權給 Claude，讓它去讀那份 docx，然後開始寫。

這件事本身就有幾個坑值得記錄。

坑 1：授權會過期，而失敗訊息不會告訴你

第一次要求 Claude 讀 Drive 的時候，回來的是一個授權錯誤。

我以為是我沒開權限，去設定裡看，Google Drive 的 connector 明明是啟用的。

啟用 connector ≠ 完成授權。 這兩件事是分開的，而且授權會過期，需要重新走一次 Google 的同意流程。

這個坑很典型，因為它的錯誤訊息只說「未完成驗證」，不會說「你的 token 過期了，去 Settings 重新連一次」。

做 IT 的人對這種訊息很熟——它技術上正確，實務上沒用。

（順帶一提，這正是 Day 12 那五條規則想解決的事。一個好的診斷回應應該告訴你下一步做什麼，不是告訴你狀態是什麼。）

坑 2：Drive 有時候就是會壞，你需要備援

寫到後面幾篇的時候，Drive 的寫入開始連續失敗，回的是 internal error。

我試了幾次，都是同樣的結果。前面十篇上傳都很順，所以不是權限或格式問題，就是服務端的暫時狀況。

處理方式：改成先在本機產出檔案，等服務恢復再補上去。

這個決定很無聊，但它讓工作沒有停下來。

而它也印證了一件我在 Day 06 就在講的事：任何依賴外部服務的流程，都要有一條不依賴它的路徑。

當時講的是 API 供應商，現在是雲端硬碟。同一個道理。

實際的工作流長什麼樣

現在的流程是這樣：

Google Drive（大綱 + 草稿存放）
        ↕
     Claude
        ↕
GitHub（原始碼，讀取用來核對事實）
        ↕
      我（提供事實、修正錯誤、決定方向）

具體來說，Claude 在這個流程裡實際做的事：

其中兩項值得單獨講。

用 GitHub 核對事實，抓到我自己的兩個錯誤

寫 Day 11 的時候，需要寫出實際的 Claude API 呼叫程式碼。

Claude 憑著討論脈絡寫了一版，看起來很合理。但那是它推論出來的，不是我的程式碼。

於是我把 index.html 的 raw URL 貼給它，叫它去看實際的實作。

結果抓出兩個錯：

1. localStorage 的命名：草稿寫的是 apikey_claude，實際上是 it_key_claude / it_model_claude 這一套
2. model 欄位的處理：草稿寫成一個叫 selectedModel 的變數，實際上是從 providers 物件取 p.model

Header 那部分它猜對了（anthropic-dangerous-direct-browser-access 一字不差），但另外兩處是編的。

這件事的教訓不是「AI 會編東西」，而是「有原始資料就不要讓它推論」。

推論在沒有資料時是有價值的。有資料時，推論就是不必要的風險。

而順帶的收穫是：核對的時候還撿到了一段我自己都忘記的程式碼——

// Backward compat: migrate old single apiKey
if(!providers.claude.key && localStorage.getItem('it_key')) {

早期版本只支援 Claude，Key 存在 it_key。後來改成多供應商，我留了一段搬遷邏輯。

這五行是「已經有真實使用者」的證據。 沒人在用的話，直接改掉 key 名稱就好了，誰在乎。

這個論點寫進 Day 11 了。它是核對事實時的副產品，而不是我原本要找的東西。

搜尋過去對話，找回我匯出不了的紀錄

Day 12 到 Day 15 那四篇的核心，是 Evidence-driven Dialogue 那五條規則。

問題是：那些討論散在好幾次不同的對話裡，而我沒辦法把對話紀錄匯出成檔案。

我能做的只有：告訴 Claude「那些討論都在這個專案裡」。

然後它去搜尋，把東西找回來了——五條規則的完整英文原文、PS 那條決策相關性測試、code audit 的完整結果（包括 index.html 第 983 和 1098 行這種細節）、還有 GSD 那整組設定選項。

這是這個工作流裡我最沒預期到的能力。

而它讓一件事變得可行：我不需要在討論的當下就決定「這段以後要寫進文章」。 我可以先討論，幾週後再回頭把它撈出來。

對一個邊工作邊寫作的人來說，這個差別很大。因為在討論技術問題的當下，我在想的是怎麼解決問題，不是怎麼寫文章。

這個流程裡最重要的一步：我修正事實

前面講的都是 Claude 做了什麼。現在講我做了什麼，因為這才是這個流程能成立的關鍵。

Claude 寫出來的第一版草稿，有好幾處事實錯誤。而那些錯誤，只有我能發現。

實際發生過的修正：

修正 1 — 誰在 debug

草稿寫的是：朋友傳來手機跑版的截圖，「我」去分析 CSS、找出四個原因、修好。

事實是：朋友傳截圖給我，我轉手貼給 Claude，說「你去修」。

我看到那段草稿的反應是笑出來，然後回它：「事實上我只有看到 BUG，截圖給你，Claude 你去修 XD」

改完之後那篇變好了。 因為真實版本才是 2026 年的 IT 工作現實。

修正 2 — 語言的順序

草稿寫成：一開始是英文介面，使用者說看不懂中文，所以加了中文。

事實是反的：一開始就是繁體中文，英文是後來才加的。

修正 3 — 主題的順序

草稿寫成：原本淺色，使用者要求加深色模式。

事實也是反的：預設就是深色，朋友說想要淺色，我丟給 Claude 加，加完之後淺色模式的文字全消失了。

修正 4 — 那個沒影響到我的事件

寫 Day 16 的時候，Claude 引用了 2026 年 6 月某些模型因出口管制暫停存取的事，並寫成「我當時的反應是……」

事實是：我這個工具是 6 月 10 日上 GitHub 的，開發用的是 Sonnet 4.6，完全沒受影響。

而修正之後，那篇文章反而變強了——因為真相是「我沒被影響是運氣，不是設計」，這比「我遇到問題然後架構救了我」更能說明供應商依賴的風險。

修正 5 — 我到底測了什麼

Day 20 原本寫著我測過小模型但沒有系統性數據。

事實是：我當初只測了決策樹那部分，AI LLM 輔助那塊我根本沒測。

而這個修正引出了整個系列裡我覺得最有意思的一個發現，那已經寫進 Day 20 了。

五個修正的共同點

回頭看這五個修正，它們有一個共同的模式：

Claude 錯的方向，全部都是「讓故事更符合常規敘事」。

• 工程師自己 debug（比較像技術文章）
• 先英文後中文（比較像國際化的常規順序）
• 先淺色後深色（比較像大眾預設）
• 作者親身遭遇風險然後架構救了他（比較像有起承轉合的故事）
• 有測過但缺數據（比較像一個負責的開發者）

每一個錯誤都比真相「更合理」。 這就是它們危險的地方。

如果我沒有逐篇核對，這五處都會留下來，而且沒有讀者會發現。

所以這個流程的分工是什麼

我不是這些文章的打字員，也不是它們的審稿人。我是事實的來源。

而這正是 AI 在這類工作上的邊界：它可以組織、可以推論、可以寫得很流暢，但它不知道那天到底發生了什麼事。

只有在現場的人知道。

結構化地看這個工作流

核心 vs 外部
核心是「文章講的事情是真的」。文字流暢度、結構、修辭，全部是外部。

一篇寫得很好但事實錯誤的文章，比一篇寫得普通但誠實的文章糟糕得多。

可控 vs 不可控
我控制不了 Claude 會不會在缺資料時推論。我控制得了要不要給它資料。

所以正確的做法不是「叫它不要編」，是把 raw 檔案的 URL 貼給它。

已成立 vs 假設
草稿裡的每一句敘事，在我核對之前都是假設。
核對之後才變成事實。

而核對的成本，遠低於一篇有錯誤的文章被公開的成本。

今天的反思

這篇文章可能會讓人覺得：所以你只是在改 AI 寫的東西？

我的答案是：改不是重點，提供事實才是。

那五個修正裡，沒有一個是「文筆不好我來潤稿」。全部都是「這件事不是這樣發生的」。

而在一個 AI 能把任何素材寫得很流暢的世界裡，「知道事情實際上是怎麼發生的」這件事，價值反而變高了。

因為那是唯一不能被生成的東西。

明天預告： 講到這裡，我必須把最後一件事講清楚。這三十篇文章，草稿是 Claude 寫的。我為什麼選擇公開這件事，而不是假裝全部自己寫？

作者：Rich Chang | IT 基礎建設工程師 | 越南・柬埔寨・台灣