做技术选型这么多年我最大的感受是真正难的不是技术本身而是在一片模糊里做决定。你手上有二十个方案每个方案都有人站台每个方案都有翻车案例最后往往拼的是谁的嗓门大或者谁更熟悉某个技术。后来我开始把AI当作选型副驾驶让AI辅助决策这套方法帮我省下了大量查资料和撕扯的时间。这篇文章把我踩过的坑、用过的提示词和决策模板一起整理出来希望能让你的下一次技术选型少一点玄学多一点可追溯的判断依据。1. 为什么技术选型需要AI辅助决策1.1 传统选型流程的三个痛点先说痛点不然你不知道为什么非要用AI。第一个痛点是信息收集成本高。你以为你熟悉某个技术其实你熟悉的是它三年前的模样。我去选型的时候最怕的从来不是“没方案”而是“不知道自己不知道”。数据库选型可能漏掉新的云原生方案消息队列选型可能漏掉自带流处理的中间件等开会开到一半突然有人翻出一个冷门方案整个评估又要重来。第二个痛点是决策维度太多人脑算不过来。功能、性能、社区活跃度、许可协议、团队熟悉度、运维复杂度、未来扩展性这些维度叠在一起靠一张Excel表硬比很容易比着比着就开始凭感觉打分。尤其当多个方案分数接近的时候谁更会讲故事谁就赢了。第三个痛点是团队偏见和路径依赖。人是有惯性的用Java的人天然觉得Java生态才是正道用Go的人觉得Go的并发才是未来。这种偏见放在个人身上没问题放在技术选型里就是大坑。因为选型一旦定下来后面三年所有人都在为这个决策买单。这三个痛点不是简单多搜两篇资料就能解决的你需要一个没有情绪、能快速整理信息、愿意被反复追问的助手。AI辅助决策正好把这块短板补上。1.2 AI不是决策者是信息整理器和“杠精”我要先说清楚一个立场AI辅助决策重点在“辅助”不在“决策”。AI做得好的是信息整理、候选方案枚举、对比维度补全、风险点反向提醒。比如你问“作业系统用定时任务还是消息队列”AI可以把两种方案在可靠性、时效性、运维成本、故障恢复上的差异列成表格让你一目了然。这个过程效率极高比你自己翻十篇博客快得多。但AI做不好的是对你们团队实际情况的理解。它不知道你们有多少人能维护这套系统不知道你们的生产环境有多老也不知道你们老板对工期有多敏感。这些信息只在你脑子里你得主动喂给它。所以我的用法是把AI当成一个非常博学但没有工作经验的顾问我先告诉它完整的背景然后让它输出结构化对比最后我把它的结论当成参考输入而不是最终答案。这种方式能帮团队把所有候选方案拿到桌面上避免“看谁顺眼就选谁”的尴尬。2. 技术选型的AI辅助决策方法论2.1 先写决策上下文而不是直接问“选什么”很多人用AI做选型的姿势上来就是一句“微服务用什么数据库”。这种问法不是不行但得到的答案一般很水因为AI没有足够的信息判断你的真实场景。我习惯先写一份“决策上下文”把项目情况说清楚再让AI给建议。你可以把它理解成给医生描述病情你说得越具体诊断越靠谱。一份合格的技术选型上下文至少应该包含这些信息上下文项需要写清楚的内容业务目标这次选型要解决什么业务问题是拉新、转化、还是内部提效用户规模当前用户量、预期增长量、峰值并发大概是多少流量模型读写比例、实时性要求、有没有明显的波峰波谷技术约束现有技术栈、云环境/自建机房、必须兼容的旧系统团队情况团队人数、主力语言、对候选技术的熟悉程度时间窗口多久必须上线有没有试错空间许可与合规是否允许开源协议变更、是否需要私有化部署这个表我每次选型都会填。填完之后把它一起贴给AI得到的答案质量会完全不同。比如你问“Java后端实时推送选什么”AI可能会直接说WebSocket。但如果你告诉它“移动端为主、弱网环境多、需要省电”AI就会把MQTT列进前排。背景信息不同结论就不同这不是AI在端水而是问题本身需要更多约束才能收敛。2.2 让AI生成候选清单和对比维度上下文写完之后第一轮对话不要急着要结论先让AI列候选清单。我会用下面这种提示词模板我们团队是Java技术栈维护在K8s集群上需要做一个面向Web端和移动端的实时消息推送服务。单机预计10万在线连接消息延迟希望控制在1秒以内要求自部署不依赖商业云产品。请先不要给最终结论帮我列出技术方案候选清单按适用场景、优势、劣势、团队学习成本、运维复杂度这五个维度做对比。这个提示词的关键在最后一句“先不要给最终结论”。一旦你说了这句话AI就会老老实实做对比而不是急着给你打分排名。我实测下来AI一般会把WebSocket、SSE、MQTT、RSocket、WebRTC DataChannel、短轮询、长轮询都列出来。里面有一些方案你可能一开始根本没考虑过比如RSocket它在Java生态里其实很能打只是平时存在感不高。这个“查漏补缺”的作用就是AI辅助决策最直观的价值。拿到第一版对比表之后我还会追问一句“有没有被低估的方案哪些冷门方案在特定场景下反而更合适”这一步能逼着AI跳出主流视野把边缘方案也暴露出来。2.3 把“感觉”变成可评分的决策矩阵候选清单出来之后下一步是建立评分模型。先说一个常见错误让AI直接打分但你没给权重。AI默认会给每个指标同样的权重这跟现实严重不符。对某些业务来说实时性就是一切运维复杂度可以往后放对另一些业务来说运维复杂度才是决定项目能不能长期活下去的关键。所以我建议先定权重再让AI打分。权重总和是100%这样分数可解释、可回溯。拿前面的实时消息推送场景举例我可能会这样设置评分维度权重说明实时性30%核心业务要求端到端延迟低并发连接能力25%单机10万在线是硬指标团队熟悉度15%决定上手和排障速度运维复杂度15%没人愿意天天处理连接风暴生态成熟度15%社区活跃坑少文档全然后我会对AI说请按上表权重对这五个候选方案进行加权评分每个维度打1到10分。不要只给总分要把每个维度的分值和计算过程列出来最后说明为什么某个方案得分更高。让AI列出计算过程这个动作很重要。因为AI可能会算错也可能为了迎合你的措辞而调分。你把计算过程摊开至少能确认它的逻辑是否自洽。算完之后AI给的很可能是WebSocket以8.9分微弱领先SSE的8.8分。这个差距小到没有统计意义但没关系真正的价值是它让团队看到了分数接近背后的维度差异接下来就该做原型验证了。2.4 用AI做反向校验我最后一步不是让AI“帮我选”而是让它“骂骂我的选择”。一旦团队有了倾向性方案我会把倾向方案和理由发给AI然后加一句我们目前倾向于选择WebSocket方案理由是实时性强、生态成熟、团队熟悉。请从反面攻击这个选择在什么情况下它会变成错误决定如果要推翻这个选择最可能的原因是什么这招非常有用。AI会列出WebSocket的短板比如网关层连接管理复杂、移动端弱网断线重连困难、长时间连接对负载均衡不友好等等。这些问题不一定都会发生但至少逼着团队提前准备应对方案。反向校验的本质是把选型从“证明我对”改成“证明我不会错”。很多时候团队选型失败不是选了个烂技术而是只看了优点没看缺点结果上线之后被缺点反噬。AI辅助决策能把这个反噬提前到成本最低的阶段。3. 实战用AI辅助选一个实时消息推送方案3.1 项目背景和约束条件为了更好地说明这套方法怎么落地我拿一个我实际参与过的场景举例细节做了脱敏处理。当时我们要给一个内部业务平台做实时消息推送业务方提的需求很模糊订单状态变了要通知前端后台操作要实时同步偶发跨区域通知。我们团队是Java技术栈服务已经跑在K8s上没有专职运维希望方案别太折腾。我先把这些背景整理成决策上下文写清楚几个关键约束在线连接数峰值约5万到10万主要来自Web端少部分来自移动端H5。实时性要求中等偏上秒级延迟能接受但不能出现大规模消息堆积。不能引入商业云推送服务需要自部署。团队对WebSocket有基础了解对MQTT几乎没有生产经验。上线时间窗口只有三周不允许做超过两周的架构改造。这个背景一摆出来其实已经把很多方案淘汰掉了。比如短轮询虽然简单但5万连接下会产生大量无效请求运维压力很大RSocket虽然性能好但团队不熟三周内很难保证交付质量。AI的作用不是替我做这些判断而是把这些“我脑子里知道但没说出口”的约束变成显性对比条件。3.2 三轮AI对话的过程与关键提示词第一轮我让它列候选方案。我用的是前面那套“先不要给结论”的提示词最终拿到了六七个候选方案。我没有要它一次性把所有细节都讲完而是让它先给对比表格控制信息量。第二轮我让它按维度打分。分数表出来之后我特意追问了一句SSE和WebSocket在这个场景下分数很接近请指出它们各自在什么情况下会崩以及崩之前有没有预警信号。AI给出的回答是SSE在HTTP/2连接被代理层断开时容易静默重连而WebSocket在客户端断网时会不断触发重连风暴需要设计指数退避。这些点看起来是常识但放在决策表里就能帮助团队提前写设计文档。第三轮我做了反向校验。我说“我们比较倾向WebSocket”让AI列举推翻这个倾向的理由。它提到了网关层超时配置、移动端iOS Safari对WebSocket的限制、以及长连接内存泄漏需要压测验证。这些问题我们后来在原型验证阶段真的遇到了而且都在可控范围内。三轮对话结束后我没有要求AI给一个“最终结论”。因为到了这个阶段团队已经知道该验证什么了再让AI给结论反而容易导致甩锅。3.3 打分结果与实际选择最终的打分结果大致是这样的维度权重WebSocketSSEMQTTRSocket实时性30%109810并发连接25%8798团队熟悉度15%91065运维复杂度15%71085生态成熟度15%10985加权总分100%8.98.87.957.25可以看到WebSocket和SSE总分非常接近SSE在运维复杂度上明显占优WebSocket在实时性和生态上占优。团队最后选择WebSocket并且用Spring WebSocket加上Redis Pub/Sub做了一个轻量原型。为什么这么选不是因为总分高那0.1分而是因为我们认为“实时性可以更高”和“团队已有熟悉度”在这个项目里比“运维简单”更不能妥协。这个结论不是AI下的是我们根据AI提供的信息人工下的。但AI辅助决策帮我们节省了很多时间至少大家不用再花三天去争论“SSE到底算不算推送技术”这种话题。4. AI辅助技术选型中常见的坑和对策4.1 AI信息幻觉推荐了一个不存在的组件AI模型是按照训练数据生成的它会把一些概念拼凑在一起产出一个看起来合理但实际不存在的方案。我遇到过AI推荐了一个叫“Spring Messaging Gateway”的组件听着挺像回事但查下来发现没有这个官方项目。对策很简单拿到AI给出的每一个关键结论都必须去官方文档或GitHub仓库确认。我现在的习惯是要求AI在输出中标注“这个结论建议去xx官方页面复核”并把复核结果作为选型材料的一部分存档。AI可以当信息索引但不能当最终信息来源。4.2 知识过期只看热闹没看版本生命周期大模型的训练数据有截止时间它对最近一年的版本变化并不敏感。比如某些开源软件换了许可证某些组件从stable变成maintenance模式这些信息AI不一定能及时反映出来。所以我做选型时会再补一个动作单独问AI“请列出这些方案最近一年的重要版本变化和license变更”然后自己快速核对changelog。这两个信息对选型的长期影响很大因为一个正在调整许可证的数据库可能在第二年就让公司法务发来一封信。4.3 “端水式回答”和“墙头草式结论”不带约束条件问AI它很容易给你一堆“各有优势看具体场景”的废话。不是AI想逃避是因为你给的信息太少它只能端水。如果你需要它给出倾向性意见就把约束条件加满然后明确指令如果必须在这几个方案里选一个且团队只有三周时间上线请选一个你认为风险最低的方案并说明你愿意承担什么样的代价。这个提示词会逼着AI做取舍。它一旦做出取舍你就能看到取舍逻辑然后判断这个逻辑是否符合团队现实。如果不符合你自己也能想清楚哪里不符合。4.4 把AI输出当最终决策责任无人承担技术选型最大的风险不是选错而是没人敢为选错负责。如果团队把AI推荐的结论直接拿去做决策出了事之后大家都可以说“这是AI说的”这就很危险了。我的经验是AI辅助决策的全过程必须留痕。你和AI的对话、生成的对比表、会议讨论纪要、最终选型理由全部归档。归档不是走流程而是让三周后、三个月后的人回头看还能知道当时的约束条件是什么为什么没有选另一个方案。这种可追溯性才是AI辅助决策最有价值的地方。5. 从辅助决策到落地闭环让选型结果可追踪5.1 让AI生成ADR架构决策记录草稿选型结束之后不要急着写代码先写一份ADR。ADR是架构决策记录用来描述“我们决定用什么、为什么、放弃了什么、代价是什么”。AI很适合写ADR草稿因为它刚参与完决策过程对上下文掌握得很全。我会给它一个模板请基于前面的对比表和我们最终选择的方案帮我写一篇ADR草稿。包含背景、决策、理由、备选方案、被否决原因、预期风险和后续验证指标。语言要克制不要夸大不要写“显著提升”“完美解决”这种词。AI生成的草稿可能有点空但骨架已经有了我再把团队讨论中的真实细节填进去。这样ADR不会变成一篇没人看的文档它会成为团队后续排障时的参考地图。5.2 用AI Agent持续跟踪选型后的技术指标选型不是一天完成的很多问题要等系统上线后在真实流量下才会暴露。我后来会把一些跟踪工作也交给AI Agent来做。最简单的用法是让AI定期对比选型时的预期指标和线上真实指标。比如当时我们预期WebSocket单机连接数是10万实际压测能达到8万那AI Agent就可以帮你从监控数据中抓出连接数趋势标注出哪个时段有连接泄漏的嫌疑。再进一步它可以把这些数据和原来的ADR关联起来形成一个“预期和实际偏差记录”。这个动作的意义在于技术选型的决策质量不是看选型当天谁说得对而是看系统运行半年后当初的约束条件是否还成立当时的取舍是否换来应有的收益。AI辅助决策如果只停留在“聊天出表”阶段价值会打折扣。真正让我觉得这方法有用的是它把选型从一个一次性的会议变成了一个可以复盘、可以修正的工程过程。我个人现在做选型都会把AI生成的对比表、评分过程和反向校验记录放进项目文档库。遇到团队争论我就把文档打开让大家对着当时的权重聊。很多分歧在看完原始背景之后就自然消失了。技术选型没有完美的答案但可以有不留遗憾的决策过程。