本篇文章更新時間：2026/03/20
如有資訊過時或語誤之處，歡迎使用 Contact 功能通知或向一介資男的 LINE 社群反應。
如果本站內容對你有幫助，歡迎贊助支持 。
內容目錄
規格越寫越像程式，那為什麼不直接寫程式？
副標題：讀 Gabriella Gonzalez〈A sufficiently detailed spec is code〉的幾點深度思考
編輯前言：這篇文章來自 Gabriella Gonzalez 的原文 A sufficiently detailed spec is code，她用 OpenAI Symphony 的案例，犀利拆解「從規格自動產生程式碼」的迷思。對所有在 AI 時代討論工程流程的人，都非常值得一讀。
核心觀點 (Key Takeaways)
- 真正能產生可用程式碼的規格文件，必然精確到幾乎就是程式碼。
- 規格不會比寫程式簡單，還可能更難；若優先追求開發速度，規格必然變成語焉不詳的雜湊文字。
- 即使規格寫得極度詳細，AI 仍難以穩定地從「純規格」生成完整可執行的系統。
深入解析
作者從 OpenAI 的 Symphony 開刀，指出官方宣稱該專案「來自規格文件」（SPEC.md），但實際打開文件後，內容完全不像傳統理解的「規格」：
- 大量資料庫 schema 逐欄列出，幾乎是直接貼 code
- 各種流程描述其實就是以自然語言包裝的 pseudocode
- 甚至有「目前程式碼就長這樣」的逐行參考實作
- 一些段落只是為了「避免模型寫錯程式」而加入的提示
「你不能宣稱規格文件可以取代程式碼，如果你的規格文件看起來就像程式碼。」
作者藉此拆解第一個迷思：
1. 規格文件並不比程式碼簡單
如果你真的要讓 AI 從規格自動產生正確的系統，那份規格就必須精確到能涵蓋所有邏輯細節。這種文件為了避免歧義，必須變得越來越形式化，最後寫出來就像程式碼本身。
這正如 Dijkstra 所說：當你試圖用自然語言達到程式語言的精確度時，不但寫起來更辛苦，還充滿模糊與反覆溝通的成本。
2. 規格即便寫得再細，AI 依然無法穩定生成正確程式碼
作者實際找 Claude Code 依照 SPEC.md 產生 Haskell 版本的 Symphony，結果：
- 多個 bug
- 即使修完錯誤也無法正常執行
- agent 在簡單任務上原地轉圈
這呼應她引用的一個例子：
即使像 YAML 這麼成熟、詳細、普及的規格，仍沒有實作能百分之百符合標準。
換句話說，越想補強規格的空洞與模糊，規格就越膨脹，直到變成 Borges 筆下「和領土等大」的地圖，無法再被真正使用。
3. 規格本應該比 coding 更需要深度思考，但今日的工程文化不允許
理論上：
規格的目的，是讓工程師在寫程式前先把邏輯想透。
但現實中：
業界追求「快」，於是規格文件變成形式化產物，甚至被 AI 自動生成，內容看似像規格，但其實缺乏上下文、邏輯與工程判斷。作者形容 Symphony 裡某段（10.5）就是典型 AI 生成的「specification-shaped slop」。
筆者心得與啟發
看完這篇，我最深的感觸是：
所謂「用規格生成程式」的願景，真正困難的不是模型，而是人是否真的願意寫得夠精確。
但只要你願意寫到能讓模型轉成可執行程式，那份文件就必然和程式一樣複雜、同樣需維護、同樣會出 bug。這也讓我重新反思：
- 規格是「思考的過程」，不是「加速開發的捷徑」。
- 如果工程目標是快速迭代，那麼維護兩份等價文件（規格與程式）根本不划算。
- 反而，當 AI 讓程式碼生成成本變低，我們更應該直接在程式層進行思考，而不是企圖把「清晰度」外包給自然語言規格。
換句話說，如果你希望 AI 幫你寫出高品質系統，最重要的不是交給它「更厚的規格」，而是要先確保自己真正想清楚了。
這篇文章對當前 AI 工具泛濫、規格被濫用、工程文化重速度輕思考的現象，是一記非常誠實的提醒。