技术选型一直是开发者头疼的事情，选错了后期迁移的成本非常大。最近半年我开始有意识地用AI辅助做技术选型，踩了一些坑也摸索出了一些方法，今天分享出来。
传统选型的问题
以前做技术选型，我的流程一般是这样的：Google搜一圈、看几篇对比文章、问问身边用过的同事、然后凭感觉做决定。
这个流程的问题很明显。第一，搜索引擎上的对比文章大部分都过时了，技术变化太快，两年前的推荐现在可能已经不适用。第二，我们容易受到确认偏差的影响，如果心里已经倾向某个方案，就会不自觉地只看支持这个方案的观点。第三，每个人的经验都是有限的，身边的同事可能只用过两三个方案，给不了全面的比较。
AI的出现让这个流程可以做得更系统。
我的AI选型四步法
第一步：给AI提供完整的需求背景
这是最关键的一步，你给AI的背景信息越充分，它给出的推荐越靠谱。
我一般会包含这些信息：项目类型和规模、团队技术栈和人员情况、性能要求、预算限制、时间线、未来的扩展需求。
举个例子。我们要选一个消息队列，我给AI的描述是：“团队五人，都有Java和Go经验。日均消息量大概五十万条，峰值一百万。需要支持延时消息。部署环境是阿里云K8s。预算有限希望运维成本低。项目需要一个月内上线。”
这比直接问"Kafka和RabbitMQ选哪个"要有用得多。
第二步：让AI列出所有可选方案
不要一开始就限定选项。让AI根据你的需求列出所有可能的方案，包括你可能没听过的。
接上面的例子，AI除了列出Kafka、RabbitMQ、RocketMQ这些常见的选项，还推荐了Pulsar和NATS。如果我自己做调研可能根本不会考虑后两个，但AI提供了这些选项让我有了更全面的视角。
当然你可以让AI先简要介绍每个方案的定位和适用场景，初步筛掉明显不合适的，比如Kafka对于我们五十万日消息量的场景来说确实有些重了。
第三步：让AI做详细的对比分析
对筛选后的候选方案，让AI从多个维度做对比。我通常会要求这几个维度：
- 学习成本：团队现有技能能不能快速上手
- 性能表现：在我们预期的数据量下表现如何
- 运维复杂度：部署、监控、扩容有多麻烦
- 生态和社区：第三方集成、文档质量、遇到问题好不好查
- 成本：包括云服务费用和人力运维成本
- 可扩展性：如果未来量增长十倍能不能扛住
让AI以表格的形式输出对比结果特别清晰。每个维度按五分制打分，附上简要的理由说明。
第四步：让AI给出推荐并说明理由
最后让AI综合所有维度给出它的推荐方案，并且说清楚为什么推荐这个、什么情况下应该选其他方案。
AI通常会给出一个主推荐和一个备选。比如在消息队列的例子中，AI主推RocketMQ，理由是性能满足需求、原生支持延时消息、社区中文文档丰富、运维相对简单。备选RabbitMQ，理由是更成熟稳定、团队如果有Erlang经验可以优先考虑。
AI选型的优点
全面性。 AI可以在几分钟内列出几乎所有可选方案，包括你不知道的小众但可能更合适的技术。人力做到这个程度可能要花好几天。
客观性。 AI不会因为"我以前用过这个所以推荐这个"而产生偏见。它的评估是基于你给出的需求来的，相对客观。
速度。 传统选型可能要花一两周做调研和写对比文档。AI辅助的话，从提需求到拿到完整的对比分析可能只要一两个小时。
AI选型的局限
但AI选型也有明显的短板，不能无脑相信。
缺乏实际踩坑经验。 AI知道RocketMQ的官方文档写着支持延时消息，但它不知道实际使用中延时消息的精度在高并发时可能会有偏差。这种实战经验只有真正用过的人才知道。
可能推荐过时方案。 AI的训练数据有截止日期，它可能不知道某个库已经停止维护了，或者某个框架最近发布了重大的Breaking Change。
无法评估团队适配度。 AI不了解你团队每个人的真实水平和偏好。它可能推荐了技术上最优的方案，但你的团队用起来很别扭。
对中小厂商的了解有限。 AI对主流技术的了解比较准确，但一些新兴的小众方案可能信息不全或者有误。
正确的用法
我的建议是把AI定位为信息收集和初步分析的工具，最终的决策还是由人来做。
具体来说，AI负责列出所有可选方案、做结构化的对比分析、指出每个方案的优缺点。人负责结合团队实际情况做判断、验证AI说的关键信息是否准确、做小规模的POC验证。
最好的实践是用AI快速收窄到两三个候选方案，然后对这两三个方案做实际的技术验证。花一两天写一个简单的Demo跑跑看，比看任何分析文章都靠谱。
另外一个技巧是用不同的AI模型交叉验证。同一个选型问题分别问Claude、GPT和DeepSeek，如果三个模型的推荐方向一致那可信度就比较高，如果分歧很大就说明这个选型确实没有明显的最优解，需要你根据自身情况谨慎判断。
你们做技术选型的时候会参考AI的建议吗？有没有被AI带偏过或者AI推荐得特别准的经历？来评论区聊聊你的选型故事。