我给 codex 装的最有用的 skill，是反过来盘我的

装完 codex，很多人在输入框里敲的第一句话是这样的：帮我做个 XX 网站。

然后就开始来回改。改到第五轮的时候，你会发现它已经忘了你第一轮说过什么，上下文里塞满了各种修正记录，它反而更糊涂了。

最近一月我用 codex 用得挺凶的，累计 66.7 亿 token，单日峰值 10 亿，最长的一个任务跑了 2 小时 27 分，连着 32 天没断过。（在此跪谢tibo的重置）

我的 token 使用情况

烧了这么多量，我最大的体会是，codex 写得差，很多时候问题不在模型，在开局那句话太空了。

这篇就说说装完 codex 之后我最后留下来的 5 个 skill，以及它们串起来的一条完整开发流程，安装命令我放在最后，可以直接抄。

先说说大家会走的那条弯路。

帮我做个网站这句话，你自己脑子里其实是有画面的，用什么框架、数据存哪、登录怎么做、哪些功能这版先不做，这些你都想过。但你一个字都没说。

codex 只能猜。

它猜的版本和你脑子里的版本大概率对不上，你就开始改。改需求这个动作很消耗，因为你不是在补充信息，你是在纠正它已经写下的东西。改到后面，代码里一半是它的理解，一半是你的补丁。

进阶一点的人会去装superpowers。

obra/superpowers 仓库数据

258k star，23k fork，43 个贡献者，数据非常吓人。它的自我介绍是一套 agentic skills 框架加软件开发方法论。

superpowers 仓库结构

点进仓库你就明白框架这两个字的分量了。hooks、scripts、skills、tests、各家平台的 plugin 目录，claude、codex、cursor、kimi、opencode 全都单独适配了一套，光 commit 就 628 个。

它是把一整套开发方法论打包塞给你。

好处很明显，全。坏处也很明显，重。你只是想改个小需求，它也要拉着你把整套规矩走一遍。我用下来的感觉是，这套东西更适合团队去落地规范，个人开发者装上会有点被绑住。

真正在我这留下来的，是另一个东西。

The /grill-with-docs Skill

grill-with-docs，作者是 Matt Pocock，前端圈子里应该不少人认识他。

这个 skill 干的事只有一件：在你写任何代码之前，一次只问你一个问题，往死里追问，直到你和它对同一件事的理解完全对齐。

grill-with-docs 官网说明

grill 这个词本身就是拷问、盘问的意思，命名很直白。

但追问本身不稀奇，你自己写一段提示词让 AI 多问几句也能做到。它真正值钱的地方在后半句：追问完不蒸发。

官网的说法是，普通的追问只会让你当下的思路变清晰，然后随着会话结束一起蒸发掉，对齐只活在你自己脑子里。

grill-with-docs 会一边问一边往你仓库里写东西。聊定的术语，当场写进根目录的CONTEXT.md词汇表；那些难以反悔的一次性决定，写成 ADR 落到docs/adr/目录下。两个文件都是懒加载，没聊出东西就不生成，不需要你提前搭架子。

下次你或者 codex 再进这个项目，共识是躺在文件里的，不用重新对一遍。

最让我意外的是这个 skill 本身的体量。它的 SKILL.md 全文就 7 行：

---

name: grill-with-docs

description: A relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.

disable-model-invocation: true

---

Run a `/grilling` session, using the `/domain-modeling` skill.

对面是 628 个 commit 的一整套框架，这边是 7 行。

顺带说一下最后那行disable-model-invocation: true，意思是模型不会自己去调用它，必须你手动敲/grill-with-docs才会启动。这个设计我觉得挺对的，需求对齐这种事，得你主动开口。

两个东西怎么选，我的判断是这样。

Skills for Real Engineers

Matt Pocock 在仓库 README 里写得很清楚，他说 GSD、BMAD、Spec-Kit 这类方案是想帮你接管整个流程，但接管的同时也拿走了你的控制权，出了 bug 很难查。他这套 skill 的设计目标是 small、easy to adapt、composable，小、好改、能拼，配任何模型都能跑。

所以想要一整套现成的团队规矩，上 superpowers；卡在需求说不清楚这一步，先装 grill-with-docs 就够了。

而且 grill-with-docs 只是个开场。真正好用的是它后面接的那条链路。

mattpocock/skills 仓库

180k star，同一个仓库里还有另外四个 skill，五个连起来是一条完整的开发流程：

grill-with-docs→to-spec→to-tickets→implement→code-review

to-spec的特点是不再问你问题。它直接把你刚才聊定的东西合成一份 spec，也就是大家熟悉的 PRD，内容包括问题陈述、解决方案、用户故事清单、已经拍板的实现决策、测试方案，以及明确不做的范围。写完自动发到项目的 issue tracker 上，打好 ready-for-agent 标签。

to-tickets负责把 spec 拆成一张张任务票。这里有个细节我很喜欢，它拆的是竖切，官方叫 tracer bullet，每张票都贯穿数据库、接口、界面、测试全链路，能单独跑起来单独演示。不是那种先把所有后端写完再动前端的横切法。每张票还会标好自己被哪些票卡着。

implement只管执行，不管决策。照着 spec 和票干活，能用 TDD 的地方走 TDD，中途定期跑类型检查和单个测试文件，最后跑一遍完整测试套件，干完自动触发 code-review 并提交到当前分支。

code-review是两条轴分开审。一条看规范，代码符不符合这个仓库文档化的编码标准；一条看需求，有没有忠实实现对应 issue 的要求。这两条轴跑在各自独立的子 agent 里，结果分开报，不合并。

为什么不合并，官方的解释我觉得挺有道理：一份代码可能规范上挑不出毛病但根本没做对需求，也可能需求做对了代码写得一塌糊涂，混在一起报会互相掩盖。

一圈走下来，你的角色变了，以前是在后面改 AI 写的代码，现在是在开工前把话说清楚。

最后说怎么装。

Build skills

codex 现在原生支持 skills，敲$就能唤起 skill 选择器，装好的都在这里面。

codex 的 skill 选择器

安装 grill-with-docs 的命令是这一条：

npx skills add mattpocock/skills --skill=grill-with-docs

更新用这条：

npx skills update grill-with-docs

另外四个把--skill=后面换成to-spec、to-tickets、implement、code-review就行。仓库地址是github.com/mattpocock/skills，装之前可以自己进去对一眼，我不建议闭着眼睛往自己项目里装任何东西。

装完之后建议先只用 grill-with-docs 跑一个小需求，感受一下被追问是什么体验。说实话第一次会有点烦，它是真的一个问题一个问题往下钻。但被钻完你会发现，很多你以为自己想清楚了的地方，其实全是模糊的。

我自己的体感是，让 AI 写代码的门槛已经基本没有了，门槛挪到了你能不能把一件事说清楚。以前这个能力叫沟通，现在它直接决定你的产出质量。

文章来自于"AI产品普洱"，作者 "AI产品普洱"。