ARTICLE · 1087744
别急着让 AI 开工:先用 Codex 的 Grilling Skill 把想法问到站得住
Grilling 的目标不是否定你的想法，而是在投入时间写代码之前，把那些没有说出口的假设逐个找出来。
大多数 AI 擅长回答问题，但真正昂贵的错误，往往来自一开始没有问对问题。
假设你告诉 Codex：
我准备给团队做一个日志分析工具。开发者上传应用日志后，系统自动定位性能瓶颈并给出原因。
普通 AI 很可能马上给出技术架构、日志解析流程、异常检测模型，甚至直接开始生成项目代码。
这些内容看起来很完整，却可能建立在一连串没有验证的假设上：
谁会在什么故障场景下使用它？ “定位性能瓶颈”具体是找出慢接口、异常调用链，还是判断根因？ 系统必须支持哪些日志格式和调用链信息？ 生产日志中的账号、请求参数和业务数据怎样脱敏？ 怎样证明它比现有监控告警更快、更准确？
AI 的执行速度越快，这些问题越危险。方向错了，AI 只会帮你更快地走远。
这正是 grilling Skill 想解决的问题：在实施之前，让 Codex 先成为一个不轻易点头的合作者。
一、Skill 到底是什么？
OpenAI 官方把 Skill 定义为一组指令和资源，用来教 ChatGPT 或 Codex 完成某种可重复的工作流。一个 Skill 至少包含一个 SKILL.md，其中写明名称、触发条件和具体流程，还可以附带参考资料、脚本、模板和其他资源。
参考：OpenAI Skills 概念文档
因此，Skill 不是一个新模型，也不一定需要调用外部服务。它更像给 Agent 安装了一套稳定的做事方法。
例如：
代码审查 Skill 规定先检查哪些风险、怎样组织结论； 博客写作 Skill 规定文章结构、图片数量和发布前检查； Grilling Skill 则规定如何追问一个计划，直到关键决策不再含糊。
本文介绍的 grilling 是社区 Skill，来源于mattpocock/skills，并不是 Codex 默认内置功能。它的价值不在于文件很长，而在于几条非常明确的对话规则。
二、Grilling 不是“多问几个问题”
grilling 可以直译为“拷问”或“盘问”，但它不是为了让对话变得咄咄逼人。
更准确地说，它是一种结构化的压力测试：把计划画成一棵决策树，只询问当前已经具备前提的问题；等用户回答后，再展开下一层。
它有五个关键机制。
1. 把计划表示成决策树
一个计划通常不是平铺的一张待办清单，而是存在依赖关系。
以“开发日志分析工具”为例：
是否值得做├── 为谁解决问题│ ├── 谁负责故障排查│ └── 现在怎样定位慢请求├── 系统输出什么│ ├── 异常日志聚类│ ├── 可疑调用链排序│ └── 带证据的原因建议├── 如何验证效果│ ├── 历史故障覆盖率│ └── 误报率与排查耗时└── 如何接入生产环境├── 日志格式与采集方式├── 数据脱敏与保留周期└── 人工复核和降级方案
只有先确定使用者和故障场景，后面才有资格选择模型、存储和分析方式。否则，“用向量数据库还是时序数据库”只是脱离问题的技术选型。
2. 每一轮只询问当前的 frontier
Grilling 把“当前已经可以回答的所有决策”称为 frontier，可以理解为决策树的当前前沿。
如果故障场景还没有确定，就不应该追问应该选择哪种检测模型；如果输入数据还没有确定，也不应该先讨论向量索引和存储容量。
这条规则看似简单，却能避免普通 AI 对话里最常见的问题：一次丢出十几个互相依赖的问题，让用户只能凭感觉一起回答。
橙色节点代表当前可以讨论的决策，灰色节点仍被前置条件锁住；回答一轮后，新的分支才会被解锁。
3. 每个问题都附带推荐答案
Grilling 不只是问“你觉得呢”，还要求 Agent 给出自己的推荐答案。
标准格式类似这样：
❓ Q1 - 核心使用者：第一阶段到底由谁来使用？➡️ 我的建议：先聚焦“负责 Java 后端服务值班的开发者”，不要同时覆盖客户端、数据平台、运维和安全团队。
推荐答案非常重要。它给用户一个可以同意、拒绝或修改的具体锚点，也迫使 Agent 暴露自己的判断，而不是把所有思考都推回给用户。
4. 事实由 Agent 查，决策由用户做
如果一个问题可以通过读取项目、搜索资料或运行工具得到答案，Grilling 不应该反过来问用户。
例如：
“仓库现在有没有自动测试？”应该由 Codex 检查代码； “当前日志中是否包含 trace ID？”应该由 Codex 检查样本和采集配置； “第一阶段先解决慢请求还是内存泄漏？”才是用户需要做的决定。
这条边界能显著减少无效问答：用户负责价值判断，Agent 负责寻找事实。
5. 没有确认，不直接实施
当决策树的前沿为空，并不代表 Codex 可以马上开工。
Grilling 要求最后再确认一次：双方是否真的形成了共同理解。只有用户确认，才进入写代码、制作产品或发布内容的阶段。
这是一道很有价值的“刹车”。它把“讨论清楚”和“开始行动”分成两个阶段，避免 Agent 一边提问，一边已经按照未确认的假设改动项目。
三、实际跑一轮：用它拷问一个日志分析工具计划
继续使用开头的想法：
我准备给团队开发一个日志分析工具。开发者上传应用日志后，系统自动定位性能瓶颈并给出原因。请使用 Grilling 帮我压力测试。
第一轮不应该立刻讨论模型、框架或数据库，而应该先处理根部决策。
可能得到这样的结果：
❓ Q1 - 核心场景：第一阶段只解决哪一种故障？➡️ 建议先解决“Java 微服务出现慢请求，值班开发者需要快速缩小排查范围”，不要同时覆盖崩溃、内存泄漏、网络抖动和安全事件。---❓ Q2 - 输出边界：系统承诺给出什么结果？➡️ 不要承诺“自动找到唯一根因”。建议先输出三条带证据的可疑调用链，让开发者把排查范围从数千行日志缩小到三个候选点。---❓ Q3 - 数据边界：第一版允许分析哪些数据？➡️ 先使用测试环境日志和已经脱敏的历史生产日志。第一版不直接连接在线生产日志，也不把原始日志发送到未经审核的外部服务。---❓ Q4 - 验证标准：达到什么结果才值得接入真实值班流程？➡️ 先选取 20 次已有结论的历史故障做盲测。如果正确原因能在前三个候选中覆盖至少 14 次，再进入两个小组的影子试运行。
注意，这一轮没有问“应该使用哪种大模型”。因为在输入、输出和验证标准确定之前，模型选型还没有进入 frontier。
假设用户回答：
1. 同意，先解决 Java 微服务慢请求。2. 同意，只给出带证据的三个候选点，不声称自动确定根因。3. 同意，第一版只使用测试日志和脱敏后的历史日志。4. 同意，先用 20 次历史故障盲测，再进行影子试运行。
第二轮才会围绕刚刚确定的方向，继续展开：
20 次历史故障怎样抽样，才能避免只挑容易案例？ 不同服务的日志格式怎样映射成统一事件结构？ 候选原因必须展示哪些日志、指标或调用链证据？ 误报、超时或数据不足时，系统怎样明确降级而不是编造结论？
好的追问不会把工具问死，而是把“自动定位瓶颈”逐渐变成明确场景、可复查证据和历史故障盲测。
四、在 Codex 中怎样调用？
安装后，最直接的方式是在任务中显式指定 $grilling：
使用 $grilling 对下面的计划进行压力测试：我准备开发一个供后端团队使用的日志分析工具，读取脱敏日志和调用链后，给出导致慢请求的三个可疑位置及证据。请先建立决策树，按 frontier 分轮提问。每个问题给出你的推荐答案。可以从代码或公开资料查到的事实，请自行查找，不要问我。在我确认达成共同理解之前，不要开始实现。
如果你已经有一份方案文档，可以让 Codex 先读取文件：
请读取 D:\my_project\product-plan.md，然后使用 $grilling 对这份方案进行压力测试。重点检查：- 目标用户是否过宽；- 成功标准是否可测量；- 技术方案是否依赖尚未验证的假设；- 数据安全、误报处理和降级方案是否有遗漏。不要重复询问文档中已经写清楚、可以直接查到的事实。
你也可以只用自然语言触发：
不要顺着我说，请把这个计划当成一次设计评审，沿着决策依赖关系追问到没有隐含假设为止。
不过在第一次使用或特别重要的计划中，我更建议显式写出 $grilling，这样意图最清楚。
五、哪些场景最适合使用？
Grilling 最适合“行动成本不低、但方案仍有很多隐含分支”的任务。
例如：
决定一个跨团队工程平台是否值得投入； 在写代码前澄清产品需求； 选择系统架构、数据模型或部署方案； 设计收费方式和交付边界； 评估一次迁移、重构或技术选型； 把一个模糊创意变成可以验证的实验。
它不太适合以下情况：
问题只需要一个明确事实，例如某个 API 参数怎么写； 任务已经充分定义，只差执行； 你只想快速获得十个创意，而不是收敛决策； 项目已经完成，现在需要的是代码审查或故障诊断； 决策非常容易撤销，讨论成本反而高于试错成本。
一个实用判断是：
如果做错后需要几天甚至几周返工，先 Grill；如果十分钟就能做出原型验证，先试再说。
六、让 Grilling 真正有用的四个技巧
1. 先给计划，不要只说“问我问题”
至少写清目标、背景、已有证据和限制。输入越具体，决策树越接近真实问题。
2. 用证据回答，不要用愿望回答
“用户应该会喜欢”不是答案。“已有 12 位读者领取模板，其中 5 位在一周内实际使用”才是证据。
3. 不要机械接受所有推荐
Grilling 的推荐答案只是待讨论的判断，不是权威结论。真正有价值的对话往往发生在你不同意它的时候。
4. 结束后要求一份决策摘要
在确认共同理解后，可以让 Codex 输出：
请把本次 Grilling 结果整理为一页决策摘要，包含：1. 最终目标；2. 已确认的关键决策；3. 被否决的方案及原因；4. 仍然接受的风险；5. 下一步最小验证实验；6. 暂时不做的内容。
这样，长对话才能转化成后续可执行、可复查的材料。
七、最后：怎样安装 Grilling Skill？
这里要先区分两件事：Skill 机制由 Codex 支持，而本文的 grilling 内容由社区仓库维护。
OpenAI 官方文档说明，每个 Skill 位于独立目录中，必须包含 SKILL.md；Skill 也可以被打包进 Plugin，通过插件目录或本地 marketplace 分发。参考：Build skills与Package your plugin。
对于本文使用的社区版本，最简单的安装方式是使用上游仓库推荐的 Skills CLI。
第一步：确认本机已经安装 Node.js
在 PowerShell 中运行：
node --versionnpm --version
如果两条命令都能显示版本号，就可以继续。
第二步：运行安装命令
在你的项目目录中执行：
npx skills@latest add mattpocock/skills
安装器会让你选择要安装到哪个 Agent，以及需要哪些 Skills：
Agent 选择 Codex； Skill 至少选择 grilling； 确认写入范围是当前项目还是个人全局目录； 安装完成后，重新打开 Codex 会话。
上游仓库的当前安装说明见：mattpocock/skills。
不建议同时用多种方式重复安装同一个 Skill，否则 Codex 可能发现多个同名版本，后续更新也更难判断来源。
第三步：验证是否安装成功
新建一个 Codex 对话，输入：
使用 $grilling 压力测试这个计划：我们准备把单体应用拆成多个微服务。
正常情况下，Codex 不会直接替你写产品，而是会按编号提出第一轮问题，并为每个问题附上推荐答案。
如果没有触发，可以依次检查：
安装时是否真的选择了 grilling；Skill 目录内是否存在 SKILL.md；是否重新开启了会话； SKILL.md顶部的 name和description是否完整；是否显式写出了 $grilling。
安装第三方 Skill 前，再多做一步
Skill 本质上是交给 Agent 的工作指令，有些 Skill 还会携带脚本、工具依赖或外部连接。安装前应该先检查来源、SKILL.md、附带脚本和权限要求，不要把不可信仓库直接加入重要项目。
本文所用仓库公开提供源代码和 MIT License，但仍建议你在安装时查看当前版本的改动，而不是永久相信某一次审查结果。
八、我的理解：Grilling 降低的是“错误开工率”
很多人用 AI Agent 时，最关注的是它能不能更快地写代码。
但当执行速度不断提升，真正昂贵的能力开始前移：是否选择了值得解决的问题，是否把成功标准说清楚，是否看见了隐藏依赖，是否知道哪些决定还缺少证据。
Grilling 不会直接替你完成项目，甚至会让项目晚一点开始。
可是这种“慢”，可能恰好是 AI 时代最值得购买的时间。
好的 Agent 不只是接收任务，也应该在任务本身站不住时，阻止我们过早开工。
如果你已经有一个准备实施的产品、功能或架构计划，可以先不要让 Codex 写代码。把方案交给 $grilling，认真回答两轮问题，再看看原来的计划还剩下多少。
你可能会失去一个看起来很完美的想法，但也可能因此保住接下来几周的时间。
参考资料
OpenAI：Skills 概念 OpenAI：Build skills OpenAI：Package your plugin mattpocock/skills：社区 Skill 源码与安装说明