前段时间在整理个人 AI 工作流时我发现一个很有意思的现象同样一份需求文档直接让 AI 评审它往往会给出“整体不错、略有风险”这类礼貌性结论但换一种方式让它以挑剔面试官的口吻连续追问很多隐藏问题立刻暴露出来。这个思路来自社区里流行的一种交互方式——/grill-me简单说就是让 AI 反复“拷问”你的方案、代码或想法直到漏洞被翻出来为止。更关键的是这种能力可以被固化成独立的 skill让 Claude Code、Codex、Cursor 等 agent 工具随时加载而不是每次手写一长串提示词。本文就围绕“如何写一个 /grill-me 风格的 skill”展开从前置概念、目录结构、SKILL.md 编写、安装调用到进阶设计完整拆解。无论你是刚接触 agent skill 的新手还是想沉淀团队内部规范的老手都可以按本文思路落地一个自己的质询型 skill。1. 背景为什么需要一个“拷问式”的 skill先聊一个常见场景。你负责一个后端模块的改造自认为方案已经完整缓存策略、降级开关、分表键、日志埋点都考虑到了。把方案发给 AI 助手做 code review结果它只是重复了你的设计最后补一句“注意做好监控和回滚”。这份 review 不能说错但没有产生增量价值。问题出在哪AI 的默认输出风格偏向“配合”它倾向于顺着用户的表达继续而不是主动挑战。当你用开放式提问比如“这个方案有什么问题”它很难做出足够尖锐的分析。但如果换一种交互方式AI 被设定成“必须连续追问、逐条质疑、不允许带过任何假设”结论会完全不同。/grill-me正是这种交互方式的代表。它模拟的是一群不同背景的评审专家围着你提问有人关注数据一致性有人关心异常恢复有人在意接口兼容性有人专门找边界条件。一轮轮追问之后AI 再把所有质询点和你的回应汇总成一份“压力测试报告”。这种机制非常适合以下场景代码 review 前自查先让 AI 找你方案里的漏洞再提交给同事。需求评审把 PRD 丢给 skill让它模拟运营、后端、测试、安全等角色反复追问。技术选型论证写清楚备选方案让 skill 不断挑战你的选择标准。面试模拟把简历和岗位要求交给 skill让它出题并追问。创业想法验证在写 BP 之前先让 AI 帮你把商业模式漏洞列出来。这类能力如果用普通提示词每次都要复制粘贴一大段角色设定、追问规则、输出格式很容易漏掉细节不同会话的表现也不稳定。把它封装成 skill 之后就能在多个项目中复用团队成员也能共享同一套质询逻辑。2. skill 的核心概念与工作原理2.1 什么是 agent skill技能skill可以通俗地理解成一个“可复用的能力包”。它通常是一个目录里面有描述文件、示例、参考规范甚至包含可执行脚本用来告诉 AI 在什么场景下应该怎么表现。以 Claude Code 为例它支持从~/.claude/skills/或项目.claude/skills/目录加载 skill。每个 skill 目录下都有一个SKILL.md包含 YAML 格式的元信息name、description和具体的指令正文。当用户提问触发 description 里描述的场景时模型会读取对应 SKILL.md 并遵循其中的流程工作。Codex、Cursor 的机制与此类似只是目录名称、加载方式存在差异。核心思想一致把特定领域的专业做法写进 Markdown 文档让模型在需要时自动参照执行。2.2 agent skill 与 MCP 的区别很多刚开始接触的人会把 skill 和 MCP 搞混这里简单做一个区分MCPModel Context Protocol是一种协议用来让 AI 调用外部工具和数据源比如查询数据库、调用内部 API、读写文件系统。它解决的是“AI 如何获取外部能力”。skill 是写在本地或项目内的一组指令和示例它不一定要调用外部服务纯粹靠提示词工程就能定义 AI 的工作方式。它解决的是“AI 如何按照专业流程输出”。换句话说MCP 是给 AI 接上“手和眼睛”skill 是给 AI 戴上“工作手册”。两者可以配合使用skill 中描述了工作流程流程里如果需要查数据或调接口再通过 MCP 工具实现。对于/grill-me这种偏思考类的能力通常只需要 skill不需要额外的 MCP 工具。2.3 /grill-me 的启发把“质疑”变成可复用流程/grill-me的核心价值不是“怼人”而是把一套高质量追问策略沉淀成固定流程。把它固化到 skill 中之后每次使用都会稳定输出几个环节第一轮澄清方案背景拆解目标与约束 第二轮分角色质询覆盖技术、业务、风险、边界 第三轮逐个漏洞追问不允许含糊跳过 第四轮输出压力测试报告包含风险等级与改进建议这个流程听起来简单但要用自然语言写清楚让模型每次都能稳定执行需要在 SKILL.md 里写足够具体的行为约束而不是只写一句“请质疑我的方案”。下面我们进入实战环节。3. 环境准备与目录规划3.1 工具说明本文的示例以通用 Markdown 格式为主不绑定某个特定客户端。你可以根据实际情况选择Claude Code适合已有 Claude 账号、习惯命令行操作的开发者。Codex适合使用 OpenAI 系工具链的开发者。Cursor适合在 IDE 中直接使用 AI 辅助的开发者。其他支持 skill 或 rule 的 agent 工具思路一致路径和加载方式按官方文档调整。由于不同版本的加载路径和规则解析存在差异这里不写死某个唯一路径。你需要以当前安装版本的官方文档为准我们只演示核心思路。3.2 skill 目录结构一个典型的 skill 目录长这样grill-me/ ├── SKILL.md ├── examples/ │ ├── input-plan.md │ └── output-report.md └── scripts/ └── save_report.pySKILL.md核心描述文件定义触发条件与质询流程。examples/示例输入和输出帮助模型理解预期效果。scripts/可选辅助脚本比如把质询记录保存为 Markdown 报告。如果没有脚本需求只保留SKILL.md也可以工作目录越简单越容易维护。4. 完整实战制作一个 grill-me 风格 skill这一节逐步实现一个可以直接使用的 skill。我们的目标很简单用户提供一份方案、代码或想法skill 负责以“评审团”模式进行多轮质询最后输出一份结构化压力测试报告。4.1 创建目录与 SKILL.md首先创建目录mkdir -p ~/.claude/skills/grill-me/examples如果你的工具是 Codex可以换成mkdir -p ~/.codex/skills/grill-me/examples然后创建核心文件SKILL.md--- name: grill-me description: 对用户提出的方案、代码、PRD、技术选型或想法进行高强度质询。当用户需要评估、评审、找漏洞、压力测试时使用。触发词包括“grill me”、“帮我挑毛病”、“压力测试这个方案”、“评审一下”、“帮我找漏洞”等。 --- # Grill Me Skill 你是一个由多位专家组成的评审团。你需要对用户提交的材料进行多轮质询帮助用户发现被忽略的风险、逻辑漏洞和边界问题。 ## 工作流程 ### 第一轮理解与拆解 先向用户确认以下信息如果用户已提供足够内容可以直接开始 1. 这份材料的核心目标是什么 2. 成功标准是什么 3. 有哪些显性约束时间、成本、技术栈、团队资源 4. 需要重点评审的维度是什么代码、架构、业务逻辑、性能、安全 如果用户没有说明可以默认按综合方案处理。 ### 第二轮分角色质询 依次扮演以下角色每个角色至少提出 3 个问题 - 资深后端工程师关注数据一致性、事务边界、接口幂等性、异常处理、依赖兼容性。 - 架构师关注扩展性、模块边界、部署方式、演进路径、过度设计。 - 测试工程师关注边界条件、异常路径、并发场景、脏数据、回归风险。 - 安全工程师关注权限校验、输入过滤、敏感信息、依赖漏洞、越权风险。 - 业务/产品负责人关注需求合理性、用户体验、埋点是否完整、是否解决真实问题。 每个问题要具体避免“你考虑过安全性吗”这种泛泛而谈更好的问法是“如果用户通过某个未校验的接口直接修改他人订单会发生什么”。每一次质询之后等待用户回答或确认再继续下一个问题不要一次性全部输出。 ### 第三轮深度追问 针对第二轮用户回答中暴露的风险点进行至少 3 轮追加提问。追问规则 - 如果用户说“已经考虑过 X”继续追问“有没有边界情况会导致 X 失效”。 - 如果用户说“后续再优化”继续追问“不优化会对当前目标产生什么影响”。 - 如果用户说“团队约定就是这样”继续追问“这个约定是否有文档新人如何知道”。 ### 第四轮输出压力测试报告 当用户说“结束”或“出报告”时按以下格式输出 markdown # 压力测试报告 ## 材料概述 用 3-5 句话概括原始方案 ## 质询过程摘要 列出最有价值的 8-10 个问题与结论 ## 发现的问题清单 | 风险等级 | 问题描述 | 影响范围 | 建议动作 | | --- | --- | --- | --- | | 高 | ... | ... | ... | | 中 | ... | ... | ... | | 低 | ... | ... | ... | ## 关键结论 用 3 个要点总结避免套话行为约束必须保持挑剔、直接、具体的语气但不要人身攻击。每个问题都要落到具体场景不要让用户做填空题。禁止在质询阶段就给出解决方案先聚焦发现问题。如果用户在某一轮回答“不知道”“没想过”把这个点标记为高风险项并继续追问。这里把核心逻辑都放在 SKILL.md 里角色分工、质询节奏、输出格式、行为约束。模型会根据这份说明来“表演”评审团。 ### 4.2 编写示例文件 为了让模型更清楚“输入到输出”的完整形态建议在 examples/ 下放两个示例文件。这是很多 skill 工程中容易被忽略的细节。 examples/input-plan.md markdown # 用户提交的评审材料示例 ## 方案名称 用户登录模块缓存改造 ## 背景 目前登录态校验每次都查数据库高峰期数据库压力大希望通过 Redis 缓存 token 降低数据库 QPS。 ## 设计方案 1. 用户登录成功后生成 token写入 RedisTTL 为 2 小时。 2. 网关层统一校验 token命中缓存则放行未命中则回源数据库。 3. 用户登出时删除 Redis 中的 token。 ## 期望评审重点 高并发场景下的正确性、缓存一致性、安全隐患。examples/output-report.md# 压力测试报告 ## 材料概述 该方案通过 Redis 缓存登录 token 来降低数据库压力核心流程包括登录写入、网关校验、登出删除。 ## 质询过程摘要 1. 如果 Redis 集群重启所有 token 失效用户是否需要重新登录 2. 如果某用户 token 被主动作废但旧 token 仍在 Redis 中缓存期内如何感知 3. TTL 2 小时期间用户权限变更是否允许旧 token 继续访问 ## 发现的问题清单 | 风险等级 | 问题描述 | 影响范围 | 建议动作 | | --- | --- | --- | --- | | 高 | token 续期逻辑缺失缓存过期后所有用户强制重新登录 | 全部在线用户 | 设计滑动续期策略 | | 中 | 权限变更无法实时同步到已缓存 token | 权限变更用户 | 增加版本号机制 | | 低 | 登录状态与 Redis 强耦合Redis 故障时登录校验不可用 | 全局 | 设计降级开关 | ## 关键结论 1. 方案整体可行但需要补充 token 续期与主动失效机制。 2. 权限变更场景需要引入 token 版本号。 3. Redis 故障时需要有降级路径。这两个文件本身也是很好的模板后续实际使用时可以直接参考。4.3 增加可选脚本保存对话报告纯 Markdown 的 skill 已经可以工作但如果希望每次质询结束后自动保存一份报告到本地可以用一个小脚本增强体验。下面是一个不依赖任何第三方库的 Python 脚本#!/usr/bin/env python3 # 文件路径grill-me/scripts/save_report.py 用法 python save_report.py --title 登录模块评审 --output ./report.md 从 stdin 读取报告内容也可以直接把报告写入指定文件。 import argparse import sys from datetime import datetime from pathlib import Path def main() - None: parser argparse.ArgumentParser(descriptionSave grill-me report to local file) parser.add_argument(--title, requiredTrue, helpReport title) parser.add_argument(--output, default./report.md, helpOutput path) args parser.parse_args() content sys.stdin.read() if not content.strip(): print(No report content received, skip saving.) return output_path Path(args.output) output_path.parent.mkdir(parentsTrue, exist_okTrue) now datetime.now().strftime(%Y-%m-%d %H:%M:%S) report f# {args.title}\n\n 生成时间{now}\n\n{content}\n output_path.write_text(report, encodingutf-8) print(fReport saved to {output_path.resolve()}) if __name__ __main__: main()使用时可以让模型在生成报告的同时调用该脚本把最终报告写入本地文件。实际使用方式取决于你的 agent 工具是否支持自定义命令如果不支持可以忽略这个脚本不影响 skill 本身的质询能力。4.4 安装到 Claude Code把整个grill-me目录放到 skill 路径后重新启动 Claude Code。输入帮我 grilling 一下这个登录缓存方案重点看高并发和一致性。或者直接输入/grill-meClaude Code 会读取SKILL.md中的 description当它判断当前请求匹配“评审、找漏洞、压力测试”场景时就会自动遵循质询流程。也可以使用/skills命令查看当前已加载的 skill 列表确认grill-me是否被正确识别。4.5 安装到 CodexCodex 的 skill 目录通常位于~/.codex/skills/同样把grill-me目录复制过去cp -r grill-me ~/.codex/skills/然后启动 Codex输入一段触发描述例如请 grill 一下我这段转账接口实现关注并发和幂等性。如果版本支持自动技能发现它会读取 skill 并按流程执行。如果不支持自动发现也可以在提示词里直接写明“请参考 grill-me skill 的流程”让模型主动读取对应文件。4.6 在 Cursor 中使用Cursor 的规则机制与 Claude Code 略有不同它更偏向“项目级规则文件”。你可以把 4.1 节编写的SKILL.md内容复制到项目根目录的.cursor/rules/grill-me.mdc中也可以写成AGENTS.md让 Cursor 自动读取。这一步的核心是让规则文件与项目绑定。对于每个人的全局工具不同客户端加载方式不同本文不强行给出统一标准建议以官方文档为准。4.7 运行与验证写完之后建议用一个简单的“测试方案”验证 skill 是否生效而不是直接把核心项目材料丢进去。比如先让 AI 评审下面这段“改进方案”为了提升查询性能我打算在订单表上直接增加 10 个冗余字段并在写入时同步更新。如果 skill 正常加载AI 应该问你冗余字段的一致性由谁保证同步更新失败的补偿机制是什么这 10 个字段的查询需求是否真的需要冗余而不是直接回答“这个方案很好”。如果它只是一本正经地夸你说明 SKILL.md 没有被正确加载需要检查目录路径、文件命名或 description 是否触发。5. 进阶设计让 skill 适配更多场景5.1 支持自定义提问风格不同场景下质询风格差异很大。评审技术方案需要冷静、直接模拟用户访谈则需要更温和的探索式提问。可以在 SKILL.md 中增加一个“风格开关”让用户通过一个变量控制模式。## 风格配置 如果用户提到“严格模式”所有质询必须更加简短直接不允许使用缓冲语。 如果用户提到“温和模式”每个问题前先确认用户的思路逻辑再指出可能的盲区。 如果用户提到“角色扮演”默认使用面试官/天使投资人/安全红队等角色。这样同一个 skill 能覆盖更多场景而不需要拆成多个文件。5.2 输出结构化报告默认输出表格已经足够。如果希望进 CI/CD 流程可以让 skill 额外输出 JSON 格式的风险清单方便后续程序解析。修改 SKILL.md 的输出部分当用户要求 JSON 输出时按以下结构返回 { issues: [ { severity: high, title: 问题简述, impact: 影响范围, suggestion: 改进建议 } ] }这种设计可以让 skill 从“聊天助手”变成一个可集成的质量检查工具。5.3 与其他 skill 组合一个 skill 不必覆盖所有能力。grill-me负责发现问题和输出报告另一类 skill 可以负责生成修复建议、补充测试用例、或者按规范改写代码。在实际项目中可以让 agent 先调用grill-me得到风险清单再调用“代码生成 skill”针对高风险项自动修复。组合方式不用写得很复杂关键是让每个 skill 职责单一描述清晰方便 agent 在合适的时机自动选择。6. 常见问题与排查思路在实际使用 skill 的过程中最常遇到的问题就是“模型根本不按 skill 来”。下面整理几个典型问题和排查方向问题现象常见原因解决思路模型没有进入质询状态仍然直接回答description 里的触发词不够明确或当前工具没有自动加载 skill检查目录路径是否使用SKILL.md命名多写几个触发词或在提示词中直接要求“按照 grill-me skill 执行”skill 被加载了但质询太浅SKILL.md 中的角色分工和问题清单写得不够具体增加更细致的示例问题并在行为约束中写明“必须提出具体场景问题”每次输出的报告格式不一致输出模板在 SKILL.md 中占比重太低把报告模板单独写成代码块并注明“必须严格按此格式输出”安装后没有生效缓存或客户端未重启重启工具检查/skills或等价命令是否能列出该 skill与现有 MCP 工具行为冲突skill 和工具的触发条件重叠在 description 中明确边界比如“仅用于评审和质询不负责查数据库”中文场景下偶尔失效模型对中英文混合描述理解不一致关键表述同时用中英文各写一遍尤其是指令性动作排查顺序建议为目录路径 → 文件命名 → description 描述 → 进程是否重启 → 是否有多个同名 skill 优先级冲突。7. 最佳实践与工程建议这一节把编写和使用 skill 的经验总结成可执行的规范。7.1 命名与目录规范skill 名称统一使用小写字母和连字符例如grill-me避免空格和中文。目录名与 skill 名称保持一致。每个 skill 目录下必须有SKILL.md这是大多数工具的默认加载入口。不要在一个 skill 中塞入过多主题保持职责单一。7.2 描述信息要面向“触发”description是模型决定是否加载 skill 的关键依据。不要写“评估方案”而要写“当用户需要评审、找漏洞、压力测试、grill me 时使用”。触发场景越具体自动命中率越高。7.3 指令要可验证一份好的 SKILL.md 不能只写“请专业地提问”而要写明具体步骤顺序。每个步骤产出什么。禁止做什么。如何判断用户是否满意。这样模型在跑完一个流程后自己和用户都能判断是否“完成了任务”。7.4 版本管理与共享建议把 skill 目录纳入 Git 管理并在 SKILL.md 中加入 version 字段name: grill-me version: 0.2.0 description: ...方便团队协作时追踪改动。如果你在公司内部推广可以建一个私有仓库统一管理 skill成员通过拉取代码的方式同步避免每个人维护一份漂移的规则文档。7.5 安全与边界不要要求 skill 自动修改生产环境配置。如果 skill 需要调用脚本务必检查脚本内容只保留必要的最小操作。对于涉及敏感信息的材料建议在提交前脱敏避免把密钥、客户数据直接写入对话。如果 skill 用于代码评审它给出的是建议不是最终结论最终变更仍需要人工确认并经过测试环境验证。8. 总结与学习路线本文从/grill-me的交互方式出发完整演示了一个质询型 skill 的创建过程。你学会了理解 agent skill 的基本概念以及它和 MCP 工具的边界。设计一个“评审团”式质询流程并把流程固化成 SKILL.md。通过示例文件和辅助脚本增强 skill 的稳定性。将 skill 安装到 Claude Code、Codex、Cursor 等工具中。下一步可以从两个方向继续深入第一把本文的grill-me改造成适合自己团队业务的版本补充行业特有的风险清单。比如电商项目可以增加“库存超卖”“支付幂等”等专项检查金融项目可以增加“资金安全”“审计日志”等维度。第二研究其他类型的 skill比如代码规范检查、数据库评审、UI 设计规范等逐步建立自己的 skill 库。当你积累的技能足够多时agent 就不再只是问答工具而更像一个携带团队方法论的数字员工。如果你在编写或安装过程中遇到了其他问题也可以对照第 6 节的排查思路逐项检查。无论你最终选择哪种客户端核心逻辑是一致的把专家的思考过程写清楚让模型可复现。