AI Knowledge Archive - Batch Summary

處理文章數

涵蓋分類數

🌟 今日領域總結 (Domain Summaries)

AI工具領域

AI工具總結報告

Claude Code 的 Model 與 Effort 設定經常被誤解為「都讓答案更好」的平行選項，但實際上它們控制完全不同的維度。Model 控制使用哪一組**凍結的 weights**（能力上限、知識庫），而 Effort 控制在請求時的工作深度（token 數量、工作量、驗證程度）。核心診斷框架是：當 Claude 搞砸時，**先查 context**（prompt、tools、skills、verification），再區分問題類型——「不知道」（Model 問題）需要換更大的模型，「不夠努力」（Effort 問題）需要提高工作深度。Token 經濟學顯示：常規任務小模型省錢不犧牲品質，困難任務大模型雖單 token 貴但總成本可能更低（更少步數達品質門檻）。高 Effort 不是「想更久」而是「做更多事」（讀更多檔案、跑測試、雙重驗證），且計畫會動態調整（找到 bug 後跳過剩餘假設）。

核心主題 (Key Themes)

Model = 能力上限（凍結的知識庫），Effort = 工作深度（嘗試程度）：Model 選擇實際上是交換哪一組凍結的 weights 處理請求。weights 在訓練時設定，inference 期間唯讀——你的 prompt、CLAUDE.md、context 都不會改變它們，只能「引導」預測方向。這解釋了為什麼「沒見過的庫」無法被「教會」若庫在訓練時不存在，它就不在 we...
診斷優先順序：Context → Model vs Effort：當 Claude 搞砸時，第一直覺不應該是改設定，而是檢查 context。你的 prompt 太模糊嗎？Claude 連到正確工具嗎？它有正確 skills 嗎？只有在給了明確 context 且仍失敗時，才診斷是「不知道」還是「不夠努力」。
Token 經濟學：常務省錢 vs 困難任務的成本曲線交叉：Model 選擇、Effort、Token 消耗的互動取決於任務類型。
Effort 的動態特性：計畫不是凍結的：高 Effort 不是「想更久」，而是「做更多事」，且計畫會動態調整。當三假設除錯計畫的步驟 1 找到 bug，「調查假設 2 和 3」可能不再必要。Claude 通常會明確說這點（例如「第一次檢查找到了，所以剩餘檢查不需要」）並跳過——你會在 Claude Code 中看到任務列表中途被修訂。
比喻框架：專家、高手、通才 + 時間分配：Fable＝專家能處理幾乎無人能解問題的專家。即使低 Effort，他們會發現沒人會發現的事。那認知也是你付最多費的，所以值得保留給真正需要的任務。

# 領域總結：AI工具 (2026-07-09) ## 總結概述 Claude Code 的 Model 與 Effort 設定經常被誤解為「都讓答案更好」的平行選項，但實際上它們控制完全不同的維度。Model 控制使用哪一組**凍結的 weights**（能力上限、知識庫），而 Effort 控制在請求時的工作深度（token 數量、工作量、驗證程度）。核心診斷框架是：當 Claude 搞砸時，**先查 context**（prompt、tools、skills、verification），再區分問題類型——「不知道」（Model 問題）需要換更大的模型，「不夠努力」（Effort 問題）需要提高工作深度。Token 經濟學顯示：常規任務小模型省錢不犧牲品質，困難任務大模型雖單 token 貴但總成本可能更低（更少步數達品質門檻）。高 Effort 不是「想更久」而是「做更多事」（讀更多檔案、跑測試、雙重驗證），且計畫會動態調整（找到 bug 後跳過剩餘假設）。 ## 核心洞察與共同趨勢 ### 1. Model = 能力上限（凍結的知識庫），Effort = 工作深度（嘗試程度） Model 選擇實際上是交換哪一組**凍結的 weights** 處理請求。weights 在訓練時設定，inference 期間唯讀——你的 prompt、CLAUDE.md、context 都不會改變它們，只能「引導」預測方向。這解釋了為什麼「沒見過的庫」無法被「教會」：若庫在訓練時不存在，它就不在 weights 中，提供 docs 只是**單次引導**（steering），不是教學（teaching），Claude 的回應只影響該次請求，底層 model 未保留任何東西。 Effort 控制的是工作量，包括讀檔數量、驗證程度、執行步數。高 Effort 時 Claude 會執行更多動作（讀檔、跑測試、雙重檢查）才回報；低 Effort 時寧可詢問更多 context，自己少花 token 推演。實測顯示相同 prompt 下，高 Effort 路徑生成約 **7x tokens** 以達到更高信心答案。 * **案例**：`const x = await` 的預測來自訓練時編碼的權重——`const` 映射到 token ID 1978，`await` 映射到 4293，model 預測下一個 token 時計算詞彙表中每個 token 的機率，這些機率完全由凍結的 weights 決定，prompt 只能引導預測方向。 * **案例**：Opus 4.8 預設 Effort 在相同任務上產生比 Opus 4.7 預設 Effort 更好的結果，且 token 量大約相同——顯示 Effort 是「學到的行為」烘焙到 weights 中，而非簡單的時間設定。 ### 2. 診斷優先順序：Context → Model vs Effort 當 Claude 搞砸時，第一直覺不應該是改設定，而是**檢查 context**。你的 prompt 太模糊嗎？Claude 連到正確工具嗎？它有正確 skills 嗎？只有在給了明確 context 且仍失敗時，才診斷是「不知道」還是「不夠努力」。 * **「不知道」→ 換 Model**：選更大 model 當問題真正困難（微妙 bug、陌生領域、架構決策）。當小 model 不管給多少 context 都**自信地錯**時，大 model 是你要的。大模型也更擅長處理模糊性，在小 model 上指向執行的具體指令更成功。 * **「不夠努力」→ 調 Effort**：選更高 Effort 如果 Claude 因不夠努力而做錯（跳過檔案、不跑測試、不雙重檢查）。這最相關於如果你選了低於 model 預設的 Effort 等級。 * **案例**：常規編輯任務使用 Sonnet 高 Effort（有一下午的通才，會讀所有東西、執行、雙重檢查）比 Opus 低 Effort（高手 5 分鐘，快速讀碼不仔細通過每個檔案）更適合；架構設計則需要 Opus 高 Effort 或 Fable（專家處理幾乎無人能解的問題）。 ### 3. Token 經濟學：常務省錢 vs 困難任務的成本曲線交叉 Model 選擇、Effort、Token 消耗的互動取決於任務類型。 * **常務工作**：大、小 model 通常都對。大 model 用額外驗證步驟消耗更多 tokens，且每 token 價格更高——這是常務 stretch 降到小 model 省真錢又不犧牲品質的原因。 * **困難、多步驟工作**：公式翻轉。小 model 必須磨到能力極限，燃燒迭代，而大 model 用更少步數達到相同品質門檻。你為大 model 每個 token 付更多，但在真正拉伸小 model 的任務上，**每任務總成本可能更低**。 * **Fable 定位**：在長、多步驟工作拉得最領先，完成 Opus 和 Sonnet 在任何 Effort 都达不到的工作。但每 token 成本最高，值得保留給真正需要的任務。 * **案例**：簡單編輯任務兩個模型都能快速完成，小 model 因較少驗證步驟而總成本更低；複雜架構決策大 model 用更少迭代達成，雖單 token 貴但總成本可能更低。 ### 4. Effort 的動態特性：計畫不是凍結的高 Effort 不是「想更久」，而是「做更多事」，且**計畫會動態調整**。當三假設除錯計畫的步驟 1 找到 bug，「調查假設 2 和 3」可能不再必要。Claude 通常會明確說這點（例如「第一次檢查找到了，所以剩餘檢查不需要」）並跳過——你會在 Claude Code 中看到任務列表中途被修訂。高 Effort 確實讓 Claude 更可能雙重檢查（驗證找到的答案、仍調查可跳過的假設），但通常不會只因 Effort 調高就人為膨脹簡單任務的使用量。「Overthinking」在 model 訓練時特別注意避免，因為它會降低效果。 * **案例**：高 Effort 路徑生成約 7x tokens（含更多思考、驗證步驟），但在找到解後會跳過剩餘假設，不是死板執行原始計畫的所有步驟。 * **案例**：簡單問答即使高 Effort 也不會膨脹——訓練時避免「不必要的推理步驟」，模型學會在簡單任務上保持簡潔。 ### 5. 比喻框架：專家、高手、通才 + 時間分配 * **Fable＝專家**：能處理幾乎無人能解問題的專家。即使低 Effort，他們會發現沒人會發現的事。那認知也是你付最多費的，所以值得保留給真正需要的任務。 * **Opus＝高手**：有深層經驗的高手。他們帶來你程式庫中沒有的知識；他們看過的模式、他們知道要檢查的 gotcha、只有解過很多類似問題才得到的經驗。 * **Sonnet＝通才**：很棒的通才。擅長寫程式，會讀所有東西、執行、雙重檢查工作，最後徹底理解你的特定程式碼。 * **Effort＝時間**：Opus 低 Effort 像得到高手 5 分鐘（快速讀碼不仔細），Sonnet 高 Effort 是有一下午的通才（徹底理解）。 **沒有一個普遍「更好」**。Model 設定大約是**多能**；Effort 設定大約是**多徹底**。大多數真實任務需要兩者的一些。 ## 行動建議與實踐指南 ### 1. 建立 Model-Effort 決策樹，記錄失敗模式下次 Claude 搞砸時，先記錄「失敗模式」再診斷：是「沒讀某檔」「沒驗證結果」「沒跑測試」（Effort 問題）還是「產生不存在 API」「混淆概念」（Model 問題）。建立團隊內部的決策樹： * **常規編輯** → Sonnet Default（預設 Effort 已足夠） * **機械性變更** → Sonnet Default 或 Low（可偏好詢問而非自行推演） * **架構設計** → Opus High（需要計畫先行、讀取所有檔案、執行測試、雙重驗證） * **微妙 bug** → Opus High 或 Fable（需要深層經驗和細緻調查） * **陌生領域** → Fable（需要專家級知識庫） * **深坑問題** → Fable（處理幾乎無人能解的問題） ### 2. 診斷時嚴守「先 context，再設定」順序改變任何設定前，先檢查： * **Prompt 精確度**：是否描述清楚任務目標、範圍、輸出格式？ * **Tools 可用性**：Claude 是否連到正確工具（Read、Edit、Bash 等）？ * **Skills 匹配度**：是否有相關 skill 可用？ * **Verification 機制**：是否有方法讓 Claude 驗證自己的工作？只有在 context 完整仍失敗時，才考慮換 Model 或調 Effort。 ### 3. 根據任務類型選擇 Effort 等級 * **使用預設 Effort**：對大多數任務，預設是 Claude 將 token 使用量調整到大多數人在任務上願意花費的等級。 * **提高 Effort**：當你需要更高徹底度（跳過檔案、不跑測試、不雙重檢查工作），或你對徹底度有強烈偏好（基於領域或工作類型）。 * **降低 Effort**：當你偏好速度，且任務可精確描述（常規編輯、機械性變更）。 * **將 Effort 視為通用偏好**：而非逐任務決策。刻意使用時，將其設定為領域或工作類型的預設行為。 ### 4. Token 成本優化策略 * **常務工作降級 Model**：簡單編輯、機械性變更、已載入程式碼問題，用 Sonnet 而非 Opus/Fable——省真錢又不犧牲品質。 * **困難工作投資大 Model**：架構決策、微妙 bug、陌生領域，用 Opus 或 Fable——雖單 token 貴，但總成本可能更低（更少步數達品質門檻），且能完成小 model 不能的任務。 * **Fable 保留給真正需要**：最困難、多步驟工作，或 Opus/Sonnet 在任何 Effort 都达不到的工作。 * **監控 Token 消耗模式**：觀察任務的 token 曲線——常務任務應相對平坦（少驗證步驟），困難任務可能有早期峰值（多計畫、多驗證）但總步數較少。 --- **資料來源**：2026-07-09 AI 工具領域 XRay 深度拆解（1 篇） **原始文章**：Model and effort in Claude Code: knowing more vs. trying harder by Lydia Hallie (@lydiahallie), Claude Code 團隊技術成員

Obsidian 開啟

AI工程領域

AI工程總結報告

今天 AI 工程三篇文章的共同主線是「重新界定瓶頸」：直覺以為的約束（模型 token 成本、模型強度、GPU 記憶體容量）被證明不是真正的閘門，工程重心於是從「換更強／更便宜」轉向「重構資料路徑與控制路徑」。KV Caching 揭露 agent 推理預算約 62% 是重複內容，而 prefix caching 的 byte-for-byte 前綴硬上限在 RAG 多文件、順序變動、歷史增長三場景全 miss；LMCache 把 cache 管理拆成獨立 process 消除 20%+ 爭用損耗（實測 14x TTFT），CacheBlend 利用 attention 局部性只重算跨文件邊界 token 打破前綴限制。私有知識庫 8 層工程把「demo 聰明、日常崩潰」歸因到檢索鏈路而非模型，權限在檢索前過濾、混合檢索（dense + BM25 + metadata filter + reranker）、評估集分檢索／生成兩層，是 demo 與生產的分水嶺。Qwen3-235B 以 1.58-bit ternary quantization（53 GB）+ per-expert 磁碟串流證明 frontier MoE 的記憶體牆已變成磁碟頻寬牆，fit 與總參數數解耦（跨 7× 模型尺寸峰值穩在 9–15 GB）。三篇共享同一組分散式系統的老直覺——關注分離、記憶體階層下推、利用稀疏性、可觀測性先行——AI 工程正在把資料庫、OS、CDN 驗證過的架構原則重新套用到 LLM 基礎設施上。

核心主題 (Key Themes)

「優化錯誤的變數」是三篇共通的反模式——直覺瓶頸是假象：三篇文章的第一句話都在拆穿同一個直覺你以為的瓶頸不是真正的瓶頸，繼續往錯誤方向使力只會放大浪費。
關注分離：I/O 重與 compute 重必須拆開，這是可遷移的架構鐵律：把本質不同的工作負載塞進同一個 process（或同一條 pipeline），是三篇文章共同指認的結構性缺陷；解法都是把資料路徑與控制路徑、或 I/O 與 compute 拆離。
記憶體階層下推：熱冷資料分層，按需拉取取代全量駐留：三篇都在實作「把熱資料放快層、冷資料按需從慢層拉」的記憶體階層設計——這是 OS demand paging、DB buffer pool manager、串流媒體 chunked delivery 的同一套直覺，現在被打進 LLM 基礎設施。
稀疏性與局部性是可榨取的結構性紅利：三篇都沒有發明新演算法，而是利用模型或資料本身的稀疏結構，把「全量重算」降級為「只算必要的少數」——這是效能紅利的真正來源。
可觀測與可驗證是上生產的硬門檻——指標先行、回歸測試、等價驗證：三篇都不把「跑起來」當終點，而是把「可度量、可追溯、可回滾」視為生產化的真正門檻；缺乏觀測的優化等於靠感覺調參。

# 領域總結：AI工程 (2026-07-09) ## 總結概述今天 AI 工程三篇文章的共同主線是「重新界定瓶頸」：直覺以為的約束（模型 token 成本、模型強度、GPU 記憶體容量）被證明不是真正的閘門，工程重心於是從「換更強／更便宜」轉向「重構資料路徑與控制路徑」。KV Caching 揭露 agent 推理預算約 62% 是重複內容，而 prefix caching 的 byte-for-byte 前綴硬上限在 RAG 多文件、順序變動、歷史增長三場景全 miss；LMCache 把 cache 管理拆成獨立 process 消除 20%+ 爭用損耗（實測 14x TTFT），CacheBlend 利用 attention 局部性只重算跨文件邊界 token 打破前綴限制。私有知識庫 8 層工程把「demo 聰明、日常崩潰」歸因到檢索鏈路而非模型，權限在檢索前過濾、混合檢索（dense + BM25 + metadata filter + reranker）、評估集分檢索／生成兩層，是 demo 與生產的分水嶺。Qwen3-235B 以 1.58-bit ternary quantization（53 GB）+ per-expert 磁碟串流證明 frontier MoE 的記憶體牆已變成磁碟頻寬牆，fit 與總參數數解耦（跨 7× 模型尺寸峰值穩在 9–15 GB）。三篇共享同一組分散式系統的老直覺——關注分離、記憶體階層下推、利用稀疏性、可觀測性先行——AI 工程正在把資料庫、OS、CDN 驗證過的架構原則重新套用到 LLM 基礎設施上。 ## 核心洞察與共同趨勢 ### 1. 「優化錯誤的變數」是三篇共通的反模式——直覺瓶頸是假象三篇文章的第一句話都在拆穿同一個直覺：你以為的瓶頸不是真正的瓶頸，繼續往錯誤方向使力只會放大浪費。 * **KV Caching**：token 從 2023 到 2026 跌了 80%（GPT-4 等級從 $30/M 跌到 $0.40/M），但 agent 總帳單不降反升——Stanford 研究顯示每次呼叫約 62% 是重複內容（system prompt、tool 定義、文件），這些 KV cache 被每次從零重算。作者點名產業在「優化錯誤的變數」：讓 token 更便宜沒有用，如果這些 token 根本不該存在。 * **私有知識庫**：demo 問「報銷標準」答得出，日常問「新人出差住酒店報多少」就答非所問——根因不是模型不夠強，而是用詞對不上、跨來源綜合、多跳線索、權限洩漏這四類檢索鏈路問題。換更強的模型「只讓錯誤答案寫得更順」，根因沒被解決。 * **Qwen3-235B**：235B frontier MoE 在 16 GB Mac mini 上峰值 ~14.8 GB 仍能跑——fit 與總參數數解耦。真正的瓶頸不是 RAM 容量，而是磁碟頻寬（外接 SSD ~0.6 tok/s）；「這模型塞得進去嗎？」是錯的問題，「我的磁碟多快、要哪個 build？」才是對的。 ### 2. 關注分離：I/O 重與 compute 重必須拆開，這是可遷移的架構鐵律把本質不同的工作負載塞進同一個 process（或同一條 pipeline），是三篇文章共同指認的結構性缺陷；解法都是把資料路徑與控制路徑、或 I/O 與 compute 拆離。 * **KV Caching**：LMCache 採 disaggregated 架構，cache 管理（I/O 重，在 GPU/CPU/storage 間搬大 tensors）跑在獨立 process，inference engine（compute 重，GPU 矩陣乘法）只送極小訊息索取 block IDs，真正的 tensor 搬移全在 LMCache 側完成。Google TurboQuant 把 KV cache 量化到每值 3 bit、零精度損失，但跑在 inference engine 內時造成 20%+ 減速——「壓縮完美，但與推理同 process 抵消效益」是整篇最可遷移的洞見。 * **Qwen3-235B**：串流器把小骨架（attention + embeddings + router + norms，resident ~0.33 GB）常駐 RAM，128 枚 experts 全留磁碟按需 `pread`；用 `F_NOCACHE` 開 fd 避免 OS page cache 把 RSS 撐爆。每個 expert 是沿 expert axis 連續堆疊的 tensor，所以是一次 `pread(fd, offset, length)` 的連續 byte range——這個 byte-slice primitive 跨 `qwen3_5_moe`、`deepseek_v2/v3`、`qwen3_moe` 三個 MoE family **零改動**，per-model 成本僅一行 rotation-config。 * **私有知識庫**：8 層架構每一層職責單一（解析只管結構、切分只管顆粒、檢索只管相關性），這是系統可演進的基礎。權限過濾是最鮮明的關注分離決策——必須在檢索階段用 metadata filter 完成，而非「先檢索全庫再讓模型不要回答」，後者把安全責任交給不可靠的模型指令遵守。 ### 3. 記憶體階層下推：熱冷資料分層，按需拉取取代全量駐留三篇都在實作「把熱資料放快層、冷資料按需從慢層拉」的記憶體階層設計——這是 OS demand paging、DB buffer pool manager、串流媒體 chunked delivery 的同一套直覺，現在被打進 LLM 基礎設施。 * **KV Caching**：LMCache 支援 GPU memory、CPU RAM、local SSD、cloud storage 四層「並行」查詢（傳統做法逐一檢查、卡在最慢層），從任何命中處並行串流資料；跨 GPU zero-copy 共享讓兩個 GPU 直接讀寫同一塊記憶體區域。一張 GPU 每天產生約 15 TB KV cache，其中多數被丟棄——管理這些資料的基礎設施正在此時被打造。 * **Qwen3-235B**：per-expert byte-slice + byte-budgeted LRU cache，熱專家駐留、冷專家按需從 SSD 拉，等同 buffer pool manager。backbone 常駐 + experts 落盤的分工，讓峰值記憶體由 Metal wired cap 與 backbone 治理，與參數數或磁碟尺寸無關——跨 35B→235B 共 7× 模型尺寸 span，峰值穩在 9–15 GB 狹窄區間。 * **私有知識庫**：chunk 是知識庫的基本顆粒（推薦 500–1000 中文字 + 80–150 重疊），父子切分讓小 chunk 用於檢索、大段落用於生成；`documents` 表存 `raw_hash` 做增量更新判斷，hash 沒變跳過、變化才重新解析切分 embedding，把「全量重建」降級為「按需重算」。 ### 4. 稀疏性與局部性是可榨取的結構性紅利三篇都沒有發明新演算法，而是利用模型或資料本身的稀疏結構，把「全量重算」降級為「只算必要的少數」——這是效能紅利的真正來源。 * **KV Caching**：CacheBlend（EuroSys 2025 Best Paper）的關鍵發現是「現代 transformer 多數 token 主要 attend 自己的局部脈絡，只有少數 token 在跨文件邊界上有強連結」。獨立快取的兩份文件「互不知道對方」，但只需識別那少數跨文件邊界 token 選擇性重算，其餘全部原樣重用，就能縫合獨立 cache——多文件查詢 2–4x faster、品質不損，把 RAG 裡每份文件都變成可重用資產。 * **Qwen3-235B**：MoE 每 token 只路由 top-8 experts（其餘 120 枚閒置），94 層全 MoE 代表每 token 752 expert slices；但 routing locality 是真實的，熱專家會被 LRU cache 重複命中。K-reduction 旋鈕（`--max-active-experts 4`，top-4 而非 top-8）把 bytes/token 砍半，近乎倍速（0.31→0.60 tok/s）；K=2 是連貫性懸崖（壓到 <4B active 產出 word salad），K=4（~11B active）是可用品質底線。 * **私有知識庫**：Agentic RAG 的工具路由、查詢改寫、證據充足性判斷、多跳檢索，本質都是「不查全庫，只查最相關來源」——Agent 根據問題選擇 `search_policy_docs` 或 `search_meeting_notes` 等工具，而非把所有庫都查一遍；多跳檢索是「查 A → 根據 A 決定查 B」的稀疏展開。 ### 5. 可觀測與可驗證是上生產的硬門檻——指標先行、回歸測試、等價驗證三篇都不把「跑起來」當終點，而是把「可度量、可追溯、可回滾」視為生產化的真正門檻；缺乏觀測的優化等於靠感覺調參。 * **KV Caching**：行動建議是「先量重複 token 占比與 cache hit rate 兩個指標」，重複高但 hit rate 低（典型 RAG 多文件場景）就是 LMCache + CacheBlend 的高槓桿切入點。LMCache 附 Prometheus/OpenTelemetry 追蹤 cache hit rate 與 I/O、Kubernetes operator 部署、CLI 除錯；雙向容錯降級（engine 掛了 cache 保留在 CPU/storage 免冷啟動、LMCache 掛了 engine 降級停用快取照常推理）確保任一故障不拖垮系統。 * **私有知識庫**：評估集是「RAG 系統的測試套件」——準備 50–200 題真實問題，分檢索層（正確文件是否進 top-k，對應單元測試）與生成層（答案是否正確、有無引用、是否胡編，對應整合測試），每次換模型／切分／檢索參數都跑回歸驗證。上線前要產出「不可靠地圖」（系統在哪些問題上不可靠），比平均分數更重要——它標出系統邊界。 * **Qwen3-235B**：串流輸出與全駐留模型 bit-identical（greedy decode 產出完全相同 token stream，per-step max-abs-diff = 0）是嚴格的等價驗證；每次 run 回報 resident RSS、decode tok/s、expert hit-rate、總磁碟讀取。作者對 recall 結果誠實標註「單次 greedy run，非保證」，並警告「錯一個數字就是錯答案」的場景（長文件 QA、程式碼、精確 literal 查找）要先在自己的資料上驗證。 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **動手優化前先量瓶頸，分辨「容量」還是「頻寬」／「檢索」還是「生成」**：自架 agent／RAG 先量「重複 token 占比」與「cache hit rate」，重複高但 hit rate 低就是 LMCache + CacheBlend 的切入點；RAG 系統先人工看 top-k 有沒有正確資料（檢索不對，生成再強也救不回），這比換模型或調 prompt 優先級更高；端側推論先分辨瓶頸是「記憶體容量」還是「磁碟頻寬」，因為二者最佳化路徑完全不同（加 RAM 對頻寬牆無效，換更快 SSD 才是直接線性提速）。 2. **用關注分離重審現有架構，找出「塞在同一 process」的工作負載**：檢查 cache 管理是否與 inference 同 process（若是，預期 20%+ 爭用損耗）；檢查權限過濾是否在資料進模型前完成（先檢索後過濾 vs 先過濾後檢索是資料洩漏的關鍵）；檢查熱冷資料是否分層（backbone 常駐、experts 落盤；system prompt 的 KV cache 應被重用而非每次重算）。8 層 RAG 架構每一層職責單一是可演進的基礎，不要把解析、切分、檢索、生成混在一起。 3. **把評估集與觀測當成上線前的硬門檻，而非事後補丁**：為 RAG 建立 50–200 題評估集分檢索／生成兩層，每次改動跑回歸測試並產出「不可靠地圖」；為推論服務接 Prometheus/OpenTelemetry 追蹤 hit rate 與 I/O，設計雙向容錯降級；量化模型用 bit-identical（per-step max-abs-diff = 0）驗證串流與駐留等價，並在「錯一個數字就是錯答案」的場景於自有資料上實測 recall 邊界。 4. **消費級硬體跑 frontier 模型的路徑已打通，重新計算自架推論的硬體投資**：1.58-bit ternary quantization（53 GB）+ per-expert 磁碟串流讓 Qwen3-235B 塞進 16 GB Mac mini、在 64 GB Mac 完全駐留跑 ~5.6 tok/s（一次性 `sysctl iogpu.wired_limit_mb=60416`）。先評估「瓶頸是容量還是頻寬」再決定投資 RAM 或 SSD——K-reduction（top-4 experts）是近乎免費的 1.94× 倍速旋鈕，更快 SSD（內接 NVMe vs 外接）是 ROI 最高的單一改動；但注意 spec-decode 在 TurboQuant 模型上反效果（per-token Hadamard rotation 無法攤銷，串流慢 6×）。

Obsidian 開啟

AI模型領域

AI模型總結報告

2026 年的前沿模型 post-training pipeline 中，distillation 已從可選的壓縮技術升格為標準組件，且底層統一為同一套 teacher-student 機制的三種變體：off-policy 壓縮（Gemma 3/4、DeepSeek-R1-Distill）、on-policy 合併 RL 專家（DeepSeek-V4、MiMo-V2-Flash、GLM-5、Nemotron 3 Ultra）、self-distillation（Cursor Composer 2.5、Thinking Machines）。最深刻的範式轉移是「teacher 不需更大，只需更專精」——主流 on-policy 路線的 teacher 多為同一 base 的 checkpoint，靠單領域 RL 推到極致獲得教學能力，顛覆了傳統「大教小」的規模假設。根本邏輯在於 per-token dense signal 的 sample efficiency 遠高於 trajectory-level sparse reward：Qwen3 實測蒸餾僅需 RL 約 1/10 的 GPU 小時即超越 RL baseline，是蒸餾相對 RL 最有力的性價比論證。而 reverse KL 的 mode-seeking 特性使多 teacher 合併在數學上可行；self-distillation 進一步解構了對外部 teacher 的依賴，把「更好的自己」當老師，同時解決推論效率與 continual learning 兩個實務痛點。全部變體已可在 TRL 的 GKD Trainer 開源重現，實作門檻大幅降低。

核心主題 (Key Themes)

On-policy Multi-Teacher Distillation（MOPD）成為合併 RL 專家的主流收斂方向：單一模型用 RL 擅長所有領域會遭遇 catastrophic interference——一個訓練階段獲得的技能在下一階段退化。2026 年主流實驗室收斂到的解法是為每個領域訓練獨立 RL expert，再以 on-policy distillation 合併進單一 student。與 off-p...
Reverse KL 的 mode-seeking 特性是 multi-teacher 合併可行的數學基礎：DeepSeek-V4 在 multi-teacher 場景選擇 reverse KL loss 而非 forward KL，是 2026 年 on-policy 蒸餾的關鍵架構決策。KL 散度的方向決定了 student 如何逼近 teacher 分佈，直接影響多 teacher 合併時是否會產生...
Self-distillation 以 privileged teacher 解構「外部 teacher」依賴，開闢推論效率與 continual learning 新方向：第三種用途完全拋棄外部 teacher，讓模型向「更好的自己」學。核心洞察是 teacher 不需要更大，只需要在 context 中更好——有時候那個更好的版本就是模型自己。這條路線同時回應了兩個實務痛點推論時不想帶冗長 prompt、以及 fine-tune 後不想忘舊能力。

# 領域總結：AI模型 (2026-07-09) ## 總結概述 2026 年的前沿模型 post-training pipeline 中，distillation 已從可選的壓縮技術升格為標準組件，且底層統一為同一套 teacher-student 機制的三種變體：off-policy 壓縮（Gemma 3/4、DeepSeek-R1-Distill）、on-policy 合併 RL 專家（DeepSeek-V4、MiMo-V2-Flash、GLM-5、Nemotron 3 Ultra）、self-distillation（Cursor Composer 2.5、Thinking Machines）。最深刻的範式轉移是「teacher 不需更大，只需更專精」——主流 on-policy 路線的 teacher 多為同一 base 的 checkpoint，靠單領域 RL 推到極致獲得教學能力，顛覆了傳統「大教小」的規模假設。根本邏輯在於 per-token dense signal 的 sample efficiency 遠高於 trajectory-level sparse reward：Qwen3 實測蒸餾僅需 RL 約 1/10 的 GPU 小時即超越 RL baseline，是蒸餾相對 RL 最有力的性價比論證。而 reverse KL 的 mode-seeking 特性使多 teacher 合併在數學上可行；self-distillation 進一步解構了對外部 teacher 的依賴，把「更好的自己」當老師，同時解決推論效率與 continual learning 兩個實務痛點。全部變體已可在 TRL 的 GKD Trainer 開源重現，實作門檻大幅降低。 ## 核心洞察與共同趨勢 ### 1. On-policy Multi-Teacher Distillation（MOPD）成為合併 RL 專家的主流收斂方向單一模型用 RL 擅長所有領域會遭遇 catastrophic interference——一個訓練階段獲得的技能在下一階段退化。2026 年主流實驗室收斂到的解法是：為每個領域訓練獨立 RL expert，再以 on-policy distillation 合併進單一 student。與 off-policy 的關鍵差異在於 student 邊生成 rollout 邊被打分——teachers 對 student 當前實際會生成的內容逐 token 給 dense 回饋，gradient 直接作用在 student 的行為空間上，避開 off-policy 的 covariate shift。這正是蒸餾能用 1/10 計算超越 RL 的根本原因。 * **DeepSeek-V4**：最清晰的 pipeline 描述——每領域先 SFT 再各自 GRPO 形成 domain expert，之後透過 on-policy distillation 訓練單一統一模型，student 對 specialist teachers 優化 reverse KL loss * **MiMo-V2-Flash**：正式將此機制命名為 MOPD（Multi-Teacher On-Policy Distillation），domain teachers 對 student 生成的內容提供 dense、token-level signal，後續有獨立論文研究 * **Nemotron 3 Ultra（NVIDIA 旗艦）**：規模化驗證，採用超過 10 個專業 teacher，各有獨立 domain pipeline，對 student 自己的 rollout 提供密集 token-level guidance * **Qwen3**：量化性價比——student 生成並將 logits 對齊到大 teacher，蒸餾 GPU 小時約為 RL 的 1/10，結果更好 * **GLM-5**：跨訓練階段（非跨領域）的變體，teacher 是同一血脈的早期 checkpoint，在 sequential RL phases 後做 final distillation pass 修復沿途退化的能力，距「模型教自己」只差一步核心範式轉移：teacher 不需更大，只需更專精。這些 teacher 多為同一 base 的 checkpoint，與 student 同等大小，靠 specialization（單領域 RL 推到極致）而非 scale 獲得教學能力。 ### 2. Reverse KL 的 mode-seeking 特性是 multi-teacher 合併可行的數學基礎 DeepSeek-V4 在 multi-teacher 場景選擇 reverse KL loss 而非 forward KL，是 2026 年 on-policy 蒸餾的關鍵架構決策。KL 散度的方向決定了 student 如何逼近 teacher 分佈，直接影響多 teacher 合併時是否會產生行為衝突。 * **Reverse KL（mode-seeking）**：student 傾向在 teacher 高機率的地方也保持高機率，但允許 student 在 teacher 低機率的地方自由探索。這讓 student 不必被迫覆蓋每一個 teacher 的所有行為 mode——多 teacher 各自專精不同領域時，student 可選擇性繼承各 teacher 的強項而非全盤模仿 * **對比 forward KL（mode-covering）**：forward KL 會強迫 student 覆蓋 teacher 分佈的所有 mode（mean-seeking），在 multi-teacher 場景下會造成不同 teacher 的行為要求互相衝突，student 被迫平均化 * **隱形假設的留白**：作者指出各家用法不同但未深入解釋為何如此選擇；reverse KL 與 forward KL 在 multi-teacher 場景的實務取捨、以及 teacher 數量從 3 個增加到 10+ 的邊際收益曲線，仍是 tech report 未交代清楚的盲點 ### 3. Self-distillation 以 privileged teacher 解構「外部 teacher」依賴，開闢推論效率與 continual learning 新方向第三種用途完全拋棄外部 teacher，讓模型向「更好的自己」學。核心洞察是 teacher 不需要更大，只需要在 context 中更好——有時候那個更好的版本就是模型自己。這條路線同時回應了兩個實務痛點：推論時不想帶冗長 prompt、以及 fine-tune 後不想忘舊能力。 * **Cursor Composer 2.5（privileged teacher）**：訓練時在 context 注入描述目標行為的 hint，有 hint 的模型版本成為 teacher，per-token KL 將 unhinted policy 拉向 hint-conditioned policy，最終推論時移除 hint 但行為已內化。課堂稱此為 privileged teacher。架構意義在於這是一種「行為蒸餾」——hint 作為 privileged information 啟動目標行為，與部署場景的 system prompt 移除問題高度相關（省 token、降延遲） * **Thinking Machines（continual learning 的自我蒸餾）**：使用與 on-policy 相同的 recipe，但 teacher 換成自己——fine-tune 新領域資料後，從 pre-fine-tune checkpoint 蒸餾，恢復被 fine-tune 抹去的行為同時保留新知識。根本觀念是 catastrophic forgetting 不是要避免的 bug，而是要管理的 trade-off，蒸餾是在新舊能力間找平衡點而非二選一 * **與 GLM-5 的呼應**：Thinking Machines 的 continual learning 與 GLM-5 跨 RL 階段的修復機制解決的是同一問題，只是 scale 不同——GLM-5 在實驗室規模，Thinking Machines 在個人/單一模型規模 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **把 on-policy multi-teacher distillation 納入 post-training pipeline 評估**：相較於讓單一模型用 RL 擅長所有領域，改為每領域訓獨立 RL expert（SFT→GRPO per domain）再 on-policy 合併，可避開 catastrophic interference。入門直接從 TRL 的 GKD Trainer 開源實作切入，並以 Thinking Machines 的 on-policy distillation write-up（附實務數據）作為理論到實作的橋樑。 2. **multi-teacher 合併優先評估 reverse KL**：reverse KL 的 mode-seeking 特性讓 student 可選擇性繼承各 teacher 強項，避免 forward KL 的 mode-covering 在多 teacher 下造成行為平均化。但需建立 teacher 數量邊際收益的觀測——從 3 個到 10+ teacher 的收益曲線目前 tech report 闕如，應在自家資料上實測 plateau。 3. **以 self-distillation 處理推論效率與 continual learning 兩個痛點**：部署場景若需移除冗長 system prompt，採 Cursor 式 hint-conditioned privileged teacher，訓練時用 hint 誘發行為、推論時移除 hint 但行為已內化；持續 fine-tune 新領域時，從 pre-fine-tune checkpoint 蒸餾以管理 catastrophic forgetting，把遺忘當 trade-off 來管理而非視為 bug。

Obsidian 開啟

AI視野領域

AI視野總結報告

Zack Shapiro《The Two Clocks》以美國法律產業為顯微鏡，診斷 AI 落地的真正瓶頸：不是模型太弱，而是機構還沒學會「吸收（absorption）」。作者提出貫穿全文的「兩座時鐘」隱喻——快時鐘（模型/agent 能力）每幾週跳一格，慢時鐘（委員會、政策、報酬週期、工作流程）如組織慣性般移動，兩者距離就是「當前商業最重要的事實」。這個落差解釋了為何 AmLaw 50 事務所把人類建過最強的科技用來清時間條目、排會議，而全球營收最高的 Kirkland & Ellis 寧花 $500M 自建平台也不租 Harvey、Legora 等通用工具。吸收已成為稀缺工作，forward-deployed engineer 從 Palantir 二十年前獨有的怪癖，變成 OpenAI（資本 $4B+）、Anthropic（合資約 $1.5B）重金搶建的軍備。作者最鋒利的洞見在於指出價值移轉的終局：AI 先攻擊「生產」端使其商品化，真正稀缺的「判斷」浮現溢價——而判斷正是帳單一個世紀來從不條列的那一項。MIT 2025 年研究顯示 95% 組織在 generative AI 上看不到可衡量回報，正是「能力不等於吸收」的硬證據。

核心主題 (Key Themes)

瓶頸從「智能」移到「吸收」：forward-deployed engineer 成為軍備核心，且應為機構而非 vendor 工作：作者的核心命題是 AI 瓶頸已從算力/智能移轉到「把能力從快時鐘搬到慢時鐘、又不壓垮機構」的稀缺工作。這份工作今天通常是一個人——懂舊工作法足以用老方法做、懂工具足以用新方法重建、且坐在重建現場的人。Palantir 二十年前發明的 forward-deployed engineer 職稱，今年春天...
通用技術的延遲兌現與「採購≠吸收」：歷史類比＋Kirkland $500M 的正反面教科書：作者用兩個歷史類比證明「通用技術（GPT）只有在工作被重新設計後才兌現，而重設往往落後發明一整個世代」，再用 Kirkland & Ellis 的 $500M 賭注做當代正反印證——採購強大技術不等於吸收，不改工作流程就是把貴馬達塞進舊傳動軸。這個洞察串連了總體經濟學的 GPT 文獻（Paul Da...
價值移轉：生產商品化→判斷成稀缺→判斷溢價；prompt→workflow→機構能力的三層躍遷：作者的最終論證是經濟學層級的價值移轉AI 先攻擊生產端（起草、盡調、引註查核、比對），使過去用來計費的時間失去稀罕性；稀缺的是指揮機器、測試答案、做困難推薦的判斷。作者提出「發票的虛構（invoice fiction）」——客戶一個世紀以來真正想買的是判斷，但帳單只列生產時間。而把判斷從個人技巧變成...

# 領域總結：AI視野 (2026-07-09) ## 總結概述 Zack Shapiro《The Two Clocks》以美國法律產業為顯微鏡，診斷 AI 落地的真正瓶頸：不是模型太弱，而是機構還沒學會「吸收（absorption）」。作者提出貫穿全文的「兩座時鐘」隱喻——快時鐘（模型/agent 能力）每幾週跳一格，慢時鐘（委員會、政策、報酬週期、工作流程）如組織慣性般移動，兩者距離就是「當前商業最重要的事實」。這個落差解釋了為何 AmLaw 50 事務所把人類建過最強的科技用來清時間條目、排會議，而全球營收最高的 Kirkland & Ellis 寧花 $500M 自建平台也不租 Harvey、Legora 等通用工具。吸收已成為稀缺工作，forward-deployed engineer 從 Palantir 二十年前獨有的怪癖，變成 OpenAI（資本 $4B+）、Anthropic（合資約 $1.5B）重金搶建的軍備。作者最鋒利的洞見在於指出價值移轉的終局：AI 先攻擊「生產」端使其商品化，真正稀缺的「判斷」浮現溢價——而判斷正是帳單一個世紀來從不條列的那一項。MIT 2025 年研究顯示 95% 組織在 generative AI 上看不到可衡量回報，正是「能力不等於吸收」的硬證據。 ## 核心洞察與共同趨勢 ### 1. 瓶頸從「智能」移到「吸收」：forward-deployed engineer 成為軍備核心，且應為機構而非 vendor 工作作者的核心命題是 AI 瓶頸已從算力/智能移轉到「把能力從快時鐘搬到慢時鐘、又不壓垮機構」的稀缺工作。這份工作今天通常是一個人——懂舊工作法足以用老方法做、懂工具足以用新方法重建、且坐在重建現場的人。Palantir 二十年前發明的 forward-deployed engineer 職稱，今年春天成為所有有錢人都在抄的位置，但作者提出關鍵的產權歸屬問題：這個人為誰工作，決定了吸收能力最終落在誰的資產負債表上。 * **forward-deployed engineer 軍備**：OpenAI 於 2026 年 5 月 11 日成立 Deployment Company，資本超過 $40 億（TPG 領投），並收購 Tomoro 帶進約 150 名 forward-deployed engineer；Anthropic 與 Blackstone、Goldman Sachs、Hellman & Friedman 於 5 月 4 日合資成立 AI-native 企業服務公司，資本約 $1.5B。賣智能的 vendor 已認定：沒有吸收的能力什麼也不生產。 * **「為誰工作」的產權判斷**：一般企業租 vendor 平台跑物流是划算的，因為物流從來不是優勢、widget 才是。但律師事務所「沒有 widget」，工作跑在客戶信託上，程序編碼了事務所自家方法論。讓 vendor 工程師把方法寫在 vendor rails 上，它就傾向往 vendor 產品遷移，隔壁事務所就能訂閱。Palantir 執行長 Alex Karp 在 CNBC 專訪呼籲企業「擁有 AI 背後的生產手段」而非租用——他在賣東西，但他也是對的。 * **MIT 2025 研究的硬證據**：95% 組織在 generative AI 上看不到可衡量回報，這不是模型不夠強，而是吸收缺口。change management 從產出 stakeholder map 的舊樣貌，昇華成「把專家判斷轉成機器可執行、機構可信任的自動化程序」的新工作。 ### 2. 通用技術的延遲兌現與「採購≠吸收」：歷史類比＋Kirkland $500M 的正反面教科書作者用兩個歷史類比證明「通用技術（GPT）只有在工作被重新設計後才兌現，而重設往往落後發明一整個世代」，再用 Kirkland & Ellis 的 $500M 賭注做當代正反印證——採購強大技術不等於吸收，不改工作流程就是把貴馬達塞進舊傳動軸。這個洞察串連了總體經濟學的 GPT 文獻（Paul David 電腦生產力悖論）、Christensen 的 Innovator's Dilemma，以及製造業的 process redesign。 * **電氣化傳動軸類比**：工廠主人把蒸汽引擎換成馬達，卻保留同一根中央傳動軸，將近三十年才拆地板重做生產線（unit-drive，每台機器裝一顆小馬達、讓生產線跟著任務走）。AI 現在就在這個階段——新馬達鎖在舊傳動軸上，地板還是為蒸汽鋪的。 * **Coca-Cola vs GE 的價值捕獲移位**：機械冷凍普及時，最大贏家不是造冰箱的 GE/Westinghouse/Frigidaire，而是把冰可樂佈到全球手臂可及處的 Coca-Cola（Robert Woodruff 1920 年代立志「放在欲望的手臂可及之內」）。前沿實驗室是此刻的 GE，Coca-Cola 財富屬於先想清楚「冷能做什麼」的人。 * **Kirkland $500M 的正反兩面**：正面——全球營收最高律所（2025 年 $10.56B、年增 20%，每位 equity partner 利潤 $11.1M、595 位 equity partner）認定租通用工具無法保護護城河，首發 PE 客戶的 fund formation engine。反面警示——專屬平台的價值恰好等於它接上的那個改變後的執業，若保留工作流程不變，$500M 只是貴馬達塞舊軸。 * **PE 兩面夾擊的壓力源**：Blackstone 付給 Kirkland 的律師費從 2024 年 $101.3M 降至 2025 年 $87.8M；同時 Blackstone/Bain Capital/Vanguard 母公司 Norm Ai 資助 Norm Law（$50M 投資，挖走 Sidley Austin 執委會前主席 Michael Schmidtberger）。同類挑戰者：Crosby（Sequoia/Index/Lux 投 $85M+）、Eudia（Series A $105M）。打造 Kirkland 為史上最賺錢律所的產業，正在資助它的挑戰者。 * **Sullivan & Cromwell 假引註事件的 process 啟示**：2026 年 4 月 S&C 在破產案緊急動狀帶出數十處 AI 幻覺引註錯誤，Andrew Dietderich 4 月 18 日致函首席法官 Martin Glenn 道歉。S&C 並非草率事務所——重點是名望不能防止這種失敗，只有 process 能。 ### 3. 價值移轉：生產商品化→判斷成稀缺→判斷溢價；prompt→workflow→機構能力的三層躍遷作者的最終論證是經濟學層級的價值移轉：AI 先攻擊生產端（起草、盡調、引註查核、比對），使過去用來計費的時間失去稀罕性；稀缺的是指揮機器、測試答案、做困難推薦的判斷。作者提出「發票的虛構（invoice fiction）」——客戶一個世紀以來真正想買的是判斷，但帳單只列生產時間。而把判斷從個人技巧變成機構資產的方法論，是 prompt → workflow → 機構能力的三層躍遷。 * **軟體業已兌現快時鐘的證據**：截至 2026 年 5 月，Anthropic 生產程式碼庫 80%+ 由 Claude 撰寫（2025 年 2 月 Claude Code 上線前僅個位數%）；2026 年 3 月約 130 名研究員內部調查，中位產出約為無 AI 時的 4 倍。Clive Thompson 於《紐約時報雜誌》訪談 Google/Amazon/Microsoft/Apple 等 70+ 工程師，同一形狀：資深者寫更少、指揮更多——「工作單位從生產移向指揮（orchestration）」。 * **prompt anatomy 的零技術方法論**：task（要做什麼，不是 summarize 而是具體任務）／background（客戶、態勢、商業目標、對造動態）／judgment（哪些條款通常重要、哪些看似法律其實商業、不該主張的論點）／constraints（律師願背書的信心水準、客戶真正會讀的格式）／deliverable（排序過的條款清單＋擬議反制語言，而非泛泛 summary）／verification（答案回來前必須跑的查核，如引註獨立驗證）。全白話、零技術——像資深律師交辦給好 associate 的完整 brief，學最快的人往往是最會交辦的人而非最年輕的人。 * **workflow＝合夥人給新 associate 的常設 playbook**：prompt 告訴模型「這個」案件做什麼，workflow 告訴模型某律師如何做「這一類」工作。實務上是一份 plain-English playbook，模型每個案件、每次都遵循，不需被提醒。更有價值的是實質性部分：某律師怎麼審合約（termination→liability caps→indemnification→discretion standards→IP ownership→survival 的審查序列）、哪些條款必查、何時要更多事實、何時反駁前提、何時因經驗教過她這裡是出錯點而放慢。lessons-learned 檔不是知識管理的樣板戲，是複利機制——模型漏了什麼、律師更正、那個更正成為下一次跑的一部分。 * **「發票的虛構」與判斷溢價**：更可能的算術是「每個法律工作的一半被取代」而非「一半的法律工作整個被取代」——機器拿走生產那一半，人們上法學院的那個部分留下來。判斷一直是客戶真正想買的，卻是帳單從不條列的那一項。成熟回應是保護那個資產並終於為它定價，同時讓機器商品化包裝部分。招募隨之轉向：從「法學院成績＋撐過 brutal hours」移向「判斷力早期跡象、agency、商業嗅覺、人際技能」（法官助理、財星 500 非法律職務成為新來源）。 * **隱形假設的邊界**：作者假設判斷力是 AI 難以商品化的稀缺資源，但未深入論證判斷本身能否被下一波 reasoning/long-horizon agentic 模型部分自動化；Dario Amodei「五年內消滅一半入門白領工作」的預言與 Jevons paradox 反論被點到卻未真正交鋒。當 model 突破到能可靠地自己做判斷時，「判斷溢價」前提動搖——這是本洞察最需要持續驗證的未知項。 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **把 AI 支出從「買馬達」重新分類為「拆地板」**：對企業決策者，逐一盤點 AI 預算背後是否有任何工作流程被重寫。若沒有 workflow 被改變、只有任務小組/政策/vendor 訓練，那就是「AI 劇場」。判斷標準只有一個問題：哪個工作流程變了？快了多少？對客戶改善了什麼？現在在活生生的案子上做了什麼不同的事？模糊永遠是破綻。 2. **用 prompt anatomy 立刻自我診斷**：拿自己最近一次「summarize this / review this」的空泛指令，用 task-background-judgment-constraints-deliverable-verification 六層重寫一次，比較輸出。這個 anatomy 零技術、可立刻遷移到任何領域（不只法律），本質是把模型當成「讀過一切但對你客戶一無所知的聰明新 associate」然後據此 brief 它。 3. **把個人 prompt 昇華為機構 workflow，並確認產權歸屬**：核心方法論是 prompt（單一案件）→ workflow（一類工作的 plain-English playbook）→ 機構能力（複利資產）。對沒有 widget、核心是客戶信託＋自家方法論的專業服務業，workflow 必須住在機構自有的基礎設施上，而非 vendor 產品裡——否則等於把方法論遷移進對手可訂閱的 platform。同時建立 lessons-learned 機制，讓每次模型出錯與律師更正成為下一次自動跑的一部分。 4. **趁營收創高時重建，並把招募轉向判斷力**：機構依兩種時程改變——刻意地或在緊急狀況中，而緊急狀況的一切都讓重建更糟（人才在走、客戶在重新談判）。現在開始的機構能在營收仍創紀錄時重寫工作流程，拉開以年計的複利領先。同時把招募 JD 從「成績＋抗壓」改寫為「判斷力、agency、商業嗅覺」，因為 grind 被壓縮後，學徒制無法自行運轉，必須刻意圍繞決策來設計訓練。

Obsidian 開啟

Agent架構領域

Agent架構總結報告

今天 8 篇 Agent 架構文章共同傳遞一個明確訊號：**工程焦點已系統性地從「模型能力」轉向「圍繞模型的迴圈、記憶、治理與自我改進機制」**。無論是 Addy Osmani 的 `Agent = model + harness`、Taxonomy 的三要素拆解、還是 `AI = LLM × Harness` 的乘法公式，所有框架都不約而同把 LLM 降格為「引擎」，把 harness（tools/memory/guardrails/loop/skills）升為「真正可工程化的車」。在這個共識之上，文章沿三條軸線展開：其一是自我改進層級的上移——從優化產物（artifact）進化到優化「產生產物的機制」（mechanism），Bilevel Autoresearch 用 outer loop 在 runtime 注入 Python 搜尋機制、達到 5× 改善，證明機制層自我改進的報酬遠高於參數調整。其二是記憶系統的反直覺設計——選擇性、結構化與讀取時機比儲存量更關鍵，Taste Index 的「No signal, no storage」與 Ontology 的「提取 schema vs 語意基礎設施」漏斗，共同對抗「記得越多、理解越少」的退化。其三是人類當責邊界的重畫——當 agent 跑整個 inner execution loop，人類價值移向 outer loop 的判決、審計與後果承擔，而認知頻寬成為 factory scale 的硬上限。三條軸線匯流於一個結論：Agent 時代的瓶頸不再是模型有多聰明，而是迴圈如何閉合、證據如何跨越邊界、以及誰能在自動化盡頭簽名承擔。

核心主題 (Key Themes)

Harness 取代模型，成為 Agent 工程的真正介面：8 篇文章中有 5 篇直接確立「模型只是引擎、harness 才是車」的等式，差別僅在各自延伸的方向。這不是修辭，而是可工程化介面的位移——你調不了引擎，但你能設計整台車。
自我改進的戰場從 artifact 層上移到 mechanism 層：三篇文章從不同角度證明優化「產生產物的機制」報酬遠高於優化產物本身，且機制載體不限於程式碼。
記憶系統的反直覺共識：選擇性、結構化、讀取時機勝過儲存量：四篇文章從不同尺度（個人、企業、產品、單一 agent）得出同一結論記憶的價值不在「存更多」，而在「存對的、存結構化、在對的時間讀」。
人類當責邊界重畫：Own the outer loop，back pressure 取代最大自主性：當 agent 跑整個 inner execution loop，多篇文章共同指出人類價值移向判決、審計與後果承擔，且認知頻寬是 factory scale 無法平行化的硬上限。
驗證訊號與迴圈閉合處決定系統最終價值：多篇文章共同指向一個常被忽略的前提自演化與可信賴性的上限，由驗證訊號的可靠性與迴圈閉合的位置決定。

# 領域總結：Agent架構 (2026-07-09) ## 總結概述今天 8 篇 Agent 架構文章共同傳遞一個明確訊號：**工程焦點已系統性地從「模型能力」轉向「圍繞模型的迴圈、記憶、治理與自我改進機制」**。無論是 Addy Osmani 的 `Agent = model + harness`、Taxonomy 的三要素拆解、還是 `AI = LLM × Harness` 的乘法公式，所有框架都不約而同把 LLM 降格為「引擎」，把 harness（tools/memory/guardrails/loop/skills）升為「真正可工程化的車」。在這個共識之上，文章沿三條軸線展開：其一是自我改進層級的上移——從優化產物（artifact）進化到優化「產生產物的機制」（mechanism），Bilevel Autoresearch 用 outer loop 在 runtime 注入 Python 搜尋機制、達到 5× 改善，證明機制層自我改進的報酬遠高於參數調整。其二是記憶系統的反直覺設計——選擇性、結構化與讀取時機比儲存量更關鍵，Taste Index 的「No signal, no storage」與 Ontology 的「提取 schema vs 語意基礎設施」漏斗，共同對抗「記得越多、理解越少」的退化。其三是人類當責邊界的重畫——當 agent 跑整個 inner execution loop，人類價值移向 outer loop 的判決、審計與後果承擔，而認知頻寬成為 factory scale 的硬上限。三條軸線匯流於一個結論：Agent 時代的瓶頸不再是模型有多聰明，而是迴圈如何閉合、證據如何跨越邊界、以及誰能在自動化盡頭簽名承擔。 ## 核心洞察與共同趨勢 ### 1. Harness 取代模型，成為 Agent 工程的真正介面 8 篇文章中有 5 篇直接確立「模型只是引擎、harness 才是車」的等式，差別僅在各自延伸的方向。這不是修辭，而是可工程化介面的位移——你調不了引擎，但你能設計整台車。 * **AI = LLM + Harness（PolicyPulse 案例）**：作者把等式寫成乘法 `Agent = LLM × Harness`，強調 harness 為零則整個 agent 退化為聊天機器人；MongoDB 直言「LLM 可能是生產級 agent 系統裡最小的部分」，Anthropic 的〈Building Effective Agents〉持相同觀點，且團隊改善 agent 行為靠的是重新設計 harness 而非置換模型 * **Own the Outer Loop（Addy Osmani）**：把 harness 具體拆成 files、tools、memory、skills、sandboxes、permissions、observability、recovery 八類組件，並定義三層抽象（Agent → Loop → Factory），其中 Loop 的結束條件「不由模型自己說了算，而由獨立檢查決定」是 loop 可被信任的來源 * **Taxonomy of Self-evolving Agents**：以 `Agent = Model + Harness`、`Agent → Artifact` 作為全部分類的地基，任何自演化系統都可被問「你改的是 model、harness、還是 artifact？」 * **BestBlogs 早報**：速覽明確點出「如果 Harness 比模型本身更重要會怎樣」，並指出從固定 Harness 走向運行時自適應是下一步，但「結構會變，審計與除錯就更難」 ### 2. 自我改進的戰場從 artifact 層上移到 mechanism 層三篇文章從不同角度證明：優化「產生產物的機制」報酬遠高於優化產物本身，且機制載體不限於程式碼。 * **Bilevel Autoresearch**：用同一個 DeepSeek 模型的 outer loop 在 runtime 生成並注入新搜尋機制（Tabu Search / Multi-Scale Bandit / Orthogonal Exploration），在 Karpathy GPT benchmark 達到 5× 改善（val_bpb −0.045 vs −0.009），而僅調參數的 Level 1.5 無可靠增益；關鍵發現是生成的機制打破了 LLM「大 batch 更好」的隱含偏誤、逼出被系統性迴避的 TOTAL_BATCH_SIZE 縮小方向。作者的核心深層主張：code 不是特權載體，skill、prompt、workflow、evaluator、memory schema 同樣是 mechanism 的可能載體 * **Taxonomy**：把自演化系統分成三層（Artifact 迭代優化 / Harness 自我改進 / Model 無金標籤學習），並指出邊界正在模糊、未來應聯合演化——「更強 model 建造更好 harness、更好 harness 加速 artifact 搜尋、更好 artifact 回饋 model learning」 * **Building a Moat（CopilotKit）**：把學習施加位置分為 model weights / harness / context 三層，明確指出 model weights 路徑「只適用於可由電腦評分的領域，建議留給大實驗室」，多數產品的差異化空間在 harness 層；同時把 LLM 帶來的質變定位為「operator + optimizer 二合一」，帶來更大搜尋空間與更強 heuristic searcher ### 3. 記憶系統的反直覺共識：選擇性、結構化、讀取時機勝過儲存量四篇文章從不同尺度（個人、企業、產品、單一 agent）得出同一結論：記憶的價值不在「存更多」，而在「存對的、存結構化、在對的時間讀」。 * **Taste Index（Hermes + GBrain）**：極端選擇性——「No signal, no storage」，只有人類發出 trigger phrase（save this / I like this）才儲存，且每次儲存必須附帶「What I liked + Why useful」兩欄判斷；核心區分是「連結是收據，理由才是資產」（map ≠ territory），結論是「20 個強 capture 勝過 2000 個弱筆記」；讀取時機比儲存結構更重要——把 taste 讀取嵌入工作流前置步驟，等同在 reasoning loop 插入固定的「consult taste」 * **Ontology（企業級 memory）**：把「ontology」拆成兩個獨立決策——提取 schema（YAML/Pydantic，便宜，幾乎永遠該做）vs 語意基礎設施（OWL/SHACL/triple store，昂貴，條件性值得）；漏斗架構讓 95% 的事實永留 episodic KG，只有 5% 的 load-bearing nouns 通過 promotion gate 升級；反模式 2 的血淋淋案例：無 schema 的多 agent 系統六週後出現 `Vendor`/`vendor`/`Supplier`/`supplier_org`/`SupplierEntity`/`external_party` 六個近重複名詞指同一物件，跨 agent 檢索靜默失敗 * **Building a Moat**：借用認知科學把記憶分為 Procedural（工作流，風險是錯誤被放大）、Episodic（案例，挑戰是策展成本）、Semantic（事實，最危險的是無聲過時且 agent 自信不降）；強調介面層（AG-UI）是唯一同時看到 agent trace 與人類 ambient activity 的位置 * **AI = LLM + Harness（PolicyPulse）**：記憶層追蹤「變動」而非「現狀」——搜尋引擎回答「現在規則是什麼」，harness 回答「自上次以來改了什麼」，寫入是 idempotent 且每階段寫 checkpoint ### 4. 人類當責邊界重畫：Own the outer loop，back pressure 取代最大自主性當 agent 跑整個 inner execution loop，多篇文章共同指出人類價值移向判決、審計與後果承擔，且認知頻寬是 factory scale 無法平行化的硬上限。 * **Own the Outer Loop**：命題核心是「agent 跑整個 inner loop，工程師 own outer loop」；back pressure 原則是「不給 agent 它能行使的最大自主性，只給剛好夠並保留停止/檢查能力」；把傳統 human-in-the-loop 拆成四個迴圈（constraints / sampling / audit / ownership）；三個隱藏成本附帶可查證數據——cognitive surrender（Wharton：AI 錯時 ~75% 仍接受且更有信心）、cognitive debt（Anthropic RCT：理解測驗 50% vs 67%，差 17 個百分點）、orchestration tax（認知頻寬無法自動化、無法平行化）；關鍵隱喻是「edge 半衰期是一次 release，signature 半衰期是一整個職涯」 * **AI = LLM + Harness**：護欄必須「能真正失敗」才有價值——永遠綠勾的護欄等於沒有護欄；自癒來自 `enough` 判斷（`while not enough and loops < MAX_LOOPS`）加上後備切換（`search_with_source_policy` 偵測零官方來源就升級到 LLM web search，實測 UK 簽證主題從 0/8 官方來源變成 7/8） * **Taste Index**：curator「只 audit 不 ingest」是最關鍵的安全約束——維護任務只能 UPDATE/DELETE 不能 INSERT，否則就成了繞過 gate 的後門寫入路徑；「沉默 = 健康」避免通知疲勞，與 SRE 的 on-call 哲學一致 * **BestBlogs 早報**：human-in-the-loop 不該是「點批准的流程」，而該是「讓人保持判斷力的介面」——讓人看證據、做判斷、發現不確定性；強模型讓人容易放手卻可能推遲理解，弱模型反而迫使及時規劃與審查 ### 5. 驗證訊號與迴圈閉合處決定系統最終價值多篇文章共同指向一個常被忽略的前提：自演化與可信賴性的上限，由驗證訊號的可靠性與迴圈閉合的位置決定。 * **Taxonomy**：提出終極三問「What evolves? What feedback drives it? Where does the loop close?」——迴圈閉合在 benchmark 得到解題器、閉合在 code 得到更好軟體、閉合在科學得到新發現、閉合在物理世界得到真實系統的建造方式；但作者盲點是對驗證訊號品質過度樂觀，列舉的成功案例（kernel、程式碼、可模擬的機器人任務）都有廉價且可靠的 verifier，存在倖存者偏差 * **Bilevel Autoresearch**：validate-and-revert 機制（importlib 動態載入驗證、失敗從 pre-patch backup 還原）是 mechanism 注入安全的關鍵；論文誠實揭露 silent fallback 是危險失敗模式——一次初步 run 因 sys.modules 註冊 bug 讓所有機制注入靜默退回原 runner，無錯誤訊號 * **AI = LLM + Harness**：`enough` 檢查讓 agent 與 one-shot script 本質不同——一次性腳本在第一次搜尋弱時安靜失敗，這個迴圈能察覺證據單薄、改寫 query、再跑一輪；call_json 用 schema 驗證 + 矯正提示重試，把 trace 裡假造的 retry 次數 `0` 變成真實數字 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **為每個 agent workflow 畫出 inner/outer loop 邊界，並建立 accountability contract**：借鏡 Own the Outer Loop 的操作模型——把品質檢查收進 loop 內、判決權留在 loop 外，明確標出證據在哪裡跨越邊界；為每個 change 建立 checklist + evidence + accountable owner + post-block system status 的當責契約。同時用 Taxonomy 的三問（What evolves? What feedback? Where does the loop close?）在動手前定位你到底在優化哪一層，避免在錯誤層次做最佳化。 2. **記憶系統第一天就建輕量提取 schema，並設計 promotion gate**：依 Ontology 文章的行動綱領——不論系統規模，立刻寫一個 YAML 定義 15-20 個 entity class 與 10-15 個 relation type（成本極低，回報極高）；用漏斗架構讓多數事實留在 episodic KG，只有被「超過一個系統爭議且造成生產故障」的 load-bearing nouns 才升級到語意基礎設施層；指定一個 promotion gate 的 owner（data steward 或 category manager），否則語意層會累積過時定義。個人級系統則借鏡 Taste Index 的「No signal, no storage」與 curator「只 audit 不 ingest」約束。 3. **護欄設計成能真正失敗，並補上自我修正迴圈**：依 AI = LLM + Harness 的健檢清單——為現有 agent / skill 補上三件事：可真正失敗的護欄（不是永遠綠勾，要會亮紅/黃燈並把未滿足政策當 warning 而非靜默放行）、可觀測的 trace（retry 次數是真實的）、自我修正迴圈（弱結果會回頭改寫 query 再跑）。若要做 mechanism 層自我改進，借鏡 Bilevel 的 validate-and-revert（importlib 驗證、失敗從 backup 還原），並為 silent fallback 加上顯式偵測——無錯誤的靜默退回是最危險的失敗模式。 4. **評估 Agent 產品時，先判斷它演化哪一層、迴圈閉合在哪裡**：多數自稱「自學習」或「自演化」的產品其實只在 harness 層做 prompt/skill 累積，並未真正學習；用 Building a Moat 的「兩種訊號來源 × 三個施加位置 × 三種記憶類型」框架審計它是否同時捕獲 agent trace 與使用者修正、學習施加在哪一層、以及記憶類型的失敗模式是否被正視。引進任何 Agent 時，優先驗證它在真實倉庫裡推進長任務的表現（讀專案、呼叫工具、犯錯後恢復、驗證結果），而非只看基準分數。

Obsidian 開啟

實戰教學領域

實戰教學總結報告

今日「實戰教學」領域僅有一篇，但品質紮實——作者以一手實踐經驗拆解「普通人與中小企業如何搭建 AI 知識庫」這個高頻痛點，核心命題不是選型或採購，而是回到第一性原理：通用大模型用公開資料訓練，像「見多識廣但剛入職的新人」，缺的是你公司的上下文。作者提出輸出質量公式「模型 × 上下文 × 任務約束」，並把知識庫實現拆成由輕到重的五階階梯（投餵 → 目錄化 → 索引地圖 → RAG → 集成平台），明確指出絕大多數中小企業從第二階「目錄化」起步即可，反對一上來就追求向量檢索等重型方案。最有價值的洞察來自健康睡眠案例——顛覆直覺地主張「最有價值的資料不是產品說明書，而是客戶真實聲音」，先採集小紅書、抖音評論區與客服私信的問題，再結合產品資料生成回答模板。整篇方法論的可操作性極高：最小版本 5 步驟、跑通判斷 3 標誌、5 點自檢清單、兩段可直接複製的 prompt，以及把「錯誤寫回規則」當作系統生命線的反饋閉環。

核心主題 (Key Themes)

五階實現模型：知識庫是階梯而非選單，中小企業應從「目錄化」起步：作者最關鍵的選型決策是把實現方式定位為「由輕到重的五個階段，而非五個並列選項」，並明確中小企業的起點。這套階梯避免了一上來就過度工程的常見誤區。
RAG 語義匹配：當目錄與關鍵詞失效時的精準檢索升級路徑：作者把 RAG（Retrieval-Augmented Generation）定位為第四階，並清楚界定它的觸發條件與價值，而非當作入門必備。
最小版本 5 步驟：今天就能跑通一個場景的最短路徑：作者把「今天回去能做什麼」收斂成一條可立即動手的最短路徑，並附跑通判斷標準與自檢清單，這是全文可操作性最強的資產。

# 領域總結：實戰教學 (2026-07-09) ## 總結概述今日「實戰教學」領域僅有一篇，但品質紮實——作者以一手實踐經驗拆解「普通人與中小企業如何搭建 AI 知識庫」這個高頻痛點，核心命題不是選型或採購，而是回到第一性原理：通用大模型用公開資料訓練，像「見多識廣但剛入職的新人」，缺的是你公司的上下文。作者提出輸出質量公式「模型 × 上下文 × 任務約束」，並把知識庫實現拆成由輕到重的五階階梯（投餵 → 目錄化 → 索引地圖 → RAG → 集成平台），明確指出絕大多數中小企業從第二階「目錄化」起步即可，反對一上來就追求向量檢索等重型方案。最有價值的洞察來自健康睡眠案例——顛覆直覺地主張「最有價值的資料不是產品說明書，而是客戶真實聲音」，先採集小紅書、抖音評論區與客服私信的問題，再結合產品資料生成回答模板。整篇方法論的可操作性極高：最小版本 5 步驟、跑通判斷 3 標誌、5 點自檢清單、兩段可直接複製的 prompt，以及把「錯誤寫回規則」當作系統生命線的反饋閉環。 ## 核心洞察與共同趨勢 ### 1. 五階實現模型：知識庫是階梯而非選單，中小企業應從「目錄化」起步作者最關鍵的選型決策是把實現方式定位為「由輕到重的五個階段，而非五個並列選項」，並明確中小企業的起點。這套階梯避免了一上來就過度工程的常見誤區。 * **第一階直接投餵**：把檔案上傳給 AI 臨時回答，適合一次性小任務，但每次重傳、難沉澱成長期系統。 * **第二階目錄化（作者最推薦的起點）**：不搭平台，把資料分五類放進目錄（企業基礎、產品服務、客戶問題、案例資料、輸出規則），告訴 AI「遇到什麼場景去哪個目錄找」。不需技術基礎、不用先買系統，本質是把電腦／飛書／網盤裡的資料變成「AI 能找到的資料區」。 * **第三階索引地圖**：解決目錄化「一個檔案不只歸一類」的痛點，讓 AI 先掃過所有資料、按主題畫索引地圖，對應 Andrej Karpathy 的 LLM Wiki 思路（讓 AI 維護 wiki 頁面、索引與日誌串聯原始資料）。 * **第四階 RAG 與向量檢索**：資料多到目錄與關鍵詞都失效時的升級方案。 * **第五階集成平台**：把知識庫嵌入既有客服／文檔系統的企業級方案。 * **起點判斷**：「對絕大多數普通人與中小企業，從第二種開始就夠了」「能用起來，比方案看起來複雜更重要」——這是全文選型的核心裁決。 ### 2. RAG 語義匹配：當目錄與關鍵詞失效時的精準檢索升級路徑作者把 RAG（Retrieval-Augmented Generation）定位為第四階，並清楚界定它的觸發條件與價值，而非當作入門必備。 * **觸發條件**：當資料量爆炸、需要語義級精準檢索時，目錄化與索引地圖迅速失效，此時才須升級到 RAG。 * **語義匹配 vs 關鍵詞匹配**：RAG 提前把資料按片段（chunking）處理好，檢索時不匹配關鍵詞而是「匹配語義」——理解問題的意思，去找意思最接近的那段資料。典型場景是找「表達某種特定主題的文案」或「很具體的知識點」，這類需求很難用目錄名或關鍵詞定位。 * **選型啟示**：作者刻意淡化向量資料庫與 RAG 的技術門檻，對普通人與中小企業明確「第一版通常還用不到這麼重的方案」，把 RAG 留給資料量大、需按語義精準找片段的場景——這是一條務實的升級判斷線，而非技術追清單。 ### 3. 最小版本 5 步驟：今天就能跑通一個場景的最短路徑作者把「今天回去能做什麼」收斂成一條可立即動手的最短路徑，並附跑通判斷標準與自檢清單，這是全文可操作性最強的資產。 * **五步驟**：第一步建一個「知識庫」根目錄；第二步分五類（企業基礎、產品服務、客戶問題、案例資料、輸出規則），先把現有資料扔進去即可不必完美；第三步選一個能讀本地檔案的 AI agent 工具（核心標準：能不能進入你的環境讀資料並在授權下做事，Codex／WorkBuddy 屬此類）；第四步用結構化 prompt 讓 AI 先給分類建議、人確認（不讓 AI 直接移動原檔）；第五步從一個最小場景測試，建議選「安全任務」——10 份不敏感資料 + 1 個真實但不涉隱私的客戶問題。 * **跑通判斷 3 標誌**：AI 能說明引用了哪些資料；輸出比通用問答更貼近真實業務；可透過反饋繼續修正。 * **5 點自檢清單**：AI 有無說明引用資料／回答有無出現自家產品案例規則／有無編造知識庫沒有的資訊／能否稍微修改後使用／能否把不滿意處寫回輸出規則。 * **兩段可複製 prompt**：一是資料自動分類（讀檔名與內容、按五類給歸屬建議、標主分類與關聯分類、列無法判斷清單，嚴格不刪不改不移原檔）；二是基於知識庫回答客戶問題（先判斷客戶真正關心什麼、給可發給客戶的簡短回答、必須標註引用來源、資料不足明確說「不能確定」、列出需人工確認的風險點）。 * **反饋循環是生命線**：搭起來只是第一步，每次錯誤不只改這次回答，而是把限制寫回規則（如產品只適合哪些人、哪些場景須人工確認），下次 AI 自然更精準——這對應 prompt 工程的 few-shot 累積與 rule-based guardrails，也是 PDCA 持續改善閉環在知識管理的映射。 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **別從 RAG 起步，先建五類目錄跑通一個最痛場景**：依五階階梯定位自己所在階段，中小企業絕大多數從第二階「目錄化」起步即可。今天花 15 分鐘做最小測試——建一個「知識庫」資料夾、分五個子目錄、放 10 份不敏感資料、用客戶問答 prompt 拿一個真實問題試一次，用 5 點自檢清單驗收。 2. **資料採集優先採客戶真實聲音，而非先整理產品說明書**：參考健康睡眠案例，先去小紅書、抖音評論區、客服私信、銷售對話採集客戶到底在問什麼，篩選高頻高價值問題，再結合產品資料讓 AI 生成回答模板。這決定了知識庫內容的優先級，避免「整理得很整齊卻沒人用」。 3. **把「錯誤寫回規則」當成系統維護的日常紀律**：每次 AI 答錯或輸出有「AI 味」，不要只改這一次，把限制（產品適用人群、必須人工確認的場景、不要用的句式與開頭）寫回輸出規則文檔。指定專人維護規則庫，避免規則膨脹失序或互相矛盾。 4. **設定明確的升級觸發訊號，避免在目錄化階段硬撐**：當五類目錄下檔案從 10 份成長到上千份、目錄與關鍵詞開始找不到東西、或需按語義精準找片段時，就是升級到索引地圖或 RAG 的訊號；當企業要求知識庫嵌入既有客服／文檔系統時，才走向第五階集成平台。把升級判斷線寫進團隊規範，而非憑感覺。

Obsidian 開啟

工作方法領域

工作方法總結報告

Fable 5 標誌著「模型能力不再是瓶頸」的時代到來，Agentic Coding 的核心從「模型能做什麼」轉向「使用者能否把需求說清楚」。Thariq 提出的四類未知框架（Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns）成為系統化管理 AI 協作中「未知」的認知工具。優秀的 agentic coder 共同特徵是「未知特別少」— 他們清楚自己要什麼，同時假設存在未知並提前為偏差留空間。方法論在三個階段展開：編碼前用盲點掃描、頭腦風暴、採訪式提問、參考代碼低成本發現未知；編碼中維護 implementation-notes.md 記錄決策偏差；編碼後用 Pitch 文檔和自測 Quiz 將個人探索轉化為團隊資產。視頻剪輯案例驗證了「從已知出發、增量探索」的工作方式在全新領域依然有效。

核心主題 (Key Themes)

四類未知框架來自軍事情報領域，適用於 AI 協作：這個認知工具將「未知」分類為四個象限Known Knowns 是寫進 prompt 的明確需求；Known Unknowns 是知道還沒想清楚的部分（如數據庫選型）；Unknown Knowns 是太顯而易見不會寫下，但看到結果就知道對不對的隱性標準（視覺設計是典型例子）；Unknown Unkno...
編碼前的投入產出比最高，四個低成本技巧對付四類未知：針對不同類型的未知，編碼前有四個技巧盲點掃描針對 Unknown Unknowns，讓 AI 用 HTML 可視化展示你根本沒考慮過的風險維度；頭腦風暴和原型針對 Unknown Knowns，讓 AI 做 5 個方向的快速原型，你從中挑選和排除，把隱性標準顯性化；採訪式提問是最關鍵的一步，讓 AI...
編碼中到編碼後，將個人探索轉化為團隊資產：編碼中都會遇到新的 Unknown Unknowns，維護 implementation-notes.md 記錄每一個偏離計劃的決策（做了什麼假設、為何選此方案、哪裡偏離原計劃、發現什麼邊緣情況），下次做類似任務時就知道哪些地方容易出意外。編碼後的 Pitch 文檔讓 AI 把原型、spec 和實作...

# 領域總結：工作方法 (2026-07-09) ## 總結概述 Fable 5 標誌著「模型能力不再是瓶頸」的時代到來，Agentic Coding 的核心從「模型能做什麼」轉向「使用者能否把需求說清楚」。Thariq 提出的四類未知框架（Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns）成為系統化管理 AI 協作中「未知」的認知工具。優秀的 agentic coder 共同特徵是「未知特別少」— 他們清楚自己要什麼，同時假設存在未知並提前為偏差留空間。方法論在三個階段展開：編碼前用盲點掃描、頭腦風暴、採訪式提問、參考代碼低成本發現未知；編碼中維護 implementation-notes.md 記錄決策偏差；編碼後用 Pitch 文檔和自測 Quiz 將個人探索轉化為團隊資產。視頻剪輯案例驗證了「從已知出發、增量探索」的工作方式在全新領域依然有效。 ## 核心洞察與共同趨勢 ### 1. 四類未知框架來自軍事情報領域，適用於 AI 協作這個認知工具將「未知」分類為四個象限：Known Knowns 是寫進 prompt 的明確需求；Known Unknowns 是知道還沒想清楚的部分（如數據庫選型）；Unknown Knowns 是太顯而易見不會寫下，但看到結果就知道對不對的隱性標準（視覺設計是典型例子）；Unknown Unknowns 是根本沒考慮過的維度，連問題都提不出來。Thariq 觀察到 Anthropic 內部優秀工程師的 prompt 寫作特徵是「未知特別少」— 他們非常清楚自己要什麼，但同時假設存在未知並提前為偏差留空間。 ### 2. 編碼前的投入產出比最高，四個低成本技巧對付四類未知針對不同類型的未知，編碼前有四個技巧：盲點掃描針對 Unknown Unknowns，讓 AI 用 HTML 可視化展示你根本沒考慮過的風險維度；頭腦風暴和原型針對 Unknown Knowns，讓 AI 做 5 個方向的快速原型，你從中挑選和排除，把隱性標準顯性化；採訪式提問是最關鍵的一步，讓 AI 一次問一個問題，優先問那些「你的回答會顯著改變實現方向」的問題，逼出你沒意識到的偏好；參考代碼解決「你知道要什麼但描述不出來」的問題，直接指向實現類似行為的代碼庫，讓 AI 學習現有實現而非用語言重新描述。 ### 3. 編碼中到編碼後，將個人探索轉化為團隊資產編碼中都會遇到新的 Unknown Unknowns，維護 implementation-notes.md 記錄每一個偏離計劃的決策（做了什麼假設、為何選此方案、哪裡偏離原計劃、發現什麼邊緣情況），下次做類似任務時就知道哪些地方容易出意外。編碼後的 Pitch 文檔讓 AI 把原型、spec 和實作筆記打包成可以直接扔到 Slack 的文檔，這對需要審批的團隊特別有用，因為審批者和你一開始有同樣的未知，一份好的 pitch 能加速他們的理解。自測 Quiz 讓 AI 給你出一份 HTML 報告和 quiz，測試你對改動的理解程度，與其花 30 分鐘逐行讀 diff，不如用 5 分鐘做個測驗。 ## 行動建議與實踐指南 1. **立即行動：盲點掃描** — 下次讓 AI 幫你做任何事之前，先做一次「盲點掃描」—「先別實現，列出我可能根本沒意識到的坑、邊界情況、需提前定的決策，按會不會返工/影響架構/影響資料安全排序」。這個技巧的成本幾乎可以忽略，但能避免在實現階段才發現方向錯誤的巨大代價。 2. **短期實踐：implementation-notes.md** — 建立「implementation-notes.md」習慣，記錄每一次偏離計劃的決策，連同「做了什麼假設」「為何選此方案」「哪裡偏離原計劃」「發現什麼邊緣情況」。這些筆記在當次會話結束後可以被刪除，但它們的價值在於下次做類似任務時，你知道哪些地方容易出意外。 3. **長期投資：參考代碼庫** — 建立個人的「參考代碼庫」，收集高品質的實作範例。遇到類似需求時直接指向代碼庫而非模糊描述需求。這對於「我不知道這叫什麼，但我知道長什麼樣」的場景特別有效，比試圖用語言重新描述要精確得多。 4. **增量主義工作方式** — 採用「從已知出發、增量探索」的工作方式，而非一開始就規劃好完整方案。從已知的起點出發，用原型快速探索，遇到未知時就地學習就地實現。視頻剪輯案例驗證了這個方法在全新領域依然有效 — 知道 Claude 能用代碼剪輯視頻和轉錄音頻，做多個方向原型測試 UI 和音頻同步，遇到 Unknown Unknown（視頻偏灰）時讓 Claude 教調色概念後直接在代碼中實現。

Obsidian 開啟

工作流領域

工作流總結報告

今天工作流領域只有一篇文章，但它是少見把「Claude 工作流」從口號推進到可複製工程藍圖的實戰拆解。作者 Christine Zhu 是同時管理 5-10 條工作線的 platform PM，她提出的工作流設計核心命題是：判斷力（judgment）本質是對上下文做模式匹配，而 Claude 能持有的上下文遠大於人——因此工作流的設計目標不是「自動化雜務」，而是系統性地把上下文餵進去、降低啟動門檻，讓 Claude 介入需要判斷的高槓桿工作。她引用 @shreyas 的三層產品工作框架（impact / execution / optics），為每一層配置不同的人機協作模式與觸發頻率：曝光層用 scheduled task 全自動產出 status board、執行層用 context-dump 與 planning skill 當副駕駛、影響層用語音 dump + Fable max 當對練夥伴產出 shitty first draft。整套設計最值得借鏡的不是工具清單，而是兩個工程決策：用 JSON + Drive inbox + Apps Script time trigger 把「Claude 產出」與「Sheet 寫入」解耦，以及用一個持續更新的 context folder 作為所有工作流的共同基礎建設。這是一份從「單點自動化」升級到「分層授權工作流系統」的遷移指南。

核心主題 (Key Themes)

依「判斷密度」分層，對應三種不同的人機協作模式與觸發頻率：工作流設計的第一步不是選工具，而是把工作依「需要多少判斷」分層，再為每一層配對不同的授權程度。作者引用 @shreyas 的三層框架，並為每層指定一種明確的協作模式
鬆耦合的自動化管線：用 inbox 模式解耦「LLM 產出」與「目標系統寫入」：作者提供的 scheduled task instruction template 是這篇文章最具操作性的產物，其架構亮點不是五步驟本身，而是刻意把產出與寫入拆開的解耦設計。五步驟為Read current sheet state（用 google connector）→ Gather signal...
context folder 作為共同基礎建設：持續 onboard + 降低啟動門檻的雙軸設計：三層工作流要能齊用，前提是 Claude 永遠拿到對的上下文。作者把這件事升級成一個獨立的基礎建設層——context folder——並用兩個軸向把它操作化一是「持續 onboard 讓上下文不斷更新」，二是「降低啟動門檻讓人願意在零碎時間啟動最難的工作」。

# 領域總結：工作流 (2026-07-09) ## 總結概述今天工作流領域只有一篇文章，但它是少見把「Claude 工作流」從口號推進到可複製工程藍圖的實戰拆解。作者 Christine Zhu 是同時管理 5-10 條工作線的 platform PM，她提出的工作流設計核心命題是：判斷力（judgment）本質是對上下文做模式匹配，而 Claude 能持有的上下文遠大於人——因此工作流的設計目標不是「自動化雜務」，而是系統性地把上下文餵進去、降低啟動門檻，讓 Claude 介入需要判斷的高槓桿工作。她引用 @shreyas 的三層產品工作框架（impact / execution / optics），為每一層配置不同的人機協作模式與觸發頻率：曝光層用 scheduled task 全自動產出 status board、執行層用 context-dump 與 planning skill 當副駕駛、影響層用語音 dump + Fable max 當對練夥伴產出 shitty first draft。整套設計最值得借鏡的不是工具清單，而是兩個工程決策：用 JSON + Drive inbox + Apps Script time trigger 把「Claude 產出」與「Sheet 寫入」解耦，以及用一個持續更新的 context folder 作為所有工作流的共同基礎建設。這是一份從「單點自動化」升級到「分層授權工作流系統」的遷移指南。 ## 核心洞察與共同趨勢 ### 1. 依「判斷密度」分層，對應三種不同的人機協作模式與觸發頻率工作流設計的第一步不是選工具，而是把工作依「需要多少判斷」分層，再為每一層配對不同的授權程度。作者引用 @shreyas 的三層框架，並為每層指定一種明確的協作模式： * **Optics（曝光層）— autopilot 全自動**：讓進度被對的人看見。在 Cowork 設定 scheduled task 每週跑兩次，從 Slack channels、calendar、meeting notes、git 拉取上下文，寫入 Google Sheet 模板，產出 G-Sheet status board 讓團隊自行查答案。作者只剩「審閱/編輯」這一步，並強調「要無情地自動化 optics，因為它照顧了 dopamine backlog，讓你留在心流中」。另有一個 skill 把同一份更新封裝成不同受眾與論壇的版本。 * **Execution（執行層）— copilot 人機協作**：三個具體自動化。每週一跑 context-dump skill，讀過去一週的 Slack、calendar、notes、repo activity，做效率與個人模式的因果診斷（真實輸出範例：「Leverage 降至 ~70% 目標以下，不是因為 overhead 上升，而是 alignment/ceremony 佔了 calendar 的 ~35-40%，擠掉了 heads-down leverage work」——這是教練級判斷而非摘要）。planning skill 檢查 Jira 狀態與 roadmap、顯示下一步該排什麼，再由人請 Claude 做 Jira 更新或把 PRD 轉成 tickets。customer support 分析則是每月 scheduled task，給 top themes 與趨勢。 * **Impact（影響層）— sparring partner 人為主、Claude 為輔**：這是最難、也最多人不敢外包的一層——思考新產品賭注、準備高風險簡報敘事、把策略拿去對抗 business unit 策略。作者的關鍵解法不是「等完美條件」，而是用 10 分鐘空檔語音 dump 到預載上下文的 Claude project，用 Fable high 或 max 對練出 shitty first draft。這是全篇「最大生產力躍升」發生之處。分層的實質意義：不同層適合不同的「放手程度」。autopilot 可以不審就出；copilot 必須人看過再行動；sparring 的產出永遠是人類的起點而非終點。把三層混為一談、用同一種協作模式對待，是工作流設計最常見的錯誤。 ### 2. 鬆耦合的自動化管線：用 inbox 模式解耦「LLM 產出」與「目標系統寫入」作者提供的 scheduled task instruction template 是這篇文章最具操作性的產物，其架構亮點不是五步驟本身，而是刻意把產出與寫入拆開的解耦設計。五步驟為：Read current sheet state（用 google connector）→ Gather signals from Slack channels + PM Journal（last 3 days）→ Determine changes（只報告有 verifiable backing 的變更）→ Push updates via Drive inbox → DM Christine 一份 under 500 characters 的 glanceable 摘要。 * **JSON + Drive inbox + Apps Script time trigger 的解耦**：Claude 不直接寫 Google Sheet，而是把 JSON update file 丟進一個 Drive inbox 資料夾，由 Apps Script 每小時的 time trigger pick up 並套用變更。這個設計的工程價值在於：LLM 的產出（不可靠、可能格式錯）與目標系統的寫入（需要一致性、可重試）被佇列隔開，即使 LLM 這次產出有問題，也只是一顆未消化的 JSON，不會污染 sheet 狀態；且 Apps Script 可獨立加 schema 驗證。這是「把 LLM 當不可信產出者」的正確架構姿勢。 * **guidelines 作風格校準層**：template 結尾明確標注「Be factual. No inferences or speculation.」「Use the sheet's own terminology（如 ◉ In Dev、○ Planned、Complete、On Track、At Risk）」「Keep the DM under 500 characters. Christine wants glanceable, not comprehensive.」——這些不是裝飾，而是把輸出風格（精確 vs 推論、完整 vs 掃一眼）寫進 prompt，避免 LLM 預設的「樂於補充」破壞 status board 的可用性。 * **connectors 是工作流的血管**：整套 setup 依賴 Slack、Google Drive、Outlook、Jira、GitHub、HeyMarvin 等 connectors 把多源 context 帶進 LLM。這也點出邊界——當組織禁止 connectors 存取 Slack/Jira 時，整套管線無法落地；當 context 含 PII 或商業機密時，onboard 整個 roadmap 有隱私與合規風險（作者未討論）。 ### 3. context folder 作為共同基礎建設：持續 onboard + 降低啟動門檻的雙軸設計三層工作流要能齊用，前提是 Claude 永遠拿到對的上下文。作者把這件事升級成一個獨立的基礎建設層——context folder——並用兩個軸向把它操作化：一是「持續 onboard 讓上下文不斷更新」，二是「降低啟動門檻讓人願意在零碎時間啟動最難的工作」。 * **context folder 的具體內容**：從既有的產品 deck、roadmap、codebase summary 開始，再語音 dump 進目標與指標、stakeholder（角色 + 他們關心什麼）、想學與成長的領域。在 Cowork project 或 Claude Code 裡用這個 context folder 工作，讓它隨工作自動更新。PM folders 另存放 evergreen markdowns：會議筆記、writing style guide、company annual goal、templates/frameworks。這不是一次性設定，而是一個活的、隨工作生長的 context 庫。 * **降低 activation energy 本身就是產物**：作者引用化學隱喻——催化劑不改變反應物，只降低啟動門檻。impact 層工作最大的敵人不是「做不好」，而是「一直不開始」。10 分鐘空檔 + 語音 dump + Fable max 的組合，把「過去要花好幾天」的啟動壓縮到幾分鐘，產出 shitty first draft 作為後續迭代的起點。HTML artifact 技巧（請 Claude 產出 HTML artifact 而非 markdown 牆）進一步降低理解門檻，但作者刻意不分享 HTML artifact 本身——它只作為視覺化起點，再到 Claude Code 透過 Figma connector 迭代成最終分享的 doc 視覺。 * **context-dump 的 rolling history 形成自評閉環**：context-dump skill 不只做當週分析，它的 rolling history（做了什麼、遇到什麼挑戰、達成什麼、從會議筆記建立的人際動態）每隔幾個月可請 Claude 審查，評估新技能、盲點、推薦成長方向——前提是先在 goals.md 定義好「下一階段」。這讓工作流從「執行→產出」的單向管線，升級成「執行→產出→回顧→校正目標」的閉環，也讓月度與年終 review 有現成的素材。 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **為你的工作畫一張分層地圖，並為每層指定一種人機協作模式**：列出你這週所有工作，逐一標記屬於 optics / execution / impact 哪一層。關鍵判準是「這件事需要多少判斷」——需要越少判斷、越重複的，越該往 autopilot 推；需要策略對抗與敘事建構的，留在 sparring。為每層寫下不同的授權程度（全自動出 / 人看過再行動 / 人為主 Claude 為輔），避免用同一種模式對待三層。 2. **挑一個每週重複的曝光類工作，實作一條 inbox 解耦管線**：選一個週報或 status update，照五步驟 template 實作：LLM 從多源拉 signals → 只報 verifiable changes → 把更新寫成 JSON 丟進 inbox → 由排程器 pick up 套用 → DM 一份 glanceable 摘要。重點是讓 LLM 不直接碰目標系統，中間留一個可審查的 JSON 佇列。guidelines 務必寫死「factual, no inferences」與字數上限。 3. **建一個 context folder 並讓它隨工作生長**：從產品 deck、roadmap、codebase summary、stakeholder 清單、目標開始，放進 Claude project 或 Claude Code workspace。核心是「讓它隨工作自動更新」而非一次性設定。同步建一個 writing style guide md，讓產出風格一致。先開始、再迭代——作者明說 setup 是「最不重要的部分」，別讓完美設定變成新的 dopamine backlog。 4. **為 impact 層工作設計一個「10 分鐘啟動」入口**：挑一個你一直拖延的最高槓桿任務，在預載 context folder 的 Claude project 裡，用語音 dump 現有想法，問它「我漏了什麼」。目標不是產出成品，而是產出 shitty first draft 把啟動門檻降到零碎時間也能啟動。這對應作者的核心心智模型翻轉：判斷力是上下文的函數，只要你願意系統性地 onboard，Claude 的判斷可以超越你。

Obsidian 開啟

知識管理領域

知識管理總結報告

今日單篇文章直擊知識管理的最大盲區——人們系統性地保存「結果」（文章、代碼、筆記），卻任由「過程」（AI 對話這類最高頻、最密集的思考產物）聊完即棄。作者的做法不是呼籲手動整理，而是把 AI 工具本地的「SQLite 元資訊 + JSONL transcript」雙層存儲結構當成可靠資料源，用一個 Python 腳本把會話解析成 Obsidian Markdown 卡片，再以按角色截斷（用戶全文、AI 分三檔）與 transcript_mtime 增量同步這兩個工程機制，解決「卡片太長拖垮 Obsidian」與「重生卡片覆蓋手動標註」兩個會讓自動化破產的難題。從架構師視角看，價值不在腳本本身，而在它示範了一個可遷移模式——任何本地優先（local-first）的 AI 工具，只要底層是「元資訊表 + 時序 transcript 檔」的雙層結構，就能用同一套「找檔 → 解析 → 轉卡片」邏輯接入知識庫。而讓方案能長期運行的關鍵，不是功能強大，而是截斷與增量同步這兩個不起眼的工程細節。更深一層的洞見是：知識庫的隱藏價值不是檢索過去，而是讓多張卡片並列時，思維模式與迴避信號自己浮現——這是單次對話永遠看不到的。

核心主題 (Key Themes)

SQLite 元資訊 + JSONL transcript 的雙層存儲架構，是對接 AI 工具的通用介面：作者發現兩個本地優先的 AI 工具（Codex、WorkBuddy）底層存儲結構高度同構——都是「元資訊走 SQLite、對話本體走時序 JSONL 檔」的雙層設計。這意味著「找檔 → 解析 → 轉 Markdown」可以抽象成一套統一邏輯，差異只在「去哪找檔案」與「JSONL 裡 type 欄位的...
按角色分檔截斷——用價值不對稱換取可讀性：對話動輒 4MB、單條 AI 回覆上萬字，全文保留會把 Obsidian 拖到卡死。作者沒有採用「統一字數上限」這類對稱截斷，而是基於一個明確的價值判斷做不對稱處理用戶的提問是高密度資訊（意圖、脈絡、判斷），AI 的回復大量是推理過程與試錯，可壓縮。這個判斷讓截斷策略同時兼顧「保留檢索價值」與「控制...
transcript_mtime 增量同步——讓自動化不破壞既有標註：自動同步最大的隱形風險不是效能，而是「重生卡片會覆蓋掉用戶之前在手動標註、批注的內容」。作者用檔案系統的 mtime 作為便宜的髒資料標記，把「是否要重生」變成 O(1) 的時間戳比對，避免每次全量重生。這個機制是方案能長期運行、不與用戶產生衝突的工程基石。

# 領域總結：知識管理 (2026-07-09) ## 總結概述今日單篇文章直擊知識管理的最大盲區——人們系統性地保存「結果」（文章、代碼、筆記），卻任由「過程」（AI 對話這類最高頻、最密集的思考產物）聊完即棄。作者的做法不是呼籲手動整理，而是把 AI 工具本地的「SQLite 元資訊 + JSONL transcript」雙層存儲結構當成可靠資料源，用一個 Python 腳本把會話解析成 Obsidian Markdown 卡片，再以按角色截斷（用戶全文、AI 分三檔）與 transcript_mtime 增量同步這兩個工程機制，解決「卡片太長拖垮 Obsidian」與「重生卡片覆蓋手動標註」兩個會讓自動化破產的難題。從架構師視角看，價值不在腳本本身，而在它示範了一個可遷移模式——任何本地優先（local-first）的 AI 工具，只要底層是「元資訊表 + 時序 transcript 檔」的雙層結構，就能用同一套「找檔 → 解析 → 轉卡片」邏輯接入知識庫。而讓方案能長期運行的關鍵，不是功能強大，而是截斷與增量同步這兩個不起眼的工程細節。更深一層的洞見是：知識庫的隱藏價值不是檢索過去，而是讓多張卡片並列時，思維模式與迴避信號自己浮現——這是單次對話永遠看不到的。 ## 核心洞察與共同趨勢 ### 1. SQLite 元資訊 + JSONL transcript 的雙層存儲架構，是對接 AI 工具的通用介面作者發現兩個本地優先的 AI 工具（Codex、WorkBuddy）底層存儲結構高度同構——都是「元資訊走 SQLite、對話本體走時序 JSONL 檔」的雙層設計。這意味著「找檔 → 解析 → 轉 Markdown」可以抽象成一套統一邏輯，差異只在「去哪找檔案」與「JSONL 裡 type 欄位的語義」，這是讓方案能低成本擴展到第三、第四個 AI 工具的關鍵。 * **Codex（VS Code AI 編輯器）**：會話元資訊存在 `~/.codex/state_5.sqlite` 的 `threads` 表（標題、模型、創建時間、工作目錄），對話本體在 `~/.codex/sessions/rollout-*.jsonl`，JSONL 每行一個 JSON 物件按時間排序，`type` 欄位區分用戶消息／AI 回復／工具調用。 * **WorkBuddy**：元資料存在 `~/.workbuddy/workbuddy.db` 的 `sessions` 表，transcript 在 `~/.workbuddy/projects/{project}/{sessionId}.jsonl`，`type` 欄位語義更細——含 `message`、`reasoning`（AI 推理過程）、`function_call`（工具調用）。 * **可遷移性判斷**：純雲端網頁版（如網頁 ChatGPT 無本地檔）無法走這條路，需改走 API 匯出；這個模式的適用邊界是「本地有 sqlite + jsonl 檔」的 AI 工具。 ### 2. 按角色分檔截斷——用價值不對稱換取可讀性對話動輒 4MB、單條 AI 回覆上萬字，全文保留會把 Obsidian 拖到卡死。作者沒有採用「統一字數上限」這類對稱截斷，而是基於一個明確的價值判斷做不對稱處理：用戶的提問是高密度資訊（意圖、脈絡、判斷），AI 的回復大量是推理過程與試錯，可壓縮。這個判斷讓截斷策略同時兼顧「保留檢索價值」與「控制卡片體積」。 * **用戶消息一律不截斷**：再長也全文保留，因為提問是最高價值的內容。 * **AI 回復按長度分三檔**：≤6000 字全文保留；6000~15000 字保留頭尾、去中間；>15000 字只保留開頭分析 + 結尾輸出。閾值 6000／15000 作者未說明推導依據，屬經驗值，遷移時需依自身工具回覆長度分布重新校準。 * **未解的演進方向**：截斷目前是「按長度」，更進階應升級為「按資訊密度」——例如只保留被 AI 追問後改變想法的轉折點，丟棄純試錯噪音。 ### 3. transcript_mtime 增量同步——讓自動化不破壞既有標註自動同步最大的隱形風險不是效能，而是「重生卡片會覆蓋掉用戶之前在手動標註、批注的內容」。作者用檔案系統的 mtime 作為便宜的髒資料標記，把「是否要重生」變成 O(1) 的時間戳比對，避免每次全量重生。這個機制是方案能長期運行、不與用戶產生衝突的工程基石。 * **同步邏輯**：每張卡片頭部的 YAML frontmatter 記錄 `transcript_mtime`（來源 transcript 檔的最後修改時間）；腳本每次運行對比當前 mtime 與記錄值，有變化才重生，沒變化直接跳過（「一秒都不花」）。 * **排程與靜默執行**：Windows 定時任務每天 10:00 觸發，用 `pythonw.exe` 靜默運行，不彈窗口、不需互動；實作踩過 mtime 精度問題與 pythonw 下 stdout 崩潰等坑，但已修補。 * **與截斷策略的協同**：截斷決定「一張卡片多大」，增量同步決定「何時重生一張卡片」——兩者共同保證知識庫不會被自動化反噬；缺任一個，腳本要麼拖垮 Obsidian，要麼清掉用戶的標註。 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **盤點自己常用 AI 工具的本地存儲結構**：先確認工具是否為 local-first（本地有 sqlite + jsonl 檔）。找到元資訊表（如 threads／sessions）與 transcript 檔的對應關係後，用「SQLite 讀元資訊 → 找對應 transcript 檔 → 解析 JSONL 的 type 欄位 → 生成 Markdown 卡片」這條流水線即可接入知識庫；純雲端工具改走官方 API 匯出。 2. **為對話入庫設計不對稱截斷策略**：預設保留用戶消息全文，AI 回復依長度分檔壓縮；6000／15000 字閾值是作者經驗值，應依自身工具回覆長度分布重新校準，並追蹤「截斷後是否漏掉關鍵結論」來迭代閾值。 3. **用 mtime 增量同步保護手動標註**：在卡片 frontmatter 記錄來源檔的 `transcript_mtime`，每次運行只重生 mtime 變化的卡片；搭配定時任務（如 Windows Task Scheduler 或 cron）靜默執行，避免自動化覆蓋用戶在卡片上累積的批注。 4. **擴大「過程即資產」的視野**：AI 對話只是「高頻卻最不保存」的思考產物之一；同理可建的入庫管道還包括會議錄音轉稿、語音備忘錄、草稿與白板照片。並在累積一定數量後，刻意把跨專案的卡片並列檢視，讓重複的思維模式（如「先啟動再定義問題」）與迴避信號自己浮現——這是知識庫超越「檢索」之上的自我發現價值。

Obsidian 開啟

系統架構領域

系統架構總結報告

今日系統架構領域僅有一篇深度拆解，來自資深 infra 工程師 @CMGS1988（前豆瓣平台組、cocoonstack 開源作者）以 cocoon / sandbox（基於 cloud-hypervisor 的企業級 sandbox）實戰為主軸，重新定義了 AI 時代 infra 工程的核心命題：infra 的本質不是「寫代碼」，而是 trade-off 與責任承擔（背鍋）。全文透過兩個一手案例——2012 年豆瓣繞開 GIL 時唯獨 Redis 維持同步的歷史決策，以及當前 cloud-hypervisor 開 UFFD 後 restore 變快卻讓系統恢復變慢的反直覺數據——論證了一個架構師級結論：trade-off 的目標函數權重（延遲、成本、穩定性、事故責任等）本質是組織題與人心題，無法被數學形式化，因此 human in the loop 不可省。與此同時，AI（尤其 Fable 5 xhigh）已在執行層達到「3-1 / 阿里 P8 級執行者」的水準，把會設計的人的執行力放大十倍。架構演進的真正斷層不在「AI 能不能寫 infra」，而在「不可形式化決策是人的護城河、可形式化執行正被 AI 快速吃掉」——設計判斷力與事故經驗（「吃過的屎」）成為新定價錨點。

核心主題 (Key Themes)

Infra trade-off 不可形式化——權重是「人心題」不是「數學題」：架構決策的目標函數看似可量化，但真正的瓶頸在於權重由誰而定。作者提出一份架構決策 checklist 清單，這些維度的權重從來不是數學題，而是組織題、人心題，必須由人承擔後果
UFFD 效能 trade-off——「快啟動 ≠ 快可用」的反直覺證據：cloud-hypervisor restore 開 UFFD（userfaultfd）的實測數據，是全文最硬的反方檢驗案例，也示範了為何 AI 在 trade-off 上仍需人類輸入。e2b.dev、fly.io 等開源 sandbox 為追求進程層面快速啟動，普遍採用 UFFD 與 FUSE 懶...
Infra 選型與 AI 協作——「會設計的人執行力被放大」才是真衝擊：AI 對 infra 的衝擊方向，不是「不會寫代碼的人也能寫 infra」，而是「會設計的人執行力被放大」。作者用國內大廠職級對模型能力做了主觀分級（未經標準化 benchmark，僅供參考）

# 領域總結：系統架構 (2026-07-09) ## 總結概述今日系統架構領域僅有一篇深度拆解，來自資深 infra 工程師 @CMGS1988（前豆瓣平台組、cocoonstack 開源作者）以 cocoon / sandbox（基於 cloud-hypervisor 的企業級 sandbox）實戰為主軸，重新定義了 AI 時代 infra 工程的核心命題：infra 的本質不是「寫代碼」，而是 trade-off 與責任承擔（背鍋）。全文透過兩個一手案例——2012 年豆瓣繞開 GIL 時唯獨 Redis 維持同步的歷史決策，以及當前 cloud-hypervisor 開 UFFD 後 restore 變快卻讓系統恢復變慢的反直覺數據——論證了一個架構師級結論：trade-off 的目標函數權重（延遲、成本、穩定性、事故責任等）本質是組織題與人心題，無法被數學形式化，因此 human in the loop 不可省。與此同時，AI（尤其 Fable 5 xhigh）已在執行層達到「3-1 / 阿里 P8 級執行者」的水準，把會設計的人的執行力放大十倍。架構演進的真正斷層不在「AI 能不能寫 infra」，而在「不可形式化決策是人的護城河、可形式化執行正被 AI 快速吃掉」——設計判斷力與事故經驗（「吃過的屎」）成為新定價錨點。 ## 核心洞察與共同趨勢 ### 1. Infra trade-off 不可形式化——權重是「人心題」不是「數學題」架構決策的目標函數看似可量化，但真正的瓶頸在於權重由誰而定。作者提出一份架構決策 checklist 清單，這些維度的權重從來不是數學題，而是組織題、人心題，必須由人承擔後果： - 延遲（latency） - 成本（cost） - 穩定性（stability） - 可維護性（maintainability） - 遷移風險（migration risk） - 事故責任（incident liability） - 團隊能力（team capability）豆瓣 2012 年的 Redis 同步決策是此命題的教科書案例：當年用 Gevent monkey patch + 自研 greenify 繞開 Python GIL，做到全棧非同步 IO，唯獨快取維持同步。推理鏈是——MySQL 的 DB op 開銷大、IO wait 動輒數十到數百毫秒，業務層只能等，值得非同步化；但 Redis / Memcached 快如閃電，黑魔法（monkey patch）的開銷可能已大於「讓 GIL 鎖著同步請求」的開銷，硬上非同步是純負優化。決策者還得反覆向業務開發解釋、並承擔這口鍋。作者面試常問「什麼場景選 select、什麼場景選 epoll」，多年沒幾人答得好——這正是 trade-off 判斷力稀缺的證據。 ### 2. UFFD 效能 trade-off——「快啟動 ≠ 快可用」的反直覺證據 cloud-hypervisor restore 開 UFFD（userfaultfd）的實測數據，是全文最硬的反方檢驗案例，也示範了為何 AI 在 trade-off 上仍需人類輸入。e2b.dev、fly.io 等開源 sandbox 為追求進程層面快速啟動，普遍採用 UFFD 與 FUSE 懶載入，但代價很少被攤開來看： - 開 UFFD 後，cloud-hypervisor restore 開銷從約 150ms 降到 70~80ms（PR 可號稱「亞毫秒級啟動」） - 但系統可用恢復時間從 1s 直接飆到 7s+ - 行為隨 OS 不同而異：Linux 與 Windows 表現不一致 - 隨記憶體大小不同而異：大記憶體機器與小記憶體機器 again 不一樣 CH 進程「咻」地啟動、設備層模擬得很快，但系統不可用——這種快又有什麼意義？作者辛辣類比：「就像宇宙條那個 json 庫，你再快還不是得讓 SQL 拖後腿。」深層原因在於 AI 的 token 預測本質是貪心算法（greedy），多數情況按機率高選 token 沒毛病，但遇到需要策略與 trade-off 之處，局部最優反而未必是好選擇，因為凡事都有代價。模型「吃的屎不夠多」——缺乏真實機架與真實事故的經驗累積，這正是老機架工程師的經驗溢價所在。 ### 3. Infra 選型與 AI 協作——「會設計的人執行力被放大」才是真衝擊 AI 對 infra 的衝擊方向，不是「不會寫代碼的人也能寫 infra」，而是「會設計的人執行力被放大」。作者用國內大廠職級對模型能力做了主觀分級（未經標準化 benchmark，僅供參考）： - Opus 4.6 ~ Opus 4.8：約從「頭條 1-2」進化到「2-2 弱」水平，還得看 Anthropic 算力是否持續投入 - 國產開源 Qwen 27B：約「1-2 強」水平 - Fable 5（xhigh 開）：至少「頭條 3-1 / 阿里 P8 級別」的執行者上線，是質的飛躍 sandbox 專案的實戰佐證了這個量級：作者僅貢獻詳細設計、自己吃屎的經驗、代碼習慣，時不時看一眼，項目就基本成了。技術棧表現差異明顯——Go / Python（作者熟悉）讓模型提取其代碼習慣後，每輪提交自行按習慣 review，產出代碼工整、功能完備、測試齊全；Rust（作者經驗不多）也有約 60 分。原本十天半月的工作量被壓縮到數天。關鍵啟示：會設計 + 有事故經驗的人，現在只要提供設計與習慣就能讓項目成型，純執行型、無 trade-off 的 infra 工作（樣板部署、常規腳本）則會被大幅稀釋。 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **把 trade-off 思維當核心競爭力刻意練習**：不要糾結於特定框架或語言的熟練度，而是把上述七項權重清單（延遲 / 成本 / 穩定性 / 可維護性 / 遷移風險 / 事故責任 / 團隊能力）內化為每次架構決策的 checklist，並在設計文件中明確標出每個決策的取捨與承擔者。 2. **用具體方案實體逼出 trade-off 偏好，而非抽象討論**：UFFD 開/關兩版的實測數據（150ms vs 70ms、1s vs 7s+）之所以有說服力，是因為它把「快啟動 ≠ 快可用」具象化。做架構決策時，應主動產出 ≥2 個對立的具體方案實體（含實測數據、邊界條件如 OS / 記憶體差異），讓 stakeholder 看到取捨後再判斷，避免 AI 或人用「業界最佳實踐」偷偷填補未知項。 3. **把事故經驗與決策理由結構化記錄，作為 human in loop 的最高價值輸入**：作者能讓 sandbox 專案成立，靠的不是寫代碼，而是「吃屎經驗」。應建立 ADR（Architecture Decision Record）或事後檢討的結構化知識庫，記錄每個決策的脈絡、踩過的坑、不同 OS / 記憶體配置下的行為差異——這正是模型最缺、也最難自動取得的訓練信號。 4. **自我重定位為「設計者 + 督導」，主動用 AI 放大執行力**：參照作者的協作模式——貢獻設計、提取並固化自己的代碼習慣給模型、按 Milestone 讓模型自行推進、定期 review。把自己從碼農拉高到設計者與督導，把可形式化的執行交給 AI（如 Fable 5 xhigh 的 P8 級執行力），把心力集中在不可形式化的 trade-off 與責任承擔。

Obsidian 開啟

認知框架領域

認知框架總結報告

兩篇文章表層各講各的——一篇拆解「Loop」在 Anthropic、吳恩達、納德拉三方手中的三層含義（執行機器 × 分工結構 × 復利飛輪），一篇主張成人學習要 180 度反轉、先做後學。但拉到認知框架的抽象層，兩篇其實在描述同一個範式轉移：AI 商品化了「執行」與「知識供給」之後，線性的「先備齊再出發」路徑全面失效，取而代之的是自我增強的循環（Loop）——而循環的設計目標不是單次效率，而是可持續的復利與動機維持。在這個範式下，人的核心價值從「能做什麼」上移到「判斷做什麼、為什麼做、問對問題」；能否把每一輪循環裡的判斷沉澱成跨工具、跨模型耐久的資產（而非隨迭代腐爛的用法），決定了一個人是在累積 Token 資本，還是只在租用別人的能力。兩篇共同把「循環 + 復利 + 判斷沉澱」確立為 AI 時代的認知作業系統，並一致指出：瓶頸已從知識取得轉移到提問與判斷，動機與可持續性才是這套系統真正的目標函數。

核心主題 (Key Themes)

循環（Loop）取代線性路徑，因果方向被反轉：兩篇都拒絕「先系統化備齊、再出發應用」的線性路徑，主張先把循環跑起來，讓循環本身帶你升級。直覺的「能力 → 產出」因果被反轉為「產出 → 能力」，直覺的「先備齊 → 再做事」被反轉為「先做事 → 循環帶你備齊」。
瓶頸上移——AI 商品化執行層後，稀缺性與人的價值往判斷、提問、Spec 定義移動：兩篇共同指出一個經濟學與認知科學雙重視角的轉移AI 把最內層的執行壓縮到分鐘級後，價值的稀缺點往外、往上移動。人的核心價值不再是「能做什麼」，而是「判斷做什麼、為什麼做、問對問題」。
沉澱的耐久度決定你是資產還是裝修——沉澱判斷（why）而非用法（how）：循環轉完一圈後留下什麼，是兩篇共同的核心焦慮。能跨工具、跨模型、跨版本耐久的東西才是資產（Token 資本），會隨迭代腐爛的東西只是給隨時會拆的樓裝修。
可持續性（動機 + 復利）是系統設計的目標函數，單次效率是陷阱：兩篇都把「可持續的自我增強」奉為系統設計的隱性目標函數，並明確指出單次最高效、理論上最完備的路徑，若壓垮動機或無法復利，就是失敗的設計。

# 領域總結：認知框架 (2026-07-09) ## 總結概述兩篇文章表層各講各的——一篇拆解「Loop」在 Anthropic、吳恩達、納德拉三方手中的三層含義（執行機器 × 分工結構 × 復利飛輪），一篇主張成人學習要 180 度反轉、先做後學。但拉到認知框架的抽象層，兩篇其實在描述同一個範式轉移：AI 商品化了「執行」與「知識供給」之後，線性的「先備齊再出發」路徑全面失效，取而代之的是自我增強的循環（Loop）——而循環的設計目標不是單次效率，而是可持續的復利與動機維持。在這個範式下，人的核心價值從「能做什麼」上移到「判斷做什麼、為什麼做、問對問題」；能否把每一輪循環裡的判斷沉澱成跨工具、跨模型耐久的資產（而非隨迭代腐爛的用法），決定了一個人是在累積 Token 資本，還是只在租用別人的能力。兩篇共同把「循環 + 復利 + 判斷沉澱」確立為 AI 時代的認知作業系統，並一致指出：瓶頸已從知識取得轉移到提問與判斷，動機與可持續性才是這套系統真正的目標函數。 ## 核心洞察與共同趨勢 ### 1. 循環（Loop）取代線性路徑，因果方向被反轉兩篇都拒絕「先系統化備齊、再出發應用」的線性路徑，主張先把循環跑起來，讓循環本身帶你升級。直覺的「能力 → 產出」因果被反轉為「產出 → 能力」，直覺的「先備齊 → 再做事」被反轉為「先做事 → 循環帶你備齊」。 * **納德拉 Loop（三層樓）**：完整的 Loop 是三層疊加——一樓 Anthropic 的執行機器（`/goal`、`/loop`、Stop hook、子智能體）必須先轉起來，三樓納德拉的復利飛輪才會發生。三層互為前提：缺一樓輪子空轉，缺二樓每天從零開始，缺三樓概念落不了地。Loop 不是「轉圈」而是「爬山」，迴圈本身就是升級機制。 * **Unlearn school（180 度反轉）**：口訣「Do first, learn later」把「能力 → 產出」反轉為「產出 → 能力」，與精實創業的 build-measure-learn 迴圈、軟體工程的 just-in-time learning 與 spike 同構。作者用 Google AI Studio / Replit / Cursor 學 coding，白話描述想法、幾分鐘產出可用成品，幾個專案下來學到的比一年大學 CS 講座還多——迴圈跑起來後，能力是產出的副產品。 ### 2. 瓶頸上移——AI 商品化執行層後，稀缺性與人的價值往判斷、提問、Spec 定義移動兩篇共同指出一個經濟學與認知科學雙重視角的轉移：AI 把最內層的執行壓縮到分鐘級後，價值的稀缺點往外、往上移動。人的核心價值不再是「能做什麼」，而是「判斷做什麼、為什麼做、問對問題」。 * **納德拉 Loop（吳恩達的稀缺性外移）**：當寫代碼被 agentic coding 壓縮到分鐘級，稀缺性外移到定義 Spec、修正方向、從真實用戶拿回 External Feedback。吳恩達的三層循環（Agentic Coding → Developer Feedback → External Feedback）把「哪層交 AI、哪層人必須留下」從感覺變成結構性結論。 * **Unlearn school（瓶頸轉移到提問能力）**：AI 是「24/7 世界級家教，只要你問得出問題」。瓶頸從「找不到人教、找不到資料」轉移到「你知不知道自己缺什麼、問不問得出對的問題」——學習路徑由需求 pull，而非由課綱 push。會問問題的人取得巨大優勢。 ### 3. 沉澱的耐久度決定你是資產還是裝修——沉澱判斷（why）而非用法（how）循環轉完一圈後留下什麼，是兩篇共同的核心焦慮。能跨工具、跨模型、跨版本耐久的東西才是資產（Token 資本），會隨迭代腐爛的東西只是給隨時會拆的樓裝修。 * **納德拉 Loop（換模型測試 + 判斷 vs 用法）**：納德拉提出最尖銳的可操作檢驗——「能否隨時換掉底層模型，而不丟失系統裡沉澱的專業知識？換個模型系統就廢了，那你的 Loop 只是在消費別人的能力。」作者進一步區分粒度：業務判斷（如「為何選 Postgres 不選 Mongo」）跨工具跨世代成立，是 Token 資本；工具細節（如「Claude Code 碰 TypeScript 要加 `--strict`」）綁定特定工具行為，工具一升級就失效，是裝修。核心原則：沉澱判斷，別沉澱用法。 * **Unlearn school（能力透過真實產出固化）**：成人學習不是靠背誦基礎固化能力，而是靠真實產出與愉悅感（elation / empowerment）把判斷內化。作者請 AI 走過 codebase 結構、各檔案用途、串接方式並加註解，是在沉澱「這個系統為何這樣設計」的判斷，而非記住某個 API 的呼叫方式。 ### 4. 可持續性（動機 + 復利）是系統設計的目標函數，單次效率是陷阱兩篇都把「可持續的自我增強」奉為系統設計的隱性目標函數，並明確指出：單次最高效、理論上最完備的路徑，若壓垮動機或無法復利，就是失敗的設計。 * **納德拉 Loop（獨立開發者必須自建三樓）**：大公司有組織慣性，不刻意建 Loop 也會沉澱東西；獨立開發者沒有這個慣性，寫完就扔、明天全新會話從頭來過，Loop 永遠停在一樓。納德拉「你可以把任務外包、把崗位外包，但不能把學習外包」——三樓的學習復利無法委外，必須靠紀律每週加一顆螺絲。 * **Unlearn school（sustaining motivation is the key）**：成人學習一切方法的設計都服從「保護內在動機、讓學習可持續」這個唯一不變量。反轉學習之所以有效，不是因為「由上而下」在認知科學上必然優於「由下而上」，而是因為它把學習即時連結到產出與愉悅感，維持了成人唯一的燃料。系統化打底若會壓垮動機，就該被犧牲。 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **為工作流與學習各畫一張三層 Loop 診斷圖**：盤點你目前卡在哪一層——執行機器沒搭起來（一樓：`/goal`、Stop hook、子智能體是否到位）、人機分工沒想清楚（二樓：哪些層交 AI、哪些層你必須留下判斷與回饋）、還是轉完一圈什麼都沒沉澱（三樓）。用納德拉的換模型測試做壓力測試：明天換掉底層模型，你的 CLAUDE.md / skill / hook / 筆記還能讓新模型接手嗎？能，代表在建資產；不能，代表在租用別人的能力。 2. **把「先做後學」落實為 48 小時產出迴圈**：對任何一直學不起來的領域，先定義一個 48 小時內能產出的小成品（一段翻譯、一個可運行網頁、一篇摘要），倒推所需知識，用 AI 即時補位。關鍵是把 AI 當蘇格拉底式家教——請它走過結構、解釋每個檔案用途與串接、在每處加註解——而不是只問答案。瓶頸不再是知識取得，而是你問不問得出對的問題。 3. **建立「判斷級 vs 用法級」的沉澱分流機制**：每週回顧新增的筆記、規則、skill，逐條標註是「判斷級」（跨工具跨模型成立，如架構選型理由）還是「用法級」（綁定特定工具版本，如某個 flag 與 workaround）。前者進核心資產並持續複用，後者標註有效期限並定期清理。Loop 的減法與加法同等重要——舊判斷也會過時，何時刪除一條沉澱是必須主動設計的機制，否則三樓會從資產退化成僵化教條。 4. **把「保護動機」設為隱性目標函數**：無論學習或工作流設計，在「理論上更系統完備」與「能即時產出愉悅感與回饋」之間，優先選後者。對成人與獨立開發者，可持續性永遠優於單次最優——一個能持續跑下去、每週多沉澱一點的次優迴圈，長期會碾壓一個完美但跑三次就放棄的路徑。為你的學習標的先定義 job to be done，確保每一輪循環都能看見產出。

Obsidian 開啟

開發工具領域

開發工具總結報告

今日開發工具領域僅有一篇深度拆解，但技術密度極高——CodeGraph 示範了 AI coding 工具下一階段的優化路徑：與其追求更聰明的模型，不如預先為 codebase 建立一張可即時查詢的結構地圖。它用 tree-sitter 把整個專案解析成 AST，萃取 function/class/method 的 calls、imports、inheritance 邊，寫入本地 SQLite 並啟用 FTS5 全文搜尋，再透過單一次 MCP（Model Context Protocol）工具呼叫回傳「確定性答案」——這與 Cursor 的向量語意搜尋回傳「機率性線索」形成根本的資訊架構對立。在七個真實開源專案、七種語言的嚴謹 benchmark 中（統一使用 Claude Opus 4.7 無頭模式、每組四跑取中位數），CodeGraph 平均削減 57% token、35% 成本、提升 46% 回應速度、減少 71% 工具呼叫次數。更關鍵的是它揭示了一條收益曲線：專案規模越大、語言模組系統越複雜（尤其 Rust 的巢狀 mod/use/pub use 重匯出），圖譜的邊際價值越高——Excalidraw 降 90% token、Tokio Rust 成本從 $2.41 降至 $0.42。這代表「模型智力」已不再是 AI 輔助開發的唯一瓶頸，「context 取得的工程效率」才是。

核心主題 (Key Themes)

確定性呼叫圖取代向量語意搜尋——tree-sitter AST + SQLite FTS5 + MCP 的技術棧選擇：CodeGraph 的核心創新不在「更聰明的搜尋」，而在根本改變 AI 取得 codebase 資訊的介面從「讀檔 + 相似度排序」換成「查圖譜 + 確定關係」。
Benchmark 揭示收益曲線——規模 × 語言模組複雜度決定圖譜價值：CodeGraph 團隊自跑的 benchmark 雖為自報數據（採用時應留意選樣偏差），但其方法論嚴謹七專案 × 七語言、相同 Claude Opus 4.7、相同探索任務、唯一變數為是否有圖譜、每組四跑取中位數。數據清楚指向一條可預測的收益曲線。
三層自動同步架構——讓索引在開發流程中完全隱形：圖譜類工具的成敗往往不在「能不能建圖」，而在「圖能不能隨 codebase 演進無感保持新鮮」。CodeGraph 用一個三層系統解決這個工程難題，是全文技術密度最高的段落，對自建類似系統極具參考價值。

# 領域總結：開發工具 (2026-07-09) ## 總結概述今日開發工具領域僅有一篇深度拆解，但技術密度極高——CodeGraph 示範了 AI coding 工具下一階段的優化路徑：與其追求更聰明的模型，不如預先為 codebase 建立一張可即時查詢的結構地圖。它用 tree-sitter 把整個專案解析成 AST，萃取 function/class/method 的 calls、imports、inheritance 邊，寫入本地 SQLite 並啟用 FTS5 全文搜尋，再透過單一次 MCP（Model Context Protocol）工具呼叫回傳「確定性答案」——這與 Cursor 的向量語意搜尋回傳「機率性線索」形成根本的資訊架構對立。在七個真實開源專案、七種語言的嚴謹 benchmark 中（統一使用 Claude Opus 4.7 無頭模式、每組四跑取中位數），CodeGraph 平均削減 57% token、35% 成本、提升 46% 回應速度、減少 71% 工具呼叫次數。更關鍵的是它揭示了一條收益曲線：專案規模越大、語言模組系統越複雜（尤其 Rust 的巢狀 mod/use/pub use 重匯出），圖譜的邊際價值越高——Excalidraw 降 90% token、Tokio Rust 成本從 $2.41 降至 $0.42。這代表「模型智力」已不再是 AI 輔助開發的唯一瓶頸，「context 取得的工程效率」才是。 ## 核心洞察與共同趨勢 ### 1. 確定性呼叫圖取代向量語意搜尋——tree-sitter AST + SQLite FTS5 + MCP 的技術棧選擇 CodeGraph 的核心創新不在「更聰明的搜尋」，而在根本改變 AI 取得 codebase 資訊的介面：從「讀檔 + 相似度排序」換成「查圖譜 + 確定關係」。 * **解析層的容錯性賭注**：選擇 tree-sitter（最初為 Atom 開發、現為 Neovim 語法引擎）而非傳統編譯器前端，關鍵在於**fault-tolerance**——即使程式碼含語法錯誤（正在寫到一半的狀態），仍能產生部分 AST。這在真實開發場景中是硬需求，也讓索引數萬檔可行。萃取 query 辨識 symbols（function/class/method/interface）與 edges（calls/imports/inheritance/implementations）。 * **儲存與取用的零摩擦組合**：所有資料寫入單一 `.codegraph/codegraph.db`（SQLite + FTS5 全文搜尋），單檔零依賴、無雲端、無 API key、無資料傳輸——這對受監管產業與專有 codebase 是 Gemini Code Assist（雲端託管、程式碼離開本機）與 Copilot 索引（雲端限定 beta）無法滿足的差異化錨點。 * **MCP 作為確定性答案的傳輸層**：AI agent 問「誰呼叫了這個 function？」時，單一次 MCP 工具呼叫直接回傳 entry points + 相關符號 + 程式碼片段，**沒有逐檔探索、沒有 agent 迴圈、沒有被無關檔案撐爆的 context window**。安裝器自動偵測本機 Claude Code、Cursor、Codex CLI、Gemini CLI 等 8 種工具並設定 MCP 整合，免手動配置。相較之下 Cursor 的向量嵌入只能回傳依相似度排序的片段（線索），AI 仍需逐一讀檔驗證關係——CodeGraph 回傳的是「答案」而非「線索」。 ### 2. Benchmark 揭示收益曲線——規模 × 語言模組複雜度決定圖譜價值 CodeGraph 團隊自跑的 benchmark 雖為自報數據（採用時應留意選樣偏差），但其方法論嚴謹：七專案 × 七語言、相同 Claude Opus 4.7、相同探索任務、唯一變數為是否有圖譜、每組四跑取中位數。數據清楚指向一條可預測的收益曲線。 * **大型 TypeScript monorepo 受益最深**：VS Code（~10,000 檔）token 從 280 萬降至 60.1 萬（↓78%）、Ops ↓85%；Excalidraw（~640 檔）token 從 350 萬降至 34.4 萬（↓90%）、Ops ↓96%。**草垛越大，沒有地圖的 AI 越狼狽**——驗證了「預計算結構換查詢加速」在龐大 codebase 的槓桿效應。 * **Rust 模組系統對 agent 遍歷的懲罰最重**：Tokio（Rust，~790 檔）成本從 $2.41 降至 $0.42（↓82%）。合理歸因：Rust 的 `mod` 宣告、`use` 路徑、`pub use` 重匯出、巢狀模組階層創造了特別曲折的探索路徑，CodeGraph 用單一查詢就解析掉。 * **小專案邊際效益遞減的邊界**：OkHttp（Java，645 檔）僅 ↓13% token、成本 ↓2%；Gin（Go，110 檔）↓34%。在小規模下暴力讀檔懲罰不大，圖譜價值下降——這是採用決策的關鍵門檻判斷。另一個邊界是：省下的每個 token 都是被消除的機械式探索，**對推理密集任務（「為何這 query 慢」「設計快取層」）不貢獻**，CodeGraph 是 enhancer 非 replacement。 ### 3. 三層自動同步架構——讓索引在開發流程中完全隱形圖譜類工具的成敗往往不在「能不能建圖」，而在「圖能不能隨 codebase 演進無感保持新鮮」。CodeGraph 用一個三層系統解決這個工程難題，是全文技術密度最高的段落，對自建類似系統極具參考價值。 * **Layer 1 — 原生 OS 檔案監看器（零 polling）**：macOS 用 FSEvents、Linux 用 inotify、Windows 用 ReadDirectoryChangesW——各 OS 提供的最低階變更通知機制，檔案存檔時 OS 直接通知 CodeGraph，**無 polling、無 CPU 額外開銷**。這是整個無感同步的效能基石。 * **Layer 2 — 兩秒 debounce 批次處理**：一個靜默窗口收集所有變更並合併成單一次增量同步。一次重構改五個檔案，被當作一個批次而非觸發五次獨立索引重建——避免「存檔即重建」的效能抖動。 * **Layer 3 — staleness 旗標 + 重連調解**：尚未同步的檔案被明確標記為 stale，AI agent 知道要直接讀原檔而非查可能過時的圖譜；工具重新連線時用 `(size, mtime)` 比較 + content-hash 驗證，只辨識真正變更的檔案重新同步。結果是**任何人的工作流程中都沒有「重建索引」這一步**——這正是本地優先方案能與雲端託管競爭的關鍵工程細節。 ## 行動建議與實踐指南 (Actionable Takeaways) 1. **在大型 TypeScript / Rust 專案上實測 CodeGraph 量測自身 token 削減**：安裝只需 `curl -fsSL https://raw.githubusercontent.com/colbymthenry/codegraph/main/install.sh | sh` 後 `codegraph init -i`。macOS 先裝 Xcode command-line tools（`xcode-select --install`），否則 fallback 模式慢 5-10 倍。優先挑 ~1,000 檔以上的專案——小專案（OkHttp 645 檔僅 ↓13%）邊際效益不足以證明導入成本。預設排除 node_modules、vendor、dist、build、target、.venv、gitignored、>1MB 檔案。 2. **評估 AI coding 工具 TCO 時，單獨拆出「探索成本」計算**：benchmark 證明同一個 Claude Opus 4.7 在有圖譜時 token 從 280 萬降至 60.1 萬——這塊「機械式檔案探索」往往是隱形大宗。團隊在比較 Cursor / Gemini Code Assist / Copilot 時，應把「context 取得效率」當獨立維度，而非只比模型智力。 3. **自建內部工具時，套用「預計算索引取代重複探索」的同構模式**：這與 DB 的 B-tree 索引避免全表掃描、編譯器的 call graph analysis、導航的預建路網圖、記憶體階層的 cache 預熱是同一原理。盤點團隊流程中「哪些重複的機械式探索（找路由 config、追 middleware 鏈、跨服務呼叫追蹤）可以被預計算的結構索引取代」——CodeGraph 的 14 框架路由辨識（Spring/NestJS/Flask/FastAPI/Rails/Laravel/Django URLconf/SvelteKit）就是這個思路的具體落地。 4. **認清靜態呼叫圖的邊界，評估「靜態 + 動態」混合圖的潛力**：重度依賴 reflection / metaprogramming / DI 的語言（重度 DI 的 Java、Ruby metaprogramming、裝飾器注入）會造成靜態解析漏邊。若團隊 codebase 大量使用動態分派，考慮用運行時 trace（如 OpenTelemetry）補強靜態圖譜，或結合向量語意搜尋做「先語意定位、再結構追蹤」的兩階段查詢。

Obsidian 開啟

📚 文章摘要列表 (Articles)

AI工具

Model and effort in Claude Code: knowing more vs. trying harder（模型與努力：Claude Code 中的知識更多與更努力）

"先檢查 context；若 context 完整仍失敗——「不知道」換 Model，「不夠努力」調 Effort。"

Top 5 Insights

**Model 控制能力上限，Effort 控制工作深度**：Model 決定使用哪組凍結 weights（知識庫），Effort 決定在做請求時的工作量（讀檔數、驗證度、執行步數）。
**診斷優先順序**：Claude 搞砸時先查 context（prompt、tools、skills、verification），再診斷「不知道」（Model 問題）vs「不夠努力」（Effort 問題）。
**Token 經濟學**：常規任務小模型省錢不犧牲品質；困難任務大模型雖單 token 貴，但總成本可能更低（更少步數達品質門檻）。
**Effort 的動態特性**：高 Effort 不是「想更久」，而是「做更多事」，且計畫會動態調整（找到 bug 後跳過剩餘假設）。
**比喻總結**：Fable＝專家（最深坑任務），Opus＝高手（架構、微妙 bug），Sonnet＝通才（常規編輯）；Effort＝給他們的時間。

--- tags: [AI工具, ClaudeCode, 模型選擇, Effort設定] date: 2026-07-09 read: false source: "2026-07-09T131835+0800-Model and effort in Claude Code knowing more vs. trying harder.md" original_title: "Model and effort in Claude Code knowing more vs. trying harder" --- # Model and effort in Claude Code: knowing more vs. trying harder（模型與努力：Claude Code 中的知識更多與更努力） ![Image](https://pbs.twimg.com/media/HMuGsvQbwAAimdV?format=jpg&name=large) 原始來源與檔名：2026-07-09T131835+0800-Model and effort in Claude Code knowing more vs. trying harder.md --- ## SOURCE | 資訊源評估 - **準確性**：高 - 來自 Claude Code 官方團隊成員 Lydia Hallie，技術細節與實作機制描述具備權威性 - **易理解性**：中 - 需具備基礎 LLM 運作知識（tokenization、inference、weights）才能完全理解技術細節 - **閱讀策略建議**：先理解「Model 控制能力上限，Effort 控制工作深度」這個核心二元關係，再深入技術實作細節 ## NAPKIN | 餐巾紙 ### 餐巾紙公式 > **Model = 能力上限（知識庫），Effort = 工作深度（嘗試程度）** _模型決定「能知道什麼」，努力決定「做多少事」_ ### 一句話 > 當 Claude 搞砸時：先檢查 context；若 context 完整仍失敗——「不知道」換 Model，「不夠努力」調 Effort。 ### 餐巾紙草圖 ``` Model Setting (模型選擇) ├─ Fable (專家) → 最強能力，處理幾乎無人能解的問題 ├─ Opus (高手) → 架構決策、微妙 bug、陌生領域 └─ Sonnet (通才) → 日常編輯、機械性變更、已載入程式碼 Effort Setting (努力程度) ├─ High (高努力) → 計畫先行、讀取所有檔案、執行測試、雙重驗證 ├─ Default (預設) → 根據任務自動調整 token 使用量 └─ Low (低努力) → 快速掃描、偏好詢問而非自行推演診斷流程 ┌─ 結果不佳？ │ ├─ context 清晰嗎？（prompt、tools、skills、verification） │ └─ 否 → 改善 context │ └─ 是 → 繼續 │ └─ 失敗原因？ ├─ 不夠努力（跳過檔案、不跑測試、不驗證） → 提高 Effort └─ 不知道（能力不足） → 換更大的 Model ``` ## ROUND 1: SKELETON | 骨架掃描 - **核心問題**：Model 與 Effort 這兩個設定實際上如何影響 Claude Code 的輸出？如何判斷應該換 Model 還是調 Effort？ - **核心答案**：Model 控制使用哪一組凍結的 weights（能力上限），Effort 控制在做請求時的工作量（讀檔案數、驗證程度、執行步數）。診斷問題時先查 context，再依「不知道 vs 不夠努力」決定調整方向。 - **論證結構**：從 Model 運作原理（tokenization → weights → inference）切入，再解釋 Effort 的 token 機制，最後給出實務選擇指南與診斷流程。 ### 章節骨架（條列） 1. **開場問題**：Model 與 Effort 看起來都「讓答案更好」，但實際差異是什麼？ 2. **Model 運作原理**：從 API 請求到 tokenization、weights、inference 的完整鏈路 3. **Effort 運作機制**：控制思考/工具呼叫/文字輸出的 token 分配 4. **選擇 Model 的時機**：什麼時候用大模型？什麼時候用小模型？ 5. **選擇 Effort 的時機**：何時提高努力？何時用預設？ 6. **比喻總結**：專家、高手、通才 + 時間分配 7. **Token 消耗模式**：常規任務 vs 困難任務的成本曲線 8. **診斷流程**：Claude 搞砸時的排查順序 ## ROUND 2: DISSECTION | 血肉解剖 ### 論證鏈（ASCII）/ 3 個關鍵證據 / 隱形假設與邊界 **論證鏈** ``` 用戶請求 → Claude Code 組裝上下文 ↓ API 請求（system prompt + tools + CLAUDE.md + history + files） ↓ Tokenization（文字 → token ID array，const→1978, await→4293） ↓ Model Inference（凍結的 weights 計算每個 token 的機率） ↓ Token Generation（一次生成一個 token，200 token = 200 次矩陣運算） ↓ Effort Level 影響每次生成的 token 數量（思考、工具、文字） ``` **3 個關鍵證據** 1. **Weights 在 inference 期間唯讀**：`const x = await` 的預測來自訓練時編碼的權重，你的 prompt 只能「引導」預測方向，不能改變權重本身。這解釋了為什麼沒見過的庫無法「學會」——只能透過 context 引導單次請求。 2. **Effort 控制的「工作量」是 token 數**：同樣 prompt，高 Effort 生成約 7x token（含更多思考、驗證步驟），但這不是「思考時間」而是「工作深度」。 3. **成本曲線交叉點**：常規任務小模型省錢不犧牲品質；困難任務大模型雖然單 token 貴，但總成本可能更低（因為能更少步數達到品質門檻）。 **隱形假設與邊界** - 假設：用戶已理解「tokenization 是預處理步驟」——實際上用戶可能認為 model 直接讀文字。 - 假設：用戶知道「weights 訓練後凍結」——實際上用戶可能期待「context 可以教會 model 新知識」。 - 邊界：`max_tokens` 是硬性截斷（中斷回應），`task budgets` 是軟性引導（學會在接近上限時收尾）。 - 邊界：Effort 不強制 token 消耗——簡單任務即使高 Effort 也不會人為膨脹（訓練時避免「overthinking」）。 ## ROUND 3: SOUL | 靈魂提取 - **作者盲點**：未充分探討「什麼算 clear context」——給出具體檢查清單（prompt 精確度、tools 可用性、skills 匹配度、verification 機制）會更實用。 - **知識連接**： - 連結到「Chain-of-Thought prompting」——Effort 本質上是自動化的 CoT 深度控制。 - 連結到「Capability vs Thoroughness trade-off」——類似 hiring 時「選人才」vs「給時間」的權衡。 - 連結到「Token economics」——大模型在小任務上的驗證步驟是「保險費」，大任務上的效率是「規模經濟」。 - **行動觸發**： - 下次 Claude 搞砸時，先記錄「失敗模式」再診斷：是「沒讀某檔」「沒驗證結果」「沒跑測試」（Effort 問題）還是「產生不存在 API」「混淆概念」（Model 問題）。 - 建立團隊內部的「Model-Effort 決策樹」：常規編輯→Sonnet Default，架構設計→Opus High，深坑 bug→Fable。 ### 留白提問（2 題）/ 跨域映射 1. **如果 Effort 可以自動動態調整（根據任務複雜度自動升/降），什麼信號應該觸發調整？** 是檔案數量？錯誤訊息複雜度？還是 user 迭代次數？ 2. **「Overthinking」在訓練時如何被偵測與懲罰？** 是透過人工標註「不必要的推理步驟」，還是自動化指標（相同品質下 token 較少的路徑獎勵）？ **跨域映射**： - **專案管理**：Model ≈ 團隊能力上限（seniority），Effort ≈ 投入工時（hours）。高能力團隊短時間 vs 中能力團隊長時間。 - **教學設計**：Model ≈ 教師專業深度，Effort ≈ 課程深度設計。專家講 5 分鐘 vs 資深老師講一下午。 ## DEEP READ | 精讀指引（2-3 段 + 推薦理由，製造認知阻力） **精讀段 1：Weights 的唯讀性（第 48-62 行）** > 「The weights of each model are set during training, and by the time you're sending requests they're read-only. Nothing in your prompt, your CLAUDE.md, or your context changes them. If you've run into the word inference, that's all it means: using the model after training is done, with the weights fixed.」 > > 「If a library didn't exist when the model was trained, it isn't in the weights. You can put the docs in context and Claude will use them, but that's steering, not teaching. Claude's response is only influenced for that one request, but the underlying model hasn't retained anything.」 **推薦理由**：這段揭露了 LLM 最核心的「能力凍結」特性——透過 context 引導不是「教會」而是「單次引導」。理解這點後，你會明白為什麼「沒見過的庫」需要提供 docs，以及為什麼提供 docs 不會永久增強 model 能力。這是許多用戶誤解的盲點。 **精讀段 2：Effort 的實際影響（第 96-106 行）** > 「Same prompt, two effort levels. The high effort path generates roughly 7x more tokens to reach a higher confidence answer.」 > > 「When step 1 of a three-hypothesis debugging plan finds the bug, 'investigate hypotheses 2 and 3' may no longer be necessary. Claude will usually say this explicitly (e.g. 'the first check found it, so the remaining checks aren't needed') and skip ahead. You see this happen in Claude Code when task lists get revised mid-run.」 **推薦理由**：這段挑戰了「高 Effort = 想更久」的直覺——實際上是「做更多事」，而且「會動態調整」。理解「計畫不是凍結的」這點後，你會期待 Claude 在高 Effort 下「中途修正計畫」，而不是死板執行原始步驟。這是觀察 Claude 行為的重要指標。 **精讀段 3：診斷流程（第 118-140 行）** > 「When Claude gets something wrong, your first instinct shouldn't be to change a setting. It should be to look at the context you gave it. Is your prompt too vague? Is Claude connected to the right tools? Does it have the right skills?」 > > 「Pick a larger model when the problem is genuinely hard, like subtle bugs, unfamiliar domains, architecture decisions. A larger model is what you want when the smaller model is confidently wrong no matter how much context you give it.」 **推薦理由**：這段提供了「診斷優先順序」——先 context，再設定。許多用戶一看到錯誤就「換最大的 Model」，但這段教導「context 完整仍失敗」才考慮換 Model。同時區分「不知道」（Model 問題）vs「不夠努力」（Effort 問題）的診斷框架，是實務上最有用的決策樹。 ## STRUCTURE MAP | 全書結構圖（ASCII） ``` Model & Effort in Claude Code ├─ Part 1: Core Concepts │ ├─ Model = Capability (weights, read-only after training) │ │ ├─ Tokenization flow │ │ ├─ Weights as frozen knowledge base │ │ └─ Inference as matrix multiplication │ └─ Effort = Thoroughness (token quantity, not time) │ ├─ Categories: Thinking / Tool calls / Text to you │ └─ Effort as input prompt → learned behavior │ ├─ Part 2: Selection Guide │ ├─ Model Selection │ │ ├─ Larger model: subtle bugs, unfamiliar domains, architecture │ │ ├─ Smaller model: routine edits, mechanical changes │ │ └─ Diagnostic: confidently wrong = model problem │ └─ Effort Selection │ ├─ Default for most tasks │ ├─ Higher effort: skipped verification, incomplete investigation │ └─ Diagnostic: didn't try hard enough = effort problem │ ├─ Part 3: Expert Metaphor │ ├─ Fable = Specialist (hardest problems, highest cost) │ ├─ Opus = Expert (deep experience, architecture decisions) │ └─ Sonnet = Generalist (routine work, whole afternoon available) │ ├─ Part 4: Token Economics │ ├─ Routine work: smaller model wins (less verification overhead) │ ├─ Hard work: larger model can win (fewer steps to quality) │ └─ Fable premium: save for work that truly needs it │ └─ Part 5: Diagnostic Flow ├─ First: Check context (prompt, tools, skills, verification) ├─ If context OK: Diagnose failure type │ ├─ Not knowing enough → Change Model │ └─ Not trying hard enough → Change Effort └─ Practical: Default effort usually sufficient ``` --- # Model and effort in Claude Code: knowing more vs. trying harder (Architectural Deep Dive) ## 前言/背景 Claude Code 提供兩個看似都能「讓答案更好」的設定：**Model（模型）**與 **Effort（努力程度）**。但這兩者實際上如何影響輸出？什麼時候應該換模型，什麼時候只是調整努力程度？常見的直覺假設是： - 選擇更大的模型（如 Fable）會得到更聰明的輸出； - 更高的努力程度只是讓 Claude 想更久才回答。第一個假設是正確的——我們最大的模型在業界標準基準測試中**更強**。但努力不僅是「思考時間」——它控制 **Claude 在你的請求上做多少工作**，包括： - 讀取多少檔案； - 做多少驗證； - 在多步驟任務中推進多遠才回報。高努力時，Claude 會執行更多動作（讀檔、跑測試、雙重檢查）才回報。低努力時，它寧可詢問你更多 context，自己花 token 推演。 ![Image](https://pbs.twimg.com/media/HMp7c2RbkAAVN7X?format=jpg&name=large) ## 章節詳細總結 ### How model selection works（模型選擇運作原理）要理解 Model 設定實際控制什麼，最好從按下 Enter 的那一刻開始。 Claude Code 將你的訊息與 system prompt、tool definitions、CLAUDE.md、對話歷史、context 中的檔案組裝在一起。所有這些作為一個 API 請求送出。 **在伺服器端，文字在到達 model 之前會先被 tokenization**——文字被分割成片段，每個片段映射到模型訓練時的固定詞彙表中的整數。`const` 可能映射到 1978，`await` 可能映射到 4293。從這裡開始，**你的 prompt 是一個整數陣列**。 ![Image](https://pbs.twimg.com/media/HMp7pYKbAAA_X1F?format=jpg&name=large) tokenizer 將文字分割並映射到詞彙表中的整數。上排每個區塊變成其 token ID（下排）；顯示的 ID 是範例。 **Model 的工作是接收該陣列並預測下一個 token**。它計算詞彙表中每個 token 的機率並從頂部選擇。在 `"const x = await"` 之後，訓練良好的 model 會對 `"fetch"` 給高機率（非常可能），對 `"banana"` 給近乎零機率（完全不可能）。 ![Image](https://pbs.twimg.com/media/HMp70iMa8AECvcq?format=jpg&name=large) model 的預測是詞彙表中每個 token 的機率。最佳猜測與無關 token 之間的差距巨大。將輸入 tokens 轉化為這些機率的是 **weights（也稱 parameters）**：以矩陣形式組織的數十億數字。要預測一個 token，model 將你的輸入通過這些矩陣（一長串矩陣乘法）並在末端讀取機率。**weights 是 model 「知道」的一切的所在**。每個 model 的 weights 在訓練期間設定，到你發送請求時**它們是唯讀的**。你的 prompt、CLAUDE.md 或 context 都不會改變它們。如果你聽過 **inference** 這個詞，就是這個意思：在訓練完成後使用 model，weights 固定。 ![Image](https://pbs.twimg.com/media/HMp77BfaQAAuYPa?format=jpg&name=large) 你的 prompt 進去，機率出來。中間的 weights 不改變。 **Claude 知道的所有 TypeScript、熱門框架或任何通用程設知識，都在訓練時編碼到這些 weights 中**。你的 prompt 和 context 仍可引導預測。將真實程式碼放在 Claude 面前就是引導，而且效果很好。但這不會增加任何東西到 weights 本身。如果一個庫在 model 訓練時不存在，它就不在 weights 中。你可以將 docs 放在 context，Claude 會使用它們，但這是**引導，不是教學**。Claude 的回應只影響該次請求，底層 model 沒有保留任何東西。當 Claude 自信地呼叫一個不存在的 API（幻覺），那是 weights 產生一個從訓練模式看來合理的 token 序列，不是查詢失敗。 **所以改變 model 實際做什麼？它交換哪一組凍結 weights 處理你的請求**。 model 不會一次生成整個答案。它預測一個 token，將其附加到序列，然後再次運行整個計算以取得下一個。200 token 的回應是通過 weights 的 200 次獨立傳遞。這個循環是你大部分等待時間（和輸出成本）的來源。 ![Image](https://pbs.twimg.com/media/HMp8BjeaMAAhSeb?format=jpg&name=large) 序列每步增長一個 token。model 每次重新讀取整個陣列以預測下一個。 **Model 設定決定哪些 weights 處理你的請求，也決定每個輸出 token 的成本**。它不決定的是**生成多少 token**。這個數字對相同 prompt 可能差異很大，取決於 Claude 決定做多少工作。這正是 Effort 控制的。 ### How effort works（努力運作原理）當 Claude Code 工作於任務時，它生成的 tokens 分為幾類： - **Thinking（思考）**：你在動作前和動作間看到的串流推理。 - **Tool calls（工具呼叫）**：命名工具如 Read 或 Edit 及其參數的結構化區塊，Claude Code 會解析並執行。 - **Text to you（給你的文字）**：計畫、進度更新、結尾的摘要。這些都是同一個循環的普通輸出 tokens，以相同費率計費。思考 tokens 的生成方式與其他輸出 tokens 完全相同，並在該回合的剩餘時間留在 context 中。當 Claude 移到寫程式碼時，它早先的推理已成為輸入的一部分，就像它讀取的檔案。 ![Image](https://pbs.twimg.com/media/HMp8IlTa8AA3yea?format=jpg&name=large) Claude 的所有輸出都是 tokens。思考、工具呼叫、給你的文字都從同一循環生成。 **那 Effort 如何改變這些？Effort 等級是作為請求的一部分發給 model**，就在你的 prompt 旁邊。model 被訓練成理解如何在每個 Effort 等級下行為，那學到的行為被烘焙到凍結的 weights 中。當你的請求到達，Effort 只是 model 回應的另一個輸入，就像它回應你的 prompt 文字。它設定 Claude 在認為任務完成前需要多徹底、多確定。這在每回合都被衡量，更高信心需要更多 tokens 才能達到。 ![Image](https://pbs.twimg.com/media/HMp8OpFa0AAXQK4?format=jpg&name=large) 相同 prompt，兩個 Effort 等級。高 Effort 路徑生成約 7x tokens 以達到更高信心答案。在高 Effort 等級，Claude 通常先建立計畫，Effort 等級影響計畫的深度與廣度。但計畫不是凍結的。當 Claude 從動作取回結果，它會更新它對「做了多少進展」與「累積結果的確定度」的畫面。當三假設除錯計畫的步驟 1 找到 bug，「調查假設 2 和 3」可能不再必要。Claude 通常會明確說這點（例如「第一次檢查找到了，所以剩餘檢查不需要」）並跳過。你會在 Claude Code 中看到這發生——任務列表中途被修訂。高 Effort 確實讓 Claude 更可能雙重檢查，例如驗證找到的答案，或仍調查它可跳過的假設。然而，它通常不會只因 Effort 調高就人為膨脹簡單任務的使用量。「Overthinking」是我們團隊在 model 訓練時特別注意的，因為它會降低效果。 ### Picking an effort level（選擇 Effort 等級）對大多數任務，**使用 model 的預設 Effort 等級**。預設是 Claude 將 token 使用量調整到大多數人在任務上願意花費的等級。將 Effort 視為 Claude 工作多努力、多長時間的手動覆寫。當你對徹底度或速度有強烈偏好（基於你的領域或工作類型）時刻意使用，將其視為通用偏好，而非逐任務決策。 Opus 4.8 發布後的一個實務註記：在我們測試中，Opus 4.8 的預設 Effort 在相同任務上產生比 Opus 4.7 預設 Effort 更好的結果，且 token 量大約相同。 ### What to change when Claude gets it wrong（Claude 搞砸時改什麼）當 Claude 搞砸時，你的第一直覺不應該是改設定。應該是看你給它的 context。你的 prompt 太模糊嗎？Claude 連到正確工具嗎？它有正確 skills 嗎？如果你在不該需要高 Effort 的任務上提高 Effort，修通常在上游：你的 context、CLAUDE.md，或任務範圍。但假設你給了明確 context 且 Claude 仍搞砸。該問自己：**是它不夠努力，還是它不知道？** ![Image](https://pbs.twimg.com/media/HMp8Xd_aIAAMi_7?format=jpg&name=large) **Model：問題太難** 選更大 model 當問題真正困難，如微妙 bug、陌生領域、架構決策。當小 model 不管給多少 context 都自信地錯時，大 model 是你要的。大 model 也更擅長處理模糊性。在小 model 上，指向執行的具體指令是更成功的配方。選更小 model 當工作是常規：你可精確描述的編輯、機械性變更、已在 context 中的程式碼問題。沒理由為任務不需要的能力付費。如果 Claude 有所有相關 context，明確嘗試過，仍搞砸；這是換大 model 的信號。如果你在大 model 上且工作常規一陣子，降級會提升速度並通常降低成本而不影響輸出品質。 **Effort：Claude 不夠努力** 選更高 Effort 等級如果 Claude 因不夠努力而做錯：跳過檔案、不跑測試、不雙重檢查工作。這最相關於如果你選了低於 model 預設的 Effort 等級。 ### The specialist, the expert, and the generalist（專家、高手、通才）我喜歡將兩個設定想成：Fable 是能處理幾乎無人能解問題的專家，Opus 是高手，Sonnet 是很棒的通才。Effort 等級決定他們花多少時間在你任務上。 Opus 低 Effort 像得到高手 5 分鐘——他們對像你這類問題有深層經驗。他們帶來你程式庫中沒有的知識；他們看過的模式、他們知道要檢查的 gotcha、只有解過很多類似問題才得到的經驗。但 5 分鐘意味快速讀你的程式碼，不是仔細通過每個檔案。 Sonnet 高 Effort 是有一下午的通才。他們擅長寫程式，會讀所有東西、執行、雙重檢查工作，最後徹底理解你的特定程式碼。 Fable 是你叫其他人卡住時的專家。即使低 Effort，他們會發現沒人會發現的事。那認知也是你付最多費的，所以值得保留給真正需要的任務。 **沒有一個普遍「更好」**。Model 設定大約是**多能**；Effort 設定大約是**多徹底**。大多數真實任務需要兩者的一些。 ### Effort, model, and token consumption（Effort、Model 與 Token 消耗）那麼 Model 選擇、Effort、Token 消耗如何互動？看任務而定。 **在相同 Effort 的常規工作**，大、小 model 通常都對。大 model 用額外驗證步驟消耗更多 tokens，且每 token 價格更高。這就是常規 stretch 降到小 model 省真錢又不犧牲品質的原因。 ![Image](https://pbs.twimg.com/media/HMp9BhXawAA7MjW?format=jpg&name=large) 曲線僅供說明，顯示單一任務簡單到兩個模型都能快速完成。不代表真實基準數據。 **在困難、多步驟工作**，公式翻轉。小 model 必須磨到能力極限，燃燒迭代，而大 model 用更少步數達到相同品質門檻。你為大 model 每個 token 付更多，但在真正拉伸小 model 的任務上，每任務總成本可能更低。更重要的是：大 model 能完成小 model 不能的任務，即使最高 Effort 設定。這在 Fable 最明顯。在長、多步驟工作，它拉得最領先。在我們測試中，它完成了 Opus 和 Sonnet 在任何 Effort 都达不到的工作。它也每 token 成本最高，這是為真正需要的工作保留它的另一個原因。 ![Image](https://pbs.twimg.com/media/HMp9IOba4AArT7v?format=jpg&name=large) 曲線僅供說明，顯示單一任務困難到兩個模型都被拉伸。不代表真實基準數據。上方圖表的關鍵點：Effort 選擇 Claude 願意沿曲線走多遠。這不代表 Claude 需要走那麼遠完成任務。最後，Effort 塑造 token 消耗，但不限制它。系統中唯一硬上限是 [max_tokens](https://platform.claude.com/docs/en/build-with-claude/extended-thinking#max-tokens-and-context-window-size-with-extended-thinking)，它會在命中時中斷回應，但它是鈍器具且主要與 API 開發者相關。像 [task budgets](https://platform.claude.com/docs/en/build-with-claude/task-budgets#task-budgets-are-advisory-not-enforced) 或在 prompt 中要求 Claude 簡潔這類軟控制更有幫助。它們是 model 被訓練遵循的引導（它會在接近上限時嘗試收尾），不是它撞到的牆。 **Effort 改變 Claude 做多少工作。Model 改變 Claude 知道什麼**。當你對結果不滿，碰任何設定前先檢查 context：給 Claude 明確 prompt、正確工具與 skills、驗證自己工作的方法。如果 Claude 仍搞砸，問自己：是它不知道，還是它不夠努力？不知道是 Model 問題，不夠努力是 Effort 問題。 ## 總結與結論（3-5 點） 1. **Model 控制能力上限，Effort 控制工作深度**：Model 決定使用哪組凍結 weights（知識庫），Effort 決定在做請求時的工作量（讀檔數、驗證度、執行步數）。 2. **診斷優先順序**：Claude 搞砸時先查 context（prompt、tools、skills、verification），再診斷「不知道」（Model 問題）vs「不夠努力」（Effort 問題）。 3. **Token 經濟學**：常規任務小模型省錢不犧牲品質；困難任務大模型雖單 token 貴，但總成本可能更低（更少步數達品質門檻）。 4. **Effort 的動態特性**：高 Effort 不是「想更久」，而是「做更多事」，且計畫會動態調整（找到 bug 後跳過剩餘假設）。 5. **比喻總結**：Fable＝專家（最深坑任務），Opus＝高手（架構、微妙 bug），Sonnet＝通才（常規編輯）；Effort＝給他們的時間。 --- 本文作者：[@lydiahallie](https://x.com/@lydiahallie)，Claude Code 團隊技術成員。

🌟 今日領域總結 (Domain Summaries)

AI工具 總結報告

AI工程 總結報告

AI模型 總結報告

AI視野 總結報告

Agent架構 總結報告

實戰教學 總結報告

工作方法 總結報告

工作流 總結報告

知識管理 總結報告

系統架構 總結報告

認知框架 總結報告

開發工具 總結報告

📚 文章摘要列表 (Articles)

Model and effort in Claude Code: knowing more vs. trying harder（模型與努力：Claude Code 中的知識更多與更努力）

Run Qwen3–235B on a 16 GB Mac mini: 1.58-bit Ternary Quantization with TurboQuant-MLX（在 16 GB Mac mini 上運行 Qwen3–235B：以 TurboQuant-MLX 進行 1.58-bit 三值量化）

Your KV Caching Is Broken（你的 KV Cache 壞了）

私有知识库从 demo 到生产，中间差了 8 层工程（私有知識庫從 demo 到生產，中間差了 8 層工程）

角色重构——工程师从「写代码的人」变成「编排 Agent 的人」

Distillation in 2026 (so far): which frontier models use it and how（2026 年蒸餾技術現況：哪些前沿模型在用、怎麼用）

The Two Clocks（兩座時鐘：AI 能力與機構吸收的結構性落差）

A Taxonomy of Self-evolving Agents（自演化代理的分類學）

AI = LLM + Harness：Agent Harness 到底做了什麼（以及我如何用 AI 打造一個）

BestBlogs 早報 · 07-09｜連續語音、長任務模型、本地小模型，把 AI 帶進真實工作流

Bilevel Autoresearch: Meta-Autoresearching Itself（雙層自動研究：對自身進行元自動研究）

Build a Taste Index with Hermes and GBrain（用 Hermes 與 GBrain 打造品味索引）

Building a Moat: Self Learning Agents（自學習 Agent 與企業護城河）

Own the Outer Loop（擁有外迴圈）

Your Agent Memory Probably Needs an Ontology — Just Not the One You Think（你的 Agent 記憶體可能需要一個 Ontology——只是不是你想的那種）

一文講清楚，普通人與中小企業如何搭建 AI 知識庫

Fable 5 高手都在做同一件事：动手前先找到自己的盲区

You're not ambitious enough with Claude（你對 Claude 的企圖心還不夠）

我把和AI的所有对话，都存进了自己的知识库

Infra 和 AI

To learn anything, first unlearn school（想學任何事，先忘掉學校教的那一套）

當納德拉也開始講 Loop，這個詞終於長出了第三層

CodeGraph: The Open-Source Knowledge Graph That Makes AI Coding Tools Dramatically Cheaper（CodeGraph：讓 AI 程式開發工具大幅降本的開源知識圖譜）

AI工具總結報告

AI工程總結報告

AI模型總結報告

AI視野總結報告

Agent架構總結報告

實戰教學總結報告

工作方法總結報告

工作流總結報告

知識管理總結報告

系統架構總結報告

認知框架總結報告

開發工具總結報告