Claude Code 源碼泄露後，我反而更確定：終端 Agent 只該接 3 類活

大家好，我係孟健。Claude Code 今次最值得睇嘅，唔係八卦，而係佢將終端 Agent 嘅邊界扒得更清楚咗。

以前好多人仲喺度問：Claude Code 勁唔勁，值唔值得買，會唔會將 Cursor 打低。

但係今日更現實嘅問題其實係：咩嘢工應該交俾佢，咩嘢工暫時唔好交。

如果呢個邊界冇諗清楚，Agent 唔係幫你提升效率，而係幫你提早做返工。

01 今次泄露，點解值得普通開發者關心

3 月 31 日，Claude Code 因為 npm 包入面帶咗 source map 出嚟，完整 CLI 源碼俾外界睇到咗。相關討論喺 Hacker News 直接衝到 1800+ points、900+ comments，證明呢件事已經唔係小圈子八卦，而係開發者羣體級別嘅關注。

更重要嘅係，外界唔係淨係見到一堆實現細節，而係見到幾個非常有代表性嘅設計信號：

• 有 anti-distillation 相關機制，會注入 fake tools 之類嘅反蒸餾手段
• 有 undercover mode，會盡量避免喺外部倉庫入面暴露 Anthropic 內部痕跡
• 仲有一堆對真實工作流好敏感嘅判斷：權限、上下文、會話壓縮、客戶端校驗

呢件事對我嘅啟發好直接：終端 Agent 唔係唔用得，而係佢本來就應該被擺喺「邊界清楚」嘅位置上。

爭議啲講，好多人唔係高估咗 Claude Code 嘅能力，而係高估咗自己落任務嘅清晰度。

AI 編程最貴嘅成本，唔係 token，而係你將模糊需求交出去之後，再收返嚟重做嘅一輪又一輪。

02 我而家淨係將終端 Agent 放喺 3 個位置

1）邊界清晰、驗收明確嘅實現任務

Anthropic 官方 best practices 入面寫得好直白：俾 Claude 一個可驗證嘅成功標準，係最高槓桿動作；推薦流程唔係直接開寫，而係 explore first, then plan, then code。

咁就決定了第一類最適合交俾佢嘅工：

• issue 已經寫清楚
• 改動邊界明確
• 有測試、截圖或輸出可以驗證
• 完成標準一句話可以講得清

呢種任務交俾 Agent，慳落嚟嘅唔係敲代碼嗰幾分鐘，而係少咗中間嗰幾次上下文切換。

2）重複出現、適合流程化嘅工作流任務

GitHub 喺 2 月 4 日將 Claude 同 Codex coding agents 放咗入 public preview，都證明成個行業已經喺度將 Agent 塞入工作流，而唔係淨係當聊天玩具。

官方畀嘅入口非常明確：可以從 GitHub、GitHub Mobile、VS Code、issue、PR、Agents tab 直接啟動同分派任務。

呢類最適合 Agent 嘅工通常係：

• issue 起草初版修復
• PR review comment 跟進
• 文檔、配置、測試一齊補齊
• 腳手架同重複改造任務

人唔係做唔到，而係太碎。碎到最後，真正浪費你嘅唔係技術，而係切來切去。

3）先跑第一輪、再由人拍板嘅探索任務

Claude Code 官方仲單獨將 subagents 拎出嚟講，核心價值就係：將探索同實現放進唔同上下文，減少主會話被污染。

呢其實特別似真實團隊協作。

你先俾 Agent 去：

• 掃 code base
• 列改動點
• 寫第一版計劃
• 起最小可運行版本
• 將風險先翻出嚟

然後你再決定邊條路值得繼續行。

好多人將 Agent 當最終執行者。我而家更願意將佢當第一輪推進者。

先等佢將條路踩出嚟，再由人決定值唔值得向前衝。

03 邊 3 類任務，我反而更唔會交俾佢

1）需求自己都未定清嘅工

如果你自己都講唔清楚目標、邊界同唔做啲乜，Agent 只會將模糊放大。佢會好努力，但努力錯方向，比唔努力更貴。

2）高風險嘅真實動作

涉及生產環境、賬號權限、資金、外部執行行動嘅任務，我而家都唔會俾終端 Agent 單獨閉環。能力越強，越要知道邊度必須人工接管。

3）強依賴視覺判斷同業務感覺嘅任務

複雜 UI 微調、產品取捨、老細一句話背後嘅真實意圖，呢啲唔係代碼問題，係判斷問題。判斷未定清之前，將工交出去就係預支返工。

最近 GitHub 上各種 Claude Code how-to、best practice、workflow 倉庫開始一齊冒頭，都證明用戶關注點已經從「邊個模型更強」，轉到「點樣將 Agent 接進主流程」。

04 如果你今日就要上手，我建議用呢張判斷表

我自己而家俾任務之前，會先過 4 個問題。

第一問：目標可唔可以一句話講清

如果一句話講唔清，暫時唔好掟俾 Agent。

比如：

• ✅「將呢個登入報錯修好，跑通現有測試」
• ❌「你順手將成個登入體驗優化一下」

前者係任務，後者係願望。

第二問：驗收標準係唔係客觀嘅

最好嘅驗收標準，唔係「睇落差唔多」，而係：

• 測試通過
• 頁面截圖對齊
• lint/build 成功
• 某個接口返回正確結果

Anthropic 官方 best practices 點解一直強調 verification？因為冇驗證，Agent 好容易生成「睇落好似啱嘅嘢」。呢類錯最煩。你第一眼覺得差唔多，第二日先發現根本冇真正解決問題。

第三問：出錯成本高唔高

如果呢一步一旦出錯，代價係線上事故、賬號權限、資金風險、客戶數據風險，咁就唔好追求型，直接將人工接管點前置。

我而家嘅原則好簡單：

• 低風險動作，俾 Agent 多啲跑
• 中風險動作，俾 Agent 提方案，人確認
• 高風險動作，淨係俾 Agent 做準備，唔俾佢最終執行

第四問：返工嘅時候邊個嚟收尾

好多人低估咗呢一問。

如果呢件事做歪咗，最後一定都係你自己返嚟兜底，咁你就應該提前判斷：今次交俾 Agent，到底係減少工作，定係只係推遲工作。

以前常見嘅流程係：

• 我自己讀 code
• 我自己試改
• 我自己跑測試
• 我自己回滾
• 我自己補文檔

而家更合理嘅流程應該係：

• 我先將邊界寫清
• Agent 先讀、先試、先列方案
• Agent 跑第一輪實現同驗證
• 我淨係接 review、決策同最後嘅 merge

呢個變化表面睇係「俾 AI 做多啲」。

本質上唔係。

本質上係：將你最貴嘅腦力，用喺方向判斷，而唔係用喺反覆起步。

呢個都係點解我而家越來越少問「呢個 Agent 做唔做到」，而係先問「呢件事值唔值得俾 Agent 先跑」。

問題一換，返工會即刻少好多。

05 寫喺最後

所以我今日嘅結論好明確。

Claude Code 今次泄露，真正令人睇清嘅，唔係邊段源碼更刺激，而係：終端 Agent 天生適合邊界清楚、可驗證、可回收嘅任務，唔適合幫你接住所有判斷。

如果你今日就想開始用，最穩陣嘅分工只有三步：

• 人定邊界
• Agent 跑第一輪
• 人做最後判斷

呢個先係我心目中 2026 年 AI 編程最靠譜嘅姿勢。

唔係將人拎走。

而係將人從低價值推進動作入面拎出嚟。

工具就擺喺嗰度。用唔用，係你嘅事。

🚀 想同更多 AI 愛好者交流，共同成長嗎？

同一班志同道合嘅人，持續精進 AI 嘅每一天

大家好，我是孟健。Claude Code 這次最值得看的，不是八卦，而是它把終端 Agent 的邊界扒得更清楚了。

過去很多人還在問：Claude Code 強不強，值不值得買，會不會把 Cursor 幹掉。

但今天更現實的問題其實是：什麼活該交給它，什麼活先別交。

如果這個邊界沒想清楚，Agent 不是幫你提效，而是幫你把返工提前做掉。

01 這次泄露，為什麼值得普通開發者關心

3 月 31 日，Claude Code 因為 npm 包裏帶出了 source map，完整 CLI 源碼被外界讀到了。相關討論在 Hacker News 直接衝到了 1800+ points、900+ comments，說明這已經不是小圈子八卦，而是開發者羣體級別的關注。

更關鍵的是，外界不是隻看到了一堆實現細節，而是看到了幾個非常有代表性的設計信號：

• 有 anti-distillation 相關機制，會注入 fake tools 之類的反蒸餾手段
• 有 undercover mode，會盡量避免在外部倉庫裏暴露 Anthropic 內部痕跡
• 還有一堆對真實工作流很敏感的判斷：權限、上下文、會話壓縮、客戶端校驗

這件事對我的啓發很直接：終端 Agent 不是不能用，而是它本來就該被放在“邊界清楚”的位置上。

爭議一點說，很多人不是高估了 Claude Code 的能力，而是高估了自己下任務的清晰度。

AI 編程最貴的成本，不是 token，而是你把模糊需求交出去以後，再收回來重做的那一輪又一輪。

02 我現在只把終端 Agent 放在 3 個位置

1）邊界清晰、驗收明確的實現任務

Anthropic 官方 best practices 裏寫得很直白：給 Claude 一個可驗證的成功標準，是最高槓杆動作；推薦流程不是直接開寫，而是 explore first, then plan, then code。

這就決定了第一類最適合交給它的活：

• issue 已經寫清楚
• 改動邊界明確
• 有測試、截圖或輸出可驗
• 完成標準一句話能說清

這種任務交給 Agent，省下來的不是敲代碼那幾分鐘，而是少掉中間那幾次上下文切換。

2）重複出現、適合流程化的工作流任務

GitHub 在 2 月 4 日把 Claude 和 Codex coding agents 放進 public preview，也說明整個行業已經在把 Agent 往工作流裏塞，而不是隻當聊天玩具。

官方給的入口非常明確：可以從 GitHub、GitHub Mobile、VS Code、issue、PR、Agents tab 裏直接啓動和分派任務。

這類最適合 Agent 的活通常是：

• issue 起草初版修復
• PR review comment 跟進
• 文檔、配置、測試一起補齊
• 腳手架和重複改造任務

人不是做不了，而是太碎。碎到最後，真正浪費你的不是技術，而是切來切去。

3）先跑第一輪、再由人拍板的探索任務

Claude Code 官方還單獨把 subagents 拿出來講，核心價值就是：把探索和實現放進不同上下文，減少主會話被污染。

這其實特別像真實團隊協作。

你先讓 Agent 去：

• 掃代碼庫
• 列改動點
• 寫第一版計劃
• 起最小可運行版本
• 把風險先翻出來

然後你再決定哪條路值得繼續走。

很多人把 Agent 當最終執行者。我現在更願意把它當第一輪推進者。

先讓它把路踩出來，再由人決定是不是值得往前衝。

03 哪 3 類任務，我反而更不會交給它

1）需求自己都沒定清的活

如果你自己都講不清楚目標、邊界和不做什麼，Agent 只會把模糊放大。它會很努力，但努力錯方向，比不努力更貴。

2）高風險的真實動作

涉及生產環境、賬號權限、資金、外部執行動作的任務，我現在都不會讓終端 Agent 單獨閉環。能力越強，越要知道哪裏必須人工接管。

3）強依賴視覺判斷和業務感覺的任務

複雜 UI 微調、產品取捨、老闆一句話背後的真實意圖，這些不是代碼問題，是判斷問題。判斷沒定清前，把活交出去就是預支返工。

最近 GitHub 上各種 Claude Code how-to、best practice、workflow 倉庫開始一起冒頭，也說明用戶關注點已經從“哪個模型更強”，切到“怎麼把 Agent 接進主流程”。

04 如果你今天就要上手，我建議用這張判斷表

我自己現在給任務之前，會先過 4 個問題。

第一問：目標能不能一句話說清

如果一句話說不清，先別丟給 Agent。

比如：

• ✅「把這個登錄報錯修掉，跑通現有測試」
• ❌「你順手把整個登錄體驗優化一下」

前者是任務，後者是願望。

第二問：驗收標準是不是客觀的

最好的驗收標準，不是“看起來差不多”，而是：

• 測試通過
• 頁面截圖對齊
• lint/build 成功
• 某個接口返回正確結果

Anthropic 官方 best practices 為什麼一直強調 verification？因為沒有驗證，Agent 很容易生成“看起來像對的東西”。這類錯最煩。你第一眼覺得差不多，第二天才發現根本沒真正解決問題。

第三問：出錯成本高不高

如果這一步一旦出錯，代價是線上事故、賬號權限、資金風險、客戶數據風險，那就別追求帥，直接把人工接管點前置。

我現在的原則很簡單：

• 低風險動作，讓 Agent 多跑
• 中風險動作，讓 Agent 提方案，人確認
• 高風險動作，只讓 Agent 做準備，不讓它最終執行

第四問：返工時誰來收尾

很多人低估了這一問。

如果這件事做歪了，最後一定還是你自己回來兜底，那你就應該提前判斷：這次交給 Agent，到底是在減少工作，還是隻是在推遲工作。

以前常見的流程是：

• 我自己讀代碼
• 我自己試改
• 我自己跑測試
• 我自己回滾
• 我自己補文檔

現在更合理的流程應該是：

• 我先把邊界寫清
• Agent 先讀、先試、先列方案
• Agent 跑第一輪實現和驗證
• 我只接 review、決策和最後的 merge

這個變化表面看是“讓 AI 多做一點”。

本質上不是。

本質上是：把你最貴的腦力，用在方向判斷，而不是用在反覆起步。

這也是為什麼我現在越來越少問“這個 Agent 能不能做”，而是先問“這件事值不值得讓 Agent 先跑”。

問題一換，返工會立刻少很多。

05 寫在最後

所以我今天的結論很明確。

Claude Code 這次泄露，真正讓人看清的，不是哪段源碼更刺激，而是：終端 Agent 天生適合邊界清楚、可驗證、可回收的任務，不適合替你接住所有判斷。

如果你今天就想開始用，最穩的分工只有三步：

• 人定邊界
• Agent 跑第一輪
• 人做最後判斷

這才是我心裏 2026 年 AI 編程最靠譜的姿勢。

不是把人拿掉。

而是把人從低價值推進動作裏拿出來。

工具就擺在那裏。用不用，是你的事。

🚀 想要與更多AI愛好者交流，共同成長嗎？

和一羣志同道合的人，持續精進 AI 的每一天