软件工程 on KnightLi的博客

拒绝 Vibe Coding：Matt Pocock 的 skills 仓库给 AI 编程补上工程约束

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

AI 写代码越快，项目失控也可能越快。真正的问题不是模型会不会生成函数，而是它是否理解需求、是否遵守团队语言、是否能在已有架构里小步推进。如果把 AI 当成“随便说一句就自动完工”的代码喷射器，最后很容易得到一堆跑不通、难维护、没人敢改的代码。

Matt Pocock 开源的 mattpocock/skills 仓库，正好给了一个相反方向的示例：不要让 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 是放大器；配合得不好，它会把混乱也一起放大。

所以，软件工程基础没有因为 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%，而是题目已经摆出来了。