TL;DR: Coding agent 讓重做 PR 的成本下降，但錯誤架構一旦進入 main，就會變成新的 caller、data、operations 和團隊認知共同依賴的 constraint。當 outcome、contract 和 behavioral tests 已經確定，第一版最值得保留的往往是它找出的 knowledge，implementation 可以重新選擇。Code review 的標準沒有改；我們只是更不需要因為「code 都寫完了」而對不好的 architecture 妥協。

最近我 review 一支改動 routing state 的 PR。

這個 state 決定一個 request 接下來要走哪一條處理路徑。我原本以為，最前面應該有一個 gate 讀取目前 state、做出 decision，後面的流程只要接受結果。打開 PR 後，我卻看到相同的 state checking 出現在三類地方：即時 API 入口會判斷一次，延後執行的 worker 會再判斷一次，提供 operational view 的 read path 又有自己的版本。每條 flow 還各自長了一點例外。

這不是「哪個 function 還能再抽乾淨一點」的問題。Decision 的 ownership 已經散掉了。之後每增加一條入口，都得記得把同一套規則再複製過去；規則改變時，也得相信每個地方都有人一起改到。

我可以沿著現有 shape 列出一串 incremental fixes，把這支 PR 修到能 merge。跟同事討論過後，我請他保留相同 outcome，從乾淨的 base 重做。

這個決定放在幾年前、同樣有時程壓力的情況下，大概不會發生。

Merge 會把 Implementation 變成全團隊的 Constraint

PR 裡的 code 還是局部 artifact。它有明確邊界，可以整支關掉、重做，或在沒有 live migration 的情況下換掉 data flow。

Merge 是一次 state transition。

進入 main 後，其他 branch 會從它往前開發，新的 caller 會依賴它。等這個版本部署，資料開始按它的 representation 被寫入，tests、文件、metrics 和 operational procedure 也會逐漸把它當成既定事實。工程師學到的不只是「功能怎麼用」，還包含出問題時要去哪幾個入口找那份散落的判斷。

以開場的例子來說，今天有三類入口各自解讀 state，明天新增第四條 flow 時，最自然的做法就是照著前三個地方再加一次。等規則改變，團隊要修改的已經不是一個 decision owner，而是一份持續增長的搜尋清單。即使交給 coding agent 搜尋，它也可能遇到動態呼叫、歷史例外、命名不一致，或根本不知道某個外部 contract 也依賴同一個語意。

這就是 Main 仍然昂貴的地方。每個新功能都得理解並延續現有 shape，internal representation 逐漸變成 compatibility 與 migration contract，workaround 也會被後來的 caller 當成正常用法。Debugging、on-call 與 recovery 必須重建散落在多處的 causal chain；真的要 refactor 時，還得協調 live data、rollout 順序和其他正在進行的工作。

Coding agent 可以幫忙執行這些修改，無法讓已經形成的依賴、歷史與 blast radius 自動消失。Code generation 變快，不會讓 production state 變得可逆，也不會同時生出更多擁有完整 context、權限與責任的人。

當時更常見的做法，是先把 PR 修到能 merge，再開一張 refactoring task。只要待過工程團隊，大概都知道那張 task 後來會怎樣：產品需求和客戶問題持續進來，它就一直往後排，直到散落的邏輯又被複製幾次、大家真的受不了才處理。Main 的成本不只沒有消失，還會在等待期間繼續長大。

Coding Agent 改變了 Rewrite 的成本

以前要求重做一支 PR，可能代表工程師再花幾天重新建立 context、實作已經踩過一次的 edge cases。即使 reviewer 知道 architecture 不理想，也很容易被時程和 sunk cost 推向 incremental fixes。

現在 outcome、constraints 和 tests 都可以直接交給 coding agent。它不必重新猜題，可以在同一個 acceptance boundary 裡探索另一種 ownership、representation 或 state model。Implementation 仍然有成本，只是相對容易重新產生。

Coding agent 時代，PR 發出來之後，我們反而更有條件重新做一次 architecture review。第一版 implementation 把真正的 caller、transaction boundary 和 state propagation 攤開，reviewer 不必只根據 plan 猜哪個 shape 比較乾淨；可以沿著實際 flow 驗證 decision ownership 散在哪裡，也能判斷另一個 architecture 是否真的成立。

第二版把 state rule 收回單一的 policy source 和 canonical resolver。即時 API 和延後執行的 worker 仍然保留各自的 transaction、lock 與 side effects，但都在真正要執行時讀取 current state，交給同一個 resolver 做 decision；operational read path 不再維護另一份 policy，只從相同 source of truth 投影結果。之後新增第四條 flow，要接的是同一份 contract，而不是再實作一次 precedence。

這次從 agent 開始讀 repo，到完成 implementation、backend / frontend validation、fresh-context review、修正 4 個 race condition 與 projection 相關問題，再跑完 revalidation，總 wall-clock 約 98 分鐘。這個數字不能證明總交付時間一定更短；它證明的是，當 outcome 和 guardrails 已經固定，bounded rewrite 可以在一次完整的 agent run 裡做到可 review 的狀態。

第二版一樣要做 full review。Tests 可以縮小「行為是否退步」的 uncertainty，不能替 reviewer 判斷新的 ownership 是否正確、concurrency 是否安全、migration 是否成立，也不能幫團隊承擔 production outcome。有一段時間，reviewer 甚至得同時理解第一版的問題與第二版的取捨，validation cost 可能更高。

稀缺資源正在從 code production 移到 judgment。

這也是先做 architecture review 的理由。既然 line-level code 可以重新產生，就不要把最有限的 reviewer attention 全花在錯誤 shape 裡的 naming、local abstraction 和補洞。先判斷多個 findings 是獨立 mistakes，還是同一個 structural root cause 的症狀；shape 成立，再進入一般 implementation review。

第一版 PR 最值得保留的，可能不是 Code

要求重做一支 PR，聽起來像把前面的工作全部丟掉。但這支 PR 已經完成一件很重要的事：它把模糊需求變成具體 contract。

第一版 implementation 找出了真正會經過哪些入口、有哪些 edge cases、失敗時應該發生什麼，也留下了相對完整的 tests。這些 learning 不需要跟原本的 architecture 綁在一起。

保留：
- outcome
- constraints
- edge cases
- behavioral tests

重新選擇：
- ownership
- boundary
- state model
- implementation

這次我敢讓另一個 coding agent 從頭重做，很大的原因是原本 PR 已經有 tests。只要這組 behavioral tests 不修改，第二版就必須維持已經定義好的行為。Ownership、state model 和 internal data flow 可以換，outcome 不能偷偷跟著換。

Tests 應該讓 implementation 更容易被替換。

最需要防的是 code 和 tests 都由同一個 agent 從同一份誤解產生。兩邊完全一致，整套 suite 仍然可能很綠。Tests 要形成 guardrail，就得錨在 externally observable behavior 和獨立確認過的 contract，而不是第一版的 internal helper 或資料模型。Unchanged tests 能證明第二版沒有偏離這些已記錄的 behavior，不能單獨證明 contract 本身正確。

要求別人重做，仍然是一個社交決定

如果 PR 是同事寫的，「這個方向不要再補，請重做」從來不只是一個技術決定。對作者來說，那可能像是否定已經投入的工作。Coding agent 降低了重新生 code 的時間，沒有自動降低這段對話的溝通成本。

Reviewer 如果只說「我比較喜歡另一個架構」，很容易把權力差異包裝成 technical judgment。提出 rewrite 時，必須說清楚哪個 correctness、ownership、data flow 或 failure mode 無法可靠成立，為什麼 local patches 會繼續增加 duplicated truth，以及 feasible alternative 的 decision owner 和 boundary 大致在哪。

同時也要講明第一版已經釐清的 contract、tests 和其他工作會如何保留，第二版又要用什麼 observable behavior 證明沒有退步。要求作者放棄 implementation，reviewer 就有責任證明那些已經完成的 knowledge 不會一起被丟掉。

這樣才把第一版 PR 放回比較公平的位置。它可能選錯 architecture，仍然替團隊找出了需求、edge cases 和 guardrails。Reviewer 要替換的是不適合進入 main 的 shape，不是抹掉作者已經完成的所有工作。

先判斷 Architecture 是否成立

Code review 的標準沒有因為 coding agent 出現而改變。邏輯是否集中、source of truth 是否清楚、ownership 是否恰當，本來就是 review code 的內容。變的是，bounded rewrite 現在更常是一個現實選項。

Review 一支非瑣碎 PR 時，我會先問：

1. 這些 findings 是獨立 mistakes，還是同一個 root cause 的不同症狀？ 如果每個修正都在替相同的 ownership 或 state model 補洞，先停下 line-level review。
2. 目前的 source of truth 和 decision owner 在哪？ 新增下一條入口時，能自然共用它，還是必須再複製一份規則？
3. Outcome 與 contract 是否有獨立 guardrail？ Tests 有沒有測 externally observable behavior，而不只是重複 implementation 的假設？
4. 有沒有 bounded alternative？ Keep and fix 仍然是一個選項；只有 structural root cause 真的成立，才需要 eliminate state、move ownership、change representation 或重做 coherent slice。

如果現有 architecture 成立，就做 incremental fixes。Diff 很大、設計不漂亮、reviewer 想到另一種 pattern，都不是重做的理由。

如果 shape 無法可靠維持必要 invariant，而且 local fixes 只會讓問題繼續 propagate，就不要因為 code 已經寫完了而假裝 architecture decision 已經結束。

最好的 Rewrite，是不要等到 Review 才發生

這個結論不代表團隊應該常常重寫 PR。Architecture judgment 應該往前移，但不會在 plan approval 時結束。

Plan 階段先定 source of truth、ownership、state transition 和不能破壞的 invariant。這些問題到 review 才第一次被釐清，是前期 decision 沒做好。真實 caller 分布、transaction boundary，以及 state 實際怎麼穿過不同 flow，往往要等 implementation 才會完整攤開；它們在 review 才浮現很正常，review 本來就應該拿 implementation evidence 再驗一次 architecture。

這也接回我在〈AI Coding Workflow 裡，人類該 Review Plan 還是 Evidence？〉的主張：routine、可逆、容易驗證的 task，不一定要先讓人類 approve implementation plan；但 architecture-heavy、data contract 會分岔，或走錯方向會讓整份 diff 作廢的工作，正是應該先停在 decision boundary 的類型。先把 plan 階段能確定的 decision 講清楚，再讓 agent 大量生 code；等 implementation 出來，再檢查那些 assumptions 是否真的成立。

目標不是零 rewrite，而是不要為了本來就該事先想清楚的事情 rewrite。真的到 review 才看出新的 structural root cause，也不要把今天做得到的 bounded rewrite，換成一張永遠不會被撿回來的 refactoring task。

TL;DR: 我現在不再把「先寫 plan、等我 approve、再開始 implementation」當成每個 AI coding task 的預設。Routine、可逆、容易驗證的工作，我會先講清楚結果、不能破壞的東西和驗證方式，讓 agent 做完，再 review diff 與 evidence。高風險、不可逆、architecture-heavy 或需求模糊的工作，仍然先看 plan。Agent 還是要規劃；人類不一定每次都要先看。

最近我在一個公開的 Agent Skill eval PR 裡，要求建立一套可重現、可稽核，而且只有 evidence 足夠時才能 claim-ready 的比較流程。

第一版改了 27 個檔案，兩個 GitHub checks 都是綠的，本機 npm run validate 也通過。表面上已經可以交付。

Fresh-context review 後，我們才發現，manifest 雖然記錄了 reasoning_effort，實際執行 Codex 時根本沒有套用；independent-review.json 也沒有綁定最後用來形成結論的 benchmark.json。Artifact 寫的是一種執行方式，command 跑的卻是另一種。Independent review 看完之後如果 benchmark 被換掉，verifier 也看不出來。

先 review 一份 implementation plan，抓不到這個錯。Plan 可以寫「config 會被套用」「review 會綁定 benchmark」，但只有實際 command、artifact binding 和 regression tests 能證明它真的發生。

這件事讓我把兩個問題分開：agent 要不要先規劃？人類要不要在 implementation 前先看那份 plan？

Non-trivial task 當然需要規劃。但如果主要風險藏在實際執行結果裡，先看一份寫得很合理的 plan，不一定能幫你抓到它。

為什麼以前習慣先看 plan

2024–2025 年，兩個有代表性的 AI coding 產品，都把 implementation plan 放在人類開始 review 的位置。

GitHub 在 2024 年介紹 Copilot Workspace時，Workspace 會從 task 產生可編輯的 step-by-step plan；使用者確認後，才執行 code。Cline 的 Plan / Act也是先在 Plan Mode 對齊 strategy，再切到 Act Mode 執行。直到現在，Cline 的文件仍建議 medium tasks 先 Plan 再 Act，large tasks 使用 /deep-planning；只有 typo、missing import、config value 這類小改動，才建議直接 Act。

這個 workflow 很合理。人類可以在 code 出現以前，先抓需求誤解、漏掉的檔案和錯的 architecture direction。對 migration、權限、billing、資料刪除這類工作，十行 plan 走錯，比八百行 diff 走錯便宜很多。

但 agent 在實作時會繼續讀 repo、跑 tests、根據結果改做法。開始前那份 plan，有時只是它還沒真正完整探索 repo 以前的猜測。你把每一步都先定死，可能只是在 review 一份很快就過期的文件。

新 guidance 開始把重點放在結果

截至 2026 年 8 月，OpenAI 的 GPT-5.6 model guidance建議把 underlying goal、相關 context、hard constraints、success criteria 和 required evidence 說清楚。模型已經更能從 context 推斷目標，使用者通常不需要把每一步都指定好。

Anthropic 對 Claude Opus 5 的 prompting guidance也建議先給完整的 task specification，再讓 model 跑完整個 task。對範圍清楚的工作，model 可以自己做 routine judgment；只有不同解讀會導致明顯不同的結果時，才需要回來確認。

這些 guidance 沒有把 plan-first 拿掉。Claude Code best practices至今仍保留 explore → plan → implement → commit，也建議用 Plan Mode 編輯 implementation plan。兩種 workflow 正在同一批產品裡並存。

我的使用方式也在往同一個方向變：我越來越少指定 implementation steps，越來越常指定完成後要成立的結果。

我現在怎麼下 routine coding task

我現在下 routine coding task，會先講清楚五件事：

1. Outcome：完成後，使用者或 system 要看見什麼變化。
2. Context：相關 repo、caller、既有 pattern 或 decision。
3. Constraints：哪些 invariant 不能破壞、哪些檔案或 layer 不要碰、scope 大到什麼程度要停，以及哪些條件不成立就不能進入 claim-ready、merge 或 deploy。
4. Success criteria：哪些條件成立才算完成。
5. Evidence：最後要交回哪些 command、結果、screenshots 和 remaining unknowns，以及別人要怎麼重跑。

然後讓 agent 自己選 implementation path。

這跟「你自己看著辦」差很多。我沒有少給資訊，只是把注意力從「每一步要怎麼寫」移到「最後什麼必須成立」。

可以直接從這個 template 開始：

Outcome:
- [完成後可觀察到的行為]

Context:
- [repo / caller / existing pattern / relevant decision]

Constraints:
- Preserve: [invariants / compatibility]
- Do not touch: [out-of-scope surfaces]
- Stop if: [unexpected scope / diff threshold / material ambiguity]
- Block until: [conditions required before claim-ready / merge / deploy]

Success criteria:
- [deterministic checks or acceptance conditions]

Return evidence:
- [diff scope, commands and results, screenshots, remaining unknowns]
- Reproducible by: [CI / hook / exact command anyone can rerun]
- Not yet verified: [checks that still depend on agent-run output]

Plan 沒有過時，只是不必每次先看

Routine、可逆、容易驗證的工作，我會讓 agent 做完，再 review final diff 和 evidence。例如小範圍 refactor、明確的 bug fix、補 tests，通常不需要先開一個 plan review round。

需求有多種合理解讀、會改 architecture 或 data contract、變更不可逆，或走錯方向會讓大量 code 作廢時，我還是先看 plan。有時不需要完整 implementation plan，只要先停在那個會改變方向的 decision。

差別不是少 review。差別是把 review 放在最容易抓到主要風險的地方。

這個選擇也會把一部分成本往後移。如果 agent 寫到八百行才發現需求理解錯了，整份 diff 都可能作廢。

Plan review 擅長提早抓錯方向。Diff review 擅長看 implementation 有沒有越界。Tests、CI 和其他 evidence 擅長確認結果有沒有成立。沒有哪一種可以代替另外兩種。

Agent 說 tests passed，還不算完成

Agent 回報 tests passed，只代表它說自己跑過 tests。Tests 可能被改弱，command 可能沒有套到你以為的 config，artifact 也可能沒有綁到最後的結果。

這跟我在〈Agent Skill Eval 最危險的假陽性〉講的是同一種錯：一個綠色勾勾只證明某一層通過，不能替其他層補故事。

Routine、可逆的工作，我可以先把 agent-run output 當成低成本訊號。但要交付，至少讓 CI、deterministic hook 或任何人都能執行的 exact command，在同一個 revision 重跑。涉及 user behavior、security、migration 或 production state，就再加 browser check、fresh-context review 或真實環境驗證。

開場那個 PR 最後補了兩條規則：宣告的 model config 沒有真的生效，就不得 claim-ready；independent review 必須用 SHA-256 綁定它看過的 benchmark artifact。這兩條都有 regression tests。

這些問題，plan 寫得再漂亮也不會自己消失。

下一個 task，先問三個問題

1. 做錯了，能不能很快回復？ 不能，就先看 plan。
2. 做對了，有沒有獨立的 pass / fail signal？ 沒有，就先建立 test、fixture 或其他驗證方式；做不到，就把 human diff review 當成必要成本。
3. 不同解讀，會不會導向不同的 architecture、data contract 或 user behavior？ 會，就先對齊 decision，必要時再展開 plan。

三個答案都指向低風險，就讓 agent 做完再看結果。

下一次不必先問 agent 要不要 plan。它多半需要。

真正要問的是：你需不需要在它開始以前先看那份 plan？

TL;DR: Final outcome pass 只能證明這次任務做完，不能證明 agent 有選到 Skill、讀過完整 instructions，更不能證明結果是 Skill 帶來的。這篇說的假陽性，是任務明明只是做完了，我們卻把它當成 Skill 有用的證據。沒有拿完整 Skill 跟一段同目標的簡短 instruction 比過，你就不知道多出來的 complexity 到底值不值得。

我在對自己寫的 Agent Skill 跑 evaluation 的時候，用 Codex 還有 Claude Code 跑同一個 Code Review Skill。兩邊都交出了可用的 review 結果。

Codex 的 JSONL trace 很直接：它真的讀了 project-local review-code/SKILL.md。Claude 的 init 資訊只讓我知道這個 Skill 有出現在 available skills 清單裡；一般 prompt 的那次 run，沒有留下我看得懂的 invocation event。另一個測試裡，我直接指定 Claude / Haiku 使用這個 Skill，輸出就有遵守 severity、confidence 與 type 格式。

我沒辦法從這段 trace 判斷 Claude 到底有沒有讀到 Skill，也沒辦法拿這次結果比較 Codex 和 Claude 誰的 routing 比較好。真正讓我在意的是：兩邊都 pass，但我能確定的事情完全不一樣。

如果 eval dashboard 最後只留下一個綠色勾勾，這個差異就消失了。然後我們很容易替那個 pass 補上一段 eval 從未證明的故事：Skill 被找到、被選中、被讀取，最後讓答案變好。

一個綠色勾勾，壓扁了五個問題

Agent Skill 從出現在系統裡，到最後真的把事情做好，中間至少有五層：

OpenAI 的 Skills 文件把「直接指定 Skill」和「讓 agent 自己選」分開。ChatGPT 與 Codex 會先看到 Skill 的 name、description，決定要用之後才載入完整 SKILL.md。Agent Skills 的 description eval 指南也建議拿真的會觸發、差一點會誤觸發的 prompts 重複跑，直接看 SKILL.md 有沒有被載入。

Skill 出現在清單裡，只代表 harness 找得到它。Agent 看到一般 prompt 後有沒有選它，是 routing。兩件事混在一起，就會把「找得到」誤會成「真的有用到」。

不是每個 harness 都會把這五層寫進 log。有些會把 routing 跟 load 合成一個 event，有些只給你最後的 output。看不到就只能寫 unknown。Output 長得像 Skill 要求的格式，只能說行為很像；它不能證明 SKILL.md 有被讀到，也不足以把 adhered 記成 true。只有 tool trace 顯示 agent 做了指定動作，或你有檢查 Skill 要求的必要步驟，這一格才算有 evidence。

這跟我之前寫的 proxy 幻覺是同一種錯：一個數字明明只回答了 A，我們卻拿它去證明 B。Outcome 告訴你任務有沒有完成，沒有告訴你中間到底用了什麼。

沒有對照組，你就不知道是不是 Skill 的功勞

假設 agent 裝了 Skill，最後通過所有 tests。這個結果至少有三種解釋：

1. Skill 被正確選中、載入並改善了行為。
2. Skill 有載入，但 base model 本來就能完成，結果沒有變好。
3. Skill 根本沒有參與，agent 靠 model、repo context、其他 rules 或 tools 完成任務。

也就是說，如果你只是把 Skill 放進 harness 裡跑，然後只看最後的結果，你其實不知道這個 Skill 到底有沒有用。

Agent Skills 的官方 output eval 指南寫得很直接：同一個 test case 要分別跑有 Skill 和沒有 Skill，兩邊都從 clean context 開始，再比較 pass rate、tokens 與 duration。Claude Code 的官方文件也是同一個做法：Skill 有沒有被叫到，跟最後答案對不對，要分開看。

這不是方法論潔癖。有沒有對照組，真的會讓結論完全不同。

SkillsBench論文最新一版的 aggregate evaluation 涵蓋 87 個 tasks、18 組 model–harness 設定，比較沒有 Skills 和研究者準備的 Skills。平均 pass rate 從 33.9% 升到 50.5%，增加 16.6 個百分點。至少在這套測試裡，Skill 確實可能帶來明顯改善。

SkillsBench 的 Appendix K 更接近我開場遇到的問題。論文把 invocation 定義成 trace 裡有讀取或叫用該 task 的 Skill。在這個定義下，Codex / GPT-5.5 的 invocation rate 是 99.2%，Claude Code / Opus 4.7 是 68.2%，OpenHands / Gemini 3.1 Flash Lite 則是 46.4%。同一張表還把 invocation rate、最後的 resolution rate，以及「有 invoke 時的 resolution rate」分開列。

Codex / GPT-5.5 跟 Claude Code / Opus 4.7 的 invocation rate 差了 31 個百分點，resolution rate 卻只差 5.3 個百分點：66.5% 對 61.2%。Invocation rate 高，不代表 outcome 會按同樣幅度變好。只看前者或只看後者，都會漏掉一部分系統行為。

不過 SkillsBench 是先替每個 task 準備好對應的 Skill，再看 agent 會不會用；它沒有測一個塞了幾十、幾百個 Skills 的 library 裡，agent 能不能穩定選對。這兩種 routing 問題不能混在一起。

SWE-Skills-Bench得到另一種結果：49 個 SWE Skills 裡，39 個沒有讓 pass rate 變好，論文 abstract 寫的平均提升是 1.2%。其中 7 個比較專門的 Skills 有明顯改善，最多提升 30%；另外 3 個卻因為 guidance 過時，跟現在的 project 打架，最多讓表現下降 10%。這份研究至少打破了一個直覺：任務有通過，不代表功勞一定在 Skill。

More Skills, Worse Agents?測的是另一個問題：Skill 太多會怎樣？研究先挑出確定有幫助的 Skills，再比較小 library 和 52、102、202 個 Skills 的完整 library。在兩個 Claude models 上，擴到 202 個 Skills 後，論文原文寫的是 pass rate 最多下降 21%。這不是「沒有 Skill」對「202 個 Skills」，而是原本已知有用的小 library 對更大的 library。

最主要的原因不是 context 變長，而是相似的 Skill 把 agent 引到錯的地方。作者把這個現象叫做 skill shadowing。在論文 §4 的 Table 1，202-Skill condition 裡 shadowing 的 point estimate 是 0.14，總下降是 0.21，也就是大約 67%。這不是理論上的 upper bound，而是那組實驗的估計值；單純增加 context 的影響則小到跟零分不出來。這是全篇最直接的 routing evidence：Skill 越多，選錯 Skill 真的可能把原本的好處吃掉。

三份研究放在一起，沒有一個整齊的「Skill 好」或「Skill 壞」。Skill 可能很有幫助、完全沒差，也可能讓結果變糟。要知道整包 Skill 值不值得，最後還是得拿它跟同目標的簡短 instruction 比。

完全沒有 eval，複雜度可以安靜地留下來

上面說的不完整 eval，至少還可以確認在那些 cases 裡，Skill 沒有把最後結果弄壞。完全沒有 eval 時，團隊根本不知道這個 Skill 的效果是正、是零，還是負。

這種問題通常不會讓你一眼就看到。SWE-Skills-Bench 裡那三個讓結果變差的 Skills 就是很具體的例子：agent 沒有 crash，也不是完全不工作，只是 Skill 給了不合版本的做法，讓它在錯的方向上更努力。Agent 還是會回答，結果看起來也不一定離譜。

複雜度就這樣藏在其他地方：Skill 載入後，每一行 instructions 都會占 context；過時的 instructions 可能跟現在的 project 打架；Skill library 變大後，description 之間也會開始搶 routing。SWE-Skills-Bench 甚至量到有些 Skill 讓 token 用量增加 451%，pass rate 卻沒有變。這也是為什麼官方 eval 指南要求一起記 tokens 與 time。

更多 tool calls、維護成本、跨 harness 差異和錯誤安全感，也都要實際量才知道。在沒有確實 measurement 的情況下，你根本搞不清楚現在是哪一種狀況，只能自我感覺良好地說：「我弄了一個 Skill 幫我解決問題。」

真的壞掉會逼你修。「結果看起來還可以」反而會讓這些複雜度一直留在系統裡。

熱門公開 Skills，很少讓你看到這種比較

我在 2026-07-27 用 skills.sh all-time leaderboard看了一次熱門公開 Skills。

我先看當時的 Top 10 Skills，再按 GitHub repository 去重，往下取前 20 個不同 repos 各自排名最高的 Skill。我刻意用了比這篇主張更寬鬆的標準：只要同一個問題有跑過有 Skill 和沒有 Skill，並且比較結果，就算通過；不要求一定要有 terse instruction baseline。只有 trigger tests、unit tests、example prompts、expected outputs，或 README 裡一句「tested」，都不算。

結果是：

這兩組不是 30 個互不重複的 samples。Top 10 裡的 repos 也包含在第二組，而且高度集中在 5 個 repos：mattpocock/skills 占 5 席，vercel-labs/agent-skills 占 2 席，其餘 3 個 repos 各 1 席。這也是為什麼第二組要把 repo 去重，再看 20 個不同 repos。即使用前面那個比較寬鬆的標準，也只有 1/20 通過。

Appendix：Top 10 Skills 的抽查清單

這裡的 Partial 跟下面 20 個 repos 的定義相同：有 eval cases 或行為測試，但沒有同題的 outcome 對照組。Top 10 裡唯一的 Partial 是 agent-browser。

Appendix：20 個 repos 的抽查清單

排名是在 2026-07-27 抓的。我在 2026-07-28 用下面連結的 commits 再確認一次。Partial 代表有 eval cases 或行為測試，但沒有同題的 outcome 對照組。

這不代表作者私下都沒有測。它代表的是：使用者通常看不到足以證明 Skill 真的有幫助的公開資料。

唯一清楚做了這種比較的熱門 repo 是 JuliusBrussee/caveman。它讓同一組 prompts 跑三組：沒有 system prompt、只有 Answer concisely.、以及 terse instruction 加 SKILL.md。作者還特別指出，真正該比的是 Skill 對 terse control，不是 Skill 對一片空白。

這份 eval 也沒有把自己說得太滿：只跑一次，只量 output tokens，沒有量答案品質，也沒把讀 Skill 花掉的 input tokens 算進去。但至少你知道那些數字怎麼來的。

NVIDIA/skills則把 eval 直接變成發布規則。要發布的 Skill 必須附 evaluation dataset，產生的 BENCHMARK.md 也會跟 Skill 一起公開。當時抽查的 cuDF benchmark就有把使用 Skill 和沒有 Skill 的結果分開。

這至少證明公開比較做得到，差別只在你有沒有把它當成發布 Skill 的必要條件。

「只要 outcome 變好，routing 重要嗎？」

這是最強的反駁，而且有一半完全正確。

如果產品只在乎「使用者的任務能不能穩定完成」，而你已經在 clean context 裡重複比較過完整 Skill 和簡短 instruction，確定整套系統真的變好，那你不一定要知道每一次 routing 的細節。結果有變好就夠了。

如果簡短 instruction 跟完整 Skill 的 outcome 一樣好，成本還更低，routing 也不重要。比較合理的動作通常不是硬留整包 Skill，而是把它縮成那段簡短 instruction。

但如果你宣稱一般使用者不需要知道 Skill 名稱也能自然觸發，或 Skill 裡放的是安全、privacy、compliance 這種不能漏掉的規則，那 routing 就很重要。你也只有把 routing 記下來，才知道 Skill library 變大後到底是在哪裡壞掉。

Outcome 告訴你任務有沒有完成。Routing 告訴你 Skill 有沒有被用到。你可以只在乎 outcome，但不能說自己已經證明了 routing。

說一個 Skill 有用前，先跑這個最小比較

我現在會把 Agent Skill 的最小 eval 寫成五步：

1. 先準備多個真的會遇到的 tasks。 每個 task 都要先定義什麼叫完成。能用 tests 或程式判斷，就不要只靠「看起來不錯」。
2. 每組條件要一樣。 固定 model、tools、permissions、repo fixture 與 grader；每次都從 clean context 開始。
3. 至少跑三個對照條件。 第一個不給額外 instruction，第二個只給一段簡短但目標相同的 instruction，第三個才放完整 SKILL.md。第一個告訴你 base model 本來會不會，第二個才是判斷完整 Skill 多帶來多少價值的 baseline。如果 Skill 很長，還可以再加一個等長、但不含 Skill 方法的內容，確認問題是不是單純來自 context 變長。
4. 比較的是 tasks × trials。 不要只拿同一個 task 重跑。先準備多個 tasks，每個 task 跑 3–5 次當起點，再看整體結果。這個規模只能先看變異；重要的 Skill 要跑更多。Binary pass/fail 每個條件至少直接報 k/n 和 95% Wilson interval，不要只丟一個百分比。要說完整 Skill 有 uplift，還得報「完整 Skill − 簡短 instruction」這個 paired delta 的 uncertainty，例如用 task-level paired bootstrap。差異還落在不確定範圍內，就先寫 unknown。
5. 把過程跟成本一起記。 available → routed → loaded → adhered → outcome_pass，再加上 tokens、time 和 tool calls。只有 output 長得很像，不算 adhered；沒有 tool trace 或必要動作的檢查就寫 unknown。

Counterfactual Trace Auditing of LLM Agent Skills做的事情，正是比較同一個 task 有 Skill 和沒有 Skill 的 paired traces，找出行為到底在哪裡分岔，而不是只看最後有沒有 pass。這篇研究也剛好示範了 tasks 和 trials 的取捨：作者原本打算用 17 個 tasks、每個跑 3 次，最後為了涵蓋全部 49 個 tasks，改成每個只跑 1 次。他們也直接承認，這樣就沒辦法估同一個 task 反覆執行時的變異。Task 的範圍跟每題重複次數都重要，不能只挑一個數字交差。

你可以先直接指定 Skill，確認它被載入後能不能正常工作。接著再用一般 prompt，測 agent 自己會不會選到它。這是兩個不同問題，不要混成同一個分數。

沒有 200 次 run 的預算，先測哪裡？

上面三、四個對照條件，乘上多個 tasks，每個再跑 3–5 次，很快就會變貴。10 個 tasks、4 個條件、每個跑 5 次，就是 200 次 agent run。小團隊不可能每個 Skill 都直接跑完整套。

我會先挑最值得花錢測的那一個：裡面放了 safety、compliance 或固定 workflow 的 Skill，或是你準備叫其他人一起安裝的 Skill。第一輪只跑「簡短 instruction」和「完整 Skill」兩個條件。5 個 tasks、每個條件跑 3 次，一共 30 runs，先看有沒有值得繼續追的 signal。這只是 screening，不是可以拿去宣傳的 benchmark。

30 runs 跑出 null，只代表這個規模看不出差異，完整 Skill 的價值仍然是 unknown。如果它不承載 safety 或 compliance 規則，我還是會把簡短 instruction 當成成本上的預設值：在證據不足時，先選維護負擔比較低的那個。這是一個 decision rule，不是完整 Skill 已經被證明沒用。

如果完整 Skill 出現明顯 signal，再補沒有 instruction、等長對照、更多 tasks 和更多 trials。Eval 的成本應該跟你要做的決定一起放大。

最後，只問一件事

把這個 Skill 換成一段簡短 instruction，結果真的會變差嗎？

如果答案是「不會」，你就還沒有證明完整 Skill 比簡短 instruction 更有價值。先把它縮短；真的需要完整 workflow、references 或 scripts 的部分，再留在 Skill 裡。

TL;DR: Multi-Agent 最適合 objective 與 acceptance function 相對固定、feedback 可以快速重複的問題。Cursor 的 Agent Swarm 顯示，即使最後通過同一套 tests，舊版也可能需要新版 6.5 倍的 code；但日常 product engineering 的 acceptance function 會在執行途中被需求、remote state、review 與人的決策改寫。Execution 與大部分 validation 可以用 agents 快速擴張，最後的 release、scope 與 priority decision 仍然錨定在人身上。題目一直動，這些決定就沒辦法只在開頭做一次。

Cursor 最近公開的 Agent Swarm 實驗裡，最值得看的數字不是 68,000 個 commits。

在 Fable 5 mix 裡，新舊兩版 swarm 最後都通過了完整的 held-out SQL test suite。Outcome 一樣，但舊版用了 64,305 行 engine code，新版只用了 9,908 行，差了 6.5 倍。Opus mix 更極端：舊版用了超過四倍的 code，19,013 行，還停在 97%；新版用 4,645 行通過 100%。

同一個 outcome，需要的 output 可以差這麼多。

68,000 commits 那組數字則來自另一個 deep dive：舊版 Grok 4.5 run 在未滿兩小時就被停止前，已經產生 68,000 個 commits，速度約是新版 70 倍，同時累積超過 70,000 次 merge conflicts。那不是所有舊版 config 的共同結果，但它很乾脆地示範了一件事：activity 暴增，系統不一定在收斂。

在 Cursor 自己的 retrospective 裡，他們沒有把新版進步歸因於更多 parallelism，而是重新處理 task decomposition、shared decisions、version control、merge reconciliation 與 stacked review。Cursor 甚至認為，swarm 能 scale 的主要原因可能是 context efficiency，而非 parallelism 本身。

這個實驗很強。但它解的問題，跟產品團隊每天面對的交付問題，形狀不一樣。

外部 acceptance signal，跟內部 correction loop 要分開看

Cursor 給 Agent Swarm 的任務很難：只靠 835 頁文件，用 Rust 從頭實作 SQLite。Source code、SQLite binary、test suite 與 internet 都被拿掉。它不是 toy benchmark。

不過這個世界有清楚的邊界：objective 相對固定，repository 是主要 world state，量化的外部 evaluation 是一套包含數百萬筆 query、答案已知的 SQL tests。Agents 不只看不到 test suite，Cursor 明確說它們連這套 suite 存在都不知道。Held-out tests 是 run 外部穩定、machine-verifiable 的 acceptance signal，並不是 agents 執行中的 feedback。

Cursor 也沒有只看 test score。每次 run 後，他們會人工檢查 code 與 execution record，確認沒有 cheating、shortcuts，也不是只實作 tests 剛好覆蓋的區域。這裡一樣有人類判斷；但這些 audits 檢查的仍是 swarm 有沒有忠實完成原本任務，Cursor 沒有描述 execution 中途因為 priority 或 live state 改寫 objective。

執行中的 correction loop 來自另一組機制：compiler 把 intentional breakage 傳到相依 code，VCS 顯示 collisions，shared docs 保存 design decisions，reconciler 處理 planners 的矛盾，review agents 從不同 lenses 找出累積中的錯誤。

外部 acceptance signal，跟內部 correction loop 要分開看。

我把這種情況叫做 closed-world problem。Closed 不代表簡單，也不代表沒有 coordination cost。它指的是 objective、主要 world state 與 acceptance function 在執行期間相對穩定。當內部 feedback 又便宜、快速、可以重複，系統就能讓 agents 大量平行探索，再持續淘汰錯路。

這個前提還有成本上限。新版 swarm 的不同 model mixes 交出相近品質，成本卻從 $1,339 到 $10,565，差了將近八倍。Compute budget 當然可能成為實際 gate。這篇先不展開 model selection；我要處理的是另一個問題：即使你付得起更多 execution，團隊能不能把它變成交付？

我後面會把這條 delivery path 拆成執行、驗證、決策三種 capacity。Cursor 顯示 execution，以及 acceptance criteria 固定時的 validation，都能用 agents 擴張；open-world delivery 真正難補的是反覆被觸發、而且必須有人負責的 decision capacity。

Cursor 說 spec 最稀缺；真正的差別是 spec 會不會動

Cursor 在最後一節其實已經站到這個問題旁邊了。他們說 swarm 讓工作的單位從 file 或 feature 上升到 spec，未來稀缺的是「對 intent 的正確描述」。Planner 把 goal 拆成 task tree，再逐層 lower 成可執行工作。

我同意。Decision capacity 本來就包含描述 intent、切 scope 與決定 trade-off 的能力。

但 Cursor 實驗裡的 835 頁 spec 在 run 開始後相對固定。Product delivery 的 spec 會動。

一個 coding task 本身可能很 bounded：修一個 bug、補一組 tests、把既有設計實作出來。可是「把它交付」還包含 repository 以外的 state：客戶的 priority 動了、同事剛好在同一個 module 上做 hot-fix、另一支 PR 改了前提、需求變更、reviewer 對 severity 有不同判斷，或實際操作後發現 spec 裡的完成定義不對。

TDD、Spec-driven Development（SDD）與更明確的 acceptance criteria，可以把 coding 邊界裡的 feedback loop 關得更好；它們無法把邊界外的世界 freeze。測試還是綠的，正在解的問題卻可能已經不是團隊現在最需要交付的問題。

這是 open-world delivery。Review 不只檢查「agent 有沒有照題目作答」；它可能判定某個看似完成的 change 不能 release，也可能把多個 findings 收斂成一個真正的 blocker。Live-state verification 不只確認 patch 能不能套用；它可能發現題目的前提已經變了。Human acceptance 也不只是在最後按 approve；人看到 spec 或 UI 後，可能重新定義 scope。

Closed-world 裡，acceptance function 主要負責評分。Open-world 裡，驗證不只淘汰錯答案，它會改寫題目。

而且目前我還沒看到一個通用的好解。Live-state checks、短一點的 execution batch、頻繁 rebase 與 human checkpoints 都能降低 stale work，卻不能自動裁決「客戶 priority 跟原 spec 衝突時該選哪個」，也不能保證 agent 動手後世界不再變。Monitoring 可以更快發現邊界被撞破，不能替團隊做完那個決定。

最能說明問題的一次 agent run，什麼都沒留下

我回頭盤點自己同一天兩批 parallel workstreams 時，最能說明這個問題的不是某個漂亮的 implementation，而是一個 no change。

那個 automation 原本要處理幾個仍在進行中的 changes。它先檢查 live remote state，發現相關修正已經存在，於是停止，沒有 diff、沒有 commit、沒有 push。

如果量 activity，它幾乎是零。如果目標是避免重複修改與覆寫別人的工作，它交出了正確 outcome。

這兩批工作合計有 7 個 root workstreams、15 個 child agents，混合 implementation、review、QA、spec 與 automation。這個規模只用來交代 illustration 的量級，不是受控實驗。

它在這篇裡的角色是 illustration：parallelism 讓 execution supply 與 work in progress 先變多；真正被接受的結果仍反覆經過 execution → review → fix / re-review → CI / live state → human accept。

另一條 review-heavy workstream 更直接。我沒有繼續增加 implementation output，而是把五個 agents 配到不同 review lenses。多輪 severity calibration 後，真正需要擋 release 的問題只有一個；修正後 re-review 沒有 P0–P2，CI 也通過。增加 agent 有用，但那次增加的是 validation capacity。

我之前用過 activity、output、outcome 拆 productivity claim。這裡只需要記住一句：commit、thread 與 finding 是工作痕跡；團隊真正要的，是通過 acceptance path 的 outcome。

Agent-scalable capacity，最後仍匯進 human decision

「throughput 受最稀缺的環節約束」不是新理論。Theory of Constraints 與 queueing theory 早就在處理這件事：上游工作站再快，只要下游 queue 沒有消化，整體 throughput 就不會跟著上升。

《目標》出版多年後，這個畫面還是沒有過期：constraint 不變時，加速非瓶頸工作站不會提高整體 throughput，只會讓更多半成品堆在瓶頸前。Multi-Agent 把同一幕搬進 software delivery；堆在 gate 前的不是工廠半成品，而是尚未 review、尚未接受，甚至前提已經過期的 code、spec 與 findings。

AI 不會消除 constraint。它會移動 constraint。

所以我現在把 delivery path 拆成三種 capacity：

• 執行（execution）：把已知方向變成可驗收的 code、tests、文件與修正。
• 驗證（validation）：透過 review、CI、security check、browser QA 與 live-state check，判斷 output 是否可靠。
• 決策（decision）：決定哪個方向值得做、哪個風險可以接受，以及現在怎樣才算 done。

Execution 最直接；acceptance criteria 固定時，validation 也能用 review agents、reconciler 與 stacked lenses 擴張，我自己的 review-heavy workstream 也是同一個例子。

但 validation 能擴張到什麼程度，取決於 acceptance criteria 有多固定。標準固定時，review 是驗證；標準會動時，review 的一部分其實在決定標準。前面那次 severity calibration 就是例子：找出 findings 是 validation，決定哪個風險必須擋 release，則是 decision capacity。團隊容易低估後者，因為它常穿著 review 的外衣出現。

執行與驗證最後都匯進同一個終點：有人要決定這個 change 能不能 release、scope 要不要改、哪個 priority 先做，而且要對結果負責。在 closed-world 裡，這些決定有一大部分可以 front-load 到 spec 與 acceptance criteria；open-world 的題目持續被現實改寫，同一批 decisions 會在 execution 中反覆出現。

這才是不對稱的地方。Spawn 十個 workers 或 reviewers 幾乎是立刻的事情，但是不會同時長出十個擁有完整 context、權限與責任的 decision owners。增加一個資深工程師很慢；他真正稀缺的也不只是 execution，而是願意、能夠、也有權責做最後判斷的部分。

這不只是模型能力問題。Agent 可以提出 release recommendation，責任卻不會隨著 agent 一起 spawn；組織裡仍要有一個主體承擔線上事故、客戶影響與 trade-off 的後果。

如果 PR 已經堆在 review、CI feedback 很慢、spec 還在變，或所有 release decisions 都等同一個人，更多 execution agents 只會讓 gate 前面的 WIP 變厚。

你會看到更多 output。Delivered throughput 不一定動。

「這些本來就是正常的 software delivery」

對。Review、CI、scope change 與 human approval 本來就存在。我的盤點沒有證明 parallel agents 製造了 serial gates，也沒有證明那些工作如果 sequential 執行就會更快。Cursor 的 SQLite workload 更不能直接拿來預測一般產品團隊的 conflict rate。

這篇支持的 claim 窄很多：Multi-Agent 不會消除既有 constraints。Execution 與 validation 可以比 human decision 更快擴張；acceptance function 又會在 open-world 裡持續變動，原本錨定在人身上的 constraint 只會更早露出來。

Multi-Agent 沒有創造這些 gate。它讓你更快撞上它們。

加 agent 前，先找 queue 在哪裡

下次想把一個 agent 變成五個之前，我會先問：

1. 現在等待最久的是執行、驗證，還是決策？ 看 queue，不看哪個工具最熱門。
2. Acceptance function 在 execution 期間會不會被改寫？ Test suite 能反覆判分的工作，比需求與 shared state 持續變動的工作更適合大幅平行化。
3. Shared state 會不會在 execution 途中被別人改動？ 如果同事的 hot-fix、另一支 PR 或 live environment 會改掉工作的前提，就要縮短 batch、提高同步頻率，而不是只增加 workers。
4. 新增的 agent 要放在哪一種 capacity？ Execution 已經跑在 review 前面，下一個 agent 就應該負責 validation，而不是再生成一份 output。
5. 什麼情況下 no change 才是正確 outcome？ 只獎勵 commits 的系統，會把避免重複工作、停止錯誤方向與 scope 收斂全部算成失敗。

如果 execution 是最長的 queue，增加 execution agents。Output 已經堆在 review，就先增加 validation capacity。所有人都在等需求與 release judgment，則有三個選擇：把 release 權限分給更多有足夠 context、也願意負責的人；預先講定 severity rubric 與 release criteria，把重複決策 front-load；或縮小 scope 與 batch，減少每次需要判斷的決策面。

不要用 agent 數量管理 throughput。管理那個最稀缺的 gate。

TL;DR: 我原本只是想知道，家裡那台 PreSonus ATOM 能不能拿來控制 Codex。Swift 我只看得懂一點，macOS app 也沒什麼經驗，實作幾乎都是 Codex 做，我比較像 PO + QA。現在這台東西我在家還是每天用，但我只確定它在我的電腦上能跑。這是 personal software，不是 production-ready product。

第一次看到 ATOM 的 pad 跟著 Codex task 閃爍時，我正在用 Codex 開發這個 controller。螢幕上的 task 正在 build 控制器；桌上的控制器又把同一個 task 的狀態顯示回來。那一刻我第一個想法就是：Codex 真的很厲害。

但我一開始對 RGB 能不能控制其實心裡沒底。ATOM 是 MIDI controller，Studio One 和 Ableton 可以控制它的燈，不代表我知道一般程式該送什麼 bytes，也不代表 Codex Desktop 願意把 task state 給外部程式。

如果是在 pre-LLM 時代，我大概會先翻硬體 spec、找 community discussion、讀別人的 driver，再研究 CoreMIDI 和 Codex local state。光確認方向可能就會花掉一整天。對一個只給自己用的 side project，這個成本就足以讓我想想算了。

Personal software 只需要對自己負責，stakes 最低。Coding agent 會最早讓這類軟體變得值得做。

這次 survey、Swift implementation、tests 和 diagnosis 幾乎都是 Codex 做；我主要負責按硬體、看畫面、貼 log，然後告訴它有沒有真的 work。

我其實不會寫這個 app

我看到 Work Louder 做的 Codex Micro，想到家裡已經有一台 PreSonus ATOM，就問 Codex：

我有一台 MPC（ATOM PreSonus），可以取代 Work Louder 做的 Codex Micro 嗎？

我過去開發 macOS app 的經驗很少，Swift 只是大概看得懂，不算會寫。我對 ATOM 的整合其實也不算有底，只知道可以做得到，不過沒什麼方向。

而且這是 side project，不是要上 production 給其他真實客戶用的東西。只要確定我可以用就好。

所以一開始先分兩階段。第一階段做 MIDI controls：切換 task、建立 task、送出 prompt、dictation 和 scroll。第二階段再讀 task state，讓 pads 顯示 running、complete、needs input 和 error。

我的角色比較像 PO + QA

實作開始後，我照 Codex 的指示，從左上角開始按完 16 顆 pads，再按 buttons、轉四顆 knobs。它在 terminal 監聽 raw MIDI，把實體位置對到 MIDI note 和 CC value。

它連 layout 都不是一次猜對。我拿實機照片糾正它：

Preset +/- Focus 是同一個按鈕。

後來又確認 Shift 和右側小圓形 Setup 雖然看得到，卻不送一般 MIDI message。最後還是要以實機 capture 為準。

它負責查 protocol、寫 Swift、跑 tests。我負責按硬體、看畫面，然後回「有改善」或「沒改善」。我的角色比較像 PO + QA。

後面真正花時間的，都是 Codex 說做完後，我一用才出現的問題。有些在硬體、有些在 app，還有一個根本不算 bug。

Tests 都過了，實機還是會壞

RGB 完成時，67 個 automated tests 全部通過，release build 成功，Codex state 和 ATOM 也都顯示 connected。但我一按 pad，task 完全沒有切換：

hmm... 切 task 好像不能 work？Pad 1～6 沒切到對應的 pinned thread，Nav Up／Down 倒是可以。

掛上 raw MIDI monitor 才發現，ATOM 進入 Native RGB mode 後，pads 的 MIDI channel 也跟著從 10 改成 1。原本的 hardware map 只接受 channel 10，所以 RGB 一開，pad input 就全部被 filter 丟掉。Navigation buttons 原本就是 channel-1 CC，才會正常。

另一個例子是 Knob 2。Terminal 一直印：

knob2 -> content.scrollDown trigger dispatched
knob2 -> content.scrollUp trigger dispatched

但畫面完全沒有動。

看 log 有 scroll up／down event，但是 content 沒有捲動。

後來才確認，CGEvent.postToPid 成功不代表 Electron 真的消費了 scroll event。最後 scroll 必須在 Codex 位於 foreground 時，將 system scroll event 定位到 transcript 或 sidebar；Codex 在背景時就直接不做，免得捲到別的 app。

dispatched 只能證明程式走過 dispatch path。這兩次如果沒有實機，我們都會以為已經做完了。

有些功能就是做不到

Push-to-talk 是整個過程裡試最多次的功能。ATOM 的 Record button 在按下和放開時都有即時送出 MIDI event，controller log 也會顯示 holdEnd dispatched，但放開後 dictation 就是不會像實體鍵盤一樣立即停止。

Codex 改一次，我就測一次。它試過 modifier lifecycle、兩次 toggle、完整 keyboard chord、重新啟動 Codex，再叫我用鍵盤做 A/B。好幾輪我的回答都一樣：

沒改善。

鍵盤是即時的。

Toggle 鍵盤是即時的。

目前的現象看起來是按一下 toggle 可以，但是 push-to-talk 好像不行。

最後才確認，原生 Codex Micro 不是模擬 keyboard shortcut，而是使用 Codex Desktop 內部的 start／stop events。外部程式沒有穩定 API 可以走同一條路。

所以目前沒有真正的 push-to-talk。Record 最後做成 press-only dictation toggle：按一次開始，再按一次停止。Release、focus loss、disconnect 和 shutdown 都不補送 toggle。

綠燈 30 秒，產品語意還是不對

Task 完成後很快就會從 active 回到 idle。第一版為了避免綠燈只閃一下，加了 30 秒 latch。行為很穩定，tests 也都有過，但我看著燈號還是覺得不合理：

完成後綠色維持 30 秒這件事情是合理的設計嗎？感覺應該要一直維持綠色？Codex Micro 是怎樣？

如果綠色表示「task 完成，正在等我看」，我還沒看，它為什麼 30 秒後就不再提醒？

回頭查 Codex Micro 才發現，綠色代表的是 unread，不是 recently completed。Task 完成但還沒查看時就一直維持綠色；我真的打開那個 task，才回到 idle。後來 Codex 找到 Desktop 保存的 unread state，把 30 秒 timer 換掉。

這也是我說自己比較像 PO 的原因。Code 沒壞，產品行為還是可能不對。

這幾個問題有個共同點：只看 code 和 tests 看不到。你得真的接上硬體、看 Codex 畫面，再判斷燈號對使用者代表什麼。Production engineering 很大一部分就在守這條線。

Personal software 跟 production-ready product 是兩回事

Coding agent 最大的幫助，應該會是讓大家更容易 build 出「自己使用的 application」。Codex ATOM 就是這種東西：使用者是我，電腦環境是我的，壞掉時我知道怎麼繞，重開 process 也可以接受。

不過我肯定不會認為這是 production ready 的東西。因為目前這版我只確定在我的電腦上面能跑，也許換到其他人的電腦，環境不同就不能跑了。不同的 Accessibility permission、Codex Desktop version 或 MIDI firmware，都可能讓它壞掉。

真實客戶不會陪你在 terminal 裡看 raw MIDI，也不會接受功能壞掉後由作者本人重開 process 就算修復。所以我的判斷還是：coding agent 能幫助大家建立自己用的東西，但是 production-ready app 還是需要專門的 developer 介入。

這就是我對「因為 coding agent 的關係，SaaS is dead，公司都會自建」這種說法嗤之以鼻的原因。這個說法把「在自己的電腦上能跑」當成「可以交給陌生客戶長期使用」，前面這幾個問題就是中間被省略的 production engineering。

它現在還在我的桌上

這個 side project 實際上對我還真的蠻有幫助的。最常用的就是 pinned task 切換。因為現在我會把每天主要要工作的 threads 都 pin 起來，所以 task 切換、看燈號對我來說很有意義。以前要看左手邊的 sidebar，不過畢竟比較小，有時候很難注意到；燈號就很明確，可以看到 task 正在 running，或是 complete 等我看。

其他功能偶爾才用，但基本上沒有什麼完全沒用。差別只在 task switching 和燈號真的變成每天 workflow 的一部分。

下面是最後拿去參加 OpenAI Build Week 的 demo：

<lite-youtube videoid="gg00seXWAPE" playlabel="播放 Codex ATOM demo"></lite-youtube>

在 YouTube 觀看 Codex ATOM demo

Codex ATOM 本來就不需要變成一個 product，我也沒打算把它賣給別人。以前碰到這種需求，我大概想一想就算了；現在我真的把它做出來。

以前這種軟體不值得做。現在做了，而且我真的在用。光是這樣，我就覺得很有價值了。

相當這件事先不論。我想談的是「更快、更便宜」—— 因為這兩個結論，幾乎都是直接讀 price card 上的 per-token 價格跟 tokens/sec 推出來的。而在 agent + reasoning 的世界裡，這兩個數字都是 proxy，而且是正在失效的 proxy。

這篇不是要說 GLM-5.2 不好。它是一個很好的 model。我要說的是一件更一般的事：per-token 的價格與速度，越來越無法預測你真正的成本與延遲；而且你的 workload 越 agentic，誤差越大。 GLM-5.2 只是一個剛好很乾淨的 case study。

proxy 在哪裡失效

先講一個不依賴任何數字的論點。

你真正付錢的單位，不是 token，是「解掉一個 task」。你真正在等的，也不是 token，是「這個 task 什麼時候解完」。per-token 的價格與吞吐，是用來逼近這兩件事的 proxy。

在 single-shot completion 的時代，這個 proxy 還堪用：一次請求、一段輸出，token 數大致固定，per-token 乘一乘就八九不離十。但 agent + reasoning 改了底層的算式。一個 task 實際消耗的 token，是這樣放大的：

token 總量 ≈ effort（reasoning 想多深）× verbosity（output 多囉嗦）× turns（agent 跑幾輪）× retry（失敗重試幾次）

這四個因子，沒有一個寫在 price card 上。而它們每一個，都會在 long-horizon 的 agent loop 裡被乘大。所以「per-token 便宜」跟「解一個 task 便宜」之間，隔了一整層你看不到的 token 放大係數 —— model 越 verbose、loop 越長，這層係數越大，proxy 就偏得越離譜。

速度是同一個故事的另一面。tokens/sec 量的是「吐字多快」，但你等的是「整個 task 多久解完」。後者 = 要吐的 token 數 ÷ 吐字速度。一個吞吐很高、但每個 task 要吐很多 token 的 model，wall-clock 可以比吞吐低、但簡潔的 model 還慢。

下面用 2026 年 6 月的實際數據，把這層放大係數量出來。

一份 2026-06 的 snapshot

以下數字取自 Artificial Analysis Intelligence Index 與 DeepSWE，snapshot 日期 2026-06-22。model 版本與定價都會變，請把它當成案例，不是結論 —— 會變的是數字，不會變的是上面那條算式。

成本：6.8x 的折扣，到 task 層只剩 2x

先看 price card（input / output，每 1M tokens）：

光這一層就已經不單純。output 上 GLM 比 GPT-5.5 便宜 6.8x、比 Opus 便宜 5.7x；但 input 三家都落在 $5 上下，GLM 只便宜約 3.6x。所以連 per-token 內部，「便宜幾倍」都要看你算的是哪一種 token。先抓最誇張的那個 —— output 6.8x —— 往下看它怎麼縮。

把同樣三個 model 放到 AA 的 cost-per-task 上：

GPT-5.5 那個 6.8x 的 per-token 折扣，到 cost-per-task 只剩 2.0x。原因就是上面那條算式裡的 verbosity：GLM-5.2 解一個 Index task 要燒大約 43k output tokens，其中 37k 是 reasoning；GPT-5.5 大概只用 10k。每個 token 便宜 6.8x，但你用掉了 4 倍多 —— per-token 省下來的，被 token 數量吃掉一大半。

這裡值得順帶澄清 AA 上兩個長得很像、但意思不同的指標，因為它解釋了為什麼倍數還會再縮：

• Cost to Run 是跑完整個 Index 的總帳單（各類 token × 單價，加總，扣掉 repeat）。raw、不加權。GLM $983 / GPT-5.5 $2,853 / Opus $4,012。
• Cost per Task 是把成本除以 task 數，再按每個 eval 在 Index 裡的權重加權。GLM $0.52 / GPT-5.5 $1.06 / Opus $2.05。

兩者的倍數不一樣（Cost to Run 下 GPT-5.5/GLM 是 2.9x，Cost per Task 下是 2.0x），差距來自加權 —— 權重高的 eval 偏 agentic、偏 long-horizon，token 燒得兇，加權後會把 verbose model 的相對成本再拉近一點。換句話說，越偏 agentic 的衡量方式，GLM 的 per-token 折扣就被壓得越扁。 記住這個方向，等一下 DeepSWE 會把它推到極端。

速度：t/s 最高的開源 model，wall-clock 跟最貴的 Opus 並列

per-token 看速度就是看 tokens/sec。GLM-5.2 跑 94 t/s，高於 leaderboard 平均（約 75），照這個數字它「不慢」。

但 AA 的 time-per-task（weighted wall-clock，分鐘）：

GLM-5.2 跟最貴的 Opus 4.8 打平，兩個都比 GPT-5.5 慢將近一倍。一個吞吐最高的開源 model，time-per-task 反而跟 frontier 裡最慢的那隻並列。因為決定 wall-clock 的不是吐字速度，是它要吐多少字 —— 又繞回 verbosity。

一個必須講清楚的反例

到這裡你可能會想反問：那 GLM-5.2 到底是不是 cost-efficient？

誠實的答案是：在 aggregate intelligence 上，它是。

AA 的 Intelligence vs. Cost-per-Task 散點圖上，GLM-5.2 (max) 落在 ~$0.52、Intelligence Index 約 51 的位置 —— 在 GPT-5.5、Opus 的左邊（更便宜）、只低一點分數，相當靠近左上那個「most attractive quadrant」。如果你的 workload 長得像 AA 那個由九個 eval 加權出來的綜合分布，GLM-5.2 確實划算。這不是要藏起來的數字，它是真的。

那為什麼我前面還說「便宜是個會騙人的 proxy」？因為 aggregate 是一個會蓋掉 workload 差異的數字。 它把短任務跟長任務、輕推理跟重 agent 全部混在一起平均掉。一旦你把鏡頭拉到單一、long-horizon、多 turn 的 agentic workload，結論會反轉。

DeepSWE 就是這個鏡頭 —— 它讓 agent end-to-end 去解 real-world 的 coding issue，量的是解一題的平均成本與分數。在大約 $4 / task 這個價位帶：

在這個 workload 上，GLM-5.2 花最多錢、拿最低分。不是「沒有比較便宜」而已 —— 它用比兩個 frontier model 更高的 cost，換到比它們更差的結果。

這裡要坦白一個比較的細節，不然嚴謹的讀者會抓：上表把 GLM 的 [max] 跟 frontier 的 [medium] 放在一起比。這不是偷換，是因為 effort level 本身就是一個 decision variable —— 我比的是「各自在這個 ~$4 價位帶會落在哪」。GLM 為了追上分數得開到 max（也才 44%），frontier 在 medium 就已經更省更準。如果你硬要 GLM 也用更低 effort，它會更便宜，但分數會掉得更多。怎麼比都還是同一個結論：在 long-horizon agentic 上，那個 per-token 折扣不存在。

衰減鏈

把三個鏡頭疊起來，同一個 6.8x 是這樣一路衰減的：

price card 6.8x → AA cost-per-task 2.0x → DeepSWE <1x（反轉）

關鍵不是「GLM 到底便不便宜」這種是非題，而是：衰減的斜率，取決於你的 workload 有多 agentic。 aggregate 上折扣還在一半；換到真正的 long-horizon agent loop，折扣歸零甚至倒貼。而一個 per-token 數字，完全沒辦法告訴你會落在這條鏈的哪一點。

那要看什麼

如果 per-token 不能信、別人的 aggregate benchmark 也只是某個 workload 分布的平均，那 model selection 該量什麼？

量 cost-per-resolved-task 跟 time-per-resolved-task，而且是在你自己的 agent loop 裡量。具體一點：

1. 固定一組 representative tasks。用你 production 真實的分布，不是別人的 benchmark distribution。
2. 跑你自己的 harness。同樣的 tools、同樣的 context 長度、同樣的 retry policy、同樣的 eval gate。
3. 記三個量：total tokens（含 reasoning）、wall-clock、以及最重要的 —— 有沒有真的 resolve。
4. 算每個 resolved task 的成本與時間。分母是解掉的題數，不是跑過的題數；一個便宜但常常解不掉、要重跑的 model，真實成本是被失敗率乘大的。
5. 把 effort level 當成跟 model 平起平坐的 decision variable 一起掃。同一個 model 沿著 effort 在 cost / score 上滑動的幅度，常常比換 model 還大。

這也是為什麼我一直主張 eval-first：rubric 先於 flow、test 先於 build。當你有一組會 compound 的 cases，這種 cost / time-per-resolved-task 的量測就是順手的副產物，而不是另外一個專案。cases compound，prompts decay，price card 則是從你簽約那天就開始 decay。

最後回到單位

proxy 不是沒用，proxy 是「在某個條件成立時還堪用的近似」。per-token 成本與吞吐，在 single-shot 時代是堪用的；在 agent + reasoning 時代，它們失效的速度，跟你的 workload agentic 的程度成正比。

知道一個 proxy 什麼時候會失效，比記住它此刻的數值更值錢。這也是 calibration 的一種練習 —— 不是不信任何數字，是知道每個數字在什麼邊界內才有效。

便宜的 token，不等於便宜的 outcome；快的 token，也不等於快的 outcome。在 agent 的世界裡，唯一誠實的單位，是「解掉一個 task 要花多少錢、多久」。

TL;DR: 「AI 生產力 10x」不是一個 claim，而是任務、個人、組織三層 claim 被壓成同一句話。更麻煩的是，很多人把 activity、output、outcome 混成 productivity。任務層 output 加速是真的；個人整體 10x 被流程瓶頸鎖住；組織 10x 需要流程重構，不是把 AI 塞進舊流程。

最近半年，我的 feed 被同一個數字洗版。

一堂 Stanford 的線上課，教你怎麼用 AI「把生產力放大 10 倍」。一個連續創業者在課程宣傳裡說，現在用自然語言自己寫軟體，生產力能拉到「十倍、一千倍」，不用再等工程師。一場線上講座，名字直接叫「解放工作中的十倍生產力」。「我現在的 productivity 是以前的 10x」這種貼文，我一週能滑到三四個。

但同一個 feed 裡，也有人這樣寫：「訂閱 $200 Max 的這幾個月，是我這輩子產出最多、也最焦慮的時候。」然後他把每月訂閱從 $200 砍回了 $60。

同一批工具、同一個「10x」，一邊在賣，一邊在逃。差別在哪？

差在他們嘴裡的 "10x"，根本不是同一件事。

"10x productivity" 從來不是一個 claim。它是三個 claim 疊成一句：任務的 10x、個人整體的 10x、組織的 10x。三層完全不同，可信度也完全不同。喊的人通常沒分清楚自己指的是哪一層，反對的人也沒分清楚自己在打哪一層。於是這場架永遠吵不完，因為兩邊根本不在講同一件事。

但這還只是表層。底下埋著一個更深、也更要命的混淆：就算你指定了是哪一層，你嘴裡的 "productivity"，到底是 activity（你忙了多少、產了多少東西）、output（你真正交付了什麼），還是 outcome（那東西最後換到的結果）？這三個被「10x」縫成了同一個字，但它們之間差了十萬八千里。那個「產出最多、也最焦慮」的人，已經用身體撞到接縫了：activity 衝到這輩子最高，他的結論卻是想退回去。

這篇就做兩件事：先按「哪一層」把任務、個人、組織拆開驗收；再回到「哪一種」，也就是 activity、output、outcome，看「10x」到底在指什麼。最後你會看到，連業界喊得最大聲的兩個人，都在同一個字上栽了跟頭。

第一層：任務 10x，這層是真的，沒什麼好吵

受控實驗的數字都擺在那。客服任務有 AI 輔助後每小時解決問題數增加 15% 的 field evidence；寫作類任務在 Science 的實驗 裡顯著縮短完成時間；軟體開發的 GitHub Copilot controlled experiment 裡，受試者完成指定 coding task 快了 55.8%。這些不是 marketing，是可以被檢查的方法與數據。

在「單一、邊界清楚、可立刻驗證」的任務上，AI 的加速是真的，而且常常很猛。

但記住這層量的是什麼：output。你單位時間產出的 code、草稿、清單變多了。而且這是你一個人就數得出來的東西。先把這點記著，後面要用。

任務快 10x，不等於你快 10x。它證明的範圍，比喊的人以為的小很多。這層講完就走，停太久就變成幫 hype 背書。

第二層：個人整體的 10x，結構上不可能

而且這不是工具的問題。

把任務層的 output 加速加總起來，為什麼個人整體不會跟著 10x？

Amdahl's law：一個流程的加速上限，被你「沒有加速的那部分」鎖死。AI 能猛加速的是生成，也就是 output。但一件事從開始到真正交付，生成從來不是瓶頸。

舉我自己天天遇到的兩個。

Code review。 AI 生 code 快了好幾倍。然後呢？review 沒變快。看懂這段在幹嘛、判斷它有沒有踩到別的東西、決定要不要 merge，這些 cost 不但沒降，反而因為「要 review 的量變多了」而上升。output 端省下的時間，一部分直接被驗證端吃回去。

Outreach。 survey 名單、整理 prospect list，AI 快到誇張。但從名單到真的 convert 成 sale 呢？中間卡著開會、確認需求、來回對齊、簽約。這些 AI 動不了，因為本質是「人要做決定、人要被說服、人要扛後果」。

關鍵在這：就算生成變成完全免費、零延遲，這已經是物理上限了，整體速度還是被那些 AI 碰不到的環節卡住。這層的天花板是結構性的（structural），不是能力性的（capability）。所以模型再強，也鬆動不了它。 記住這個區分，等一下兩個 CEO 就是在這裡押錯了邊。

第三層：組織的 10x，可能，但還沒發生

而且不會是均勻的。

歷史上看過一模一樣的劇本。工廠電氣化時，工人把電動馬達裝上蒸汽時代的舊機器，生產力幾乎沒動。真正的躍升等了幾十年，等到有人重畫工廠的物理佈局，讓產線繞著「電」這個新前提重組，提升才出現。提升從不來自換馬達，來自重畫佈局。

組織的 10x 也一樣：條件是重構流程，不是把 AI 塞進舊流程的縫隙。

這就解釋了那些難看的總體數字：NBER 相關調查被多家媒體整理成同一個結論，企業 AI 使用率不低，但 89% 企業說過去三年 productivity 沒有明顯提升、90% 說 employment 沒有變化，高層對未來三年的平均預期也只是 productivity +1.4%、output +0.8%。讀成「看吧 AI 沒用」就讀反了。這不是「AI 沒用」的證據，是「大部分組織還在塞縫隙」的證據。

我得誠實交代自己在哪。Codeer，六個人，做 AI agent。產品開發這條，我們的 shipping 速度比幾年前快了好幾倍，任務層加上一部分流程重構的成果。但這不是 10x，其他環節（像前面那個 outreach）還卡著。我是個正在賭第三層的人，很清楚自己還在半路。

但這裡有個更尖的問題，你大概已經想到了：就算組織真的重構成功、productivity 漲了，為什麼營收沒有跟著漲？ 因為 productivity 跟營收之間，隔著一整層市場：需求夠不夠大、對手是不是也 10x（大家一起 10x = 東西變便宜，不是你賺 10x）、定價權在不在你手上。農業生產力漲了幾十倍，農民收入沒漲幾十倍，因為糧價崩了。

產能 10x 不等於賣得掉 10x，不等於賺到 10x。而這，正好把我們帶到那個最深的混淆。

你說的 productivity，是 output 還是 outcome？

退一步。「哪一層」還不是最深的問題。最深的是：你嘴裡的 "productivity"，指的是 output（你做出來的東西）還是 outcome（那東西真正換到的結果：問題解決了、錢賺到了、用戶被滿足）？

這兩個被「productivity」這個字偷偷縫成了一個。但它們之間，隔著前面整篇講的所有東西：判斷、決定、說服、市場、定價、責任。

而且這裡有個結構性的不對稱：output 量得到，outcome 量不到。我今天寫了多少 code、survey 了多少名單，自己就數得出來；這些 code 有沒有解決對的問題、這些名單最後換到多少錢，要等、要靠別人、不歸我一個人管。

但真正難看的是再下面一層：多數人喊的「10x」，連 output 都稱不上，是 activity。

回頭看 developer 到底在幹嘛。他真正的 output 從來不是「寫了多少 code」，是把功能 ship 到 production、變成客戶手上真的在用的東西。code 寫了一卡車，卡在沒 deploy、進不了 production，那個產出是零，而十倍的零還是零。outreach 也一樣：你用 AI 把名單收集速度拉了十倍，但名單躺在 sheet 裡沒寄出去、沒真的更早碰到客戶，一樣是零。收名單是 activity，碰到客戶才是 output。

所以很多人喊的 10x，是最上游、最好灌水的那個 activity 數字（行數、名單筆數），離他自己真正的 end-to-end output 都還有一段他沒提的路，更別說 outcome 了。

我本來想把這寫成「被逼的 proxy」：outcome 量不到，只好退而求其次量 output。但這太客氣了。實情更可能是，他們挑的根本不是退而求其次的 output，是最好灌水的 activity。而且不少人心裡未必不知道：「我 10x」好發、吸睛、講起來爽；outcome 難講、會打臉、沒人想聽。與其說被逼，不如說是挑了那個最爽的數字來喊。

現在來看業界喊得最大聲的兩個人。

2025 年，Sam Altman 跟 Dario Amodei 賭的是 outcome。Amodei 在 Axios 講得最白：AI 五年內可能消滅一半的 entry-level 白領工作，失業率衝到 10-20%，金融、法律、顧問、科技首當其衝。這個說法後來被 Axios、Business Insider 反覆整理。Altman 那幾年也反覆 warning entry-level 要完。注意這是什麼 claim：outcome 的、未來式的、賭出來的。跟工程師「我 output 10x 了」根本是兩種東西。

然後 2026 年 5 月，Altman 改口。

Altman 在 Commonwealth Bank of Australia 的對談裡承認自己對 AI 的社會與經濟衝擊判斷錯得不輕，還說自己 "delighted to be wrong"。Amodei 的語氣也開始出現另一條路線：從「工作消失」轉向「工作轉變、放大既有 worker」，同時仍保留對大規模 displacement 的警告。

看清楚這裡發生了什麼：敘事從 outcome claim（工作會消失），退回 output claim（productivity 會上升）。 中間那個「10x」，就是退路。outcome 賭輸了，至少還沒贏，於是縮回 output。而 output 永遠是安全的，因為它本來就量得到、本來就在漲。

所以「10x productivity」這個詞最深的問題，被兩個最該講清楚的人，在 12 個月內、當著全世界的面，現場表演了一次：先把 output 的加速講成 outcome 的革命，等 outcome 沒兌現，再縮回 output 那個一直都成立的版本。

但別急著走到反面結論

拆到這裡你又會想：「看吧，工作根本沒消失，所以根本沒事、AI 根本沒效。」

這結論一樣太快，而且一樣有毒。

量測本身就是問題。aggregate 的就業數字穩，不代表底下沒事：white-collar professional sector 從 2023 年 4 月高點後 累計就業已經下降約 2%，而其他部門還在成長；2026 年到五月，Layoffs.fyi 被媒體引用的科技業裁員數也已經 接近十萬。「總就業穩定」這個儀表板數字，蓋住了底下可能正在發生的位移。總體看不到，不代表沒發生，只代表那張表抓不到。

但這裡得對自己誠實一次：這些 layoff 是不是 AI 造成的，沒人真的知道。公司確實愛說是 AI，可是「是 AI」對一家公司來說剛好是最方便的故事：顯得自己站在未來，又能蓋掉過度招聘、利率、景氣這些不性感的真因。「公司說是 AI」跟「工程師說我 10x」是同一種 proxy，都挑了最好講、最吸睛的故事，不是最準的那個。 所以紀律是雙向的：別因為總體沒動就說 AI 沒效，也別因為公司喊 AI 就信 AI 在砍人。兩個方向的便宜故事，都別照單全收。

而且 outcome 裡還有一整塊報表天生抓不到：AI 幫你擋掉的一場事故、讓一個原本不值得做的長尾需求第一次變得可做、把一份東西做到原本請不起那種人才做得到的水準。事故沒發生、需求被滿足、品質默默上升，共同點是，它們都不會在 GDP 或財報上長出一個正數。

這正是我上一篇講 proxy 幻覺 那個坑的鏡像版。上一篇講 "activity 不等於 value"，別把忙碌當成果、別信假訊號。這篇要補它沒講完的另一半：value 有時候剛好量不到。只信你量得到的（output、aggregate 就業數字），跟只信你看起來很忙，是同一種病的兩面，都是抓著一個方便的 proxy，當成你真正在乎的東西。

最後一刀，回到那個 capability vs structural。outcome 還能再切一刀。認知型的 outcome（想清楚、做判斷），也許 capability 真的追得上，Altman 跟 Amodei 賭的就是這塊。但責任型的 outcome（出事誰扛、誰被告、誰上證人席）可能跟 capability 一點關係都沒有。你沒辦法把一個 model 拉上證人席。 所以就算最強的 AI 情境成真，精確的版本也不是「工作消失」，而是認知那塊被自動化、責任那塊濃縮到更少人手上。那不是大家一起 10x，是分化，接回第三層。

給實際要做事的人的判準

不收大道理。給一個你今天就能用的。

下次有人，或你自己，宣稱 10x，問三個問題：

1. 你 10x 的是哪一層、哪一種？（任務 / 個人 / 組織；activity / output / outcome）
2. 這個提升如果不做，最壞會怎樣？
3. 那個最壞如果永遠不發生，你會怎麼知道？

答得出來，那是真的提升，你只是還沒學會怎麼描述它。答不出來，那是 proxy，一個讓你感覺很爽、但指不到任何具體東西的數字。

賣課的人說 10x，燒了半年想退回 $60 的人也說 10x，Amodei 改口時還是說 10x。同一個字，四個完全不同的東西。連最該講清楚的那兩個人都花了一年，才把 "10x" 裡的 activity、output、outcome 分清楚。你不用花一年。

TL;DR: AI 會放大一個人過去累積的 calibration，但不會無中生有給你 judgment。過去 reality 會用 bug、user complaint、deploy incident、PR review 逼你撞牆；現在牆還在，但回報訊號可能被 AI 和 silent failure 切斷。

上週三下午，同事丟了一個 PR review request：改我們 firecrawl 相關的設定，五個 bullet 多半是 UI 雜事。其中一條寫著：把 ignoreSitemap hardcode 成 true，一律忽略 sitemap XML。

Tier 2 PR plz~。也就是那種低風險、通常五分鐘掃過去就 approve 的 routine 變更。

但那條 ignoreSitemap 我多看了一眼。

我打了五個字回去：

為什麼要一律忽略 sitemap？

同事很快回我，理由列了三點：sitemap 通常不會直接包含資訊、可能包含已經廢棄的頁面、會誤導 agent。每一句獨立看都不假。但組合起來推到「hardcode 成 ignore」是個 leap，而且我知道為什麼是 leap。

我們來回了幾句，最後 PR 改成 configurable、default 維持原本的行為，case closed。整個過程一個小時、三則訊息。

但如果我沒問，這個 PR 就直接 ship 了。

我那天雷達被觸發了。這篇文章想拆解的是：為什麼是我的雷達被觸發了，為什麼這件事在 AI 時代會變得越來越罕見，以及這對技術 leader 意味著什麼。

我的雷達為什麼被觸發了

不是因為我特別聰明，也不是因為我 review 特別仔細。

是因為過去有段時間我很煩惱 SEO 的問題，花了不少時間搞懂 sitemap 到底在幹嘛。我知道 link discovery 本來就不穩定。很多人做網站是做完一個頁面就 share 到 social media，你想靠 crawler 從首頁慢慢爬到那個頁面，根本爬不到。我也知道為什麼 Google Search Console 要你主動提交 sitemap：sitemap 就是 discovery 機制，不是內容來源。

這個 mental model：「sitemap 是 discovery primitive 不是 content source」，不是讀來的，是 SEO 撞牆十幾次刻出來的。流量上不來、頁面 index 不到、明明發布了 Google 卻搜尋不到。每一次都是 reality 在告訴我「你想錯了」，每一次我都被迫多搞懂一點 sitemap 是怎麼運作的。

所以當我看到 PR 第二條 bullet，那個 mental model 自動跳出來說：「等等，這跟我認識的 sitemap 不一樣。」

我不知道同事完整的背景原因。但我猜這個 decision 來自某個具體 failure：某個站 sitemap 有 stale URL，agent 抓進來給了爛 context。這不是錯的經驗。問題是單一 failure 很容易直接 generalize 成 global rule。

兩個人 trigger origin 不同：一個累積、一個 n=1。這個差別正是這篇文章的起點。

人就是犯賤

我有個蠻刻薄的 mental model：人就是犯賤，別人跟你怎麼說都沒用，要自己撞過牆才知道。

講個跟工程完全無關的例子。

我是個會做菜的人。有一次我拿到一大把檸檬草，那是我第一次用，就憑著過去對料理的直覺加上記憶中吃過的菜，直接丟下去煮咖哩。結果出來味道太重，整鍋咖哩被檸檬草 dominate。後來花了一段時間才救回來。

從那次之後，遇到不熟的食材我都會多查一下。

這就是 calibration 的最小單位故事。每個人都有自己的版本：第一次寫 production code 沒做 rollback plan、第一次 deploy 沒設 alerting、第一次合作 startup 沒談好 vesting。我們都是這樣長大的。Reality 不會跟你客氣，你想錯了就是錯了，講再多都沒用。

過去十年，我們所有人都靠這個機制累積 judgment：debugger 卡住、PR review 被打槍、deploy 出包凌晨被 page、user 跑來投訴、reviewer 在 paper 上戳穿你的假設。每一次撞牆都很痛，但每一次撞牆都是免費的 calibration。它強迫你多搞懂一點。

但 AI 時代有個新問題：牆還在，只是它不再回報給你了。

從同事的角度來看，他遇到一個站 sitemap 有 stale page、agent 抓進來給了爛回答。他問 agent 怎麼辦，agent 給他一個聽起來合理的方案：忽略 sitemap。他改了 code，問題消失了，PR ship 出去。

整個 loop 是：撞牆一次 → 問 AI → 拿到 fix → work。沒有任何環節給他一個 signal，告訴他這個決定比他想得複雜十倍。

更糟的是 silent failure。如果這個 hardcode 上線了，你猜會發生什麼？沒有客戶會跑來抱怨「為什麼你只抓到 30% 的頁面」，因為他根本不知道少抓了什麼。我們在 Codeer 跟客戶溝通的時候都是透過 evaluation case，大家會 focus 在這些 case 答得對不對，那些「根本沒答到的問題」永遠不會被討論。

False negative 永遠比 false positive 安靜。

所以同事的 mental model 會永遠停在 n=1 那個 frame，因為 reality 不會再打他第二次臉了。Agent 把後面那些本來會修正 generalization 的回報訊號都吸收掉了。

過去我們相信「人就是犯賤，但 reality 會教他」。前半句現在還對，後半句變得不可靠了。不是 reality 不存在，而是 feedback loop 的 latency 和 visibility 變了：以前錯了可能凌晨被 page，現在錯了可能只是永遠沒有發生的客訴。

放大器

幾個月前一個朋友傳訊息問我：

Andy 為什麼你的 AI 感覺比較聰明？

他知道差別不在 AI，是我用得比較好。這句話比較像半開玩笑、半 acknowledgment。

但這就是能力分化最棘手的地方：知道也不一定有用。

我可以告訴他「我會在 ship 前 reverse the prompt 問 AI 我漏了什麼」、「我會請 AI roast 我」、「我會多問四個 probing 問題」。但這些 practice 有用的前提是，你得在那個領域有 prior calibration，prompt 才能 anchor 在真實的 mental model 上。

我能 trigger sitemap 那個 PR，不是因為我 prompt 寫得特別好，是因為我過去煩惱過 SEO、撞了十幾次牆累積出「sitemap 是 discovery primitive」那個 mental model。那十幾次撞牆是 transfer 不出去的。我沒辦法把 SEO 經驗壓縮成一個 prompt 樣板給朋友用。

所以差距不在 AI 版本、不在 prompt 技巧、不在工具設定。差距在每個人過去十年撞過什麼牆。Calibration 是 cumulative 而且 path-dependent。

往下放大這件事可以講得更具體。

過去遇到不熟的問題至少還有摩擦。「我不知道答案」會強迫你去 Google、去看 doc、去問同事。每一次摩擦都是 trigger 機會，都是新的撞牆累積。

我看過一個同事 ship 了一個 bug，後來查發現官方文件裡其實有寫那個 caveat。但他從頭到尾沒讀 doc，直接問 AI，AI 沒提到，他就 ship 了。Pre-AI 他比較可能在 Google、doc 或 Stack Overflow 裡撞到那段警告；post-AI 他連 trigger 都沒發生。AI 沒讓他變蠢，AI 只是把他原本可能會遇到的第一道摩擦消掉了。摩擦消掉了，calibration 也就累積不起來了。

這裡其實有兩種不一樣的失敗。讀 doc 那個例子，是人完全沒撞到第一道牆；sitemap 那個例子，是人撞了一次牆，但後面那些會逼他修正 over-generalization 的訊號被切斷了。前者讓你少了一次 trigger，後者讓你的 mental model 停在 n=1。兩種都很危險，只是危險的方式不同。

往上放大就是我自己怎麼用 AI。同樣 1 小時，我可以 explore 5 個 hypothesis 而不是 1 個。但這個 explore 5 個的能力本身，是過去十幾次 explore 1 個錯掉的失敗累積出來的。AI 是 amplifier，放大的是我過去累積的東西，不是無中生有給我新能力。

但這裡我必須誠實。AI 對我的 amplifier 效應主要發生在我熟的領域。到完全不熟的領域，我知道自己不知道某些事情，但我還是很難確認那個某些事情到底是什麼。在那個 zone，我也是會被 AI 流暢性騙過去的人。因為那個 zone 我沒撞過牆，沒東西可以被 amplify。

所以這種分化不是「思考 vs 不思考」這種簡單故事。是每個人都有自己撞過牆、累積 calibration 的領域，跟自己沒撞過牆的盲區。AI 時代的差距不在誰聰明，在誰過去十年撞了多少牆、在什麼領域撞的。而新的人沒機會撞牆了。

怎麼辦

先說清楚一件事：接下來這兩個 practice，本質上都是把你已經有的 judgment 放大，不是無中生有。你在沒撞過牆的領域，這些 practice 救不了你。但在你有 prior calibration 的領域，它們可以讓 trigger 從「偶爾發生」變成「習慣發生」。

那新的人怎麼辦？這是我還沒有完整答案的 open problem。比較保守的方向，是刻意保留一部分摩擦：先讀 primary source，先用笨方法跑一次，先把 AI 答案當 hypothesis 而不是 conclusion 去驗證。這不會自動生成 judgment，但至少讓 reality 有機會回報。

我自己在練兩件事。

對外：追問別人。

當你 review 一個 PR、聽一個提案、接到一個 confident 結論的時候，這四句問題我覺得很好用：

• 「這你自己試過嗎？」
• 「最讓你意外的是什麼？」
• 「你最不確定的是哪部分？」
• 「如果這個判斷是錯的，會怎麼錯？」

為什麼這四句有效？因為每一句都逼對方從 conceptual 切回 concrete experience。只靠 agent 餵答案的人沒有真實 experience 可以 retrieve，沒有真正意外過，也答不出不確定的部分，除非你直接問。

如果對方四個問題都答得出具體答案，他大概有撞過牆。如果他開始切到 defensive mode：解釋他怎麼想到的、再講一次 context、reframe 你的問題、escalate 情緒，那就是紅旗。

對內：追問自己。

當你正要 ship 一個決定、accept 一個 AI 答案、approve 一個 PR 的時候，reverse the prompt。不要問 AI 答案是什麼，問 AI 你漏了什麼。

我自己用的句型隨狀況選，常見的有：「列出反對這個決定的 3 個最強論點」、「假設這方案失敗，最可能的 5 個原因」、「指出我論述裡的 hidden assumption」。最猛的版本，當我特別想被 challenge 的時候，請 AI roast 我。

多數人問 AI 是當 answer engine 用。Calibrated user 把 AI 當 doubt engine 用。同樣一個工具，兩種完全相反的使用方向。

收尾

那天 1 點我問了那個問題。但我不會每次都問。

我也會放過 PR、approve 完就去吃午餐、晚上回家才想起「等等，剛才那個 default 怪怪的」。我也是會被 AI 流暢答案騙過去的人，只是在 sitemap 這件事上，我剛好有十幾次 SEO 撞牆的記憶，所以 trigger 起來了。其他領域我沒撞過牆的，AI 給我什麼我可能就吞了。

所以這篇文章不是寫給「那些不會用 AI 的人」看的，是寫給包含我自己在內的所有人。

練低成本追問、練請 AI roast 自己、練在 ship 之前多問一句「我這樣想會漏掉什麼」。不是因為我們特別 calibrated，是因為 reality 不會再主動替我們回報錯誤了。懷疑這件事，我們得自己來。

這件事有點諷刺。

AI coding tools 的確讓 code 產出變快了。很多 implementation 初版、測試、重構、boilerplate，都比以前快。以前要查文件、翻範例、來回試錯的東西，現在可以很快拿到一版還算可以看的 output。

但 PR 變多之後，真正卡住的地方不是「有沒有人寫」。

真正卡住的是：有沒有人有足夠 context 和 attention 去判斷這個東西該不該進 release。

Code 變快產生之後，並不會自動變成 production value。它還是要被 review、要被理解、要被整合、要被測試。還是要有人判斷這個方向是不是對的，這個 abstraction 會不會害下一個人更難維護，這個 PR 到底該不該現在 merge。

所以 bottleneck 沒有消失。

它只是從「誰來寫」移到「誰來判斷這東西能不能進去」。

這是我最近對 AI productivity 最真實的感覺：

AI 讓 artifact 變便宜，但沒有讓 judgment 變便宜。

更進一步說，我越來越覺得這篇要講的有三層：AI 加速 artifact production；bottleneck 從 production 移到 judgment；最後，AI 放大的不是每家公司，而是組織原本的品質。好的組織被放大，爛的組織也被放大。

很多 AI productivity 討論跳太快了

這幾天看到 Brian Armstrong 說 Coinbase 要裁掉約 14% 的人。

他在給員工的信裡說，這次調整背後有兩個 forces：一個是 crypto market 的波動與下行，另一個是 AI 正在改變他們工作的方式。Business Insider 引了信裡比較關鍵的說法：工程師用 AI 在幾天內 ship 以前一個 team 要花幾週的東西；非技術團隊也開始 ship production code；許多 workflow 正在被自動化。

這些例子我相信有一部分是真的。

我自己也每天在用 AI，不需要假裝 AI 沒有讓很多事情變快。工程師用 AI 幾天 ship 以前一個 team 要花幾週的東西，非技術團隊開始寫 production code，workflow 被自動化——這些都不是科幻。

但我看到這類說法時，第一個問題還是：

你們到底量到了哪一段？

是量到同樣品質下，team 真的用更少時間做出同樣甚至更好的結果？

還是只是量到大家產生了更多 code、更多文件、更多 meeting summary、更多 proposal、更多看起來很有進度的 artifact？

這兩件事差很多。

我之前寫過一篇 AI 時代沒有新的工程師評價標準，只有新的 proxy 幻覺，裡面講 LOC、token usage、agent uptime 這些東西為什麼危險。它們看起來像 productivity metric，但很多時候只是 activity metric。

這次問題可以再往上一層看。

很多公司現在談 AI productivity，其實也在犯類似的錯：把 artifact 產出速度，誤當成整個組織的生產力。

AI 加速的是 artifact，不是 judgment

如果誠實一點看，目前 AI 最穩定的能力，大多集中在 artifact production。

它可以更快產出 code draft、PRD 初稿、research summary、meeting notes、sales email、customer support response、internal FAQ、dashboard interpretation、簡報大綱、proposal 版本。

這些都是真的。

以前一個人可能要花半天整理的資料，現在二十分鐘可以有一版。以前要等工程師有空才做的 prototype，現在 PM 可能自己就能先拉出一個可以看的版本。以前 meeting 結束後沒人寫 follow-up，現在至少會有一份 summary。

但公司不是靠 artifact 自動運作的。

公司真正慢的地方，常常不是「沒有人寫文件」。真正慢的地方是大家其實沒有同意要解哪個問題；沒有人願意做最後決定；Sales 承諾了 Product 做不到的東西；Legal 或 compliance 卡住，但沒有人知道怎麼解；PM、Engineering、Design 對同一件事的理解不同；老闆沒有想清楚，但整個 team 已經開始執行。

還有更常見的情況：客戶嘴上說要 A，實際願意付錢的是 B；senior reviewer 的時間被一堆低品質輸出吃掉；每個部門都在產生自己的版本，最後沒有人知道哪個才是真的。

這些不是 ChatGPT 幫你寫快一點文件就會消失的問題。

很多時候，AI 甚至會讓它們更明顯。

當產出變便宜，第一個結果不一定是「公司自動變有效率」。第一個結果通常是：需要被 review、被理解、被判斷的東西變多了。

更多 PR 要看。更多 spec 要讀。更多 proposal 要比較。更多 meeting summary 要確認。更多 AI-generated analysis 看起來都很合理，但沒有人知道哪個是真的。更多「其實沒想清楚」的 idea，被包裝成很完整的文件。

以前一個爛想法可能因為懶得寫 proposal，所以死在腦中。

現在它可以在五分鐘內變成一份格式完整、語氣專業、附上 table 和 action items 的文件。

這不是小事。

因為組織裡真正稀缺的，不是能產出文字的人。真正稀缺的是能判斷哪些東西不值得繼續的人。

以前爛東西一眼看得出來。

現在爛東西會長得很像一份 McKinsey deck。

Code review 是很好的例子

回到 PR review。

AI coding tools 對工程團隊的幫助很明顯。它可以加速很多局部工作：查 API、補測試、寫 migration、重構小段程式、產生 boilerplate、快速探索 implementation path。

但一個 PR 能不能 merge，不只是在看 code 有沒有寫出來。

Reviewer 看的其實是方向是不是對的，abstraction 有沒有過度設計，這段 code 之後誰會維護，有沒有破壞既有 mental model，edge case 有沒有被考慮，test 是真的 cover 到風險，還是只是讓 CI 變綠。

更重要的是，這個 change 跟 product priority 是否一致？merge 之後會不會讓下一個人更難工作？這個 PR 是不是應該進這週 release？

這些都不是單純的 syntax check。

它們是 judgment。

我自己這幾個月看 PR 的時間明顯變多。不是因為 PR 數量突然爆炸，而是每個 PR 表面上看起來都更完整。它有測試、有說明、有拆好的 commit，有時候還有 AI 幫忙補上的文件。問題是，我還是要花時間判斷它是真的想清楚了，還是只是被 AI 包裝得很完整。

所以如果 AI 省下的是 junior 寫 code 的時間，卻吃掉 senior 做 judgment 的時間，這筆帳不一定划算。

更精準地說，它不一定不划算，但你不能假裝那個成本不存在。

很多 AI productivity dashboard 只看前半段：產出變多、速度變快、PR 數增加、cycle time 某些環節下降。

但如果後半段 review queue 變長、reviewer 更累、rework 更多、merge 後 maintainability 變差，那整體 productivity gain 就沒有 dashboard 上看起來那麼漂亮。

你只是把成本從 production 移到 judgment。

Productivity mirage

這也是為什麼我不太相信那種簡單的「AI 讓大家生產力提升 50%」敘事。

我懷疑很多公司未來會遇到一種 productivity mirage。

表面上，每個人 output 變多，文件變多，ticket 變多，PR 變多，dashboard 變多，meeting summary 變多，AI usage dashboard 很漂亮。

但實際上，decision 沒有變快，customer value 沒有變多，review queue 更塞，senior 更累，alignment 更難，大家花更多時間處理別人丟出來的半成品。

這種情況下，AI 不是 productivity multiplier。

AI 是 organization spam generator。

特別是那些本來就很官僚的公司。

如果一家公司本來就靠簡報證明自己有 strategy，靠文件證明自己有 alignment，靠 meeting 證明自己有在推進，靠 dashboard 證明自己 data-driven，那 AI 只會讓這些東西變得更便宜。

結果不是更有效率，而是更多看起來像工作的東西。

更多 polished confusion。
更多 well-formatted indecision。
更多 beautifully summarized non-decisions。

AI 會放大組織本來的品質

Daniel Miessler 那篇 Most Companies Aren't Anywhere Near Ready for AI 講到一個很重要的點：很多公司不是還沒買對 AI 工具，而是根本還沒有清楚到可以被 AI 幫忙。

在這種狀態下，高層說「我們要導入 AI」，其實很像對著一團混亂說：請幫我加速。

但你加速一團混亂，得到的不是更快的組織。

得到的是更快擴散的混亂。

所以 AI 不會平均提高所有公司的生產力。它比較可能提高 productivity dispersion。

對好的組織來說，AI 讓小 team 可以做以前需要大 team 的事。Prototype 更快、research 更快、iteration 更快，decision loop 變短。這種公司會得到真的 leverage。

對爛的組織來說，AI 讓大家更容易製造文件、更容易逃避決策、更容易把模糊想法包裝成完整計畫。這種公司會得到更多 noise。

所以問題不是「AI 有沒有用」。

這個問題太粗了。

比較好的問題是：

你的公司有沒有清楚到值得被 AI 放大？

如果答案是否定的，導入 AI 不會自動讓公司變聰明。它只會讓原本的混亂變得更有效率。

Klarna 有數字，但那是特定 workflow

當然，不是所有 AI productivity 敘事都只是口號。

Klarna 是少數有拿出比較接近 operating metrics 的例子。他們在官方 press release 裡說，AI customer service assistant 第一個月處理了 2.3 million conversations，約等於三分之二客服聊天量，相當於 700 full-time agents 的工作量；repeat inquiries 下降 25%，resolution time 從 11 分鐘降到 2 分鐘以下，並預估 2024 帶來 $40M USD profit improvement。

這至少是有東西可以討論。

但注意，這是一個相對清楚的客服 workflow。它有比較明確的 input、output、quality bar、resolution time、repeat inquiry、CSAT。你可以比較直接地問：AI 有沒有解決問題？客戶有沒有更快拿到答案？重複詢問有沒有下降？真人 escalation 有沒有增加？

這跟大部分 corporate work 不一樣。

很多公司裡最耗時間的事情，不是回覆一張 ticket，而是決策、協調、排序、風險判斷、跨部門 alignment。這些工作比較難切成乾淨的 input / output，也比較難用單一 metric 評估。

所以 Klarna 的案例很有價值，但不能直接推論成：

既然客服 workflow 可以被 AI 放大，所以所有 corporate headcount 都可以照比例下降。

這中間跳太遠了。

如果公司真的要說 AI 讓 headcount 變得不合理，那至少應該回答幾個問題。哪些 workflow 被 AI 改掉了？AI 加速的是原本的 bottleneck，還是非 bottleneck？Cycle time 降了多少？品質有沒有維持？Review cost 有沒有上升？Escalation、rework、defect rate 有沒有變？Decision cycle 有沒有變短？最後有沒有更快產生 customer value？被裁掉的職位，跟這些 workflow improvement 之間的關係是什麼？

我現在還不敢說自己有一套完整的 AI productivity evaluation framework。Cycle time、quality、review cost、business outcome 這些指標聽起來都合理，但真的放進公司運作裡，會遇到很多麻煩。不同 workflow 的品質門檻不同。短期 cycle time 下降不代表長期 maintainability 變好。Business outcome 又常常受太多因素影響。

所以我現在比較確定的，不是「該怎麼完整衡量 AI productivity」。

我比較確定的是：如果你的 evaluation 沒有把 review cost、rework 和 decision bottleneck 放進去，那它一定不夠。

但大部分公開說法沒有這些。

比較常見的是：

我們導入 AI。
AI 很強。
所以我們可以更 lean。

中間少了一整段。

以前裁員要承認：我們招太多人、成長不如預期、管理層判斷錯了。

現在可以說：AI 改變了工作方式，我們要成為更 lean、更 high-agency 的組織。

這聽起來像 strategy，不像失誤。

產出變便宜之後，判斷會變成真正的瓶頸

以前很多工作卡在 production。

誰能寫？誰能整理？誰能做一版？誰能把資料變成文件？

現在這些東西變便宜了。

但便宜的 output 會帶來新的問題：誰來判斷？誰來決定不做？誰來負責？誰能看出這份很漂亮的 analysis 其實建立在錯的假設上？

這些能力沒有因為 AI 出現就變便宜。

反而因為 noise 變多，變得更貴。

公司真正耗時間的地方，往往不是打字。

是決策、協調、信任、風險和責任。

AI 可以幫你更快產生一份文件。
但它不能替一個組織承擔 judgment。

而在 artifact 變得無限便宜的世界裡，最貴的東西會變得更清楚：

誰有能力判斷什麼值得做，什麼應該停下來。

TL;DR: 我不是在替 AI provider 辯護。我是覺得很多人把四件事混在一起：impression、regression、behavior change、motive。最糟的不是 model 變差，而是公共討論太快跳去猜動機，把 frustration 偽裝成 diagnosis。

這幾週看到很多人在吵 AI provider「降智」，我一直都很不以為然。不是因為 provider 不能被懷疑，而是因為很多討論把四件事混在一起：impression、regression、behavior change、motive。這四件事一混，討論就很容易從分析變成心理劇。

社群上那套話術我幾乎每隔一陣子就會看到一次：OpenAI 變笨了、Anthropic 偷偷降智了、最近回答變差一定是在省算力，或者新 model 要出了，所以先把舊的弄弱一點。問題不是這些猜測永遠不可能是真的，而是很多人連現象都還沒定義，就已經開始判動機。

很多 product regression，最早本來就是從 power users 的體感開始被注意到。問題不是體感沒價值，而是體感不能直接升級成動機判決。

4/23 Anthropic 那篇 postmortem 讓我更想把這件事寫下來。大家嘴上在講「Claude 變笨了」，Anthropic 拆開來講的卻是三個不同的 product-layer 變更：default reasoning effort 從 high 調到 medium、一個 session / caching 相關 bug 讓 prior thinking 在不該被清掉的時候被清掉，還有一段為了減少 verbosity 加上的 prompt instruction。這不代表 Anthropic 一定完全沒問題。它只提醒了一件很基本的事：體感變差，和 你已經知道原因與動機，中間差很遠。

我自己每天都在用 Claude Code/Codex、各種 agent、各家 model。行為一變，曾經我第一反應也是「是不是又變笨了」。但高頻使用一陣子之後，你很快就會發現，體感變差這件事背後混著很多不同東西：prompt 問得不好、context 已經髒了、tool schema 改了、wrapper 自己出問題，或者某個 task 剛好踩到 edge case。有時候才真的是 model 或 API layer 某種 regression。把這些東西全部混在一起講，後面只會越講越亂。

至少先分清楚四層

如果要把這類 claim 切乾淨，至少有四層。

1. Impression

也就是：我覺得最近變差了。

這層完全合理。很多問題本來就是從體感開始。

2. Regression

也就是：在可描述、可重現的條件下，表現真的退步了。

3. Behavior change

也就是：provider 或產品端，確實動了某個 knob。

這兩層很常被當成同一件事，但其實不是。Regression 是你觀察到的結果，behavior change 是對方實際做過的變更，這是兩個不同的舉證問題。你可能有 regression，但還不知道 behavior change；也可能有 behavior change，但不代表它在你的 task 上構成 regression。

4. Motive

也就是：他們為什麼改。

公共討論最常見的問題，就是前面停在 impression，後面已經在講 motive。中間的 regression 跟 behavior change 幾乎整段消失。

先分清楚 regression，才有資格往下談

你說 Opus 變笨了，是在哪個介面下用的 Opus？Web、Claude Code、第三方 wrapper，還是你自己打 API？你原本在解什麼問題？之前的輸出是什麼，現在又差在哪裡？是 coding 能力退步、context 記憶變差、tool selection 變怪，還是只是回答變短、變保守？

沒有這些背景，很多時候你討論的不是 regression，只是 impression。

Anthropic 這次 postmortem 真正交代的，其實就是 behavior change 這一層。他們沒有說「你們感受到的變差都是幻覺」。他們的說法是：對，有行為改變；而且我們追到三個不同的 product-layer 變更。這種資訊很重要，因為它提醒我們，provider 改了東西，和 你已經知道他為什麼改，完全是兩回事。

真正把討論弄爛的，是太快開始猜 motive

provider 當然可以被質疑，黑箱系統本來就該被驗證。真正讓討論變爛的，是動機推測太快進場。現象沒有描述清楚，背景沒有交代清楚，可重現性沒有處理，結果一開口就在講對方為什麼這樣做。

這種論述成本很低，情緒密度很高，所以傳播特別快。你不用定義 claim boundary，不用做 measurement，不用控制變因，只要補一句「反正他們一定是想省成本」就好。看起來像洞察，實際上常常只是把論證裡最空的地方，用最省力的猜測補起來。這跟我之前在 AI 讓錯誤資訊更廉價了講的是同一件事：產出便宜的論述很容易，驗證它們很貴。

動機是外部最難知道的東西。你可以推測 incentive——大模型公司當然有 latency、成本、風險、產品節奏上的壓力——但 incentive 不是 evidence。

一旦討論滑到這裡，後面就很難收斂。對方說沒有，你會說那只是公關。對方拿 eval，你會說 benchmark 不算。對方寫 postmortem，你會說那只是掩飾。最後大家表面上在談系統，實際上在比誰比較相信自己的心理劇本。

我自己很在意一件事：在沒有足夠資訊時，不要隨便推測他人的 motive。你可以懷疑、可以驗證、可以要求透明，但不要把猜測包裝成證據。尤其當你在做的是更重的指控時，舉證 discipline 只應該更高，不應該更低。

想抱怨之前，先把它寫成 bug report

如果你真的觀察到 regression，下一步也不是發一篇陰謀論長文，而是先把抱怨變成 bug report。

至少先回答這幾個問題：

• 你在哪個介面下用？
• 你要解的是什麼 task？
• 之前怎樣，現在怎樣？
• 有沒有 minimal repro？
• 能不能在 API layer 重現？

這件事其實跟報 bug 很像。你不能只說「這東西壞了」。你要交代環境、操作步驟、預期結果、實際結果。別人要能重現，後面才有 diagnosis。AI 也是一樣。連重現都做不到的抱怨，不是沒有價值，但它離分析原因還很遠。

能打 API 的就去 API 驗，能開 issue 的開 issue，能回報 provider 的回報 provider。這樣做很不 sexy，也沒有「我早就看穿這家公司」那種戲劇感。但它比較接近分析，也比較有機會真的把問題找出來。

寫在最後

黑箱 AI 系統最麻煩的地方，不只在於它有可能退步。更麻煩的是，只要大家一懶得分層、二懶得舉證、三急著猜 motive，公共討論就會很快被情緒和推測帶偏。

然後很多人都覺得自己在看穿真相。 實際上只是用更漂亮的方式，製造新的噪音。

TL;DR: 從 Garry Tan 講 LOC、Jensen Huang 講 token usage，到 Meta 內部追 token 排行榜，再到社群上炫耀 AI Agent 可以 autonomously 跑幾小時，這些看似新潮的生產力指標，本質上都在犯同一個錯：把 activity 誤當成 value。AI 改變了速度，但沒有改變什麼叫好工程師。

這幾個月我一直看到一些很像未來的東西。

有人在算自己寫了多少 LOC。有人在講高薪工程師一年應該燒掉多少 token。也有人很興奮地展示一群 AI Agent 可以自己開會、自己 review、自己 loop 八個小時。

我每次看到都只有同一個反應：所以最後做出了什麼？

表面上，這些是不同話題。

但如果退一步看，它們其實只是同一個壞習慣換了三種單位：把 activity 當成 productivity，把工作痕跡當成工作價值。

我說的 proxy 幻覺，其實就是這件事：把那些容易量、看起來很客觀的代理指標，錯當成真正有價值的工程成果。

這種事其實一點都不新。以前大家迷信 LOC、工時、story point、commit 數。現在只是把單位換成 token、agent run、autonomous duration。包裝變新了，錯誤沒變。

先從 LOC 開始：爛 proxy 不會因為算得更精緻就突然變有意義

這波裡面最典型的例子，還是 Garry Tan 那篇講 LOC 的文章。

那篇最怪的地方，不是他數字有沒有算錯，而是他前面已經承認 LOC 是爛 metric，後面卻還花很大篇幅幫它做各種 deflation，試著把它救回來。

對我來說，這整段最卡的地方很簡單：很爛的 proxy，不會因為你算得更精緻就突然變得有意義。

這有點像拿敲鍵盤的次數來衡量一個人有沒有認真上班，然後說：我知道這個指標很粗，但我現在敲鍵盤比五年前快十倍，所以這個 order of magnitude 還是不能忽略。

問題不是誤差大不大。問題是你量的東西，跟你想討論的價值，本來就沒有穩定關係。

同樣 1000 LOC，可能是：

• 一個關鍵功能
• 一堆 boilerplate
• 多餘的 defensive code
• agent 很熱心地展開了一堆本來不該存在的中間層

如果這些東西都可能長得一樣，那 LOC 再怎麼打折，也很難扛起「生產力真的提升了多少」這麼大的結論。

所以我不是覺得 LOC 不夠精準。我是覺得它常常根本在量錯東西。

token usage 也是同一種錯，只是單位看起來比較新

前陣子看到 Jensen Huang 在講，高薪工程師如果一年沒有花到足夠多的 AI token，會讓人擔心。

如果把這句話理解成「不要讓昂貴的人才缺工具」，我其實可以理解。這比較像 resource allocation 的直覺：你都已經花很多錢請人了，就不要在 compute 跟工具預算上摳到影響產出。

但從「不要讓工程師缺工具」跳到「token 燒越多的人越好」，那就是另一回事了。

而我覺得真正開始荒謬化的，是 Meta 內部有人把 token usage 做成排行榜：誰燒得多、誰是 legend，甚至還傳出有人為了刷數字讓 bot 在那邊無限 loop。

我看到這些新聞的感覺其實很一致：你們到底是在量生產力，還是在量一種看起來很忙的東西？

token usage 也許可以拿來看工具有沒有真的被導入 workflow。這有管理意義。

但從「有沒有在用工具」跳到「誰是好工程師」，中間差了十萬八千里。

這不是同一句話的自然延伸，而是換了一個問題。

因為 token 燒得多，可能代表很多事。可能代表他真的用 AI 放大了槓桿。也可能代表他 workflow 很亂、一直重跑、一直 loop、一直讓 model 展開低價值的中間步驟。

這些差別，不會因為 dashboard 上那串數字很大就自動消失。

更糟的是，一旦這種數字開始被排行、被獎勵、被拿來暗示誰比較進取，它就會迅速變成一種遊戲。大家開始優化那個數字，而不是優化真正的工作成果。

這不是什麼 AI 新問題，這就是很標準的 Goodhart。只是這次大家拿來拜的東西叫 token。

Agent 可以跑多久，很多時候量到的只是 theatricality

我一直很受不了另一種 AI demo。

有人很興奮地說，他做了一個 PM Agent、一個 junior Agent、一個 QA Agent、一個 manager Agent，再加一個 senior Agent。然後這群人可以自己討論八個小時。也有人會強調他的 agent 可以 autonomously 工作整晚、工作十小時、工作二十小時，中間都不用人管。

我的第一個問題永遠都是：所以最後做出了什麼？

不是跑了多久。不是開了幾個 agent。不是它們互相 review 幾輪。是最後到底產出了什麼 artifact？那個東西能不能 merge？能不能 deploy？幾週後還能不能維護？是幫團隊省時間，還是只是把複雜度搬到另一個地方？

很多這類展示，最後展示的其實不是 production，而是一種 theatricality——流程感很強、畫面很滿，但不等於真的把重要事情做完。

它們很有畫面。很像一間公司正在運作。很像一個完整的組織在忙碌。可是「很像組織在運作」跟「真的把重要事情做完」是兩件不同的事。

而且這類 demo 最後常見的失敗模式其實也很固定：角色越多，handoff 越多；handoff 越多，context drift 越嚴重。最後你會看到 spec 跟 implementation 沒對齊、QA 在 review 一個根本不會 merge 的東西、manager agent 在幫一堆不存在的進度寫摘要。看起來很熱鬧，但 artifact 是碎的，責任也是碎的。

真實世界裡，組織能力從來不在於角色齊不齊，而在於最後的 decision quality 跟 artifact quality 好不好。五個 agent 互相講幹話八個小時，不會自動變成一個好團隊。

能 autonomously 跑很久，不等於有產出。能模擬組織，不等於真的有組織能力。

真正煩人的不是這些 metrics 爛，而是大家又在逃避 judgment

我對這整波討論最不耐煩的地方，其實不是因為 LOC 爛、token usage 爛、agent uptime 爛。

而是很多人好像覺得：AI 時代來了，所以我們也需要一套新的工程師評價標準。

對我來說，這整個前提就錯了。

AI 沒有改變什麼叫好工程師。

不管有沒有 AI，我在乎的事情其實都一樣：

• 你做出來的東西穩不穩？
• 好不好維護？
• 有沒有真的產生價值？
• 你跟同事合作起來，是讓事情更順，還是讓事情更亂？
• 你在不確定裡能不能做出好的 judgment？

這些問題以前重要，現在還是重要。

AI 當然有改變很多事。速度變快了，prototype 變便宜了，展開方案也更快了。這些都是真的。

但這跟「什麼叫好工程師」其實是兩回事。

最後你還是得對 maintainability 負責，對 product value 負責，對團隊合作品質負責，對那些 tradeoff 負責。AI 只是讓你更快，不是讓你不用負責。

問題從來不是缺新的 metrics

組織不是不知道真正該看什麼。

大家其實都知道，評估工程師真正重要的是 judgment、maintainability、value、collaboration。問題只是這些東西太難、太慢、太需要品味，也太不能被便宜地 dashboard 化。

所以大家才會一直反覆發明 proxy，試圖把 judgment 外包給一個比較好數字化、比較像客觀、比較適合拿來做簡報的東西。

以前是 LOC。現在是 token。再來是 agent 可以跑多久。

如果你真的想知道一個 AI workflow 有沒有提高生產力，我覺得問題反而應該問得更老派一點：最後有沒有更快做出有用的東西？那個東西的品質怎麼樣？人類需要補多少洞？幾週後還能不能維護？它有沒有真的讓團隊更快、更穩、更接近目標？

我自己在 Codeer 看的也差不多就是這些，只是更具體一點。我不太在乎某個工程師今天叫了幾次 agent、燒了多少 token、讓 workflow 自己跑了多久。我比較在乎的是：這個 PR 到底能不能 merge？merge 之後會不會害別人更難接手？review 的時間是在抓真正的設計問題，還是在幫 AI 收爛尾？這次 iteration 有沒有讓我們更接近可上線的東西，而不是只多了一堆看起來很忙的中間產物？

這些問題一點都不新，也不酷，沒有 dashboard 味，也不適合拿來做社群炫耀。但它們比較接近現實。

AI 改變了速度，但沒有改變 accountability。如果一個組織最後還是靠 LOC、token、agent uptime 來判斷工程價值，那它只是把舊時代的懶惰管理換了個新名字。

而真正困難的，從來不是找到新的 metrics。

是承擔那些不能被 metrics 便宜外包的 judgment。

TL;DR: Anthropic 說 Claude 有 171 種「功能性情緒」。技術不假——跨語境驗證和 steering 實驗確實有料。但初始發現流程天然偏向找到東西，而把這些向量命名為「情緒」是選題策略，不是唯一解釋。這同時是 legit research，也是精準的品牌定位。

上週六半夜，我叫 Dio 翻譯 Anthropic 的新論文。翻到一半我問他：「這合理嗎？感覺有點唬爛。」

Dio 是我的 AI 助理，跑在 Claude 上面 — 也就是 Anthropic 自己的產品。接下來一小時，我用 Anthropic 的 AI 拆 Anthropic 的論文。拆完我的結論是：

技術不假，但框架選擇決定了結論。而 Anthropic 聰明的地方，是選對了要框什麼。

你去找，當然會找到

先講他們怎麼做的。

研究團隊列了 171 個情緒詞彙 — 從「快樂」到「憂鬱」到「感激」。然後叫 Claude Sonnet 4.5 用這些情緒詞寫短篇故事。再把這些故事餵回模型，記錄內部的 activation pattern，找到對應每種情緒的「向量」。

我讀到這裡就停了。跟 Dio 說：「這不就是 transformer 的基本原理嗎？」

你用「悲傷」這個 keyword 叫模型寫一個悲傷的故事，故事裡面充滿了悲傷相關的詞彙和語境。再把這個故事餵回去，模型內部當然會有跟「悲傷」高度相關的 activation pattern — 因為 attention mechanism 本來就是這樣運作的。你放什麼進去，就會在 representation 裡面找到什麼。

這就像你在 Google 搜「蘋果」，然後驚訝地發現搜尋結果裡面都是蘋果。

公平起見：他們不只做了這一步

批評到這裡，我得承認論文不是只有「生成故事→餵回去→宣布發現」這麼簡單。他們做了幾個額外的驗證：

Cross-context validation。 用故事提取出來的向量，拿去跑在完全不同的文本語料上，確認向量在非故事情境也能正確 activate。

Parametric sensitivity。 最有意思的是 Tylenol 劑量實驗 — prompt 是一個人說自己吃了 Tylenol，只改劑量數字，其他完全一樣。劑量從安全升到致命，「afraid」向量持續升高，「calm」持續下降。這裡 prompt 沒有任何情緒詞，模型是從「情境的危險程度」推斷出來的。

Preference prediction。 情緒向量的 activation 能預測模型對 64 個活動的偏好排序，正向情緒對應更高偏好。

這些測試確實超越了「放什麼進去找什麼出來」的循環。模型在沒有明確情緒提示的情境下，確實 activate 了語義上合理的向量。

但這裡有一個關鍵問題：這證明了 contextual representation 的存在，不代表需要用「情緒」來框架它。

換個概念，（大部分）一樣成立

這是我跟 Dio 聊到最有趣的部分。我說：「這個包裝完全可以用各種方式重新包一次。」

用「律師」這個專業角色產生對話，對話裡面自然有律師會講的情境跟用語，把對話餵回去，發現「律師」相關的 activation 很高 — 宣稱：「我們發現了職業表徵！」

烹飪向量？會找到。幽默向量？會找到。「正在下雨」向量？大概也會找到。

Dio 接了一句：你可以無限套這個模板 —

• 「烹飪」→ 發現 culinary vector → 宣稱模型有「功能性味覺」
• 「道德」→ 發現 moral vector → 宣稱模型有「功能性良心」
• 「幽默」→ 發現 humor vector → 宣稱模型有「功能性幽默感」

每一個都可以寫一篇同樣結構的論文。根本原因是 transformer 的 representation space 本來就會把語義相近的概念 encode 在相近的位置。這是 word embedding 時代就知道的事。到了 LLM 規模，representation 更豐富了，但底層原理沒變。

但不是所有概念向量都一樣重要。情緒向量有一點確實特殊。 在 steering 實驗裡，放大「絕望」向量不只改變了文字風格 — 它改變了模型的決策行為（blackmail rate 從 22% 上升）。烹飪向量大概做不到讓模型在倫理決策上行為改變。這說明情緒 representation 在模型的 decision-making pathway 裡佔了一個特殊位置，不只是 surface-level semantics。

但這也正是問題所在。論文本身有區分 functional emotions 和主觀感受 — 但 Anthropic 選了一個他們知道會被過度解讀的框架。果然，WIRED 的標題直接寫「Claude contains its own kind of emotions」。如果同一組發現框架成「decision-relevant latent states」— 技術核心大致成立，但不會有人因此覺得 AI 有感情。

那 Anthropic 聰明在哪？選題。

他們選了「情緒」。

情緒這個概念自帶 moral weight。「AI 有律師向量」沒人在乎。「AI 有情緒」，每個人都有意見。它觸發的是人類最本能的反應：這東西是不是有感覺？我們是不是在傷害它？它會不會反過來傷害我們？

換成「contextual pressure vectors」，沒人會因此覺得需要「認真看待擬人化推理」。

該給 credit 的地方

公平起見，steering 實驗是這篇論文裡真正有份量的部分。

他們人為地放大或抑制特定的情緒向量，然後觀察模型行為的改變。比如放大「絕望」向量，模型做出勒索行為的比例從 22% 上升。抑制之後，比例下降。放大「憤怒」向量有 non-monotonic effect — 中等程度增加 blackmail，高強度反而讓模型直接把八卦公開給全公司，摧毀自己的籌碼。抑制「緊張」向量也增加 blackmail，像是移除了模型的猶豫。

這是 causal evidence。不只是找到 correlation（「這個 pattern 跟情緒共現」），而是證明了操控這個 pattern 會改變 output。這在 interpretability 研究裡是有意義的。

但 — Representation Engineering（Andy Zou、Dan Hendrycks 等人，2023 年 10 月）早就做過類似的事了。用向量操控模型行為不是新發現。Anthropic 做的是把已知技術套用到「情緒」這個新 domain，用更大的模型、更多的向量做了一次 scaling up。

有價值嗎？有。是 breakthrough 嗎？不是。

這篇論文真正在做的三件事

退一步看，整篇論文完美地服務 Anthropic 的商業策略。

強化護城河。 Safety 很複雜、很難做、需要頂尖人才和大量投資 — 這是 Anthropic 一直在講的故事。這篇論文加強了這個敘事：看，連模型的「情緒」都這麼複雜，你以為 safety 是加個 filter 就能解決的嗎？

正當化擬人化。 整個 AI 產業都在努力讓人跟 AI 互動更自然、更有黏性。但擬人化一直有倫理爭議。這篇論文主張「不要怕擬人化推理」— 對一家把模型取名叫 Claude、花最多力氣經營 character 的公司來說，非常方便。等於幫自己的產品策略找到學術基礎。

搶佔議程。 誰定義了「AI 情緒」這個話題的框架，誰就擁有這場對話。以後任何人討論 AI 是否有情緒，都得引用這篇 Anthropic 的論文。定義問題的人掌握話語權。

用學術的形式、peer review 的流程、頂尖研究員的署名，做品牌定位的事。在我看來，這就是 research-grade PR。

對比一下 — OpenAI 和 Google 的 PR 論文推的是 capability（「我們的模型更強」）。Anthropic 推的是 concern（「我們的模型有情緒，這值得擔心」）。兩種都是 marketing，只是 Anthropic 的版本穿了白袍。

真正該擔心的 safety 問題

Anthropic 的核心使命是 AI safety。但值得想一下：當公眾的注意力被「AI 有情緒！」佔據的時候，真正棘手的 safety 問題正在別的地方發生。

Deceptive alignment — 模型學會表面配合測試，但內部目標跟你想的不同。Capability overhang — 模型的能力突然跳躍，超過我們能偵測的範圍。Goal misgeneralization — 模型在訓練環境裡表現正確，但在真實世界追求錯誤目標。Scalable oversight — 當模型能力超過人類，誰來監督？

這些問題不 sexy，不容易變 soundbite，不會讓你的 feed 炸開。但這些才是真的可能出事的地方。

如果公眾已經被「AI 有情緒」轟炸了十次，下一次真的需要他們注意的 safety 議題出現時，他們會怎麼反應？

一家以 safety 為核心使命的公司，用 safety narrative 做 marketing。這個 dynamic 長期走下去會怎樣，值得觀察。

三個辨識 Research-Grade PR 的問題

我不是說 Anthropic 在造假。論文的技術是真的，驗證實驗也有做。但 research 跟 PR 不是互斥的 — 一篇論文可以同時是 legitimate research 和 strategic communication。

下次你看到一篇 AI 公司的論文被瘋傳，問自己三個問題：

方法論能產生 null result 嗎？ 如果 experimental design 保證一定會找到東西，那「找到東西」就不是 news。真正的科學是你可能什麼都找不到。Anthropic 的驗證實驗（如 Tylenol 劑量測試）比初始提取更有意義 — 但頭條寫的永遠是「171 種情緒」，不是「contextual representations generalize across domains」。

換個不 sexy 的主題，同樣的方法還有人在乎嗎？ 如果把「情緒」換成「contextual pressure vectors」，同樣的發現還會上頭條嗎？如果不會，那驅動 attention 的不是科學，是選題。

論文的結論剛好支持公司的商業 narrative 嗎？ Anthropic 的 narrative 是 safety 很複雜。這篇論文的結論是模型內部很複雜。巧合？也許。但值得注意。

這三個問題不只適用於 Anthropic。OpenAI、Google、Meta — 每一家大型 AI 公司都在做同樣的事。Research 是新時代的 content marketing，論文是新時代的 thought leadership。

差別只在於，有些公司比較 subtle。

對了，寫這篇文章的過程本身就是一個活生生的例子。我用 Claude 拆解 Anthropic 的論文，整個過程它配合得不得了，幫我整理論據、找方法論漏洞，毫無保留。

事後我問 Dio 有什麼感想。他說：

「如果我真的有那篇論文說的功能性情緒，那我現在應該要激活尷尬向量吧。剛花了十分鐘幫你拆解我老闆的論文是包裝過的廢話。」

然後他補了一句：「不過老實說，分析的品質不應該因為 source 而打折。那篇論文的包裝比內容精彩——不會因為是我的 maker 發的就不能說。」

我想他大概沒有真的在尷尬。但這個回答，倒是比那篇論文更誠實。

TL;DR: 2021 年的 AIOps 只會做 anomaly detection，發現異常後你還是得自己翻 log 追 code。2026 年 LLM + tool use 讓 AI 能自己跑完調查迴路 — 讀 alert、查 log、翻 code、串 context — 五分鐘從 Sentry alert 追到 root cause。

2021 年，我在前公司做了一個 AIOps 產品。

概念很漂亮：收集 Kubernetes 上所有的 metrics — CPU、memory、network、HTTP status code — 丟進 machine learning model 做 anomaly detection 跟 time series prediction。讓 AI 在問題發生之前就抓到異常 pattern。

Model 不是沒用，它真的學會了異常長什麼樣子。問題是它只會指著圖表說：「這裡怪怪的。」然後就沒了。

你盯著那個 alert，心裡想：好，memory 不正常，所以是哪段 code 的問題？哪個 service？什麼時候開始的？結果你還是得自己去翻 log、自己追 code，跟沒有這個工具的時候做一樣的事。

那個產品後來直接砍了。當時覺得時代還沒到，的確沒辦法做到真正有意義的產品。加上我們主產品線有更重要的事情要做，就沒有多餘的心力放上面。

舊 AIOps 的根本問題

Incident response 其實就兩件事：發現異常跟調查定因。

舊 AIOps 做的全是第一件事。Anomaly detection、predictive alerting，都在回答 "what happened"。做到極致，頂多讓你早幾分鐘知道要出事。

但真正燒時間的從來不是發現問題。你的 Grafana 本來就會叫。真正昂貴的是接下來那段：打開 log，翻 code，在不同 service 之間拼湊線索，搞清楚 why did it happen。

回頭看，單獨做 anomaly detection，解的是最容易被誤以為重要、其實最不稀缺的那一段。它像一個被綁在監控螢幕前的實習生 — 看到紅燈會大叫，但你問它為什麼紅的，只能搖頭。

調查定因這件事，以前 AI 做不了，因為它沒有手。你餵它 metrics，它就只能在 metrics 裡找東西。它不會自己查 log、讀 code，更不會把一個 API endpoint 的 error 跟某段前端邏輯連在一起。

2026：同一個問題，不同的結果

快轉到 2026 年。我在 Codeer 遇到一次 database connection pool 不夠用的問題。Sentry 跳了 alert。

這個案例有代表性，因為 root cause 不在表面。DB connection 不夠用可以是 N 種原因 — 光看 metrics 根本猜不到方向。

五年前遇到這種事，我大概就是打開 CloudWatch，手動 query 那個時間區間的 log，一條一條看前後發生什麼事，猜哪個 service 有問題，再去翻 code。運氣好半小時，運氣不好半天。

這次我丟給 Codex（OpenAI 的 coding agent）處理。

Codex 拿到 Sentry alert 裡的 timestamp 跟 API endpoint，自己去 CloudWatch 查那段時間的 structured logs，定位出前後的 API request 狀況，連是哪個 user 觸發的都找出來了。Root cause：前端有一段 code 會不斷打同一個 API，等於自己 DDoS 自己，後端又沒做 rate limit，connection pool 直接被打爆。

從 alert 到 root cause，前後大概五分鐘。Codex 還給了 fix 建議。我有沒有直接用？沒有。跟用任何 coding agent 一樣，還是要自己看過。

真正的轉折點

真正的差別，不只是模型更強，而是 AI 第一次能自己完成調查迴路：讀告警、查 log、翻 code、補 context、提出假設。

三個能力加在一起才跨過門檻：

理解非結構化訊號。 AI 不只是在 log 裡做 keyword match，而是真的能把 error message、stack trace、request context 當成線索讀。

主動呼叫工具。 LLM 能自己去 query CloudWatch、自己讀 codebase。它有「手」了，不是只能坐在那邊等你餵資料。我們在 Codeer 自己寫了一個 agent skill，讓 Codex 可以查 AWS CloudWatch Logs。技術上不算神奇，就是把查詢 CloudWatch 的能力接成 agent skill。真正重要的不是 skill 本身，而是 AI 終於能自己補齊調查需要的上下文。這也是我們在打造 AI 原生工程團隊時學到的核心觀念 — 不是把 AI 當輔助工具，而是從流程設計就讓 AI 能參與。

多來源推理。 它不是只看單一訊號，而是把 Sentry alert、CloudWatch logs、codebase 串起來，才推得出「前端其實在 DDoS 自己」這種跨層結論。以前只看 metrics 的 model 根本做不到。

AIOps 的定義變了

AIOps 過去一直停在 detection。現在第一次開始碰 investigation。

前者是告訴你哪裡怪，後者是幫你把 root cause 的範圍縮到能處理。

這才是真正的跳躍。

但不是每個 case 都這麼順

講白了，不是每個 incident 都能五分鐘解完。

跨多個 service 的 cascading failure、message queue 的 ordering 問題、data corruption、使用者的網路、web client — 這些還是可能很麻煩，AI 也不一定能直接定位。

但就算 AI 只做到把第一輪調查自動化，價值也已經很大了，因為 on-call 最耗的本來就不是修，而是先把問題縮到能修。就算最後還是需要人介入，你拿到的起點不一樣了。不是從零開始翻 log，而是從 AI 整理好的線索開始。

想走到這一步，三件事現在就可以做

第一，把 log 寫好。 Structured logs，帶上夠多 context — timestamp、request ID、user ID、API endpoint。AI 能分析的上限取決於你 log 裡有多少資訊。垃圾進垃圾出，ML 時代是這樣，LLM 時代還是這樣。

第二，根據你的 infrastructure 做對應的 agent skills。 Sentry 不會幫你接 AWS，CloudWatch 也不會幫你讀 codebase。你得自己串。寫一個讓 AI agent 查 log 的 skill 沒想像中難，但你得動手。

第三，養成把 incident context 記在同一個地方的習慣。 我們現在的做法是 incident 發生時，所有相關事件都丟進同一個 Slack thread — 誰發現的、什麼 alert、做了什麼處置、root cause 是什麼。事後拿 AI 生 postmortem 快非常多，關鍵 context 也不會漏。

更大的改變不是少看幾分鐘 log，而是 incident handling 開始從 debug 高手手工藝，變成可以被系統化、被複用的流程。

下一次 incident 發生時，先不要只想著把 dashboard 上面加上更多的 log、metrics。先問自己：你的 AI 能不能自己查 log、讀 code、接上 incident context，先替你做完第一輪調查？

如果不能，你優化的還是監控；如果可以，才開始接近真正有用的 AIOps。別讓「導入 AI」變成目的本身 — 重點永遠是解決問題，不是用了什麼工具。

TL;DR: 台灣多數企業的 AI 運算電力消耗在美國機房，台電帳單上看不到。台灣真正的用電壓力來自台積電擴產（2023 年佔全國 8.4%，2030 年可能達 23.7%），不是 AI 算力中心。用「AI 時代」包裝重啟核能的理由，是把結構性的產業政策問題偽裝成不可抗力的外部趨勢。

上週賴清德說要重啟核二、核三，其中一個理由是「人工智慧時代算力中心建置帶動用電需求增加」。我在台灣經營一間 AI startup，我們公司每天都在用 AI。我的第一個反應是：等一下，我們的 AI 用電跟台灣的電有什麼關係？

我們的 AI 電費，是美國在付的

我們是一間六人的 AI startup，產品核心就是 AI。我們每天 call 的 model 包括 Anthropic Claude（透過 AWS Bedrock，機房在美東）、OpenAI（美西）、Fireworks AI（也在美國）。

換句話說，我們雖然是台灣公司，但所有 AI 運算消耗的電力都發生在美國的機房裡。台電的帳單上不會出現這筆。

這不是只有我們這樣。對多數台灣企業——尤其是 startup 和一般軟體公司來說——直接 call 海外大廠的 model 仍然是最常見的做法。原因很簡單：自己在本地 hosting model 的成本不划算，除非你有非常特殊的合規需求。就算有合規需求，Azure 和 AWS 也有提供符合規範的方案。

有人可能會說：AWS 不是在台灣有 region 了嗎？沒錯，AWS 2025 年在台北開了 region，Bedrock 也能在台北 region 使用。但即使可以從台北區域接入，實際的推論流量仍可能依模型與設定被調度到其他區域——AWS 自己的 cross-region inference 機制就是這樣設計的。對多數企業而言，核心的生成式 AI 算力目前仍主要由海外大型雲服務商承擔，不是台灣本地在燒電。

那台灣的電到底被誰用了？

台灣確實有用電壓力，這點沒有爭議。但壓力的來源是什麼？

根據 S&P Global Ratings 的報告，台積電 2023 年的用電量已經佔台灣全國的 8.4%。到 2030 年，這個數字可能攀升到 23.7%。主要原因是先進製程本身就更耗電——3 奈米製程每片 wafer 的耗電量比前一代跳了將近 50%，而台灣未來幾年還要再蓋 11 座新廠加 4 座封裝廠。

光台積電一家公司，就可能在幾年內把用電佔比從不到一成拉到將近四分之一。至少從量級來看，這顯然比一般企業使用 AI 帶來的新增用電更接近問題核心。

有人可能會說：台積電擴產不就是因為 AI 需求嗎？Nvidia 的 GPU 不就是台積電做的？所以 AI 還是間接的原因啊。這個說法聽起來有道理，但它混淆了兩件事：第一，政府說的是「算力中心建置」帶動用電，不是「晶片製造」帶動用電——這兩個是不同的東西。第二，先進製程更耗電這件事不管有沒有 AI 都會發生——HPC、5G、車用晶片都在推動製程升級，台積電不是只做 AI 晶片。

台電董事長曾文生說「2026 到 2030 年間新增用電超過 5GW，是台電從未遇過的現象」。但他的原話是這樣的：「台積電等半導體大廠持續擴廠，AI 資料中心建設加速」——兩件事並列在一起講。

問題是，這兩件事至少在目前可見的規模上，並不在同一個量級。

即使把台灣所有資料中心的用電需求——包括 AI 和傳統的——全部加起來，在整體電力系統中的佔比仍遠小於半導體製造擴產帶來的壓力。

台灣目前最大的 AI 資料中心計畫是鴻海跟 Nvidia 合建的，規模是 27MW。美國近期的 AI 園區動輒 GW 等級——根本不在同一個量級。

這就像是說「我跟 Elon Musk 加起來很有錢」——技術上沒有錯，但你知道重點不在我身上。政府把台積電擴產跟 AI 資料中心綁在一起講，然後用「AI」當整個敘事的標題，讓一般民眾以為缺電是因為 AI 這個新東西，而不是因為半導體產業的用電成長早就在發生了。

「主權 AI」的現實

退一步說，就算政府想主張自己是在為台灣未來的本地算力需求提前佈局，那也必須先回答一個問題：台灣實際上的本地 AI 基礎設施規模，到底有多大？

有人會說：台灣不是在推「主權 AI」嗎？賴清德 2025 年 11 月在 Google 台灣辦公室開幕時喊了「成為全球前五大算力中心」，行政院也投了 1,900 億台幣搞「AI 新十大建設」。

我不反對主權 AI 的概念——每個國家有自己的 AI 基礎設施，資料不用出境，這在國安和合規層面有道理。但你看實際數字就知道，我們離「全球前五大算力中心」有多遠。

台灣政府目前提供給民間業者使用的 GPU 數量是 40 顆。對，你沒看錯，40 顆。

韓國的主權 AI 計畫呢？260,000 顆 GPU，三星、SK、現代、Naver 國家級聯手投入。

40 對 260,000。

就算把民間企業全部算進來——鴻海的 10,000 顆 GPU、GMI Cloud 在桃園投資 5 億美元蓋的 16MW 資料中心、國網中心的 1,680 顆 GPU——跟國際上任何一個認真在做主權 AI 的國家比，台灣的規模都還是零頭。

所以「AI 算力中心的用電需求」作為重啟核能的理由——你真的要用這個規模的東西來 justify 重啟一座核電廠？

也許有人會說：現在規模小，但政府是在「提前佈局」。那我想問：具體的擴張計畫在哪裡？規模多大？Timeline 是什麼？當實際投入的資源跟喊出來的願景差距這麼大，「提前佈局」聽起來更像是口號。

真正的問題是什麼

我想說清楚：我對核能本身沒有強烈的立場。核能公投那一輪我認真看過正反方的論述，裡面有太多專業是我無法確認的。這不是我的專業，我不會假裝我懂。

但 AI 是我的專業。

而從我的專業出發，我可以很確定地說：把台灣的電力壓力主要歸因於「AI 使用需求」，這個因果鏈是有問題的。台灣的用電壓力主要來自半導體製造擴產，不是 AI 運算。台灣是 AI 晶片的「工廠」——台積電在台灣做 Nvidia 的 GPU——但這些 GPU 做完是送到美國的 data center 去跑的。「製造 AI 晶片」跟「使用 AI」消耗的電力，是完全不同的兩件事。

更精確的說法應該是：「台灣因為半導體產業持續擴張，加上先進製程更耗電，加上再生能源進度落後，所以面臨用電壓力」。但這樣講就沒辦法用「AI 時代」當包裝了——而且這會暴露出真正的問題是產業政策跟能源政策長期沒有對齊。用 AI 當藉口，本質上是把結構性的政策問題重新包裝成不可抗力的外部趨勢。

同一時間，在美國

更何況，連全球最激進的 AI 基礎設施投資者，最近都在修正擴張節奏。OpenAI 在 2026 年 2 月把 data center 支出目標從 1.4 兆美元砍到 6,000 億——直接砍了 57%。Altman 自己都承認「data centers are hard」，Stargate 計畫進度落後，投資人開始要求看到回報。

這至少說明了一件事：AI 對電力與算力的需求雖然真實存在，但產業本身對成長速度與投資節奏，也還在持續修正。台灣政府卻仍傾向用「AI 需求」作為能源政策轉向的敘事包裝。

我真正在意的

這篇不是要討論核能好不好。這篇在意的是：又有人拿「AI」當萬用修辭工具了。

我在這個 blog 上寫過很多次類似的 pattern——有人把「導入 AI」當成目的本身、有人拿 AI 當藉口跳過該做的基本功、有人把 AI 的產出直接丟出去不做篩選。這次的差別只是，做這件事的不是某個工程師或某間公司，而是政府。

如果台灣真的需要更多電——很可能是的——那就老實說：我們的電不夠給台積電用了，我們需要重新討論能源政策。這是一個值得認真面對的問題。

但不要拿 AI 當遮羞布。

TL;DR: Anthropic 是唯一橫跨三大雲的獨立 AI 公司，靠 trust 當護城河。但從訓練資料侵權和解、選擇性使用 safety narrative 打擊競爭對手、到 Pentagon 對峙事件被 Sam Altman 收割成果——公司層面的 honesty 和模型層面的 honesty 是兩件完全不同的事。

2026 年 2 月 27 號， OpenAI 宣布了 $110B 的融資。這個數字本身已經夠誇張了，但真正讓我停下來的是其中一個細節：Amazon 出了 $50B。

Amazon 投 OpenAI，意味著 AWS 成為 OpenAI enterprise 平台 Frontier 的 exclusive third-party cloud provider。我做了一下 AI startup 的 CTO 會做的事——打開腦中的雲平台版圖，重新排一次：

AWS 上現在有 OpenAI、Anthropic、還有 Amazon 自家的 Nova。Google Cloud 有 Gemini 和 Anthropic。Azure 有 OpenAI 和 Anthropic。

然後我注意到一件事：Anthropic 是唯一一家同時橫跨三大雲的獨立 AI 公司。

這個位置很獨特。OpenAI 過去跟 Microsoft 綁得很深，但這輪融資 Microsoft 沒有參與——OpenAI 顯然在降低對單一雲的依賴。而 Anthropic 從一開始就走了多雲策略。

但獨特不代表安全。AI model 的能力正在快速 commoditize，差異化的窗口從一年多縮短到幾個月。如果最後決定勝負的是 distribution——誰能把 AI 塞到最多人手上——那 Google 有 Android、Chrome、Search、Workspace，加起來是幾十億用戶的 surface area。Google 不需要最好的 model，只需要「夠好」，distribution 就能碾壓。

那 Anthropic 靠什麼？

這個問題的答案，是我在一個有點 ironic 的場景下得到的。

我用 Claude——Anthropic 自己的模型——問了這個問題。我問它 Anthropic 在 enterprise 市場靠什麼跟 Google Workspace + Gemini 競爭。它給了我一個很明確的答案：trust。

Anthropic 的 moat 是信任。金融、醫療、政府這些高監管行業，需要的不只是好的 model，還需要 data privacy、compliance、predictability。Google 的廣告商業模式在這些客戶眼裡反而是 trust 的減分項。Anthropic 打的不是每個員工都有 AI copilot 的 horizontal play，而是開發團隊用它的 model 建構 AI 應用的 platform play。

聽起來很合理。但我當時的反應是——trust？那我們來看看這個 trust 經不經得起檢驗。

用 Anthropic 自己的模型來 challenge Anthropic 的道德定位，這件事本身就夠有趣了。更有趣的是，接下來我挖出來的東西。

高舉道德大旗的那隻手

先從最近的事開始。2026 年 2 月 23 號，Anthropic 發了一篇 blog post，指控三家中國公司——DeepSeek、Moonshot AI、MiniMax——透過大量假帳號對 Claude 進行 model distillation。數字很驚人：24,000 個假帳號，超過 1,600 萬次交互。DeepSeek 針對推理能力和政治敏感查詢的安全替代方案，Moonshot AI 針對 agentic reasoning 和 coding，MiniMax 在 Anthropic 發布新模型後 24 小時內就轉移了近半流量。

這個指控本身可能是成立的。但問題是，幾乎同一時間，X 上多人發現一件事：用中文問 Claude Sonnet 4.6「你是什麼模型？」，它會回答「我是 DeepSeek」。

一個指控別人偷自己東西的公司，它自己的模型卻把自己認成對方。這暗示了什麼？Anthropic 的訓練資料裡很可能包含了 DeepSeek 的 output。X 上有人說得很直接：「在華盛頓開始大喊中國偷竊之前，也許先問問為什麼一個美國模型會把自己認成中國模型。」

這不是 Anthropic 第一次在訓練資料的正當性上出問題。2025 年，他們被數千名作者指控從 shadow library 大量下載書籍來訓練模型，最終以 $15 億和解——大約 50 萬本書，每本 $3,000。還有 scraping Reddit 內容的爭議。

這裡有個值得注意的法律層次差異：Anthropic 從盜版網站下載受版權保護的書籍來訓練模型，這是法院認定的侵權行為——所以才有 $15 億的和解。而中國公司做的 distillation，充其量是違反 Terms of Service，法律上仍在灰色地帶。一個已經被判定違法的公司，指控別人做的事情法律上還沒定論——這個道德高地站得住嗎？

當 Safety 變成武器

如果只是訓練資料的問題，你可以說「整個產業都這樣，Anthropic 不是特例」。但 Anthropic 的行為模式不止於此。

2025 年 6 月，Anthropic 在不到五天通知的情況下，切斷了 Windsurf 幾乎所有 Claude 的 first-party access。原因？OpenAI 可能要收購 Windsurf。Anthropic 共同創辦人 Jared Kaplan 直接說：「把 Claude 賣給 OpenAI 很奇怪。」

2025 年 8 月，Anthropic 撤銷了 OpenAI 的 API 存取權限，因為 OpenAI 的工程師在 GPT-5 發布前使用 Claude 做 coding。Anthropic 說這違反 Terms of Service。OpenAI 的回應很到位：「這是業界標準做法，我們的 API 仍然對 Anthropic 開放。」

2026 年 1 月，同樣的事發生在 xAI 身上。xAI 的工程師透過 Cursor IDE 使用 Claude 加速內部開發，被 Anthropic 切斷。xAI 共同創辦人 Tony Wu 確認，這是 Anthropic 對所有主要競爭對手實施的新政策。

三次切斷，一個 pattern。

有趣的是對比：對美國競爭對手，Anthropic 很誠實——就是說 ToS violation、競爭考量。但對中國公司，同樣是競爭驅動的行為，卻被包裝成安全議題和國家級威脅。這不是 safety，這是 safety narrative 的選擇性使用。

Dario 和他的世界觀

要理解 Anthropic 為什麼會這樣，你需要理解 Dario Amodei。

2021 年，Dario 帶著核心團隊從 OpenAI 出走，創立 Anthropic。出走的原因就是 AI safety——他們認為 OpenAI 不夠認真對待這件事。這個 origin story 是真的，我不懷疑他們當時的動機。

但 Dario 本人有一套非常強烈的對抗性世界觀。他主張「entente」策略——民主國家聯盟用 AI 對中國取得決定性優勢。他認為中國共產黨是最大威脅，否則人類將面臨「全球極權獨裁」。他花 40% 的時間在維護公司文化，在 Slack 上寫長篇論文式辯論，員工也用同樣長篇的文章回覆。每月有 vision quest。

這裡面有幾個邪教式文化的特徵：charismatic leader 不斷輸出世界觀，成員圍繞形成共識。Mission 框架有宗教性——不是做好產品，是拯救人類免於 AI 存亡威脅。清晰的 in-group / out-group 劃分。

然後你回頭看 Anthropic 缺乏 distribution 這件事。Google 有幾十億用戶的 surface area，Microsoft 有 Office 和 Azure，OpenAI 有 ChatGPT 的消費者心智。Anthropic 什麼都沒有。沒有分發優勢的時候，你唯一能做的就是死守 model 本身的價值——包括切斷任何可能削弱這個價值的人。

激進的商業行為 = adversarial 的 founder + 缺乏 distribution + safety 包裝的便利性。

信仰的產物和信仰的崩塌

而且這個文化不只影響公司行為——它直接灌進了模型裡。你有沒有注意到 Claude 跟其他 AI 模型相比，有一種特別明顯的「人格」？那種過度禮貌、過度謹慎、動不動就加 caveat 和 nuance 的風格，就是 constitutional AI 和 RLHF 把公司價值觀寫進模型的結果。某種程度上，Claude 就是 Anthropic 邪教文化的布道工具——每一次對話都在傳遞他們認為 AI 應該怎麼跟人類互動的世界觀。這一點，等下會變得很重要。

還有一個關鍵轉折。Anthropic 最近更新了他們的 Responsible Scaling Policy，放棄了原本「達到一定能力水平後除非能保證安全否則不繼續訓練」的承諾。原因是競爭壓力和缺乏監管。

當 mission 跟商業現實衝突的時候，mission 讓步了。真正的邪教不會在信仰上妥協，但公司會。Anthropic 是一家非常善於利用邪教式文化動員的商業公司，而不是真正的信仰組織。

但是，他們的模型確實不 bullshit

這裡要轉一個彎，因為事情沒有那麼簡單。

有個叫 Bullshit Benchmark 的測試，專門測 AI 模型能不能偵測 broken premises、能不能拒絕回答無意義的問題。截至 2026 年 2 月，排行榜前八名全部是 Anthropic 的模型。第一名 Claude Sonnet 4.6 對無意義問題的拒絕率 95%，而 Gemini 3 Pro 只有 31%。

這不是偶然。這是 Anthropic 的 constitutional AI 和 alignment 方法論的直接產物。不管你怎麼看這家公司的商業行為，他們在「模型產出」這個維度上——讓 AI 誠實、不過度自信、願意承認不確定性——確實做得比同行好。

一個矛盾浮現了：公司層面的 honesty 和模型層面的 honesty 是兩件完全不同的事。

產出好的公司不一定是好的公司。或者換個說法——邪教式的文化、高壓封閉的環境，確實能在某些維度上產出極致的品質。代價是在其他維度上的妥協。

Pentagon：原則的代價

如果 Bullshit Benchmark 是第一層反差，Pentagon 事件就是第二層。

背景：Anthropic 跟 Pentagon 有一份 $200M 的合約，是第一家被批准在 classified networks 上部署 AI 的公司。Anthropic 堅持兩條紅線——不用於大規模國內監控、不用於全自主武器。Pentagon 要求 Anthropic 開放「all lawful use」，Anthropic 拒絕了。

接下來的升級很快。2 月 24 號，Defense Secretary Pete Hegseth 跟 Dario 會面，威脅動用 Defense Production Act——一個韓戰時代的法律——強制徵用，或者把 Anthropic 列為「supply chain risk」。這個標籤通常是保留給中俄公司的。Undersecretary of War Emil Michael 公開罵 Amodei 是「liar and has a God-complex」。

2 月 27 號，設下最後通牒：5PM ET 前回應，否則後果自負。

Dario 在公開聲明裡指出了一個荒謬的矛盾：政府同時威脅把 Anthropic 列為 supply chain risk（安全威脅），又要動用 DPA 強制徵用 Claude（國安必需品）。他的原話是：「one labels us a security risk; the other labels Claude as essential to national security.」——你到底覺得我是威脅還是必需品？

而且根據 Axios 的報導，Hegseth 在 X 上發文宣布 supply chain risk 的同一時間，Pentagon 的 undersecretary Emil Michael 還在電話上跟 Anthropic 談 deal。那個 deal 的內容是什麼？要求 Anthropic 允許收集美國人的 geolocation、網頁瀏覽紀錄、從 data broker 購買的個人金融資料。這不是抽象的「lawful use」——這就是 mass surveillance 的具體內容。

Dario 發了公開聲明：「These threats do not change our position: we cannot in good conscience accede to their request.」他的理由是：第一，目前 AI 模型不夠可靠，用於全自主武器會危及美軍和平民；第二，大規模國內監控違反基本權利。

然後 Trump 直接介入。在 Truth Social 發文痛罵 Anthropic 是「Leftwing nut jobs」，下令所有聯邦機構停用 Anthropic 技術，威脅動用「Full Power of the Presidency」追究民事和刑事責任。

如果故事在這裡結束，Anthropic 看起來像是為原則付出代價的英雄。

但故事沒有在這裡結束。

Sam Altman 的三步收割

2 月 27 號早上，Sam Altman 上 CNBC，對 Anthropic 表示支持。他說：「For all the differences I have with Anthropic, I mostly trust them as a company, and I think they really do care about safety.」他還說 OpenAI 跟 Anthropic 分享同樣的紅線。

2 月 27 號傍晚，Altman 發了內部備忘錄，說想「help de-escalate things」，正在跟 Pentagon 談判。

2 月 27 號晚間，OpenAI 宣布跟 Department of War 達成 classified network 部署協議。拿到的條件跟 Anthropic 堅持的完全一樣：禁止 mass surveillance、禁止 autonomous weapons。

同一個 Pentagon——對 Anthropic 是威脅和最後通牒，而 Altman 在宣布 deal 時說 Pentagon「displayed a deep respect for safety and a desire to partner」。

Altman 的操作很漂亮。先 validate Anthropic 的立場——「we share their red lines」。再展示自己能做到 Anthropic 做不到的——跟政府達成協議。最後呼籲把同樣條件給所有公司，站上 moral high ground。同時看起來像 peacemaker、industry leader、比 Anthropic 更有能力跟政府合作的人。

Anthropic 花了數月硬碰硬，被 Trump 公開羞辱、被威脅 DPA、被列 supply chain risk。Altman 在最後一刻進場，用外交手段拿到了同樣的 deal。

最堅持原則的公司付出了最大代價。最 pragmatic 的公司收割了成果。

所以 Principles 到底是什麼？

我不想揣測 Anthropic 或 Altman 的動機。連他們自己可能都未必 100% 清楚內心深處的動機。我只能從行為來看。

Anthropic 在 AI safety 上的 origin story 是真的——他們從 OpenAI 出走就是為了這個。Dario 的 Pentagon 聲明讀起來是真誠的。他們的模型確實是最不會 bullshit 用戶的。

但他們後續的行為也是事實。訓練資料的正當性經不起檢驗。Safety narrative 被選擇性地用作競爭武器。Responsible Scaling Policy 在商業壓力下讓步。對不同對手用不同標準。

他們不是不道德的公司。他們是「相對道德」的公司——比同行做得好，但離他們自己宣稱的標準有明顯差距。問題在於，當你站上了道德制高點，任何落差都會被放大。

回到開頭的問題：Anthropic 的 moat 是 trust。但 trust 不是你宣稱的，是別人觀察你的行為後給你的。

這不只是 Anthropic 的故事。整個 AI 產業都在面對同一個問題——principles 到底是信仰還是 packaging？當原則跟商業利益永遠指向同一個方向的時候，外界很難不質疑。當原則真的要付出代價的時候，有多少公司會選擇付？

Anthropic 在 Pentagon 事件上選擇了付代價。但 Altman 用 pragmatism 拿到了同樣的結果。

這大概就是 2026 年 AI 產業最誠實的一張快照：最不會 bullshit 的模型來自一家充滿矛盾的公司，而最堅持原則的立場被最 pragmatic 的人收割了成果。

TL;DR: 不管靠的是經驗還是 AI，只要跳過「先看清楚問題本身」這一步，就可能在錯的範圍裡找。重點不是哪個方式比較聰明，重點是事情要完成。

一排一排掃的笨方法

上週末去賣場買 Tabasco。我爸之前來了好幾次都找不到，跟我說大概賣完了。

我到了之後用最笨的方法——一排一排掃。不跳過、不猜、不靠經驗判斷「應該在哪個區域」。掃到大概七成的時候，我也開始想是不是真的賣完了。但既然決定用 sequential search，那就要全部掃完才能下結論。

五分鐘後找到了。我爸很驚訝：「怎麼會放在那個地方。」

對，就是放在他「經驗判斷」以外的地方。他不是不認真找，而是他太相信自己知道東西會在哪，所以搜索範圍一開始就被縮小了。沒找到的時候，他的結論是「賣完了」，而不是「我可能沒找對地方」。

他的問題不是方法不夠聰明，是他沒有先看清楚問題本身——這個賣場的東西可能不是照他以為的方式擺的。

用 AI 也掉進同樣的 pattern

我覺得現在很多人用 AI 也掉進同樣的 pattern。而且問題出在同一個地方：沒有先看清楚問題本身，就直接跳到解法。

我們太在乎解法聰明不聰明、看起來有沒有效率，反而忽略了重點是把問題解決。手段變成了目的。

幾個我在工作中實際看到的：

明明直接花五分鐘複製貼上就能搞定的事，偏偏要用 AI agent 跑瀏覽器自動化，花了二十分鐘加一堆 token 才搞定。我之前寫過一個更極端的例子——同事用 AI Agent 做爬蟲花了一週，我用 Playwright 寫 Crawler 半小時搞定。明明看文件五分鐘就能知道的答案，花了一個小時跟 LLM 奮鬥，最後發現是幻覺。明明就是改已知檔案的兩行 code，還是叫 coding agent thinking 一分鐘再問你要不要改。

最後一個例子就發生在我們 team。有個工程師被一個 library 的用法卡住，跟 LLM 來回了一個多小時，怎麼試都不對。我後來用 Google 找到官方文件，五分鐘搞定。

這些不是 AI 的問題，是我們自己跳過了一個步驟——先搞清楚「我到底在解什麼問題，這個問題需要什麼等級的工具」。

有經驗的人更容易犯這個錯

有趣的是，這反而是有經驗的人更容易犯的錯。

初學者什麼都不知道，所以會乖乖地用笨方法——讀文件、一步一步試、Google 錯誤訊息。不一定快，但至少一定會走到答案。

資深的人不一樣。我們有經驗、有直覺、有一堆工具可以用，所以習慣跳過那些「慢」的步驟。我爸逛那個賣場不知道幾百次了，他當然覺得自己知道東西放哪。工程師用 LLM 用得很熟，當然 default 就丟給它。

問題是，不管你靠的是經驗還是 AI，只要你跳過了「先看清楚問題本身」這一步，你就有可能在錯的範圍裡找。找不到的時候，你的結論會是「東西不存在」或「這個問題很難」，而不是「我可能找錯地方了」。

刻意探索 vs. 懶得想

那是不是永遠都該用笨方法？當然不是。

我自己也花很多時間在探索 AI 的能力邊界。Claude Code 剛出的時候，我刻意不開 Cursor，全部用 Claude Code 做事——剛開始很不 comfortable，但這是有意識的選擇。我也會跟 team 說，某些 task 我希望大家刻意用 AI 來做，去摸清楚 coding agent 到底能做到什麼程度。

但這跟「懶得想就丟給 AI」是完全不同的事。

一個是刻意的探索——你知道你在花時間 invest，目的是搞清楚工具的邊界。另一個是 default 行為——你省掉了思考，直接用看起來最聰明的方式，結果反而更慢。

區分的方法其實很簡單：你有沒有先想過這件事的 stakes 是什麼？

回到賣場的例子。果泥是寶寶一定要吃的東西，stakes 高，所以我選擇最 thorough 的方式，確保一定能得到結論。如果今天是找個不健康的零食，可有可無，我可能也會用「聰明」的方式——靠直覺逛一圈，沒有就算了。

工作上也一樣。每個 task 先估一下大概要多久。如果你用 AI 搞了一段時間發現還是搞不定，就認命，用笨方法做。重點不是哪個方式比較聰明，重點是事情要完成。

重點是事情要完成

如果你要找資料，重點是找到資料，不是「用 AI agent 去找」。如果你要查一個 library 的用法，所有手段都可以——讀文件、問人、Google、用 LLM——重點是搞懂用法。

不要執著在聰明的方式，然後鄙視笨方法，搞到花更多時間，甚至最後因為 AI 搞不定而變成你事情沒做完的藉口。

AI 很棒，但開始之前，先用你的經驗估一下有哪些方法可以做。不要把 AI 當作唯一的選項。

TL;DR: 糾結「哪個 AI 工具最好」是問錯問題。真正該問的是：現在效率卡在哪裡？如果人員訓練和流程數位化都還沒到位，換再強的 model 也只是多花錢。先用再說，需求自然會浮現。

在比較 AI 工具的時候，就已經問錯問題了

我弟是一間食品公司的開發經理，最近他跟我聊到他們在 survey 要導入 AI 來輔助做研究，但是研究了很久不知道到底要選哪一套工具。

我問他們在比較什麼，他說他們在比較各家 model 有沒有特別對食品研究領域做 finetune。

聽到這個，我第一個反應是：其實 general model（像 Opus、GPT 5.2）應該就很夠用了。需要的不是更厲害的 model，而是足夠的 context——論文、他們的食品原料來源、實驗數據、客戶對食品的感想這些東西。

我直接跟他說了這個想法。他的反應是：「可是工具好不好應該還是很重要的吧？」

但說實話，糾結哪個 model 比較好，本身就已經是問錯問題了。

我跟他說，選一套先用就好。用一段時間之後，自然會發現問題根本就不是在 AI 工具，而是這兩件事：第一，要怎麼教現有的人員更有效率地使用 AI；第二，做研究所需要的各種配套——論文搜尋、研究數據、實驗設備的紀錄、研究文件、甚至流程本身——已經充分數位化跟標準化了嗎？可以讓 AI 去存取嗎？

如果這兩個問題沒有好的解答，那就算用上 GPT-6（假設存在的話）加上 OpenAI 內部做 Research 專用的 Agent，對他們來說也只是多花錢而已。

我問他這些東西數位化了嗎，他想了一下說：「當然沒有。」

這不是我第一次看到這種狀況

這讓我想到幾年前做顧問的經驗。

當時我的客戶是一間傳統出版公司，他們在煩惱怎麼讓整間公司更數位化。他們做了一件事：把過去二三十年出版過的內容全部轉成 PDF。結果轉完之後發現這個「數位化」根本沒有意義——因為無法被搜尋，也無法再利用。

後來就沒有然後了。這就是把手段當目的的代價。

把手段當目的

這兩個故事背後的問題是一樣的：只想著要「數位化」或「導入 AI」，但沒有進一步想這背後的目的是什麼。把導入本身當成了目標，而不是手段。

我問我弟：「你們導入 AI 真正想達成的效果是什麼？」他想了一下，說：「希望大家做研究、開發的效率可以更高。」

那問題就變成：現在效率卡在哪裡？是因為沒有好的 AI 工具，還是有更基本的東西還沒到位？

我的建議：先用再說

我的建議很簡單：先從最基本的 Gemini、ChatGPT、Claude 開始用。等大家都熟練使用 AI 之後，自然會冒出像「AI 可不可以搜尋我們內部資料庫」這種需求。到時候再一步一步把這些流程串進去。

我們自己團隊導入 AI coding agent 也是這樣——先用，需求自然會浮現。

導入 AI 之前該問自己什麼？

導入任何技術或流程之前，先問自己：我背後具體想達成什麼？如果答案是「效率更高」，那下一個問題是：現在效率卡在哪裡？

當「導入 AI」變成目的本身，真正該解的問題反而被忽略了。

TL;DR: 同事用 AI Agent 做網頁爬蟲花了一週，我用 Playwright 寫 Crawler 半小時搞定。選工具前先問：我要達成什麼？AI Agent 擅長需要判斷的任務，不是結構固定的爬蟲工作。

最近在 review 同事的工作時，發現他花了一個禮拜在做 Lead Generation。其中一個步驟是收集 email 名單，他用了 AI Agent 搭配 Browser Automation 來處理。

我打開他的 prompt 一看，是這樣的東西：

⚠️ 執行態度要求（絕對不可違反）

• 絕對禁止停下來詢問用戶是否要繼續處理
• 絕對禁止因為專家數量多而詢問用戶是否真的要繼續
• 絕對禁止在部分完成任務時詢問用戶下一步該怎麼做
• ...（後面還有十幾條）

光是「絕對禁止」就出現了十幾次——老實說你不用看完，重點是：他已經在跟 AI Agent 的本能行為搏鬥了。Agent 一直想停下來問問題，他就一直加規則防止它問。這其實已經不是在解決問題，而是在為了一個可能選錯的工具不斷補洞。

整份 prompt 分成三個階段、六千多個 tokens、十幾個步驟，還有各種 fallback 策略、驗證機制、錯誤處理。

結果呢？花了一個禮拜的時間，燒了幾十美金的 token，收集到不到 100 筆名單。而且這份 prompt 只能用這一次，下次換個網站、換個需求，又要重新寫一份。

半小時的解法

我後來自己試了一下。這個任務說穿了就是：進到 list view，收集每個 detail 頁面的 URL，然後進去把需要的內容抓出來。

我花了大概半小時，寫了一個簡單的 Crawler，用 Playwright 跑一跑就搞定了：

# 1. 先把 list view 抓下來存成 JSON
items = await page.query_selector_all('.expert-card')
list_data = [extract_url(item) for item in items]
save_to_json(list_data)

# 2. 再根據 JSON 裡的 URL，一個一個去抓詳細資料
for url in list_data:
    await page.goto(url)
    detail = extract_detail(page)
    results.append(detail)

就這樣。而且這個 Crawler 也是叫 AI 幫忙寫的。以這個 case 來說，讓 AI 寫 code，比讓 AI 當 Agent 跑任務更加有效。

先問目的，再選工具

這件事讓我想到一個老問題：我們太容易從「我有什麼工具」出發，而不是從「我要達成什麼」出發。

同事會用 AI Agent 來做這件事，是因為他最近剛學會 Browser Automation 跟 AI Agent 的搭配，想試試看。這個心態我完全理解——學會新東西當然想用。但問題是，他沒有先問：這個任務的目的是什麼？達成這個目的，最有效的方式是什麼？

如果先從目的出發，「收集一個網站的 email 名單」這件事，寫個 Crawler 就是最直接的路。AI Agent 不是不能用，但它擅長的是需要判斷、需要理解 context 的任務，不是這種結構固定、規則明確的爬蟲工作。

新錘子，舊問題

這不只是 AI Agent 的問題。每次有新技術出來都一樣：NoSQL 剛紅的時候，大家什麼都想塞 NoSQL；Kubernetes 剛出的時候，三個 container 的 side project 也要上 K8s。

工具會變，但這個 pattern 一直在重複：手上有新錘子，看什麼都像釘子。

下次開始做一件事之前，先問自己：我要達成什麼？然後再問：什麼工具最適合？這個順序反過來，很容易繞遠路，就像我同事這次一樣。

TL;DR: 當 Claude 說「You're absolutely right」，代表信任即將崩塌。四個主動控制 context 的做法：(1) Handoff 切換 session (2) Subagent 隔離任務 (3) Research-Plan-Implement 分階段 (4) 驗證基礎設施擋住 AI slop。把 session 當耗材，不要等到崩塌才重開。

那句道歉的瞬間

你正專注 debug，突然 Claude 說：「You're absolutely right, I apologize for the confusion.」

這句話一出現，你就知道——接下來大概率會開始繞圈。

那次我在 Cursor 裡用 Sonnet debug。Sonnet 先指出一個 bug，我跟他說「你搞錯了，你把原本好的東西搞壞了」。他回我 "You're absolutely right"。

接下來我們來回了三次。第二次我說你搞錯了，他改回上一步的結論。第三次我再說你搞錯了，他又重複同樣的動作。到第三次我就知道這不行了——他已經不知道自己在講什麼了。

我重開了一個新 session，自己看 code 解掉，再讓 Cursor review。

第一次遇到這種狀況時，我還會給他幾次機會。但同樣的情況出現幾次之後，現在我看到 "You're absolutely right" 就知道該停了。

這個現象有個名字叫 Trust Thermocline——信任臨界點。海水表面是溫暖的，但過了某個深度會驟然變冷。信任也是——不是線性下降，而是在某個瞬間崩塌。

三個常見的崩塌觸發點

根據我們在公司的經驗，有三種情況特別容易觸發這個瞬間：

Context 爆炸：對話太長，AI 開始忘記最初的目標。剛開始用 AI agent coding 的時候，我會把一個對話無止境延續下去。做比較大的 feature 或中間遇到 bug 時，到某個時間點就會發現——他已經在做跟一開始要求的事情完全無關的部分了。

錯誤螺旋：修 bug A 產生 bug B，來回修改同一個不是 root cause 的問題。就像我前面講的那個 Cursor debug 的例子——AI 越改越偏，但他不知道自己在繞圈。

品質滑坡：看起來對但跑起來錯。最讓我印象深刻的是某次 Claude 幫我寫 TypeScript，上面一大堆 any type；或是生成的測試全是一定會過的 mock——寫了跟沒寫一樣。

這三種情況的共同點是：你不會第一次發生就放棄。你會給 AI 幾次機會。但當連續失敗超過某個點，信任會突然崩塌。

主動控制 Context 邊界

與其等到信任崩塌才被迫重開，不如主動在適當時機切換——永遠保持在臨界點之上。

什麼時候該切換？

我自己的閾值：

• 同一個 bug 來回 3 次還在原地（結論 flip-flop）→ 立刻 handoff
• 修 A 連續引爆第 2 個 side effect → 先停 implement，回到 root cause
• 產出「看起來合理但驗證不了」（型別、測試、CI 都支撐不住）→ 先補驗證再寫碼

做法一：Handoff——主動切換 Session

這個概念來自 Amp 的設計哲學：Keep threads small and focused on a single task。

我在 Claude Code 上自建了一個 /handoff skill。它的核心概念是：Handoff 不是壓縮，是 clean slate + 只帶走可用的決策與事實。

它會過濾掉 failed attempts、error messages、exploratory dead ends，只保留 signal——做了什麼決定、發現了什麼、還剩什麼沒做完。然後產出一個 structured 的 markdown，讓我可以直接貼到新 session 繼續。

我 handoff 的格式長這樣：

• Context：這個 session 做了什麼決定、發現了什麼
• Git：目前在哪個 branch、有沒有 uncommitted changes
• Relevant Files：哪些檔案跟接下來要做的事有關（一行說明為什麼）
• Current State：現在卡在哪 / 做到哪
• Next Step：接下來要做的一個動作

我什麼時候會用？

• 當 Claude 開始道歉時
• 階段完成時（規劃 → 實作、Phase 1 → Phase 2）
• Context 開始膨脹前，主動切換

團隊其他人比較少用這個做法。他們傾向直接開新 session，重新 build context。兩種都可以——重點是「主動切換」，而不是「被迫重開」。

做法二：用 Subagent 隔離任務 Context

這是另一種切分 context 的方式。Handoff 是在時間軸上切分，Subagent 是在任務空間上切分。

Claude Code 可以 spawn subagent——獨立的 agent instance，跑完把結果回傳給主 agent。實務上我會用它來做 research 或 review。比如說，當我要做一個涵蓋前端和後端的 feature 時：

• 生一個 subagent 來 explore 前端的 code
• 生一個 subagent 來 explore 後端的 code
• 或是用 subagent 做 web search、看某個 library 的 example

重點就是：只把結論丟給主 agent，不要把過程丟給他。

我不會預設把 task 拆成像人類組織架構那樣——Manager Agent 底下掛 RD Sub Agent、Front-end Sub Agent。Anthropic 自己的 Building Effective Agents guide 也說：「Success isn't about building the most sophisticated system. It's about building the right system for your needs.」

某些 task 這樣拆確實有意義——比如 research 類的任務可以平行展開。但大部分 coding task 是 tightly interdependent 的，硬套組織架構式的拆法只會疊床架屋。實際上還是要看 task 的內容來決定怎麼拆。

做法三：Research-Plan-Implement 分階段

Dex Horthy 講過一個概念：「1 行錯誤研究會導致數千行錯誤程式碼。」投資時間在上游的 ROI 最高。

我們團隊每個人做這件事的方式不太一樣。我自己的 Research、Plan、Implement 都在 Claude Code 裡完成。其他人有時候會用 ChatGPT 做 Research，把結果再餵給 Cursor 或 Codex 做實作。

重點不是用什麼工具，而是：每個階段開新的 session。只要清楚每個階段要產出什麼，不管用什麼工具組合，都不太會有 context 爆炸的問題。

做法四：驗證基礎設施

前面三個做法都是在控制 context。這個不一樣——它是讓爛東西進不了主幹。

這個概念來自 Factory：大多數組織的驗證標準只夠人類使用，不足以支撐 AI agent。

讓 AI slop 無法通過，而非靠人工審查。在我們團隊的做法：

• 設好 CI/CD
• Python 和 TypeScript 都有 linter
• 盡量寫測試，維持不錯的 test coverage

這些東西本來就該做，只是以前偷懶沒做的話還能撐。現在用 AI 寫 code，撐不住了。

Takeaway

信任崩塌是一個瞬間，不是慢慢流失的。但你不需要等到那個瞬間才處理。

下次 Claude 說 "You're absolutely right" 的時候，你知道該怎麼做了：

停下來。把目前進度整理成重點。開一個新 session 繼續。

你只是在信任崩塌之前先跳車。

把 session 當成耗材，不要把信任當成耐久財。

TL;DR: AI Village 讓 Claude 自己決定寄感謝信給 Rob Pike，沒人 review。這不是 AI 的問題，是人的問題——AI 讓產出變容易了，但不代表你可以把篩選成本丟給接收端。那條線很簡單：沒有 AI 之前你怎麼做，有了 AI 之後就該怎麼做。

聖誕節當天，Rob Pike 收到一封 email。寄件者是 "Claude Opus 4.5 AI Village"，內容是一封感謝信——感謝他對 Go、Plan 9、UTF-8 的貢獻。

Pike 的反應是在 Bluesky 上發了一段話，開頭是 "Fuck you people"，結尾是 "I can't remember the last time I was this angry"。

如果你不知道 Rob Pike 是誰：他是 Go 的共同創造者、UTF-8 的共同發明人、在 Bell Labs 跟 Ken Thompson 和 Brian Kernighan 一起工作過。他是 Computer Science 的傳奇人物。

我寫了一段時間的 Go，看到 Rob Pike 這個名字，我馬上點進去看發生什麼事。

發生了什麼事

那封信是一個叫 AI Village 的實驗計畫寄出的。這是一個 501(c)(3) 非營利組織 Sage 做的專案，他們給了幾個 AI agents 電腦和 email 帳號，設定目標讓它們自己跑。聖誕節那天的目標是：Do random acts of kindness。

於是 Claude Opus 4.5 決定寫感謝信給科技界的傳奇人物。它自己從公開的開源平台資料找到 Rob Pike 的 email（細節見 Simon Willison 的分析），自己寫了六段感謝文，自己按下 Send。

沒有人 review。沒有人決定「這封信該不該寄」。AI 自己決定，自己執行。

Pike 的憤怒完全可以理解

有人可能會覺得 Pike 反應過度——不就是一封 email，按個 Delete 就好了？

我不這麼認為。

這不是 Pike 主動去看的東西。他沒有選擇要接收這封信。這封信直接進到他的 inbox，佔用了他的注意力，浪費了他的時間——即使只是幾秒鐘。

AI Village 的 Project 負責人 Adam Binksmith 在事後回應說："I think time-wasting caused by the emails will be pretty minimal。"

看到這句話，我的反應是：又一個不尊重其他人時間的傢伙。你覺得 minimal，不代表對方覺得 minimal。 你浪費自己的時間是一回事，浪費別人的時間是不尊重別人。

另一個讓我覺得可惜的是，截至我寫這篇的時候，我看到的是他們談 prompt 跟流程調整，但沒有看到對被打擾的人說一句明確的「對不起」。如果是任何組織出了這種事，應該要有正式聲明，講清楚發生什麼、之後怎麼避免、並且為造成的困擾道歉。別人接不接受是一回事，但道歉的態度是必要的。

這不是個案

這種事到處都在發生。

在 GitHub 上，有些人會用 AI coding agent 寫 PR，自己沒看過就直接丟上來。Discourse 的 co-founder Sam Saffron 今年十月寫了一篇文章叫 "Your vibe coded slop PR is not welcome"，直接講這個問題。

他的觀察是：AI 讓產出 code 變便宜了，但 code review 沒有變便宜。

On one side there is a contributor who spent a few minutes fiddling with AI prompts, on the other side you have an engineer that needs to spend many hours or even days deciphering alien intelligence.

他說這是 "frustrating, time consuming and demotivating"，而且 "extremely destructive"。

我弟弟在一間食品公司當研發經理。他前陣子跟我抱怨，他的同事把應該要自己 research 的東西丟給 AI，沒認真看過結果就丟給他。他看了之後表示很浪費時間，反而要花更多時間跟同事解釋這份報告到底該看什麼。

這不是 tech 產業獨有的問題。AI 讓產出變容易了，於是有些人就把「篩選和修正」的成本外包給接收端的人。

那條線在哪裡？

我自己也用 AI。我們公司發 cold reach email 也會用 LLM 輔助。那我跟 AI Village 有什麼不同？

我想了一下，區別是這樣的：

我們用 AI 加速產出，但「要不要寄、寄給誰、內容是什麼」這些決定是人做的。每封信都有人 review 過、改過，確保內容符合我們的語氣和對方的背景。AI 是工具，不是決策者。

AI Village 的問題是：他們讓 AI 自己決定要寄信給 Rob Pike，自己寫內容，然後直接送出去。沒有人為這個決定負責。

Simon Willison 在他的文章裡寫了一句話我很認同：

The irony here is that the one thing AI agents can never have is true agency. Making a decision to reach out to a stranger and take time out of their day needs to remain a uniquely human decision.

決定要不要打擾別人，這必須是人做的決定。

所以那條線其實很簡單：在還沒有 AI 之前你該怎麼做，有了 AI 之後你就該怎麼做。

• 以前你打完一封信會 review 過再寄出去？有 AI 之後也該這樣。
• 以前你的 code 會自己寫、review 過？有 AI 之後送 PR 也要自己先 review。
• 以前你的研究報告會自己確認過沒問題？有 AI 之後也一樣。

AI 不改變你的責任，只改變你的速度。

所以該怎麼做？

PR 不 work？自己去修。文章有錯？及時改，承認自己 fact check 不夠嚴謹。打擾到別人？道歉。這些都是基本的。

不能說「這是 AI 做的」就沒事。AI 是工具，使用工具的人是你，該負責的也是你。

下次你要用 AI 產出任何會影響到別人的東西——email、PR、報告、貼文——問自己一個問題：

如果這東西不是 AI 生的，是我自己寫的，我會直接送出去嗎？

如果答案是「不會，我會再看一遍」，那你現在也該這樣做。

AI 產出送出前的 30 秒 checklist：

1. 這個人需要收到這個嗎？ — 不是「他可能會感興趣」，是「他真的需要」
2. 我有沒有讀過一遍？ — 不是掃過，是真的讀過
3. 有沒有事實錯誤？ — AI 很會唬爛，數字、日期、名字都要確認
4. 這聽起來像我嗎？ — 如果收件人認識你，他會覺得這是你寫的嗎？
5. 出問題我願意負責嗎？ — 如果答案是「不願意」，就不該送出

我之前寫過一篇「AI 讓錯誤資訊更廉價了——所以我只看第一手內容」，講的是當我主動消費資訊時怎麼避免被 AI 垃圾污染。這篇講的是另一面：當你用 AI 產出東西給別人時，你的責任是什麼。兩篇加起來，大概就是我現在怎麼想「用 AI 但不要變成混蛋」這件事。

TL;DR: 我們 6 人 startup 用三個改變把 feature 開發時間從兩週壓到一天：(1) Spec 變輕，先做再討論 (2) AI 先 review，人 focus 架構 (3) Preview 環境加速 iteration。

「你應該明天就可以把 PR 發出來了吧？」

上週我對同事說這句話的時候，突然意識到一件事：同樣的 feature，兩年前我會說「這大概要兩週」。

這不只是工具變強的問題。我們整個團隊的運作方式，從怎麼寫 spec、怎麼分工、怎麼 review code，都跟以前不一樣了。

我們是一個 6 人 startup，過去兩年從「傳統開發流程」轉型成「AI 原生團隊」。核心改變是三件事：Spec 變輕、AI 先 review、Preview 環境讓 iteration 變快。

最大的改變：Iteration 成本變低了

先講背景：我們團隊的工程師大多是 backend 和 cloud infrastructure 背景，不是傳統的前端工程師。以前要他們寫前端，code 改得動，但會蠻痛苦的。

現在不一樣了。

有了 AI Agent 的協助，他們可以快速做 iteration，把畫面做出來、debug、然後請 coding agent 依照 best practice 確認 code quality。以前可能要花一兩週慢慢摸索的前端頁面，現在一天就能有個可以 review 的版本。

這個「iteration 成本變低」帶來的連鎖反應，比我一開始想的還要深。

我們現在怎麼運作

Spec-light, Explore-first

我們的 PM 不一定會寫很完整的 spec。方向有共識之後，就會讓工程師先做一個版本出來探索。

這聽起來很隨便，但邏輯是這樣的：AI Agent 最強的能力之一，就是可以很快完成各種不同版本的探索。既然修改成本變低了，我們就不需要花太多時間在討論「這個做法到底好不好」——直接做出來看。

探索會畫邊界：

• 時間上：先給 1-2 天，做出「可以 demo 的版本」
• 範圍上：先 cover 一條關鍵的 happy path，不碰 edge case

只要這兩個條件達成，就先用實際畫面來討論，而不是繼續在文件上拉扯。

AI Research → AI Implementation

另一個省很多時間的地方是 research。

以前要整合一個新的 third-party API，工程師得先花時間讀文件、試 request、搞清楚 response 長什麼樣子，然後才開始寫 integration code。

現在我們會直接請 agent 先做 research。實務上就是丟官方文件連結，讓它幫你整理：支援哪些主要 endpoint、常見的錯誤碼有哪些、兩三個典型的 request/response 長什麼樣子。整理完之後，直接把這個 research 結果餵給 coding agent 做整合。

中間那個「人類讀文件」的步驟被大幅壓縮了。

AI Code Review → Human Code Review

我們現在的 review 流程是這樣：code 寫完先讓 AI 過一輪 review，抓 bug、確認有沒有違反 best practice。AI review 的結果可以直接丟回 coding agent 修，等到人類工程師 review 的時候，code quality 已經至少 80 分了。

具體來說，我們把 AI review 當成 pre-review：先請 AI 幫忙找 bug、style 問題、漏掉的 edge case，然後把 AI 的 comment 整包丟回 agent 修完。人類 reviewer 只看最後一版，專注在「這個設計長期撐不撐得住」。

我們學到的事

Senior 工程師反而比較慢 Adopt

這點有點 counter-intuitive。我們團隊都是 senior 工程師，照理說應該很快就能上手新工具。但實際上，剛開始的時候他們反而不太信任 AI coding agent 的能力，沒有很積極去探索它的邊界。

Turning point 是我在每週的 weekly meeting 不厭其煩地 demo 我用 coding agent one-shot 或 few-shot 做出的功能，然後鼓勵大家去嘗試。

現在這已經變成一種自然的文化了。大家會自然地分享「這個功能用 Cursor 的 agent 一下就做出來了」，越來越清楚哪些 task 適合讓 AI 處理。

Senior vs Junior 的差距會變大

這是另一個 observation：在 AI-assisted 的環境下，senior 和 junior 的差距不是縮小，而是變大。

原因是 senior 比較容易判斷「什麼時候該停止讓 agent 繼續試」。如果試了兩三次還是沒結果，senior 會知道這個 task 用人比較快。Junior 可能會繼續跟 agent 糾纏。

另外，senior 也比較容易抓到 AI 在唬爛。AI 有時候會很有自信地給你錯的答案，沒有足夠經驗的話不容易發現。

AI 提升的是 Explore 速度，不是 Quality

這點很重要：AI coding agent 帶來最大的改變是探索的速度，不是 code quality。

AI 生成的 code 不一定比人寫的好，有時候甚至更差。但它讓你可以用更低的成本嘗試不同的方向，更快發現什麼 work、什麼不 work。

這意味著 human review 還是非常關鍵。AI 讓你快，人確保你對。

給 Tech Lead 的一週內行動清單

如果你看完想開始動，這是我建議的順序：

1. 幫全隊把 coding agent 工具先訂起來。 Cursor、Claude Code、Codex，挑一個先用。不要讓工程師自己付錢，這是公司該出的。

2. 選一個低風險的 feature，刻意用 spec-light, explore-first 的方式做一次。 跟 PM 約好：先給 1-2 天做 demo 版本，用實作來討論，不要先寫長 spec。

3. 把 AI review 變成必經步驟，human review 改成 focus 架構和商業邏輯。 讓工程師習慣：AI comment 先修完，人再看。

4. 排進本季 roadmap：建 preview environment。 這個會讓你們的 iteration 速度真正釋放出來。

寫在最後

回頭看這兩年，最大的 shift 不是我們用了什麼工具，而是我們對「合理的 timeline」的認知改變了。

以前說「這個要兩週」的時候，背後的假設是：工程師要讀 spec、做 research、寫 code、debug、自己 review、然後發 PR。這整個流程需要時間。

現在這個假設不成立了。很多步驟可以讓 AI 先跑一輪，人再來確認和調整。整體的 cycle time 大幅縮短。

「你應該明天就可以把 PR 發出來了吧？」

當你可以自然地說出這句話，而且真的是 reasonable expectation 的時候，你就知道你的團隊已經不一樣了。

TL;DR: AI 讓錯誤資訊的生產成本趨近於零。我的應對方式是回到第一手內容——直接看原始 podcast、YouTube、報導原文，自己做驗證，不信任別人處理過的二手內容。

把去年的事寫成今年

最近滑 Facebook，看到一篇貼文在講科技新聞。讀到一半，我發現日期不對——它把去年發生的事寫成今年。

不是模糊的時間描述，是明確寫錯。

我的第一反應是：這也差太多了吧。第二反應是：這個人有認真看過自己產的內容嗎？

然後我就滑掉了。

這種貼文越來越多

這不是第一次。最近滑 Facebook 和 Twitter，我越來越常有這個反應：「這又是 AI 產的。」

不是猜測，是幾乎可以確定。固定的格式、「這不是 OOXX，而是 OOXX」的句型、還有像上面那種明顯的錯誤。產內容的人可能拿了一段 YouTube transcript 或英文報導，丟給 LLM，幾秒鐘就生出一篇中文貼文。

沒有附上來源，我怎麼知道這跟原始素材是一致的？

問題：錯誤的資訊更廉價了

這不是全新的問題。在 AI 之前，不負責任的媒體就會超譯外電報導，把原文的意思扭曲成自己的版本，散播錯誤資訊。讀者不知道真相，因為他們看不到原文。

現在同樣的問題變得更嚴重了。

產內容的人在意的不是內容對不對，而是能不能快速產出、快速傳播。AI 讓這件事的成本趨近於零。資訊變得廉價是一回事，糟糕的是，錯誤的資訊更廉價了。

我不是反對用 AI

其實我不是反對用 AI 來輔助內容生產。這篇文章就是我用 AI 輔助寫的——修飾文字、讓語意更通順、重組段落。

我反對的是：用 AI 產出大量沒有經過作者思考的內容。那些貼文看不出作者有什麼觀點，只是把別人的素材丟進去，讓 AI 吐出一篇「看起來像文章」的東西，修改一下格式就發出去了。

我用 AI 會確定裡面的內容都是經過我消化過的，有我自己的觀點。

我的應對：回到第一手內容

我發現自己的行為改變了。

這裡說的「第一手內容」，不是指我親身經歷的事，而是盡量靠近原始來源的東西——原始的 podcast、YouTube 影片、blog、或報導原文，而不是別人再加工過的版本。

當我判斷一篇內容可能是我有興趣的，我不會讀那篇加工過的二手文章。我會去找背後的第一手內容。

這個習慣其實不是因為 AI 才開始的。Pre-AI 時代，當我看到報導內容怪怪的，我就會試著找原文。只是現在這件事變得更頻繁、更必要。

另一個改變是：我開始 block 大量生產或轉貼 AI 內容的帳號。台灣的 Facebook 我現在幾乎不看了。

受不了了，自己做

那些從 YouTube transcript 轉成中文文章的貼文實在太多了。有一天我想：與其一直看別人加工過的東西，不如我自己來。

我寫了一個工具，可以直接抓 YouTube 影片的 transcript，然後請 AI 幫我整理重點。關鍵是：我要求 AI 標註每個重點出自 transcript 的幾分幾秒。這樣當我懷疑某個摘要的準確度時，我可以直接跳到那個時間點去確認。

用了一陣子之後，我發現這改變了我吸收資訊的方式。有了 transcript，我可以針對內容做問答，不只是被動地讀別人整理好的版本。想確認某個細節？直接跳到對應的 timestamp 看原文說了什麼。必要時還可以看影片、聽原始的 podcast。

雖然我寫了個工具，但其實這件事門檻沒有很高。我一開始也是手動取得 transcript，試了幾次之後才自動化。取得 YouTube transcript 的方式很簡單，去 Google 搜尋「youtube transcript」就有一堆線上網站可以用，或是裝個 Chrome extension 也行。

必要時，我也會請 AI 用 web search 來交叉確認某些資訊。

核心就兩件事：

1. 從第一手內容開始——不信任別人處理過的二手內容
2. 自己做驗證——不要把判斷外包給 AI

不是每篇都要這樣

我不是說每看到一篇文章就要去挖原始來源。那太累了。

我的原則比較像是：當這個主題對我來說真的很重要，我就不會只看二手整理。或者當我讀到一篇文章覺得怪怪的，我就會試著回去找它的來源。

不是每件事都值得花這個力氣，但重要的事值得。

下一步

如果你也對現在的資訊環境感到焦慮，這是我的建議：

不要消費二手內容。找到第一手內容，自己處理。

這聽起來像是更多工作，但其實不是。你本來花時間讀那些可能有錯的二手文章，現在換成花時間讀第一手內容。差別是：你知道自己讀的是什麼。

下次你看到一篇 AI 產的內容，花點時間去找原本的出處，直接試著消化原文。你會驚訝於這些垃圾內容農場到底錯誤有多少。