Claude AI三工具協奏曲：Chat、Cowork、Code

Claude AI 本身是一個通才型的大語言模型，什麼都能聊，但在特定專業領域（例如撰寫符合法規要求的技術文件），它的表現取決於你給它多少領域知識。Claude 提供了一個叫做 Skills 的機制：你可以把領域知識打包成一個 ZIP 檔案，上傳到 Claude.ai，之後 Claude 在處理相關任務時就會自動載入這些知識。

一個 Skill 的結構大致是這樣的：

skill-name.zip
└── skill-name/
├── SKILL.md ← 入口檔案：告訴 Claude 這個 Skill 怎麼用
├── core/ ← 核心流程檔案
├── domains/ ← 各領域的專業指引
├── references/ ← 參考資料（這就是那一百多個 MD 檔案的所在地）
│ ├── indexes/ ← 索引檔：告訴 Claude 去哪裡找什麼
│ └── details/ ← 細節檔：具體的領域知識內容
└── scripts/ ← 輔助腳本

核心是 references 裡面那些 Markdown 檔案。 它們是我日常維護的主要對象，也是整個 Skill 的價值所在。這些 MD 檔案裡裝的不是程式碼，而是結構化的專業知識，例如：

先前技術分析：某個技術領域有哪些已公開的專利，各自的技術方案和弱點在哪裡

撰寫模式庫：在這個領域，高品質的技術文件通常怎麼組織、用什麼措辭、遵循什麼格式

法規合規檢查表：不同國家和地區的法規對技術文件有什麼特殊要求，哪些用語會觸發審查風險

術語對照表：同一個技術概念在不同脈絡下應該用什麼精確的表述

品質防護規則：AI 生成的文字常犯哪些錯誤，如何偵測和修正

Claude 在處理任務時，會根據使用者上傳的資料判斷屬於什麼技術領域，然後透過 Skill 的索引機制找到對應的 MD 參考檔案載入。這就像一個醫生在診斷時翻閱教科書的特定章節，而不是把整本書從頭讀到尾。這套「按需載入」的架構讓一個 Skill 可以涵蓋十幾個技術領域而不會超出 AI 的處理極限。

這套索引架構從何而來？一次跨 AI 的專利研究

這套多層索引系統不是憑空設計的，它來自一次認真的 Deep Research。

當技能包的檔案數量從 30 多個成長到 80 多個時，我意識到一個問題：Claude 的上下文窗口只有 20 萬 Tokens，不可能一次載入所有檔案。它需要一套「地圖」來決定先讀什麼、後讀什麼、什麼不需要讀。

但我不知道這種「AI 自主導航大型知識庫」的索引架構應該怎麼設計。於是我設計了三組 Deep Research Prompt，分別聚焦在三個問題：LLM 如何自主決定讀取哪些檔案？階層式索引的最佳層數是幾層？每個檔案需要攜帶什麼後設資料才能讓 AI 高效導航？我把這三組 Prompt 分別交給 Claude、ChatGPT、Gemini 各執行兩次，總共產出了六份研究報告。這些報告涵蓋了十多家包含了Palantir、Microsoft、 Amazon… 等科技公司的專利技術。我將這六份報告交給了Claude交叉分析後，最終產出了這套命名為「Ontology-Navigated Progressive Disclosure」的三層架構：

Tier 0（永遠載入，~7.4K tokens）：_schema.yaml（物件類型定義）+ _map.yaml（14 個分類的關鍵字地圖）+ _nav.md（導航協議和停止規則）。這是 AI 的「世界地圖」，每次對話都會載入。

Tier 1（按需載入 2-5 個，~8-16K tokens）：14 個 _idx-*.yaml 分類索引。AI 讀完 Tier 0 的地圖後，判斷當前任務屬於哪些技術領域，只載入對應的索引。

Tier 2（按需載入 10-20 個，~80-120K tokens）：實際的 MD 參考檔案。AI 從 Tier 1 索引中挑選需要的檔案，按需載入。每個檔案分為 CORE（必讀的精華）和 EXTENDED（按需展開的細節），進一步節省上下文空間。

這個架構的設計原則是「先讀地圖，再按圖索驥」，而不是「把所有書搬來再慢慢翻」。它讓一個包含 118 個檔案、總計 1,700K 的技能包，可以在 20 萬 Token 的上下文窗口內高效運作。

為什麼這些 MD 檔案需要持續更新？ 因為專業領域的知識不是靜態的。新的技術方案出現了，先前技術的分析就要更新。新的法規判例出來了，合規檢查表就要調整。隨著工作經驗的累積和對公開技術文獻的持續追蹤，撰寫模式庫也需要收錄新的實踐經驗。每一次對公開資料的 Deep Research，都可能催生出需要新增或更新的參考檔案。三個月下來，最大的一套 Skill 從 30 多個檔案成長到 118 個檔案，總計約 1,700K 的結構化知識。

維護者的日常

我是一位具有電子工程背景的工程師，同時維護著七套這樣的技能包。除了參考檔案的更新之外，日常工作中有些高頻任務（如文件格式轉換）如果全靠 AI 處理，訂閱制的每日用量額度會被大量消耗，排擠掉其他更需要 AI 智慧判斷的工作，需要開發本地程式來取代這類機械性任務。而我雖然有扎實的硬體和系統設計基礎，但不熟悉 Python 等現代程式語言。

手邊有三個 AI 工具可以使用，每個都有不同的能力和限制。

工具本質最擅長的事

Claude Chat（網頁版）：對話式分析平台，可搜尋網路、執行程式、存取專案知識庫、深度分析、策略規劃、知識萃取、設計規格

Claude Cowork（桌面版）：本地檔案操作助手，可直接讀寫電腦上的檔案和資料夾、檔案編輯、批次修改、打包部署、跨檔案調查

Claude Code（命令列版）：自主式程式開發代理，可獨立執行程式碼修改和測試、程式碼除錯、自動化測試、迭代修復、原始碼重構

關鍵的體悟是：沒有任何一個工具能獨立完成所有工作。真正的效率來自於理解每個工具「做不到什麼」，然後用另一個工具來補位。

回頭看這三個月的歷程，它很像一款開放世界的角色扮演遊戲。你一開始只有一把武器（Chat），在新手村裡做任務覺得夠用了。直到有一天，你碰上了一隻靠這把武器打不動的怪物。你不會把遊戲刪掉，你會去找第二把武器。然後你發現第二把武器也有它打不到的怪。於是你去找第三把。

每碰一次壁，你就解鎖一個新能力。每解鎖一個新能力，你就能挑戰更難的任務。而每完成一個更難的任務，你獲得的不只是成果，還有一種「原來可以這樣玩」的成就感。

Chat 的天花板，催生了 Cowork 的遷移

最初，所有技能包的維護都在 Claude Chat 的「專案」功能中進行。這個方式運作了將近三個月。Chat 的專案功能提供了知識庫搜尋（RAG）、跨對話記憶、自訂指令等強大功能，看起來是理想的維護環境。

為什麼需要用「專案」而不是普通對話？ 因為當時一個對話框只有 20 萬 Tokens 的上下文窗口。當技能包有上百個 MD 檔案需要新增或更新時，單一對話框根本無法一次完成所有修改。AI 需要先讀取現有檔案、理解架構、比對研究報告，光是這些就可能佔掉一半以上的上下文窗口。所以我透過 Project 的多對話框機制，將一次大規模更新拆分為多階段任務：每個對話框負責一個子任務，而 Project 的自訂指令和知識庫在所有對話框之間共享，確保任務之間的連貫性。

但隨著技能包從 30 個檔案成長到 118 個檔案，痛點逐漸浮現。這是新手村畢業後碰到的第一場 Boss 戰：不是某一個具體的任務太難，而是工具本身的機制開始拖後腿。

痛點一：每修改一個檔案都要經歷繁瑣的手動循環。 Chat 的專案檔案區是唯讀的。AI 只能把修改後的檔案輸出到一個暫存區，我必須手動下載、刪除舊檔、上傳新檔。當一個任務涉及修改十幾個檔案時，這個循環要重複十幾次。

痛點二：不支援子目錄。 專案檔案區是完全平面的。一個原本有 core/、domains/、references/details/ 等多層目錄結構的技能包，被迫攤平成 118 個同層檔案。為了讓 AI 能正確重建目錄結構，自訂指令中維護了一張 120 行的路徑對照表。

痛點三：編碼限制。 專案檔案區對非 ASCII 字元處理不穩定。所有中文內容必須抽離到單一 JSON 翻譯檔，其餘 117 個檔案全部 ASCII 化。這為每次修改增加了約 30% 的額外工作。

痛點四：自訂指令的膨脹。 路徑對照表、ASCII 化規則、內容所有權表、任務佇列…自訂指令膨脹到 700 行，光是載入這些規則就佔據了 AI 上下文窗口的 15%。

限制催生創意

這些痛點並非一夜之間出現。它們是在一次大規模重構任務（將技能包從平面結構升級為三層漸進式揭露架構，耗時十個對話視窗）中集中爆發的。

我的反應不是放棄，而是問了一個問題：「有沒有可能用另一個工具來消除這些限制？」

答案是 Claude Cowork。Cowork 直接操作本地檔案系統，不需要上傳下載循環、支援子目錄、支援 UTF-8 編碼、不需要路徑對照表。

但遷移本身也是一次創意實踐：

原本 700 行的自訂指令被重新設計為一份精簡的「資料夾指示檔」，因為不再需要補償平台限制的規則

發明了 inbox / pending / processed 三層分類機制，讓多個 AI 工具（Claude、Gemini、ChatGPT）產生的研究報告能有條理地進入維護流程，由 Cowork 自動分類和處理

引入了 Git 版本控制來取代手動維護的修改紀錄檔

檔案修改的手動循環被大幅簡化。

那種感覺就像在遊戲裡磨了很久終於換到一把好武器，突然發現原本需要反覆操作的繁瑣流程現在幾乎一氣呵成。不是任務變簡單了，是你的裝備升級了。而這個「裝備」不是別人給你的，是你自己在碰壁的過程中一點一點拼出來的。

Chat 做分析，Cowork 做執行

遷移完成後，兩個工具形成了穩定的分工模式：

Chat 負責「想」： 深度分析文件內容、評估可行性、設計模組規格、產生結構化的執行指示。Chat 最強大的武器是它的 Deep Research 功能：它可以針對一個技術主題，自動搜尋數十個來源、交叉比對資訊、產出結構化的研究報告。這對於建立技能包的 references MD 檔案至關重要，因為這些 MD 檔案的品質取決於底層研究的廣度和可靠性。

而且我不只用 Claude 一家的 Deep Research。對於同一個技術主題，我會同時動用 Claude、Gemini、ChatGPT 三個 AI 工具分別進行研究。每個 AI 工具的訓練資料和搜尋策略不同，產出的研究報告會從不同角度切入。三份報告交叉比對，可以互相驗證事實、補充彼此的盲區。最終整合進技能包的 MD 參考檔案，是經過多來源驗證的結構化知識，而不是單一 AI 的一家之言。

Cowork 負責「做」： 接收 Chat 產生的執行指示，直接編輯本地的技能包檔案、更新交叉引用、打包成 ZIP 檔案。Cowork 的優勢在於它能直接讀寫本地檔案，不需要任何手動搬運。多個 AI 工具產出的研究報告也由 Cowork 負責分類、整合到對應的技能包中。

一個典型案例完美展示了這種分工：

我在處理已公開的專利之答辯時，發現這個技術領域尚未加入 Skill 的 references MD 檔案中。於是我用 Claude、Gemini、ChatGPT 三個工具分別展開 Deep Research，產出了多份研究報告。Chat 負責分析這些報告、評估該領域與現有技能包架構的契合度、設計新的 MD 檔案規格和導引資料的更新方案，然後產生了一份完整的 Cowork 執行指示。Cowork 接手後，自動完成了新增 MD 參考檔案、更新索引導引、更新版本紀錄、打包部署的全部流程。

AI 生成內容的品質盲區：為什麼人類審查不可或缺

隨著越來越多工作交給 AI 處理，我也逐漸意識到一個容易被忽略的問題：AI 生成的內容看起來流暢、結構完整、邏輯通順，但裡面可能藏著人類不仔細看就發現不了的品質盲區。這些盲區大致可以分為幾種類型：

AI 幻覺（Hallucination）： AI 會自信滿滿地產出根本不存在的事實。例如捏造一個不存在的文獻編號、引用一個從未發表過的研究、或者編造一個看起來很合理但其實查不到來源的統計數據。幻覺的危險在於它的外觀跟正確資訊一模一樣，你不去核實就不會發現。

AI 過度推斷（Over-Elaboration）： AI 有時候會根據訓練資料中的常見模式，自動補充你沒有提供的細節。例如你只描述了一個概念的大方向，AI 卻幫你填入了具體的數值、特定的方法論、或完整的實作步驟，這些看起來合理但其實不是你要表達的內容。

AI 結構性偏差（Structural Bias）： AI 生成的文字有一些很難察覺的結構特徵：句子長度過於均勻、段落結構高度一致、喜歡用三個一組的列舉、過度使用特定的轉折詞。這些特徵單獨來看不是錯誤，但累積起來會讓整份文件帶有明顯的「AI 味」。

AI 語意漂移（Semantic Drift）： 在長篇文件中，AI 有時候會在不同段落中對同一個專有名詞給出微妙不同的定義，或者在前後文之間出現邏輯上的不一致，而表面上每一段讀起來都很通順。

這些品質盲區正是我持續擴充技能包中「品質防護規則」類 MD 檔案的原因。每發現一種新的盲區模式，我就把它的偵測規則和修正方法整理成結構化的參考資料，寫進技能包。下一次 AI 在撰寫時就能自動套用這些規則來避免同樣的問題。換個角度想，這就像玩遊戲時每次被隱形怪打到後，你不只是補血繼續走，而是把這隻怪的攻擊模式記錄下來，鍛造成一件能自動偵測隱形怪的護甲。下次再經過同一片區域，你不會再被同一隻怪打到了。

人類的創意在哪裡？ 在於判斷哪些技術領域值得投入 Deep Research 來擴充技能包，以及如何設計 MD 檔案的結構讓 AI 能有效利用。AI 工具只能在人類定義的框架內運作；框架本身來自人類的洞察。

這就是打電動裡發現「隱藏組合技」的快感。Chat 和 Cowork 各自的能力你都已經熟悉了，但某天你靈光一閃：「如果我讓 Chat 先做 Deep Research 分析出知識結構，再讓 Cowork 把這些知識寫進技能包的 MD 檔案，那以後 Chat 用這個技能包的時候就會自動引用這些知識？」這不是任何一個工具的使用手冊裡教你的。這是你「玩」出來的。

用量額度催生了 Code，看不懂程式碼催生了 Cowork + Code 協作

如果說遷移到 Cowork 是「換裝備」，那接下來發生的事就是誤入了一個全新的副本。

故事要從一個資源排擠的問題說起。

我的日常工作中，有一個高頻任務：將引證文件的 PDF 預處理成結構化的 JSON 檔案，以供後續分析使用。原本這個任務是直接交給 AI 處理的：上傳 PDF，讓 AI 讀取內容、解析結構、輸出 JSON。效果很好，但每處理一份 PDF 就要消耗不少用量額度。身為訂閱制用戶，每日的使用額度是固定的。當一天需要處理數份甚至十幾份引證文件時，光是 PDF 預處理就吃掉了大半額度，留給真正需要 AI 智慧判斷的工作（如深度分析、策略規劃、文件撰寫）的額度就所剩無幾了。

我想到了一個根本性的解法：既然 PDF 到 JSON 的轉換邏輯是可規則化的（版面解析、段落切割、元資料提取），那為何不寫一支程式來做？程式在本地執行，完全不消耗 AI 額度，寫好一次就能反覆使用。把機械性的工作交給程式，把 AI 額度留給真正需要智慧的任務。

問題是：我雖然具備電子工程的底子，對系統架構和資料流有直覺，但不熟悉 Python 語法，看不懂 Code 寫出來的程式碼細節。

Claude Code 解決了「寫程式」的問題。它是命令列環境中的自主式程式開發代理，能根據需求描述獨立撰寫 Python 程式碼、執行測試、根據測試結果自行修改，直到功能完成。於是，一個不熟悉現代程式語言的工程師透過 Code 建立了一個涉及 OCR 處理、正則表達式解析、多格式文件支援、雙欄與單欄版面判斷的 PDF 預處理程式。這在以前是不可想像的事。

但「寫好」和「寫對」是兩回事。

這就像打電動裡經典的劇情轉折：你以為打倒了 Boss（額度排擠問題），結果 Boss 變身了（程式有 bug）。而且這次你手上的武器全部失效，因為你雖然懂系統架構，但不熟悉這隻怪的語言（Python）。

看不懂程式碼，如何除錯？

程式寫出來了，但輸出的 JSON 檔案有各種問題：段落編號錯誤、元資料欄位為空、頁首頁尾文字污染了正文內容、跨頁的段落被截斷。這些都是需要修改程式碼才能解決的 bug。

對於一個看得到程式碼在跑、但讀不懂語法細節的人，最直覺的做法是把問題描述丟回 Code，讓它自己想辦法。但 Code 的使用門檻在這裡浮現了。

Code 本身其實具備讀取 PDF、分析版面的能力，但它是純指令行介面。做個類比：這就像你明明有一台功能齊全的示波器，但操作面板上所有按鈕的標示都是你不熟悉的語言。儀器本身沒問題，是你跟它之間的溝通卡住了。對於習慣圖形化操作的我來說，在指令行環境中做除錯，就像隔著一道牆在修電路：我知道輸出波形不對，但我沒辦法直接拿探棒去量每個節點，我只能用文字告訴牆另一邊的人「幫我量一下那個電容兩端的電壓」。問題是，除錯的本質是探索：你需要東量西量、交叉比對、逐步縮小範圍。如果每一次「伸手去量」都得先組織成一段精確的文字指令，效率就會大打折扣，尤其是當你連「該量哪裡」都還不確定的時候。

Code 有兩種使用情境：一種是目標明確的執行，例如「把這個函式裡的正則表達式改成那樣」，這時候 Code 的效率極高，它可以自己改、自己跑測試、自己驗證，完全不需要我介入。另一種是目標模糊的調查，例如「JSON 輸出的第六段內容是錯的，但我不知道是 PDF 解析錯了、段落切割錯了、還是編號對映錯了」，這時候需要同時打開好幾種檔案來回比對，在指令行裡做這件事就像用對講機指揮別人幫你翻書：可以做，但遠不如自己親手翻來得快。

而 Cowork 恰好填補了這個缺口。

這裡有一個關鍵的底層邏輯：Claude Code 寫的所有程式碼都存放在我的本地端電腦上，而 Cowork 的工作範圍恰好也是本地端電腦上的檔案。換句話說，Code 寫出來的 Python 原始碼、Code 執行後產出的 JSON 輸出、我放進去的 PDF 測試檔案、我設計的 Schema 定義檔，全部都在同一台電腦的同一個資料夾裡。

Cowork 天生就看得到 Code 的一切產出，不需要任何額外的傳輸或轉換。這就像兩個人坐在同一張桌子前工作，桌上的文件兩個人都看得到。

正因為 Cowork 和 Code 共享同一個本地檔案系統，Cowork 可以直接讀取 Code 寫的程式碼（即使我讀不懂 Python 語法，Cowork 讀得懂），同時也能讀取 PDF、MHTML、JSON 輸出等各種格式的檔案。它可以渲染 PDF 頁面為圖片來目視確認版面結構。它可以比對「PDF 第六段寫的是圖式說明，但 JSON 輸出的第六段卻是實施方式描述」這種跨來源的編號矛盾。更重要的是，它可以把程式碼的邏輯和 JSON 輸出的錯誤關聯起來，因為兩者就在同一個資料夾裡，隨時可以交叉比對。

更關鍵的是：預處理後的 JSON 檔案必須遵循一套已經設計好的 Schema。所謂 Schema，就像是一份「標準答案的格式規範」，它定義了輸出檔案應該長什麼樣子：哪些欄位必須存在、每個欄位的資料類型是什麼、欄位之間的關係應該如何對應。就好比你設計一張表格，Schema 規定了這張表格有幾欄、每欄填什麼類型的資料、哪些欄位不能留空。我設計的這套 Schema 包含 30 多項驗證規則，涵蓋了段落編號格式、元資料完整性、內容對應關係等面向。

有了 Schema，除錯就有了明確的判斷基準。Cowork 可以讀取 Schema 定義，再讀取 Code 產出的 JSON，精確地判斷哪些欄位不符合規格、偏差在哪裡、程式碼的哪個環節最可能出問題。

這是整個旅程中最像「遊戲頓悟時刻」的一幕：你盯著螢幕上三個視窗（程式碼、Schema、JSON 輸出），突然意識到「我不需要看懂程式碼，我只需要告訴 Cowork 什麼是正確的格式規範（Schema），什麼是實際的錯誤結果（JSON），它就能幫我反推程式碼哪裡出了問題」。Schema 就是我的「標準答案」，JSON 就是「學生的作業」，Cowork 就是「幫我批改作業並告訴 Code 哪題要訂正的助教」。那個瞬間的興奮感，跟在遊戲裡發現隱藏通道沒什麼兩樣。

於是，除錯的方法自然浮現了：讓 Cowork 當調查員，Code 當執行者，我當品質閘門。

具體的運作方式是這樣的：Code 寫的預處理程式會讀取 PDF 檔案，同時參考對應的 MHTML 網頁存檔作為輔助，將內容轉換成結構化的 JSON 輸出。我拿到 JSON 後，會對照 Schema 的規格定義去檢查：哪個欄位該有值卻是空的、哪個段落的編號跟預期對不上、哪段文字混入了不該出現的頁首頁尾字串。通常是我先發現問題，而不是 Cowork。因為 Cowork 在初期還無法理解 MHTML 與 Schema 之間的對應關係：MHTML 的資料結構跟 PDF 不一樣，段落編號系統不同，元資料散落在不同的 HTML 標籤裡。這些對應規則是我在反覆比對中逐漸摸清楚的，然後一點一點教給 Cowork。

當我發現 JSON 輸出有問題時，我會告訴 Cowork「這幾個欄位不對，正確的值應該長這樣，你去看看程式碼哪裡出了問題」。Cowork 這時候才去讀 Code 寫的 Python 程式碼，根據我指出的錯誤類型反推是哪個函式、哪段邏輯最可能出問題，然後把分析整理成一份結構化的「除錯指示」，交給 Code 去執行修改。隨著迭代次數增加，Cowork 對 MHTML 結構和 Schema 對應關係的理解也越來越深，後期它開始能主動發現一些我還沒注意到的問題。但在早期，發現問題這件事主要靠我的領域知識。

Code 拿到除錯指示後，就進入它最擅長的模式：讀取指定的程式碼段落、修改邏輯、重新跑測試、驗證修復。修完之後我再跑一次預處理，拿到新的 JSON 輸出，再丟給 Cowork 比對。如果還有問題，Cowork 產出下一版除錯指示，Code 繼續修。就這樣一輪一輪迭代，直到 JSON 輸出完全符合 Schema。

在這個迴圈裡，我始終不需要讀懂任何一行 Python 語法。我做的事情只有兩件：一是定義「什麼是正確的輸出」（也就是 Schema），二是看最終的 JSON 檔案告訴 Cowork「這裡對了、那裡還是不對」。這正是工程思維的體現：設計引擎的人不需要親手車出每一個零件，但他必須定義引擎該達到什麼規格，並且在測試台上判斷「這顆引擎過了沒有」。定義規格和驗收成果，這是工程師不可被取代的價值；中間的實作過程，可以交給適合的工具去完成。

版本化除錯指示：兩個 AI 之間的介面

Cowork 和 Code 之間的溝通介面是一份「版本化除錯指示」。這份 Markdown 文件的結構本身就是一次創意實踐：

「已解決」區段：防止 Code 重複修復已修好的問題

「待修復」區段：每個問題附帶具體證據（精確字串、出現次數、檔案位置）

「成功標準」：明確定義什麼算「修好了」

「約束條件」：禁止硬編碼、禁止修改無關程式碼、必須通過回歸測試

零程式碼區塊：因為發現 Code 在處理含有大量程式碼區塊的長指示時會發生截斷

最後一點特別值得一提。第四版指示中包含了程式碼範例，結果 Code 在執行時只處理了指示的前半部分。我注意到這個問題後，Cowork 在後續版本中完全移除了所有程式碼區塊，改用純文字描述修復方法。這個「格式影響執行品質」的發現，是三方協作中只有人類能做出的判斷。

人永遠是品質閘門

在八次迭代的除錯過程中，有四個關鍵問題是人類發現的，而非任何 AI 工具：

問題一： Cowork 在分析網頁存檔時斷言「缺少日期資訊」。我知道這不對，因為網頁存檔中確實包含申請時間軸的完整資料。Cowork 檢查了錯誤的資料欄位。

問題二： 程式碼指示中的程式碼區塊導致 Code 截斷執行。這是一個操作層面的問題，AI 工具不會注意到自己沒有完整執行指示。

問題三： OCR 產生的頁首頁尾文字污染了段落內容。我在閱讀原始輸出時發現了混入的格式字串。

問題四： 測試檔案數量從 19 個清理為 5 個。每次除錯迭代都要跑一輪全部 19 個測試檔案，等待時間太長，嚴重拖慢了除錯節奏。我挑出 5 個最具代表性的檔案，涵蓋不同的版面格式和邊界情況，讓每輪測試的回饋速度大幅加快。

這四個問題的共同特點是：它們需要「領域知識」或「後設認知」（對 AI 工具行為的理解）來發現。AI 工具在自己的能力範圍內表現優異，但它們不知道自己不知道什麼。

互補的串接模式

模式 A：分析 → 執行 Chat 做分析和規格設計 → 產出結構化指示 → Cowork 執行檔案編輯和打包

模式 B：調查 → 修復 Cowork 做多來源調查和問題定位 → 產出版本化除錯指示 → Code 執行程式碼修改和測試

模式 C：研究 → 整合 → 部署 多個 AI 工具（Claude/Gemini/ChatGPT）分別做 Deep Research → 報告匯集到本地 → Cowork 分類、整合、更新技能包 → 打包 ZIP → 上傳雲端平台

模式 D：跨工具迭代 Chat 發現問題模式 → 系統化為方法論 → Cowork 將方法論寫入技能包 → 下次 Chat 使用技能包時自動套用新方法

模式 E：工程師跨語言除錯（額度排擠驅動） AI 預處理吃掉太多額度 → Code 寫本地程式取代 → 程式有 bug 但我不熟悉 Python 語法 → Cowork 讀程式碼 + Schema（格式規範）+ JSON 輸出，反推問題 → 產出除錯指示 → Code 根據指示修復 → 我只需看 JSON 輸出是否符合 Schema

困難催生創意

AI 預處理 PDF 吃掉太多每日額度，排擠其他工作

讓 Code 寫一支本地程式，把機械性任務從 AI 額度中釋放出來

有工程底子但不熟悉 Python，看得到程式碼但讀不懂

讓 Cowork 讀程式碼和 Schema（格式規範），用 JSON 輸出的錯誤反推程式碼問題，產生除錯指示給 Code

專案檔案區不支援子目錄

發明了 120 行路徑對照表，後來又催生了遷移到 Cowork 的決定

每次修改都要經歷繁瑣的手動上傳下載循環

設計了 inbox / pending / processed 三層自動分類機制

AI 生成內容的品質盲區是現有工具未覆蓋的偵測類別

從具體案例歸納出多種模式，系統化為可重複使用的檢查模組

除錯指示中的程式碼區塊導致 Code 截斷

發明了「零程式碼區塊」的純文字除錯指示格式

PDF 和 MHTML 對同一內容使用不同段落編號

Cowork 渲染 PDF 為圖片做目視確認，建立跨來源對照機制

Cowork 對 MHTML 的分析有錯誤假設

建立了「AI 產出必經人類驗證」的品質閘門原則

前兩個實例特別值得注意，因為它們展示了一個完整的創意連鎖反應：額度排擠問題 → 決定寫程式 → 但不熟悉 Python → 用 Code 來寫 → 程式有 bug → 但讀不懂語法細節無法自己改 → 發現 Cowork 可以讀程式碼和 Schema（格式規範）→ 讓 Cowork 產生除錯指示 → Code 根據指示修復。這整條鏈路的每一步都是「碰壁後轉向」的結果。

為什麼整個過程像打電動

如果你問我三個月下來最深的感受是什麼，答案可能不是「效率提升了」或「流程改善了」。答案更接近：「很好玩。」

這整個過程有一種打電動的節奏。

打怪： 每一個限制都是一隻怪物。Chat 的手動上傳下載循環是一隻磨人的小怪，做一兩次沒什麼，做一百次就受不了。程式碼的 bug 是一隻會變身的 Boss，你以為修好了，跑測試才發現它換了一個形態出現。AI 生成內容中隱藏的品質問題是一隻隱形怪，你不知道它存在，直到仔細比對原始資料才發現。

升級： 每打倒一隻怪，你就獲得經驗值。不是工具的經驗值，是你對「工具能做什麼、不能做什麼」的理解。這份理解是真正的升級。第一次用 Cowork 的人和用了三個月的人，手上是同一個工具，但後者知道什麼時候該讓 Cowork 上、什麼時候該切回 Chat、什麼時候該叫 Code 出場。

裝備： 每一個你發明的流程、格式、介面，都是一件裝備。而那些 MD 參考檔案本身就是你最核心的裝備庫存。每寫好一份先前技術分析，就是往武器庫裡多放了一把針對特定怪物的武器。每整理好一份撰寫模式庫，就是多了一件提升全隊輸出的增益裝備。inbox 三層分類機制是一件自動拾取裝備。版本化除錯指示的格式是一件增傷裝備。「零程式碼區塊」規則是一件從失敗中鍛造的防具。這些裝備不是別人給的，是你在副本裡一件一件打出來的。

成就感： 最讓人上癮的不是最終結果，而是那些「頓悟時刻」。「原來 Cowork 可以讀 Code 的程式碼！」「原來我不需要看懂程式碼，只要定義好 Schema（格式規範）就能驅動除錯！」每一個頓悟都帶來一波多巴胺，讓你忍不住想：「還有什麼是可以這樣玩的？」

而且這個遊戲沒有終點。 七套技能包在持續演化，新的領域在不斷加入，工具本身也在更新。你永遠不會「破關」。但這恰恰是它好玩的地方：每一天都有新的怪可以打，新的組合技可以嘗試，新的裝備可以鍛造。

最重要的是：能力的增長不是線性的，而是指數型的。 打電動的人都知道，前期升級很慢，裝備少、技能少、每隻怪都要苦打。但過了某個臨界點之後，裝備開始互相加成，技能開始觸發連鎖效果，原本需要十分鐘的戰鬥現在三十秒就結束了。AI 工具的使用也一樣。當你只有 Chat 一個工具、零個自訂技能包的時候，每個任務都要從頭教 AI。但當你累積了七套技能包、三個工具的串接經驗、一套成熟的研究到部署的流水線之後，新任務的處理速度和品質會急遽提升。因為每一次經驗都沉澱為技能包裡的 MD 參考檔案，每一個流程改進都固化為 Cowork 的指示檔，每一次除錯都讓 Schema（格式規範）變得更完善。那些 MD 檔案不是死的文件，它們是活的知識庫：你今天花一小時整理的先前技術分析，明天 AI 在處理類似案件時就會自動引用，省下的不只是一小時，而是你原本需要從頭解釋背景知識的整段對話。檔案越多、覆蓋越廣，AI 就越像一個真正了解你的領域的助手。你不只是在完成任務，你是在建造一台越轉越快的飛輪。

這跟原子習慣的概念很像：每天進步 1%，一年後你不是進步了 365%，而是 37 倍。每天多摸索一個工具的小技巧、多整理一份參考資料、多把一次踩坑經驗寫進技能包，這些微小的累積在初期幾乎感覺不到差異。但三個月後回頭看，你會驚訝於自己的工作方式已經完全不同了。

而學習的心法，其實跟讀物理很像。 讀物理的人知道，死背公式是最笨的方法。真正有效的是理解底層邏輯：牛頓三大定律搞懂了，很多力學題目自然就會解。學 AI 工具也是一樣的道理。與其去記每個工具的每個功能，不如先搞懂每個工具的底層限制是什麼。Chat 的限制是什麼？不能直接改本地檔案。Cowork 的限制是什麼？不能跑程式碼。Code 的限制是什麼？指令行介面不適合做探索式調查。當你把這些限制摸透了，工具之間的串接方式就像物理題的解法一樣，很自然地就浮現了。你不需要有人教你「先用 Cowork 讀 Schema（格式規範）再產生除錯指示給 Code」這種特定的組合技，因為當你理解了兩個工具各自做不到什麼，這個串接方案就是唯一合理的解法。

新手攻略

三把武器都先摸摸看。 不要一開始就想把每把武器運用到極致。輪著用、不熟也無妨，多用多嘗試，手感自然會來。當你碰到某把武器怎麼揮都打不動的怪時，自然會想到切換另一把試試。碰壁的那個瞬間，你自然會知道需要什麼。是檔案搬運太痛苦？那就是 Cowork 出場的時機。是需要寫程式？那就是 Code 出場的時機。讓痛點當你的導師。

打造你的專屬裝備。 工具之間的介面比工具本身更重要。Chat 和 Cowork 之間的「結構化執行指示」、Cowork 和 Code 之間的「版本化除錯指示」，這些介面文件的品質直接決定了協作效率。花時間設計好介面格式，這是你最值得投資的裝備欄位。

你是隊長，不是旁觀者。 AI 工具不知道自己不知道什麼。在 MHTML 日期的例子中，Cowork 自信地給出了錯誤的分析。在 AI 生成內容的品質審查中，AI 產生的技術內容看起來完全合理，但原始來源中從未提及。只有了解脈絡的人才能發現這些問題。你不需要會寫程式，但你需要知道「什麼是對的」。

程式碼看不懂語法沒關係，看得懂邏輯就夠了。 我在 Code 撰寫和修改程式碼時看了很多，Python 語法不熟，但電子工程的底子讓我能理解資料流和系統架構。我能判斷的是「JSON 輸出對不對」和「Schema（格式規範）定義的是什麼」。Cowork 把「輸出不符合 Schema」翻譯成「程式碼哪裡需要改」，Code 把「需要改」翻譯成「實際修改程式碼」。你需要的不是讀懂每一行語法，而是定義「什麼是正確結果」的工程判斷力。

每次翻車都是鍛造材料。 品質檢查模組中的多種偵測模式不是憑空設計的，它們來自一次又一次具體案例的審查經驗。除錯指示的「零程式碼區塊」格式不是事先規劃的，它來自一次截斷事故。每一次「這次搞砸了」都是「下次怎麼避免」的起點。最好的裝備都是從失敗的素材中鍛造出來的。

享受探索的過程。 三個月前，我知道 Cowork 和 Code 的存在，也知道它們各自能做什麼，但從沒想過可以這樣串連起來用。「讓 Cowork 讀 Code 寫的程式碼，再產生除錯指示餵回 Code」這種組合技，不是任何一個工具的使用手冊裡教的。「AI 生成內容的品質盲區」作為一個值得系統化偵測的問題類別，也不是事先規劃的。這些都是在「玩」的過程中，一次又一次碰壁、轉向、嘗試之後，才逐漸拼湊出來的。最有價值的知識不是來自使用手冊，而是來自「如果我試試這樣做呢？」的好奇心。