为什么你的AI编程越用越乱?Matt Pocock的21个Markdown文件说出了真相

你有没有过这种体验：

用 Claude/GPT 写代码，开头很爽，十几分钟一个功能出来了。然后你想改点东西，AI 给出的代码开始不对劲了。你解释，它改，改完又引入新 bug。来回几个回合，你发现代码已经变成了一团没有人看得懂的东西——包括 AI 自己。

这时候你面临一个选择：继续修，还是删掉重写？

大多数人选了后者。然后循环继续。

问题出在哪？ 不是模型不够强，是你没有一套让 AI 真正"理解你在做什么"的方法。

🛠️ 一个让人拍大腿的开源项目

2026 年 3 月，TypeScript 社区的"老熟人" Matt Pocock（Total TypeScript 的作者）做了一件有意思的事：

他把自己平时在 Claude Code 里用的 .claude/skills 目录，原样推到了 GitHub。

没有花哨的多 Agent 编排，没有复杂的框架，整个仓库 只有 21 个 Markdown 文件。每个文件就是一段写给 Claude Code 的"工程原则提示词"。

结果一夜之间冲上 GitHub Trending #1，目前 143K Star。

第一次看到这个仓库的时候，我以为又是一个"AI 全自动开发框架"。点进去发现——压根不是。

它做的事情很简单：把工程师几十年来踩过坑、也救过命的几个"小动作"，每一个都做成一段提示词，让 AI 也能执行。

💡 AI 编程的四个本质痛点

GitHub Stars: 49.8k+ | 开源协议: MIT

Matt 在 README 里直接说了一句很狠的话：

"那些全包式框架本质上是把开发流程从你手里抢走了。一旦流程出 bug，你连改的地方都找不到。"

他给出的解法不是"做一个更大的框架"，而是围绕四个老掉牙却始终最致命的问题，每个都做一个可组合的 Skill。

痛点一：AI 没听懂你在说什么

最常见的 AI 编程失败模式就是：你以为你说清楚了，AI 以为它听懂了，等代码出来发现完全是两回事。

Matt 的解法很反直觉：在写代码前，先让 AI 反过来"拷问"你。

两个核心 skill：

· /grill-me —— 用于非代码类决策

· /grill-with-docs —— 代码场景的拷问 + 顺手更新领域文档

核心是：不让 AI 直接开始写代码，而是先强迫你把需求说清楚。

我自己的经验是，每次跑 /grill-with-docs，AI 问的问题都会暴露出我原本没想清楚的地方。等拷问完了，代码怎么写其实已经很清楚了。

痛点二：AI 太啰嗦，变量名乱起

AI 之所以啰嗦，是因为它进入项目时不懂你们团队的"行话"。所以它会用 20 个词描述一个概念，而你们内部一个词就够了。

Matt 给了一个具体例子：

优化前：There's a problem when a lesson inside a section of a course is made 'real'

优化后：There's a problem with the materialization cascade

一旦你和 AI 共享了一份 CONTEXT.md（领域语言词典），每个 session 都能省下大量 token，变量名、函数名、文件名也会自动变得一致。

这不是小问题。代码的一致性，直接决定了一个项目能不能长期维护。

痛点三：AI 写出的代码不 work

AI 写出 bug 不是模型问题，是反馈环没建立。

没有类型检查、没有自动化测试、没有实时验证，AI 就是闭眼开车。

对应的 skill 是 /tdd——但它做的 TDD 和你想象的可能不一样。

绝大多数所谓的"AI TDD"都是水平切片：先把所有测试写完，然后让 AI 把所有实现一次性写出来。Matt 直接把这种做法标成 anti-pattern。

他坚持的是垂直切片：写一个测试 → 让它通过 → 再写下一个测试。每次只走一小步，但每一步都是确定性的。

痛点四：项目变成大泥球

AI 让你写代码的速度提升 5 倍，也让代码烂掉的速度提升 5 倍。

Matt 的解法是把"关心架构"这件事做进每一层 skill。最重要的是：这些不是一次性动作，而是周期性习惯。就像你每隔几天要清理一下桌面一样，你的代码库也需要定期"修剪"。

🔍 为什么这套 Skills 比大多数框架更有用？

现在市面上有很多 AI 编程框架：GSD、BMAD、Spec-Kit、Superpowers……它们都很厉害，但有一个共同问题：它们在替你做决定。

· GSD：接管 context window，自动管理长任务 —— 你失去了流程控制权

· BMAD：模拟一支虚拟敏捷团队 —— 太重，小项目杀鸡用牛刀

· Superpowers：强制 TDD 纪律 —— 单 orchestrator 在长 session 里 context 会爆

· mattpocock/skills：不接管流程，给你工程基本功 —— 你需要知道自己在做什么

Matt 的 skills 最打动我的地方是：它没有取代我的判断，而是把我十几年来好不容易养成的习惯固化成了 AI 也能执行的提示词。

当我说 /grill-with-docs 的时候，我清楚地知道接下来会发生什么、为什么这么做、出问题该怎么改。

这种"可控感"，是其他框架给不了的。

💡 写给你的：从哪里开始？

如果你今天只想记住一件事，那就是：

AI 不是来替你做工程师的，是来放大你工程能力的。但前提是——你得真的有工程能力。

具体怎么做？我的建议是：

· 第一步：先装 grill-with-docs、tdd、diagnose 三件套

· 第二步：坚持每次写代码前先跑 /grill-with-docs

· 第三步：学会用垂直切片的方式拆任务

· 第四步：定期跑 /improve-codebase-architecture

📝 写在最后

Matt Pocock 的这套 skills 火了之后，很多人说"原来 AI 编程的秘诀就是写好提示词"。

不对。真正的秘诀是：你得先知道什么是好的工程实践，然后才能让 AI 帮你执行。

AI 不会替你成为更好的工程师。但它可以让一个已经有工程基本功的人，把能力放大 10 倍。

这就是我觉得这套 skills 最值得细读的原因——它不教你如何用 AI，它教你如何做一个能被 AI 放大的工程师。

架构前线 — 发现好工具，提升开发效率。