想法一直是對的，問題在於不划算

軟體工程裡有很多方法，你一讀就會覺得「這本來就該這樣做」。

當然應該用 contracts 明確 function 能接收什麼、必須回傳什麼。當然 tests 不該只寫幾個人工挑選的例子，而應該驗證 properties。當然團隊不該把 coverage 當成品質代理，而應該真的去判斷 tests 能不能抓到 faults。也當然，架構決策應該和程式碼保持同步，而不是寫完就爛在文件目錄裡。

這些想法本身從來不荒謬。問題一直是經濟性。它們貴的不是算力，也不是工具授權，而是最難擴張的資源: 持續性的專業注意力。

過去很多強工程策略都死在同一個循環裡。團隊很有熱情地引入，品質也真的提升了，然後維護成本開始出現。contracts 開始漂移，property tests 跟不上 schema 變化，surviving mutants 越積越多卻沒人分流判斷，架構文件逐漸變成虛構文字。它們不是因為「理論錯了」才失敗，而是因為它們要求的持續專業能力遠超多數產品團隊能穩定投入的程度。

這才是目前 AI 時刻真正重要的地方。關鍵變化不只是模型能更快寫 code，而是模型開始能接住過去最昂貴的 specification 與 verification 工作。

真正把這些策略困在小眾裡的是什麼

不是算力。便宜算力很早就有了。

也不只是工具。不少方法早就有成熟工具，但工具仍然預設有人知道該怎麼寫 invariants、generators、contracts、boundary rules。

真正的瓶頸是一種很難並行化的專業能力。

  • Design by contract 需要有人能寫出在 refactor 之後仍然有意義的 preconditions、postconditions、invariants。
  • Property-based testing 需要有人看到一個 function 時，會自然想到 round trip、idempotence、error behavior、algebraic properties，而不只是幾個 examples。
  • Mutation testing 需要有人能分流判斷 survivors，判斷它們暴露的是真空缺還是無害的 equivalent mutants。
  • Type-level correctness 需要團隊理解 branded types、phantom types、typestates，甚至 formal verification 工具。
  • Living specifications 需要持續把人的決策翻譯成可執行的 architecture rules。

每一種策略都有自己的維護稅。把它們組合起來會更貴，因為你還得寫中間那層膠水。

所以很多「紙面上看起來很好」的方法最後只留在航太、金融、形式化方法研究，或極度自律的基礎設施團隊裡。方法有效，人力配置模式不成立。

AI 改變了什麼

AI 不是拿走工程判斷，而是改變判斷花在哪裡。

以前資深工程師得手寫大部分腳手架。現在模型可以先起草 contract、建議 properties、搭出 schema、把自然語言決策轉成 architecture rule，甚至順手為 surviving mutant 寫一個 regression test 初稿。人類工程師不再從空白頁開始，而是把精力放在領域正確性審查上。

這個變化比表面看起來大得多。

舊工作流是重撰寫，新工作流變成重審查。

這意味著:

  • contracts 的導入成本下降了
  • property-based testing 變得更現實了
  • mutation testing 終於更可營運了
  • architecture constraints 更容易真正落地到 CI

真正的經濟性突破就在這裡。不是「用模型取代工程師」，而是讓過去需要專家撰寫的策略，變成一般產品團隊也能承受的東西。

更關鍵的一點: 這些策略組合起來才更強

最有價值的變化，不是某一個技術單點變便宜了。

真正有意思的是，AI 讓整套 stack 的組合成本下降了。

一個 contract 可以變成 property test 的來源。一個 property test 可以再交給 mutation testing 去衡量強度。一個 schema 可以定義 runtime boundary。一個 ADR 可以變成 architecture rule。一個 branded type 可以在 runtime checks 之前先收緊 surface area。價值不只在每一層本身，更在這些層之間的膠水。

在 AI 之前，多數團隊連其中一個策略都很難證明值得做。AI 之後，同時組合幾層開始變得現實，而且不必把可靠性工作做成全職專家項目。

這不是魔法

當然也有錯誤做法。

如果你只是讓 AI 生成 code、contracts、tests，卻沒有 deterministic enforcement，那你得到的只是一大堆看起來很像那麼回事的文字。目標不是讓模型「批准」你的 codebase。目標是讓模型幫助你產出可以被低成本、重複驗證的 artifacts。

所以真正有效的模式依然很樸素:

  • 用 AI 生成
  • 用 deterministic tools 驗證
  • 在 specification level 做 review
  • 一旦規則被破壞，就讓 CI 立即失敗

AI 在這裡的價值，是補上專業能力缺口，而不是充當最終裁判。

為什麼現在尤其重要

今天很多團隊已經在用 AI 壓縮實作時間。真正的風險是，交付速度的成長速度，超過驗證深度的成長速度。

如果發生這種失衡，你得到的不會是一個更高效的工程組織，而只是一條更快滑向脆弱系統的路徑。

真正的機會，是用同樣加速生成的模型，把過去太貴而無法持續的可靠性實踐重新帶回來。這樣，速度才不會直接變成營運債務。

未來幾年，真正佔優的會是那些很早意識到這一點的團隊。AI-assisted coding 本身不是策略。AI-assisted verification and enforcement 才是。

這也是為什麼那麼多老工程策略突然重新重要起來: 不是因為它們突然變得更正確，而是因為它們終於變得在經濟上可行了。