第一次看到 /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 放在一起比，其实两者解决的问题不同。
MCP（Model Context Protocol）解决的是“Agent 能不能连接外部能力”的问题，比如读取本地文件、调用数据库、访问网页、操作浏览器。它更像一个工具接入协议，让 AI 能拿到外部数据或执行外部动作。
Skill 解决的是“拿到任务后按什么思考流程执行”的问题，它不一定需要外部工具，也可以在流程中调用 MCP 工具。
| 对比项 | Skill | MCP |
|---|---|---|
| 作用层 | 行为规则、对话流程 | 工具连接、外部数据访问 |
| 关注点 | 怎么思考、怎么输出 | 能做什么、怎么接入 |
| 是否需要外部服务 | 通常不需要 | 通常是外部服务或本地工具 |
| 典型内容 | 角色、步骤、输出模板 | 工具列表、请求格式、返回结构 |
| 协作方式 | 可以在流程中调用 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里通常要有这几个部分：
name：Skill 名称，最好和触发方式一致。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 把高频问题沉淀进 Skill
Skill 用久了，你会发现在某个场景下总会出现同样的追问。比如内部报表系统总会问数据量级、图表渲染方式、权限粒度。这些问题不应该每次都靠 AI 临场发挥，可以直接写进 Skill 的检查清单里。
在 SKILL.md 底部加一节checklist，把高频问题列出来。运行时，Agent 会结合清单和用户回答去追问。这样 Skill 会越用越贴近业务，而不是停留在通用“挑毛病”层面。
同时建议把好的质询案例放进examples/目录。每次遇到效果特别好的追问记录，就整理成一组输入输出示例。模型可以参考这些示例照猫画虎，比单纯堆指令更稳定。
7.3 版本管理和分享建议
Skill 文件是纯文本，用 Git 管理最合适。目录结构清楚后，把整个 Skill 文件夹放进私有仓库或团队共享仓库，按版本发布。
发布给别人用时，建议在 SKILL.md 开头写清楚三件事：这个 Skill 用来干什么；需要什么输入；在哪个工具、哪个版本下验证过。不要给别人留一个没有说明的文件夹，否则别人导入后跑不通，只会重新踩一遍你踩过的坑。
如果你要把 Skill 做得更好，可以给它加一个最小测试用例，让使用者拿到就会验证：给一个示例输入，跑一遍，看输出是否接近预期。这个环节虽然不起眼，但在团队推广时非常省事。
真正的落地经验是：先把单条任务跑稳，再谈批量、团队和分享。Skill 本身不复杂，复杂的是“在什么场景触发、按什么流程走、输出是否稳定”这三件事。写质询型 Skill 也一样，不要一开始就想做一个万能的大而全版本，从一个自己能跑通的场景开始，比什么都重要。
