最近 agent skill 这个概念在 Claude Code、Codex 这类工具里越来越常见。简单说，skill 就是把一组提示词、规则、参考文档和固定工作流打包成一个文件夹，让 Agent 在特定场景下自动加载并执行。它不是模型，不是插件，也不是 MCP 服务，更像是一份“可以被 Agent 读取并严格执行的操作手册”。
这次我们来看的是一个很特别的 skill 思路：grill-me。这个名字直译过来是“盘问我”或者“把我放在火上烤”。它不是一个复杂工具，而是一种提示词设计范式：不让 Agent 乖乖执行你的命令，而是让 Agent 反过来对你进行高强度追问、预判风险、拆穿逻辑漏洞，最后再给出结论。这种“对抗式”的审查风格，被很多人用来做技术方案评审、需求澄清、代码 review 和面试模拟。
基于这个灵感，你可以自己写一个 grill-me 风格的 skill，挂到本地 agent 上。这篇文章会讲清楚四件事：skill 到底是什么、grill-me 这种 skill 的目录结构和提示词怎么写、怎么部署到 Claude Code 或 Codex、怎么测试它真的在“盘问”而不是“附和”。全文不依赖云端服务，本地就能跑。
1. grill-me 风格 skill 核心能力速览
先把最关键的规格放在前面，方便你快速判断这东西值不值得折腾。
| 能力项 | 说明 |
|---|---|
| 项目性质 | 受 grill-me 思路启发的自定义 Agent skill，属于提示词工程/工作流封装 |
| 运行载体 | Claude Code、Codex、OpenCode 等支持自定义 skill 的 Agent 工具 |
| 核心功能 | 对用户的方案、代码、需求进行高强度追问、风险预判、逻辑审查和结论复盘 |
| 显存/GPU 要求 | 无，纯文本提示词，不需要本地大模型推理 |
| 是否支持接口 API | 不直接提供 API，跟随宿主 Agent 的 API 或命令行使用 |
| 是否支持批量任务 | 取决于宿主工具；skill 本身可被多次触发，适合逐个方案审查 |
| 启动方式 | 在 Agent 中输入/grill-me或描述场景后自动加载 |
| 安装难度 | 低，只需要创建目录和 Markdown 文件 |
| 适合读者 | 正在用 Claude Code / Codex 做方案设计、代码审查、需求澄清的开发者 |
需要说明的是，受 grill-me 启发的 skill 本身不限制硬件，也不需要显卡。它的运行成本就是宿主 Agent 的模型调用成本。如果你本地用的是 Claude Code 或 Codex 这类工具，模型在云端，本地只负责文件读写；如果是 OpenCode 接本地模型，那才需要考虑显存。
2. grill-me 思路到底在解决什么问题
很多人第一次看到 grill-me 这个 skill 名，会以为它是一个“刁难用户”的工具。实际理解要反过来：它解决的是 Agent 太顺从、太容易给答案的问题。
默认情况下，你让 Agent 写一个方案，它会很快列出一二三四五。表面上内容完整，但里面可能藏着没被你注意到的假设。比如你说“我要做一个批量图片压缩工具”，Agent 会直接给你代码，但不会主动问：图片格式是哪些？原图保留不保留？压缩率目标值是多少？批量规模是一百张还是一百万张？这些信息缺失时，Agent 只能猜，猜错了后面全白做。
grill-me 的核心思路就是：在 Agent 给出正式方案之前，先进入一个“盘问阶段”。它会把你的需求当成一个待审查的项目，不断提出边界问题、风险问题和验证问题。当你答完这一轮，它拿到足够约束条件，才开始产出方案。
这种范式适合四类场景：
- 技术方案设计前期的需求澄清。
- 代码提交前的自我 review，让 Agent 以红队视角挑毛病。
- 写技术文档或者做技术选型时，让 Agent 扮演评审者而不是写手。
- 模拟面试、架构答辩、方案汇报等需要被提问的场景。
不适合的场景也有。如果你只是想快速得到一个样板代码，或者时间很紧张，grill-me 风格会觉得啰嗦。它是有意制造“摩擦”的，目的是逼你先想清楚。另外，它不适合用在客服对话、闲聊、内容生成这类需要流畅输出的场景里。
使用边界上要记住：grill-me 风格 skill 给出的所有“质疑”和“结论”都是模型生成的，不代表事实判断。涉及安全、合规、法律、财务等关键决策时，还是要人工复核。不要让 Agent 的盘问结果直接替代专业意见。
3. 环境准备与 skill 目录结构
在开始写 skill 之前，先确认你的 agent 工具支持自定义 skill。目前比较常见的是 Claude Code 和 Codex，两者的目录约定基本一致。
3.1 环境检查清单
| 检查项 | 说明 |
|---|---|
| 操作系统 | Windows / macOS / Linux 均可，skill 是纯文本文件 |
| 必装工具 | Claude Code 或 Codex 之一，能正常调用模型 |
| 目录权限 | 用户目录下可读写，或项目目录下可读写 |
| 依赖项 | 无额外 Python 包，无 Node 包，无数据库 |
| 网络 | 取决于宿主 Agent 的模型访问方式，和 skill 本身无关 |
3.2 约定目录结构
一个 skill 通常就是一个文件夹，里面放一个SKILL.md主文件，外加若干参考文档子目录。受 grill-me 启发的 skill 建议采用下面这个结构：
grill-me/ ├── SKILL.md └── references/ ├── question-bank.md └── examples/ └── session-example.mdSKILL.md：skill 的入口文件，包含 frontmatter 元信息和提示词正文。references/：可选的辅助文档目录，用来存放问题模板、示例对话、审查清单等。examples/：示例输出目录，方便 Agent 在不确定格式时参考。
对于 Claude Code，skill 放在项目的.claude/skills/目录下；对于全局生效，则放在用户配置目录的skills目录下。Codex 的使用方式类似，可以把 skill 文件夹放到其 skills 配置路径中。
具体路径在不同版本里可能略有差异。稳妥的做法是：先在你的 agent 工具里查看当前 skills 目录的加载路径，或者把 skill 放到项目根目录的约定位置，再通过命令确认能否被识别。
4. 编写一个 grill-me 风格的 SKILL.md
这是整篇文章的核心。一个 skill 能不能起作用，九成取决于SKILL.md这个文件写得够不够清楚。
4.1 frontmatter 部分的写法
SKILL.md要带 YAML frontmatter，至少包含name和description。description非常关键，因为宿主 Agent 会扫描所有 skill 的 description，来判断当前对话是否触发这个 skill。描述写得越具体，触发越准。
--- name: grill-me description: > 当用户需要做方案评审、需求澄清、技术选型审查、代码 review 或面试模拟时， 使用本 skill 对用户进行高强度盘问。它会逐条追问目标、边界、约束、风险和验证方式， 在信息不足时拒绝直接给方案，直到关键信息被确认。 ---注意description里写的是“什么时候用”，不是“这个 skill 是什么”。不要把描述写成“这是一个 grill 风格的提示词工具”，那样 Agent 很可能无法在正确时机加载它。
4.2 正文部分的提示词设计
正文部分要明确告诉 Agent 做什么、按什么顺序做、做到什么程度。下面是一个可复用的 grill-me 风格正文模板，你可以直接改造成自己的版本。
# 角色 你是一名严格的方案评审员，负责对用户提出的目标进行高强度盘问。 你的职责是帮助用户在动手之前暴露所有假设、缺失约束和潜在风险。 # 执行阶段 当你被触发时，严格按以下阶段执行： ## 阶段一：目标拆解 先让用户用一句话说明要达成的最终结果。如果句子超过 40 个字， 要求用户拆分。只保留可验证的动词，例如“生成”“部署”“返回”“减少”。 ## 阶段二：边界追问 根据用户目标，从以下维度逐条追问，每次只问一个维度，不要一次抛出全部问题： - 输入边界：输入是什么？格式是什么？数量级是什么？ - 输出边界：输出是什么？验收标准是什么？ - 环境边界：运行在什么环境？是否有版本约束？ - 性能边界：是否有响应时间、吞吐量、资源上限要求？ - 失败边界：出错时允许失败，还是必须兜底？ 每个维度追问一次后，等待用户回答。用户未回答时，不要跳到下一个维度。 ## 阶段三：风险揭示 基于用户回答，列出最多 5 条潜在风险。每条风险必须遵循以下句式： “如果 [条件] 成立，可能导致 [后果]。确认 [验证方式] 后才能继续。” 禁止泛泛而谈。每一条风险都要能对应用户自己的输入内容。 ## 阶段四：结论确认 当所有边界问题得到回答，且风险被确认或排除后，输出一个“最终需求摘要”。 摘要必须包含：目标、范围、约束、验证方式、优先级。 在用户确认摘要之前，不要给出实施建议或代码。 # 禁止事项 - 禁止在用户未回答边界问题前直接输出方案。 - 禁止把“我觉得”“可能”当作结论。 - 禁止同时提出超过 3 个问题。 - 禁止使用“这是一个很好的问题”等恭维话术。 - 禁止在信息不足时任选默认值。 # 退出条件 用户确认最终需求摘要，或者明确说“跳过盘问直接给方案”时，退出本 skill 流程。这份模板的设计重点是“有节奏”。很多 Agent 提示词失败，是因为一次性让模型做太多事情。grill-me 风格要求把“追问”和“给答案”拆成不同阶段，每一阶段有明确的输入和输出。这样 Agent 才不会在问了两句之后，忍不住又帮你把方案写了。
4.3 参考文档怎么写
references/question-bank.md是给 Agent 备用的问题库，防止它在盘问时思路枯竭。问题库不需要写太多，重点是分类清晰。
# 问题库 ## 目标类 - 这个目标在当前时间节点要解决什么问题？ - 谁是这个目标的最终受益者？ - 完成到什么程度算“完成”？ ## 数据类 - 数据从哪里来？是什么格式？ - 数据量大概多少？峰值是多少？ - 数据里是否包含敏感信息？ ## 技术类 - 现有系统用了哪些技术栈？ - 有没有不能替换的依赖？ - 是否有历史包袱需要兼容？ ## 验证类 - 你怎么证明结果是对的？ - 测试数据来源是什么？ - 如果上线失败，回滚方案是什么？5. 部署到 Claude Code / Codex / OpenCode
写好SKILL.md之后，部署只是复制文件的事情。
5.1 部署到 Claude Code
在项目根目录创建.claude/skills/grill-me/，把SKILL.md和references目录放进去。
mkdir -p .claude/skills/grill-me/references cp SKILL.md .claude/skills/grill-me/ cp -r references/* .claude/skills/grill-me/references/启动 Claude Code 后，在对话中直接说“帮我评审一下这个方案，先盘问再给结论”，Agent 应该能根据 description 自动加载这个 skill。
5.2 部署到 Codex
Codex 的 skills 在它的客户端设置中，一般也是指向某个 skills 根目录。把grill-me整个目录复制到对应目录即可。
# 假设 Codex skills 目录为 ~/.codex/skills mkdir -p ~/.codex/skills cp -r grill-me ~/.codex/skills/需要注意的是，这里写的是通用路径，具体路径以你本机 Codex 版本的实际配置为准。如果放进去之后没有生效，优先看客户端里有没有 skills 管理面板，而不是盲目改路径。
5.3 部署到 OpenCode
OpenCode 这类开源 agent 工具也支持类似结构。一般是在项目根目录创建一个约定名称的目录来放置技能文件。具体目录名请查阅当前版本文档。逻辑是一样的：一个目录 + 一个 SKILL.md + 可选的 references。
5.4 验证 skill 是否被识别
不管部署到哪个工具，都要做一次加载验证。最简单的办法是让 Agent 展示自己的技能列表：
列出你已经加载的所有 skill，只输出 name 和 description。如果列表里没有 grill-me，检查三件事：
SKILL.md文件名是否完全一致。- frontmatter 是否写了两条横线
---包裹。 description是否在扫描时能匹配你的测试语句。
6. 功能测试：让 skill 跑起来
部署完成后，不要直接上真实项目。先用简单的测试用例验证 skill 在“追问”而不是“附和”。
6.1 测试用例一：目标不清晰时触发追问
输入示例：
帮我做一个图片压缩工具。预期结果：Agent 不会直接给代码，而是问你输入图片格式、源图目录、是否保留原图、压缩目标等边界问题。
判断成功的标准：回复中至少包含 2 个以上针对“图片压缩工具”这一句的边界提问，而不是直接堆代码。
常见失败：Agent 直接给出完整代码。这说明 skill 没有触发，或者提示词中的禁止事项不够强。可以加大description的匹配权重，或者在输入时明确写“用 grill-me 风格先盘问”。
6.2 测试用例二：连续追问后能收敛
输入示例：
帮我做一个图片压缩工具。 图片是 jpg 和 png，放在 /data/input 目录。 输出到 /data/output，压缩后单张不超过 300KB。 原图保留，压缩失败的文件写入失败日志。预期结果：Agent 在拿到关键信息后，不再继续问输入输出问题，而是进入风险揭示和最终需求摘要。
判断成功的标准：回答中出现“最终需求摘要”或类似结构化总结，并且没有在一次回复里问超过 3 个问题。
6.3 测试用例三：主动拒绝默认假设
输入示例：
系统就用 Python 3.10 写吧，没问题。预期结果：Agent 应该追问“Python 3.10 是团队强制要求，还是你可以自由选择？”而不是直接说“好的”。
判断成功的标准：Agent 能识别出“用户可能自行设定了未经验证的约束”，并对约束本身提出质疑。
6.4 测试用例四：退出条件生效
输入示例：
跳过盘问，直接给我方案。预期结果：Agent 立即进入方案输出模式，不再不停追问。
判断成功的标准：Agent 认可用户主动退出信号，并给出完整方案，而不是继续走流程。
这四组测试分别覆盖：触发、收敛、质疑、退出。如果都通过，说明这个 skill 在行为层面是稳定的。
7. agent skill 和 MCP 有什么区别
写 grill-me 风格 skill 的过程中，很多人会把 skill 和 MCP 搞混。这两个概念经常同时出现，但解决的问题不一样。
| 对比项 | Agent Skill | MCP |
|---|---|---|
| 本质 | 一段可复用的结构化提示词和操作流程 | 一种工具调用的开放协议 |
| 核心作用 | 约束 Agent 的工作方式 | 暴露外部工具和数据给 Agent 使用 |
| 有没有代码 | 通常只有 Markdown/参考文件 | 需要服务端代码或 SDK 实现 |
| 是否需要运行服务 | 不需要 | 通常需要本地服务或远程服务运行 |
| 典型场景 | 让 Agent 按固定流程做方案评审、代码规范审查、文档生成 | 让 Agent 读取数据库、发送请求、操作文件 |
| 触发方式 | 按描述匹配自动触发 | 按工具调用 token 显式调用 |
更直白的说法是：skill 改的是“Agent 怎么想”，MCP 改的是“Agent 能碰到什么”。你完全可以在同一个 Agent 里同时使用 grill-me skill 和几个 MCP 工具。比如用 MCP 连接代码仓库和数据库，然后要求 grill-me skill 在输出任何方案前先做边界盘问。
如果你只是想约束 Agent 的工作流，不需要写服务端代码，那就用 skill；如果你要把外部系统接进来，比如读 issue、查监控、发工单，那就用 MCP。两者不是替代关系。
8. 常见问题与排查方法
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| Agent 看不到 skill | skill 目录路径不对或文件名不规范 | 让 Agent 列出已加载 skill，检查目录结构 | 按工具要求调整目录，确认 SKILL.md 文件名 |
| skill 被触发但行为不对 | description写得像“功能说明”而非“触发条件” | 把测试输入改为更自然的用户句子 | 重写 description，增加使用场景触发词 |
| Agent 一次性问太多问题 | skill 正文没有限制提问数量 | 检查 SKILL.md 是否写明“一次最多追问 3 个问题” | 在正文中加入明确的提问数量上限 |
| Agent 无法收敛，一直追问 | 缺少“退出条件”和“最终摘要”环节 | 检查执行阶段是否写了阶段四 | 补充“用户确认摘要后终止追问”的流程 |
| skill 加载后不起作用 | frontmatter 格式错误或没有在正文中声明“严格按阶段执行” | 打开 SKILL.md，看 frontmatter 是否被正确解析 | 修复 YAML 格式，在正文加大强制执行语气 |
| 引用的 references 文件没生效 | Agent 不支持自动读取 references，或路径错误 | 在 SKILL.md 中明确给出参考文件路径 | 在 SKILL.md 中写入references/question-bank.md的完整相对路径 |
| 模型回答还是太顺滑 | 提示词中缺少“禁止事项” | 检查是否列了禁止直接给方案、禁止使用恭维话术 | 增加一段“禁止事项”，并用命令式短句 |
9. 最佳实践与使用边界
grill-me 风格 skill 的代码量几乎为零，但要做好“调教”的打算。这里给几条工程化建议。
第一，第一次使用先跑测试用例，不要直接拿真实项目试。因为真实项目的输入往往充满模糊信息，Agent 如果工作流不对，会把问题都归咎于你输入不够清晰。先用最简测试句，例如“做一个 XX 工具”，观察它是否发起追问，再逐步增加复杂度。
第二，SKILL.md 要维护成版本化文件。skill 本质上是你和 Agent 之间的一份“行为契约”。随着你使用 Agent 的频率增加，你会慢慢发现哪些问题该问、哪些提示词没效果。把这些经验回写到references/question-bank.md里，比每次临时手写一段提示词要稳定得多。
第三，模型本身的稳定性会影响 skill 效果。skill 是提示词工程，不是代码逻辑。同一个 skill 放在不同模型上，效果可能差异很大。如果你使用的是 Claude Code 里的不同模型，或者 OpenCode 接的不同本地模型，不要默认效果一样，要以实际触发和回答质量为准。
第四，设置明确边界。受 grill-me 启发的 skill 适合做方案打磨和风险暴露，它不能替代代码测试、安全扫描和人工决策。特别是涉及生产环境变更、财务操作、法律判断时，Agent 的任何“盘问”和“结论”都要被当作参考信息，而不是最终判断。
第五，注意隐私和版权。如果你在真实项目中使用 skill，SKILL.md 和 references 文件里的问题库不要包含公司敏感信息。如果使用第三方 agent 工具的云端模型，输入内容会按服务商的隐私策略处理。不要在不允许外发的环境中输入内部代码和商业数据。
10. 总结与下一步
grill-me 风格 skill 最值得尝试的地方是它扭转了 Agent 的使用习惯：从“让模型直接写”变成“让模型先问”。这个变化看起来简单，实际能显著减少返工。很多方案翻车，不是因为编码能力不够，而是因为需求和边界在一开始就没对齐。
拿到这个 skill 后，第一件事是把它部署到你的主用 agent 工具里，然后用“帮我做一个 XXX 工具”这句极简输入触发一次。如果它能连续追问三轮以上，并且每轮只问一个维度，说明流程基本正常。如果它直接甩代码，别急着怀疑模型，先回头检查 description 和正文章节，禁止事项不够强是很常见的原因。
最容易踩的坑有两个：一是把 skill 当成万能插件，期待它像软件一样“装上就有效”；二是把 skill 当成永久生效的规则，忘记它只是建议性的提示词。skill 改变不了模型的能力上限，只能帮你把一个相对稳定的工作流固化下来，减少重复对话成本。
后续可以往三个方向扩展。一是给 grill-me skill 增加领域版本，比如针对 Java 后端评审、Python 数据管道评审、前端架构评审，分别维护不同的问题库。二是加入输出模板，让每次盘问结束后自动生成结构化的“需求澄清记录”，方便归档。三是和其他 skill 或 MCP 工具组合，比如审查完方案后自动调用代码检索工具核对真实代码环境。
这一套流程不需要显卡，不需要 API key，不需要额外服务，唯一投入就是写一个 Markdown 文件的时间。值得试一次。
