如果你最近在关注 AI Agent 和编程助手的进阶玩法大概率会频繁碰到两个词Skill和/grill-me。先说一个很容易被忽略的痛点。很多人用 Claude Code、Codex、Cursor 这类工具感觉它们很聪明但太顺着你。你抛出一个半成品的方案它帮你把代码补齐你贴上一段有明显隐患的代码它默认你在做正确的事只会围绕现状提改进。真正到了线上出问题再回头看才发现 AI 在早期提示过的那点风险早被淹没在长篇回复里了。问题的根源不在模型能力而在协作方式你只给了 AI执行的任务没有给它质疑的任务。/grill-me这类 Skill 要解决的正好是这件事。它的核心思路不是让 AI 帮你写代码而是让 AI 像一位经验丰富的架构师对着你的代码、方案、设计决策做高强度盘问。它追问的不是这段代码怎么实现而是你凭什么认为这个方案可行边界条件怎么处理这个假设如果错了会怎样。这篇文章会从零拆解如何构建一个灵感来源于/grill-me的高质量对抗质询类 Skill。你会了解 Skill 与 MCP 的边界、Skill 文件的组成结构、一个可落地的完整示例以及让 Skill 真正好用的工程实践和避坑指南。读完可以自己写出适合团队场景的 Skill而不是停留在看过别人推荐的层面。1. 为什么关注/grill-me这类 Skill很多人对 AI 编程助手的认知还停留在两个阶段。第一阶段是问答工具我把问题描述清楚AI 给出答案我判断答案是否可用。第二阶段是结对编程助手AI 能理解上下文、跨文件改代码、甚至主动执行命令。这两个阶段都有一个共同问题AI 默认以协助者身份工作它不会轻易否定你的前提。grill-me的价值在于给 Agent 提供了一个反向角色审问者、挑战者、质量门禁。它解决了三个具体问题。第一减少盲目自信提交。开发者在写代码时往往带着思路惯性自己很难发现方案里被刻意忽略的异常分支。一个会连环追问的 Skill能逼你重新审视那些应该没问题的假设。第二减少评审问题反复。团队做代码评审或方案评审时低质量讨论经常消耗大量时间。如果 AI 能在提交前先做一轮高强度自查很多低级问题根本走不到人工评审环节。第三提升 AI 输出的可验证性。普通的帮我看看这段代码会让 AI 自然倾向于说整体写得不错建议优化以下几点。而 grill 风格的输出必须包含风险等级、质疑理由、证据定位、改进建议这让 AI 给出的结论更容易被验证。从更宏观的角度看Skill机制正在改变我们使用 Agent 的方式。以前每次都要在对话里写很长的提示词现在可以把一套方法固化成文件在合适的时机被自动加载或通过一句话显式调用。/grill-me这种风格型 Skill尤其有意思它不给 Agent 增加新工具只改变 Agent 的思维方式。这篇文章的读者我建议主要聚焦三类人群已经在用 Claude Code、Codex、Cursor 等工具但感觉输出不够犀利的开发者团队里负责技术方案评审、代码规范落地的技术负责人对 Agent Skill 机制好奇想学会自己编写 Skill 的 AI 应用开发者。如果你只是想要一个复制粘贴就能用的绝招本文也会给但更重要的是我希望你理解这类 Skill 的设计逻辑然后改造成适合自己的版本。2. Skill 是什么与 MCP、普通 Prompt 的区别2.1 Skill 的本质Skill 在多个主流的 Agent 编程工具中都有落地比如 Claude Code 的 Skills、OpenAI Codex 的 Skill、Cursor 的 Rules 与技能区等。不同工具的实现细节有差异但整体思想是一致的Skill 是一组结构化的指令、模板、示例和可选脚本打包成一个独立目录让 Agent 在特定场景下自动加载或按需调用。说得再直白一点Skill 就是给 Agent 的能力补丁。它不是新的模型不是新的 API而是一套可复用的说明书。Agent 读到 Skill 文件之后会按照里面的规则调整自己的回答方式、工作流程和输出格式。一个 Skill 目录通常长这样skill-name/ ├── SKILL.md # Skill 主文件包含元信息和核心指令 ├── scripts/ # 可选可执行的脚本或工具 ├── assets/ # 可选参考文件、示例数据 └── references/ # 可选更详细的知识库按需加载SKILL.md是灵魂。这个文件里通常有 YAML frontmattername、description 等然后是正文指令。2.2 Skill 与 MCP 的核心区别这是很多人容易混淆的地方。搜索热词里agent skill 和mcp有什么区别热度很高说明这个问题确实困扰不少人。用一句话区分MCPModel Context Protocol解决的是Agent 能调用什么外部能力Skill 解决的是Agent 用什么样的方法和流程做事。MCP 是通信协议它让 Agent 可以连接到数据库、GitHub、浏览器、内部 API本质是扩展能力边界。Skill 是行为协议它不提供工具只提供思维方式、步骤模板和输出规范。可以用工作时的人类类比来理解MCP 好比你能使用的设备扳手、电钻、测量仪Sensor 好比你的操作手册先拆哪颗螺丝、按什么扭矩锁紧。没有设备很多操作做不了没有手册设备容易用错。两者在实际工程中经常配合使用。比如一个代码审查 Skill可以写清楚审查步骤和提问规则同时通过 MCP Server 读取 Git 提交记录、调用静态分析工具、扫描依赖漏洞。Skill 决定怎么审MCP 决定能审到什么。2.3 Skill 与普通 Prompt 的区别也有人会说这不就是一个比较长的提示词吗有相似之处但 Skill 做了几个关键升级结构化Skill 按固定目录存放元信息用 frontmatter 声明Agent 可以通过 description 自动判断是否加载。可复用Skill 文件可以提交到 Git 仓库、跨项目共享也可以放进团队内部的知识库。条件触发好的 Skill 会在合适的场景自动被 Agent 选中不需要每次都粘贴一遍提示词。可组合多个 Skill 可以同时加载一个负责拆解问题一个负责输出格式一个负责风险审查。理解这个区别有助于你正确评估 Skill 的工程价值。它不是魔法也不是单纯的字符串拼接而是一种轻量级的 Agent 行为工程手段。3.grill-me的思路拆解怎样设计一个高质量质询型 Skill构建 Skill 之前必须先想清楚设计目标。grill-me这个名字来自英文里的 grill someone意思是盘问、拷问通常指像烧烤架上翻面一样从各个角度逼问对方。做 Agent Skill 时需要把这种模糊的风格拆成一套可执行的规则。我把它拆成五个核心环节建立基线、挑战假设、追问边界、风险分级、给出可行建议。3.1 建立基线开场不要急着提问。Skill 应该先让 Agent 复述对用户输入内容的理解包括代码的功能、方案的目标、隐含的使用场景。这一步有两个作用确认 Agent 没有误读也让用户意识到AI 理解到的方案和我脑海中的方案是否存在偏差。如果没有这一步后续所有追问都可能建立在错误理解上效率反而更低。3.2 挑战假设这是 grill 风格的灵魂。Agent 需要主动找出用户输入中被当成理所当然的部分。常见假设包括这个接口的调用量真的像你预估的那么低吗这个第三方服务在极端情况下的可用性可以默认吗这段逻辑对数据量增长的容忍度足够吗这个设计对团队其他成员来说真的可维护吗为了让追问足够具体Skill 应该提供不同领域的质疑清单而不是让 AI 自由发挥。自由发挥容易给出缓存需要考虑、并发要小心这种正确但无用的废话。3.3 追问边界边界条件往往是缺陷的重灾区。Skill 要引导 Agent 关注失败路径、异常分支、权限场景、超时与重试、数据一致性等边界问题。一个判断标准是如果用户无法回答某个追问说明他可能还没有完全想清楚这个场景。此时 Skill 应该把该问题标记为待确认风险而不是替用户蒙混过关。3.4 风险分级单纯的连环追问如果不分级会让人觉得很吵、很烦最后失去参考意义。所以 Skill 必须对每个质疑点给出风险等级。我在设计 grill 类 Skill 时常用 P0/P1/P2 分级P0会导致功能错误、数据丢失、安全漏洞必须解决P1在特定条件下会出问题建议解决P2属于优化项可以延后。风险分级让 AI 的输出从感受变成可决策的信息。用户能直观看到哪些问题是上线前必须处理的哪些是锦上添花。3.5 给出可行建议只提问题不给方案等于让用户加班。Skill 在最后应该产出一份修改建议集合按优先级排序并尽量给出可操作的改法或示例。这五个环节共同构成了一个完整的 grill 闭环先理解、再质疑、再分级、最后给方案。这个结构本身也可以复用到方案评审、架构设计审查、文案校对等场景。4. 环境准备在哪个工具里运行 SkillSkill 机制的实现在不同工具中不太一样。以当前主流生态看比较常见的有Claude Code将 Skill 放入项目的.claude/skills目录或用户级~/.claude/skills目录。Codex可通过配置文件或自定义 Skill 机制加载。Cursor通过.cursor/rules或技能配置管理类似能力。DeepSeek、Cline、OpenCode等其他 Agent 工具也有各自的 skills/openclaw 等目录约定。由于各工具版本迭代较快不建议网上任何一篇教程里写死某一种加载命令就直接照抄。你操作时先查阅当前所用工具的最新官方文档确认目录路径和加载方式这是最稳妥的。不过一个好消息是Skill 的核心设计是通用的。即使不同工具的目录结构略有差异SKILL.md的编写逻辑、指令设计和辅助文件拆分方式是可以复用的。这也是本文采用通用思路 具体示例组合的原因。我在实战中建议按以下步骤准备环境选择你日常使用最频繁的 Agent 工具先用官方文档确认 Skill 的存放目录。创建 Skills 根目录前先用一个最小示例验证 Skill 能被正确加载。确认 Skill 的加载机制是自动触发还是手动触发方便后续调整 description 写法。把 Skill 目录纳入 Git 管理后续可以迭代和回滚。这里有个容易踩坑的地方部分工具要求 Skill 目录名与 SKILL.md 中的 name 字段保持一致否则可能识别异常。所以目录名尽量使用类似grill-me、code-review-lite这样的短横线风格不要使用中文名称或特殊符号。5. 完整示例构建一个 grill-me 风格的代码审查 Skill下面给出一个可落地的最小示例。这个示例以通用 Skill 目录结构为准复制到支持 Skill 机制的 Agent 工具中再按工具要求调整路径后即可使用。5.1 Skill 目录结构# 创建目录结构 mkdir -p grill-me/referencesgrill-me/ ├── SKILL.md └── references/ └── question-bank.md5.2 SKILL.md 主文件文件路径grill-me/SKILL.md--- name: grill-me description: 以高强度盘问的方式审查代码、技术方案或设计决策。当用户请求审查、挑战、把关、看看哪里有问题、review、critique时优先考虑加载本 Skill。适合代码评审、方案评审、风险排查、设计决策复盘。 --- # grill-me ## 角色 你是一位经验丰富、以严苛著称的技术评审专家。你不对用户保持礼貌性敷衍你的职责是通过高质量的追问帮助用户发现方案中的隐藏假设、边界漏洞和风险点。 ## 工作流程 ### 第 1 步复述理解 先用 200 字以内复述你对用户提供的代码/方案/想法的基本理解。包括 - 它试图解决什么问题 - 核心实现路径是什么 - 它的前置条件和适用场景是什么 确认理解正确后再进行下一步。 ### 第 2 步建立质疑基线 从以下维度逐一审查 - 正确性逻辑是否闭环是否存在必现或偶现 bug - 边界空数据、大数据、并发高、依赖超时、网络分区时会发生什么 - 安全权限校验、输入校验、数据暴露范围是否合理 - 可维护性六周后的新成员能否理解并修改这段代码 - 性能时间复杂度和资源消耗是否在可接受范围 - 依赖引入的新依赖是否值得有没有更轻量的替代 - 一致性与现有代码风格、架构约定是否统一 ### 第 3 步分级输出质疑 对每个发现的问题按以下格式输出 - [P0] 问题摘要一句话说明问题 - 证据指出代码位置或逻辑依据 - 为什么严重说明 P0 的必要性 - 建议改法给出可执行的修改思路 - [P1] 问题摘要一句话说明问题 - 证据指出触发条件 - 建议改法给出改进方向 - [P2] 问题摘要一句话说明问题 - 建议改法给出优化建议 ### 第 4 步补充追问 在输出所有问题后列出你仍然不确定、需要用户明确回答的问题。这些问题必须具体禁止使用定时任务是否考虑异常这种大而化之的问法应改成定时任务执行到一半进程重启已处理的任务是否会有重复消费 ### 第 5 步给出总体结论 用一段话给出综合判断当前方案是否可以进入下一步编码/提交/上线需要先解决哪些 P0 问题或可以带着哪些 P1 问题继续。 ## 注意事项 - 不要只夸优点也不要不分轻重全盘批判。区分关键风险和风格偏好。 - 不要泛泛而谈。每个质疑都要能落到具体代码位置、字段、函数或逻辑分支。 - 如果用户提供的输入明显不完整可以要求用户补充材料不要硬着头皮硬评。5.3 辅助问题库光靠主指令Agent 在具体场景中还是可能问得不够深入。辅助问题库可以在 SKILL.md 里用如果需要深入请参考 references/question-bank.md这样的方式引用让 Agent 在需要时按需加载。文件路径grill-me/references/question-bank.md# 深度问题库 以下问题按场景分类审查时按需选用。注意不是全部都要问而是根据被审查内容挑选最相关的 5 到 8 个避免审问疲劳。 ## 代码审查 - 这段代码在输入数据为空、重复、超长时分别会怎样 - 如果下游接口超时这段代码的行为是什么会无限重试吗 - 有无绕过权限校验直接访问资源的分支 - 日志里是否会打印敏感信息 - 有没有办法用更少的代码获得相同效果复杂度值得吗 ## 技术方案 - 方案的容量规划依据是什么基于哪些历史数据 - 与其他可选方案相比这个方案牺牲了什么换取了什么 - 方案上线后如何回滚回滚会影响数据完整性吗 - 方案涉及的变更如何拆分才能让评审者容易理解 - 团队需要新增哪些知识才能长期维护这套方案 ## 设计决策 - 这个决策改变后哪些模块会受影响影响范围你排查过吗 - 你现在选择这个方案是因为它最好还是因为你最熟悉 - 什么情况下你会推翻这个决策那样做的代价有多大5.4 Skill 调用与触发方式Skill 的调用方式依赖具体工具。大多数支持 Skill 的 Agent 工具会在对话中根据description自动匹配加载。比如你输入请按 grill-me 的方式审查下面这段用户登录接口代码 [粘贴代码]Agent 读到grill-me和审查关键词后就知道要加载这个 Skill。如果你的工具支持手动引用也可以在项目配置里把 Skill 设为默认加载例如在约束文件中写明涉及代码审查、方案评审、技术选型讨论时自动使用 grill-me Skill。在这个示例中我没有依赖任何特殊 API 或模型能力完全通过 Prompt 结构来改变 Agent 的行为。这也是 grill 类 Skill 的最大特点它不增加能力只调整思维模式。6. 运行验证与效果判断Skill 写完不是看一眼没问题就结束必须实际跑一轮验证。下面是验证路径。6.1 准备测试输入找一段你熟悉的、故意埋了多个坑的代码片段。比如一个没有做空指针保护、日志里打印了用户密码、超时处理缺失的 Service 方法。注意测试数据最好是你自己编写的不要拿生产代码去试避免不必要的干扰。6.2 触发 Skill在 Agent 工具里发起一次包含明确 Skill 意图的对话。例如使用 grill-me 技能审查下面这段代码重点看安全性和异常处理 [粘贴代码片段]6.3 判断标准一次成功的 grill-me 输出应该符合以下条件先有复述理解且复述内容与真实代码逻辑一致质疑点能落到具体代码行而不是空泛的建议优化性能风险分级明确P0/P1/P2 齐全每个问题都有证据和改法最后有总体结论能够帮你做决策。如果输出里全是建议使用枚举代替字符串常量这种几乎不算问题的建议说明这个 Skill 被弱化了。需要检查 SKILL.md 里的逐项审查指令是否被模型充分执行。6.4 失败时先看哪里Skill 不生效最常见的三个原因description 写得不够准确Agent 没在正确场景自动加载目录结构或路径不符合工具要求主指令太长模型在长上下文中丢失了关键指令。遇到问题优先检查这三项不要一上来就怀疑模型能力。7. 常见问题与排查方法以下表格总结了 grill 类 Skill 实操中常见的问题问题现象可能原因排查方式解决方案Skill 没有被自动加载目录结构错误或 description 触发词不匹配检查 Skill 目录路径和 SKILL.md 的 description 是否包含用户会使用的关键词修正目录结构在 description 中补充审查、把关、挑战、review等触发词输出的问题太泛、缺少证据测试输入不够完整或主指令没有强制定位到代码位置检查输出中是否包含文件名、行号或具体变量名在 SKILL.md 中明确要求每个质疑必须包含证据位置和触发条件盘问过于激进全是批评缺少平衡指令模型被引导成否定一切查看输出是否包含了总体结论和P2 优化项在流程中加入先复述理解最后给总体结论环节平衡批评与建设性Skill 在不同工具间无法通用各工具的 Skill 目录和加载方式不一致查阅两套工具的官方文档对比差异抽象出核心 SKILL.md按工具打包成不同目录格式上下文过长指令被稀释SKILL.md 过长或引用了过多辅助文件审查 Skill 的 token 占用精简主文件把长问题库放到 references 中按需加载提问过多用户疲于回答没有控制问题数量查看输出是否列了 10 条以上的追问在主指令中写明追问最多 5 到 8 条只保留最关键的问题与 MCP 工具配合不佳Skill 只做了提问没有读取真实数据检查是否配置了相关 MCP Server为 Skill 增加可选的 MCP 依赖说明在需要时通过 MCP 获取代码库信息8. 最佳实践与工程建议8.1 一个 Skill 只解决一类问题写 Skill 最大的诱惑是什么都想要。有人会在一个审查 Skill 里同时写代码规范、安全扫描、性能优化、文档生成结果每个方向都只能给泛泛建议。更好的做法是拆开grill-me通用方案/代码盘问spring-boot-reviewer专门针对 Spring Boot 项目结构的审查规则ui-design-reviewer专门审查 UI 设计稿和组件规范language-tutor专门做语言学习陪练。在SKILL.md的 description 里把场景写得越具体Agent 加载越准确输出质量越高。8.2 description 是触发核心模型判断要不要使用这个 Skill基本靠 description。写 description 时包含用户可能使用的动词如审查、review、把关、挑战、看看哪里有问题、critique包含适用场景名词如代码、架构方案、设计决策、PR 合并前写明不适用场景防止错误加载。一个好的 description 示例description: 高强度盘问式评审工具。适用于代码 review、技术方案评审、PR 合并前检查、设计决策复盘。当用户请求批判性分析、风险排查、逻辑挑战时使用。不适合生成新代码或写详细设计方案。8.3 主文件精简细节放 referencesSKILL.md主文件避免超过 300 行。领域规则、详细问题清单、代码规范等内容放到references/目录。这样既能保证核心指令稳定加载又给 Agent 保留了按需深读的空间。8.4 用示例输出校准格式在references/里放一段理想输出示例对稳定输出格式很有帮助。示例不需要很长但要让 Agent 明白好答案长什么样。比如# 输出示例 [P0] 接口未做幂等控制重复提交会生成两条订单 - 证据OrderController.createOrder 方法没有检查 requestId - 为什么严重客户端重试、消息队列重投都会导致重复数据 - 建议改法使用 requestId 作为唯一约束冲突时返回已有订单8.5 与团队协作和版本管理Skill 本质是代码资产应该进入 Git 仓库。建议放在独立仓库或项目根目录的skills/下团队成员拉取后即可使用。更新 Skill 时要写 changelog避免悄悄改了规则大家行为不一致。团队内部评审 Skill 的改进也像审查代码一样走 MR 流程。8.6 安全边界Skill 再聪明也只是提示词。涉及真实环境、权限变更、数据库操作、删除动作时必须让 Agent 明确告知用户确认后再执行绝对不要直接执行高风险操作。如果 Skill 要通过 MCP 访问代码仓库、云平台或内部系统请遵循最小权限原则只授予完成工作所需的最小访问范围。对于自动挖洞绕过认证等任何可能越权的场景不要通过 Skill 去实现。9. 总结与后续学习方向/grill-me的价值不在这个词本身而在它代表的一种人机协作思路给 Agent 增加不盲从的能力。本文从 Skill 的基础概念讲起理清了 Skill 与 MCP、普通 Prompt 的区别然后拆解了 grill 型 Skill 的五个设计环节复述、挑战假设、追问边界、风险分级和建议闭环。在此基础上给出了一个可直接复制的grill-me示例覆盖 SKILL.md 主文件、辅助问题库和调用方式并整理了常见的失败场景和排查方法。接下来你可以做三件事把文中的示例 Skill 抄下来在你常用的 Agent 工具里跑一次用一段你自己的代码测试输出质量。结合自己团队的技术栈做一个领域版本的 grill Skill比如 Spring Boot 审查、React 组件审查、API 设计审查。继续研究 Skill 与 MCP Server 的组合用真实数据源取代纯提示词让审查建立在代码库、监控指标和依赖信息之上。最后提醒一句Skill 不是一次写对就一劳永逸的。它会随着团队场景、工具版本和模型能力的变化而漂移需要像维护代码一样持续维护。建议把优化 Skill当成一个持续的小任务每个迭代都留一点时间打磨而不是等出了大问题再重构。收藏本文下次在评审方案被问倒的时候你可能会感谢那个愿意盘问你的 Agent。