选型方法论

选型最容易出错的地方，不是比不出来，而是比错了维度。功能清单可以并列贴出来，工程里的时间却花在环节与环节之间。这篇文章给一套能带走、能逐条问的比法——不比口号，比可数的事实。

一、先换掉那个比法

多数选型从一张功能对照表开始。表格越长，越像严谨。但功能表有两个结构性的问题。

第一，它是静态的。清单只回答「有没有」，不回答「在你的流程里好不好用」。一个动作在演示里是一步，到了你现场可能是三步加一次等待。

第二，它是可并列的。只要愿意写，任何两家的表格都能填满同样的勾。于是选型悄悄退化成「谁的材料更漂亮」。

更接近真实的比法，是换一个比较对象：不比功能，比流程。

二、把一次真实交付拆开

先把一次真实的工程交付拆成环节。大致是七段：

需求理解：把现场要的动作，翻译成工程里要写的逻辑。
组态与编程：变量、类型、输入输出映射、程序结构落到位。
编译与检查：语法与静态问题在提交前暴露出来。
下载与调试：从工程到设备，让它跑起来。
诊断与定位：出问题的时候，多快能指到具体位置。
测试与回归：改一处，确认没有改坏别处。
维护与交接：换了人来接手，工程还能不能看懂。

拆开之后，每一段都问同样三个问题：谁在做？交接几次？失败时路径确定吗？

这三个问题听着朴素，却能把大部分包装剥掉。

三、为什么「交接次数」值得当第一指标

交接次数的定义很简单：信息或产物在人与工具之间、工具与工具之间被搬动的次数。

复制一段文本算一次，切换窗口算一次，导出再导入算一次，等同事回一句也算一次。

它有三个好处：可数、可复现、难包装。你不需要相信任何一方的说法，只要在真实工作里数一次交接。同一个工程、同一个人，两个平台各做一遍，数字就摆在那里。

交接越少，工具越像流程的一部分；交接越多，它越像放在旁边的一个窗口。

四、四个维度，逐条问下去

维度一：工程上下文的连续性

关键问题：工具理解你的工程，还是只理解你粘贴给它的那段文本？

变量表、类型定义、输入输出映射、程序结构，是被工具读到的，还是被人抄过去的？
改一处，是一处生效，还是需要几个地方手动同步？

证据形态：看它能不能报出你工程里实际有什么，而不是复述你告诉它什么。

维度二：编译与运行的一致性

关键问题：工程里通过，和现场跑对，中间需要多少经验来补？

静态检查覆盖到什么程度？提交之前能拦住几类问题？
同一份程序，换一次构建环境，结果还能复现吗？

证据形态：同一份程序重复构建的结果是否一致，以及检查报告能不能指到具体行。

维度三：自动化的可重复性

关键问题：测试能不能自动跑，诊断能不能定位到行？

改一个变量，影响面能不能算出来？
一次回归里，有多少步是人必须做的？
报错给的是「某处有问题」，还是「第几行、什么问题」？

证据形态：一次真实改动后的回归记录——总耗时与人工步数。

维度四：迁移与退出成本

这一维度最容易被跳过，代价也最大。

工程文件是开放格式，还是只能被某一个工具打开？
标准库与行业库，换平台要不要重写？
团队的学习曲线有多长？

证据形态：拿一个你已有的工程，实际走一遍打开、编译、下载，记下要改多少处。

五、三个常见的比法陷阱

陷阱一：只看「有没有」。 有某项能力，不等于这项能力在你的流程里可用。要问的是它在第几段生效、中间需不需要人接手。

陷阱二：只看演示。 演示是按最优路径编排的，异常路径通常不在里面。而工作量恰恰藏在异常里。

陷阱三：只看一次。 单点试用的结论，抵不过一个真实工程的回归。一次能用，和改过三十次之后还能用，是两件事。

六、怎么组织一次真实验证

选一个你真实做过的小工程，不要用演示样例。
先定三个数：完成时间、交接次数、一次改动后的回归耗时。
同一个工程、同一个人，在每个平台上各做一遍。
每次都记录失败时的处理路径：是确定的三步，还是「看情况」。

这四个动作做完，结论通常自己会浮出来。

七、一张可以带走的对照清单

维度	该问的问题	什么样的答案是证据
上下文连续性	工具能否读到工程里实际有什么	它能列出你的变量与结构，而不是复述你的输入
编译一致性	重复构建能否复现	同一份程序的结果与检查报告逐次对齐
自动化可重复	一次回归里多少步必须由人做	可复跑的记录：总耗时与人工步数
退出成本	换平台要重写多少	拿真实工程走通一遍，记下改动处
流程交接	一次交付里交接几次	现场数一次，逐条列出发生在哪一步

填完这张表，选型讨论会从「哪家更好」变成「哪家在我的流程里留下的交接更少」。

阅读全文 →

选型方法论