用大模型做技术选型或方案评审时，一个常见的现象是：你问“该不该用Redis做缓存”，它会把Redis的优点列得整整齐齐；你换个问法“Memcached有什么优势”，它又能把Memcached夸得头头是道。模型倾向于顺着提问方向给出支持性回答，这种单一视角的输出看似有理有据，实则隐藏了对立面的信息，拿来辅助决策风险不小。解决思路并不复杂：在提示词里明确要求模型同时呈现正反方观点，并强制它做权衡分析，而不是只陈述一边的理由。
为什么模型容易陷入单一视角
从训练机制看，语言模型的目标是根据上下文预测最“顺”的 continuation。当你的提问带有倾向性，比如“为什么微服务比单体更好”，这个问题本身已经预设了结论，模型会优先生成与预设一致的论据，对立面的内容自然被压缩甚至省略。这不是模型“不知道”反方观点，而是提示词没有给它们出场的机会。
另一个原因是默认的回答风格偏“服务型”。模型倾向于满足用户的显性期待，你问优点它给优点，你问缺点它给缺点。如果你不做额外约束，它很少主动补全另一面。理解了这一点就明白，多角度输出不是靠模型自觉，而是靠提示词显式要求。换句话说，权衡分析必须写进指令里，成为任务的一部分，模型才会认真执行。
正反方观点提示词的几种写法
最基础的写法是“对照式”，直接在提示词中规定输出结构，正方论点、反方论点、各自适用条件。示例如下：
请分析"创业公司是否应该采用微服务架构"这一问题，输出格式如下： 1. 正方观点：列出3条支持采用微服务的理由，每条附带具体说明 2. 反方观点：列出3条反对理由，重点说明团队规模小、运维能力不足时的代价 3. 权衡分析：针对每对正反论点，说明在什么条件下正方成立、什么条件下反方成立 4. 结论：基于以上权衡，给出分场景的建议，不要给出绝对化结论
这种写法的关键在于“结构强制”。如果不规定输出格式，模型可能把正反观点混在一段话里，反方内容一笔带过。把结构写死成编号列表，并用“每条附带具体说明”约束信息密度，输出质量会明显提升。
第二种是“多角色辩论式”，让模型扮演持不同立场的角色互相辩驳。比如让一个角色扮演坚定的微服务倡导者，另一个扮演踩过坑的保守派架构师，再来一个中立主持人做总结。这种写法的好处是观点碰撞更真实，反方会直接针对正方的论点反驳，而不是各说各话。需要注意的是要限制轮数，两到三轮即可，否则对话可能冗长且重复。
第三种是“决策矩阵式”，适合有多个候选方案的场景。要求模型把各方案的关键维度（成本、性能、维护难度、团队熟悉度等）列成表格打分，并强制注明每个分数的依据。表格形式天然要求横向对比，单一视角很难在矩阵里存活。
避免权衡分析流于形式
要求了正反方观点之后，还有一个常见的坑：模型会“和稀泥”。比如反方观点写成“微服务也可能带来一些挑战”，这种空话没有任何决策价值。解决办法是在提示词里要求反方论点必须具体化，包含场景、代价和量化描述。可以加一句“反方观点必须指出具体的失败场景和大致的额外成本，禁止使用‘可能有风险’这类模糊表述”。
另一个技巧是要求模型区分“事实”与“判断”。让它在每条论点后标注这是普遍认可的事实，还是在特定条件下的经验判断。这样你在阅读输出时能快速识别哪些部分需要自己进一步验证，哪些可以直接采信。对于技术选型这类决策，还可以要求模型最后补充一句“如果我的前提条件是XXX，结论会怎么变化”，帮你提前想清楚关键变量。
最后要控制结论的确定性等级。可以要求模型把最终建议分为“强烈推荐”“可以尝试”“需要谨慎”“不建议”四档，并说明归入该档位的触发条件。这比一句模棱两可的“各有优劣”有用得多。下面是一个整合了上述约束的完整模板：
角色：你是一位中立的技术顾问。 任务：分析【待决策问题】，必须包含正反双方观点。 要求： 1. 正方与反方各列3条论点，每条必须包含具体场景、影响程度、适用前提 2. 论点后标注[事实]或[判断] 3. 禁止使用"可能有风险""看情况"等模糊表述 4. 权衡部分说明每对论点的冲突点和取舍依据 5. 结论按四档确定性等级给出，并注明触发条件 6. 补充：如果前提条件变化，结论如何调整
把这样的模板沉淀下来，遇到选型、评审、方案对比类问题时替换占位内容即可复用。多试几轮后你会发现，模型给出的不再是顺着你说的心里话，而是真正能帮你把问题想全面的参考材料。单一视角的问题，本质上不是模型能力缺陷，而是提问方式缺陷——把正反方与权衡要求写进提示词，答案的客观性立刻上一个台阶。