AI 编程助手越帮越乱?93K Star 的解法,来自 TypeScript 圈最硬的那个人

↑阅读之前记得关注+星标⭐️，😄，每天才能第一时间接收到更新

大家好，我是杰克王，AI 算法 6 年老兵。

你有没有遇到这种情况：让 Claude 或 Copilot 帮你写功能，它噼里啪啦写了一大堆，你一看，完全不是你想要的东西。

重新说一遍，它又误解了。再来一遍，还是跑偏。

最后你发现，自己花在"纠正 AI"上的时间，比直接自己写还多。

今天我要介绍一个项目，能直接解决这个问题。不是什么神奇的大模型，就是 28 个 Markdown 文件。截至 2026-05-19，它在 GitHub 上攒了 93,209 颗 Star，从建立到现在刚好 3 个半月。

项目地址：https://github.com/mattpocock/skills^[1]

项目描述：Skills for Real Engineers. Straight from my .claude directory.

先说说作者是谁。

Matt Pocock，TypeScript 圈里最硬核的教育者，Total TypeScript 创始人，曾任职 Vercel 和 Stately，GitHub 上 17,000 多人关注他。他出品的 TypeScript 教程在开发者圈子里几乎是"必学"级别的，60,000 名开发者订阅了他的 newsletter。

这次他不是出了一个课程，而是把自己 .claude 目录里每天真实在用的 skill 文件全部开源了出来。原话是："My agent skills that I use every day to do real engineering - not vibe coding."

这句话值得多读一遍。Real engineering，不是 vibe coding。

什么是 vibe coding？就是"感觉上"在用 AI 写代码，实际上在用 AI 凑出一坨能跑但没人懂的代码。Matt 设计这套 skills 的出发点，是让 AI 成为真正的工程搭档，而不是只会堆代码的工具人。

AI 编程为什么经常越帮越乱？Matt 总结了 4 个根因。

失败模式 1：AI 根本没搞清楚你想要什么

这不是 AI 的错，是人类的通病。连《The Pragmatic Programmer》都说："No-one knows exactly what they want."

你觉得你说清楚了，AI 理解的却是另一回事。等你看到输出，才发现中间有个巨大的认知鸿沟。

解法是 /grill-me 和 /grill-with-docs——让 AI 在动工之前主动质问你，把每个设计分支的每个决策都理清楚。这个过程有点像被"审讯"，但比事后翻工省多了。

（顺便一提，Issues 里有个帖子叫 "Codex just asked me 200 questions"（11条评论），用户崩溃地说 Codex 用 grill-me 之后一口气问了他 200 个问题。另一个人回复："我在第26个问题就已经精力耗尽了，每个问题都需要认真思考……"

Matt 本人出来回复说："记住，你是主导者，不是被考试的那个。把问题当作补充信息的提示，不是审讯。"

这个场景太真实了。）

失败模式 2：AI 用 20 个词表达本来只需要 1 个词的概念

每次新会话，AI 都是陌生人，得从零理解你项目的"黑话"。它不知道你的"materialization cascade"是什么，就会用一大段白话文描述同一件事。

解法是 CONTEXT.md——用 /grill-with-docs 在和 AI 对话的过程中逐步建立一份共享语言词汇表。

效果：变量、函数、文件名全部按共享语言命名；AI 思考时消耗的 token 更少；代码库导航更顺畅。

失败模式 3：代码跑不通

对齐了需求，写出来还是烂的。

原因是缺反馈回路。AI 在"飞盲"——它不知道代码实际跑起来是什么效果。

解法是 /tdd——强制 TDD 红绿重构循环。AI 先写失败测试，再修复，再重构。有了即时反馈，代码质量会明显上一个台阶。

还有一个 /diagnose 用于调试：复现 → 最小化 → 假设 → 验证 → 修复 → 回归测试，一套成熟的 debug 流程封装成了 skill。

失败模式 4：代码越堆越乱，改动一处牵动全局

AI 加速了编码，也加速了代码腐烂。没有人管设计，一个月后你面对的就是一坨泥球。

解法是 /improve-codebase-architecture 和 /zoom-out。前者定期帮你找代码深化机会，后者让 AI 在修改局部代码时先做系统级解读，防止因视野太窄把整体搞乱。

Matt 的建议：每隔几天跑一次 /improve-codebase-architecture，就像给代码做定期体检。

28 个 Skills，怎么用？

仓库里有 28 个 skill 文件（截至 2026-05-19），分三类：

推荐的端到端工作流（Issues #23 讨论里有人总结过）：

/grill-me（明确需求）→ /to-prd（生成需求文档）→ /to-issues（拆分成独立 issue）→ /tdd（逐个开发）→ /improve-codebase-architecture（定期重构）

这条链路里每一步都有 skill 托底，不再靠运气。

安装只需 30 秒：

npx skills@latest add mattpocock/skills

运行后选你想装的 skills 和想用的编程助手（Claude Code、Codex 等），再在助手里执行一次 /setup-matt-pocock-skills，就完成了。它会问你用的是哪个 issue tracker（GitHub / Linear / 本地文件），设置好后所有 skills 就能联动起来。

还有一个我很喜欢的细节：/caveman 这个 skill，通过极度压缩通信语言，把 AI 的 token 消耗减少约 75%，同时保持技术准确性。省 token 就是省钱，这个设计很实用。

一个很有意思的 Issues

闭合 Issues 里有一条："Why does this have so many stars?"（5条评论）

提问者说："这不就是一堆 .md 文件吗？GitHub Star 的含金量去哪了？"

这个问题本身就是最好的答案。

一堆 .md 文件，3 个半月 93K Stars，8,190 个 Forks。不是因为技术有多复杂，是因为它解决的是每一个用 AI 写代码的人都踩过的坑。

AI 编程助手的问题从来不是"不够聪明"，而是"流程不对"。你不设计流程，AI 就自己发明流程，发明出来的东西可能一塌糊涂。这套 skills 本质上是把成熟工程实践（TDD、DDD 的 ubiquitous language、红绿重构循环）翻译成了 AI 能直接理解的指令文件。

用 Matt 的话说："Software engineering fundamentals matter more than ever." 软件工程基本功在 AI 时代比以往任何时候都重要。只不过执行层变了——现在是 AI 在执行，但你设计的那套流程不能少。

项目链接：https://github.com/mattpocock/skills^[2]

作者 newsletter（60,000 开发者在订阅）：https://www.aihero.dev/s/skills-newsletter^[3]

有兴趣的直接去仓库，30 秒安装，先跑一遍 /grill-me 感受一下被 AI 审讯是什么体验 🔥

觉得有收获，点个在看支持一下 👇 感谢阅读。我是杰克王，欢迎加微：2831062189交流 🚀

引用链接