從對話到指令：AI 如何從開發者助理，升級為可管理的工程管線

大型語言模型在軟體工程領域的真正價值，並非來自於更流暢的對話或更驚豔的單次程式碼生成，而在於它能否被整合進標準化、可驗證的交付流程。當我們將開發工作從零散的問答，轉化為一系列明確、可重複的「指令」，AI 才從一個聰明的個人助理，升級為工程流水線中可管理的執行者。這意味著我們關注的焦點，不再是個人多會下提示詞 (prompt)，而是整個團隊能否將 AI 的能力，納入既有的標準作業程序 (SOP)、品質門檻與交付節奏中。這是一場關於工作流的典範轉移。

為什麼將開發流程「指令化」是關鍵下一步？

過去一年多，許多開發者習慣於透過對話與 AI 協作，例如請它解釋程式碼、除錯、或產生單元測試。這種模式雖然提高了個人效率——GitHub 的研究便指出，使用 Copilot 的開發者完成任務的速度提高了 55%——但它本質上是零散且難以規模化的。每一次互動的品質，高度依賴提問者的經驗、情境掌握，以及 AI 模型當下的不確定性，導致產出結果難以預測與標準化。

然而，軟體工程的核心始終在於建立可靠、可重複的流程。我們追求的不是一次性的靈光乍現，而是穩定、高品質的交付。正因如此，將開發流程「指令化」成為了解決上述挑戰的關鍵一步。

它的核心思想，是將一系列經過驗證、由多個步驟組成的最佳實踐，封裝成一個單一指令。當 AI 執行這個指令時，它遵循的是一個預先定義好的腳本，而非進行開放式的即興創作，確保了結果的可預期性與一致性。

這種轉變帶來幾個顯著的好處：

• 標準化 (Standardization)：確保團隊中每個人，無論資歷深淺，在執行特定任務（如建立新功能分支、撰寫 commit message、或產生 API 文件）時，都遵循相同的規範與品質標準。
• 可驗證性 (Verifiability)：指令化的輸出格式更為固定，使其易於被後續的自動化工具（如 linter、測試框架）進行驗證，從而確保品質。
• 降低認知負擔 (Reduced Cognitive Load)：開發者不再需要記住繁瑣的步驟或最佳提示詞公式，只需呼叫一個簡單的指令，例如 /develop-issue，就能啟動一個複雜但標準化的工作流。

Claude Code 的 Custom Skill 如何將 SOP 轉化為 AI 指令？

這個概念並非紙上談兵。近期的開發工具已經開始內建此類功能，例如 Anthropic 在其 Claude Code 預覽版中提供的 "Custom Skill" 功能，就是一個極佳的範例。開發者可以透過一個名為 SKILL.md 的檔案，來自定義專屬於自己專案的「斜線指令」(slash command)。

這個 SKILL.md 就像一本 AI 的工作手冊或食譜。我們可以在裡面定義一個指令，例如 /feature-idea，並詳細描述當這個指令被呼叫時，AI 應該執行的具體步驟。例如，它可能包含以下流程：

1. 分析使用者提供的功能想法。
2. 根據預先定義的模板，生成一個包含使用者故事、技術規格、潛在風險的 issue 描述。
3. 建議 3-5 個相關的檔案與函式，作為實作的起點。
4. 產出對應的初步測試案例結構。

透過這種方式，我們不是在與 AI「聊天」，而是在「指派任務」。每一次呼叫 /feature-idea，AI 都會穩定地執行同一個被明確定義的 SOP。這使得 AI 的產出不再是隨機的靈感，而是一個可預期、可信賴的工程產物。這種模式的價值，在於將個人的隱性知識（如何有效地與 AI 溝通以完成某項任務）轉化為團隊共享、可執行的顯性資產。

我們追求的不再是「更聰明的對話」，而是「更可靠的執行」。當 AI 的行為可被預測、其產出可被驗證時，它才真正從一個輔助工具，轉變為軟體交付供應鏈中的一環。

如何設計有效的 AI 指令化工作流？

將工作流指令化，本身就是一門值得深究的工程學問。這不僅僅是把一長串提示詞包裝起來，而是需要更結構化的思考。根據 Zenn.dev 上一位開發者 gunma 的實務分享，以及我們對軟體開發生命週期自動化的觀察，有效的指令設計應遵循幾個原則：

首先是原子性 (Atomicity)。一個好的指令應該專注於做好一件事。與其設計一個包山包海的 /do-everything 指令，不如將其拆解為 /plan-feature、/write-code、/generate-tests、/draft-pr-description 等更小、更專注的指令。這不僅讓每個指令的職責更清晰，也提高了它們被組合使用的彈性。

其次是可組合性 (Composability)。原子化的指令為工作流的組合提供了可能。開發者可以像使用 Unix pipe 一樣，將前一個指令的輸出作為後一個指令的輸入，形成更複雜、客製化的工作鏈。例如，先執行 /plan-feature 產生規格，再將其輸出交給 /write-code 進行實作。

最後是邊界清晰 (Clear Boundaries)。每個指令都應該有明確的輸入要求與輸出格式，這就像定義一個函式的簽名 (function signature)。

當 AI 知道它需要什麼樣的輸入，以及必須產出什麼樣的結構化輸出（例如 JSON 或符合特定格式的 Markdown），它的表現會更加穩定，其產出也更容易被其他自動化工具所串接。這種對結構的強調，是區分工程應用與日常聊天的關鍵，也是現代模型如 Claude 3.5 Sonnet 強調 Tool Use (Function Calling) 能力的核心原因。

當我們開始用設計 API 的思維來設計與 AI 的互動時，AI 就不再是一個黑盒子，而是我們軟體交付流程中一個可預測、可測試、可依賴的組件。這條路徑，才能讓 AI 的潛力在工程組織中被真正釋放，從而系統性地提升整個團隊的交付能力，而不僅僅是個體開發者的生產力。

延伸閱讀

• Research: Quantifying GitHub Copilot’s impact on developer productivity and happiness (GitHub Blog)
• Introducing Claude Code (Anthropic)
• Claude Code の custom skill の設計パターンと落とし穴まとめ (Zenn.dev)
• Automating the Software Development Lifecycle with Large Language Models: A Survey (arXiv)
• Tool use (function calling) (Anthropic Official Documentation)

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