GrillMe技能9大失败模式与最佳实践指南

引言：GrillMe不是面试，而是一场对话

GrillMe和GrillWithDocs作为AI Agent中PlanMode的替代品，已经被全球开发者广泛使用。GrillMe和GrillWithDocs是Roo Code等AI编程助手生态中的自定义技能（Custom Modes），由社区开发者创建并广泛传播。与PlanMode让AI先生成实施计划再执行的方式不同，GrillMe采用苏格拉底式追问法，通过持续向开发者提问来逼迫其厘清需求、边界条件和技术决策，本质上是一种结构化的需求澄清流程。GrillWithDocs则在此基础上增加了文档上下文，让AI能基于已有代码库和文档进行更有针对性的追问。

然而，许多用户在实际使用中遇到了各种问题——有人反馈被AI连续追问200个问题，感到心理压力巨大。

这些技能的核心理念是：AI会毫不松懈地向你发问，直到双方就某件事达成共识。但关键在于，它依赖的是回答问题的人。换句话说，使用GrillMe时，你需要擅长规划、理解范围、清楚应该问哪些问题，以及要求回答所需的保真度级别。

这些技能的设计初衷是帮助你作为工程师，而不是取代你作为工程师的角色。以下是使用这些技能时最常见的9个失败模式及其解决方案。

理解问题的保真度层级

高保真问题与低保真问题的区别

借鉴Ryan Singer在《Shape Up》一书中的概念，问题可以分为两类。《Shape Up》是Basecamp（现37signals）公司内部孵化的产品开发方法论，于2019年以免费电子书形式发布。该方法论的核心思想是在项目启动前进行"塑形"（Shaping），即在抽象层面定义问题的解决方案轮廓，而非一开始就进入高保真的线框图或详细规格说明。Singer提出的"保真度"概念强调：在不同阶段应使用不同精度的工具来探索问题——低保真阶段用粗略的草图和文字描述就够了，而高保真阶段则需要可交互的原型或实际代码来验证假设。

• 高保真问题：需要聚焦到细节才能回答的问题。比如"这个界面实际使用时是什么感觉？""表单字段应该拆分成多个页面还是做成一个大表单？"这类问题只有通过高保真原型或实际构建才能真正回答。

• 低保真问题：不需要高保真原型就能回答的问题。比如"这个功能应该放在哪个URL上？"只需要一问一答就能解决。

失败模式一：在Grilling会话中试图回答高保真问题

第一个也是最常见的失败模式是：在Grilling会话期间尝试回答那些本质上需要更高保真度才能澄清的问题。有些问题适合被"拷问"（能在对话中得到答案），有些则无法通过对话来回答。

当遇到无法通过Grilling澄清的问题时，正确做法是使用Handoff技能将对话交接给一个原型设计会话。Handoff（交接）技能是AI Agent工作流中的一种协调机制，它能将当前会话的上下文、已做决策和未解决问题打包传递给另一个专门的会话或模式——类似于软件团队中的工作交接文档，保留了决策的完整链条和推理过程，避免信息在模式切换时丢失。在原型设计会话中以更高保真度探索问题，然后将学到的东西交还给最初的Grilling会话，继续提出适合被追问的问题。

范围控制是GrillMe成功的关键

失败模式二：Grilling的范围太大

如果你要盘问的东西太大，会遇到两个问题：

1. 隐藏的高保真问题：范围越大，越容易触及那些在没有真正看到完整内容的情况下难以回答的问题。在已有基础上继续构建总是更容易——你知道它可行，而且已经做得很好了。与其试图无休止地规划未来，不如一步步来。

2. 上下文窗口限制：如果范围铺得太大，最终会撞到模型的"Dumb Zone"。上下文窗口（Context Window）是大语言模型一次能处理的最大token数量。虽然当前前沿模型（如Claude、GPT-4、Gemini）标称支持128K甚至200K token的上下文长度，但研究表明模型性能并非在整个窗口范围内均匀分布。多项"大海捞针"（Needle in a Haystack）测试发现：当上下文填充超过约60-70%容量时，模型对中间位置信息的检索和推理能力会显著下降，这被称为"中间丢失"（Lost in the Middle）现象。大约12万token是大多数前沿模型进入性能下降区的经验临界点——即使模型理论上能处理更长的输入，实际的有效推理能力在此之后会明显衰减，表现为遗忘早期决策、重复提问、逻辑不连贯等问题。

解决方案：面对大范围工作时，提前让AI智能体将其拆分成更小的子范围，然后分别对每个部分进行Grilling。

主动性的平衡：避免两个极端

失败模式三：过于被动

很多超长的Grilling会话，问题出在用户太被动了。记住，这是一场对话，不是一场面试。AI在向你提问，但弄清楚方向、明确范围、确保一切按计划推进是你的责任。

如果你过于被动，AI就很容易问你540个问题、把范围炸得满天飞、问一些保真度不合适的问题。

失败模式四：过于主动

另一个极端是过于积极——一直揪着某个低保真话题不放地追问，而实际上你需要的是动手构建来看看效果。

关键原则：时刻审视自己在被动-主动这条轴上的位置，既要主动掌控方向，又不能固执到忽视了该进入编码阶段的信号。

珍惜Grilling会话中的决策成果

失败模式五：丢弃Grilling会话的上下文

一个让人抓狂的常见错误是：用户在Grilling会话中做出了大量优秀的设计决策（可能消耗了10万token），然后清空上下文，开一个新窗口运行2PRD。

这简直是暴殄天物！每一次Grilling会话中做的每一个决定都非常有价值，应该被记录下来并最终转化为代码，或者放进交接文档以便后续查阅。

正确做法：

• 如果上下文窗口还有足够空间，直接在当前会话中开始实现
• 如果需要退出，使用2PRD技能创建交接文档（PRD），而不是从零开始。2PRD能将一次可能消耗数万token的非结构化对话——包含大量试探、否定、修正和最终确认的决策——压缩为一份结构化的产品需求文档（Product Requirements Document），包含功能描述、用户故事、技术约束和验收标准等信息。这份文档既可以作为后续编码会话的输入（避免重新消耗上下文窗口来重建决策链），也可以作为团队协作的共享知识载体
• 务必保留已做出的决策，为它们创建某种交接工件

模型选择对Grilling质量的影响

失败模式六：用太笨的模型做Grilling

模型的知识来源有两个：

• 上下文知识：你传递给它的文件、提示、工具调用结果
• 参数化知识：模型训练时学到的内在理解

Grilling高度依赖参数化知识——我们依赖模型对系统和应用的内在理解，来提出我们还没想到的好点子和"天马行空"的想法。参数化知识（Parametric Knowledge）是模型在预训练阶段从海量语料中学习并编码在数十亿到数万亿参数权重中的知识，涵盖编程范式、架构模式、常见陷阱、最佳实践等。这种知识是"内化"的，模型可以据此进行类比推理和创造性建议——比如在你描述一个数据同步需求时，主动提出你可能忽略的并发冲突处理、幂等性设计或最终一致性方案。

当你这样依赖参数化知识时，你需要一个参数量大、训练水平顶尖的前沿模型。

有趣的是，到了实施阶段反而可以用更小的模型，因为那时大部分信息是上下文提供的（详细的实施计划、相关代码文件等）。具体的代码修改主要依赖上下文中提供的代码文件和实施计划，对参数化知识的依赖相对较低，因此可以使用成本更低、速度更快的模型来完成执行工作。

并行Grilling提升工作吞吐量

失败模式七：只开一个会话串行工作

提升效率的方法是同时开启多个Grilling会话。具体做法：在一个会话里回答问题后，切换到另一个会话（那边通常已经准备好了新的问题），如此来回切换。

这并不是真正的"上下文切换"——更像是管理两个独立的Slack线程。传统的上下文切换之所以代价高昂，是因为人需要重新加载工作记忆中的任务状态。但GrillMe的并行模式不同：每个会话的状态由AI维护，开发者只需要阅读最新问题并给出回答，认知负荷类似于在两个聊天频道之间切换。效率提升的核心在于消除了等待时间——当一个会话在处理你的回答并生成下一个问题时（通常需要10-30秒），你可以在另一个会话中工作。

通常建议最多同时开两个会话，超过这个数量后，维持每个会话决策一致性的认知成本会急剧上升。除非其中一个在执行耗时任务（如研究）时可以尝试三个。这样做吞吐量直接翻倍，而且随着熟练度提升，还可以进一步增加并行性。

GrillMe最佳实践清单

1. 区分问题保真度：低保真问题在对话中解决，高保真问题交接给原型设计会话
2. 控制范围：将大任务拆分成小范围，避免撞到上下文窗口限制（约12万token的经验阈值）
3. 保持适度主动：主导对话方向，但不要固执于低保真问题
4. 珍惜决策成果：不要丢弃Grilling会话中的上下文，使用2PRD创建交接文档
5. 使用前沿模型：Grilling阶段依赖参数化知识，需要聪明的模型；实施阶段可以切换到更经济的模型
6. 并行工作：同时开启两个会话提升吞吐量，利用AI响应间隙消除等待时间
7. 适时退出：当需要看到实际效果时，果断进入编码阶段

掌握这些原则，GrillMe将真正成为你工程规划中的强力助手，而不是一个让你疲于应付的问题机器。