技术选型：把三个候选方案做成对比表并写取舍

三个方案七个指标打完分，A 是 7.8、B 是 7.5、C 是 7.1，于是选了 A。半年后被问「为什么不用 B」，答不上来——那 0.3 分本来就是拍出来的。文章讲怎么让这张表真能用来做决定：先定否决项，再反推权重，最后写清放弃了什么。

一句话结论

选型表的价值不在分数高低，而在三件事：否决项从哪来、权重从哪来、放弃项有没有写清。做法是先用三条可量化的否决项把不合格的方案直接出局，再对剩下的打分；分差落在误差范围内时，用一次最小验证定夺，而不是继续加指标。

还有一件必须做的事：结论里要有一段「我放弃了什么、为什么可以接受」。半年后有人问起，这段就是答案；没有它，选型表只是一张打分游戏。

这篇解决什么问题

三种情况最常见。一是七个指标平均分，每项权重都是 14.3%，等于没有权重——上线时间这种硬约束和「社区活跃度」被同等对待。二是表格里填的都是印象：「性能好」「生态成熟」「文档一般」，追问一句数据在哪就卡住。三是只写结论不写取舍，方案上线后遇到问题，没人说得清当初为什么排除了另一个更省事的选项。

根子是同一个：把选型当成评比，而不是决策。评比追求排序，决策追求「在什么约束下、放弃什么、换到什么」。文章把它固定成五步，做完得到一张每格有来源的对比表、一段能复述的取舍说明、一份退出预案。

开始前要准备什么

• 三个候选方案：至少有一个是「什么都不换、继续用现状」，否则容易高估收益。
• 约束清单：预算上限、并发量级、团队现有技能、上线时间窗、合规要求。每项都要有具体数字或日期，写「预算有限」等于没写。
• 可验证的测试方案：能在一天内跑完的最小验证，比如同一份数据在两个方案上各跑一遍，记录延迟与失败率。
• 一张七列表：指标、权重、方案 A、方案 B、方案 C、数据来源、判断依据。

具体怎么做

第一步：从约束里抽出三条否决项

否决项不是「重要的指标」，而是「不满足就没法用」的条件。写法必须是可判定的：不说「要有良好的私有化能力」，说「必须支持部署在我方内网，且不依赖外部接口」。三条以内，多了会把所有方案都筛掉。抽出后用它对三个候选做一次粗筛，出局的直接标掉，不进入后面的打分——这一步能让表格从三列变两列，后面的争论少一半。

这是我的项目约束（粘贴：预算、并发、团队技能、上线时间、合规要求）。
请帮我做三件事：
1. 从中抽出不超过三条「否决项」，每条写成可判定的句子（满足 / 不满足，没有中间态）；
2. 说明为什么其他约束不适合做否决项，而应该进权重打分；
3. 给出每条否决项的验证方式：用什么材料或测试可以确认方案是否满足。

约束如下：______（逐条列出，带具体数字）

第二步：权重从业务目标反推，不用平均分

可靠的做法是两两比较：把五个以内的指标列出来，每次只问「这两个如果只能保一个，保哪个」，比完统计每个指标被选中的次数，归一化成百分比。这样得出的权重一定不平均，而且每一步都能追溯到一句「因为下季度要赶上线」。权重定完写进表里，后面不要再改——边打分边调权重，结果一定是想选谁就调到谁高。

这是我的业务目标与五个候选指标（粘贴）。
请帮我用两两比较法推导权重：
1. 把五个指标两两组合，逐个问我「只能保一个时保哪个」（一次只问一组，等我回答后再问下一组）；
2. 全部比完后统计每个指标被选中的次数，归一化成百分比，保留整数；
3. 给出权重表，并检查是否有某项权重低于 5% 或高于 40%，若有，说明这意味着什么（几乎不参与决策 / 一票主导）。
4. 最后给一句校验：当前权重结构是否与「下季度必须上线」这个目标一致。

指标：______（列出五个）

第三步：建表，每格必须写来源

表格七列，「数据来源」和「判断依据」是核心。每一格填进去的内容都要能回答「你凭什么这么说」：官方文档的某一页、一次实测的数字、一份报价单、一次和对方工程师的对话记录。填不出来的格子写「未知」，不要写「一般」「尚可」——这两个词等于没填，还会让分数虚高。

这是三个候选方案的资料（粘贴文档要点、报价、测试数据）与指标清单。
请帮我填一张对比表，七列：指标、权重、A、B、C、数据来源、判断依据。

规则：
1. 每格只填事实（数字、明确的支持或不支持），不填评价性词语；
2. 找不到资料的格子写「未知」，并在最后一列注明需要补什么；
3. 对所有「未知」项，按对决策的影响程度排序，指出哪三项必须补测才能下结论；
4. 不要在这一步给总分，也不要推荐方案。

同时指出：三个方案里有没有哪一项是「看起来有数据、实际上是厂商口径」，这类数据要单独标出。

第四步：分差在误差内时，用一次最小验证定夺

加权总分出来之后，先看分差。分差在 5% 以内，说明这套指标区分不了这两个方案，继续加指标只会制造虚假的精确。这时候做一次最小验证，只测三个可量化指标：关键路径的 P95 延迟、连续运行 24 小时的失败率、一次典型变更的实际耗时（含学习成本）。第三项最容易被低估。

总分出来了：A ______ 分、B ______ 分，分差 ______%。
请帮我设计一次一天内能跑完的最小验证：
1. 只保留三个可量化指标（关键路径 P95 延迟、24 小时失败率、一次典型变更耗时），给出每项的测试步骤与记录方式；
2. 说明每项指标的「可接受阈值」怎么定（从业务目标反推，不要拍一个数）；
3. 指出这次验证最容易产生偏差的三个地方（数据量太小、环境差异、只测了顺利路径），以及各自的规避办法；
4. 给出判定规则：什么情况下选 A、什么情况下选 B、什么情况下两个都不选。

我的场景：日均请求量 ______，团队规模 ______ 人，其中后端 ______ 人。

第五步：写取舍段落与退出预案

结论部分固定三段：选了什么、放弃了什么、如果错了怎么办。第二段是重点，要写清被放弃方案的强项，以及「为什么这个强项在我们的场景里可以接受」。第三段是退出预案：如果三个月内出现什么信号，就切换到备选；切换成本是多少人日。没有退出预案的选型，等于把决定做成了信仰。

这是本次选型的全部材料（对比表、验证结果、权重）。
请帮我写结论部分，三段结构：
1. 选了什么：一句话结论 + 三个决定性理由（每条对应一个指标和数据）；
2. 放弃了什么：列出被放弃方案的两到三个强项，逐条说明「在我们的场景里为什么可以接受」，不要贬低对方；
3. 如果错了怎么办：给出三个可观测的预警信号（例如「月度运维耗时超过 X 人日」），以及对应的切换动作与预估成本。

要求：不用「综合来看」「性价比高」这类无法验证的表述，每句话都要能被追问到底。

实测记录

用一次真实的技术选型做测试：候选是「现成服务 A」「开源自建 B」「托管服务 C」，约束是三个月上线、后端只有 1 人、必须支持内网部署、预算上限明确。

• 否决项：只定了两条——必须支持内网部署、必须能导出全部数据。C 在第一条出局（不提供内网版本），表格从三列变两列。
• 权重：两两比较十次，得出上线时间 30%、维护成本 25%、性能 20%、生态 15%、迁移成本 10%，无一平均分。
• 打分：A 得 7.8、B 得 7.5，分差 3.8%，落在误差范围内。按规则不继续加指标，转做最小验证。
• 最小验证：同一份 20 万条数据各跑一遍。P95 延迟 A 为 210ms、B 为 340ms；24 小时失败率 A 0.02%、B 0.11%；一次典型变更耗时 A 为 40 分钟、B 为 3 小时 20 分钟（含查文档与踩配置）。
• 关键修正：B 的「维护成本」原估 2 人日/月，跑完一周修正为 6 人日/月——后端只有 1 人，这个差距直接改变判断，打分阶段完全看不出来。
• 结论：选 A。放弃 B 的理由写的是「B 在数据可控性上更强，但当前团队规模下，每月 6 人日的运维投入会挤掉主线开发，这个强项在我们这里无法兑现」。

最容易错的 3 个地方

第一，权重平均分。七项各 14.3% 看似公平，实际是把「上线时间」和「生态活跃度」等同。可靠做法是两两比较，逼自己在两项之间取舍。只要出现过一次「都很重要」，权重就废了。

第二，用印象填表。「性能好」「文档齐全」这类词填进去分数必然虚高，因为无法被证伪。检查方法：随便挑一格问「数据在哪」，答不出来就改成「未知」。未知超过三成，说明资料没收集够。

第三，只写选了谁，不写放弃了谁。选型结论最常见的写法是「经评估，A 最符合需求」。半年后系统出问题，没人记得 B 的强项是什么、当初为什么不要。取舍段落就是给未来的自己留证据。

可复用的东西

否决项写法：可判定、三条以内、附验证方式。这个模板同样适用于供应商筛选、工具采购、外包评估。

两两比较定权重：每次只问「只能保一个保哪个」，比完统计次数归一化。它比「请打分 1 到 10」可靠得多，因为人做二选一比做绝对评分稳定。

取舍三段式：选了什么、放弃了什么、如果错了怎么办。任何不可逆的决定——选型、招聘、签约——都能套这三段。

如果你也经常要做这件事，欢迎在评论区说说你的卡点和做法；也可以留言告诉我，你想看哪个岗位的哪件活怎么用 AI 拆。

admin 普通

收藏 海报 链接