大道至简的胜利：/grill-me 这个神级 Skill 为什么比头脑风暴更好用
最近看到一个非常有意思的 Skill：Matt Pocock 的 /grill-me。
它的内容短到几乎不像一个“高级工具”：
---name: grill-medescription: Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".---
Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase, explore the codebase instead.只有几句话，但它击中了 AI 编程里一个非常核心的问题：需求不清楚时，模型越能干，越容易把错误执行得更彻底。
它到底做了什么？
/grill-me 的作用不是直接帮你写代码，而是不断追问你：
- 这个需求真正要解决什么问题？
- 哪些边界条件还没有说清楚？
- 不同方案之间有什么依赖关系？
- 哪些决策会影响后续实现？
- 哪些问题可以直接去代码库里验证，而不是靠你口述？
换句话说，它不是“灵感生成器”，而是一个需求压力测试器。
它会把一个看似已经可以开工的想法，拆成一棵决策树，然后一条分支一条分支地问下去，直到人和 AI 对任务形成共同理解。
AI 编程的第一原则：先把需求描述清楚
很多 AI 编程翻车，不是因为模型不会写代码，而是因为它在一个模糊目标上跑得太快。
比如你说：“帮我重构一下这个模块。”
这句话里面其实藏着大量未决问题：
- 是为了提升可读性，还是为了性能，还是为了后续扩展？
- 文件应该怎么移动？
- 跨模块依赖怎么处理？
- 循环依赖能不能接受？
- 测试要不要跟着改？
- 旧接口是否保持兼容？
- 哪些函数该合并，哪些模块该解耦？
如果这些问题不先问清楚，后面的“计划”看起来再漂亮，也可能只是把不确定性包装成了步骤列表。
所以，AI 编程时真正应该记住的是：
对需求和计划慢一点，实现时才能快一点。慢就是快。
为什么它比 brainstorming 更锋利？
原文作者做了一个很直观的对比：用 /grill-me 和 brainstorming 处理一个复杂的项目级重构。
这个重构涉及几十个文件移动、大量跨模块依赖、循环依赖、测试迁移、函数合并和模块解耦。结果是：
/grill-me问了将近 20 个问题，耗时约半小时；brainstorming只问了七八个问题；- 最终基于
/grill-me生成的计划执行得更顺，一遍过，100+ 测试全部通过； brainstorming看起来更热闹，有调研、有子 Agent，但计划反而更粗。
这其实很符合直觉：复杂任务最缺的不是更多想法，而是更少遗漏。
头脑风暴擅长发散；而 /grill-me 的价值在于收敛。它不急着给你方案，而是先逼你面对那些会让执行失败的细节。
极简 Prompt 的优势
/grill-me 的另一个优点是：它非常短。
这不是缺点，反而是优势。因为 prompt 越短，留给真实任务、代码上下文、对话历史和计划细节的空间就越多。
很多复杂框架的问题是：还没开始解决你的问题，系统提示词和流程说明就已经占掉了大量上下文。/grill-me 反过来只保留最关键的行为约束：
- 无情追问，直到共同理解；
- 沿着决策树逐个解决依赖；
- 每次只问一个问题；
- 能查代码就查代码，不要凭空问用户。
这几条足够简单，也足够强。
推荐用法
如果你要把 /grill-me 用在真实项目里，我建议按这个流程：
- 先描述你的初始计划或需求。 不要追求一开始就完美，先把目标说出来。
- 让
/grill-me逐个追问。 不要嫌烦，它问得越细，后面实现越稳。 - 追问结束后，让它写成计划文档。 比如保存为
plan.md，明确目标、边界、步骤、验收标准和风险。 - 清空上下文后再执行计划。 让执行阶段只面对干净、结构化的计划，避免被长对话污染。
- 再做一次 review。 可以让另一个模型、另一个 Skill，或者
brainstorming反向审查计划，看是否遗漏文件、依赖或测试。
这里最关键的是第 3 步和第 4 步。/grill-me 本身只负责问清楚，不一定会自动把沉淀写下来。问完之后如果不固化成文档，前面的追问价值会丢掉一半。
它的局限
/grill-me 不是万能的。
它的逻辑很简单，主要是追问；它不会自动生成复杂报告，也不会天然保证最终计划没有遗漏。原文作者也提到，交叉验证时发现 /grill-me 的计划漏处理过一个文件。
所以它最好不要单独使用，而是放在一个更完整的工作流里：
/grill-me负责把需求问透；- 计划文档负责把共识固化；
- review 负责找遗漏；
- 执行 Agent 负责按计划落地；
- 测试和构建负责给出最终反馈。
结论
/grill-me 的价值不在于 prompt 多华丽，而在于它提醒我们：AI 编程不是让模型更快地开始，而是让模型在正确的问题上开始。
真正高质量的自动化，不是跳过思考，而是把思考前置、拆细、问透。
当任务足够复杂时，最好的 Skill 可能不是一个庞大的工作流框架，而是一句朴素但严格的要求：
先别急着做。先把我问明白。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！
音乐
暂未播放