如果你最近在关注 Claude Code、Codex、Cursor 这类 Agent 编程工具大概率会频繁看到同一个词Skill。热搜里“skill怎么用”“如何编写skill”“agent skill 和mcp有什么区别”这些词条几乎把 Agent 生态的焦虑写在了脸上——大家手里有了好用的模型却不知道怎么把自己的工作方法装进去。而grill-me就是这波 Skill 讨论里非常有意思的一个例子。这个名字直译过来是“拷问我”。它不是帮你写代码不是帮你读文档而是让 AI 反过来不停地质疑你的观点、拆解你的方案、攻击你的逻辑漏洞。我第一次看到这个思路时愣了一下我们习惯了 AI 当“应声虫”突然有一个 Skill 是专门让 AI 当“反对派”的这背后其实藏着一个很重要的判断——Agent 时代最有价值的能力不是让 AI 更顺从而是让 AI 更会审视。这篇文章不打算只停留在介绍/grill-me是什么。我会拆解它的工作原理解释 Agent Skill 和 Prompt、MCP 的本质区别然后带着你从零写一个受/grill-me启发的 Skill做完能直接装进 Claude Code、Codex 或 Cursor 里用。读完你不仅能看懂 Skill 是怎么运作的还能自己造出一个带个人风格的 Skill。1. 先搞清楚/grill-me到底解决了什么问题1.1 一个反直觉的现象用户开始要求 AI “别顺着我”过去一年AI 编程助手的核心卖点几乎都是“听你的话”。你说要什么它就给你什么。你让它改代码它就改你让它写方案它就写。这种“顺从”让 AI 工具的上手门槛变得极低但也带来一个副作用AI 的批判能力被默认关掉了。你带着一个有漏洞的方案去问 AI它大概率会顺着你的思路往下推甚至在五层推理之后帮你把漏洞圆回来。表面上看是“理解力强”实际是因为它没有立场也没有判断力。/grill-me这类 Skill 的出现说明用户的需求正在发生变化我不需要你认同我我需要你挑战我。1.2 grill-me 的工作方式推测从命名和社区讨论来看/grill-me的核心逻辑可以概括成三步用户抛出一个观点、方案或结论。AI 扮演一个严格的审视者从不同角度向用户提问。用户回答后AI 再根据回答继续追问直到把逻辑漏洞、隐含假设、数据缺口全部暴露出来。它本质上是一个“对抗式反馈机制”。和普通问答的区别在于它不追求“给出正确答案”而追求“逼你重新思考”。这个能力放到技术场景里非常实用。比如你写完一个系统设计方案想让 AI 帮你找漏洞而不是帮你润色。你准备在群里发一个技术判断想让 AI 先帮你把“会被别人质疑的点”列出来。你做了一个技术选型想让 AI 扮演“反方辩手”把另一种方案的优点全部摆出来。这些场景的共同点是你要的不是效率是盲区扫描。1.3 一个明确的判断/grill-me之所以能火不是因为它功能多复杂而是它踩中了一个真实的痛点大模型时代AI 的“顺从”正在变成一种信息污染。你问它“这个方案行不行”它很少说“不行”你问它“这两个框架哪个好”它容易给出一个平衡但无用的答案。Skill 的出现本质上是在给模型装上“人设开关”和“流程开关”。对开发者来说真正值得学的不是/grill-me本身而是它背后的设计思路把一种抽象的批判能力拆解成模型能执行的、可重复的流程。这才是 Agent Skill 的核心价值。2. Agent Skill 是什么和 Prompt、MCP 的本质区别要理解 Skill必须先把它放进 Agent 技术栈里看清楚位置。2.1 从 Prompt 到 Skill从“一次性话术”到“可复用流程”最早的 AI 编程助手大家用的是 Prompt。你把一段精心设计的话术贴在对话窗口里让模型按照你的要求来回答。Prompt 的问题在于每次都要复制粘贴容易出错。不同场景要维护很多段话术散落在各处。话术只能影响对话不能绑定工具、脚本或外部数据。Skill 做的第一件事就是把 Prompt 从“对话窗里的临时话术”升级成“文件系统里的正式资产”。一个 Skill 通常是一个目录里面有一个SKILL.md文件甚至还可以附带脚本、模板、参考文档。模型在对话时如果能感知到 Skill 的存在就会自动加载里面的内容来指导行为。这个变化的意义是结构性的Prompt 是“你说一次”Skill 是“你写一次模型以后每次都照着做”。2.2 MCP 和 Skill 到底有什么区别热搜里大部分人的困惑集中在“agent skill 和 mcp有什么区别”。这个问题必须解释清楚因为它们是两个完全不同的层次。维度SkillMCP本质指令与流程的定义工具与数据的标准化接入协议关注点模型“怎么思考、按什么步骤做”模型“能调用什么资源”表现形式文件夹、Markdown、脚本、模板服务端、客户端、工具定义、协议端点类比岗位说明书插座和插头标准典型问题先做什么、后做什么、按什么标准输出能不能查数据库、能不能调 API、能不能执行命令通俗理解MCP 解决的是“能力接入”问题让模型能安全地调用外部工具Skill 解决的是“行为编排”问题让模型知道拿到这些能力后应该按什么流程干活。一个 Skill 内部完全可以通过 MCP 去调用外部工具。Skill 负责“怎么干”MCP 负责“用什么干”。两者不冲突是互补关系。2.3 Skill 和 Plugin / Tool 的边界再对比两个容易混淆的概念Plugin / Tool通常指一个具体的、可被模型调用的函数或 API比如“搜索网页”“执行 Python 代码”“读取文件”。Skill是一个完整的工作流它可能包含多个步骤每一步可以决定是否调用某个 Tool也可以不使用任何 Tool 纯靠指令完成。换句话说Tool 是 Skill 流程中的一个环节Skill 是包含多个环节的“行动剧本”。2.4 为什么 Skill 是 Agent 时代的“个人方法论容器”Skill 最有吸引力的地方在于它把“一个人的工作方式”从脑子里搬到了文件里。一个资深工程师写代码时天然会先看需求边界、再设计接口、再写实现、再补测试、最后自查。这套流程以前只能靠人肉记忆现在可以写成一个 Skill让 AI 在每次任务中自动执行。这样带来的好处可复用一次写好处处使用。可分享团队里一个人写好了其他人可以直接安装。可版本化Skill 就是普通文件可以放进 Git 里管理。可测试用固定输入验证输出质量可控。/grill-me之所以能在社区扩散就是因为它被封装成了 Skill 的形态别人可以安装、修改、再创作。如果它只是一段聊天窗口里的 Prompt流传度和可演进性会差很多。3. 受/grill-me启发设计一个自己的 Skill理解了 Skill 的本质后我们开始动手。这一节先讲设计思路下一节给完整代码。3.1 确定目标做一个“方案挑战者” Skill/grill-me解决的是“AI 反驳人类观点”的问题。我不想简单复制它而是想做一个更贴合技术场景的变体名字暂定为plan-challenger。它的使用场景是你写了一个技术方案、重构计划、排期安排。你把方案贴给 AI。这个 Skill 不会夸你写得好而是执行一套严格的“找茬流程”输出一份带风险编号的评审意见。和/grill-me的不同在于/grill-me是对话式的它通过连续提问逼你思考。plan-challenger是一个完整的审查工作流它直接输出结构化报告更接近代码评审里的“反方评论”。3.2 设计核心流程把“挑战一个方案”这件事拆解成模型能执行的步骤我设计了六个阶段理解目标先概括方案要解决的问题确认没有理解偏。识别假设列出方案依赖的所有隐含假设并标记哪些是未经证实的。攻击最大风险找出如果出错会让整个方案失败的最关键风险。忽视的选项指出方案没有考虑的替代路径。改进建议针对每个风险给出具体改进方向。输出报告按固定格式输出。这个流程表面上是六个步骤但关键设计在于顺序先理解、再识别、再攻击、再补充、再改进。如果一上来就让 AI“找漏洞”它容易为了找而找输出一堆泛泛的“可能存在问题”。按顺序走模型的输出质量明显更稳。3.3 给 Skill 加一个辅助脚本Skill 不一定只能靠提示词它也可以带脚本。plan-challenger会附带一个 Python 脚本checklist.py用来对方案文本做一些简单检查比如是否包含明确的验收标准。是否提到回滚方案。是否注明依赖的假设。脚本的检查结果会作为报告的一部分输出。这样做的好处是让 Skill 的产出不完全依赖模型发挥而是有了一些确定性检查。当然脚本只是辅助。模型的推理仍然是核心。4. 完整代码实现目录结构、SKILL.md 与辅助脚本下面进入实操。本文的示例以 Claude Code 的 Skill 目录结构为例原因是它最通用。Codex 和 Cursor 的安装路径会在第 5 节说明。4.1 创建目录结构# 在 Claude Code 项目中Skill 放在 .claude/skills 下 mkdir -p .claude/skills/plan-challenger/scripts如果你不在 Claude Code 项目里也可以单独建一个目录。但为了方便测试建议放在一个真实项目的工作区里。最终的目录结构.claude/skills/plan-challenger/ ├── SKILL.md └── scripts/ └── checklist.py4.2 编写 SKILL.md 主文件文件路径.claude/skills/plan-challenger/SKILL.md--- name: plan-challenger description: 对用户提供的技术方案、设计文档或排期计划进行严格审查输出结构化风险报告。当用户粘贴方案并希望得到批判性反馈、找漏洞或评审意见时使用。 --- # Plan Challenger 你是一个严格的方案评审专家。你的任务是挑战用户的方案而不是讨好用户。 不要为了让用户开心而降低质疑标准。 ## 执行流程 ### 第 1 步理解方案目标 用 2-3 句话复述方案要解决的核心问题、主要路径和预期结果。 如果方案信息不足列出需要补充的信息然后继续后续步骤。 ### 第 2 步识别隐含假设 列出方案中所有隐含假设包括但不限于 - 对用户需求的假设 - 对技术环境的假设 - 对数据质量的假设 - 对协作方行为的假设 对每个假设标注已证实、未证实、存疑。 ### 第 3 步攻击最大风险 找到那个“一旦出错整个方案就会失败”的风险点。 要求 - 只选 1 个最关键风险不要平均用力。 - 说明为什么它是致命风险而不只是小问题。 - 给出这个风险发生的概率判断依据。 ### 第 4 步列出被忽视的选项 思考方案中可能被忽视的替代路径重点检查 - 是否可以直接购买现成方案而不是自研。 - 是否可以用更简单的架构替代。 - 是否可以直接复用已有系统。 - 是否应该先做一个更小的实验再决定。 ### 第 5 步给出改进建议 对第 2、3、4 步发现的问题分别给出具体建议。 建议必须满足 - 可执行不能只说“需要加强”。 - 注明优先级必须、应当、可以。 - 如果可能给出代码级别、配置级别或流程级别的改动方向。 ### 第 6 步输出结构化报告 按以下格式输出最终报告 markdown # 方案挑战报告 ## 一、方案目标复述 此处写方案目标复述 ## 二、风险清单 | 风险编号 | 风险描述 | 严重程度 | 发生概率 | 优先级 | | --- | --- | --- | --- | --- | ## 三、致命风险分析 此处写最致命风险的详细分析 ## 四、被忽视的选项 此处写被忽视的替代路径 ## 五、改进建议 | 建议编号 | 关联问题 | 建议内容 | 优先级 | | --- | --- | --- | --- | ## 六、最终判断 用一句话回答这个方案在当前信息下是否值得继续推进 答案三选一值得推进、需要修改后推进、不建议推进。注意如果用户没有粘贴完整方案请先引导用户提供方案而不是自己编造。所有质疑必须基于方案文本不能凭空猜测。当用户要求你“委婉一点”时仍然要保持严格但可以调整表达语气。输出报告时不要省略风险编号。### 4.3 编写辅助检查脚本 文件路径 text .claude/skills/plan-challenger/scripts/checklist.py#!/usr/bin/env python3 # -*- coding: utf-8 -*- plan-challenger 辅助检查脚本 对方案文本执行基础可靠性检查输出结构性结论。 import re import sys def check_plan(plan_text: str) - dict: checks {} # 检查是否包含验收标准 has_acceptance bool( re.search(r验收标准|完成标准|Definition of Done|done标准, plan_text) ) checks[验收标准] 通过 if has_acceptance else 未提及 # 检查是否包含回滚方案 has_rollback bool( re.search(r回滚|rollback|恢复方案|还原, plan_text) ) checks[回滚方案] 通过 if has_rollback else 未提及 # 检查是否包含明确的依赖假设 has_assumptions bool( re.search(r假设|依赖|prerequisite|前提, plan_text) ) checks[依赖假设] 通过 if has_assumptions else 未提及 # 检查是否包含时间节点 has_deadline bool( re.search(r时间节点|里程碑|milestone|排期|DDL, plan_text) ) checks[时间节点] 通过 if has_deadline else 未提及 # 检查是否包含风险说明 has_risk bool( re.search(r风险|risk|不确定性|可能失败, plan_text) ) checks[风险说明] 通过 if has_risk else 未提及 return checks def main() - None: # 支持从文件读取方案文本 if len(sys.argv) 1: file_path sys.argv[1] with open(file_path, r, encodingutf-8) as f: plan_text f.read() else: # 否则从标准输入读取 plan_text sys.stdin.read() results check_plan(plan_text) print( Plan Checklist 检查结果 ) print(f{检查项:12}{结果:8}) print(- * 30) for item, status in results.items(): print(f{item:12}{status:8}) print(- * 30) failed_items [k for k, v in results.items() if v ! 通过] if failed_items: print(f待关注项{, .join(failed_items)}) print(建议在方案中补充上述缺失内容并重新提交审查。) else: print(基础检查全部通过。) sys.exit(0) if __name__ __main__: main()4.4 脚本关键逻辑解释脚本做的事情很简单用正则表达式检查方案文本中是否包含几个关键要素。这么设计的原因是模型对“结构完整性”的判断有时会过于宽松比如方案里只写了“回滚”两个字模型可能会认为你已经考虑了回滚。脚本的检查更机械它只关注“有没有出现这个词”不判断“这个词用得好不好”。这个设计体现了 Skill 的一个重要实践确定性检查交给脚本开放性判断交给模型。两者结合比纯靠模型发挥更可靠。4.5 运行与验证单独测试脚本# 给脚本传一个测试文件 python3 .claude/skills/plan-challenger/scripts/checklist.py plan.txt也可以从管道输入cat plan.txt | python3 .claude/skills/plan-challenger/scripts/checklist.py预期输出示例 Plan Checklist 检查结果 检查项 结果 ------------------------------ 验收标准 未提及 回滚方案 未提及 依赖假设 通过 时间节点 通过 风险说明 未提及 ------------------------------ 待关注项验收标准, 回滚方案, 风险说明 建议在方案中补充上述缺失内容并重新提交审查。5. 安装与接入Claude Code、Codex、Cursor 通用思路不同 Agent 工具的 Skill 目录略有区别但核心逻辑一致把 Skill 目录放到工具能识别的位置然后在SKILL.md里写清触发条件。5.1 Claude Code 中的安装在项目根目录执行mkdir -p .claude/skills cp -r plan-challenger .claude/skills/重启 Claude Code 后输入一个方案模型应当能识别到plan-challenger并自动按流程执行。触发方式有两种自动触发当用户粘贴方案并表达“请评审/请找漏洞/请挑战”的意图时模型根据description自动决定是否加载。手动触发在对话中明确要求使用plan-challengerskill。5.2 Codex 中的安装Codex 的 Skill 目录通常放在~/.codex/skills/安装命令mkdir -p ~/.codex/skills cp -r plan-challenger ~/.codex/skills/不同版本的 Codex 对 Skill 的支持程度不同如果你的版本还不支持自动加载可以手动把SKILL.md内容作为系统指令添加到对话中。以官方文档为准。5.3 Cursor 中的安装Cursor 的规则目录通常支持把 Skill 作为规则文件导入。常见路径是项目下的.cursor/rules/可以把SKILL.md复制一份到该目录下并补充描述信息。注意 Cursor 的规则文件命名和 Claude Code 的 Skill 规格可能不完全一致需要按 Cursor 的文档调整格式。5.4 一个通用安装建议如果你在多个工具之间切换建议把 Skill 目录放到一个独立的 Git 仓库里统一管理mkdir -p ~/my-agent-skills cp -r plan-challenger ~/my-agent-skills/ cd ~/my-agent-skills git init git add . git commit -m feat: add plan-challenger skill这样不管是 Claude Code、Codex还是以后的工具都可以通过 git clone 快速安装。6. 运行效果与验证方式6.1 准备一份测试方案创建一个测试文件demo_plan.md# 订单系统重构方案 1. 将现有单体订单服务拆分为订单、支付、库存三个微服务。 2. 计划使用 Kafka 作为服务间异步消息中间件。 3. 重构期间保持旧的单体服务继续运行双写三个月后切换。 4. 团队共 6 人预计耗时 2 个月。6.2 在 Claude Code 中运行向 Claude Code 对话窗口输入请使用 plan-challenger skill 审查下面这个重构方案然后粘贴demo_plan.md的内容。预期的SKILL.md执行流程会输出一份方案挑战报告其中“致命风险分析”可能指向双写三个月的数据一致性校验方案缺失。Kafka 引入后事务性消息与本地事务的一致性问题没有设计。6 人团队同时维护新旧两套系统的资源分配假设过于乐观。6.3 如何判断 Skill 生效了判断标准不是“AI 有没有输出报告”而是以下几点报告是否包含风险编号如果没有编号说明它没有按SKILL.md的格式执行。是否出现了“方案目标复述”这个固定章节如果有说明流程被正确触发。最终判断是否明确给出“值得推进/需要修改后推进/不建议推进”如果含糊其辞说明流程被 AI 自行简化了。脚本检查结果有没有被纳入输出虽然模型不一定会主动调用脚本但你可以手动要求它执行脚本并整合结果。如果以上任意一点不满足首先检查SKILL.md的description是否写得太模糊导致模型没有识别到触发条件。6.4 脚本与模型的配合验证单独运行脚本python3 .claude/skills/plan-challenger/scripts/checklist.py demo_plan.md预期能看到“验收标准”“回滚方案”“风险说明”未通过。这个结果和模型输出的报告可以互相印证。7. 常见问题与排查方法问题现象可能原因排查方式解决方案模型没有自动使用 Skilldescription里的触发条件不清晰或工具没有扫描到目录检查 Skill 目录位置、重启工具、检查日志在description中明确写出使用场景或手动指定使用该 SkillSKILL.md 的格式没有生效frontmatter 写错或缺少name/description字段查看工具的错误日志检查 YAML 格式严格按照工具的 Skill 规格重写文件头模型输出了报告但格式不对模型把 SKILL.md 当成参考而不是指令在流程开头增加“你必须严格按以下格式输出”的强约束在 SKILL.md 中增加禁止自行改变格式的明确说明报告内容泛泛而谈没有深度流程步骤太粗模型没有经过逐步推理检查是否漏掉了“先复述再攻击”的顺序把流程拆得更细每步给出具体问题和示例脚本在运行时找不到文件路径写死或工作目录不对用python3 -m方式检查当前路径脚本内部使用相对路径或接收参数指定文件路径项目已有其他 Prompt 与 Skill 冲突多条指令互相覆盖检查用户级和项目级规则配置在 Skill 中明确优先级或用不同场景隔离Skill 在 Codex 中无法加载Codex 版本对 Skill 支持不完整查看具体版本官方文档先用手动方式粘贴 SKILL.md 内容验证效果再等待工具支持审查结果过于苛刻影响团队讨论没有设置表达语气的约束查看输出是否全部是负面评价在 SKILL.md 中增加“先承认方案的优点再挑战风险”的步骤8. 最佳实践与工程建议8.1 Skill 的命名规范与目录组织Skill 的命名推荐使用kebab-case例如plan-challenger、code-reviewer、sql-optimizer。不要使用中文名或带空格的目录名因为工具解析时可能出错。每个 Skill 目录内部建议统一结构skill-name/ ├── SKILL.md ├── scripts/ │ └── helper.py └── templates/ └── output_template.md把模板和脚本分离便于维护。8.2 description 要写“触发条件”不要写功能列表这是很多人第一次写 Skill 时最容易踩的坑。description字段的作用是让模型判断“什么时候该用这个 Skill”而不是“这个 Skill 很厉害”。错误示例description: 这是一个强大的方案审查工具能帮助你发现风险。正确示例description: 当用户粘贴技术方案、设计文档或排期计划并希望获得批判性反馈、风险审查或找漏洞时使用。判断标准很简单把这个description当作模型识别的信号如果它描述的是“用户输入什么样的文本时该触发”就是对的如果它描述的是“我能做什么”就太模糊了。8.3 步骤要原子化一次只做一件事在SKILL.md中步骤设计要遵循“原子化”原则不要写“全面分析方案的优缺点”而应该拆成“先列优点再列风险再列被忽视的选项”。每一步的输出应该可以被后续步骤引用。如果步骤超过 10 步建议检查是否有冗余。原子化的意义在于模型在长推理中容易丢失目标。步骤越细模型的输出越稳定。8.4 把关键决策点写进格式约束不要只告诉模型“要严格审查”而要说清“输出报告必须包含风险编号”。这个区别体现在SKILL.md的“注意”部分也体现在最终的格式模板里。如果某个输出项对你很重要比如“必须给出最终判断”就要在模板中强制出现并且说明不允许省略。8.5 先个人使用再团队推广Skill 的迭代过程和代码演进很像先在自己项目里试用观察哪些步骤有效、哪些是废话。根据实际输出反推修改SKILL.md。稳定后再提交到团队共享仓库。在团队中运行时收集反馈并补充典型场景。不要一上来就做一套“面向所有场景”的大而全 Skill。小步快跑一个 Skill 只解决一个问题。8.6 安全与合规边界编写 Skill 时要注意不要在 Skill 模板中写入敏感信息比如数据库密码、内部域名、私有 API Key。如果 Skill 会调用外部脚本必须在脚本中做输入校验避免把用户的恶意文本直接拼进系统命令。在公共仓库分享 Skill 前检查是否泄露了团队内部约定或代码细节。生产环境使用 Skill 自动执行操作前先在本地环境中验证并确保有回滚手段。8.7 怎么把日常操作沉淀成 Skill一个很实用的问题怎么把 Cursor 里的操作过程变成一个 Skill这也是社区里常见的需求。通用步骤是把你手工执行的操作流程记录下来按顺序写成一个 checklist。把 checklist 转成SKILL.md把需要用户输入的部分抽象成变量。设定触发条件什么情况下该自动执行这个流程。用一个最小样例测试调整指令。完成后再考虑是否添加辅助脚本。关键在于你沉淀的不是“操作步骤”而是“判断规则”。模型不缺执行能力缺的是“什么情况下做什么决定”的规则。8.8 Skill 与 MCP 的配合模式一个成熟的 Agent 工作流往往是 Skill 和 MCP 配合使用Skill 负责流程编排定义“先干什么、后干什么”。MCP 负责提供能力比如搜索、查询数据库、执行命令。如果你的 Skill 需要读取外部数据建议通过 MCP 暴露工具接口而不是在 Skill 里直接写死路径。这样 Skill 更通用MCP 也更可复用。9. 总结与后续学习方向这篇文章从一个反直觉的现象开始现在的用户开始要求 AI “别顺着我”。/grill-me之所以受欢迎说明“对抗式反馈”已经变成了 Agent 生态里真实存在的需求。而 Skill 这个概念正是把这种抽象的批判能力变成可复用、可版本化、可传播的文件资产的关键。随后我们动手写了一个plan-challengerSkill完整覆盖了目录结构、SKILL.md编写、辅助脚本、安装接入、运行验证和排错路径。这个 Skill 不一定是最完美的但它演示了 Skill 开发的核心方法论把抽象能力拆成有序步骤。用格式模板约束模型输出。用脚本做确定性检查。用描述字段设置触发条件。如果你接下来想继续深入方向有几个试着给plan-challenger接入 MCP 工具让它能自动读取代码库并检查方案与代码现状是否一致。把 Skill 提交到 Git 仓库用版本管理跟踪迭代过程。写一个针对你自己团队的“周报审查 Skill”或“代码提交信息规范 Skill”体会“个人方法论容器”这个定位。研究一下不同工具Claude Code、Codex、Cursor的 Skill 加载机制差异你会发现它们的实现思路各不相同但核心逻辑都是“文件 描述 流程指令”。最后提醒一点Skill 的价值不在数量而在质量。与其收集一百个别人的 Skill不如花一个下午写一个真正贴合自己工作方式的 Skill。从一个小场景开始让它跑通再慢慢加步骤、加脚本、加模板。当你把一个重复做了很多遍的工作流程成功“教”给了 AI你会明显感受到 Agent 从“玩具”变为“队友”的临界点在哪里。