让 LLM 在热门开发工具之间做选择听起来像是一个标准的“AI 段子”实验把 React 和 Vue 摆在一起问一次把 PostgreSQL 和 MySQL 摆在一起再问一次。但真正跑过之后你会发现这件事比想象中有价值也比想象中更容易跑偏。它最有价值的地方不是让模型替你拍板而是逼着你在提问之前先把“我们团队到底在乎什么”想清楚。适合看这篇文章的人有两类一类是近期在做技术选型、想拿 LLM 当参考意见的开发者另一类是纯粹想了解 LLM 在工程判断上能给出多高质量答案的人。下面按我实际跑过的流程拆一遍包括怎么写提示词、怎么跑多轮、怎么判断结果、怎么避免被模型的“礼貌性中立”骗过去。1. 让 LLM 帮你选开发工具先要搞清楚它到底在解决什么问题1.1 这不是“搜索引擎”而是“统一的决策框架”很多人第一次看到类似实验时会觉得多此一举工具对比我直接搜文档、看 benchmark、刷社区帖子不就行了确实可以但这些方式有一个共同问题信息是散的。你在一个帖子看到性能数据在另一个 issue 里看到坑在招聘网站上看到人才供给最后只能靠自己的脑子把这些信息揉在一起。LLM 选型实验不一样。它把比较维度、约束条件、优先级权重全部塞进同一个提示词里让模型在同一个上下文内做推理。模型不会帮你找到新数据但它会强迫你先把决策标准写清楚。这一点在工程上往往比最终结论更重要。我见过很多团队做技术选型时开三次会都定不下来不是因为信息不够而是因为每个人心里的权重不一样。有人在乎招聘难度有人在乎短期上线速度有人在乎长期运维成本。用 LLM 跑一轮工具对比本质上是把“谁的权重更合理”这个问题提前暴露出来。1.2 这个方法的边界在哪里先说清楚边界避免期待过高。LLM 不会实际部署你的项目不会帮你压测更不会替你承担线上故障责任。它给出的所有理由都基于训练数据中的公开资料而不是你的代码仓库、你的流量曲线、你团队的技能矩阵。所以它的角色是“结构化参考”不是“决策代理”。那么它还值得做吗值得。因为技术选型中至少有一半工作量是整理信息、对齐标准、穷举理由这些恰好是 LLM 擅长的。真正需要人来做的那一半是把它说的每条理由放到自己环境里验证。比较适合用 LLM 做工具对比的人是已经有初步候选范围、想快速扫一遍差异的中小团队以及刚接触某个领域、想建立基本判断框架的个人开发者。不适合用 LLM 拍板的场景是已经进入选型后期、需要精确性能数据或合规评估的技术决策这时候模型的作用只配做“查漏补缺”。2. 开始对比之前把环境、任务和评分维度定下来2.1 先确认你用哪种 LLM 接入方式不同接入方式会影响结果不只是方便程度的问题。我这里说的接入方式主要指四类接入方式适合场景主要限制网页版对话快速体验、单轮对比不方便批量跑多轮容易受对话历史干扰官方 API可脚本化、可控温度、可复现需要处理超时、token 限制、格式解析本地开源模型数据敏感、离线环境模型能力参差知识截止时间更明显聚合网关多模型对比、容灾切换不同模型行为差异大结果难归一化我自己做这类实验时优先用 API 方式因为可以固定 temperature、控制对话历史、把结果落成结构化数据。网页版偶尔用于探索性提问但不会用来做正式结论。如果你是第一次跑不用管太多先用你手上最顺手的工具启动就好。关键是后面要记住你用的是哪个模型、哪个版本、知识截止到什么时候。这些信息在判断结果可靠性时非常关键。2.2 选对比对象同赛道工具还是跨层方案工具对比可以分为两类策略不一样。第一类是“同赛道对比”比如 React 对比 Vue、PostgreSQL 对比 MySQL、Docker 对比 Podman、Grafana 对比 Kibana。这类对比背后通常是同一类问题的不同解法维度比较清晰适合让 LLM 逐项打分。第二类是“跨层或方案级对比”比如“自建 K8s 集群对比直接用云托管”“单体架构对比微服务”“自研调度系统对比直接买 SaaS”。这类对比更复杂因为它不只是工具差异还有成本结构、团队能力、时间窗口的差异。LLM 很容易在这种问题里给出过于抽象、两头都不得罪的回答。所以我的建议是如果是第一次做实验先选同赛道工具对把流程跑通等判断标准成熟了再去碰跨层方案。2.3 评分维度要提前定义别让模型自由发挥这一步是整个实验里最容易偷懒、也最容易出问题的地方。很多人的第一版提示词是“帮我比较 A 和 B选哪个好”。这种问法不是不能用但结果通常很泛模型会默认用“大众化权重”回答也就是他训练数据里最常见的开发者偏好而不是你的偏好。更好的做法是先定义评分维度。我给工具选型常用的维度有六个维度判断重点学习曲线团队上手需要多久生态成熟度库、插件、文档、社区是否齐全性能与扩展性峰值场景下的表现和上限运维成本部署、监控、升级、排障的人力投入招聘难度市场上相关经验人才是否好找长期演进项目活跃度、版本演进方向这六个维度不是固定的。如果你的项目已经上线、流量很大性能权重就要调高如果团队只有三个人且都要身兼数职学习曲线和运维成本就要调高。维度定下来之后再把每个维度的权重写进提示词里。模型不一定真的按权重计算但至少它会知道哪个维度更重要。3. 单人提问到多轮交叉验证的完整流程3.1 写清楚上下文背景信息越具体答案越不空泛同样是“帮我选数据库”两种问法结果差异很大。空泛的问法直接问“PostgreSQL 和 MySQL 选哪个”模型大概率会给一个四平八稳的回答PostgreSQL 功能强MySQL 生态广小项目都够用看具体场景。这句话对决策几乎没有帮助。更具体的问法至少包含四类背景信息团队规模和当前技术栈业务类型和预估流量上线时间约束团队对候选工具的经验水平下面是我实际用过的提示词模板你可以按自己情况改你是一名有 10 年经验的资深后端架构师。请帮我做技术选型参考。 背景 - 团队规模5 人后端团队 - 现有技术栈Java、Spring Boot、MySQL、K8s - 业务类型中小规模 To B SaaS单机峰值 QPS 约 1000 - 时间约束一个月内上线 - 团队经验没有人深度用过候选工具 候选工具PostgreSQL 15 和 MySQL 8 请从以下维度分别打分1-5 分每个维度给出不超过 50 字的理由 1. 学习曲线 2. 生态成熟度 3. 性能与扩展性 4. 运维成本 5. 招聘难度 6. 长期演进 最后给出总分、推荐结论和一句话理由。 请明确说明你的知识截止时间并指出哪些维度你判断把握不足。注意最后一句很关键让模型主动暴露不确定的地方。很多模型在不确定时不会说“我不知道”而是会顺着问题编一个合理但可能过时的答案。明确要求它标注不确定性能大幅提高回答质量。3.2 固定提示词模板保证多轮结果可比较LLM 有随机性。同一个提示词跑十次结果大概率不完全一样。这不是 bug而是模型采样机制的正常现象。但如果你的实验要得出可信结论就必须控制变量。做法是把提示词模板固定住只改变随机种子、temperature 等采样参数或者改变提问顺序。我一般会这样操作把背景和维度描述固化成模板存成一个文本文件。同一份模板跑至少 5 次。每次记录模型给出的推荐结论、总分和关键理由。统计候选工具被推荐的次数和理由的一致性。为什么要至少 5 次因为如果只跑 1 次你看到的是一个随机样本跑 3 次可能还不够稳定跑 5 次以上基本能看出模型的偏好方向。如果 5 次里有 4 次推荐同一个工具那这个结论相对稳定如果 5 次结果 3:2 甚至更分散说明这两个工具在模型眼里区分度不够或者你的评分维度没有拉开差距。这个时候先别急着下结论也不要试图通过多跑几次“刷”出一个自己想要的答案。更合理的做法是回到评分维度看看是不是权重分配没写清楚。3.3 多轮追问让模型给出“反方理由”第一轮对比通常只能得到表面结论。真正有价值的细节藏在追问里。我习惯在第一轮结果出来后追加一轮或两轮追问最常见的追问有三种第一种让模型为落败方辩护“现在假设我因为历史原因必须使用 MySQL请列出三个最应该警惕的坑以及每个坑的规避方案。”这一问能逼出很多实际运维细节。第二种让模型拆解推理过程“你给 PostgreSQL 的扩展性打了 4 分但我团队没有任何人用过它的高级特性。请说明这个 4 分是基于哪些具体能力计算的并指出哪些能力我们可能根本用不上。”第三种让模型给出反方理由“请列出选择 MySQL 而不选 PostgreSQL 的五个理由按说服力排序。”注意这里的重点不是让模型“自己反对自己”而是测试它对工具边界的认识是否足够立体。如果模型给出的反方理由都成立说明它大概率不是盲推。这一轮做完之后你手里的材料就从一个“结论”变成了一份“决策笔记”有哪些维度支持这个方案哪些维度不支持有哪些坑需要提前排。3.4 用表格记录多轮结果多轮结果不要只存在聊天记录里。我习惯用一张表格记录每次实验的字段字段示例模型GPT-4o / Claude 3.5 Sonnet / 本地 Qwen提示词版本v1 / v2temperature0.2 / 0.7推荐结论PostgreSQL 8 / MySQL 8 3 分落选方的核心反方理由MySQL 在 JSON 能力上明显落后模型的已知不确定项对 PostGIS 最新版本了解可能过时这张表跑完几轮之后会很有用。它不只帮助你判断该选哪个工具还可以用来对比不同模型在技术判断上的差异。你会发现有的模型偏向保守推荐“生态最稳妥”的选项有的模型更愿意推荐“功能最强”的选项。这本身就是一个很有意思的观察。4. 结果怎么读看推荐结论更要看理由和边界4.1 判断一份 LLM 选型建议质量的三把尺拿到一份对比结果后先别急着看“最后推荐了谁”用下面三把尺过滤一遍。第一把尺理由是否具体。如果模型说“A 扩展性更强”但没有说具体是那种扩展性——是水平分片能力、JSON 处理能力、还是插件体系——那这条理由基本没有信息量。合格的理由应该能挂钩到具体能力比如“PostgreSQL 的 JSONB 支持索引而 MySQL 的 JSON 类型在复杂查询下的优化器支持不够成熟”。这种理由才能拿到你本地环境里验证。第二把尺理由是否与你的约束条件挂钩。你的团队只有 5 个人就不会在乎 5000 人规模下的招聘差异你的业务只有 1000 QPS性能维度就该退后。模型如果通篇都在讲高并发架构下的选型逻辑说明你的约束条件没有进入它的推理链路需要回头改提示词。第三把尺模型是否主动说明不确定性。好的选型建议会写“该信息基于训练数据可能不包含 2025 年下半年之后的版本变化建议核实 X 和 Y 两点”。如果模型所有回答都非常笃定、没有任何不确定表述那才需要警惕它可能正在用自信的语气掩盖知识截止带来的信息缺口。4.2 “哪个都行”和“反复横跳”的处理方式多轮实验里最常见的两种现象一是模型说“都要看场景两个都行”二是推荐结果在不同轮次之间反复横跳。先说“哪个都行”。这种回答通常不是模型在敷衍而是你的评分维度没有拉开差距或者候选工具在这一维度上确实差异不大。处理方式不是换一个更情绪化的提示词逼它选而是引入“必须取舍”的约束。我会在提示词里加一句“假设现在必须二选一请你基于当前背景给出明确推荐并说明放弃另一个方案的最大代价是什么。”这个约束能迫使模型把隐性优先级暴露出来。再说“反复横跳”。如果 5 轮结果分别是 A、B、A、B、A你的第一反应不应该是“模型不可靠”而是想到三种可能两个工具在你的评分维度下确实难分伯仲你的权重设置没有生效模型还是按自己的默认偏好回答模型版本或采样参数不一致导致结果波动。排查顺序是先检查采样参数是否固定再检查提示词里是否给了互相矛盾的约束最后才考虑“候选工具本身区分度不足”。如果三者都排除了那这个结果本身就是一个有效结论这两个工具在给定条件下的差异可能不值得你花费太多选型成本去纠结。4.3 调用层问题超时、格式错误、解析失败跑多轮实验时实际问题往往不在模型推理而在 API 调用层。这里列几个我遇到过的真实情况。第一种请求超时。现象是等待很久之后返回llm request timed out或类似错误。这类问题多见于上下文过长、模型推理时间超过客户端超时阈值或者网络链路不稳定。处理方式是先缩短提示词把历史对话截断如果还不行调大客户端超时时间把单次请求拆成多个小请求。第二种提供方拒绝请求格式。现象是返回provider rejected the request schema or tool payload。这通常意味着你请求体里的参数不符合接口规范比如 tool 定义格式错误、response_format 不兼容、或者传入了模型不认的参数。处理方式是先打印请求体逐字段对照接口文档不要猜。第三种输出格式不统一。就算你在提示词里要求“输出 JSON”不同模型、不同 temperature 下也可能出现多余的中文解释、Markdown 代码块包裹、或者字段名大小写不一致。规避方式是在解析层做容错先尝试按 JSON 解析解析失败就剥离代码块标记再试一次还是不行就把原始输出记到日志里人工看。这些看起来都不是选型问题但它们会直接打断你的实验节奏。我的建议是把实验脚本一次性写好加上重试、超时和日志记录再开始批量跑。5. 模型选型里的隐性偏差不会写进推荐理由5.1 流行度偏差越多人讨论的工具越容易被推荐LLM 的训练数据里流行工具的样本远远多于冷门但合适的工具。这意味着模型在对比时会天然倾向于推荐它“见过更多次”的选项。这不完全是坏事。流行度高通常意味着社区成熟、坑的解决方案多、招聘容易。但问题在于模型不会告诉你“我推荐 A 的部分原因仅仅是在训练数据里 A 的讨论量更大”。它会包装成“A 的生态更成熟”这种看起来合理的理由。所以拿到推荐结果后要做一步“反流行度检查”如果模型推荐的是明显更主流的工具想想在你的具体场景里“生态成熟”这个优势是否真的能转化为实际收益。对于一个小团队、内部系统、无扩展可言的场景流行度优势可能只是心理安慰。5.2 知识截止时间导致的信息过期这是最容易被忽略的问题。模型训练有截止时间之后发生的版本变化它不知道。如果你问“最新版的 A 工具怎么样”模型很可能基于默认的版本认知回答甚至编出一个不存在的“最新版本号”。我踩过的例子让模型比较某个前端框架的构建性能和 SSR 支持它给出的版本特性描述实际是两年前的版本。如果我不去官方文档核对版本号很可能被误导。规避方法很简单在提示词里明确要求“请先说明你的知识截止时间”并且在拿到推荐结论后把模型提到的所有版本号、特性名、项目活跃度描述去官方仓库或文档里核对一遍。这一步不能省。5.3 “礼貌性中立”和“无意义正确”还有一个很隐蔽的问题我管它叫“无意义正确”。模型可能给出一个语法完全正确、逻辑也挑不出硬伤但实际上没有任何信息量的回答。比如“两者都是优秀的工具具体选择取决于你的业务需求。如果追求更丰富的功能A 可能更适合如果追求简单和稳定性B 可能是更好的选择。”这种回答单独看每一句都对放到决策场景里等于什么都没说。识别方法很简单问自己一句读完这段话我能不能直接做决定如果不能就说明模型的回答还停留在“可正确”而没有进入“可行动”。应对方式就是把问题一步步收紧先让它二选一再让它给出选择后最可能翻车的三个风险点最后让它给出如果风险发生后的应急预案。这时候模型才能真正产出对决策有用的内容。5.4 验证方法让模型引用可核实的信息如果要降低幻觉风险一个实用的做法是要求模型在关键结论后附上“可核实来源”。不是让它真的上网搜索而是让它说明“这个结论基于哪个已知项目、哪个版本、哪个文档特征”。比如你问 PostgreSQL 的 JSONB 是否支持索引模型如果说“支持”你可以让它补充说明是 GIN 索引还是 B-tree 索引。它说“MySQL 的 JSON 索引支持有限”你可以让它解释“有限”具体指什么。如果模型进入细节后开始含糊其辞那它刚才的结论大概率是表面记忆不是真正理解了机制。这一步做完模型给你的信息里能信的、需要验证的、需要彻底放弃的基本就分层了。6. 从实验走向落地把 LLM 的建议变成工程决策6.1 LLM 给的是“结构化的观点”不是“本地验证结果”这是全文最重要的一句话LLM 帮你做的不是“验证”而是“组织观点”。它可以把散落的公开信息组织成一份像样的对比报告它可以帮你穷举你自己想不到的风险点它可以逼你把决策标准写清楚。但它不会知道你的代码里是不是已经用了某个强绑定特性不会知道你团队成员是不是其实很擅长某个冷门工具更不会知道你们公司的采购流程对某个商业授权更友好。所以LLM 实验的产出物应该是一份“待验证清单”而不是“选型决议”。6.2 落地前至少补三步文档、代码、最小试验拿 LLM 的推荐结论落地之前我建议至少做三件事。第一去官方文档和 GitHub 仓库核对版本、特性、许可证和活跃度。只看“star 数”和“最后提交时间”还不够要看 issue 响应速度、release 频率、破坏性变更声明。第二把你自己的真实需求写成一个最小验证场景。比如你选数据库就是建表、写入、查询、备份、恢复你选前端框架就是把一个真实页面按现有组件库重写一遍。不需要完整业务但必须包含你场景中最核心的 2 到 3 个特征。第三做一次最基础的性能和稳定性观察。不要一上来就压测先用小样本跑一遍记录资源占用、响应时间、并发下的错误率。如果和 LLM 说的差距过大以本地实测为准。6.3 像维护 wiki 一样维护你的选型依据我曾经因为选型文档散落在聊天记录、邮件和会议纪要里导致半年后复盘时说不清当初为什么选 A 而不选 B。后来我养成了一个习惯把选型依据结构化地维护下来。这一做法和现在讨论度很高的“LLM wiki”方法很像。核心思路不是让 LLM 替你写完整文档而是把决策背景、候选方案、评分维度、测试结果、外部依据、坑点记录整理成结构清晰的上下文。以后不管是让 LLM 做后续分析还是让新人接手项目都能直接基于这份上下文继续工作而不是重新从零开始问一遍模型。具体到工具选型我会维护一个 markdown 文件结构大致如下# 选型记录数据库 ## 决策背景 - 团队规模、业务类型、上线时间 ## 候选方案 - PostgreSQL 15 - MySQL 8 ## 评分维度与权重 - 学习曲线 20% - 生态成熟度 20% - 性能与扩展性 15% - 运维成本 25% - 招聘难度 10% - 长期演进 10% ## LLM 多轮实验结果 - 模型、提示词版本、temperature、轮次统计 ## 本地验证记录 - 最小试验、版本核对、性能观察 ## 结论与风险点 - 最终选择、放弃另一方案的最大代价这样一份文档维护到后期价值会超过任何一次单轮 LLM 回答。因为它把“模型的观点”和“本地的实证”放到了一起下次做迁移评估或年度复审时直接基于这份文档展开不用再重新踩一遍坑。6.4 一份可复用的落地清单最后把整个流程压缩成一张检查清单方便你下次直接照着走。确定场景同赛道对比还是跨层方案对比先跑同赛道。定义评分维度至少包含学习曲线、生态、性能、运维、招聘、演进中的四项。明确权重团队规模、业务类型、时间约束写进背景。固定提示词模板模型、版本、temperature 保持一致。至少跑 5 轮记录每轮推荐结论、理由、不确定性声明。做反方追问让模型为落败方辩护并列出最该警惕的坑。过滤质量理由是否具体、是否挂钩约束、是否暴露不确定性。排查调用问题超时看上下文schema 报错看请求体格式乱做容错解析。识别偏差流行度偏差、知识截止时间、礼貌性中立。本地验证文档核对、最小试验、小样本性能观察。沉淀文档把决策背景、LLM 观点、本地实证、风险点写进选型记录。这个方案真正落地时最该盯住的不是模型最后推荐了谁而是整个过程中产出的“理由清单”和“待验证项”。模型负责把这些信息组织得足够完整你负责让这些信息在你的真实环境里经得起验证。这两件事都做到位工具选型这件事就算没有选到最优解至少也选得明明白白。