心法四：兩個原則，一個提醒，與螺旋的全貌
前三篇我們建立了工作流程心法的五個階段：串接工作流程、設計 Context 交接、診斷精煉與平台思維、演進到 Agent Team、擴充與發現人類價值。
但上一篇結尾我提到：如果你現在就開始動手，有兩個坑幾乎無法避免。這兩個坑不是因為你不夠小心，而是 AI 的根本性限制造成的。好消息是，有明確的對策。先談對策，再談一個貫穿全局的提醒。
原則一：用不同的 Agent 交叉稽核
第一個坑，Agent 有一個根本性的限制：他很難發現自己的盲點。
這不只是直覺 — 學術研究已經證實了這點。MIT Press 發表在 TACL 上的一篇系統性調查 [2] 直接指出：沒有主要研究在公平設定下證明 LLM 能透過自我提示成功自我糾正。 在某些情況下，自我糾正後的性能反而下降。
為什麼？Nova Spivack 的分析 [19] 解釋了根本原因：LLM 產生的內容具有高度內部自洽性（internal self-consistency）。他用同一套推理邏輯生成內容，再用同一套推理邏輯去檢查 — 錯誤對他自己來說看起來是合理的。GPT-4o 的測試顯示準確率 49.71%，但過度自信率高達 39.25%。
arXiv 上的 CRITIC 框架研究 [3] 則提出了解法：有效的自我糾正需要 外部回饋 — 搜尋引擎、程式碼執行器、知識庫，而非純粹依賴內部評估。
這就是為什麼交叉稽核不是「nice-to-have」，而是「must-have」。
（你可能會想：上一篇不是才說「不要隨便建新 Agent」嗎？沒錯，但 review 和 audit 正好是需要獨立 Context 的正當場景 — 重點不是「不能用多個 Agent」，而是「每一個 Agent 都要有明確的理由」。）
方法一：請 Agent 把設計寫下來，然後用另一個 Agent 來審查。 因為新的 Agent 有乾淨的 Context，他不會繼承前一個 Agent 的假設和偏見。
方法二：用 Multi-Agent 的方式，讓 Agent 啟用一個 Skill 去呼叫另一個 Agent 來做稽核。 這在架構上就是第五篇講的 Subagent 隔離 — 隔離的不只是 Token，還有思維模式。
這個原則在工作流程的每一個階段都適用：
- 第一階段：新串起來的工作流程，讓另一個 Agent 檢查有沒有邏輯漏洞
- 第三階段：/insight 的建議，讓另一個 Agent 評估是否合理
- 第四階段：Agent Team 的設計，讓獨立的 Agent 做 architecture review
原則二：驗證時效性 — 請 AI 搜尋最新資料
第二個坑，Agent 提出的解決方案，通常是基於他訓練資料中 最常見 的做法，而不是 最新 的做法。
這不是猜測 — ICSE 2025（軟體工程頂級會議）的一篇論文 [4] 直接驗證了這個問題：研究團隊評估了 7 個主流 LLM，所有模型都在 code completion 中使用了已棄用的 API。 根本原因是訓練資料同時包含新舊 API，模型「記憶」了過時的用法。arXiv 上的另一項研究 [8] 更具體 — 有開發者報告因為 GPT-4 建議使用已移除兩個版本的功能，而浪費了一整天。
更糟的是，有些做法已經過時了，但 AI 不會自己告訴你。他不知道某個 library 已經 deprecated，某個 API 已經有了新版本，某個設計模式已經被社群淘汰。
解法：主動請 AI 上網搜尋最新資料來驗證自己的方案。
當 Agent 完成設計文件後，你可以這樣指示他：
「搜尋這份設計文件中使用的方法和技術，確認是否有更新的替代方案或已知的問題。如果有任何過時的做法，請標記出來。」
你會驚訝地發現，Agent 在被要求搜尋時，會變得更加謹慎。他會主動用最新的資料來重新審視自己的設計，有時候甚至會推翻自己原本的建議。
Lakera 的研究 [20] 也支持這個做法：RAG（Retrieval-Augmented Generation）可以降低 40-71% 的幻覺率。雖然我們這裡談的不是傳統的 RAG pipeline，但本質一樣 — 引入外部資訊來校正模型的內部偏差。
這個原則跟「交叉稽核」本質上是同一件事 — 引入外部資訊來打破 Context 的封閉性。 交叉稽核用的是另一個 Agent 的視角，時效性驗證用的是網路上的最新資料。
一個提醒：七篇文章是可執行的原則，不只是知識
以上兩個原則是針對具體的坑。但還有一件事，它不是對策，而是貫穿整個心法的基礎。
那七篇文章講的是技術，不是心法。它們跟「建立工作流程」這件事沒有直接關係。但它們提供了一套 可以被 AI 遵循的原則。
你可以這樣用它們：
- 快速瀏覽一遍，建立概念性的理解
- 把它們交給 AI，讓 AI 讀取後作為工作原則
- 用這些原則來指導 AI 建立你的工作流程
你不需要完全理解裡面的每一個技術細節。但你需要理解 概念 — Context 流向、Token 預算、Progressive Disclosure、Subagent Return Contract。這些概念是你的「除錯工具」。
當 AI 出問題的時候 — 回應品質下降、工作流程斷裂、成本失控 — 你需要這些概念來判斷：
- 是 Context 爆了嗎？→ 檢查 Token 預算
- 是交接斷裂了嗎？→ 檢查 Subagent Return Contract
- 是知識沒載入嗎？→ 檢查 JIT 策略
- 是 Agent 太雜了嗎？→ 檢查工具數量和 Skill 分層
概念讓你能診斷問題，心法讓你能設計流程。 兩者結合，才是完整的 AI 工作方法。
一個誠實的註腳：這個閉環還在成熟中
在收尾之前，我想誠實地說一件事。
這四篇文章描述的五階段螺旋，是一個 方向，不是一個已經被完全驗證的成熟方法論。Frontiers in Computer Science 的一篇系統性文獻回顧 [9] 直接指出：「Human-AI collaboration is not very collaborative yet」— 大多數現有系統仍然是單向的，缺乏真正的迭代回饋迴路。
另外，arXiv 上一篇關於自動化 AI 研發的研究 [30] 也提出了警告：25 位受訪研究者中有 20 位認為不受約束的自動化迭代，在安全敏感環境中會增加風險。
但我認為這個限制會在相對短的時間內被突破 — 我的預期是 3 到 6 個月。
理由很簡單：AI 能力的演進速度非常快。半年前，Agent Team 還是實驗性功能；現在已經有團隊在生產環境中使用。半年前，Skill 還只是 Claude Code 的專屬格式；現在已經開始被其他平台採用。迭代協作的基礎設施正在快速成熟。
但在現階段，這意味著什麼？
意味著你不應該因為「迭代閉環尚未完全成熟」就不使用它，而是要在使用的同時，建立足夠的監控機制：
- 限定迭代範圍 — 不要讓 AI 在無邊界的情況下自由迭代。每個迭代循環都要有明確的 scope 和退出條件
- Human-in-the-loop 檢查點 — 在關鍵節點設置人類審查，特別是在跨 Agent 交接和最終輸出的地方
- 健康度指標 — 設計可觀測的指標，讓迭代中一旦出現品質下降、複雜度膨脹、或 failure drift 的跡象，人類可以及時介入修正
- 降級機制 — 如果自動化迭代出了問題，要能快速回到 human-in-the-loop 模式，而不是整個系統停擺
Parseur 的 2026 分析 [26] 也支持這個思路：Human approval gates 作為品質控制點，人類的商業判斷為自動化決策增加了真正的價值。重點不是「AI 能不能自己跑完整個循環」，而是「你有沒有設計好人類介入的接口」。
這不是迭代本身的問題，而是 監控機制的問題。有了好的監控，即使底層的 AI 協作還在成熟中，你也能安全地使用這個閉環。
整體的閉環
把五個階段畫在一起，它其實是一個螺旋：
這個螺旋沒有終點。每轉一圈，你的工作流程更完善、你對人類價值的理解更清晰、AI 能處理的範圍更大。
而這個過程中最重要的一件事，不是任何一個技術選擇，而是：
你願不願意持續地觀察、診斷、調整？
AI 不會自己變好。工作流程不會自己進化。是你在推動這個螺旋轉動的。
技術是地基，心法是方向。地基決定你能蓋多高，方向決定你往哪裡走。前七篇給了你地基，這四篇給你方向。
剩下的，就是動手了。
參考連結
[2] Huang et al., “When Can LLMs Actually Correct Their Own Mistakes?” (MIT Press/TACL) https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00713/125177
[3] “CRITIC: Tool-Interactive Critiquing” (arXiv) — 有效自我糾正需要外部回饋 https://arxiv.org/abs/2305.11738
[4] “LLMs Meet Library Evolution” (ICSE 2025) — 所有測試 LLM 都使用已棄用的 API https://dl.acm.org/doi/10.1109/ICSE55347.2025.00245
[8] “Deprecated API Usage in LLM Code Completion” (arXiv) — knowledge cutoff 導致過時建議 https://arxiv.org/html/2406.09834v1
[9] “Human-AI Collaboration: Not Very Collaborative Yet” (Frontiers in Computer Science) https://www.frontiersin.org/journals/computer-science/articles/10.3389/fcomp.2024.1521066/full
[18] DEV Community, “Iterative Review-Fix Loops Formula” — 迭代精確度天花板的數學分析 https://dev.to/yannick555/iterative-review-fix-loops-remove-llm-hallucinations-and-there-is-a-formula-for-it-4ee8
[19] Nova Spivack, “Why AI Can’t Catch Their Own Mistakes” — LLM 內部自洽性分析 https://www.novaspivack.com/technology/ai-technology/why-ai-systems-cant-catch-their-own-mistakes-and-what-to-do-about-it
[20] Lakera, “LLM Hallucinations Guide 2026” — RAG 降低 40-71% 幻覺率 https://www.lakera.ai/blog/guide-to-hallucinations-in-large-language-models
[26] Parseur, “Future of Human-in-the-Loop AI 2026” — human approval gates 作為品質控制 https://parseur.com/blog/future-of-hitl-ai
[30] “AI Researchers on Automating AI R&D” (arXiv) — 不受約束的自動化迭代風險 https://arxiv.org/html/2603.03338v2
[31] Anthropic, “Building Effective Agents” (2024) — 官方指南：先用盡簡單方案，只在必要時才增加複雜度 https://www.anthropic.com/research/building-effective-agents
支持這個系列
如果這系列文章對你有幫助，考慮請我喝杯咖啡
請我喝杯咖啡
