最近 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.mdskill 的入口文件包含 frontmatter 元信息和提示词正文。references/可选的辅助文档目录用来存放问题模板、示例对话、审查清单等。examples/示例输出目录方便 Agent 在不确定格式时参考。对于 Claude Codeskill 放在项目的.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 部署到 CodexCodex 的 skills 在它的客户端设置中一般也是指向某个 skills 根目录。把grill-me整个目录复制到对应目录即可。# 假设 Codex skills 目录为 ~/.codex/skills mkdir -p ~/.codex/skills cp -r grill-me ~/.codex/skills/需要注意的是这里写的是通用路径具体路径以你本机 Codex 版本的实际配置为准。如果放进去之后没有生效优先看客户端里有没有 skills 管理面板而不是盲目改路径。5.3 部署到 OpenCodeOpenCode 这类开源 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 SkillMCP本质一段可复用的结构化提示词和操作流程一种工具调用的开放协议核心作用约束 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 看不到 skillskill 目录路径不对或文件名不规范让 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 的任何“盘问”和“结论”都要被当作参考信息而不是最终判断。第五注意隐私和版权。如果你在真实项目中使用 skillSKILL.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 文件的时间。值得试一次。