不是“让AI写代码”，而是“和AI一起真正造软件”——Matt Pocock的Skills仓库让我彻底改观

大家用AI编码工具的时候，是不是经常遇到这种尴尬：代码看起来挺漂亮，功能也勉强跑得通，但稍微一改需求就崩了，或者过两个星期自己都看不懂当时是怎么想的？那种“vibe coding”的快感来得快，去得也快，最后留下一堆技术债。

Matt Pocock把他在实际项目里天天用的 .claude 目录整个开源了，就是这个 skills仓库。它不是一堆花里胡哨的超级提示词，而是一系列小巧、可组合、真正来自工程实战的“技能”。用起来像给AI请了一群靠谱的资深搭档，而不是让它替你当全能选手。

我特别喜欢它的定位：承认开发软件本来就很难。那些把整个流程全包的大框架虽然听起来省心，但一旦出问题，你连调试的机会都没有。Pocock的这些小技能却把控制权牢牢握在你手里，让你和AI的协作更有节奏感，也更可持续。

先把需求聊透，再动手

最常见的问题，其实是“你以为AI懂了，其实它根本没懂”。Pocock把这个叫 misalignment。解决办法就是一个“grilling”（ grilling session）过程。/grill-me 或者更强大的 /grill-with-docs，会像一个挑剔的资深工程师一样，不断追问你，直到每一个假设都说清楚。

我自己试过之后发现，这一步花的时间越多，后面的返工就越少。它不光问功能，还会帮你梳理模块边界、思考边缘情况。尤其是 /grill-with-docs，它会同步维护一个 CONTEXT.md 文件，把项目里的专有名词、难解释的决策都记录下来，形成一套“通用语言”。以后AI跟你聊天时，就不再用一堆泛泛的描述，而是直接说“materialization cascade出了问题”，一句话顶以前一大段。普通人用着觉得顺手，技术人会发现这其实是领域驱动设计（DDD）的落地实践。

代码不光要写出来，还要能活下去

需求对齐了，代码还是可能写成一坨。AI速度太快，熵也增加得特别快。Pocock的应对方式是把经典工程实践嵌入到技能里。

比如 /tdd 会严格走红-绿-重构循环：先写失败的测试，再让代码通过，最后清理。/diagnose 则提供一套纪律严明的调试流程——复现、最小化、假设、检测、修复、回归测试。不是什么新发明，但让AI每次都按这个节奏来，代码质量就完全不一样了。

更让我有感触的是他对架构的重视。仓库里有 /zoom-out 让AI从系统全局视角解释代码，有 /to-prd 把聊天内容变成规范的产品需求文档，还有定期运行的 /improve-codebase-architecture。它会主动寻找“深化机会”——把浅薄、脆弱的模块变成更深、更专注的模块，用干净的接口把复杂性藏起来。

很多人在AI加持下疯狂出货，却没意识到代码正在快速腐化。Pocock提醒我们：速度越快，越需要每天都关心设计。这不是在拖慢进度，而是在让进度真正有意义。

小技能，大灵活性

这个仓库最舒服的地方在于“轻”。你不用一次性装全部东西。运行一句 npx skills@latest add mattpocock/skills，选好需要的技能，再跑一次 /setup-matt-pocock-skills 配置好 issue tracker 和文档位置就行了。之后在和AI聊天时，直接输入 /grill-with-docs 或者 /tdd 就能触发对应流程。

里面还有些生产力小工具，比如 /caveman 能把对话压缩到极致，省 token；/handoff 把当前对话整理成清晰的交接文档，让另一个AI无缝接手；/prototype 快速做一个可扔掉的原型来验证想法。这些对普通用户也非常友好，不写代码的人也能用它来梳理思路、整理文档。

真正的洞察：AI时代，基本功反而更重要

用过这些技能后，我越来越觉得：AI不会让软件工程变简单，它只是把“执行”的成本大幅降低，把“思考”和“判断”的权重拉得更高。那些经典著作里的智慧——《程序员修炼之道》、《领域驱动设计》、《软件设计的哲学》——在AI时代不但没过时，反而成了决定你能走多远的真正护城河。

Pocock的Skills就像一套桥梁，把这些经典思想变成了AI能听懂、可重复执行的日常习惯。它不会帮你偷懒，而是帮你把精力集中在真正该由人决定的地方。

仓库地址在这里：https://github.com/mattpocock/skills，MIT协议，README写得非常清晰，建议大家直接去看看。无论你是刚入门想用AI提高效率的普通开发者，还是已经在大型项目里和AI并肩作战的老兵，都能从中找到立刻能用的东西。

真正厉害的不是AI写代码，而是你和AI一起，造出经得起时间考验的软件。