大家好，我是TIMEWELL的濱本。這是「AI原生新事業開發方法論」的第3篇。我在大型企業做了十年以上的新事業，曾擔任有超過一百家大型企業參與的挑戰者支援計畫「CHANGE by ONE JAPAN」的營運負責人，現在營運面向創業者與企業內創業者的AI驅動開發計畫「WARP ENTRE」。這篇文章，是把我在2026年3月以「AI規格驅動開發（AI-SDD）」為題寫的文章，依半年後的情況全面改寫的版本。
系列「AI原生新事業開發方法論」 ①在顧客訪談中當場做出示意畫面的技術 ②一天內跑完精實畫布、7 Powers與設計概念 ③規格驅動開發（SDD）重回焦點，文件正在變成程式碼（本文） ④用AGENTS.md、Skills、Hooks與cron養出組織的脈絡
有沒有直接對程式代理丟過一句「幫我做個電商網站」？我有。幾分鐘後出來一個像樣的東西，很感動，三天後崩了。代理用想像填補細節，那些想像和我的意圖有落差，落差就這樣層層堆上去。就像沒有設計圖就開始蓋房子。2025年，全世界大量的人經歷了這件事，作為反動，2026年「寫程式之前先把文件定下來」這個老做法，換了新名字回來了。規格驅動開發，SDD。
這篇文章寫給新事業開發部門的人，包括自己不寫程式的人。理由很簡單：SDD核心的「寫文件」這個步驟，不是工程師的工作，而是決定事業的人的工作。
摘要：2025年9月GitHub推出Spec Kit、AWS推出Kiro，以規格為「正本」讓代理實作的SDD成了主要工具的標準。Andrej Karpathy在2023年寫下「最新的程式語言是英文」，2025年提出「Vibe Coding」並支持「脈絡工程」，2026年提出「agentic engineering」，3月的autoresearch展示「程式碼由代理編輯、Markdown由人編輯」的架構。需求文件、規格書、基本設計書、細部設計書四份文件只是抽象程度不同，都能用「寫、嚴格審查、修」寫出來。此外，進度紀錄與代理的記憶也成了需要版本控制與審查的對象，也就是接近程式碼的存在。
從當時（2026年3月）到現在（2026年9月），改變了什麼
寫初版的2026年3月，我把SDD形容為「作為Vibe Coding的反動而開始擴散的概念」。半年後，情況從「開始擴散」變成了「成為標準」。
整理時間軸。2025年9月2日，GitHub公開開源的「Spec Kit」。公開時的文章這樣診斷失敗的原因：我們把程式代理當成搜尋引擎在用，其實應該把它當成「只會照字面理解的結對程式設計師」；它擅長模式辨識，但需要毫無歧義的指示。所以要重新看待規格，不是靜態文件，而是隨專案演進的「活的、可執行的產物」。規格成為共享的唯一事實來源1。截至2026年9月12日，Spec Kit的儲存庫已累積超過13萬5,000顆星2。
差不多同時，AWS推出了Kiro。Kiro的規格由三個檔案組成：requirements.md（使用者故事與驗收條件）、design.md（技術架構與圖）、tasks.md（拆成可追蹤的工作單位）3。Thoughtworks在2025年11月的Technology Radar把SDD放在「Assess（值得評估）」。比較了Kiro、Spec Kit，以及把規格本身當作維護對象的Tessl之後，他們也寫道：工作流程過於繁複且主觀，長篇規格檔難以審查，而且「為AI手工打造詳細規則終究無法擴展」這個苦澀的教訓，我們可能正在重新學一次4。
這個保留是正當的。我也認為，把SDD讀成「文件寫厚就能解決」是錯的。不過在2026年9月的此刻，主要的程式代理幾乎都以某種形式內建了「先寫規格」的階段。要寫多厚的討論仍在繼續，但「不寫」這個選項，已經從實務中消失了。
Karpathy的三年：從「英文」到「agentic engineering」
要理解SDD為什麼復興，最快的路徑是依時序追Andrej Karpathy的發言。他是OpenAI的創始成員、曾在Tesla領導自動駕駛AI，這幾年則持續創造「如何與AI一起工作」的語彙。
2023年1月，他在X上寫下：「最熱門的新程式語言是英文」5。當時聽起來像挑釁，現在讀來是預言。2025年2月，他創造了「Vibe Coding」一詞：把自己交給感覺，忘記程式碼的存在，讓LLM去寫。言下之意是，對好玩的拋棄式專案最棒，但也僅止於此6。2025年6月，Shopify的Tobi Lütke寫道「脈絡工程（context engineering）這個詞比提示工程更能表達核心技能：為了讓LLM有可能解決任務而提供所有脈絡的技術」，Karpathy回應「+1」並接著說：人們把提示詞想成短短的任務描述，但在每一個工業級的LLM應用裡，脈絡工程是「為了下一步，用恰到好處的資訊填滿脈絡視窗的精細藝術與科學」。太少、形式不對，就沒有性能；太多、不相關，成本上升而性能下降7。
然後是2026年2月。在Vibe Coding一週年時，他寫了回顧。當時LLM能力還低，所以Vibe Coding是給好玩的拋棄式專案用的。一年後的現在，經由LLM代理寫程式正成為專業人士的預設工作方式，只是伴隨更多的監督與審視。目標是取得代理帶來的槓桿，同時對軟體品質不做任何妥協。為此他提出的詞是「agentic engineering」。「agentic」，因為新的預設是99%的時間不自己寫程式碼，而是指揮代理去寫、自己擔任監督者；「engineering」，為了強調其中有藝術、科學與專業，是可以學習並精進的東西8。
把這一連串的話排起來，SDD的位置就清楚了。英文成了程式語言，經過憑感覺寫的時代，設計脈絡的技術受到考驗，現在「監督」的工作方式有了名字。要監督，就得事先決定要做什麼。寫下「決定的事」的文件，就是規格。SDD，正是agentic engineering的內容本身。
四份文件，只是抽象程度不同
那要寫什麼？我在計畫裡教的範本是四份文件：需求文件、規格書、基本設計書、細部設計書。這四份，只是內容的抽象程度不同。左邊是經營者也讀得懂的層次，右邊是AI可以直接實作的層次。用餐廳比喻：需求文件是「企畫書」，規格書是「菜單與服務手冊」，基本設計書是「樓層平面圖與動線設計」，細部設計書是「廚房的食譜」。
| 文件 | 問題 | 誰讀得懂 | 寫的內容 |
|---|---|---|---|
| 需求文件 | 為什麼、做什麼 | 經營者、家人 | 背景與目的、目標對象、要解決的課題、要實現的功能、不做的事、成功基準 |
| 規格書 | 從使用者看來怎麼運作 | 事業負責人、業務 | 畫面清單、各畫面的項目、輸入檢查、操作時的行為、錯誤時的行為、畫面轉換 |
| 基本設計書 | 從外面看怎麼做 | 建造者 | 整體結構、畫面設計、資料設計、外部服務串接、環境的區分 |
| 細部設計書 | 裡面怎麼做 | AI、工程師 | 資料庫細節、處理流程、驗證邏輯、錯誤處理、環境變數清單、資安考量 |
同樣是「餐廳的預約表單」，每份文件寫的東西完全不同。需求文件寫「為了減少電話漏接，每月有20件預約從表單進來就算成功」。規格書寫「姓名、電話、日期時間、人數的輸入欄，以及送出後的確認信」。基本設計書寫「輸入、確認、完成三個畫面，以及預約資料的儲存位置」。細部設計書寫「reservations資料表的欄位名稱與型別、電話號碼的驗證規則」。
對新事業開發部門的人來說，最重要的是前兩份。需求文件與規格書，不會出現程式碼或技術用語。而這兩份還模糊時就去寫後兩份，只會在漂亮的設計圖上蓋出沒人用的東西。需求文件裡特別重要的是「不做的事」。決定不做什麼，和決定做什麼同樣重要。沒寫不做的事，代理會出於好意全部做掉。
寫法，四份文件都是同一套三步驟：寫、嚴格審查、修。中間那一步不要跳過，精度就在那裡決定。需求文件的提示詞範本如下。
你是支援新事業產品設計的專家。接下來要製作需求文件。
不要馬上寫，請先問我問題。
# 事業前提
【精實畫布要點、顧客訪談中得知的課題（附引用）】
# 規則
- 問題最多7個。一定要包含「誰」「困擾什麼」「做到什麼算成功」「不做的事」
- 我的回答模糊時，提出3個選項讓我選
- 不用技術用語。寫到家人讀得懂的層次
- 完成後寫成 requirements.md。項目為「背景與目的」「目標對象」「要解決的課題」「要實現的功能」「不做的事」「成功基準」六項
寫出來之後，用下面的指示讓它嚴格審查：「請以嚴苛的產品經理身分審查這份需求文件。分別指出模糊的用語、無法衡量的成功基準、互相矛盾的需求，以及該寫在不做的事裡卻沒寫的項目。不需要稱讚。」反映指摘，完成。規格書、基本設計書、細部設計書也用同樣的三步驟進行。只有一件事必須嚴守：細部設計書只寫環境變數的「名稱與用途」，絕對不寫實際的API金鑰或密碼的值。因為文件有可能存到GitHub上。
開發文件、進度文件、記憶文件也是程式碼
接下來是初版沒有的內容。SDD的討論容易集中在「規格」，但實際和代理一起工作就會發現，規格以外的文件同樣有效。我分成三種。
第一是開發文件。程式碼規範、目錄的約定、測試的跑法、部署的步驟。這是代理每次都會讀的「專案使用手冊」，以AGENTS.md或CLAUDE.md之類的名字放置。OpenAI的Codex、Google的Jules、Cursor等許多代理都會讀的AGENTS.md，標榜「給代理的README」，截至2026年9月已有超過6萬個開源專案採用9。
第二是進度文件。什麼做完了、什麼還沒、決定了什麼、延後了什麼。Kiro的tasks.md和Spec Kit的任務拆解就屬於此。代理跨工作階段沒有前一次的記憶；進度不在文件裡，隔天的代理就會把昨天的討論重做一遍。
第三是記憶文件。代理自己寫的「學到的事」的紀錄，像Claude Code的自動記憶這類機制。Anthropic在2025年9月關於脈絡工程的技術文章中，把脈絡稱為「重要但有限的資源」，並舉出在長任務中以「結構化的筆記」把資訊存到脈絡之外的手法10。
為什麼說這些「是程式碼」？Karpathy在2026年的兩項工作，最清楚地說明了這一點。3月公開的autoresearch，是讓AI代理整夜自動做語言模型訓練實驗的儲存庫。README這樣寫：身為研究者平常會動的Python檔案，不去碰；取而代之的是「編程」給代理提供脈絡的program.md這個Markdown。train.py由代理編輯，program.md由人編輯。program.md本質上是一個極輕量的「skill」11。人直接編輯的對象，從程式碼移到了Markdown。
4月公開的「LLM Wiki」更進一步。不像RAG每次從原始文件檢索，而是讓LLM把讀到的資訊納入，持續維護相互連結的Markdown wiki。他把這個架構形容為「Obsidian是編輯器，LLM是程式設計師，wiki是程式庫」。定義wiki結構與作法的CLAUDE.md或AGENTS.md，他稱為「關鍵的設定檔」，並建議定期做「Lint」：檢查wiki的矛盾、過時的主張、孤立的頁面12。Lint原本是程式碼靜態檢查的用語。對文件跑Lint，這就是「文件是程式碼」的具體意義。
過去對程式碼的要求，現在也對文件要求。做版本控制。審查差異。從規格產生測試來驗證。過時就刪。檢查矛盾。實務上收斂為以下四點。
| 在程式碼 | 在文件 |
|---|---|
| 用git做版本控制，審查差異 | 規格書、AGENTS.md、進度也放進git，變更透過PR審查 |
| 用測試驗證正確性 | 從規格的驗收條件產生測試，偵測規格與程式碼的落差 |
| 刪除不用的程式碼 | 定期刪除進度文件的「已完成」與記憶中過時的學習 |
| 用Lint偵測規範違反 | 讓代理檢查文件之間的矛盾、過時敘述、孤立項目 |
用新事業開發的角度再說一次。過去你交給外部廠商或工程師的「委託書」，散落在負責人的腦袋和會議記錄裡。現在，它被寫成需求文件與規格書，直接交給代理，成為實作的依據。寫不出來，就做不出來；寫出來，當天就有會動的東西。寫文件的能力，直接連結到做事業的能力。
「厚文件」的陷阱，以及大型企業常見的誤解
讀到這裡，或許有人想「那全部寫厚一點就好」。不是的。再引一次Thoughtworks的保留：長篇規格檔難以審查，為AI手工打造詳細規則無法擴展4。Karpathy關於脈絡工程的貼文也明說，太多、不相關，性能就下降7。文件的價值，不在厚度，而在抽象程度的階梯是否正確建立。
大型企業常見的誤解有兩個。一個是想用既有資訊系統部門那種數百頁的格式來寫「需求文件」。交給代理的需求文件，是家人讀得懂的六個項目。格式的厚度，反映的不是精度，而是簽核流程的厚度。另一個是把文件當成「寫過一次就結束」。和程式碼一樣，文件在每次變更時都要更新。只改程式碼、放著規格不管，下次代理讀到舊規格，就會做出倒退的修改。規格要持續是唯一事實來源，最低條件是變更從規格開始。
另外，寫下一個事業開發部門特有的好處。四份文件的前兩份，可以直接當作公司內部共識的工具。在經營會議上拿出需求文件的「不做的事」與「成功基準」，討論就會從「有沒有趣」變成「這個成功基準對不對」。把規格書的畫面清單給業務看，會得到「這個畫面我能跟客戶說明」「這個欄位現場填不出來」這種具體的反應。文件既是給代理的指示，也是給人的說明。
在WARP裡，我們用參與者自己的主題寫這四份文件，讓代理實作，做到能動的東西為止。方法論的續篇，在第4篇用AGENTS.md、Skills、Hooks與cron養出組織的脈絡，把文件從「個人的作法」擴大為「組織的運作」。計畫的結構請見WARP頁面。
結語
SDD不是新技術。寫程式之前先決定要做什麼，這個理所當然的作法，只是在代理的時代變成了必須。需求文件、規格書、基本設計書、細部設計書四份文件只是抽象程度不同，用「寫、嚴格審查、修」三步驟就能寫出來。而規格之外，開發文件、進度文件、記憶文件也成了需要版本控制、審查、檢查的對象，也就是接近程式碼的存在。借Karpathy的話，人編輯的是program.md，wiki是程式庫。
明天就要動手的話，用現在進行中的新事業主題，只寫需求文件的六個項目試試看。特別是「不做的事」和「成功基準」。寫不出來的項目，就是第1篇說的該去訪談的地方。想以自家主題寫四份文件、並和我們一起做到讓代理實作為止的話，歡迎透過個別諮詢聊聊。
Footnotes
-
Spec-driven development with AI: Get started with a new open source toolkit（GitHub Blog，Den Delimarsky，2025年9月2日） ↩
-
Specs — Kiro Documentation（requirements.md / design.md / tasks.md 三檔案結構） ↩
-
Spec-driven development — Technology Radar（Thoughtworks，2025年11月5日，Assess） ↩ ↩2
-
Andrej Karpathy（X，2023年1月24日）「The hottest new programming language is English」 ↩
-
Andrej Karpathy（X，2025年2月2日）「There's a new kind of coding I call "vibe coding"…」 ↩
-
Andrej Karpathy（X，2025年6月25日）「+1 for "context engineering" over "prompt engineering"…」（回應tobi lutke 6月19日的貼文） ↩ ↩2
-
Andrej Karpathy（X，2026年2月4日）Vibe Coding一週年回顧與「agentic engineering」 ↩
-
AGENTS.md — A simple, open format for guiding coding agents（「used by over 60k open-source projects」，2026年9月12日取得） ↩
-
Effective context engineering for AI agents（Anthropic Engineering，2025年9月29日） ↩
-
karpathy/autoresearch README（GitHub，2026年3月。「you are programming the program.md Markdown files」「train.py — edited by the agent / program.md — edited by the human」） ↩
-
LLM Wiki — A pattern for building personal knowledge bases using LLMs（Andrej Karpathy，GitHub Gist，2026年4月4日） ↩
