規格極大化：克服 AI 精神官能症，以及為什麼我用 YAML 撰寫規格書

背景

在 AI 輔助開發（AI Coding）日益普及的當下，開發者常面臨 AI 產出「廢話」（Slop）或無法精準執行複雜邏輯的問題。Acai.sh 的作者提出了一種名為「Specsmaxxing」的開發哲學，主張將軟體規格（Specifications）以結構化的 YAML 格式明確記錄下來。他認為，規格始終存在於開發者的腦海或對話中，與其讓它模糊不清，不如將其轉化為 AI 可理解的驗收標準（Acceptance Criteria），藉此克服 AI 開發中的混亂與不確定性。

社群觀點

針對這種「規格至上」的開發方式，Hacker News 社群展開了熱烈討論。許多支持者認為，明確的需求定義是與 LLM 協作的基石。有留言指出，將規格從程式碼中抽離出來具有長遠價值，因為程式碼往往會隨時間演進而變得難以理解，而一份與程式碼同步更新的規格書，能讓 AI 在未來的開發任務中，清楚辨識哪些是刻意為之的設計，哪些僅是實作過程中的偶然。這種做法不僅能幫助 AI 在有限的上下文視窗內處理複雜系統，也能作為文件撰寫與技術支援的可靠依據。

然而，反對與質疑的聲音也相當尖銳。部分開發者認為，當規格書寫得過於詳盡與結構化時，撰寫規格的成本將會超過直接寫程式碼的效益。有人諷刺地表示，在 YAML 裡編寫邏輯就像是在進行另一種形式的程式設計，甚至可能演變成像 Helm Chart 那樣充斥著模板語法的混亂局面。批評者指出，這種做法本質上是在試圖用自然語言或結構化資料來取代程式語言，但程式碼本身其實就是最精確的規格說明。如果規格變得過於複雜，開發者最終會發現，親自動手寫程式碼反而比調教 AI 去理解複雜規格要快得多。

此外，關於規格的載體也引發了技術性的爭論。有觀點認為，與其發明新的 YAML 格式，不如回歸傳統的 Jira 票券或使用「文學編程」（Literate Programming）的理念。更有開發者質疑，這類工具多半帶有作者個人的主觀偏好，缺乏嚴謹的對照實驗來證明其優於傳統的 Markdown 或純文字描述。討論中也觸及了語言的本質：雖然有人主張 UML 等圖形化語言有其必要，但反駁者認為自然語言才是最具通用性的系統，足以描述任何複雜邏輯，關鍵在於如何減少歧義。

最後，社群達成了一個有趣的共識：無論是否使用 AI，缺乏計畫的開發最終都會導致「程式碼即規格」的窘境，這使得後續的維護與重構變得異常困難。雖然 Specsmaxxing 的具體實作方式仍有爭議，但它確實反映了開發者在 AI 時代對於「意圖傳達」與「精確控制」的集體焦慮。

延伸閱讀

在討論過程中，社群成員分享了多個與規格驅動開發相關的工具與資源。除了作者提到的 Acai.sh 外，還有專注於規格管理的 OpenSpec，以及強調在程式碼中標註規格引用的 lat.md。此外，Vercel 團隊發表的 Agents.md 研究也受到關注，該研究探討了 Markdown 格式在提升 AI 代理效能上的表現。對於偏好圖形化表達的開發者，Mermaid 則是被公認為 LLM 能夠良好處理的圖表標記語言。