從程式碼補完到流程執行：AI 開發的典範轉移

AI 輔助開發的未來，重點不在於產出更精準的程式碼片段，而在於將整個開發工作流（workflow）轉化為可被機器執行的單元。當前的 AI 工具多半扮演「建議者」的角色，但像 Anthropic 的 Claude Code 這類具備 CLI（Command-Line Interface）能力的工具，正推動一場典範轉移。它讓 AI 從單純的程式碼生成，走向實際的流程執行。這意味著 AI 不再只是從旁提供意見，而是能親身參與驗證、測試、與環境互動的循環，真正從「助理」質變為可運行的「工程夥伴」。

為什麼當前的 AI 程式碼補完還不夠？

過去幾年，以 GitHub Copilot 為首的 AI 程式碼補完工具，已經成為許多開發者的標準配備。根據 GitHub 的數據，截至 2024 年初，其付費訂閱用戶已超過 300 萬。這些工具擅長根據上下文預測並生成樣板程式（boilerplate code）、函式實作，甚至是單元測試的草稿，確實提升了「撰寫」的效率。然而，它們的互動模式基本上是單向的、被動的。

開發者在編輯器中輸入，AI 提供建議，開發者採納或修改。這個過程依然被侷限在程式碼編輯器這個沙盒內。軟體開發的本質遠不止於撰寫程式碼，它是一個包含編譯、測試、打包、部署、除錯的完整循環。然而，傳統的 AI 補完工具在這個循環中是缺席的，它們面臨幾項根本限制：

首先，它們無法實際執行與驗證程式碼。AI 建議的程式碼是否能成功編譯？執行時是否會拋出預期外的錯誤？這些工具無從得知，因為它們沒有執行的能力。其次，這些工具也無法與真實的開發環境互動，例如讀取檔案系統狀態、檢查環境變數，或與資料庫等外部服務溝通。所有的上下文都僅來自開發者餵給它的文本，這使得它們的建議缺乏真實世界的基礎。更重要的是，當程式碼因權限問題或網路超時而失敗時，AI 無法從終端機的錯誤訊息中學習並修正，缺乏對真實世界回饋的理解能力。

這種模式下的 AI，充其量是一個知識淵博但四肢癱瘓的顧問。它能給出漂亮的藍圖，卻無法親手砌上一磚一瓦，也無法在施工現場發現問題時即時調整。真正的生產力瓶頸，往往不在於打字速度，而在於這些瑣碎、重複卻至關重要的「執行與驗證」環節。

從「建議」到「可執行」：AI 開發的典範如何轉移？

Execution-oriented development 的核心思想，是賦予 AI 執行的能力，讓它成為開發循環中的主動參與者。這不僅僅是技術上的升級，更是心態上的轉變。我們不再將 AI 視為一個「程式碼生成器」，而是將其看作一個可以被賦予任務、操作工具、並根據結果回報的「代理人」（Agent）。

這個典範的實現，高度依賴於 AI 與開發環境的深度整合，而 CLI 正是那個最關鍵的橋樑。終端機是數十年來開發者與電腦系統互動最直接、最有效率的介面。當 AI 能夠理解並使用 CLI，它就獲得了操作整個系統的能力。這也是為何 Anthropic 選擇為 Claude Code 打造官方 CLI 工具與 VSCode 擴充套件的原因。它將大型語言模型的推理能力，與真實開發環境的執行能力結合在一起。

我們的目標不該是追求一個一次就能寫出完美程式碼的 AI，而是一個能深度參與真實世界軟體開發中那種反覆、混亂、由回饋驅動的迭代過程的 AI。

當開發流程可以被機制化，例如「讀取需求規格、生成初步實作、編寫測試案例、執行測試、根據失敗的測試結果修改實作、再次執行測試、直到所有測試通過為止」，這整個鏈條中的每一步，都有機會交由 AI 驅動。這不僅是自動化，更是將開發者的意圖（intent）轉化為可被監督、可被重複執行的流程。這與學術界在 AutoGen 或 LangChain 等框架中探索的 Agentic Workflows 概念不謀而合。

Claude Code 的 CLI 如何體現這種轉變？

以日本開發者 gunma 在 Zenn.dev 分享的實踐為例，他展示了如何僅用一台 Mac 電腦，透過 Claude Code 的 CLI 將個人開發流程「仕組み化」（機制化）。這套方法與傳統的 AI 補完工具相比，有幾個根本性的不同：

首先，AI 具備了情境感知與互動能力。在一個 Claude Code 的 CLI 會話（session）中，AI 不僅能存取你提供的程式碼片段，還能透過執行 ls -R 來理解整個專案的目錄結構，或用 cat 讀取特定檔案的內容。這使得它的建議不再是空中樓閣，而是植根於專案的真實樣貌。當它建議修改某個檔案時，它可以直接生成 patch 指令，甚至幫你執行。

其次，它實現了即時的回饋循環。當你請 AI 撰寫一段 Python 程式碼，下一步你可以直接在同一個終端機視窗中命令它：「用 `python` 執行剛剛那段程式碼」。如果出現錯誤，AI 能直接看到標準錯誤輸出（stderr），並根據錯誤訊息提出修正方案。這個「生成 → 執行 → 觀察 → 修正」的循環，比起在編輯器和終端機之間來回切換、手動複製貼上，效率與流暢度有天壤之別。

最後，這套流程是可重複且可記錄的。整個開發過程的對話與指令都被記錄下來，形成一份可執行的「開發日誌」。這不僅有助於事後追溯，也為將個人開發技巧轉化為團隊共享的標準作業流程（SOP）提供了可能。例如，一個複雜的環境設定或資料庫遷移任務，可以被固化為一個由 AI 引導、人類監督的 CLI 腳本。

這種轉變的意義在於，AI 不再僅僅是加速我們完成單點任務的工具，而是成為一個能與我們共同推進整個專案進度的夥伴。它將瑣碎的執行細節抽象化，讓開發者能更專注於高層次的架構設計與業務邏輯。這或許才是 AI 驅動開發（AI-driven development）最應該追求的樣貌——不是取代開發者，而是成為開發者的「外部執行單元」，一個忠實、高效且不知疲倦的工程夥伴。

延伸閱讀

• Claude Code（公式 CLI / VSCode 拡張）を活かして、個人〜小規模チームの開発フローを「仕組み化」する ノウハウ
• Anthropic's official announcement on Claude for code
• "The Rise and Potential of Large Language Model Based Agents: A Survey" - 一篇關於 LLM Agent 的學術綜述論文

我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。