AI 開發的典範轉移：從即興指令到計畫驅動
當 AI 工具的計價模式轉向 Token 制，真正的成本已非 prompt 長度，而是來回修改的浪費。本文深入探討，為何在 AI 時代，最有效的開發紀律是回歸基本功：先定義計畫、邊界與驗收條件，將開發流程從即興問答，轉變為目標清晰的計畫執行，這不僅能省下 Token，更能提升交付品質。
隨著 GitHub Copilot 等 AI 開發工具轉向以 Token 量計價，我們的開發紀律也必須跟著演進。真正的成本瓶頸，已不再是 prompt 的長度，而是因方向錯誤、需求模糊所導致的大量重工與溝通債。我認為，在 AI 時代最能有效降低成本、提升交付品質的方法，並非鑽研更精巧的 prompt 技巧，而是回歸軟體工程的基本功：將開發流程從「指令驅動」的即興式互動，切換為「計畫驅動」的結構化執行。先對齊計畫、邊界與驗收條件，才是最根本的「省錢」之道。
GitHub Copilot 的新定價：為何我們需要重新思考開發流程？
一個明確的外部驅動因素，是 GitHub Copilot 即將到來的計價模式變革。從 2026 年 6 月 1 日起，現行的收費方式將會調整，逐漸轉向以 Token 消耗量為基礎的「GitHub AI Credits」制度。這項改變的核心在於，它讓開發成本變得更加透明，也更直接地與我們的使用行為掛鉤。
其中最值得注意的細節，是 Input Token（我們輸入的指令與程式碼）與 Output Token（AI 生成的內容）之間顯著的成本差異。根據開發者社群的分析與初步揭露的資訊，Output Token 的單價可能是 Input 的 5 倍之多。這意味著，讓 AI 大量生成程式碼，特別是生成不符合需求的程式碼，將會直接導致開發成本的飆升。過去那種「先讓它寫寫看，不對再改」的粗放式做法，在新規則下將變得極為奢侈。
為什麼「指令驅動」的即興開發不再划算？
過去，我們習慣將 Copilot 或其他 AI 助理當成一個隨傳隨到的顧問，透過一連串的即時指令與修正來完成任務。這種「指令驅動」的模式非常靈活，適合探索性的小任務，但當面對複雜需求時，其缺點便暴露無遺。
當我們把一個模糊的需求直接拋給 AI Agent，它或許能產出一個看似可行的方案，但這個方案很可能與我們內心的期望存在巨大落差。接下來會發生什麼？我們將不可避免地進入一個昂貴的修正循環：
- 發現偏差：我們花費時間閱讀、測試，才發現 AI 的實作邏輯或邊界條件處理不符預期。
- 修正指令：我們試圖用更精確的自然語言去描述「我不是這個意思」，把新的上下文加入 prompt。
- 重新生成：AI 根據新指令再次生成大量程式碼（昂貴的 Output Token），但可能又產生新的誤解。
這個循環的每一輪，都在消耗大量的 Output Token 與工程師寶貴的專注力。根據軟體工程領域的經典研究，缺陷發現得越晚，修復成本就越高，這個原則在 AI 協作中同樣適用。AI 生成的「錯誤方向」就是一種早期的設計缺陷，而即興式的開發流程，恰恰系統性地延遲了這個發現的時機。
在 Token 計價的時代，最昂貴的不是思考，而是讓 AI 在錯誤的方向上「空轉」。每一次大規模的重寫，都是對預算與時程的直接衝擊。
如何建立計畫驅動的 AI 協作流程？
要打破這種昂貴的循環，我們必須將重心從「事後修正」轉移到「事前規劃」。這並不是要回到僵化的瀑布式開發，而是在敏捷的框架下，為每一次 AI 協作任務建立一個清晰的「微型契約」。這個流程可以簡化為三個步驟：計畫、實作、審核。
- 第一步：計畫 (Plan)
在要求 AI 寫任何程式碼之前，先由人類工程師定義好清晰的邊界與規格。這不需是長篇大論的規格書，而是一份簡潔卻精確的執行計畫。例如，如果要實作一個函式，計畫可能包含：- 函式簽名 (Function Signature)：名稱、參數型別、回傳值型別。
- 行為描述 (Behavior Description)：用註解或偽代碼（pseudocode）描述其核心邏輯。
- 驗收條件 (Acceptance Criteria)：明確的輸入與預期輸出，包含邊界情況與錯誤處理。
- 第二步：實作 (Implement)
將這份清晰的計畫作為 prompt 的核心，交給 AI 進行實作。此時，AI 的角色不再是天馬行空的「創意發想者」，而是一個高效的「執行者」。因為目標明確，AI 生成的程式碼將更貼近需求，大幅減少初次生成的偏差。 - 第三步：審核 (Review)
人類工程師的角色，是根據第一步訂下的「計畫」與「驗收條件」，對 AI 生成的程式碼進行審核。審核的重點不再是「感覺對不對」，而是「是否符合規格」。這讓 Code Review 過程更客觀、更快速。
這個模式的精神，與測試驅動開發 (TDD) 或行為驅動開發 (BDD) 如出一轍，都是「先定義，後實作」。這份預先定義的計畫，不僅是給 AI 的指令，更是我們自己釐清思路、確保方向正確的工具。
除了節省成本，計畫驅動還能帶來哪些工程價值？
將 AI 開發從即興指令轉向計畫驅動，其價值遠不止於節省 Token 費用，它更代表著一種對軟體工程紀律的重新承諾。AI 工具的強大，不應讓我們放棄那些經過數十年驗證的最佳實踐，例如清晰的規格定義、模組化設計與契約式編程 (Design by Contract)。
事實上，AI 的出現反而凸顯了這些基本功的重要性。正如許多研究指出的，人與 AI 的協作模式正在重塑軟體開發的未來，人類的核心價值，也正從親手編碼轉向更高層次的架構設計、需求分析與品質保證。一個定義不清的問題，無論交給人類新手還是頂尖 AI，都難以得到正確的答案。
最終，最能善用 AI 力量的團隊，不會是那些最會「詠唱」的團隊，而是那些擁有最嚴謹工程文化的團隊。他們懂得如何提出好問題，如何定義清晰的邊界，以及如何驗證交付的成果。在 AI 成為基礎設施的未來，這種回歸基本功的計畫驅動思維，才是建立高效、可控且可持續開發流程的關鍵。
我是江中喬，專注於 AI Agent Architecture、Memory Governance 與 Cognitive Diversity，持續研究如何打造能夠長期協作、可信任且可治理的 AI 系統。