懶人包：五點看懂 AI 程式工具使用方式的轉變。第一，創始人不再建議先用規劃模式，而是改用自動模式，讓工具更獨立運作。第二，規劃模式容易造成權限疲勞，使用者會在沒有仔細審閱的情況下自動批准建議。第三，開發者不應只在對話中糾正 AI 的錯誤，而應把錯誤與教訓記錄下來，避免重複發生。第四，AI 應該超越程式碼驗證，實際啟動應用程式、操作介面並檢查功能。第五，新的目標導向指令與上下文最小化趨勢，代表給模型最少的必要資訊反而能發揮最大效用。
人工智慧工具日新月異，連帶影響程式開發者的工作方式。Anthropic 開發的 AI 程式開發工具 Claude Code 的創始人鮑里斯·切爾尼，近期分享了他對如何最大化利用這款工具的最新建議，其中部分觀點與他過往的推薦大相逕庭，為程式開發的工作流程帶來全新思維。這些建議是在 Claude Code 一週年慶祝活動的影片中，與產品負責人 Cat Wu 對談時提出的，隨後也由官方在社群媒體上發布亮點。
其中一項重要轉變，是對同步命令列介面工作流程的看法。鮑里斯·切爾尼表示，他不再使用過去建議的規劃模式，原因是隨著新一代模型的能力顯著提升，已經不再需要單獨的規劃階段。過去需要先把計畫寫清楚、再一步步執行的流程，現在可以直接交給能力更強的模型處理，省去中間的等待與切換成本。
規劃模式被放棄的另一個原因，是它容易造成權限疲勞。當系統不斷跳出批准請求，使用者很容易在沒有仔細審閱的情況下就自動批准 AI 提出的建議，審查反而變成形式。與其讓人在疲勞中點頭，不如改用自動模式，透過獨立的安全分類器評估工具操作，無需人工手動批准，讓工具能更獨立運作並減少工作流程的中斷。
自動模式的關鍵，在於把安全檢查交給專門的機制，而不是依賴使用者的每一次點擊。獨立的安全分類器會評估工具操作是否合適，符合標準的操作可以直接執行，這讓開發流程更連續，也避免因為頻繁中斷而打斷思考。對開發者來說，這是一種信任機制的轉移：從人盯著每一步，轉向讓系統先把關、人在更高層次上掌握方向。
第二項建議與錯誤處理有關。鮑里斯·切爾尼提出，開發者不應僅在對話中糾正 AI 的錯誤，而應要求工具把所犯的錯誤以及從中學習到的教訓，記錄在 CLAUDE.md 檔案或專用的技能模組中。CLAUDE.md 是一個 Markdown 組態檔，能為人工智慧程式設計代理提供永久的專案介紹與脈絡，讓同樣的錯誤不會在未來的會話中一再重複。
這個做法的意義在於把經驗留下來，而不是留在某一次對話裡。對話結束後，口頭的糾正就會消失，下一次開新會話又要從頭教起；但如果錯誤與教訓被寫進專案檔案或技能模組，之後的每一次使用都能自動參考，減少使用者的介入次數。長期來看，這是一種把個人經驗轉換成團隊資產的方式。
第三項建議是關於測試的範圍。鮑里斯·切爾尼強調，AI 應該超越標準的程式碼驗證，進一步測試其所建立的應用程式。也就是說，光是檢查程式碼寫得對不對還不夠，還要實際啟動應用程式、與使用者介面互動，並檢查功能是否正常運作。這一步把驗證從紙上談兵推向真實使用情境。
Cat Wu 也分享了相關的做法：他們使用一種桌面開發技能，讓工具能啟動應用程式、與介面互動、點擊操作、測試功能、識別並修正錯誤，然後重新測試。這個循環的重點在於閉環：發現問題、修正問題、再驗證一次，而不是只做到發現問題就停下來。對開發者而言，這代表 AI 的角色從寫程式的助手，擴大到能自己動手驗收的協作者。
新推出的目標導向指令也反映了同樣的趨勢。使用者可以透過斜線 goal 指令定義一個具體的目標，而工具將會不斷迭代，直到達到該目標或設定的限制為止。這種方式把工作模式從一步步下指令，轉變為先講清楚終點，再讓工具自己想辦法走到終點，中間的嘗試與修正都由工具負責。
鮑里斯·切爾尼的建議也反映了上下文最小化的趨勢，意即對於更先進的 AI 模型，提供最少的必要上下文反而能發揮最大效用，減少不必要的系統指令與工具對上下文的消耗。過去習慣把所有背景資料一次塞給模型的做法，現在可能反而造成干擾，精簡而精準的資訊更能讓模型專注在真正重要的任務上。
與此相關的另一項建議，是透過建立迴圈和例行程序來自動化提示，使代理能在特定條件下自動觸發，例如 GitHub 專案出現新問題或建置失敗時。這種自動化讓 AI 不再只是等使用者開口才動作，而是能在事件發生時主動介入，把重複性的檢查與初步處理交給機器，開發者則專注在需要判斷與創意的部分。
總結來說，這些建議背後有一個共同的訊息：隨著模型迅速進步，開發者必須保持開放的心態，勇於質疑既有的工作流程。鮑里斯·切爾尼自身對於規劃模式的看法轉變，正是隨著模型改進而演變的最佳例證。昨天合理的做法，今天可能已經過時；願意根據工具能力的變化調整習慣，才是跟上 AI 開發節奏的關鍵。
對一般開發者而言，這波轉變的實用啟示有三個：第一，減少不必要的批准中斷，讓流程更連續；第二，把錯誤教訓寫下來，讓經驗可以累積；第三，驗證要做到真實操作，而不只是程式碼檢查。這三件事都不需要更強的硬體或更高的預算，改變的是工作習慣與對工具的信任方式，而這往往就是效率提升的起點。
