放棄規格驅動開發的影片爆紅：開發者共鳴的，是注意力被喫掉這件事

10 月 21 日，V2EX 出現一篇貼文，討論 TypeScript 圈知名教育者 Matt Pocock 的一支訪談影片，標題大意是「規格驅動開發試了幾個月，為什麼放棄了」。貼文本身很口語，作者甚至不確定影片會紅是因為大家對 Pocock 這個人感興趣，還是因為對 spec 驅動開發累積了不滿。一天左右，這篇討論累積了上千次瀏覽。

先把名詞說清楚。規格驅動開發（spec-driven development）是這一年隨 AI 編程工具流行起來的工作方式：先不寫程式，而是寫一份詳細的規格文件，讓 AI 代理依照規格逐步實作。概念上有點像裝修房子前先畫好完整施工圖，理論上照圖施工就不會走樣。Matt Pocock 是 TypeScript 教學品牌 Total TypeScript 的創辦人，在開發者社羣有長期累積的信任，他公開說「試了幾個月，放棄了」，自然有傳播力。

V2EX 討論串裡的幾則回覆，比影片本身更值得看。一位使用者點出核心：「spec 開發耗費大量注意力，人最寶貴的就是注意力，能許願式開發的就直接許願。」這句話把兩種工作模式的成本結構講得很白。寫規格是把思考前置，你要在還沒看到任何成果之前，就把所有細節想清楚；而所謂許願式開發，是直接下一句 prompt 讓 AI 動手，錯了再改。前者把成本壓在「想」，後者把成本壓在「改」。當 AI 改程式的速度越來越快，重試的成本下降，「先把規格寫到完美」這件事的投資報酬就跟著改變。

另一位回覆則點了另一個痛處：現在的模型寫出來的規格，人很難看懂。這其實是規格驅動開發最尷尬的地方。它的前提是規格文件成為人與 AI 之間的合約，但合約要成立，雙方都得讀得懂。如果模型生成的 spec 本身就需要花力氣解讀，那規格文件就從「省溝通」變成「多一層翻譯」，反而增加來回。

有趣的是，討論串裡也有人貼出 Pocock 的 GitHub 專案「skills」，串內另一位使用者回了「好用」。也就是說，同一個人、同一個主題，放棄的是一套工作法，留下的卻是另一種形式的工具。這與我們先前整理過的AI 代理跑太慢通常卡在測試排隊的觀察一致：AI 輔助開發的瓶頸，往往不在模型本身的聰明程度，而在工作流程的設計是否配合得上。

對一般開發者來說，這場討論可以收斂成一個實際的判斷題：你的專案變更成本高不高。如果是一次性的小工具、原型、能在幾分鐘內重跑的東西，直接許願式開發的確比較省。如果是多人協作、介面要長期穩定的系統，某種形式的規格仍然躲不掉，只是那份規格不必長成 AI 時代新名詞的樣子，它可能就是你本來就在寫的設計文件與介面定義。

工具會繼續換名字，Pocock 幾個月前的結論也可能隨模型進步而改變。但注意力是有限資源這件事不會變，這也是這支影片能打到人的真正原因。