「程式碼應重新生成，而非維護」：Codeplain 倡導以規格驅動開發
檢查您的郵箱以確認一封驗證信件，您可以在此調整偏好設定，甚至加入更多群組。
追蹤 TNS 在您喜愛的社群媒體網路上的官方帳號。
「程式碼應重新生成，而非維護」：Codeplain 倡導以規格驅動開發
人工智慧生成的程式碼速度超過團隊的審查能力。多數開發者認為答案並非更快的程式碼審查，而是將其替換為另一種完全不同的方式。
Dušan Omerčević 是 Codeplain 的執行長兼共同創辦人，這是一家致力於以 規格驅動開發 作為 AI 時代軟體建置與維護基礎的公司。該公司成立於 2025 年初的斯洛維尼亞首都盧比安納，Codeplain 在同年 9 月悄然推出其服務，承諾提供「規格驅動、可用的程式碼生成」。
此概念的基礎是 Plain，一種開放原始碼的規格語言。它以結構化、易於理解的文件作為軟體應如何建置與運作的唯一真理。其核心理念為：若程式碼出現問題或需要修改，您編輯的是規格而非程式碼，Codeplain 會重新生成實作。
現在，Omerčević 進一步推廣此概念。在 [The New Stack] 的專訪中，他主張隨著 AI 產生的程式碼量越來越大，瓶頸已從撰寫軟體轉移至審查與維護，而審查規格（編碼意圖而非實作）所需的心智負荷遠低於審查程式碼。
「我們的論點是程式碼不應被維護——程式碼應被重新生成。規格應被審查，且負責維護的正是這些規格。」
Omerčević 解釋道：「我們的論點是程式碼不應被維護——程式碼應被重新生成。規格應被審查，且負責維護的正是這些規格。」
為了推進這一使命，公司正推出一個名為「plain-forge」的新開源代理技能框架。這個框架讓編程代理（例如：Claude Code、Codex 和 OpenCode）能夠透過對話來起草和維護 Plain 規範，從而自動化了以往需要最多人類投入的規範驅動開發部分。
與此同時，Codeplain 公布其已籌集到目前為止總計 $3M 的資金，支持者包括 GapMinder VC 和 [Silicon Gardens](https://www.silicongardens.com/）。
規範的樂趣：一場新的開發正規化
Codeplain 在規範驅動開發方面並非孤軍奮戰。早在 2025 年七月，Amazon 推出了 Kiro，這是一個以代理 IDE 為核心的工具，透過從自然語言提示生成結構化規範來引導開發。而 GitHub 則推出了 Spec Kit，一個開源工具集，旨在讓規範成為 AI 代理可以直接執行的可執行文件。
然而，這一概念的起源卻早於這些發展。2023 年，SpecLang——GitHub Next 的一項研究專案開始探索使用簡單英語作為真正的程式語言的可能性，讓 AI 將人類意圖轉換為可執行的程式碼。
這條線索也與 Codeplain 息息相關。Johan Rosenkilde——SpecLang 的創建者之一以及 GitHub Copilot 團隊的創始成員，目前擔任 Codeplain 的董事會成員，也是其最早期的投資人之一。
儘管規範驅動開發正在取得進展，但似乎開發人員並不熱衷於撰寫規範。透過使用者測試，Omerčević 和他的團隊發現，雖然開發人員抗拒撰寫規範，但他們普遍願意閱讀規範。事實上，一條結構良好的規範比最終產生的程式碼更容易審查和推理。
Plain-forge 是 Codeplain 對於這項矛盾的解決方案。它不再要求開發者從零開始撰寫規格，而是讓程式碼代理（coding agent）動起來——去研究問題、漸進式地草擬規格，並在人類看到之前先與 Codeplain 的渲染器（renderer）進行驗證。至關重要的一點是，它不會透過預先產生龐大的規格文件來啟動整個流程——這是 Omerčević 明確批評的做法。
他說：「我們不會一次丟給開發者 200 行的規格，我們是採取迭代式的做法。」
每一項微小的規格都會產出可運行的軟體，讓開發者能立即檢查並給予回應；這讓開發者能一次掌握一個功能而熟悉規格，而不是被迫面對一份他們根本沒參與形塑的完成文件。
「透過漸進式地增加規格，開發者正在與規格建立關係。」
Omerčević 表示：「透過這種方式，藉由漸進式地增加規格，開發者正在與規格建立關係。規格就是事實來源（source of truth），也是給予開發者的回饋，證明 AI 理解了他們的要求。」
如鳳凰般的重生
在這背後的核心理念是：程式碼應被視為可拋棄的產出，而非持久性的資產；而團隊應該保留並維護的是規格（spec），而非生成的程式碼。Omerčević 表示，他是在開發 Codeplain 的過程中得出這個結論的，但他發現很難向那些職業身分完全建立在程式碼上的開發者解釋清楚。
這就是 Chad Fowler 的 鳳凰架構（Phoenix Architecture） 介入的契機。Fowler 作為一名資深工程師以及 BlueYard Capital 的普通合夥人（General Partner），在過去的六個月中，致力於為這種方法建立一個更廣泛的哲學框架。
他在去年 12 月發布的系列文章首篇，標題為 Regenerative Software（再生式軟體），主張 AI 已讓程式碼變得廉價且充裕，這顛覆了過去數十年關於軟體系統中哪些部分值得保留的假設——而且那些堅持留守現有實作的團隊，正在比他們意識到的更快地產生技術債（technical debt）。
Omerčević 表示，這個框架提供了他一直以來苦苦尋找的描述詞彙。
「『規格驅動開發（Spec-driven development）』對於一般開發者來說真的很難溝通。」
Spec-driven development 真的很難向普通開發人員傳達，Omerčević 表示。「Chad 做得很棒的是將故事與程式碼結合，他說唯一不同之處是這段程式碼不再永久存在——它是暫態的，並且可以從其他 artefact 中隨時重新產生。」
Phoenix（鳳凰）在初學者看來是一個希臘神話生物——一種會週期性燃燒自身並從灰燼中重生的鳥類。Fowler 認為軟體系統應該被設計成這樣。
在他三月發表的文章《對話即提交》中，Fowler 討論了當開發人員手動編輯 AI 生成的程式碼時，他們切斷了某個重要事物：為什麼存在於該程式碼中的記錄以及決策過程。輸出改變了，但導致變更的原因卻消失了。
隨著時間推移，這種丟失背景資訊的累積就是 Fowler 所稱的「provenance debt」——他認為大多數開發人員在整個職業生涯中都在不知不覺地積累了這種債務。
「如果我們沒有朝著最終記錄下這些豐富且重要的資訊邁進，那麼面對以創新方式構建軟體的這一波浪潮，我們將對不起。」
「問題只在於，技術上很難在沒有極端官僚主義的情況下捕捉 provenance，因此我們的整個產業幾乎都決定這不是值得嘗試的事項。」Fowler 在《新堆棧》中解釋道。「現在的工具開啟了這些事物的可能性，而不再需要繁重的流程。我的觀點是，如果我們沒有朝著最終記錄下這些豐富且重要的資訊邁進，那麼面對以創新方式構建軟體的這一波浪潮，我們將對不起。」
換句話說，規範及其背後的理由現在才是值得保留的東西——而不是它們產生的程式碼。
很難過度誇大地這將涉及的文化轉變——開發人員畢竟是以程式碼為中心建立自身身份的。那麼你該如何向工程師說明「刪除」與「重新產生」代表進步？
對於 Fowler 來說，有兩種方式，每種方式都反映了不同類型的說服。
第一步是等待，因為他們會發現，隨著時間推移，舊有的做事方式已經變得過時。我們需要進化或者面臨淘汰，"他說。" 而更積極的第二步則是向他們展示，刪除與再生定義並強化了新的嚴謹性——只有這套新工具才能實現。"Codeplain"，在福勒看來，是一次可信的嘗試，將這種嚴謹性融入到一個運作中的產品中——不過他小心地說，這只是一個更大的拼圖的一部分，目前仍在組裝中。
"我希望有許多公司和開放原始碼開發者能夠建立它 [1],"他說。"因為我相信這個遺失的層次可能看起來非常不同。在這一點上充滿了想像力和創新空間。"我不希望走任何一個團隊或個人的假設，認為它應該如何運作。越奇怪越好，我認為。我們必須創造出一套新的慣例和工具。
達到規格
奧梅爾切維奇並非不熟悉構建並交付企業軟體的經驗——他之前創立了 Cleanshelf，一個 SaaS 管理平台。他於 2021 年將其售予 LeanIX [2]，後者又在 2023 年被 SAP 收購 [3]。那麼，Codeplain 就是他的下一個行動——而且它已經有客戶在使用它了。
Incode，一家身份驗證服務提供商，使用 Codeplain 來建立和維護與外部資料供應商的整合工作——這涉及持續的 API 研究、不斷變化的外部系統，以及對意外故障的高容忍度。
正是這個最後的問題——事情出錯了——讓奧梅爾切維奇感到最振奮。因為規格編碼的是意圖，而不是實施細節。當外部 API 改變並破壞了一個整合時，Codeplain 通常可以通過從完全相同的規格中重新生成程式碼來解決問題，而不會使規格受損。是程式碼出了錯，而不是規格出了錯。
"你甚至不需要修改規格，"奧梅爾切維奇說。"你只需要從完全相同的規格重新生成程式碼，因為通常情況下，只是小小的變化會導致問題，但規格並沒有改變。"
當然，以下是翻譯後的內容：
除了有硬有的經濟論點支撐這種方法。Omerčević 指出，編寫生成規格的代理程式使用五到十倍更少的標記碼；因為規格對代理程式來說認知負擔較小，所以可以在同一個上下文視窗內處理更大的、更有複雜性的問題。至於程式生成步驟本身，Codeplain 使用了如 Gemini Flash 這種更快、更便宜的模型，而不是 frontier 模型，以降低成本。
Omerčević 用的類比是 TypeScript 編譯器：Claude 可以直接從 TypeScript 生成 JavaScript，但為什麼要這樣做呢？當一個專門的工具可以更快、更便宜地完成時，那正是最佳選擇。
「讓專業工具去做它們真正擅長的事。」他說。「而讓 Claude 做它真正擅長的事情——研究。」
社群為開發者創建了路線圖、文章、資源和旅程，幫助他們選擇方向並在職涯中成長。