第一次看到 /grill-me 这个 Skill 名应该有不少人和我一样先想到烧烤。但在 Claude Code、Codex 这些 Agent 工具里grill 更多是“盘问、质询”的意思。它代表社区里一类很实用的 Skill 设计思路让 AI 不顺着你说话而是像面试官一样连续追问直到把你的方案、代码、想法里的漏洞问出来。这篇文章就以一个受 /grill-me 启发的质询型 Skill 为例从概念、写法、安装到验证和排错完整拆一遍。这类 Skill 适合谁看如果你正在研究 AI Skill 怎么用、怎么写或者想在 Claude Code、Codex、Cursor 里搭一套方案评审、面试模拟、代码审查的固定流程这文章可以省掉不少试错时间。下面按实际操作顺序来写不绕概念。1. 先搞清楚 /grill-me 这类 Skill 到底在解决什么问题1.1 为什么“被追问”比“被回答”更有用用 AI 时间长了会发现默认对话模式有个问题你抛出一个方案它倾向于顺着你往下说。你说“我想用 Vue 做内部报表系统”它会帮你补组件、补接口、补样式方案很少主动拆台说“你这个数据量可能会把浏览器卡死”。这个行为在多数场景下是友好的但在方案评审、准备面试、代码自查这些场景里不够用。你需要的是一个会反驳、会追问、会找反例的对手而不是一个只会点头的助手。/grill-me 这类 Skill 的核心价值就在这里。它把 AI 从“答题助手”切换到“质询者”模式角色变了、提问规则变了、输出方式也变了。你给它一段材料它不急着给结论而是先问出最关键的假设等你回答之后继续追直到漏洞暴露或问题收敛。使用体验上最明显的区别是“话轮”变了。普通对话里用户提问、AI 回答换成质询型 Skill 后AI 提问、用户回答AI 根据回答再问下一个问题。这个反转会让很多人第一次用时不太适应但效果很直接。1.2 这类 Skill 的适用场景受 /grill-me 启发的 Skill 可以套到很多场景里不局限于代码。场景输入质询重点期望输出技术方案评审架构设计、技术选型、数据模型边界条件、扩展性、失败场景每个决策的风险清单面试模拟你的项目经历或系统设计回答追问细节、指标、取舍原因追问列表和薄弱点代码审查PR 描述、关键代码片段异常分支、并发、兼容性可复现的 bug 风险点文章/PPT/汇报稿大纲、初稿、演讲逐字稿逻辑跳跃、论据不足、听众疑问修改建议和待补材料区分一下不是所有内容都适合被“grill”。如果只是查资料、写周报、生成代码片段普通对话更高效。质询型 Skill 适合用在“你要给别人解释或者要对自己负责”的材料上。1.3 一个可复用的核心设计这类 Skill 不需要写多复杂真正起作用的是四段结构角色设定要具体。只写“你是一个专家”没有用要写“你是懂分布式系统的架构师同时也是面试官只关心方案能不能扛住生产环境”。提问规则要硬。建议约定“每轮只问一个最关键的问题”避免 AI 一口气甩出十个问题。等待回答再继续。Skill 里要写清楚“用户回答完上一题后再基于回答继续追问”否则 AI 容易自问自答。结束条件要明确。比如达到 5 轮询问后输出一张问题清单和风险结论。把上面四点写进提示词就已经具备一个质询型 Skill 的雏形。后面再慢慢加格式、加 case、加场景。2. 写一个 Skill 之前先理解 Skill 是什么、和 MCP 什么关系2.1 Skill 本质上是给 Agent 的一份“能力说明书”很多刚接触 AI Skill 的人会把它理解成插件其实不太对。Skill 通常不是一个可执行程序而是一份结构化的 Markdown 文件里面写清楚这个能力什么时候被触发、任务按什么流程执行、输出格式长什么样。可以把 Skill 理解为“提示词工程的结构化包装”。你把一段很长的、经过反复调优的指令整理成固定格式放进 Agent 能识别的位置下次遇到类似任务Agent 会主动读取并按照规则执行。这样做的好处是显而易见的可复用。一次写好后团队内共享一份不用每个人重新调提示词。可版本化。用 Git 管理 Skill 文件改动有记录。可协作。有经验的同行把好用的 Skill 分享出来新人直接拷贝再按需修改。2.2 Skill 和 MCP 到底有什么区别这部分在社区里容易被绕晕。很多人把 Skill 和 MCP 放在一起比其实两者解决的问题不同。MCPModel Context Protocol解决的是“Agent 能不能连接外部能力”的问题比如读取本地文件、调用数据库、访问网页、操作浏览器。它更像一个工具接入协议让 AI 能拿到外部数据或执行外部动作。Skill 解决的是“拿到任务后按什么思考流程执行”的问题它不一定需要外部工具也可以在流程中调用 MCP 工具。对比项SkillMCP作用层行为规则、对话流程工具连接、外部数据访问关注点怎么思考、怎么输出能做什么、怎么接入是否需要外部服务通常不需要通常是外部服务或本地工具典型内容角色、步骤、输出模板工具列表、请求格式、返回结构协作方式可以在流程中调用 MCP被多个 Skill 复用最直白的理解Skill 约等于“老师傅的做单流程”MCP 约等于“工具箱”。老师傅可以不用任何工具空手判断也可以用到电钻、测量仪但只有一堆工具、没有流程是干不出稳定结果的。2.3 常见支持 Skill 的环境目前我接触到的几类工具里对 Skill 的支持方式不太一样Claude Code 一般会扫描~/.claude/skills/目录每个 Skill 放在一个独立文件夹里。Codex 社区常用的做法是把 Skill 放在~/.codex/skills/或项目级目录中具体格式要看当前版本。Cursor 有的版本用Commands或.cursor/skills来管理不同版本差异明显。OpenCode 这类开源工具命名和目录也会随版本调整。这里有个重要提醒不要照抄网上的目录配置。工具更新很快不同版本对 SKILL.md 里的字段要求未必相同。我写过几次 Skill遇到过把文件放对位置却不生效的情况最后查出来是版本里要求先执行一次索引刷新或重开会话。所以稳妥的做法是先看当前版本的官方文档确认 Skill 目录和字段格式再动手写。3. 动手写一个“质询型 Skill”从需求到文件落地3.1 写之前先想清楚三个问题很多人写 Skill 是直接打开编辑器写提示词我建议先想清楚三件事否则后面一直改。第一谁用。只有自己用可以写得很随意团队要共享就要写清楚适用场景、输入格式、触发词避免别人不知道什么时候该用。第二审什么。受 /grill-me 启发的 Skill 可以套很多场景但你不可能一个提示词覆盖所有场景。建议第一版只专注一种输入比如“只审技术方案”后面再抽离出通用版。第三输出形态。是要 AI 在对话里逐轮追问还是最后交一份完整审查报告这两种流程差异很大。逐轮追问适合面试模拟、方案推演完整报告适合代码 review、文档评审。想清楚这三点再写 SKILL.md会顺很多。3.2 目录结构和 SKILL.md 的基本写法一个最简 Skill 只需要一个文件夹和一个 Markdown 文件。下面是我的常见目录结构my-grill-skill/ SKILL.md examples/ sample-input.md sample-report.md prompts/ final-report.md其中只有SKILL.md是必需的。examples/放输入输出示例用来给 Agent 做 few-shot 参考prompts/放一些较长的片段主文件里用相对路径引用也行直接内联也行。SKILL.md里通常要有这几个部分nameSkill 名称最好和触发方式一致。description什么时候使用、输入是什么、输出是什么。这段最重要因为 Agent 通常靠它决定要不要调用。instructions实际执行步骤按顺序写清楚。constraints限制条件比如“一次只问一个问题”“不要替用户回答”。描述部分不要写得太泛。例如如果你只知道用户想“被追问”那是触发不了的。description 里应该写清楚当用户要求审查方案、模拟面试、找漏洞、挑战假设时这个 Skill 才被激活。3.3 一个能跑通的最小指令模板下面给一个简化版但能直接跑通的SKILL.md结构以“质询模式”为例# /grill-me ## Description 当用户要求审查自己的方案、代码、文档或想法希望被高强度提问、找漏洞、模拟面试/答辩时使用。 输入一段方案描述、代码片段或文本初稿。 输出逐轮追问 最终问题清单。 ## Instructions 1. 让用户先提供要审查的对象如果没提供直接问“你要我审什么”。 2. 识别输入类型技术方案、代码、文档、演讲稿。 3. 每一轮只问一个最关键的追问不允许一次抛出多个问题。 4. 等待用户回答后再判断是否继续追问或转向下一个关键点。 5. 最多进行 5 轮追问结束后输出 - 3 个最关键的风险点 - 问题清单 - 建议补充的材料实际运行时Affect 会按这个流程执行。你会发现最有效的约束是“一次只问一个最关键的追问”。一旦少了这句AI 很容易生成一张 20 个问题的大清单用户看到就头大也丧失追问感。这个模板不需要写任何代码。用 Markdown 就能跑通第一版。跑通后再根据使用体验细化。4. 在 Claude Code / Codex / Cursor 里安装并触发4.1 Claude Code 的安装路径和触发方式以 Claude Code 为例先把 Skill 文件夹放到指定目录mkdir -p ~/.claude/skills/my-grill-skill cp -r ./my-grill-skill ~/.claude/skills/放好后重开会话或者执行索引刷新然后直接用斜杠命令触发/grill-me也可以不输斜杠命令而是在对话里自然表达需求。比如“帮我审一下这个方案用 /grill-me 的逻辑来问”Agent 读取 description 后一般能匹配上。我在实际使用中遇到过一种情况文件放上去了但是新会话里第一次触发没有反应。重开会话以后才正常。所以如果你改完 Skill 文件建议先确认工具是否重新加载不要反复纠结内容写错。4.2 Codex、Cursor 等环境的差异不同工具的 Skill 管理方式还在快速变化我接触到的几个版本里差异主要在三处目录位置不同。有的放在用户全局目录有的放在项目.cursor/skills下有的要求和AGENTS.md配合。SKILL.md 字段兼容性不同。有的工具只认description和instructions有的会识别更复杂的 frontmatter。触发方式不同。有的靠斜杠命令有的靠自然语言自动匹配有的需要先安装到特定命令列表。这也是为什么我强调“以当前版本文档为准”。不要假设 Claude Code 能跑的目录Codex 一定能跑。我的习惯是每个新工具先用官方示例跑通一个最小 Skill再把自己写的搬过去。4.3 触发前检查清单如果你把 Skill 放进去了但触发不了优先按顺序检查这几项路径是否正确。比如~/.claude/skills/注意不要多一层或少一层目录。SKILL.md文件名是否完全正确。大小写、后缀都不能错。description 里是否包含足够的触发词。如果描述里只有“质询”两个字实际对话里用户说的是“审一下我的方案”可能匹配不上。目录权限是否可读。有人把 skill 放在共享目录或网盘映射目录Agent 读不到。是否有同名 Skill 冲突。多个同类 Skill 同时存在时Agent 可能选了另一个。这套检查顺序基本可以解决 80% 的“装不上”问题。5. 用单条任务验证 Skill 是否真的能用5.1 先跑一个最小样例写完 Skill不要急着放很多真实项目先跑最小样例。我常用的验证输入是这样的请用 /grill-me 帮我审一下这个技术方案用 Vue 3 开发一个内部报表系统前端负责渲染表格和图表后端返回聚合后的数据不打算引入重型图表库。观察三个点Agent 是否进入了质询者模式。它有没有先确认“要审的是技术方案”还是直接开始给建议。是否一次只问一个问题。如果一口气列出 5 个问题说明 instructions 里的约束没生效或者工具没有读到 SKILL.md。在你回答之后它是否基于回答继续追问。如果换了个无关问题说明流程设计有偏差。第一次跑通后再增加复杂度比如上传一份完整设计文档或者贴一段带并发问题的代码。5.2 输出质量怎么判断判断 Skill 好不好用不是看它“话多不多”而是看三点。第一问题是否锁定关键假设。比如报表系统需要关注数据量、缓存策略、权限模型如果追问只停留在“页面好不好看”上说明质询方向偏了。第二是否连续追进。好的质询是“你答完 A它顺着 A 追 A2”而不是“你答完 A它跳到 B”。第三最终输出是否可执行。好的 Skill 最终会收敛成“关键风险点 问题清单 待补材料”而不是一个“希望你再想想”的模糊结论。我一般会把 Skill 跑三轮每次输入同一个用例观察输出是否稳定。如果三遍答案差异很大说明指令里还有太开放的地方需要增加格式约束。5.3 参数和边界调节第一版先别追求“问得又多又狠”。建议按下面这组保守参数起步最大追问轮数3 到 5 轮。语气强度中等。不要一上来就写“你不许狡辩”会让 AI 变成纯抬杠。每次提问数量1 个。这是质询感的基础不要让步。结束输出格式固定三段式。跑顺了之后再调把轮数加多、把语气调狠、加入“只允许从架构角度提问”等限定。调参的时候一次只改一个维度否则出了问题不知道是哪个条件引起的。6. 常见问题排查Skill 没加载、触发失败、行为不对6.1 先把现象分清楚排查 Skill 问题最忌讳的是“直接改提示词”。第一步应该先确认现象属于哪一类现象优先排查方向没有任何响应像没看到 Skill路径、文件名、索引刷新响应了但完全不按 instructions 来SKILL.md 是否被加载、字段是否被工具识别按了一部分 instructions后来又跑偏指令冲突、角色设定不清晰、context 被占满输出格式完全不对instructions 里格式约束太弱需要加强制模板时好时坏上下文长度、多 Skill 冲突、并发多次调用分好现象再往下查效率会高很多。6.2 逐层排查顺序我自己用固定顺序排查先看文件再看描述最后看运行上下文。第一步检查文件本身。SKILL.md 文件名大小写、编码、目录层级。有些编辑器会保存成 UTF-8 with BOM个别工具解析会出问题把内容复制到普通文本文件里重存一次能解决。第二步检查描述能否被检索。把 description 里的关键词和你的触发语句对比一下很多时候用户说的是“帮我挑毛病”Skill 描述里写的是“审查方案”语义上有关联但匹配不到。这时候把触发词写全比如“挑毛病、找漏洞、模拟面试、审方案、挑战假设”都写进去。第三步检查运行时信息。CLI 工具一般有 debug 或 verbose 模式打开后能看到模型读取了哪些文件和工具。如果日志里根本没有提到 skill 文件说明问题在加载层如果加载了但行为不对才回到指令优化。注意很多“Skill 写得不生效”的问题其实不是提示词不好而是运行环境压根没读到文件。先确认加载再改内容。6.3 几个容易踩的认知误区第一个误区是把 Skill 当成“自动运行的插件”。多数工具里Skill 需要被用户触发或者靠 description 与上下文匹配。不是放进去就自动对每一条消息生效。第二个误区是认为所有工具支持同一套字段。Claude Code 用的 SKILL.md 结构不代表 Codex 一定会完全识别。跨工具复用之前先做一次最小验证。第三个误区是让 Skill 承担所有事。Skill 可以调用 MCP 工具但 Skill 本身不是 MCP。不要指望一份 SKILL.md 能帮你读取数据库、访问网页那部分要由外部工具完成。第四个误区是写得越长越好。SKILL.md 太长会占上下文也可能引入冲突。真正有效的文件通常角色清晰、步骤短、约束硬。一个 300 行的 Skill 不代表比 30 行的更强反而更难维护。7. 从单人到团队把 Skill 做成可复用资产7.1 统一输出格式如果只有你一个人用输出格式可以随意。一旦给团队用就要固定输出结构否则每个人拿到的结果不一样没法横向对比。我建议质询型 Skill 最终输出固定成三段关键风险结论用 3 到 5 条概括最重要的问题。问题清单按“未回答/已回答但存疑/已解决”分类。待补材料用户还需要准备的数据、测试、文档、证据。这个三段式的好处是评审、面试、 code review 都能套。团队里其他人看到同一格式马上知道下一步该补什么。7.2 把高频问题沉淀进 SkillSkill 用久了你会发现在某个场景下总会出现同样的追问。比如内部报表系统总会问数据量级、图表渲染方式、权限粒度。这些问题不应该每次都靠 AI 临场发挥可以直接写进 Skill 的检查清单里。在 SKILL.md 底部加一节checklist把高频问题列出来。运行时Agent 会结合清单和用户回答去追问。这样 Skill 会越用越贴近业务而不是停留在通用“挑毛病”层面。同时建议把好的质询案例放进examples/目录。每次遇到效果特别好的追问记录就整理成一组输入输出示例。模型可以参考这些示例照猫画虎比单纯堆指令更稳定。7.3 版本管理和分享建议Skill 文件是纯文本用 Git 管理最合适。目录结构清楚后把整个 Skill 文件夹放进私有仓库或团队共享仓库按版本发布。发布给别人用时建议在 SKILL.md 开头写清楚三件事这个 Skill 用来干什么需要什么输入在哪个工具、哪个版本下验证过。不要给别人留一个没有说明的文件夹否则别人导入后跑不通只会重新踩一遍你踩过的坑。如果你要把 Skill 做得更好可以给它加一个最小测试用例让使用者拿到就会验证给一个示例输入跑一遍看输出是否接近预期。这个环节虽然不起眼但在团队推广时非常省事。真正的落地经验是先把单条任务跑稳再谈批量、团队和分享。Skill 本身不复杂复杂的是“在什么场景触发、按什么流程走、输出是否稳定”这三件事。写质询型 Skill 也一样不要一开始就想做一个万能的大而全版本从一个自己能跑通的场景开始比什么都重要。