让 AI 出方案，它总给一个四平八稳的答案，怎么逼出真正不同的取向

数据截至 2026-07，各产品的额度与报错口径以官方最新说明为准。

你让 AI 给三个方案，拿回来三段读着不一样、骨子里一模一样的文字，多数人第一反应是”模型不行”或者”我描述得不够详细”，这两个归因基本都错。 真实原因通常是：你的需求描述里根本不存在可以分歧的支点，模型只能在同一条主线上换措辞。方案之所以不同，是因为它们在某个具体维度上做了相反的选择；你没说清那个维度是什么，它当然只会把同一个东西说三遍。

这篇按工程环节切，讲的是”方案设计”这一环：AI 能帮你到哪一步，哪一步必须你来定，以及怎么用可复核的动作确认你拿到的是真方案。站内另外两篇是相邻但不同的分工——AI 工具选型流程解决的是”这活该用哪个工具”，Agent 多方案判决解决的是”Agent 自己跑出多条候选后按什么规则收敛”，而本篇管的是它们中间那一段：怎么让候选在生成阶段就真的彼此不同。

一、先划清能力边界：哪一步它能做，哪一步只能你定

先把这一环拆开，省得后面在错误的地方使劲。

AI 在方案设计里真正靠谱的是三件事：穷举你没想到的可选路径、把每条路径展开成可读的实现骨架、指出某条路径里你会撞上的已知麻烦。这三件事它做得比多数人快，因为它见过的组合比你多。

它做不了、也不该让它做的是另外三件：定优先级（是先要上线速度还是先要可维护）、吃代价（选了异步就得接受一致性变弱，这个亏你愿不愿意认）、给事实背书（它说某个库支持某个特性，这句话的可信度是零，必须你去核）。

分歧支点属于第二类。方案之间的差别本质是”你愿意在哪个维度上吃亏”，这是价值判断，模型没有立场，所以它默认给你一个各方面都还行、哪方面都不突出的中庸解——这是它在没有偏好输入时的合理行为，不是缺陷。

判断标准很简单：如果你自己说不出这次设计里最想保住的是什么、最能牺牲的是什么，那你现在还不到问方案的时候，先去把这两句话写出来。

二、按现象分因：一张判别表

拿到 AI 的方案后先别急着挑毛病，对着下面这张表定位是哪一类问题。判别方法都能在几分钟内做完。

现象	大概率成因	怎么验证	处置动作
三个方案标题不同，正文骨架几乎一样	需求里没有可分歧的维度，只能换措辞	把每个方案的技术选型、数据流向、出错时谁兜底抽成三列并排看，三列填的一样就是换皮	显式指定分歧轴，要求每条轴上取不同的值
方案全都偏保守，只敢建议加缓存加日志	上下文里塞满了现有代码，模型把”最小改动”当成了隐含约束	另起一次提问，明确说允许推翻现有结构，看输出是否变化	分两次要：一次限定不动结构，一次强制重来，再对比
方案很有想法但落不了地，引用了不存在的接口	缺仓库事实约束，模型按常见做法脑补	让它逐条列出方案依赖的文件路径和函数名，你去仓库里逐个搜	搜不到的部分要么删掉，要么单独标成待验证，不许混在正文里
反复重问都给同一套	会话里已有的输出成了锚，后续都在它周围打转	开一个干净会话，用同一段描述重问	换会话、换切入角度、必要时换模型重问
方案数量对了，但没有一句取舍说明	你只要求了”给三个”，没要求”给代价”	检查每个方案里有没有写清楚它放弃了什么	要求每个方案必须写一条它明确不适用的场景
越追问越长，细节把主线淹了	追问方式是”再详细一点”	看结论段还能不能用一句话说清选哪个	先要一页纸的对比，细化只对已经选中的那一个做

这张表的用法是自上而下：先确认不是”换皮”，再看是不是”保守”，最后才怀疑事实层面。顺序反了容易出现你花半天核对了一堆事实，结果发现三个方案压根是同一个。

三、动作：把”给我三个方案”换成”给我三条不同的取舍主线”

定位完成后，下面这四个动作按顺序做，每个都有可验收的产出。

第一步，自己写出分歧轴。 不是让 AI 想，是你写。常见的轴就那么几类：自研还是用现成服务、同步还是异步、强一致还是最终一致、改数据模型还是在应用层绕、一次性重构还是分阶段迁移。挑一到两条跟这次任务最相关的，其余的先不管。轴选错了后面全是白费，所以这一步宁可多花十分钟。

第二步，让每个方案在轴上取死值。 描述需求时直接说：方案 A 在这条轴上取左端，方案 B 取右端，方案 C 取一个折中但必须说明折中点在哪。这么一约束，模型没有退回中庸的空间。它如果还是给三份差不多的东西，那是上下文污染，回第二节的表格第四行处理。

第三步，要求每个方案自带一条反对意见。 具体说法是：每个方案末尾写一段”什么情况下不该选它”，并且这段话不许出现”如果团队经验不足”这类万金油。这一步的价值不在于那段话本身写得多好，而在于它逼模型把方案的边界显性化——一个连边界都写不出来的方案，通常是它自己也没想清楚。

第四步，只对选中的那个做细化。 三个方案都展开成实现细节是纯浪费，而且细节一多你会被实现难度带跑，忘了当初是按什么标准选的。如果你用的工具有先出计划再动手的工作模式，这一步正好落在那里，Plan Mode 的用法里讲了怎么把计划和执行分开。

顺带说一句需求侧：如果你连要解决什么问题都还在飘，方案环节怎么折腾都没用。那种情况该往前退一步，用规格驱动开发的路子先把规格写清楚，再回来问方案。

四、验收：怎么确认拿到的是真方案

方案这东西没有自动化测试，但有几个可以当场做完的检查动作。

并排填表。 把三个方案的关键属性拉成一张表，行是属性（存储在哪、谁触发、失败怎么恢复、上线要改几个服务），列是方案。填完看有多少行是三列相同的。相同的行超过七成，基本可以判定是换皮，别自我安慰说”它们思路还是有区别的”。

做取舍反问。 挑任意两个方案问自己一句：如果我最看重的东西反过来了，我会不会改选另一个？答案是”会”，说明这两个方案确实站在不同位置；答案是”不会”，说明其中一个是冗余的，直接扔掉，两个真方案好过三个假方案。

事实抽检。 方案里凡是提到具体的库名、接口名、配置项名、文件路径，抽三到五处去仓库和官方渠道核。核不掉的先划掉。这一步不能省，方案阶段留下的编造内容会一路带到实现里，那时候修的成本高得多。仓库里搜一下就能定性：

git grep -n "SomeFunctionName" -- '*.ts' '*.py'

做一个最小验证。 如果两个方案的差别落在某个技术假设上（比如”这个接口能批量调用”），别争论，写十几行脚本试一下。开个独立分支或独立工作区，试完就扔：

git switch -c spike/plan-a-batch-check
# 写脚本、跑、把结论抄进方案对比表
git add -A && git commit -m "spike: 验证批量调用"   # 先落到这条分支上，工作区才是干净的
git switch -                                        # 回原分支
git branch -D spike/plan-a-batch-check              # 结论已经记在表里，分支直接扔

中间那次提交别省。试探产生的临时脚本如果不提交就直接切分支，改动会跟着你回到原分支，删掉分支也删不掉它们，过两天你会在工作区里看见一堆不知道哪来的文件。

关于什么算”通过”，最好在开工前就写死，否则验收会变成谁嗓门大谁赢。Agent 验收标准那篇讲的定标准方法，用在人写的方案上同样成立。

补一句模型选择上的老实话：换个模型重问确实能打破锚定，但部分海外模型官方在中国大陆有区域限制、不支持直连服务，规划工作流时别默认自己能用上。可行的做法是在官方支持的区域和渠道内使用，或者换用境内合规可用的模型；为了换个模型而把代码、需求文档送进来路不明的服务，风险远大于那点方案多样性。各家的可用范围和规则不同且会调整，以官方最新说明为准。

五、什么时候别再折腾了

这一环最容易出现的浪费，是明知道方案没出来还在一轮轮重问。下面几条到了就停。

同一段描述换了三次说法，并且至少有一次是在干净会话里问的，输出的骨架依旧一样。 干净会话这个前提要满足，否则你排除不掉上下文锚定这个更简单的解释——那种情况按第二节表格第四行处理，换会话重问一次就够。三次里包含了干净会话仍然同骨架，才可以判定不是表达问题，是你的分歧轴没定或者定错了。停止重问，回去写轴。继续问只会得到第四份换皮。

你已经开始跟模型辩论某个事实对不对。 一旦进入这种状态，说明缺的是外部信息不是生成能力。去查文档、去读源码、去跑一个最小脚本，几分钟能定性的事别用几十轮对话磨。

细化到了第三层还没收敛，反而分叉更多。 每一轮都冒出新的子问题，这是任务粒度过大的典型表现。回滚到上一版一页纸的对比，把任务砍成两块，先做能独立验证的那块。

调用侧开始出问题：接连返回 429，或者响应变慢到打断思路。 这时候拿到的输出质量本来就不稳定，人再硬撑着追问，判断力也在下降。挂起，换个时间段做。

回滚点定在哪。 我的做法是：每一版方案对比表都存成文件提交一次，哪怕内容很粗糙。这样任何时候发现跑偏，都能 git diff 出来看是从哪一版开始歪的，而不是凭记忆重构。方案文档本身不进版本库，是这一环最常见的隐性损失。

换条路的判断依据。 如果三次以上尝试之后，你依然说不清三个方案分别在保什么，那问题不在 AI，在于这个任务当前还没有可比较的选项——通常是因为约束太少（怎么做都行）或者约束太死（只有一条路可走）。约束太少就先砍范围，约束太死就直接实现，跳过方案环节。

六、避坑清单

坑一：一次性把全部背景倒给模型。 为什么会踩——直觉上信息越全结果越准。实际后果是上下文里的现有实现变成了强锚，模型所有方案都绕着现状打转，你要的”另一种取向”永远出不来。怎么避：第一轮只给问题和约束，不给现有代码；等方案骨架出来了，再喂代码做可行性检查。

坑二：用”给我三个方案”这种数量指令。 为什么会踩——它确实会返回三份，看上去满足了要求，验收很容易糊弄过去。怎么避：把数量指令换成维度指令，说清在哪条轴上必须取不同值，数量是结果不是要求。

坑三：让模型自己评选最优。 为什么会踩——它会给你一个看着很有条理的打分表，权重却是它自己编的，而权重恰恰是你唯一必须亲自决定的东西。怎么避：让它列事实和代价，评分和权重你来填；它可以帮你检查你的打分有没有自相矛盾。

坑四：方案和实现混在一次对话里。 为什么会踩——聊着聊着自然就开始写代码了，感觉效率很高。实际后果是一旦代码写出来，沉没成本立刻绑架决策，你会倾向于选那个已经写了一半的方案。怎么避：物理隔离，方案在一个会话里定完并落成文件，实现另开会话，起手先读那份文件。

坑五：把方案文档当成一次性的聊天记录。 为什么会踩——它看起来只是过程产物。实际后果是两周后有人问”当初为什么不用那个方案”，没人答得上来，于是重新讨论一遍。怎么避：方案对比表和被否掉的选项一起进仓库，被否的理由写一行就够，这行字未来能省掉一整场会。

坑六：分歧轴选了个假轴。 为什么会踩——比如把”用不用某框架”当轴，但这个框架在两个方案里都能用，取值不构成真取舍。怎么避：检验一条轴是不是真轴，看它两端是否导致不同的失败模式；两端的坏结果一样，那不是轴。

收束

方案设计这一环，AI 的定位是”选项生成器加可行性检查器”，不是决策者。它给不出真正不同的方案，绝大多数时候是因为你没有把分歧显性化——它没有立场，你得借它一个。

动手前对着这份清单过一遍：

• 我能用一句话说出这次最想保住什么、最能牺牲什么吗？
• 我写下的分歧轴是真轴吗（两端的失败模式不同）？
• 每个方案有没有自带一条”什么时候别选我”？
• 并排表里三列相同的行占多少？超过七成就是换皮。
• 方案里的库名接口名，我抽检了几处，几处核实了？
• 这一版对比表存进仓库了吗？
• 已经重问三次还是同一套骨架的话，我停手了吗？

前四条决定你能不能拿到真方案，后三条决定你会不会在同一个坑里连续消耗一整个下午。