欢迎关注微信公众号:FSA全栈行动 👋
一、为什么 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
三、核心技能实战:打造闭环工作流
这套技能集的核心价值在于,它把“需求对齐 计划拆解 迭代实现 自动化验证”这一套标准的工程流程,变成了一系列可以直接调用的指令。
我把它们整理成了下面这张工作流表,大家可以根据进度来调用:
| 阶段 | 核心指令 | 解决的问题 | 产出物 |
|---|---|---|---|
| 对齐阶段 | /grill-with-docs | 防止需求理解偏差 | CONTEXT.md (术语表) + ADR (决策文档) |
| 迭代阶段 | /tdd | 解决代码无法运行或逻辑回归问题 | 通过测试驱动的最小化实现 |
| 调试阶段 | /diagnosing-bugs | 解决难以复现的顽固 Bug | 复现脚本 + 验证过的修复代码 |
| 流水线 | /to-spec /to-tickets /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准备的。它会将调试过程规范化:先写复现脚本 最小化复现 提出假设 插入日志验证 最后修复并增加回归测试。这种“步步为营”的逻辑,比盲目修改代码要靠谱得多。
3、全自动流水线:从想法到 Commit
如果你想体验极致的自动化,可以尝试这个完整的 Pipeline:
-
/grill-with-docs:搞清楚我们要干什么,并建立术语表。 -
/to-spec:把刚刚的对话内容总结成一份标准的Spec文档。 -
/to-tickets:把Spec拆解成一个个具体的Task或Issue。 -
/implement:这是终极指令。它会读取Spec和Tickets,自动运行/tdd模式进行开发,并且在提交前进行双轴代码审查(Code Review):-
标准轴:检查代码是否符合项目的代码规范。
-
规格轴:检查代码是否真的实现了
Ticket里要求的逻辑。
-
只有两个维度都通过了,它才会执行 git commit。
四、最后
我折腾了这么多 AI 辅助开发工具,发现真正的差距不在于 AI 的模型有多强,而在于我们能否给它套上“工程化”的缰绳。
Matt Pocock 的这套技能集,本质上是把人类工程师积累了几十年的实战经验(比如 TDD、ADR、Code Review)翻译成了 AI 能听懂的“操作手册”。如果你也觉得 Claude Code 偶尔会表现得像个没经验的新手,不妨试试这套方案。
当然,这种方式也会增加一定的初期沟通成本,但比起后期修复一堆逻辑混乱的垃圾代码,这笔时间投入是非常划算的。
如果文章对您有所帮助, 请不吝点击关注一下我的微信公众号:FSA全栈行动, 这将是对我最大的激励. 公众号不仅有Android技术, 还有iOS, Python等文章, 可能有你想要了解的技能知识点哦~