让 AI 当你的"技术参谋"：选型与方案调研的实践

一、写代码是"实现题"，选型是"决策题"

日常开发里，有两类任务完全不是一回事：

一类是实现题——需求清楚，你只需把它正确地写出来。另一类是决策题——选哪个框架、用哪个库、上哪种架构、要不要换那套云服务。

实现题做错了，改回来就行；决策题做错了，返工成本可能是几个月。 而它偏偏最难：候选方案一大把，信息散在几十个网页里，每个人的偏好都不一样，还没有一套现成的评估标准。

这类"决策题"，恰好是 AI 能当个好参谋的地方——但请注意，是参谋，不是替你拍板的人。

二、AI 在选型里能帮什么

它不擅长替你承担后果，但它很擅长把"信息铺开"这件事干得又快又全：

1. 铺开候选与维度。列出可选方案，以及该看的对比维度——性能、生态、维护活跃度、学习成本、许可证、社区规模。
2. 按你的标准出评分表。你把硬约束和优先级交给它，它按标准生成一张对比表。有标准，对比才有意义；没标准，信息再多也只是一堆噪声。
3. 扮演"反方"。让每个方案都有人替它挑刺——列出它的风险、局限、典型翻车场景。想听拥护很容易，能挑刺才值钱。
4. 点出你没想到的约束。兼容性、迁移成本、团队熟悉度、许可证传染、三年后还有没有人维护——这些"隐性项"，常被兴奋于新方案的人忽略。

三、四步走：从调研到拍板

第一步：先写"决策标准"。
把约束拆成两类——硬性（必须满足，比如"许可证必须是 MIT"“要支持离线部署”）和软性（有优先级，比如"性能其次、团队上手第一"）。这一步花十分钟，能省后面十小时的纠结。

第二步：让它按标准产对比，并让每个方案"自我辩护 + 自我攻击"。
不要只问"哪个好"——那个问题它答不准。要问"在我的标准下，每个方案的得分与代价分别是什么"。

第三步：关键事实，自己核对。
版本号、性能数字、社区的活跃度、某个特性到底哪一版加的——以官方文档和实测为准。它的记忆会过时，描述会失真，而选型最经不起"用错的前提做决策"。

第四步：收敛成一张表，然后自己下决心。
把结果压成"一两页对比 + 一句推荐理由"。到这一步，拼图才拼全——而拍板这件事，交还给自己。

四、几个必须防的坑

• 信息时效。它"记得"的可能是两年前的版本，把早已改变的特性说成现状。带"最近/当前版本"的问题，尤其要警惕。
• 偏好主流。它容易偏向知名度高、资料多的方案，而忽略那个更小众、却更贴合你场景的选项。
• "看起来很全面"的假象。对比表做得漂漂亮亮，但其中某一列数字是它编的。抽样核对一两行，就能判断整张表的可信度。
• 立场漂移。同一件事，你换个问法，它可能给出相反结论——这恰恰说明它没有稳定的判断。越是这样，越不能让它替你拿主意。
• 把"调研"当"决策"。它产出的是素材和视角，不是结论。别把一张 AI 生成的对比表直接当决策依据。

五、几条边界

• 决策权和责任，都在人。AI 帮你看清选项、摆清代价，但不替你承担"选错了"的后果。
• 能实测就别只信描述。有条件的，搭个小 demo、跑个 benchmark，比读十段总结都管用。
• 团队现实 > 理论最优。维护成本、团队是否熟悉、招聘难度，经常比"纸面性能最高"更重要——而这些只有你清楚，AI 不知道。

六、结语

AI 是个称职的"技术参谋"：它能迅速把候选铺开、把维度摆全、把每条路的代价讲清楚，让你不再靠零散记忆和道听途说做决定。

但参谋终究不是指挥官。它负责让选择变清晰，你负责让选择变正确。 选型如此，很多事也一样——工具能帮你把牌看清楚，出哪张牌，还得你自己来。