AI 写的代码两周就改不动了？一个程序员的应对方案。-安知木

【导语】

你有没有碰到过这样的事情。

你让AI帮你写了个功能，当时跑起来是溜溜的。

过了两周，产品跑过来跟你说”这个地方改一下”。你打开项目一看，当场就傻了。没有开展测试，所以不敢去进行修改。

没有相关的文档，根本不清楚当时为什么要那样去写。你看着眼前的屏幕，脑子里只剩下这么一句话：我当时怎么就没想着自己来写。你并不是独自一个人。

2025 年以来，大批工程师开始天天运用 AI 来写代码，随后陆陆续续都碰到了同一堵墙——代码可以跑起来，但却改不动。有一位名叫Matt Pocock的程序员，把自己应对这个问题的办法给开源了。

将其上传到GitHub之后，有八万多人点了Star。他这套方案，核心并不是让 AI 变得更聪明，而是换了一种和 AI 打交道的办法。

有一件事得先说清楚：AI 在和人聊天的过程当中，聊着聊着就会把前面聊过的东西给忘了——这个毛病，他这套方案是治不了的。那其实是模型自己的问题。

他解决的是另外一个问题：AI 还记得上下文的时候，它有没有老老实实按规矩干活。

一、毛病出在哪

先把根给挖出来。 AI编程工具这两年的进步可以说是相当大。像Claude、GPT以及Gemini这类工具，生成出来的代码越来越精准，上下文窗口也变得越来越长，可以容纳的项目规模也越来越大。但有个情况很奇怪：代码生成的质量在往上升，长期维护的相关体验却没能跟得上。

为什么？

我有个判断，先说明这不是什么权威数据，就是我自己和周围一圈人用下来的感受，瓶颈可能变了。

以往的瓶颈在于“AI 能不能写出可以运行的代码”。随着模型能力得到提升，这个瓶颈正在被一点点攻克。但现在又冒出来一个新的瓶颈，也就是“AI 能不能写出可以维护的代码”。

这其实是两码事。可以正常运行的代码，相关要求其实很简单：也就是语法要正确，逻辑要通顺，并且在当下不会出现bug。可以进行维护的代码，需要满足的要求多了去了：结构清晰、命名合理、边界条件都处理到位、后来的人员能够看懂、修改一个地方不会莫名其妙把另一个地方搞坏。

先说明清楚一件事：这篇文章所谈论的skills，解决的是可维护性当中跟流程和规范沾边的那部分内容——也就是有没有测试、有没有文档、有没有人审视过架构。至于变量名起得好不好、结构清不清晰，那些更偏向代码本身的质量，不在skills的直接射程当中。流程可以让好代码更好地得到维护，不能让烂代码变好。

AI在第一件事上的表现十分漂亮。在第二件事上，按照我和周围同行的使用体验来说，差了一大截。不是它笨。是“能维护”这个东西，太吃上下文了——也就是这个项目的规范是啥、这个团队的约定是啥、还有三个月前做那个设计决策的时候到底是怎么想的。

这些上下文，并不在AI的训练数据当中。同时也不在你那句“帮我写个登录功能”的内容里。所以你拿到了一批可以正常运行的代码，同时也拿到了一批三个月之后才会产生的技术债务。

所以你拿到了一堆能跑的代码，也拿到了一堆三个月后的技术债。

二、Pocock 的办法：换一种跟 AI 打交道的方式

Matt Pocock 想的办法，说穿了不复杂。

他把软件工程里几十年前就有的那些老规矩——需求澄清、TDD、PRD、ADR——写成了一套 AI 能照着执行的 prompt，开源在了 github.com/mattpocock/skills。

我写这篇文章的时候（2026 年 5 月 14 日），这个仓库在 GitHub 上有大概 8 万个 Star。有个第三方网站叫 Claude Code Marketplaces（一个叫 @mertduzgun 的人搭的，不是 Anthropic 官方的，数据靠不靠谱你自己判断）统计的累计安装量超过了 107,000 次。

注意，这个数字是把每个 skill 的安装次数加起来算的，不是独立用户数——你装三个 skill，就算三次。后面提到各 skill 的安装量，都是这个算法。

仓库里有十几个 skill。每个 skill 本质上就是一个 SKILL.md 文件，有的还带了参考文档和验证脚本。文件里写的就一件事：告诉 AI，在这个场景下，你必须按这个流程走，一步不许跳。

Pocock 在 aihero.dev 上解释过他为什么这么干。他原话是这么说的：

“I’ve been an engineer for nearly a decade. You have access to a fleet of middling to good engineers that you can deploy at any time. This means you need extremely strict and well-defined processes to get them to do useful work.”

翻过来就是：他把 AI 的能力比成”一批中等到尚可的工程师”。正因为他们的水平是”中等到尚可”——不是什么天才，不能你丢一句话过去它就自己把所有事想明白——所以才需要特别严格、定义特别清楚的流程。

这个比喻挺有启发性的，但不够完整。先看它好在哪：他没说 AI 是天才。他说的是”中等到尚可”。

这个定位，把一切都定了。

你对待一批中等工程师的法子，跟你对待一个你以为是天才的人的法子，应该完全不一样。中等工程师需要流程、需要关卡、需要在关键节点有人拍板。但大多数人在用 AI 写代码的时候，默认把它当成了后者——丢一句话过去，觉得它什么都能自己搞定。

说白了，真正的问题不是”天才不需要流程”。是”所有人都需要流程，但人们误以为天才不需要”。你看看顶尖团队——Google 的代码评审规范、亚马逊的 PR/FAQ 文化——恰恰是最死磕流程的。区别不在需不需要，在有没有意识到需要。

Pocock 的办法，就是把跟 AI 的协作方式，从”当它是天才”切换成”当它是中等工程师”。

三、三个 skill，三个有意思的设计

这套 skills 里安装量最高的三个，各自解决不同阶段的问题。我不光说它们干什么——那个看文档就行——我想拆一拆它们的设计为什么好使。

先说一句：Pocock 自己现在推荐的编码流程是 domain-model → to-prd → to-issues → tdd。domain-model 和 to-prd 的安装量不如 grill-me 高，但在他自己的工具箱里，已经替掉了 grill-me 在编码场景的位置。下面聊的这三个是安装量最高的，不一定是 Pocock 现在最推荐的——但它们的设计思路，最能说明这套东西的底层逻辑。

▎grill-me：追问的价值不在答案，在过程

grill-me 是安装量最高的 skill，在 Claude Code Marketplaces 上统计装了超过 25,000 次。

它的核心指令简单到不行：在我动手之前，一次只问我一个问题。

为什么”一次只问一个”这么要紧？

因为人这东西，面对一堆问题的时候，会下意识跳过那些不好回答的。五个问题一起砸过来，你答完前三个，对后两个说”回头再说”。但后两个往往才是最要命的——那些你不太确定、想躲、或者压根没想过的问题。

一次只问一个，你躲不掉。你必须面对。

不过有个重要的定位得说一下。GitHub README 把 grill-me 归在了 productivity 下面，不是 engineering，标注的是”for non-code uses”。Pocock 自己现在推荐用 domain-model 作为编码规划的起点。他在 X 上发过一条推文，原话是：

“My new skill lineup: /domain-model – replaces /grill-me, integrates some DDD concepts and adds docs & ADR’s during discussions.”

也就是说，grill-me 在 Pocock 自己的工具箱里已经降级了——从编码规划的核心工具，变成了更轻量的通用追问工具。编码场景的替代品有两个方向：domain-model（更重，带文档和 ADR）和 grill-with-docs（grill-me 在编码场景的直接替代品，追问过程中同步更新 CONTEXT.md——项目级的上下文文件，记录规范和约定——和 ADR）。

这个演变本身就挺有意思。说明 Pocock 在不停地迭代自己的流程——发现 grill-me 在编码场景不够用了，就拆成了更专的工具。

但还有个事值得多思考一层：在一个编码工具合集当中，安装量最高的竟然是一个非编码工具，这能够说明些什么呢？大概是由于“追问”这一动作本身，要比任何具体的编码流程都更有价值——不管你写不写代码，在做出任何决定之前被人追着询问一轮，都能够少踩不少的坑。

▎tdd：AI 干 TDD 比人强，但不是你以为的那种强

tdd 也就是测试驱动开发这个技能，它干了件什么事呢？它会强制 AI 去走测试驱动开发的红—绿—重构循环。也就是先写测试，这个测试必须挂掉，然后去写刚好能让测试通过的代码，之后再进行重构。

TDD 这玩意儿并不新鲜。但这项技能的有效性，建立在一个反直觉的观察之上：AI 比人更适合干 TDD。

不是因为它更聪明，而是因为它不嫌麻烦。

人们开展TDD的时候，最大的阻碍并不是不明白它的好处，而是执行的成本——编写测试确实会让人觉得很烦。尤其是当功能比较简单的时候，心里往往会冒出“这有啥好测的”这样的想法。人们会因为“觉得没必要”就直接跳过相关步骤。

人工智能在这件事上比人类要强得多——它不会因为“觉得没必要”就跳步。当然，这并不是百分之百的情况。实际使用的时候，人工智能偶尔也会跳过提示词里要求的步骤，技能水平大幅提高了遵守的概率，但依然不能打包票。

还有一个边界条件得讲清楚：AI会老老实实走流程，并不代表它每一步都走对了。它可能写出一个很烂的测试，也就是覆盖面不够、边界条件漏了，或者测试本身就存在bug。

流程保证的是”步骤不跳”，不保证”每一步都做对”。 这是两码事。

所以TDD这个技能真正提供的，并不是一套自动化的质量保证系统。它是一个“比人更不容易主动跳步”的执行者。质量控制还是得要人来盯——也就是去看测试写得对不对、覆盖够不够、重构有没有带进新的问题。

▎improve-codebase-architecture：一个叫”删除测试”的设计

这个 skill 可以让 AI 去扫描代码库，找出架构层面的相关问题。它是借助 John Ousterhout 所著的《A Philosophy of Software Design》里的“深度模块”概念来开展相关工作的——好的模块接口比较小，但内部承载的内容十分充足，坏的模块接口数量很多，但实际没有做多少实质性的工作。它带有一个名为“删除测试”的逻辑。SKILL.md 原文是这样写的：把这段代码删掉之后，复杂度是被集中起来了，还是仅仅只是被转移了？这里得把 concentrate vs move 这个二分法吃透。复杂度不会凭空消失。删掉一个模块后，要是复杂度集中到了更少的地方，那就说明这个模块没在封装复杂度，属于“浅”的模块，应该删掉。如果复杂度只是转移到了别的地方，那就说明模块在封装复杂度，应该把它留着。还有一个设计细节挺讲究的：你拒绝了AI的重构建议之后，AI并不是每次都会问你要不要写ADR。SKILL.md写得明明白白，只有当拒绝理由是“承重墙”级别的结构性原因时，才会触发这个流程。临时的、一眼就能看明白的理由则不会触发。这个设计防范的就是ADR泛滥的情况——要是每次拒绝都生成一个ADR，那么文档很快就会变成没人翻阅的垃圾堆了。

四、Pocock 是谁

简单说一下。 Matt Pocock是教授TypeScript的讲师，Total TypeScript课程便是由他所制作的。

他的职业路线大体是这样的：先是做了声乐老师，之后在2017年前后开始写代码，接着加入了Stately，成为了XState core team的成员，再之后去了Vercel，开展Turborepo相关的工作，随后出来创办了Total TypeScript，现如今则在做AI Hero，专门研究工程师和AI搭档干活的相关内容。

他自己提及工程经验为“nearly a decade”。按照2017年开始编写代码来计算的话，到2026年大概有9年的时间，并不是所谓的“十几年老工程师”。

他开源这套 skills，让人信服的缘由特简单：这是他自己天天在用的东西，不是”我觉得你们应该试试”那种理论。在开发者圈子当中，这个区别可太大了。

五、效果到底怎么样

说句实在话：目前没有公开发表的对照实验，能证明用了这套 skills 之后代码可维护性真的变好了。

我在 GitHub issues、Reddit 以及 X 上面翻找了一番用户反馈，能够找到的全都是零零散散的个人体验：有人提到“grill-me 问出了我三个没料到的边界条件”，有人表示“tdd 帮我揪出了一个由重构带来的回归 bug”，还有人说“走完整套流程的速度太慢了，对于小项目来说并不划算”。

这些，都属于感受，而并非数据。 Pocock 自己在 AI Hero 网站上也没有给出什么量化的效果对比。他所展示的是设计逻辑以及工作流的演示，也就是告诉你这个东西要怎么去使用，而不是拿数据来砸你脸以说服你。啥意思呢？意思是你读这篇文章的时候，得自己判断：这套流程的设计逻辑，对你成不成立。

啥意思呢？意思是你在阅读这篇文章的时候，得自己去做出判断：也就是这套流程的设计逻辑，对你来说成不成立。要是你的项目已经在承受“代码能跑但改不动”的苦头，那流程约束在逻辑上是对症的——毛病出在缺乏规范，方案就是补上规范。但要是你最头疼的是AI生成的代码本身质量差、bug多，那模型能力可能才是你更该关注的方向。

流程改善所针对的是可维护性，而非代码本身的质量。除此之外，就算流程在逻辑上对症，实际效果也得看执行的质量。skill 所保证的是 AI 不会跳步骤，并不会保证每一步都做对——这个区分在第三节已经聊过了，就不再重复了。

六、在哪些场景下不要去使用这套东西

任何方案都会有其边界所在。这套技能有几个显而易见不适合的场景。

第一，小活儿不值得上流程。 像是改个按钮颜色、修正拼写错误、添加一行日志这类工作，直接用正常的方式和Claude沟通就可以了。Pocock自己也在文档当中写明了这一点。流程本身是带有成本的，工作的体量越小，流程成本在整体当中的占比也就越高。

第二，管太死可能挡住更好的路子。 严格的流程会让AI在既定路线上走得稳稳当当，但也会让它不容易跳出路线去想到更妙的解法。要是你的项目还处于探索阶段，也就是需求还在变化、架构还没有确定的阶段，管得太紧可能会坏事。

第三，流程本身可能就有毛病。 让AI老老实实去走一个有缺陷的流程，最终得到的结果不会比没有流程的时候更好。流程的上限，决定了输出的上限。这套skills的流程是Pocock按照自己的经验来设计的，不一定契合你的项目、你的团队以及你的技术栈。

第四，第三节说过了，流程保证步骤不跳，不保证每一步正确。 这个边界，所有的skill都适用。

七、这件事真正值得琢磨的地方

不过，这套 skills 还有一层意思：它把”人管不住自己”这个老毛病，交给 AI 来治了。

TDD、PRD、ADR 这些道理，在软件工程领域当中已经被提及了少说十五年的时间。但真正老老实实按照这个要求去做的团队，永远是属于少数的那一部分。不是不清楚，是做不到。人会去赶进度、会偷懒、会觉得“这次情况特殊”、还会在压力下跳过那些“重要但不紧急”的步骤。人工智能在这方面比人类要强得多——不会因为快要下班了就跳过测试工作，不会因为功能较为简单就觉得“不需要撰写什么PRD”。当然，不跳步骤并不等同于每一步都能做到位。人工智能可能会撰写一份覆盖范围不全的测试内容，也可能搞出一份内容空洞的PRD。

但至少，步骤还是存在的。要是有了步骤，你就拥有了检查的抓手，也就是可以去看测试写得对不对，还可以去修改 PRD 的内容。而不是面对一个跳过了所有流程、直接生成的代码库，连从哪开始进行检查都不知道。换个角度来看这个结论也同样成立：要是你本身就是一个能够踏踏实实开展TDD、撰写PRD、记录ADR的工程师，那么这套skills对你而言，带来的增量并没有那么大。它最大的受益者，其实是那些清楚知道该去做什么但却没办法做到的人。在我接触过的工程师当中，这类人占据了多数。当然，这仅仅只是我个人的观察结果，并非是什么正式的统计数据。还有一件事值得彻底讲清楚。

这套方案治不了上下文窗口的毛病——这是正确的，对话当中出现的遗忘问题它没办法管控。但它从另外一个角度来缓解了这个问题：把上下文外化到文件当中，让新的对话可以实现重建。

PRD 把相关的需求给记录下来，ADR 把所做的决策给留存下来，CONTEXT.md 把项目的相关规范给固定下来——这些文档不只是流程的输入内容，它们本身也就是上下文的外化形式。

流程让 AI 不跳步，文档让遗忘变得能恢复。 两样东西合在一起，才是一套完整的协作方案。

八、怎么开始

你要是平时就用 Claude Code，而且项目有一定复杂度，可以试试。别全装。先挑两三个跟你最头疼的问题相关的 skill。

Pocock 现在推荐的编码流程是：