AI寫代碼越勤快，代碼庫死得越快

一個Cursor用戶發現：讓AI寫代碼3個月后，代碼庫變成了"意大利面條"。

這不是技術債，是技術災難。當AI編碼助手（AI Coding Agent）開始批量生產代碼，我們反而需要更嚴格的代碼規范——比人類寫代碼時更嚴格。

「一只編碼助手能讓代碼庫變爛，一群編碼助手能讓代碼庫爆炸」

這份來自AI基礎設施公司Convex的工程師指南，本質上是一份"人類如何馴服AI代碼"的生存手冊。它提出的核心矛盾很尖銳：AI讓寫代碼變便宜了，但維護成本正在指數級上升。

正方：AI應該像人類一樣寫"語義化函數"

Convex團隊的第一條軍規：代碼必須自解釋（self-documenting）。

他們區分了兩種函數類型。語義函數（semantic function）是代碼庫的"原子"——只做一件事，輸入輸出清晰，無副作用，極度可測試。從quadratic_formula()到retry_with_exponential_backoff_and_run_y_in_between()，好的語義函數哪怕只用一次，也能幫未來的維護者（人類或AI）快速索引信息。

實用函數（pragmatic function）則是"流程組織者"，把多個語義函數和獨特邏輯打包成復雜流程。比如provision_new_workspace_for_github_repo()或handle_user_signup_webhook()。它們注定會頻繁變動，所以測試靠集成測試而非單元測試。

這套分層設計的隱含假設是：AI可以像人類一樣理解抽象邊界，并自覺維護這種分層。

反方：AI根本不懂你在寫什么，規范是徒勞的

質疑者的核心論點：LLM（大語言模型）的上下文窗口有限，且對代碼庫的"全局理解"是幻覺。

當你讓Cursor補全一個函數，它只能看到當前文件和少數相關文件。所謂的"語義函數"設計，對AI而言只是文本模式的延續——它不會真正理解"這個函數應該被復用"，只是模仿了訓練數據中的常見寫法。

更殘酷的觀察來自一線開發者：AI生成的代碼往往"看起來對，跑起來錯"。它能完美遵循命名規范，卻在邊界條件上翻車；能寫出漂亮的類型簽名，卻隱藏了時序依賴的bug。當AI批量生產這種"表面合規、實質脆弱"的代碼時，嚴格的規范反而成了遮羞布——讓問題更難被發現。

還有效率層面的質疑。Convex團隊要求"語義函數盡可能小"，但AI的計價模式是按token（詞元）收費。過度拆分函數意味著更多的API調用，更高的成本。當商業壓力遇上代碼潔癖，規范能堅持多久？

我的判斷：規范的價值不在約束AI，而在約束人類對AI的濫用

Convex這份指南的真正讀者不是AI，是用AI的人。

"意圖明確"（intentional）這個詞在原文標題中出現兩次，泄露了核心焦慮：當代碼生成變得零摩擦，人類容易失去對"為什么要這樣寫"的追問。規范的存在，是強迫人在提交前做一次人工審核——不是檢查語法，是檢查設計意圖是否清晰到足以被另一個AI（或6個月后的自己）理解。

語義函數 vs 實用函數的區分，本質是在代碼庫中建立"穩定層"和"變動層"的防火墻。AI可以隨便改動實用函數，但動語義函數時需要額外警惕。這種架構分層在AI時代比之前更重要，因為AI的"遺忘成本"為零——它不會記得三個月前為什么這樣設計，只會根據當前上下文生成最可能的補全。

一個冷觀察：這份指南本身被做成了"技能"（skill）——可以喂給Cursor的AI助手。這像是一個遞歸隱喻：我們用AI生成的規范，來約束AI生成的代碼。也許最終的解決方案不是更好的規范，而是更好的元AI——專門負責審核代碼設計意圖的AI審查員。

在那之前，人類還得繼續扮演那個討厭的角色：在AI狂歡后默默收拾殘局的代碼管家。