前言

在 AI 驅動開發的世界裡，現在各種方法與關鍵字正不斷湧現。

• 提示工程
• 上下文工程
• 規格驅動開發（SDD：Specification-Driven Development）
• 代理式工作流程
• 支架工程（Harness Engineering）
• Vibe Coding

新概念接連出現，讓不少人不禁困惑：「到頭來哪個才是正解？」

我們團隊也曾針對這個主題，連續約 6 週每週進行討論。我們將 Cursor 與 GitHub Copilot 正式導入工作流程，並在多個專案中持續實作，嘗試各種不同的方法。

結果，我們發現了一件有趣的事。

切入的手法很多樣，但往深處看，本質上會收斂到同一個結論。

本文將從現場實踐與討論中得到的「AI 驅動開發的本質」出發，不過度拘泥於個別方法，而是聚焦在更核心的部分進行探討。

目次

1. 手法百家爭鳴，以及其背後的共通結構
2. AI 驅動開發的進化脈絡 ― 三種工程化
3. 開發者角色的本質變化
4. 文件與程式碼的一元化 ― SSOT 的重新定義
5. 上下文的設計不是「加法」，而是「減法」
6. AI 輸出的品質保證 ― 如何處理自然語言無法擔保的領域
7. 不可迴避的課題：重新發明審查
8. 比手法更重要的「敏捷心態」
9. 結論 ― 所有手法都會收斂到同一點

1. 手法百家爭鳴，以及其背後的共通結構

1.1 為什麼會有這麼多手法出現

AI 驅動開發相關手法之所以不斷誕生，背後有 LLM（大型語言模型）的兩個特性。

• 非決定性 —— 相同輸入也可能產生波動的輸出
• 高度依賴上下文 —— 提供什麼內容，輸出品質就會劇烈改變

如何控制這兩個特性，是所有手法的出發點。由於控制的切入點不同，手法也就變得多樣化。

1.2 所有手法共通的三個要素

然而，無論深入探討哪一種手法，最後都會歸結為以下三個要素。

要素角色輸入設計要給 AI 什麼（上下文）流程設計要按什麼順序讓它做什麼（工作流程）輸出驗證如何驗證輸出並回饋SDD 是以「流程設計」為核心的手法；上下文工程是以「輸入設計」為核心；支架工程則是以「輸出驗證」為核心。它們的強調點不同，但都包含了這三個要素。

也就是說，無論選擇哪一種手法，最終目標都會收斂到「妥善設計這三個要素」。

2. AI 驅動開發的進化脈絡 ― 三種工程化

2.1 三種進化脈絡

業界出現的各種手法，其實描繪出一條相當清晰的進化脈絡。

（1） 提示工程
┗（對 AI 下指令的技巧）
↓
（2） 上下文工程
┗（設計提供給 AI 的整體脈絡）
↓
（3） 支架工程
┗（對 AI 輸出的機械式品質保證）

（1） 提示工程

這是最早期的作法，也就是「只要把問題問得好，就能得到好答案」的階段。重點在於琢磨單次指令（Prompt）。

（2） 上下文工程

只靠提示還不夠，於是進一步進入「讓 AI 讀哪些檔案」「先給哪些規則」「過去的聊天紀錄要怎麼處理」等，針對提供給 AI 的整體脈絡進行設計的階段。

SDD 與代理式工作流程，可以理解為把這種上下文設計「流程化」並定型的做法。

（3） 支架工程

即使把上下文整理得再好，僅靠自然語言指示也無法 100% 證明 LLM 遵守了所有限制。因此，進一步將 linter、腳本、CLI 指令等 機械式檢查機制（Harness） 納入本地開發循環，對 AI 輸出進行自動驗證。

這種方式不是在推送之後才執行類似 CI/CD 的檢查，而是 嵌入 AI 產生程式碼的過程中。這也是它的特色。它也可被稱為「一致性驅動開發」。

2.2 脈絡所告訴我們的事

這種進化不是「舊方法被淘汰」，而是 各階段作為下層能力疊加上去。即使實踐支架工程，內部仍然是在做上下文設計與提示設計。

新手法出現時，不必急著換掉一切；更重要的是先意識到自己現在處理的是哪一層。

3. 開發者角色的本質變化

3.1 從「寫程式碼的人」變成「設計指示書的人」

在某些現場，開發工時的大部分已經轉向製作與審查「超詳細設計（實作計畫書）」的模式。只要實作計畫書足夠精確，AI 產生程式碼本身的時間其實很短（當然仍取決於產生規模）。

這代表開發者價值的移動如下：

Before: 打字速度 × 邏輯構築能力
After : 業務理解深度 × 設計 AI 指示書的能力

3.2 Vibe Coding 單獨沒辦法做到的領域

「以氛圍（Vibe）和 AI 對話並寫程式」的 Vibe Coding，很適合作為入門，但無法涵蓋生產等級品質所需的以下要素。

• 測試觀點的完整性
• 程式碼品質與可讀性
• 符合團隊的程式撰寫規範
• 基於領域知識的合理性判斷

這些仍然是人類的責任。不是「把事情交給 AI」，而是「由人類設計出能交給 AI 的狀態」，這才是 AI 驅動開發中開發者真正的工作。

4. 文件與程式碼的一元化 ― SSOT 的重新定義

4.1 「規格書是不是已經不需要了？」這個問題

進入 AI 時代後，第一個會碰到的問題就是這個。

如果最新的原始碼就是答案，那另外保留規格書還有什麼意義？

當你正面面對這個問題時，就必須重新定義規格書的角色。

4.2 規格書不是「答案」，而是「目錄（索引）」

我們得到的結論如下。

規格書不是「答案本身」，而是用來探索複雜黑盒的索引。

對於方法數量很多的類別，讓 AI 從零開始解析原始碼，效率極低。若能保留一份以人類容易理解的自然語言撰寫、並且與程式碼一對一對應的規格書作為 Master，就能大幅提升 AI 找到變更點的準確度與速度。

4.3 DocComment 方法 ― 讓程式碼本身昇華為規格書

SDD 最大的弱點，就是規格書與原始碼容易脫節。因此，我們收斂到的做法不是把規格書放在獨立檔案中管理，而是 直接在原始碼的 method 上方撰寫詳細的自然語言規格（區塊註解）。

<span>/**
 * 【儀表板畫面】的銷售摘要。
 *
 * - 目標店鋪：由呼叫端指定的店鋪 ID
 * - 統計期間：當日 0:00 ～ 目前時間
 * - 排除退貨與作廢收據
 * - 共同語言：「銷售摘要」指的是含稅金額總和
 */</span>
<span>fun</span> <span>fetchSalesSummary</span><span>(</span><span>storeId</span><span>:</span> <span>String</span><span>):</span> <span>SalesSummary</span> <span>{</span> <span>..</span><span>.</span> <span>}</span>

這個做法有兩個很大的價值。

（1）作為協助 AI 理解上下文的中繼資料

若要讓 AI 一行一行解析複雜邏輯，會非常耗 token，也容易產生幻覺。若 method 上方有自然語言摘要，AI 就能立刻而準確地掌握「這個 method 在做什麼」。

（2）共同語言是 Agentic Search 最強的標籤

像 Claude 這類代理不會逐字讀完整個程式庫，而是先透過 Grep 或正規表示式搜尋（Agentic Search）來縮小範圍，再讀取必要程式碼。若在註解中徹底寫入專案特有的共同語言，AI 就能正確對應提示中的業務用語與註解中的詞彙，從龐大的程式碼庫中一口氣定位到要修改的地方。

4.4 實作計畫書不做版本管理

順帶一提，我們也曾討論「AI 生成的實作計畫書」該怎麼處理。若把它當成永久文件來管理，每次原始碼修改時，實作計畫書也得跟著更新，會產生雙重維護成本。

結論如下。

• 實作計畫書不納入版本管理
• 寫在 PR 訊息或議題留言中
• 未來若要調查，從 commit 歷史回溯到對應的 PR／議題

區分「應永久保存的文件」與「一次性意圖的紀錄」，是避開雙重管理地獄的關鍵。

5. 上下文的設計不是「加法」，而是「減法」

5.1 常見的失敗 ― 想要準備完美的規格書

剛開始導入 AI 驅動開發的人，常常會掉進這個陷阱。

要讓 AI 做出完美成果，就必須先準備完美的規則與規格書

這看起來很合理，但其實是最大的陷阱。因為準備完美上下文本身，反而會變成新的瓶頸。

5.2 以輸出為導向的方針

我們採用的方針如下。

先用最小必要上下文讓 AI 執行；只有在對輸出不滿意時，才補強不足資訊，將其整理成「規則」或「Master 文件」。

透過這種「減法」式做法，可以把上下文工程的工時壓到最低。而且補強後的規則是根據真實失敗經驗得來的，因此一定能直接轉化為實益。

5.3 上下文最小化原則

在實務上，以下這些最小化規則很有效。

• 不要讓聊天紀錄太長 —— 準確度會下降
• 檔案太肥大時，先切分再提供
• 一次只聚焦一個任務來下指令 —— 考量 token 限制，將任務細分
• 「不提供多餘資訊」跟「提供必要資訊」一樣重要

5.4 從模板開始，還是從零開始

在實戰現場，這兩種方法其實是並存的。

方法特點適合情境模板式（SDD／活用 OSS 技能）導入既有模板，重視流程可重現性團隊熟悉度不一，需要標準化的情境從零開始每次都從個別程式碼或設計文件建立上下文熟練者處理複雜程式碼的情境沒有哪一種才是絕對正解，現實上更可行的是 依專案熟悉度與目標複雜性來切換使用。兩者並不是對立，而是通往同一個目標——「最大化輸出」——的不同路徑。

6. AI 輸出的品質保證 ― 如何處理自然語言無法擔保的領域

6.1 自然語言制約的限制

即使在規則裡寫了「請不要用這種寫法」，LLM 也不保證 100% 會遵守。這是機率式生成模型的宿命。

因此，前面提到的支架工程，就是以非自然語言的機械式機制來加以擔保的思路。

6.2 具體實踐 ― Skill 形式的檢查機制

例如，若要把自我審查的檢查清單（是否有未推送的差異、是否確認 DB 錯誤日誌等 20～30 項）交給 AI 處理，會遇到以下問題。

• 檢查項目遺漏（本來應有 30 項，卻只做了 10 項）
• 「雖然能指出 NG 的理由，但很難證明所有 OK 項目都已完整檢查」
• 受 token 限制，無法一次執行完

若只靠 AI 的靜態分析來解決，最後通常會失敗。因此要這樣切分：

手段可擔保的內容CLI 指令（如 grep）可明確證明的事實Python 腳本涉及複雜邏輯的檢查AI 判斷依賴上下文的綜合判斷接著把它們各自拆分並註冊成 Cursor 的 Skill，讓它們依序執行。讓 AI 專注於「判斷」部分，把「驗證」交給機械式機制。

6.3 說到底，這其實就是「測試先行」的思想

仔細想想，這個發想並不新鮮。

「把人類用自然語言寫下的需求，轉化成可以機械驗證的形式」

這和 TDD（測試驅動開發）或契約式程式設計是同樣的思想。只是對象從程式行為變成了 AI 輸出，品質保證的本質並沒有改變。可以說，支架工程是把這種古典思想套用到 AI 時代後自然浮現出的結果。

7. 不可迴避的課題：重新發明審查

7.1 實作速度提升後發生了什麼

當 AI 驅動開發讓實作速度大幅提升後，審查立刻變成瓶頸。因為實作太快，對資深工程師的審查需求也會瞬間暴增。

這可以說是所有投入 AI 驅動開發的組織都會面臨的課題。

7.2 現場討論的三種方案

（1）重新定義審查角色

「是否按照實作計畫書實作」交給自我審查負責，而審查者只確認「計畫書是否合理」。透過把審查粒度提高到更抽象的層次，來降低審查者負擔。

（2）刻意降低程式碼生成速度

對於處理複雜規格的團隊，短期內決定先將 AI 的使用限制在「設計／調查階段」，程式碼生成則維持既有速度。這是一種很合理的判斷：如果只有程式碼生成變快，審查跟不上，現場就會崩潰。

這裡有一個非常重要的啟示：不是「凡事都用 AI 加速」就好，而是要 從組織整體吞吐量來思考，把 AI 投入最適合的地方。

（3）將審查的默會知識技能化

透過 GitLab CLI 等工具，讓 AI 分析過去的 MR／PR 資料與審查留言，將資深工程師的指摘傾向與觀點形式知識化。若成功，這些就能成為組織資產中的「審查觀點 Skill」。

7.3 V 字型模型整體的平衡設計

歸根究柢，AI 驅動開發不是只加速 V 字模型中的某一道工序，而是需要 重新調整整個流程的平衡。就算只加速實作，如果設計與審查跟不上，也沒有意義。

8. 比手法更重要的「敏捷心態」

8.1 為什麼手冊推動也沒用

當組織想推動 AI 驅動開發時，通常都會碰上這道牆。

明明照手冊做了，卻還是沒有出現預期的輸出

很多人會在這裡直接停住，最後對 AI 產生「根本不好用」的負面印象而離開。

8.2 為什麼只有手冊不夠

原因很簡單。AI 進化得太快了。

• 模型每隔幾個月就會大幅更新
• 工具持續加入新功能
• 今天最好的做法，下個月不一定還是最好
• 甚至連「撰寫詳細實作計畫書」這種目前的最佳實務，也可能因模型進化而變得不再必要

8.3 所需要的素質是「持續改善」的姿態

在 AI 驅動開發中，對人類最重要的要求如下。

「不要固守特定作法，而是能依照情境質疑開發流程本身，並持續改善的敏捷心態。」

當 AI 沒有產出理想結果時，不要立刻放棄，而是持續追問以下問題，這就是 AI 時代開發者所需要的「業務設計能力」。

• 為什麼（Why）失敗了？
• 缺少了什麼樣的上下文（What）？
• 問題出在流程的哪一段？

8.4 兩階段的導入方式

在組織層級，我們發現以下這種兩階段導入方式很有效。

• 第 1 階段（提供模板） —— 先照手冊實作
• 第 2 階段（突破模板） —— 在反覆循環中，回顧哪些地方總是不順，並由團隊找出專屬的最佳工作流程

不是一開始就要求自我改善，而是先透過模板建立感覺，再引導團隊逐步突破模板。

9. 結論 ― 所有手法都會收斂到同一點

9.1 把流行手法放在一起看

再次列出一開始提到的手法。

• 提示工程
• 上下文工程
• 規格驅動開發（SDD）
• 代理式工作流程
• 支架工程
• Vibe Coding

實際去做之後就會發現，雖然說法不同，但最終追求的狀態其實相同。

9.2 收斂的本質 ― 三個原則

無論透過哪一種手法，最後都會走到以下三個原則。

原則 1：重新設計以 AI 為主體的開發流程

AI 不是輔助工具，而是開發主體。開發者的角色，從「寫程式碼」轉變為「設計給 AI 的指示書，並驗證其輸出」。設計逐步轉向對 AI 友善的 Markdown，而原始碼本身則透過 DocComment 昇華為 SSOT。

原則 2：以輸出為導向，管理最小必要上下文

不追求完美的事前準備，而是以最小上下文先執行，再根據失敗補強，採取「減法」作法作為基礎。區分需要永久保存的內容與一次性的內容，排除雙重管理。

原則 3：以可持續改善流程本身的敏捷心態面對變化

不要固守特定手法，而是隨著 AI 與工具進化，不斷質疑流程本身。不要把失敗歸咎於「AI 很爛」，而是視為「我們的設計還有改善空間」，並透過上下文工程持續優化。

9.3 對於在選手法上猶豫的人

如果你正在煩惱「應該從哪種手法開始」，答案其實很簡單。

從哪一種開始都可以。

重點是，把你選的手法深入實踐，最後抵達前面提到的三個原則。不管是從 SDD 開始、從上下文工程開始，還是從支架工程開始，只要認真做下去，最後一定會得出相同結論。

手法只是入口。入口不同，但會到達的地方相同。

9.4 最後 ― 重點不是「用什麼」，而是「如何面對」

AI 驅動開發的本質，不在於工具或手法的選擇，而在於 對待開發這件事本身的態度轉變。

• 有勇氣信任 AI，並把它當作主體來看待
• 有知識上的誠實，能把自己的工作內容語言化、並設計成流程
• 不把失敗怪罪給 AI，而是當成自身仍可改善的空間

具備這些特質的組織或個人，不論使用哪種工具、選擇哪種手法，都一定能做出成果。反過來說，如果缺少這些，即使導入最新工具，也只是暴殄天物。

手法會分歧，但本質會收斂到同一點。

希望你能帶著這個觀點，選擇最適合自己團隊的入口，並深入實踐。

結語

本文是根據 6 週的每週討論內容，重新以主題軸整理而成。由於刻意不深入談各種現場細節與工具名稱，因此更聚焦於可普遍適用的思考方式。

相信你們團隊內部也一定曾有類似的討論。如果你認同本文的結論，也歡迎在留言中分享你們實際採用的做法，或是走到不同結論的過程。

AI 驅動開發仍是一個剛起步的領域。希望大家都能不失本質地，持續一起試錯前進。

原文出處：https://qiita.com/ko1-ino/items/ccc64ce6504c77100cfb