以我導入任何有意義工具的經驗來說，必定會經歷三個階段：(1) 一段沒有效率的時期 (2) 一段堪用的時期，最後 (3) 一段足以改變工作流程與生活的發現期。

大多數情況下，我得逼自己撐過第一和第二階段，因為我通常已經有一套滿意且習慣的工作流程。導入新工具感覺就像額外的工作，我真的不想花那個力氣，但為了成為在專業上更全面的人，我通常還是會去做。

這篇文章記錄了我如何從 AI 工具中找到價值，以及接下來想怎麼嘗試。在充斥著過度戲劇化、炒作言論的大海中，我希望這篇能呈現一種更細膩、更克制的觀點，說明我對 AI 的看法以及這些看法如何隨時間轉變。

步驟一：放下聊天機器人

立刻停止嘗試透過聊天機器人（例如網頁版的 ChatGPT、Gemini 等）來完成有意義的工作。聊天機器人確實有價值，也是我日常 AI 工作流程的一部分，但在寫程式方面的實用性非常有限，因為你多半是在指望它們靠著先前的訓練給出正確結果，而要糾正它們，就得靠你這個真人一再告訴它們哪裡錯了。這很沒效率。

我想每個人對 AI 的第一印象都是聊天介面。我想每個人第一次嘗試用 AI 寫程式，也都是叫聊天介面幫忙寫程式。

在我還是個重度 AI 懷疑論者的時候，我第一次「哇」的那一刻，是把 Zed 的命令選單截圖貼給 Gemini，請它用 SwiftUI 重現，結果它做得非常好，讓我真的嚇了一跳。如今 Ghostty 在 macOS 上搭載的命令選單，幾乎就是 Gemini 在幾秒內幫我生出來的版本，只做了非常輕微的修改。

但當我試著在其他任務上複製同樣的成功經驗時，卻感到失望。在既有專案（brownfield）的情境下，我發現聊天介面常常給出很差的結果，而且我得在介面之間來回複製貼上程式碼和指令輸出，讓我感到非常挫折。很明顯地，這比我自己動手做還要沒效率得多。

要找到價值，你必須使用代理（agent）。代理是業界通用的術語，指能夠在循環中對話並呼叫外部行為的 LLM¹。最起碼，代理必須具備以下能力：讀取檔案、執行程式，以及發送 HTTP 請求。

步驟二：重現自己的工作

在旅程的下一個階段，我嘗試了 Claude Code。長話短說：起初我並沒有被打動。我的使用過程就是拿不到好結果。我覺得它產出的東西樣樣都得修補，整個過程花的時間比我自己動手還多。我看了部落格文章、看了影片，但就是不覺得厲害。

我沒有放棄，而是強迫自己用代理把所有手動提交的成果再重做一遍。我真的是把工作做了兩次。我會先手動完成工作，然後再跟代理纏鬥，逼它在品質與功能上產出一模一樣的結果（當然，不能讓它看到我的手動解法）。

這過程痛苦至極，因為它妨礙了我單純把事情做完。但我在非 AI 工具上也已經打滾夠久，知道這種摩擦是很自然的，而且如果不把力氣耗盡，我就無法得出一個站得住腳的堅定結論。

但，專業就這樣建立起來了。我很快就從第一原理出發，親自發現了別人早已在說的事情，而自己親身發現，讓我有了更紮實的根本理解。

1. 把工作階段拆解成各自清楚、可執行的任務。不要想在一次超大型的對話中「直接畫出貓頭鷹」。
2. 對於模糊的請求，把工作拆成規劃與執行兩個獨立的階段。
3. 如果你給代理一個驗證成果的方法，它多半會自己修正錯誤並防止退化。

更廣泛地說，我也摸清了當時代理擅長什麼、不擅長什麼，以及對於它們擅長的任務，該如何達到我想要的結果。

這一切帶來了顯著的效率提升，讓我開始自然地使用代理，感覺上已經不比自己動手慢了（但我仍不覺得有比較快，因為我多半還是在盯著代理）。

這裡值得重申的是其中的反面空間：效率提升的一部分在於理解何時不該求助於代理。把代理用在它很可能失敗的事情上，顯然是浪費大量時間，而擁有能完全避開這種情況的判斷力，本身就能省下時間²。

在這個階段，我已經從代理身上獲得足夠的價值，很樂意把它們納入工作流程，但仍不覺得有看到淨效率的提升。不過我不在意，那時我已經滿足於把 AI 當作一種工具。

步驟三：下班前的代理

為了試著找到一些效率，我接著開啟了一個新模式：每天保留最後 30 分鐘來啟動一個或多個代理。我的假設是，或許如果代理能在我反正無法工作的時間裡做出一些正向進展，我就能獲得一些效率。基本上：與其試著在擁有的時間裡做更多，不如試著在沒有的時間裡做更多。

• 深度研究任務，我會請代理去調查某個領域，例如找出特定語言中符合特定授權類型的所有函式庫，並為每一套產出數頁的優缺點、開發活躍度、社群評價等摘要。
• 讓多個代理平行嘗試我腦中模糊但沒時間開始的各種點子。我並不指望它們能產出可直接上線的東西，但或許能在我隔天接手任務時，揭示一些未知的未知。
• Issue 與 PR 的分類與審查。代理很會用 gh（GitHub CLI），所以我手動寫了個快速腳本，讓它們能平行啟動來分類 issue。我不會讓代理直接回覆，我只是想要隔天拿到報告，幫我導向高價值或低人力成本的任務。

必須說清楚，我沒有像其他人那樣讓代理整夜循環運作。在大多數情況下，代理都在半小時內就完成了任務。但在工作日的後半段，我通常已經累了、脫離了心流狀態，發現自己個人效率很差，所以把精力轉移到啟動這些代理，反而讓我隔天早上有了「熱啟動」，能比平常更快進入工作狀態。

我感到滿意，也開始覺得自己比導入 AI 之前做得更多了，雖然只是多一點點。

步驟四：外包那些十拿九穩的工作

到了這個階段，我已經非常清楚 AI 擅長與不擅長哪些任務。對於某些任務，我有高度信心 AI 能給出大致正確的解法。所以旅程的下一步是：讓代理去做那些工作，同時我去處理別的事。

更具體地說，我每天一開始會拿出前一晚分類代理的結果，手動篩選出代理幾乎肯定能處理得很好的 issue，然後讓它們在背景持續運作（一次一個，而非平行處理）。

同時，我會去做別的事。我不是去刷社群媒體（沒有比平常用 AI 前更多），也不是在看影片等等。我處於自己原本的、導入 AI 前那種深度思考的模式，專注在我想要或必須處理的事情上。

在這個階段非常重要的一點：關掉代理的桌面通知。情境切換的成本非常高。為了保持效率，我發現身為人類，我的職責是掌控何時去打斷代理，而不是被代理打斷。別讓代理來通知你。在工作自然中斷的空檔，再切過去看一下，然後繼續手邊的事。

重要的是，我認為「去做別的事」有助於抵銷那篇廣為流傳的 Anthropic 技能形成論文所提出的問題。畢竟，這是一種取捨：你把某些任務交給代理，就不會在那些任務上形成技能，但同時你仍在持續手動處理的任務上自然地培養技能。

到了這個階段，我已經堅定地進入「再也回不去」的領域。我覺得自己更有效率了，但即使並非如此，我最喜歡的是，現在我可以把寫程式與思考的精力集中在我真正熱愛的任務上，同時仍能妥善完成那些我不那麼喜歡的任務。

步驟五：打造 Harness

就算有點老生常談：當代理第一次就產出正確結果，或至少只須要些微修補時，效率會高得多。要達成這點最可靠的方法，就是給代理快速、高品質的工具，讓它能自動知道自己何時出錯。

我不知道業界是否已經有個廣泛接受的詞來稱呼這件事，但我逐漸把它叫做「harness engineering（支架工程）」。概念是，每當你發現代理犯錯，就花時間去工程化一個解法，讓代理以後不再犯同樣的錯。我不需要在這裡發明新詞；如果已有別的詞，我很樂意跟進。

這有兩種形式：

1. 更好的隱式提示（AGENTS.md）。對於簡單的問題，例如代理反覆執行錯誤的指令或找到錯誤的 API，就更新 AGENTS.md（或同等檔案）。這裡有一個來自 Ghostty 的範例。檔案中的每一行都是針對某個糟糕的代理行為而寫，幾乎完全解決了所有問題。

2. 實際寫出來的工具程式。例如，用來截圖、執行篩選過的測試等的腳本。這通常會搭配 AGENTS.md 的修改，讓代理知道這些工具的存在。

這就是我目前所處的階段。每當我看到代理做了件壞事，我都會認真努力去防止它以後再犯同樣的錯。反之，我也認真努力讓代理能夠驗證自己正在做對的事。

步驟六：讓代理隨時保持運作

與步驟五同時，我也以隨時讓一個代理保持運作為目標。如果沒有代理在跑，我就會問自己：「現在有沒有什麼事是可以交給代理去做的？」

我特別喜歡把這個目標與較慢、思考更深入的模型結合，例如 Amp 的 deep mode（基本上就是 GPT-5.2-Codex），它可能要花 30 多分鐘才做出小幅修改。但好處是，它往往能產出非常好的結果。

我（還？）沒有同時跑多個代理，目前也不太想這麼做。我發現維持一個代理在運作，對我來說是很好的平衡：一方面能做我喜歡的深度手動工作，一方面照顧我那有點笨卻又莫名高產的機器人朋友。

「隨時讓代理保持運作」這個目標目前仍只是個目標。我想現在我大概只能在正常工作日的 10% 到 20% 時間裡，有效地讓背景代理保持運作。但我正在積極努力改善這一點。

現況

以上就是我目前的狀況。

經過這趟旅程，我個人已經到了一個能成功運用現代 AI 工具的階段，而且我相信自己是以一種務實、貼近現實的克制態度在看待它。我其實不太在乎 AI 是否會長久留存³，我就是個熱愛打造東西的軟體工匠，單純因為熱愛而做。

整個領域變化得如此之快，我很確定自己很快就會回頭看這篇文章，並嘲笑自己的天真。但就像人們常說的，如果你不會對過去的自己感到不好意思，那你大概就沒有在成長。我只希望自己是朝對的方向成長！

在這件事上我沒有任何利害關係⁴，而且除了實用性之外，當然也有其他理由讓人選擇不使用 AI。我完全尊重每個人各自的決定。我不是來要說服你的！對於有興趣的人，我只是想分享我個人摸索這些新工具的方式，並讓大家一窺我一般是如何面對新工具的，無論是否與 AI 相關。