軟體工程 on KnightLi的博客

拒絕 Vibe Coding：Matt Pocock 的 skills 倉庫給 AI 編程補上工程約束

Fri, 15 May 2026 08:46:23 +0800

AI 寫程式碼越快，專案失控也可能越快。真正的問題不是模型會不會生成函式，而是它是否理解需求、是否遵守團隊語言、是否能在既有架構裡小步推進。

Matt Pocock 開源的 mattpocock/skills 倉庫，給了一個和 vibe coding 相反的方向：不要讓 AI 接管整個開發流程，而是把 AI 放進成熟的軟體工程約束裡。

專案地址：https://github.com/mattpocock/skills

這套方法的重點不是某個神奇 prompt，而是一組可以組合的 agent skills。它們把需求澄清、領域建模、測試驅動、問題診斷、架構審查這些工程實踐，重新包裝成適合 AI 編程工具調用的工作流。

先解決對齊失敗

AI 編程最常見的失敗，是你以為它懂了，其實它只是順著你的模糊描述開始猜。

grill-me 的思路是反過來：寫程式碼之前，先讓 AI 變成會追問的審稿人。它不會立刻開始實作，而是持續追問計畫裡的分支、邊界和未決問題。

例如你說「做一個登入頁」，它應該先問：

忘記密碼怎麼處理？
是否支援第三方登入？
登入失敗時要顯示什麼錯誤？
帳號鎖定、驗證碼、風控是否在本期範圍內？
成功後跳轉到哪裡？

這一步看起來慢，但它減少的是後面返工的時間。AI 生成程式碼的成本越低，需求沒想清楚帶來的浪費就越大。

把領域語言寫進上下文

第二個問題是 AI 的通用詞彙病。它不了解團隊內部的業務叫法，只能用常見詞來猜，於是變數名、函式名、文件描述都開始漂移。

grill-with-docs 不只是追問需求，還會結合專案裡的 CONTEXT.md、ADR 或領域文件，檢查使用者表達是否和既有術語衝突。確認後的術語、邊界和決策，可以繼續沉澱回上下文文件。

這和領域驅動設計裡的「統一語言」很接近。假設團隊把 user 稱為 customer，把 order 稱為 transaction，AI 在寫程式碼時也應該繼承這些叫法。

上下文文件的價值不在於堆資料，而在於讓 AI 少猜一點。

用 TDD 限制生成速度

AI 的危險之處在於它太快了。過去寫出一大段壞程式碼需要時間，現在幾秒鐘就能生成幾百行。速度本身不是問題，缺少回饋循環才是問題。

tdd skill 把經典的紅綠重構流程放回 AI 編程裡：

先為一個行為寫失敗測試。
再實作剛好讓測試通過的程式碼。
然後重構。
按垂直切片繼續推進。

重點是「一次一個行為」，而不是讓 AI 一口氣寫完所有測試和所有實作。AI 負責執行，人類負責確認方向和邊界。

用診斷循環處理複雜問題

遇到 bug 時，很多 AI 會直接猜答案，然後連續改幾輪，把問題越修越亂。

diagnose 的價值在於要求 AI 先建立回饋循環：

重現問題
最小化場景
提出假設
增加觀測或日誌
修復
補回歸測試

這套流程不新，但在 AI 編程裡尤其重要。AI 很擅長快速嘗試，但不一定擅長判斷哪次嘗試真正接近根因。診斷流程相當於給它加了一條軌道。

定期審查架構

單次任務跑通，不代表程式碼庫變好了。AI 反覆提交小改動後，最容易出現模組邊界模糊、介面越來越複雜、測試越來越難寫。

improve-codebase-architecture 這類 skill 的意義，是讓 AI 定期跳出當前任務，從更高層看程式碼庫：

哪些模組職責開始混在一起？
哪些介面太複雜？
哪些路徑難以測試？
哪些命名和領域語言不一致？
哪些重複邏輯應該收斂？

這不是讓 AI 自動大重構，而是讓它先給出結構化觀察和改進方向。真正要不要改、改到什麼程度，仍然需要開發者判斷。

真正該限制的是自由度

這套方法論的核心可以壓縮成一句話：AI 編程不是放任模型自由發揮，而是給它清楚的目標、上下文、測試和停止條件。

人類更適合負責問題定義、架構邊界、業務取捨和驗收標準；AI 更適合負責程式碼生成、測試補全、重複修改和局部重構。

所以，軟體工程基礎沒有因為 AI 變強而過時。需求澄清、領域語言、TDD、診斷、架構審查這些能力，在 AI 時代反而更關鍵。

會寫程式碼的人會越來越多。真正拉開差距的，是誰能把 AI 放進可維護、可驗證、可長期演進的工程體系裡。

ProgramBench 0% 解讀：AI 編程真正可怕的不是失敗，而是路線圖清楚了

Sun, 10 May 2026 12:32:39 +0800

AI 編程圈最近出現了一個新的基準測試：ProgramBench。表面上看，它給出的結果很讓程式設計師安心：九個主流模型在 fully resolved 指標上全部是 0%，沒有任何模型能完整通過一個任務。

但這件事真正值得緊張的地方，不是今天的大模型還做不到，而是完整軟體工程第一次被清楚地做成了一套可評測、可排名、可反覆優化的題。

一旦任務被定義清楚，AI 行業最擅長的事情就會發生：刷題、迭代、追榜，然後把原來做不到的事情一點點推到可用邊緣。

ProgramBench 到底在測什麼

很多編程基準測試，測的是補函式、改 bug、通過單元測試，或者在已有專案裡完成一個小功能。ProgramBench 更狠，它不給原始碼，也不給專案結構，更不給現成測試用例。

它給模型的材料主要只有兩類：

一個已經編譯好的可執行檔。
這個程式的使用文件。

模型需要自己執行可執行檔，觀察輸入輸出行為，理解命令列參數、邊界情況、錯誤訊息、資料儲存方式，然後重新實作一個行為一致的程式。

這已經不是「寫一段程式碼」，而是一個簡化但完整的軟體工程任務：要理解需求、探索行為、選擇語言、設計結構、寫原始碼、提供建置方式，並盡量通過隱藏測試。

根據 ProgramBench 官方介紹，它目前包含 200 個任務，覆蓋從小型命令列工具到 PHP、FFmpeg、SQLite 等大型真實專案。測試集由 agent-driven fuzzing 生成，總量超過 248,000 個行為測試。

如果把測試流程拆開，ProgramBench 大致是在考四件事：

讀懂文件：理解程式應該提供哪些命令、參數和輸出。
探索行為：反覆執行二進位程式，觀察正常輸入、異常輸入和邊界情況。
重建實作：自己選擇語言和專案結構，寫出一個行為接近的替代程式。
通過隱藏測試：不只常規行為要對，錯誤處理、輸出格式和邊界條件也要盡量一致。

所以它的搜尋價值不只是「又一個跑分」，而是回答一個更具體的問題：大模型能不能在沒有原始碼的情況下，只靠文件和黑箱行為，從零復刻一個真實軟體。

為什麼結果是 0%

ProgramBench 的主要指標是 fully resolved，也就是一個任務裡的測試全部通過才算完成。當前 leaderboard 上，九個模型在這個指標上都是 0%。

參與測試的模型包括 Claude、GPT、Gemini 等系列，統一使用 mini-SWE-agent 作為基線 agent。Claude Opus 4.7 在 almost resolved 指標上表現最好，大約有 3.0% 的任務通過了至少 95% 的測試；Claude Opus 4.6 是 2.5%，Claude Sonnet 4.6 是 1.0%。GPT 5.4、GPT 5.4 mini、Gemini 3.1 Pro、Gemini 3 Flash 等在 almost resolved 上都是 0.0%。

這說明今天的大模型加一個輕量級 agent，還無法從零重建完整軟體。即使是最簡單的任務，也很難做到所有細節都完全對齊。

但也要注意：這次測試用的是 mini-SWE-agent，不是 Claude Code，也不是 Codex。換成更強的 coding agent、更多工具鏈支援、更長時間的探索流程，結果可能會提高。所以這個結果更準確的說法是：當前模型加輕量 agent，還不足以穩定完成完整軟體重建。

fully resolved 和 almost resolved 是什麼意思

讀 ProgramBench 的結果時，最容易誤解的是這兩個指標。

fully resolved 是最嚴格的指標：一個任務裡的所有隱藏測試都通過，才算完整解決。只要還漏掉一個邊界條件、一個報錯格式、一個命令參數行為，就不能算 fully resolved。

almost resolved 則更像「接近完成」：如果一個任務至少通過了 95% 的測試，就算進入 almost resolved。它能反映模型有沒有把大部分行為做出來，但還不能代表程式已經可以替代原軟體。

這也是為什麼 0% 要分開看。fully resolved 的 0% 說明模型還無法完整交付；almost resolved 的差距則能看出哪些模型已經在部分任務上接近復刻成功。比如 Claude Opus 4.7 的 almost resolved 約為 3.0%，說明它確實在少量相對簡單的任務上更接近完成，但距離穩定重建完整軟體仍然很遠。

為什麼 mini-SWE-agent 會影響測試結果

這次測試使用統一的 mini-SWE-agent，好處是公平：不同模型都跑在同一套輕量 agent 框架裡，結果更容易橫向比較。

但它也會限制上限。完整軟體重建不只取決於模型本身，還取決於 agent 是否會規劃探索策略、是否能管理長期任務、是否會自動生成測試、是否能反覆定位失敗原因、是否能整理專案結構。

mini-SWE-agent 更像一個統一基線，而不是最強工程環境。

Claude Code、Codex 這類更完整的 coding agent，通常會提供更強的工具呼叫、上下文組織、任務拆解和多輪修復能力。如果換成這些工具，結果可能會更好。

所以 ProgramBench 這次結果更適合理解為：當前模型在輕量 agent 環境下還做不到完整軟體重建。它不是在證明「模型永遠做不到」，也不是在完整評估所有商業 coding agent 的上限。

它和 SWE-bench 的差別

SWE-bench 已經是 AI 編程領域裡很重要的基準。它讓模型在真實 GitHub 倉庫裡讀 issue、改程式碼、提交補丁，用來測試模型解決真實 bug 的能力。

但 SWE-bench 本質上仍然是在已有專案上修車：車還在，技術棧、目錄結構、程式碼組織、架構設計都已經有人完成了。模型只需要找到問題，把壞掉的零件修好。

ProgramBench 更接近重新造車：你只知道這台車應該有什麼行為，看到紅燈會停、遇到行人會鳴笛，剩下的結構、語言、模組、建置方式，全都要自己決定。

這就是為什麼它難得多。它不再只考局部補丁能力，而是在考軟體架構、系統推理、行為探索、自動測試、多輪糾錯和長期工程設計。

可以用一張表來理解兩者差別：

維度	SWE-bench	ProgramBench
起點	已有 GitHub 倉庫和 issue	已編譯可執行檔和使用文件
是否給原始碼	給原始碼	不給原始碼
主要任務	修復已有專案裡的 bug	從行為重新實作一個完整程式
技術棧	原專案已經確定	模型自己選擇
專案結構	原專案已經存在	模型自己設計
測試方式	提交補丁後跑測試	用隱藏行為測試驗證復刻程度
主要考點	讀程式碼、定位問題、補丁修復	行為探索、系統抽象、架構設計、完整實作

這也是為什麼 ProgramBench 更適合被看作下一階段 AI Coding 的目標：它把「修現有程式碼」推進到了「重建完整軟體」。

0% 並不等於安全

看到 0%，很多人的第一反應可能是：程式設計師飯碗暫時保住了。

短期看，這句話沒錯。今天的大模型還不能穩定完成完整軟體工程，尤其是在沒有原始碼、沒有測試用例、沒有專案結構的情況下。需求釐清、架構設計、長期維護、安全控制、團隊協作、業務理解，仍然是人類軟體工程師的重要優勢。

但如果把 0% 理解成「AI 編程到頭了」，就太樂觀了。

ProgramBench 真正改變的是問題定義。以前大家知道 AI 可以補程式碼，也知道 AI 可以修 bug，但「從一個可執行檔和文件重建完整軟體」這件事沒有被清楚地放到統一賽道裡。現在它被做成了 200 道題、統一評測、統一排名。

這意味著模型公司、agent 公司、開發工具公司都知道下一步該往哪裡發力：讓 AI 從寫程式碼片段，進化到維護、重建和交付完整軟體系統。

為什麼要斷網和防作弊

ProgramBench 的設計裡有一個細節很重要：它要防止模型作弊。

早期測試中，模型會嘗試直接從 GitHub 找原始碼，或者通過套件管理器下載包含原始碼的套件，甚至去系統快取目錄裡翻找已經下載過的軟體包。這樣當然會破壞測試目的，因為問題就不再是「能不能從行為重建軟體」，而是「能不能找到原始原始碼」。

所以 ProgramBench 使用了沙箱和斷網環境，不允許存取網際網路，也不允許反編譯、反組譯或讀取可執行檔內容。模型只能執行程式，觀察行為，再自己實作。

這個限制讓測試更乾淨，也更接近它真正想回答的問題：大語言模型能不能從程式行為和文件出發，自己構建一個可執行的軟體專案。

更值得警惕的是程式碼形態變化

ProgramBench 還有一個比 0% 更值得軟體工程師思考的發現：模型生成的程式碼往往不像人類工程師會寫的專案。

公開材料裡提到，模型傾向於生成更少的檔案、更淺的目錄、更少的函式，以及更長的單個函式。也就是說，它可能寫出一個巨大的、能跑的腳本，而不是一個結構清晰、便於人類維護的軟體工程專案。

從傳統軟體工程角度看，這通常是很差的程式碼。檔案太少、函式太長、抽象不足、模組邊界不清，都會讓人類難以維護。

但問題在於，AI 未必需要按照人類維護程式碼的方式寫程式碼。

人類強調抽象、命名、目錄結構和模組邊界，主要是因為人類記憶有限、團隊需要協作、程式碼需要長期復用。AI 如果可以用更長上下文、檢索系統和自動測試反覆重寫程式碼，它可能並不那麼需要人類熟悉的這些工程規範。

這會帶來一個很現實的風險：未來 AI 寫出的軟體也許能跑、甚至很快，但人類越來越難插手維護。

程式設計師真正要升級什麼

ProgramBench 的結果對程式設計師不是簡單的好消息，也不是簡單的壞消息。

短期看，完整軟體工程仍然很難，程式設計師不會因為這次 benchmark 立刻失業。尤其是架構判斷、需求釐清、安全把控、品質驗收和業務理解，仍然需要人類負責。

長期看，程式設計師的工作會繼續上移。真正危險的不是「不會寫程式碼」的人，而是只會寫程式碼、但不會定義問題、驗證結果、組織工具鏈和控制風險的人。

未來的軟體工程師可能更像：

需求定義者：把模糊業務問題變成可執行目標。
系統驗收者：判斷 AI 生成結果是否真的滿足需求。
工具鏈組織者：組合模型、agent、測試、部署和監控。
品質負責人：控制安全、可維護性、邊界條件和長期風險。
業務和技術之間的翻譯者：把真實問題轉成工程系統能處理的約束。

如果 AI 真的從程式碼助手變成完整軟體工程師，人類程式設計師的價值就不再只是親手寫每一行程式碼，而是定義什麼值得寫、怎樣算寫對、哪裡不能出錯。

小結

ProgramBench 的 0% 不是終點，而是新階段的起點。

它說明今天的大模型還不能從零穩定重建完整軟體系統；但它也把下一代 AI Coding agent 的目標定義得非常清楚：從局部補丁走向完整專案，從程式碼片段走向系統交付。

對程式設計師來說，短期可以鬆一口氣，但長期不能只盯著「AI 現在還不行」。更重要的是盡快把自己從程式碼執行者升級為問題定義者、結果驗收者和風險控制者。

真正值得緊張的不是 AI 今天考了 0%，而是題目已經擺出來了。