技术选型评审最容易犯的错是什么？

最常见的是"先有结论再找理由"——评审人心里已经想用某个技术，评审只是给它背书。破解办法是先定评价维度和权重（性能、团队熟悉度、生态、维护成本、迁移成本…），公开写下来，再让候选方案对着维度打分。维度先于结论，评审才不是走过场。

可行性报告和技术方案有什么区别？

技术方案回答"打算怎么做"，可行性报告回答"这么做行不行、有什么风险、代价多大"。可行性报告的核心是把关键假设变成可验证的结论：性能够不够要有 PoC 压测数据，第三方接口通不通要真调一次，团队能不能驾驭要看学习曲线评估。没有验证环节的"可行性报告"只是包装过的乐观。

当决策的关键假设无法靠经验直接判断、且选错的返工成本很高时。典型场景：没用过的技术栈承载核心链路、性能是硬指标但不确定能否达标、要对接不熟悉的第三方系统。PoC 的目标不是做出可用产品，而是用最小成本证伪或证实那个最危险的假设。

需要，但要匹配规模。小团队不需要几十页文档和评审委员会，但需要把"为什么选这个、放弃了什么、关键风险是什么"写下来——哪怕一页。写下来的价值不在当下，在半年后有人问"当初为什么这么定"时，有据可查而不是全凭记忆。

技术评审不是"专家拍脑袋说这个行那个不行"，而是一套可复现的决策方法：先定评价维度与权重，再让方案对着维度打分，最后用可行性验证（PoC）替代口头判断。本文给出选型评审的完整框架、一份可行性报告该包含什么，以及三个让评审失效的坏习惯。

技术评审最大的失效模式，是先有结论、再找理由：评审人已经想好用什么，评审只是给既定选择背书。对抗它的方法很简单——把评价维度和权重放在结论前面。

一套可信的评审有三步：定维度 → 对维度打分 → 用验证替代口头判断。下面展开。

选型讨论一上来就争”A 好还是 B 好”，几乎必然跑偏——因为每个人心里的”好”权重不同。正确的第一步是把维度和权重摆到桌面上：

权重按项目实际定，不是通用模板。同一个技术，在”赶交付的初创”和”求稳的长期系统”里得分可以完全相反——这正常，因为权重不同。把权重写下来，评审就从”谁嗓门大”变成”对着标准算分”。

维度定好，候选方案逐项打分（可用 1–5 分或高/中/低）。这一步的价值不在最后那个加权总分，而在打分过程逼出的真实差距：

打分表还是沟通工具：和业务方、团队对齐时，一张表比一段论述清楚得多，分歧点一眼可见。

评审里最危险的是”我觉得应该没问题”。凡是关键假设无法靠经验直接拍板、且选错返工代价高的，就该用 PoC 验证：

PoC 不是做产品，是用最小成本证伪或证实那个最危险的假设。一次两天的 PoC，常常能省掉两个月的错误方向。

最后一句最重要：注明”在什么条件下这个结论会变”。技术决策都有前提，写明前提，报告才经得起时间。