一、为什么 AI 写代码总是“差点意思”？

现在用 AI 辅助开发确实爽，但我也经常遇到一些让人头大的问题。有时候你觉得 AI 完全理解了你的意思，结果它写出来的代码完全跑不通；或者它写得太啰嗦，每次对话都要重新定义一遍项目里的术语；最糟糕的是，由于 AI 编码速度太快，如果不加约束，项目很快就会变成一坨难以维护的“面条代码”（Codebase Rot）。

最近我关注到 TypeScript 大神 Matt Pocock 提出了一个非常有趣的观点：AI 编程的失败模式，其实和人类开发者的失败模式非常相似。针对这些痛点，他做了一个名为 Skills For Real Engineers 的项目，试图通过一套可组合的“技能指令”，把工程化的纪律性注入到 Claude Code 中。

我实测了一下，这套方案的核心逻辑非常清晰，它不是简单的 Prompt 堆砌，而是把软件工程的基本功（比如 TDD、ADR 等）封装成了 Claude Code 的插件。

二、快速配置：如何把这些技能加入 Claude Code

要使用这些技能，我个人最推荐直接使用 Claude Code 的插件安装方式，这样可以实现自动更新。

1、插件安装

在 Claude Code 终端中直接运行：

/plugin install mattpocock-skills

如果你想在项目中直接通过 npx 运行，或者想把这些技能文件直接拷贝进项目以便自己修改，可以使用：

npx skills@latest add mattpocock/skills

2、初始化配置

安装完成后，记得在每个新项目里执行一次初始化，这会帮你把 GitHub 或 Linear 等工具集成进来，并决定文档存放的位置：

/setup-matt-pocock-skills

三、核心技能实战：打造闭环工作流

这套技能集的核心价值在于，它把“需求对齐 $\to$ 计划拆解 $\to$ 迭代实现 $\to$ 自动化验证”这一套标准的工程流程，变成了一系列可以直接调用的指令。

我把它们整理成了下面这张工作流表，大家可以根据进度来调用：

阶段	核心指令	解决的问题	产出物
对齐阶段	/grill-with-docs	防止需求理解偏差	CONTEXT.md (术语表) + ADR (决策文档)
迭代阶段	/tdd	解决代码无法运行或逻辑回归问题	通过测试驱动的最小化实现
调试阶段	/diagnosing-bugs	解决难以复现的顽固 Bug	复现脚本 + 验证过的修复代码
流水线	/to-spec $\to$ /to-tickets $\to$ /implement	从对话到代码的标准化流转	Spec 文档 + Issue + 已测试提交

1、拒绝“猜”需求：/grill-with-docs

最让我惊喜的是 /grill-with-docs。以前我们跟 AI 交流，往往是“你猜我想做什么”，结果写出来完全不是一个味。

这个指令会像面试官一样，通过一系列问题“拷问”你，直到它完全搞清楚你的意图。它有两个很硬核的动作：

• 构建共享语言：它会识别出你项目里的专业术语，并自动更新到项目根目录的 CONTEXT.md 文件里。这样下次对话，AI 就不会再问你“什么是 X 模块”这种蠢问题了。

• 记录架构决策 (ADR)：当涉及到重大的技术选型时，它会自动生成 ADR 文档。这对于长期维护非常重要，以后不管是新加入的开发者还是未来的 AI，都能看到当初为什么要这么设计。

2、拒绝“写完就跑”：/tdd 与 /diagnosing-bugs

很多时候 AI 写完代码就直接收工了，根本不管能不能跑通。

• /tdd 指令：强制执行“红-绿-重构”循环。它会先写一个必失败的测试，再写实现代码，最后进行重构。这种“测试驱动”的思维能极大程度减少 AI 产生垃圾代码的概率。

• /diagnosing-bugs 指令：这是专门为“硬骨头” Bug 准备的。它会将调试过程规范化：先写复现脚本 $\to$ 最小化复现 $\to$ 提出假设 $\to$ 插入日志验证 $\to$ 最后修复并增加回归测试。这种“步步为营”的逻辑，比盲目修改代码要靠谱得多。

3、全自动流水线：从想法到 Commit

如果你想体验极致的自动化，可以尝试这个完整的 Pipeline：

1. /grill-with-docs：搞清楚我们要干什么，并建立术语表。

2. /to-spec：把刚刚的对话内容总结成一份标准的 Spec 文档。

3. /to-tickets：把 Spec 拆解成一个个具体的 Task 或 Issue。

4. /implement：这是终极指令。它会读取 Spec 和 Tickets，自动运行 /tdd 模式进行开发，并且在提交前进行双轴代码审查（Code Review）：

   • 标准轴：检查代码是否符合项目的代码规范。

   • 规格轴：检查代码是否真的实现了 Ticket 里要求的逻辑。

只有两个维度都通过了，它才会执行 git commit。

四、最后

我折腾了这么多 AI 辅助开发工具，发现真正的差距不在于 AI 的模型有多强，而在于我们能否给它套上“工程化”的缰绳。

Matt Pocock 的这套技能集，本质上是把人类工程师积累了几十年的实战经验（比如 TDD、ADR、Code Review）翻译成了 AI 能听懂的“操作手册”。如果你也觉得 Claude Code 偶尔会表现得像个没经验的新手，不妨试试这套方案。

当然，这种方式也会增加一定的初期沟通成本，但比起后期修复一堆逻辑混乱的垃圾代码，这笔时间投入是非常划算的。