AI Agent 不是萬能?Claude Code 創辦人最反直覺的一句話,徹底改變我的工作流
你有沒有過這種經驗?興沖沖地打開最新的 AI 編程工具,把一個專案丟給它,以為能泡杯咖啡等它完成。結果五分鐘後回來,看到的是滿螢幕的錯誤訊息、邏輯矛盾,甚至它為了「修正」一個 bug,把你原本好好的程式碼砍掉重練。你忍不住在心裡吶喊:說好的 AI 取代工程師呢?這根本不是自動化,這是製造災難。
先別急著刪掉你的 AI 工具。問題可能不在於 AI 不夠聰明,而在於你「用」它的方式,從根本上就錯了。最近,知名 AI 頻道 AI LABS 發布了一支影片,剖析了 Claude Code 核心創建者(Boris Cherny)對於使用 AI Agent 最重要的建議。這個建議乍聽之下平淡無奇,甚至有點掃興,但仔細品味後你會發現,它正是區分「把 AI 當玩具」與「把 AI 當生產力槓桿」的關鍵分水嶺。準備好顛覆你對 AI 的想像了嗎?讓我們深入拆解,為什麼 「人類監督」 才是 AI Agent 時代最稀缺、也最珍貴的能力。
別再「放飛」你的 Agent:當 AI 開始「自信地胡說八道」
大多數人使用 AI Agent(如 Claude Code、Devin、Cursor 的 Agent 模式)最大的誤區,就是把它們當成一個「只需要下達最終目標」的超級實習生。你告訴它:「幫我把這個 App 的家登錄功能串好,並同時修正效能瓶頸。」然後你就消失了。
但現實是,當你給 Agent 一個模糊且巨大的任務時,它就會像一個過度熱情的新手工程師,將你的意圖「腦補」成一整套它自己覺得合理的方案。它不會知道你公司內部的 API 命名慣例,不會知道你為了相容舊系統留下的技術債(Tech Debt),更不知道產品經理在會議上強調的「那個按鈕不能太顯眼」背後的使用者心理學。AI 的「自由意志」在此時成為最大的災難源,它會開始創造根本不存在的函式、擅自呼叫沒有權限的服務、或者為了達成「看起來有進度」,硬生生地把未完成的程式碼推上 Git。
Boris 的核心觀點在於:你必須將 AI 視為一個「極度聰明但缺乏常識的下屬」,而不是一個全知全能的神。 如果你不給它設定明確的「柵欄」,它就會用最華麗的方式闖禍。具體來說,你必須在交付任務時,附上三個關鍵要素:精確的驗收標準(Definition of Done)、明確的技術框架(像是只能用哪個 Library)、以及最重要的——限制條件(哪些事情絕對不能做)。
「當你給 AI 一個含糊的指令,你其實是在要求它猜測你的心思。而它一旦開始猜測,錯誤就是必然的結果,只是時間早晚的問題。」
這就像你要一個米其林主廚幫你做一桌宴席,但你只丟給他一句:「隨你煮,好吃就好。」他可能會端出你最討厭的香菜,或是用你買不到的松露,讓你事後面對爆掉的預算。在你沒有明確設定「儀表板」之前,你怎麼能奢望整台車安全抵達終點?
「先規劃,再執業」:用「語言」逼出 AI 的思考過程
那要怎麼「監督」才有效率?Boris 給出的第二個關鍵啟發是:不要讓 Agent 直接開始寫 Code(或執行任務),而是要迫使其「先說出計畫」。
這聽起來很像老生常談,但這正是人類團隊與 AI 團隊最根本的差異。在人類團隊中,我們有所謂的「設計審查」(Design Review)或「RFC(Request for Comments)」文件。而在與 AI 協作時,我們通常會為了追求效率直接下指令,跳過了這個至關重要的「對齊」步驟。
在 Claude Code 的操作哲學中,這體現為「規劃模式(Plan Mode)」。你可以下達指令:「請先分析 /src 目錄下的架構,然後列出需要修改的檔案清單,以及你打算採用的實作方式,不要動任何程式碼。」
這一步驟至少有兩個巨大的好處:
- 校正「誤解」的黃金期:你可以在 AI 還沒有造成破壞前,就發現它的思維脈絡有誤。例如,它可能搞錯了系統的登入流程,此時你只需要花 30 秒打斷它,告訴它正確的邏輯,而不是等它寫完 200 行程式碼再來 Debug。
- 讓 AI 變成「思考的鏡子」:當 AI 被迫用「語言」解釋它的計畫時,它其實是在進行「鏈式思考」(Chain of Thought)。這不僅能提高它後續執行的正確率,更重要的是,它讓你看見它的思考邏輯。這就像是幫你請了一個二十四小時全天候、永遠不嫌你煩的設計夥伴,隨時替你把腦中的雛形化為可行性方案。
下次使用 AI Agent 時,請把它當成一個「需要你批准行動計畫的參謀」,而不只是「聽命行事的士兵」。這個小小的角色轉換,能讓你避開 90% 的無效溝通。
「分解任務」才是王道:AI 不適合「一步登天」,只適合「日行一善」
即使你設定了明確的計畫,AI Agent 在處理一個動輒橫跨數十個檔案的大型任務時,仍然容易讓無窮的錯誤累積到崩潰。Boris 建議中最容易被忽略、卻最實際的智慧是:永遠不要讓 AI 做「大事」,要讓它做一千件可以被驗證的「小事」。
「請最佳化整個專案的效能」與「請分析 utils/logger.js 的函式執行時間,找出負擔最重的 3 個函式並提供優化建議」,這兩者對 AI 來說,難度天差地遠。
前者會讓 AI 陷入「抽象的徬徨」,它會嘗試一次載入多個檔案脈絡,最終超出上下文視窗(Context Window),導致「失憶」或產生幻覺,甚至為了實現「優化」而不小心改壞了嚴謹的商業邏輯。後者給了一個明確的、範圍極小的「任務邊界」,這讓 AI 能夠專注地調用有限的上下文資源,並提出一個可以被你快速檢驗的具體成果。
這個概念被稱為「最小可行任務」(Minimum Viable Task)。 這正如敏捷開發(Agile)中的核心精神:目的不是為了怕麻煩而將任務「碎片化」,而是為了確保每一次的「輸入」都能被「驗證」。
當你這樣做時,奇蹟發生了:
- 錯誤成本指數級下降:因為每個步驟都很小,就算 AI 犯錯,你也能在五秒鐘內定位問題,而不是在數百行程式碼的汪洋中撈針。
- 品質管控變成「點擊遊戲」:就像把大型軟體專案拆成一個又一個的約會(Sprint),你只需要在每個回合結束時,像檢查報告般進行測試(Code Review),按個讚或打個叉,AI 就能在下一輪立刻修正。
這背後隱藏著一個殘酷的 AI 算力現實:當前的 LLM 有 200K 甚至 1M 的上下文窗口,但對於複雜專案,巨大的上下文反而是「毒藥」。太多的不相關資訊會稀釋 AI 的注意力。透過「分解任務」,你其實是在幫 AI 做「資訊減肥」,讓它的腦力(算力)聚焦在真正重要的刀口上。
擺脫「完美主義」:AI 時代,你要當「驗收員」而不是「創作者」
最後一個,也是最顛覆性的思維轉換:在 AI Agent 的協作流程中,人類的角色必須從「執行者」(Doer)轉變為「驗收員」(Reviewer)與「決策者」(Decision Maker)。
這不是要你變得懶惰,而是要你把時間花在「機器無法替代」的事情上——品味、取捨與最終責任。當 AI 快速產出程式碼、文案或數據分析時,我們的工作不是去「寫」,而是去「問」:這符合我們的品牌調性嗎?這程式碼的維護成本會不會太高?這數據背後的假設合理嗎?
Boris 的「Greatest Tip」總結起來其實就是一句話:「Treat AI like a brilliant but reckless junior developer — you wouldn't let a junior run the company, but you'd be an idiot not to delegate the grunt work to them.(把 AI 視為一個才華洋溢但魯莽的初階開發者——你不會讓初階的員工管理整個公司,但如果你不懂得把繁瑣的雜事交給他們,你就是個傻瓜。)」
你必須建立一套「AI 成果驗收清單」:
- 這個輸出是否遵循了我原本設定的架構與限制?
- 它是否有過度的、不必要的創新?
- 它是否隱藏了潛在的資安漏洞或邏輯死角?
當你用這樣的心態去審視 AI 的產出時,你才真正掌握了「效率」二字。你不再會為了 AI 的失敗而感到沮喪,因為你知道,你需要做的就是提供精準的目標、審視過程中的里程碑,並且在最後為這個 AI 的產出蓋上「品質保證」的章。有了人類這個最終把關者,AI 才能真正成為加速器,而不是一台脫韁的跑車。
核心對比總表:老方法 vs. Claude Code Creator 的建議
為了讓你更清晰地捕捉兩者的巨大差異,我整理了一份對照表,讓你一眼看懂「錯誤使用」與「高效協作」的鴻溝。
| 協作維度 | ❌ 傳統錯誤用法 (Toy) | ✅ 創辦人建議的槓桿用法 (Tool) |
|---|---|---|
| 任務定義 | 「幫我搞定這個專案。」 | 「請先基於 README 提出三個實作方案,並列出優缺點。」 |
| 執行粒度 | 要求一次完成跨十個檔案的重構。 | 要求只修改特定的 api.service.ts 檔案並添加單元測試。 |
| 人類角色 | 旁觀者(等結果) | 審查者(看過程、抓方向) |
| 錯誤容忍度 | 致命的(崩塌式錯誤) | 可控的(馬上定位、馬上修正) |
| 思考模式 | 黑箱(不可解釋) | 白箱(強迫敘述計畫,讓邏輯透明化) |
| 核心指標 | 透過的 Token 數量 (花多少錢) | 產出品質與可維護性 (省多少時間) |
結語:未來的工程師,不是「寫 Code」的人,而是「管理 AI」的人
Claude Code 創辦人的這個建議,聽起來一點都不「科幻」,甚至有點像在「潑冷水」。但這正是它偉大的地方。它告訴我們,與其恐懼 AI 搶走工作,不如將 AI 視為一面映照我們「思考模糊」與「管理不善」的鏡子。當一個工具強大到唾手可得時,真正的競爭壁壘,在於你能不能給出那個「對的問題」與「明確的邊界」。
所以,下一次當你準備打開 ChatGPT、Claude 或任何 AI Agent 時,請在內心戒掉「粗暴的指令」,改以「嚴厲的溫柔」對待它。明確的驗收標準、事前的計畫審查、將任務化整為零的耐心,以及最終對成品毫不妥協的驗收——這些枯燥的「人類行為」,才是榨乾 AI 生產力的終極引擎。
這是一個由「手動操作」進化到「智慧監管」的典範轉移。你準備好從一個痛苦的「打字員」,升格為指揮千軍萬馬的「AI 將軍」了嗎?當你的 AI 開始「自信地胡說八道」時,你是否有足夠的紀律,在第一時間制止它,並將它導回正軌?這,才是我們這個時代最重要的技能。