規格驅動開發：什麼才是事實來源？

重點整理

先寫 PRD 再叫 AI 開發，這樣算 SDD 嗎？討論串的核心其實是：規格和程式碼，哪一個才是事實來源。

如果程式碼就是事實來源，為什麼還需要另一份規格？

・主張 A — 規格是事實來源（意圖寫在文件裡）
・主張 B — 程式碼是事實來源（實際跑的才算數）
・衝突點 — 兩者不一致時聽誰的
折衷. Living Documentation（讓兩者保持同步）

01｜source code本來就是事實

程式碼是為了解決某些問題而存在的，它就是最直接的事實來源。

・只要 GenAI 還不能只靠 prompt 就百分之百穩定地解決指定問題，寫程式就有它的價值
・理想的規格應該是同樣的輸入產生同樣的輸出，而不是靠使用者自己在規格裡補 context

類比：工程師什麼時候需要寫低階語言？永遠是不夠用、想客製時。

02｜真相常常不在程式碼裡

公司裡更常見的問題是，事實在 PM 的腦子裡，或在某位資深系統分析師的腦子裡。

・程式碼本身已經走歪，legacy code 無法反映業務意圖
・所以軟體工程界才提出 Living Documentation

程式碼有價值是對的，但它不一定還記得為什麼要這樣做。

03｜大家缺的不是觀念，是手段

多數團隊沒有能力維持規格與程式碼的一致性，也缺乏建構 Living Documentation 的方法。

・結果就是維度不夠高，只能一直讓 AI 追問、然後寫程式
・這已經是普遍常態

方法論輸給的不是另一套方法論，是「維持它的成本」。

04｜PRD 與 SDD可以相輔相成

寫 SDD 不代表不用寫 PRD。

・PRD 提供足夠的細節脈絡與架構面定義
・規格再據此展開，開發速度與品質一起往上

本質上是「需求 → 規格 → 程式碼」的一條線。

05｜「寫文件的時間，工程師早就寫完了」

・直接給 AI 程式碼是什麼意思？走 SDD 的人難道不也會給 AI 程式碼嗎？
・寫文件難道不也是 AI 透過需求訪談後幫忙寫嗎？
・「上限天花板」的理論基礎是什麼？
・你讓 AI 產程式碼的過程中，真的不需要先做系統分析嗎？

反方立場成立與否，取決於系統分析這一步有沒有被跳過。

行動清單

方法叫什麼不重要，能不能回答這五題才重要。