Brainstorming 负责扩大解空间，grill-me 负责压实决策边界，AI 编程不能把两者混用。
导语
AI 编程里有一种很常见的错觉：只要在动手前多想一轮，后面的偏差就会少一点。
问题是，很多时候不是想得不够，而是用错了思考方式。你明明已经有了一个方向，却还让 Agent 继续发散；你真正需要的是把关键选择一项项压实，它却又给你铺开一大片看起来都对的可能性。
这就是 brainstorming 和 grill-me 最容易被混用的地方。
前者适合在空白处找路，后者适合在已有路线里逼出决策。一个扩大解空间，一个缩小歧义空间。
图：Brainstorming 打开可能性，grill-me 压实关键取舍
把它们当成同一种“需求澄清工具”，后面的开发会越来越像开着雾灯赶路：每一步都能走，但很难判断是不是走偏了。
Brainstorming 解决“我还不知道有什么”
Brainstorming 的价值不在于做决定，而在于把可能性摊开。
当产品还没有明确服务对象，功能还没有稳定形态，甚至连第一版应该打哪个场景都不确定时，发散是必要的。它像是把桌面清空，把所有可能的入口、用户、载体、约束都摆上来。先看见，再选择。
比如你想做一个 AI 实时表达助手，帮助用户在直播、口播、面试、会议里改进表达。这个阶段如果直接追问“第一版做什么”，很容易被过早收敛困住。更好的做法是先打开问题：
| 场景 | 可能能力 | 隐含约束 |
|---|---|---|
| 直播 | 话术提示、弹幕情绪识别、卖点提醒 | 延迟要低，提示不能打断表达 |
| 面试 | STAR 结构提醒、回答完整度复盘 | 用户更在意准备质量，不一定接受实时干预 |
| 会议 | 发言摘要、观点清晰度反馈 | 多人语境复杂，权限和隐私成本更高 |
| 口播 | 文案节奏评分、语气复盘、卡点建议 | 内容生产频率高，但工具要足够轻 |
这类输出不是方案，它是一张地图。
地图的意义是让你意识到：原来问题不止一种切法，价值也不止一种包装方式。你可以从场景切，可以从人群切，可以从设备形态切，也可以从“表达前训练”“表达中辅助”“表达后复盘”这样的工作流切。
Brainstorming 做得好，应该让人看到更多路，而不是马上推你上路。
Grill-me 解决“我以为想清楚了”
Grill-me 的工作方式完全不同。
它不继续扩展可能性，而是沿着一棵决策树往下走。前一个回答会改变后一个问题，所以它必须一问一答地推进。一次丢出十个问题，看起来高效，实际上会把依赖关系打散。真正有用的追问，往往是按顺序发生的。
用做饭打个比方。Brainstorming 是翻菜谱，红烧、清蒸、烤、炖、凉拌都可以先看。Grill-me 是你已经决定做红烧肉以后，继续问：用五花还是梅花？冰糖还是白糖？要不要八角？焯水多久？收汁到什么程度？
“做红烧肉”只是一个方向。能不能做成，取决于后面这些小决策。
放回 AI 产品设计里也是一样。还是那个表达助手，如果已经决定先做“表达后复盘 + 训练”，grill-me 该问的就不是“还有哪些可能场景”，而是：
问题：第一版锚定直播创作者，还是泛口播创作者？
推荐：先锚定直播创作者。原因不是直播更热，而是他们表达频率高、反馈闭环短，对转化指标更敏感。
问题：核心价值说成“提升表达质量”，还是“提高内容转化率”？
推荐：对创作者来说，转化率更直接。表达质量只是中间变量。
问题：第一版做实时提示，还是做录制后的复盘报告？
推荐：先做复盘。实时提示会遇到延迟、准确率和打断感三个硬问题，第一版容易把工程复杂度拉爆。
这不是灵感生成，而是压力测试。
每个问题都逼你做一个选择。更重要的是，它要求 Agent 给出推荐答案，这样用户不是在一堆选项里自己游泳，而是在一个可讨论的判断上纠偏。你可以同意，也可以反驳，但讨论终于有了靶子。
两个工具的分界线
Brainstorming 和 grill-me 最清晰的分界，不是工具名字，而是你所处的状态。
图：Brainstorming 负责发散，grill-me 负责压实
也可以把它们放进一个简单坐标系：
| 当前状态 | 需要发散 | 需要压实 |
|---|---|---|
| 没有方案 | 用 brainstorming 找到候选路径 | 不适合，容易空问 |
| 已有方案 | 可以补充遗漏选项，但收益变低 | 用 grill-me 逐项确认决策 |
混用之后会发生两种问题。
一种是已经有方向了，还在发散。结果是材料越来越多，方案反而越来越虚。另一种是还没有方向，就开始拷问细节。问题看似尖锐，其实没有抓手，只会把用户逼进随口回答。
真正的顺序通常很简单：
图：根据问题状态选择发散或拷问
这个链路里，brainstorming 不是前置文档工厂，grill-me 也不是需求审判官。它们只是把不同阶段的认知成本拆开处理：先看见足够多的路，再把选中的路走实。
对 AI 编程更关键的是“薄上下文”
在软件工程里，grill-me 还有一个额外好处：它不鼓励生成厚文档。
这点很重要。很多团队把前期澄清做成一套很重的流程，动手之前生成需求文档、设计文档、风险列表、验收标准、实现计划。刚写出来时看着完整，过一段时间就变成仓库里的旧家具。代码已经变了，文档还在，Agent 每次读上下文都被旧信息污染。
对 AI 编程来说，过时文档不是沉淀，而是噪声。
Grill-me 更适合产出很薄的上下文：这次实现到底采用哪个术语，哪些边界已经确认，哪些取舍不要再反复讨论。真正需要长期留下来的，不是大段解释，而是能影响代码生成的东西。
比如：
| 应该沉淀 | 不必沉淀 |
|---|---|
| 术语表：UI、变量名、文件名应该统一叫法 | 长篇背景介绍 |
| ADR：为什么选方案 A 不选方案 B | 会议纪要式推演过程 |
| Context：本次实现的关键边界和禁区 | 每轮问答的完整聊天记录 |
| 可验证约束：性能、权限、兼容性、数据口径 | “未来可扩展”这类空泛承诺 |
模型越强，工具提示反而越不该写成厚手册。一个短 skill 只要准确激活模式就够了：持续追问、按依赖顺序、一次一个问题、每问给推荐答案、能查代码就不要问用户。
复杂流程不是完全没用，但它很容易把“帮人思考”变成“拖着人走流程”。AI 编程最怕这个。用户只是想把一个方案敲实，工具却强制拉出完整规格、计划和评审，最后文档比代码更像主产物。
一次好的 grilling 应该怎么发生
好的 grilling 不只是 Agent 问得尖锐，用户也不能只点头。
如果每个推荐答案你都说“可以”，最后得到的方案并不一定是你的方案，而是模型默认经验塑出来的方案。更好的方式是把每个问题当成讨论入口，把你的真实约束说出来：以前踩过什么坑，哪些边界不能碰，哪些收益只是看起来诱人，哪些实现会让团队后续维护很痛苦。
一个有效的 grilling 回合，通常有几个特征：
· 问题足够小，小到可以当场做判断。
· 问题有依赖顺序，不把后置决策提前问。
· Agent 必须给推荐答案，否则用户只是在填问卷。
· 用户要补充背景，而不是只回答“是”或“否”。
· 对已经能从代码库里查到的信息，不再反复问用户。
尤其是最后一点。AI 编程里的很多问题不该靠问，而该靠查。比如项目用什么路由框架、状态管理怎么组织、已有组件有没有类似实现，这些都应该让 Agent 自己进代码库确认。Grill-me 应该拷问的是产品和工程取舍，不是把本该检索的信息丢回给用户。
真正的分工
Brainstorming 和 grill-me 不是谁替代谁的问题。
Brainstorming 负责把“未知的可能性”摊开。它让你知道还有哪些路径没看见，哪些假设可以被组合，哪些用户场景值得试。它适合混沌期，适合从零到一，适合还没选路的时候。
Grill-me 负责把“模糊的方向”压成决策。它让你知道第一版服务谁、先做什么、不做什么、为什么这样取舍。它适合方案期，适合从一到落地，适合已经选了一条路但还没有走稳的时候。
最怕的不是选错工具，而是在错误阶段使用正确工具。
没有种子时就拷问，只会在空地上逼问树枝长向哪里。已经选定种子后还继续发散，土都没埋下去，手里又多了一把新种子。
对 AI 编程来说，比较稳的节奏是：
图：两类决策工具在 AI 编程流程中的分工
这条链路不重，但够用。
它把思考留在动手前，把事实留在代码里，把长期知识留在少量稳定文档中。工具越轻，阶段越清楚，Agent 越不容易把你带进一套看起来完整、实际很粘的流程里。
最后可以用一句话判断：如果你还不知道有哪些路，先 brainstorm；如果你已经选了一条路但说不清怎么走，开始 grill。
扫一扫
186
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
