AI Agent 工程化實踐：從懷疑到精通的六個階段
來源: @hongming731 | 原文連結
日期:
標籤:
Claude CodeAgent 工程化工作流優化
來源: My AI Adoption Journey by Mitchell Hashimoto (譯者：@hongming731 / ginobefun) 日期: 2026-03-05 標籤:
AI Agent工程實踐Claude Code工作流程優化
引言：Mitchell Hashimoto 是 HashiCorp 的聯合創始人，也是終端模擬器 Ghostty 的作者。這篇文章沒有任何 AI 公司的利益背景，記錄的是一個資深工程師從 AI 懷疑論者到熟練使用者的真實歷程。他把這段經歷拆成了六個清晰的階段，每一步都有具體的方法論和踩過的坑。對於那些還在糾結 AI 到底能不能幫上忙、或者已經試過但覺得不過如此的開發者來說，這可能是目前最務實的一份參考。
我用任何一款有分量的工具，基本都會經歷三個階段：一開始效率反而變低，然後慢慢用得順手，最後才真正發現它能改變工作方式甚至生活方式。
大多數情況下，前兩個階段我都得逼自己往前走。畢竟手頭已經有一套用著舒服的工作流了，學新東西本身就是一種負擔。但為了不讓自己的技術視野變窄，我通常還是會硬著頭皮去試。
這篇文章記錄的就是我從 AI 工具中找到價值的整個過程，以及接下來的計劃。在一片誇大和炒作的聲音裡，我希望這篇能代表一種更務實、更有分寸的視角。
這篇文章完全是我手寫的，每個字都是我自己的。討厭必須聲明這一點，但考慮到文章主題，還是說清楚比較好。
第一步：放下聊天窗口
首先要做的，是停止試圖通過聊天機器人（ChatGPT、網頁版 Gemini 之類的）來完成真正的編碼工作。聊天機器人有它的價值，也是我日常 AI 工作流的一部分，但用它來寫代碼效率很有限——你基本上是在賭它能憑訓練數據給出正確答案，而糾錯方式就是你反覆告訴它哪裡不對。這太低效了。
我想大多數人接觸 AI 的第一站都是聊天界面，第一次嘗試用 AI 寫代碼也是在聊天界面裡。
我還是個重度 AI 懷疑論者的時候，有過一個讓我大為震驚的瞬間：我把 Zed 編輯器的命令面板截了個圖扔給 Gemini，讓它用 SwiftUI 複刻出來，結果做得相當好。今天 Ghostty macOS 版裡的命令面板，就是在 Gemini 幾秒鐘生成的結果上稍加修改而來的。
但當我想在其他任務上重現這種體驗時，就很失望了。在已有項目的代碼庫裡，聊天界面給出的結果經常很差，來回複製粘貼代碼和命令輸出的過程讓我非常煩躁。很明顯，這比自己動手寫要慢得多。
要真正從 AI 中獲得價值，你得用 Agent。這是行業裡通用的叫法，指的是一個能對話、能循環調用外部工具的大模型。最起碼，它得能讀文件、執行程序、發 HTTP 請求。
像 Opus 和 Codex 這樣的現代編碼模型，經過專門訓練，在工具調用上的傾向性遠強於普通對話模型。
第二步：用 AI 複現自己的手動工作
接下來我試了 Claude Code。直說吧：一開始沒覺得有多厲害。幾次會話下來結果都不太理想，產出的東西每個都要修，修完發現還不如自己從頭寫來得快。讀了不少博客、看了不少視頻，還是沒被打動。
但我沒放棄。我強迫自己把每次手動提交的工作，都用 Agent 重新做一遍——字面意義上的做兩遍。先手動完成，再讓 Agent 在看不到我方案的前提下，產出同等質量和功能的結果。
這個過程非常折磨人，嚴重拖慢了實際產出。但我用非 AI 工具的經驗夠多了，深知摩擦是自然的，不把勁使完就下結論站不住腳。
然後，經驗慢慢長了出來。我通過自己的實踐從頭驗證了那些別人早就在說的東西，但正因為是自己摸出來的，理解要深刻得多：
- 把任務拆成獨立的、目標明確的小塊，別想在一個大會話裡一步到位。
- 模糊的需求，先拆成規劃會話和執行會話兩步走。
- 如果你給 Agent 提供驗證自身輸出的手段，它多半能自己修錯、防止回退。
更宏觀地說，我也摸清了 Agent 當時擅長什麼、不擅長什麼，以及擅長的任務該怎麼引導才能拿到想要的結果。
這些積累帶來了明顯的效率提升。到後來，我用 Agent 已經自然到不覺得比自己做慢了——雖然也沒覺得更快，畢竟大部分時間還是在盯著 Agent 幹活。
這裡值得強調一下反面：效率提升的一部分恰恰來自於知道什麼時候不該用 Agent。讓 Agent 去做它大概率搞砸的事，顯然是巨大的時間浪費，而避開這些場景本身就是在省時間。
由於模型迭代速度極快，我對什麼該用、什麼不該用 Agent 的判斷也在不斷更新。
走到這一步，我已經能從 Agent 身上獲得足夠的價值，願意把它納入日常工作流了，但還沒感覺到淨效率增長。不過我不介意——AI 作為工具，我已經滿意了。
第三步：下班前啟動 Agent
為了再擠出一些效率，我開始了一個新習慣：每天留出最後 30 分鐘來啟動一個或多個 Agent。我的設想是，與其在工作時間裡試圖做更多，不如在我本來就做不了事的時間裡讓 Agent 替我幹活。
跟之前一樣，一開始又是既不成功又煩人。但很快我發現了幾類特別有用的場景：
深度調研。比如讓 Agent 掃描某個編程語言下的所有庫，按特定許可證類型篩選，然後為每個庫產出多頁總結，涵蓋優缺點、開發活躍度、社區評價等。
並行探索模糊想法。讓多個 Agent 各自嘗試我腦子裡還不成形的方案。不指望它們產出能上線的東西，但也許能幫我發現一些盲點，方便第二天正式開工。
Issue 和 PR 的分診。Agent 能很好地操作 gh（GitHub CLI），所以我寫了個簡單的腳本批量並行啟動 Agent 來分類 issue。我不讓 Agent 直接回覆任何人，只要第二天早上給我一份報告，幫我定位高價值或低成本的任務就行。
說清楚，我沒有像有些人那樣讓 Agent 整夜循環運行，大部分任務半小時以內就跑完了。但到了一天的後半段，我通常已經比較疲憊，心流也斷了，個人效率其實很低。把這段時間用來啟動 Agent，能讓我第二天早上有個熱啟動，進入狀態比平時快不少。
到這個階段我已經很滿意了，開始感覺自己比用 AI 之前做得更多——雖然幅度不大。
第四步：把穩贏的任務交出去
到這時候，我對 AI 擅長什麼、不擅長什麼已經非常有把握了。有些任務我信心很高，Agent 幾乎肯定能給出基本正確的方案。所以下一步就是：讓 Agent 在後台處理這些事，我同時去做別的。
具體來說，每天早上我會看前一晚分診 Agent 的報告，手動篩出那些 Agent 大概率能搞定的 issue，然後一個一個地丟給後台 Agent 處理（不是並行）。
與此同時，我自己在做別的事。不是刷社交媒體（至少不比沒有 AI 的時候刷得多），不是看視頻，而是進入我 AI 之前就有的那種深度思考模式，處理我想做的或者必須做的工作。
這個階段有一點很重要：關掉 Agent 的桌面通知。上下文切換的代價非常大。要保持效率，應該由人來決定什麼時候去看 Agent 的進展，而不是讓 Agent 來打斷你。在你自己工作的自然間隙裡切過去看一眼就好。
還有一點值得說。這種自己做一件事、Agent 做另一件事的模式，我覺得能在一定程度上對沖 Anthropic 那篇廣為討論的技能形成論文帶來的擔憂——你確實不再為交給 Agent 的任務積累技能了，但你仍然在為親手做的任務正常地磨練手藝。
走到這裡我已經完全回不去了。就算效率提升不明顯，我最喜歡的一點是：我可以把編碼和思考的精力集中在自己真正熱愛的任務上，而那些不那麼有趣的事情也能被妥善完成。
第五步：打造工程化約束（Harness Engineering）
這一步可能有點顯而易見：Agent 第一次就做對——或者只需要最少量修正——的時候效率最高。而達成這一點最靠譜的方式，就是給 Agent 提供快速、高質量的反饋工具，讓它能自動發現自己做錯了。
我不確定行業裡有沒有統一的叫法，我自己管這個叫 harness engineering。核心思路是：每當發現 Agent 犯了一個錯，就花時間做一個工程化的方案，讓它以後不再犯同樣的錯。如果已經有更好的術語，我隨時切換。
這分兩種形式：
一是優化隱式提示，也就是 AGENTS.md。對於簡單的問題——比如 Agent 老是跑錯命令或者調錯 API——直接更新 AGENTS.md 就行。Ghostty 項目裡就有一個，每一行都對應 Agent 曾經犯過的某個錯誤，效果立竿見影，幾乎把那些問題全部解決了。
二是編寫專用工具。比如自動截圖腳本、過濾測試腳本等，通常配合 AGENTS.md 的更新來使用，讓 Agent 知道這些工具的存在。
這就是我目前的狀態。每次看到 Agent 做了蠢事，我都會認真地想辦法讓它以後不再犯。反過來也一樣——我也在努力讓 Agent 能夠驗證自己做的是對的。
第六步：始終保持一個 Agent 在運行
與第五步同步進行的，是我給自己定的另一個目標：隨時都有一個 Agent 在運行。如果後台沒有 Agent 在跑，我就問自己：現在有沒有什麼事可以交給它？
我特別喜歡把這個目標跟更慢但更深入的模型搭配使用，比如 Amp 的 deep mode（底層基本就是 GPT-5.2-Codex），做一個小改動可能要 30 多分鐘，但結果往往很不錯。
我目前沒有並行跑多個 Agent，暫時也不想這麼做。一個後台 Agent 對我來說是個不錯的平衡點——既能專注於有趣的深度手工活，又有一個有點笨但莫名其妙能出活的機器人朋友在旁邊幫忙。
始終保持 Agent 運行目前還只是個目標。我估計現在大概有 10% 到 20% 的工作時間裡真的有後台 Agent 在跑，但我在持續改進這個比例。
我不想為了跑 Agent 而跑 Agent，只有在確實有一個對我真正有幫助的任務時才會啟動。這個目標的挑戰之一在於改進自己的工作流和工具，讓我能有一個穩定的高質量任務流可以委派——其實這一點，就算沒有 AI，也同樣重要。
寫在最後
這就是我目前的狀態。
經過這一路，我已經在現代 AI 工具上取得了不錯的成果，而且我相信自己是用一種務實的、基於現實的態度在對待它。我真的不在乎 AI 是否會長久存在下去——我就是一個熱愛造東西的手藝人，純粹因為喜歡才做這件事。
不過，技能形成的問題確實讓我擔憂，特別是對那些基礎還不牢固的初級開發者來說。
整個領域變化太快了，我確信很快就會回頭看這篇文章，然後笑自己當時多幼稚。但話說回來，如果你對過去的自己不覺得尷尬，那你可能沒在成長。我只希望自己是在朝對的方向長。
我在這件事上沒有利益關係——不為任何 AI 公司工作，也沒有投資或顧問關係。當然，除了實用性以外還有很多理由讓人選擇不用 AI，我完全尊重每個人的決定。寫這篇不是來說服誰的，只是想分享一下我個人應對新工具的方式和思路。