用AI做方案对比与头脑风暴：我的"军师"使用手册

做技术的人每天都要面对各种选择：数据库选哪个、架构怎么定、方案A和方案B哪个好。以前我习惯自己闷头想，想到一个方案就往下做，经常做到一半才发现有个更好的路。后来我把AI用成了自己的"军师"——每次做决策前先跟它过几轮头脑风暴和方案对比，思路开阔了不少，踩坑也少了。这篇文章分享我的完整方法。

一、AI做头脑风暴的正确打开方式

误区：问"你觉得我该选哪个"

最开始我问AI"MySQL和PostgreSQL我该选哪个"，得到的回答是教科书式的罗列优缺点，用处不大——因为AI不知道我的场景。

正确姿势：给足上下文，先发散后收敛

我的标准流程分四步：

第1步：交代背景——把场景讲清楚：数据量多少、并发多少、团队会什么、预算多少、运维能力如何、有什么约束（必须用XX云）。AI的回答质量完全取决于你给的背景信息量。

第2步：让它"发散"——不问"选哪个"，而是问"请给出3-5个可能的方案，每个方案的适用场景、优缺点、风险是什么"。AI会给我列出我没想到的方向，比如"可以不引入数据库而是用对象存储""可以用托管服务避免运维"——这些点子我以前自己根本想不到。

第3步：让它"收敛"——让AI根据我给的约束条件，对各方案做打分和排序，并解释为什么。这一步能快速缩小候选范围，但排序结果只做参考，因为AI对"我们团队的真实能力"判断不准。

第4步：让它"抬杠"——选出一个候选方案后，让AI扮演"反对派"，全力找出这个方案的不适："这个方案在什么情况下会失败？最坏情况是什么？"这一步是灵魂——它逼我把方案想周全，我踩的坑里至少有三分之一是被这一步提前发现的。

二、三个让我印象深刻的实战案例

案例1：日志系统改造

我要把团队日志系统从ELK迁走，背景给AI后，它列出了6个方向，其中"用对象存储+查询引擎"和"托管日志服务"是我完全没想过的。最终方案结合了AI的建议，成本省了四成。

案例2：消息队列选型

对比Kafka、RocketMQ、RabbitMQ时，AI给了一个我没注意到的维度：团队已有运维体系对哪个更友好。这比单纯比性能更符合我们小团队的实际情况。

案例3：数据库分库分表

"抬杠"环节AI指出：我们的查询模式大部分是单key查询，根本不需要分库分表，加索引+读写分离就够了——这个结论省掉了我们一大笔改造预算。

三、踩过的坑

1. 背景不给足，答案全是废话：这是最大的坑。AI是"镜像"，你给的信息越全，它的建议越靠谱。现在我写提示词的时间占了三分之一；
2. 别把AI的"自信"当"正确"：AI推荐方案时语气非常肯定，但它并不知道我们的真实代码和团队能力。凡是涉及"团队真实情况"的判断，必须以人为准；
3. AI会"趋同"：连续追问时，AI容易顺着你的语气走——你先说"我倾向A"，它就倾向于论证A好。所以我会故意"不说立场"，让AI独立分析；
4. 结果要存档：每次头脑风暴的结论我会存档，包括AI的建议、我的决策、最终原因——过几个月回头看，能发现自己当初的决策质量如何。

四、总结

我的使用手册总结成一句话：把AI当"军师"，不当"决策者"。它负责提供信息、发散思路、做对比，我负责判断"哪个方案适合我们团队"。这套方法用下来，我的方案质量明显提升，最大的变化是"先想清楚再动手"——以前是想到哪做到哪，现在是先让军师把路都探一遍，再选最稳的那条走。

如果你也常做技术选型和方案设计，建议从"背景+发散+收敛+抬杠"四步开始。花20分钟和AI过一轮，可能帮你省下几个月的返工。