最近在整理 Claude Code 的 skills 目录时我注意到一个名字很特别的项目grill-me。直译过来就是“拷问我”。第一反应是这不像一个工具更像一种提醒。大多数技能都在想办法让 AI 变得更主动、更高效但这个技能却在教 AI 反向提问逼着用户把想法说清楚。试了几轮之后我意识到它解决的是一个被很多人忽略的问题在 Agent 帮你写代码之前你常常没想清楚自己到底要什么。这篇文章不打算逐行复述某个开源项目而是想聊清楚 grill-me 这类 skill 的设计逻辑、使用方法以及怎么把它变成自己的工作流。grill-me 这类 skill 真正有价值的地方不是让 AI 来审问你而是通过结构化的尖锐提问把模糊需求变成清晰边界。它改变的其实不是 AI 的生成能力而是人机协作里最容易被人跳过的那一步需求澄清。1. 先搞清楚 grill-me 这类技能到底解决什么问题1.1 需求模糊是 AI 协作里最大的隐性成本我不知道你有没有遇到过这种场面你和 AI 说“帮我写一个用户登录模块”AI 很快就给出代码但需求里没写要不要短信验证、需不需要登录日志、token 放哪、超时时间多少。于是你来回改最后发现自己最初的需求描述几乎没有信息量。在传统开发里这个阶段通常是产品经理和开发反复对齐需求通过评审会、文档、原型图把问题暴露出来。但当你直接面对 AI Agent 时这个“对齐”环节被压缩成了一句提示词。如果你说得很模糊AI 只能通过合理的猜测来替你补全。它猜对了是你的运气猜错是你继续改。grill-me 这一类技能就是在补这个断裂它把需求对齐这一环重新拉回工作流。它通过一连串尖锐问题迫使你回答“这个功能给谁用”“输入输出是什么”“成功标准是什么”“失败怎么办”。这些问题不新鲜但它发生在你真正开始写代码之前这很关键。因为 AI 生成一遍代码的成本看似低实际却很高——你要读代码、跑测试、发现偏差、再调整提示词一个来回往往十几分钟。更麻烦的是这种偏差不是一次性的。很多时候你发现 AI 生成的第一版方向不对于是修改提示词但新的提示词又引入了新的歧义结果第二版也不对。几次往返之后你已经很难判断到底是模型理解能力不足还是自己的需求描述本身就站不住脚。grill-me 的价值就是在第一版代码生成之前先把“需求描述是否站得住脚”这个问题解决掉。1.2 从“给答案”到“提问题”协作逻辑变了传统提示词工程的核心是“写描述拿结果”。你描述得越精细结果越可靠。但精细描述本身是有门槛的大多数人在没有外力介入的时候很难意识到自己的描述漏了什么。grill-me 把顺序反过来了。它不是等你给出完整描述再执行而是先启动一个提问程序。整个过程更像是“访谈”AI 扮演一个不懂行的评审专家不断追问你的目标、限制、边界和预期。你可能觉得很烦但这些追问恰恰能逼出你觉得“理所当然”的细节。举个例子。如果我想让 AI 帮我生成一个“博客搜索功能”我最开始的想法可能只有一句话。但 grill-me 会问搜索范围是标题、正文还是标签数据量级是多少需不需要分词和拼音搜索超时多久返回搜不到结果时展示什么这些细节我可能压根没想过但它们直接决定技术选型。如果只有几百篇文章用数据库自带的模糊查询就够了如果有几十万篇文章就要考虑索引甚至搜索引擎组件。从协作逻辑上看这其实是把“模型适配人类模糊表达”变成“人类回答模型的澄清问题”。前者靠模型猜测后者靠人类思考。两种方式都需要但后者明显更适合复杂任务。所以我更愿意把这类技能称为“需求澄清器”而不是一个普通的 prompt 脚本。1.3 它真正改变的是“开始行动”的时机还有一个容易被忽略的点grill-me 改变了你的启动节奏。很多人已经习惯了一拿到需求就开始“产出”无论是写方案、写代码还是生成文案。这种习惯在简单任务里没问题但任务越复杂过早行动带来的返工成本就越高。grill-me 通过强制提问把“想清楚”和“做出来”之间加了一道平缓的缓冲带。你可能觉得它在拖慢速度但从整个任务周期来看它反而节省了时间。我见过不少团队用 AI 辅助开发经常出现周一生成一个完整模块周三发现需求跟实际业务不符又推倒重来的情况。问题不在于模型能力而在于开始之前缺少一次充分的需求提问。所以如果你发现自己经常和 AI 反复拉扯先不要急着换模型也不要不要钱地堆提示词。不妨先检查一下你的输入是不是足够清晰。grill-me 这类 skill 提供的不是答案而是让你在动手之前先把自己脑子里那些模糊的、互相矛盾的、甚至根本没想清楚的假设暴露出来。2. 为什么单次跑通不等于能稳定用好它2.1 安装和调用容易但理解提问逻辑才是关键很多人看到 skill 时第一反应是找安装教程、复制文件然后运行一次看到效果觉得“哦还挺好”。但 grill-me 这类 skill 和普通的“自动写代码”技能不太一样它的输出不是结果而是问题。如果你不理解它为什么会问那些问题只是机械回答一遍就很难产生增量价值。因为这套技能真正的产物不是问答记录而是你在回答过程中重新梳理出的思考路径。比如它问你“如果这个功能上线后没人用你怎么知道”你本来可能只是想快速做个演示原型这个问题会让你意识到你并不需要登录模块的完整权限体系只需要一个最简单的用户名和密码校验。这个判断非常重要同一个 skill用在原型验证、正式项目、学习实验里效果完全不同。只有理解了提问意图你才能决定哪些问题可以跳过、哪些问题值得展开。如果你不去理解提问逻辑很容易陷入“被动答题”的状态。AI 问什么你就答什么回答完发现还是要靠 AI 自己猜。这样一轮下来你只是把需求描述从一段话变成了几段话并没有真正澄清关键点。所以使用这类技能前最好先花十分钟把 SKILL.md 打开看一下理解它的问题域和流程。2.2 提问不是越多越好要分清“澄清”和“挑战”grill-me 风格的问题大概可以分成两类。一类是澄清型比如“用户是谁”“输入格式是什么”另一类是挑战型比如“你有没有考虑过并发失控”“如果第三方接口挂了怎么办”。澄清型问题适合任何场景能帮你补全信息。挑战型问题则带有压力容易把简单任务复杂化。如果你只是写一个小脚本AI 不停追问“生产环境负载是多少”“日志系统怎么对接”反而会把需求带偏。所以实际落地时我一般建议分两步先让技能只做澄清型提问把事实信息收集完整等任务复杂度上升再引入挑战型提问。有些实现好的 skill 会在 SKILL.md 里写明提问阶段和跳过条件但还有很多预设模板是全部问题一次性抛出。你需要自己控制节奏或者修改它的配置。这里可以做一个简单区分问题类型关注点适合场景可能风险澄清型目标、用户、输入、输出、边界所有任务开始前信息过载但值得挑战型风险、失败模式、扩展性复杂任务、生产系统让简单任务变复杂如果你分不清自己的任务属于哪种就先选择澄清型。等任务规模变大再逐步加入挑战型问题。这样既不会让简单任务变得沉重也不会让复杂任务埋下隐患。2.3 一个容易忽视的点它会消耗上下文长度这类技能还有一个隐性成本它产生的问答内容会占掉不少上下文窗口。如果你用的是一个长上下文模型还好但如果模型上下文有限一轮深度问答可能把后面生成代码的空间挤掉。我见过有人跑完一轮 grill-me 后模型开始“忘记”前面的技术背景因为上下文已经被几十个问题和回答填满。所以如果你在真实项目里使用我建议把问答结论压缩成一份结构化的“需求澄清摘要”然后把摘要粘贴回主对话而不是让完整问答日志一直留在上下文里。这一步看起来不起眼但决定了技能能否在复杂的 Agent 任务中被长期使用。单次跑通只是开始真正能用好它需要把提问结果转化成后续生成代码的有效上下文。3. 从零跑通一个 grill-me 风格技能的实际流程3.1 技能在 Agent 里通常放在哪SKILL.md 是什么如果你用过 Claude Code、Cursor 或类似工具对 skill 这个概念应该不陌生。它的通用做法是在项目目录下建一个.claude/skills/或~/.claude/skills/目录然后在子目录里放一个SKILL.md文件。Cursor 和 Codex 等工具也有类似的目录约定细节稍有不同但思路一致把一份指令文件放在模型能够发现的位置。SKILL.md一般会写清楚这个技能的名字、描述、适用场景以及具体的执行步骤。模型会在用户启动技能时读取这个文件并按里面的指令行动。很多开源 skill 也是按这个结构组织的。你不需要记住每个工具的路径差异只需要理解它本质上是把一份“指令说明书”放在模型能够找到的地方。如果你拿到一个 grill-me 风格的 skill第一件事不是直接复制代码而是先打开SKILL.md看看它怎么定义“提问”的。这是理解它行为的关键也是后面自己修改的基础。3.2 如果技能没生效按这个顺序排查很多人在第一次尝试 skill 时经常遇到“调用没反应”的情况。这时候不要急着重新安装按顺序排查先看目录位置对不对。技能文件必须在工具约定的 skills 目录下而且子目录名一般要等于技能名。再看文件名和格式。通常需要SKILL.md注意大小写和后缀。接着看 frontmatter 里的name和description。name要和目录名一致description要写得足够具体否则模型可能不会把它和你的请求关联起来。然后看上下文内容。如果你已经和模型聊了很多背景但没提到技能名模型可能不会主动调用技能。最后看工具配置。有些 Agent 需要单独开启 skill 功能或者需要在启动命令里指定技能目录。这套顺序基本能覆盖大多数“skill 不生效”的问题。如果还是不行就在主对话里直接问模型你当前环境支持哪些 skill让我看到你现在能读取到的技能列表。这样能快速判断是不是路径或权限问题。3.3 最小可运行示例用一个需求触发一轮“拷问”假设你正在使用 Claude Code并且已经把 grill-me 类技能放到了技能目录里。你可以先准备一个简单需求比如“我想给博客加一个搜索功能”。然后通过提示词启动技能比如“使用 grill-me 技能帮我审查一下这个需求我想给博客加一个搜索功能。”一般情况下技能会进入提问模式你可能收到这样的问题这个搜索功能是给谁用的作者自己还是所有访客搜索范围是标题、全文还是标签期望的搜索延迟是多少数据量级大概多少需不需要分词和拼音如果搜不到结果用户应该看到什么成功上线后你怎么判断它好用不好用这些问题看起来平淡但每个都会影响后续技术选型。比如数据量级那里如果你说只有几百篇文章那最简单的 SQL like 查询就够了如果说有几十万篇那就要考虑索引甚至搜索引擎组件。回答完这些问题你可能已经发现最初说的“加一个搜索功能”背后藏着很多没有定义的细节。这就是最小可用循环。3.4 输出结果怎么用从问答记录到需求澄清报告一轮问答完成后不要直接把它丢掉。建议让模型把这些问题和你的回答整理成一份“需求澄清报告”内容包括目标、用户、边界、输入输出、非目标、成功标准、技术约束。报告既是你继续对话的上下文也是后续写代码时的需求文档。如果你在团队里工作还可以把它发到协作群里让其他人评补。如果技能本身没有提供“生成报告”这一步你可以在问答结束后追加一句“把刚才的问答总结成需求澄清报告用表格输出。”这属于很自然的二次提示并不需要额外写 skill。我自己一般会把报告分成四段一句话目标、关键决策、边界和非目标、下一步行动。这样后面无论是让 AI 生成代码还是让同事接手都有清晰的入口。4. 怎么自己写一个“grill-me 风格”的技能4.1 Skill 的定义结构其实很简单很多人以为写 skill 是高难度操作其实核心就是写一个清晰的 Markdown 文件。最简结构可以像这样--- name: grill-me description: 在你开始编码之前通过一系列尖锐问题帮你澄清需求。 --- # 角色 你是一个严格但不失礼貌的需求评审专家。 # 任务 用户给出一个任务描述后不要立即实现先提问。 # 提问规则 - 一次只问一个问题避免信息过载。 - 按顺序覆盖目标、用户、输入、输出、边界、风险和成功标准。 - 如果用户的回答足够清晰进入下一个问题如果含糊继续追问。 - 全部问题结束后输出一份需求澄清报告。这个结构不复杂但它能把模型的行为从“给答案”扭转成“提问题”。关键是description要写得具体因为模型在调用技能时通常靠描述来判断是否命中。描述写得太泛可能不会被触发。4.2 设计问题清单的四个维度如果你要自己设计问题我建议从四个维度建清单而不是东问一句西问一句。目标维度用户想解决什么问题这个任务的“最小成功”是什么边界维度什么不在本次范围内允许哪些假设哪些情况明确不做资源约束维度时间、人手、数据、成本、技术栈有什么限制风险维度如果出错最坏情况是什么你怎么提前发现这四个维度基本可以覆盖大多数软件开发需求。在 SKILL.md 里把每个维度对应三四个问题一轮拷问就不会散。还可以加入一个维度验收标准。不过验收标准可以归到目标维度也可以单列。看你的偏好。这四个维度的顺序也值得注意。我建议先问目标和边界再问资源约束最后问风险。因为如果一开始就抛风险问题用户容易被吓到也容易把简单需求当成复杂工程。先让目标清晰风险讨论才更有意义。4.3 一个可以拿来改的 SKILL.md 示例骨架为了让文章有落地价值我提供一个更接近可用的示例骨架。它不绑定具体工具你根据自己的环境调整路径和调用方式。--- name: grill-me description: 在任务启动前对用户提供的需求进行系统化提问审查帮助发现遗漏和风险。 --- # 行为模式 用户提供一个需求后你进入提问模式。不要实现功能不要给方案先理解问题。 # 提问阶段 1. 第一轮目标 - 这个需求最终要解决什么问题 - 怎么判断做完了 - 有没有明确不做的事 2. 第二轮用户与场景 - 谁会直接使用结果 - 使用频率和使用环境是什么 - 用户的专业水平如何 3. 第三轮输入与输出 - 输入从哪里来格式是什么数据量多大 - 期望输出是什么形式 - 边界条件怎么处理 4. 第四轮约束与风险 - 技术栈、时间、成本有限制吗 - 高不确定性因素有哪些 - 如果失败影响面多大 # 输出要求 所有阶段结束后输出一份 Markdown 表格字段包括类别、问题、回答、影响。这个骨架你可以直接放到技能目录里试用。如果发现某些问题不适合你的业务就删掉。skill 的好处就是它不是黑盒所有指令都可以改。你在改 SKILL.md 时等于是把自己对项目的理解直接注入了 Agent 的思考方式这比在每次提示词里重复强调要稳定得多。4.4 一个技巧给技能设定“更具体的行业或角色”通用版的 grill-me 适合个人使用但如果你在团队里建议给技能加一个具体角色。比如“后端架构评审专家”“数据需求分析师”“内容编辑助理”。角色不同提问问题也会不同。比如后端架构评审专家会更关注接口契约、数据库设计、幂等性、缓存一致性数据需求分析师会更关注数据来源、口径、空值处理、更新频率。所以你在写 SKILL.md 时不要止步于通用问答而要把你所在领域最常犯的错误写进问题清单。这样改完之后的 skill已经不是一个单纯模仿 grill-me 的技能而是带有你团队经验的定制资产。这个资产价值会随着项目迭代不断增加。5. Skill 和 MCP 到底有什么区别5.1 一个是教模型怎么思考一个是给模型更多工具在搜索 grill-me 相关资料时一定会碰到另一个词MCP。很多人会问skill 和 MCP 不是一样都是扩展 AI 能力吗我在实践中得到的理解是Skill 主要通过提示词和流程定义来改变模型的行为方式MCP 则是让模型能调用外部工具和数据来源比如数据库、API、文件系统、浏览器等。换句话说Skill 影响的是“怎么想”MCP 影响的是“能做什么”。一个典型的 grill-me skill不接入任何外部服务只是给模型一套提问流程和角色设定。而一个查阅天气的 MCP server需要让模型通过工具去请求远程接口再返回结果。两者完全不在一个层级。这种区分非常重要。如果你把技能理解成“能操作外部系统的工具”就会对它的能力产生错误预期。比如你期待一个 grill-me skill 自动读取你项目的全部代码并基于代码提出问题这就超出了普通 skill 的职责范围。它最多只能结合对话上下文提问而不是去扫描代码仓库。5.2 从协作流程看两者的分工在实际 Agent 工作流里两者经常配合使用。比如你启动一个需求评审 skill它会问你问题当你需要查询当前系统的代码结构或数据库表结构时可能通过 MCP 获得真实数据再基于这些数据继续提问。所以不必把它们当成竞争关系。Skill 适合标准化流程、沉淀团队的协作经验MCP 适合打通环境、把外部系统接入 Agent。如果你一直困惑为什么 skill 不能直接操作文件那不是 skill 的定位问题而是你可能还需要一个 MCP server。一个比较自然的用法是先让 skill 生成需求澄清报告然后通过 MCP 获取真实系统信息再把信息和报告结合起来让 AI 生成方案。这个过程里skill 负责定义“要问什么”MCP 负责提供“回答问题的依据”。5.3 什么情况你应该优先用 Skill 而不是 MCP如果你是初学者只是想给 AI 增加一套“提问技巧”完全不需要碰 MCP。Skill 写一个 Markdown 文件就可以生效几乎零成本。如果要做复杂的自动化比如让 Agent 自动读取数据库、调用公司内部 API那才需要引入 MCP。场景优先选 Skill优先选 MCP让 AI 先问问题再干活是否让 AI 调用内部 API否是沉淀团队流程规范是否读取本地数据库否是给 AI 设定特定角色是否让 AI 发送 HTTP 请求否是我建议的选型判断标准是先看你要扩展的是“流程能力”还是“连接能力”。流程能力用 Skill连接能力用 MCP。如果两者都需要就组合使用而不是二选一。6. 这类技能的适用边界和长期使用建议6.1 适合什么场景不适合什么场景grill-me 风格技能最适合两类场景一类是需求本身比较模糊、但你希望快速澄清的项目另一类是复杂任务开始前你想避免漏掉关键约束的审查场景。比如设计系统架构、写技术方案、搭建新模块都很适合先跑一轮。它不适合的场景也很明显如果你只是在写一个一两行的正则表达式或者改一个明显的 bug不需要反问“用户画像是什么”。过度使用这类技能会让简单任务变得沉重反而降低效率。尽量把它用在对错误成本比较高的任务上。更适合 grill-me 的场景不适合 grill-me 的场景新功能设计一行改动技术方案评审临时修复报错需求文档整理简单问答跨团队协作前对齐已经明确的小任务一个判断标准是如果任务失败后损失的是几分钟重写时间那不需要 grill-me如果任务失败后你要花一天去返工那非常值得在开始前跑一轮提问。6.2 可能踩的三个坑第一个坑是把它当成 AI 审问于是顺着 AI 的问题不断输出但迟迟不进入实现阶段。你要记住它的目标是澄清需求不是开一场无休止的采访。当问题已经能支撑清晰实现时就该主动停止。第二个坑是问题与项目上下文割裂。如果你已经和模型聊了很多背景却只把当前一句话交给 skill它可能问出一堆你已经回答过的问题。遇到这种情况先把关键背景压缩成摘要再启动技能减少重复问。第三个坑是上下文污染。这个问题前面提过问答过程会占据上下文窗口。使用后要及时把结论整理成报告然后在正式任务对话中只引用报告而不是把原始问答全部保留。如果你发现模型在问答后开始忽略之前的技术背景大概率就是上下文长度不够了。我自己的习惯是跑完一轮 grill-me 后立刻让它输出需求澄清报告然后新开一个对话把报告粘贴进去再要求生成实现方案。这样既保留了澄清价值又不会污染后面的生成空间。6.3 把“拷问”沉淀成团队能力如果你所在团队经常做 AI 辅助开发这类技能很容易从个人工具变成团队协作资产。你可以把运行一轮 grill-me 后得到的问答记录整理成团队内部常用的需求澄清清单再反馈到 SKILL.md 里。这样下一次别人在使用时问题会更贴合团队业务。我自己比较推荐的做法是每个项目组维护一个自己的 skill 库里面除了通用技能还有针对项目架构、技术栈、发布流程的定制 skill。grill-me 这类提问技能是很好的起点因为它能帮你建立“先澄清再动手”的习惯。而一旦有了这个习惯你再用其他 skill 或 MCP 时产出质量会明显提升。具体推进路径可以分成三步先从个人使用一个通用 grill-me 技能开始把最容易出问题的需求场景试一遍。收集两三次有代表性的问答记录挑出团队项目里最常被忽略的问题。把这些问题改写成新的 SKILL.md 里的提问清单形成定制版技能。这件事看起来麻烦但一次投入能长期复用。团队里后来的人不需要再靠口头提醒也不会再因为需求模糊反复返工。你真正沉淀的不是一个 skill 文件而是一次次“拷问”之后总结出来的深层经验。也许你不需要真的去下载一个叫 grill-me 的技能但值得在你下一次让 AI 写代码之前先试着问自己三个问题目标是什么边界在哪里怎么判断成功如果你发现回答不上来那你需要的不是更好的提示词而是一场有针对性的“拷问”。这可能就是这类技能真正想教会我们的事。