事情是这样的。
这段时间你如果混 AI 编程圈，真的很容易产生一种错觉。
好像大家聊来聊去，聊的永远都是模型。谁的上下文更长，谁的代码生成更猛，谁的 Agent 更像人，谁又在 benchmark 上把谁狠狠干翻了。刷久了你会觉得，软件开发这件事，离被彻底自动化，好像就差下一个版本号。
但我自己的感受是，不太对。
不是模型不强。坦率的讲，今天不管是 Claude Code、Codex，还是其他几家能打的东西，单看局部能力，已经强到有点离谱了。补函数，改样式，读报错，写测试，做一点中等复杂度的重构，很多时候已经不是能不能做的问题了，而是做得有多稳。
真正让我经常一声叹息的地方在别处。
就是你把这些东西真的丢进日常开发里，丢进真实仓库里，丢进一堆历史包袱、一堆业务约束、一堆 git 风险的环境里，它突然又没那么神了。经常一上来就写，写着写着方向歪了。修个 bug，最后改出一串连锁反应。让它拆任务，拆成一堆看着很勤奋其实根本没法落地的东西。你如果没盯紧一点，它连仓库都敢给你整出点事故来。
这个时候你回头看，会发现问题很多时候不是模型不够强。
而是你没有一套工作流去约束它。
这篇文章会讲什么
这篇文章我想聊三件事。
- 为什么很多 AI 编程翻车，锅并不全在模型
- Matt Pocock 的
skills仓库，到底把什么东西讲明白了 - 如果你今天就想上手，普通开发者最值得先抄的那条最小工作流是什么
我最近研究了一下 Matt Pocock 的那个 skills 仓库，看到 README 的时候，我当时就愣住了。
不是因为它又发明了什么神奇 prompt。
而是因为它在做一件更重要的事，它在把一个成熟工程师平时怎么做事，拆成一块一块可以复用的 skill。你可以把它理解成，过去很多只存在于 senior 工程师脑子里的流程经验，现在开始被显式化了，被模板化了，被工程化了。
这玩意很重要。
问题很多时候不在模型，在流程
因为很多人现在对 AI 编程的理解，还停留在一个很早期的阶段。觉得我只要会提问，会下指令，会写 prompt，就能把 AI 用起来。你当然能用起来，我也非常理解这种感觉，刚开始大家都是这么玩的，谁没经历过那个阶段呢。
但你真写一阵子代码就会发现，prompt 顶多解决的是一次对话里的表达问题。
真正决定你能不能稳定出活的，是流程。
你是先想清楚再写，还是想到哪写到哪。你是先把需求捋顺，还是直接把一个模糊念头塞给模型。你是让它一把梭生成五百行，还是逼着它一小块一小块交付。你有没有护栏，出了问题怎么回滚，需求变了怎么拆，测试怎么补，风险怎么控。回到 AI 编程这块，真正拉开差距的，就是这些东西。
Matt 这个仓库打动我的地方就在这。
它没有把 skill 写成一堆杂乱小技巧，而是隐隐约约给你画出了一张流程图。
你在需求还模糊的时候，用 to-prd，先别急着写代码，先把当前对话收束成一个 PRD。你在方案感觉心里没底的时候，用 grill-me，让 AI 反过来像审问犯人一样拷问你，把那些你以为自己已经想明白、其实根本没想明白的角落都翻出来。你在准备开工的时候，用 to-issues 把一个大任务拆成真正能抓、能做、能验收的小切片。等到了实现阶段，再交给 tdd，按红绿重构的节奏一点点推进。然后在 git 层面，先用 git-guardrails-claude-code 把最危险的坑给堵上，别等 AI 把你分支狠狠干碎了才想起来装护栏。
你看见没有，这已经不是在教模型回答问题了。
这是在给模型安排工位。
说真的，这里面最值得普通开发者抄回去的，不是某一个具体 skill 有多神，而是这套顺序感。
很多朋友可能不知道，自己之所以老觉得 AI 编程不稳定，恰恰是因为顺序是反的。
需求没清楚，先写。
边界没搞懂，先改。
任务没拆开，先让它大包大揽。
测试没想好，先生成。
git 护栏没装，先放它操作仓库。
然后翻车了，大家开始怪模型。
不是哥们，你这流程本身就很容易翻啊。。。
Matt 这个仓库真正厉害的地方
如果你让我用一句话总结这个仓库，我会这么说。
它不是在教模型怎么回答问题，它是在教工程师怎么给模型安排工作。
所以如果你今天就想把这个仓库的思路用起来，我其实不建议你一口气全装，也不建议你把 README 从头背到尾。那样很容易又回到一种收集工具的幻觉里，觉得自己学了很多，实际上一个都没落地。
我更推荐一个最小闭环，真的就够了。
一条普通开发者可以直接照抄的最小闭环
如果你今天就想开始，不用全学，先把这五步跑顺。
- 需求收束，
to-prd - 方案拷问，
grill-me - 任务拆分，
to-issues - 受控实现，
tdd - 风险护栏，
git-guardrails-claude-code
回到这块，真正值钱的不是某个单点技巧，而是这五步连起来以后，AI 编程终于开始像工程，而不是像碰运气。
1. 先装 to-prd
命令很直接。
npx skills@latest add mattpocock/skills/to-prd
这个东西适合什么场景呢。
就是你脑子里已经有一个功能想做了，也和同事聊了一轮，甚至开了几次会，但整个东西仍然是散的。每个人都觉得自己懂了，真让谁写下来，又都说不完整。这个状态特别常见，尤其在小团队里，大家很容易用口头默契代替正式需求。
这时候你别急着开写，把当前上下文交给 to-prd，让它先帮你收束。你会发现很多原来模模糊糊的东西，突然有了边界。要做什么，不做什么，用户是谁，成功标准是什么，都开始变得像话了。
这一步看起来慢，其实是最快的。
因为它帮你避免了后面那种最烦的返工，写了半天，发现大家理解的根本不是一回事。
2. 再装 grill-me
npx skills@latest add mattpocock/skills/grill-me
这个名字我挺喜欢的，很直接，就是狠狠干你。
很多时候我们不是没有方案，而是方案看着像有方案。你把它说出来，自己都觉得挺顺的，真到落地才发现一堆坑埋在底下。权限怎么处理，失败状态怎么算，老数据怎么迁移，边界情况谁兜底。平时如果没有一个经验很老到的人在旁边盯着你，这些问题很容易被跳过去。
grill-me 有点像给你临时拉来一个脾气不太好的技术负责人。
它不负责讨好你，它负责问到你烦。
但这种烦很有价值。因为很多项目最后延期，很多重构最后烂尾，很多功能上线后开始噼里啪啦出问题，根子都在这里，你以为想清楚了，其实没有。
3. 然后装 to-issues
npx skills@latest add mattpocock/skills/to-issues
这个 skill 我是真的觉得很实用。
太多人不是不会写代码，而是不会拆任务。一个需求摆在那儿，脑子里只有一个模糊的大山，根本不知道从哪一锹开始挖。于是最常见的动作就是，干脆让 AI 一口气给我搞完。然后生成出来一坨看似完整、实际很难接住的东西。
回到这块，任务拆分能力，比生成能力重要得多。
to-issues 的价值就在于，它逼你把大东西拆成一块一块垂直切片。每一块都最好能独立完成、独立验证、独立交付。你只要真这么拆过几次，就会明显感觉到，AI 好用太多了。因为它终于不需要面对一个模糊的大宇宙了，它只需要解决一个边界相对清楚的小问题。
4. 到了真正实现的时候，再上 tdd
npx skills@latest add mattpocock/skills/tdd
这个 skill 背后的判断，我一直觉得特别对。
很多人让 AI 写代码翻车，不是因为 AI 不会写，而是你给了它一种最容易失控的写法。上来就生成大段实现，没有测试，没有约束，没有反馈回路。看起来很快，实际上特别脆。稍微一改需求，或者你自己没审明白，后面就开始一路补洞。
tdd 这个节奏厉害在哪呢。
它不是让你显得很学院派，也不是为了追求某种仪式感。它是在给 AI 一个更短的反馈循环。你先让它面对一个具体的失败，再让它把这个失败修成通过，然后再整理代码。粒度一小，幻觉就少，偏航就少，连你自己 review 都轻松很多。
当然，这里我也得坦率的讲一句。
这一步一开始是会有点笨拙的。你会觉得，哎呀我直接让它写完不是更快吗，干嘛绕这么一圈。这个感受太正常了。我自己也一直觉得，很多好流程在刚上手的时候都不像捷径，甚至会让人有点烦。
但你跑过几轮真实需求就知道了，这种慢，是在买稳定。
5. 最后装 git-guardrails-claude-code
npx skills@latest add mattpocock/skills/git-guardrails-claude-code
这个我甚至觉得，应该优先级拉满。
因为前面那些 skill 主要是在提升质量，这个 skill 是在防事故。README 里写得很清楚，它是拿来拦危险 git 操作的，像 push、reset --hard、clean 这种高风险动作，先挡下来再说。
你敢信？？？
现在很多人已经开始让 Agent 直接在真实仓库里干活了，但连最基本的护栏都没装。这个状态有点像什么呢，有点像你刚学会开一台很猛的车，觉得油门真爽，然后安全带懒得系。
比较骚的事就在这，大家一边对 AI 抱有极大信心，一边又默认所有翻车都不会砸到自己头上。
这尼玛就是经典侥幸心理。
这五步为什么值得你先跑一遍
所以如果你问我，这个仓库最适合怎么开始，我的建议很简单，别全学，先照着这五步串一遍。
一个模糊需求进来，先 to-prd。
感觉方案不够实，立刻 grill-me。
准备开工前，to-issues 拆成切片。
进入实现，交给 tdd。
只要它碰 git，先把 git-guardrails-claude-code 装上。
你先跑通这一条线。
只要这一条线跑顺了，你对 AI 编程的感受会完全不一样。你不再是对着一个聪明聊天机器人碰碰运气，而是在跟一个被工作流驯化过的协作系统打配合。
说到这个，很多人会问，那我是不是也得像 Matt 一样，搞出一大仓库自己的 skills，才算真正入门。
我觉得不是。
普通开发者最容易掉进去的坑
普通开发者最容易掉进去的坑，就是一上来就想搭一整套宏大体系。今天写一个 skill，明天做一个框架，后天整一套方法论，搞得热火朝天，结果一个都没进入自己真实工作流。
反正我觉得，别贪。
你先抓一个你最痛的重复动作。
如果你每次都是需求不清楚就开写，那就先把 to-prd 用起来。
如果你每次都输在任务拆不动，那就先啃 to-issues。
如果你每次都在代码生成阶段翻车，那就狠狠干 tdd。
如果你已经吃过 git 的亏，那别犹豫，先上护栏。
一件一件来。
先把一个流程固化，再补第二个，再补第三个。你不需要先成为一个很会写 skill 的人，你只需要先成为一个肯老老实实沉淀流程的人。
而这恰恰是我看完这个仓库以后，最受触动的地方。
最后想说的
以前大家总觉得，AI 编程拼的是谁更懂模型，谁更会写 prompt，谁更懂参数，谁更早拿到新工具。现在我越来越觉得，这些东西当然重要，但都不是最深的那层。
更深的那层是，你有没有把自己做事的方法，变成可以被复用的结构。
模型会越来越强，也会越来越像水电煤。今天领先一点，明天别人跟上，后天大家都差不多。可工作流不会。你怎么收束需求，怎么做设计审问，怎么拆切片，怎么控制实现节奏，怎么给仓库装护栏，这些经验一旦沉淀下来，就开始变成你自己的生产系统。
到那一步，AI 才不只是一个会回话的东西。
它开始像一个团队。
我自己也还在摸索，这套东西我也没有完全跑通。但至少看完 Matt Pocock 这个仓库以后，我有一个判断越来越强。
AI 编程真正缺的，不是再来一个更大的模型。
而是我们终于开始认真对待工作流了。
如果你现在还把 Claude Code、Codex 这些东西，当成一个随叫随到的聊天机器人，那它很快就会碰到天花板。你会觉得它有时候神，有时候蠢，有时候像天才，有时候像实习生。
可一旦你开始给它设计流程，安装护栏，定义节奏，明确交付边界，事情就不一样了。
你不是在使用一个模型。
你是在训练一套新的工程协作方式。
如果你真想在这波 AI 编程里把差距拉开，少盯一点排行榜，少焦虑一点模型版本，多花点时间，去沉淀你自己的工作流。
那玩意，才是真正能磨平一些信息差的东西。
文中 Skills 链接: github.com/mattpocock/…
