AI写代码天天返工？23万星的开源项目给出答案

说个我自己这段时间的感受。

用AI写代码，返工最多的情况都差不多：需求我说得挺清楚，它做得也挺快，结果出来一看，根本不是我要的那个东西。

我翻过自己的返工记录，多数时候跟模型聪不聪明关系不大。是我和它之间少了一套干活的规矩，需求没问透，写完也没验。

Matt Pocock的做法很直接，他把自己每天在用的那套规矩整理出来开源了。

仓库叫 mattpocock/skills。

这个仓库现在23.8万Star，被装了1800多万次，是目前安装量最高的一套技能集。

第一性原理：AI缺的不是智商，是规矩

大多数人的思路是：AI写得不准，是因为模型不够强。于是换更强的模型，花更多的钱。

Matt反着来。

他问了一个问题：如果AI已经足够聪明，为什么还会犯错？

答案很简单——你给它的需求是模糊的，它执行的路径是没有约束的。

就像让一个顶级工程师干活，你不给他写需求文档，不给他Code Review，只说"帮我做个功能"。他能做好，但返工率会很高。

Matt的做法是把"规矩"写成文件，让AI每次干活都照着读一遍。

这叫Skill。

Skill到底是什么

一个Skill就是一个文件夹，里面放一份说明文档。

文档告诉AI：某一类活，要按什么流程干。

用的时候敲个 /tdd 这样的命令，把它喊出来。或者让AI自己判断该不该用。

它跟 CLAUDE.md 那种每次都加载的项目说明不一样。Skill只在被触发的那次会话里加载，平时不占上下文。

这背后有个杠杆思维：找到能放大10倍的支点。这个支点是"可重复执行的规矩"。

你写一次Skill，下次AI照做。你不用每次都重新解释。

四组Skill，覆盖完整工作流

仓库里有五十来个Skill，真正日常高频用的就二十多个。我按干活的顺序分成四组。

第一组：动手之前，先把需求问清楚

这是最火的两个Skill：/grill-me 和 /grill-with-docs。

它们干的事就一件——让AI反过来盘问你。

注意，是AI问你，不是你问它。它会把你需求里没想清楚的岔路一个一个问出来，一次只问一个，一直问到每条岔路都有答案为止。

我实际用下来，经常被它问住。很多想当然的地方，都是被这么问出来的。

/grill-with-docs 多干一件事：盘问过程中，它会把项目里的术语整理进一个叫 CONTEXT.md 的文件，把那些不好撤销的技术决策写成 ADR 文档存下来。

CONTEXT.md 的价值很大。没有它的时候，同样的问题你得跟AI这么解释："课程里某个章节下的课时，被变成真实文件的时候出了点问题"。有了它，一句话就够了："materialization cascade 出了个问题"。

意思没变，话短了很多。而且这个词一旦定下来，AI后面写代码也会照着用，变量名、文件名自然是同一套叫法，不用每次都重新掰扯。

第二组：写代码时，测试和排错有规矩

/tdd——测试驱动开发。

先写一个注定失败的测试，再写刚好够它通过的实现，一次只切一小片。它专门防一种很常见的假TDD：先把所有测试写完，再写所有实现。那样测的全是你想象出来的形状，不是真实行为。

/diagnosing-bugs——排查bug用的。

它的规矩很硬：必须先造出一条能稳定复现问题的命令，并且真的跑过一次，才允许进入猜原因的阶段。跑不出来就不许猜。

这条规矩我觉得直接抄进团队的bug模板里都不过分。

/code-review——提交前的检查。

一边看代码有没有遵守项目自己定的规范，一边看它是不是真的实现了当初的需求，两边分开跑，谁也不干扰谁。

第三组：管住代码库，别越写越乱

AI写代码快，代码变乱也快。

/improve-codebase-architecture 会扫一遍整个仓库，找出那些值得收拾的模块，生成一份 HTML 报告摆在你面前，你挑一个想改的，它会针对这个候选继续跟你讨论怎么改。

Matt建议隔几天就跑一次。它只负责把候选找出来给你看，不会自作主张动手重构。

这背后用的是"深模块、浅模块"那套经典理论。浅模块的接口和实现一样复杂，基本就是个传话的，这种就是它要揪出来的对象。

第四组：把一个完整需求串成流程

前面这些Skill都是单个的，下面这几个负责把流程串起来。

一个需求从讨论到提交，中间这几步它们各管一段：

/to-spec：聊得差不多了，直接把当前对话整理成一份规格说明。它不会再追问你，只把已经聊过的东西收拢成文档。

/to-tickets：把规格拆成一张张工单，每张都标清楚谁阻塞谁，先干什么后干什么。

/implement：照着规格或工单开始干活，中间自动走 /tdd 的节奏，提交之前再过一遍 /code-review。

/triage：issue一多就需要分诊，它按一套状态机把issue一个个过一遍。

/handoff：会话聊得太长、AI开始变迟钝的时候，把当前进度压成一份交接文档，开一个新会话接着干。

/prototype：遇到那种说不清、必须亲眼看到的问题，先做个一次性的原型看看，看完就扔。

为什么是现在

这个仓库我翻完以后，印象最深的一点是：里面其实没有什么新东西。

盘问需求、测试先行、统一语言、ADR、原型验证——全是软件工程里讲了二三十年的老规矩。

这个开源项目做的事，说白了就是把老规矩写成AI能照着执行的文件。

这些做法单拎出来都不新鲜。不过我还是挺认这个方向。

我现在用AI写代码，会不会写早就不成问题了。真正头疼的是它写得太快，快到以前那些老问题全被放大了。

需求没说清、代码越堆越乱，代价都比以前大不少。这种时候，反而是这些老规矩管用。

什么情况下值得用

说几个我觉得对得上号的场景。

接新需求的时候。需求越模糊，grill系列的价值越大。我自己体会是，盘问那半小时看着烦，但比起写完再返工，还是划算得多。

Bug复现不出来的时候。与其盯着代码猜，不如让 /diagnosing-bugs 逼着我们先把复现命令造出来。很多查了好几天没结果的bug，回头看都是这一步被跳过去了。

老项目越改越乱的时候。隔几天跑一次

/improve-codebase-architecture，让它把值得收拾的地方列出来，我们挑着改。

还有不写代码的事。/grill-me 不看代码也能用，写方案、做决策、想产品点子，让它盘你一轮，比自己闷头想要扎实。

什么时候用不上

就想快速糊个demo、写个一次性脚本，那这套东西对你就是负担。直接让AI写就完了。

Matt在README里也写得很明白：这些skill是他拿来做真实工程的，vibe coding用不上这套。

我的建议

别一次全装。挑一两个最对症的先试。

我自己是从 /grill-with-docs 开始的，它是这套东西的入口。用顺手了再往下加。

这套东西不挑模型。README里写明了 work with any model，装的时候可以选装到哪个工具上，Codex也好、其他支持Agent Skills规范的客户端也好，都能用。

最后一句

AI不会因为你换更强的模型就变得靠谱。它只会因为你给了更清晰的规矩而变得靠谱。

把老规矩写成文件，让AI照着执行。这是我能想到的最朴素的智慧。

本文属个人实战分享，不构成投资建议。市场有风险，决策需谨慎。

作者：K哥聊AI，深圳35加，AI工具重度用户，专注免费AI工具教程与实战，拒绝割韭菜。