选型最容易出错的地方，不是比不出来，而是比错了维度。功能清单可以并列贴出来，工程里的时间却花在环节与环节之间。这篇文章给一套能带走、能逐条问的比法——不比口号，比可数的事实。
一、先换掉那个比法
多数选型从一张功能对照表开始。表格越长，越像严谨。但功能表有两个结构性的问题。
第一，它是静态的。清单只回答「有没有」，不回答「在你的流程里好不好用」。一个动作在演示里是一步，到了你现场可能是三步加一次等待。
第二，它是可并列的。只要愿意写，任何两家的表格都能填满同样的勾。于是选型悄悄退化成「谁的材料更漂亮」。
更接近真实的比法，是换一个比较对象：不比功能，比流程。
二、把一次真实交付拆开
先把一次真实的工程交付拆成环节。大致是七段：
- 需求理解：把现场要的动作，翻译成工程里要写的逻辑。
- 组态与编程：变量、类型、输入输出映射、程序结构落到位。
- 编译与检查：语法与静态问题在提交前暴露出来。
- 下载与调试：从工程到设备，让它跑起来。
- 诊断与定位：出问题的时候，多快能指到具体位置。
- 测试与回归：改一处，确认没有改坏别处。
- 维护与交接：换了人来接手，工程还能不能看懂。
拆开之后，每一段都问同样三个问题：谁在做？交接几次？失败时路径确定吗？
这三个问题听着朴素，却能把大部分包装剥掉。
三、为什么「交接次数」值得当第一指标
交接次数的定义很简单：信息或产物在人与工具之间、工具与工具之间被搬动的次数。
复制一段文本算一次，切换窗口算一次，导出再导入算一次，等同事回一句也算一次。
它有三个好处：可数、可复现、难包装。你不需要相信任何一方的说法，只要在真实工作里数一次交接。同一个工程、同一个人，两个平台各做一遍，数字就摆在那里。
交接越少，工具越像流程的一部分；交接越多，它越像放在旁边的一个窗口。
四、四个维度，逐条问下去
维度一：工程上下文的连续性
关键问题：工具理解你的工程，还是只理解你粘贴给它的那段文本？
- 变量表、类型定义、输入输出映射、程序结构，是被工具读到的，还是被人抄过去的？
- 改一处，是一处生效，还是需要几个地方手动同步？
证据形态：看它能不能报出你工程里实际有什么，而不是复述你告诉它什么。
维度二：编译与运行的一致性
关键问题：工程里通过，和现场跑对，中间需要多少经验来补？
- 静态检查覆盖到什么程度？提交之前能拦住几类问题？
- 同一份程序，换一次构建环境，结果还能复现吗？
证据形态：同一份程序重复构建的结果是否一致，以及检查报告能不能指到具体行。
维度三：自动化的可重复性
关键问题：测试能不能自动跑，诊断能不能定位到行？
- 改一个变量，影响面能不能算出来？
- 一次回归里，有多少步是人必须做的？
- 报错给的是「某处有问题」，还是「第几行、什么问题」？
证据形态：一次真实改动后的回归记录——总耗时与人工步数。
维度四：迁移与退出成本
这一维度最容易被跳过，代价也最大。
- 工程文件是开放格式，还是只能被某一个工具打开？
- 标准库与行业库，换平台要不要重写？
- 团队的学习曲线有多长？
证据形态：拿一个你已有的工程，实际走一遍打开、编译、下载，记下要改多少处。
五、三个常见的比法陷阱
陷阱一：只看「有没有」。 有某项能力，不等于这项能力在你的流程里可用。要问的是它在第几段生效、中间需不需要人接手。
陷阱二：只看演示。 演示是按最优路径编排的，异常路径通常不在里面。而工作量恰恰藏在异常里。
陷阱三：只看一次。 单点试用的结论，抵不过一个真实工程的回归。一次能用，和改过三十次之后还能用，是两件事。
六、怎么组织一次真实验证
- 选一个你真实做过的小工程，不要用演示样例。
- 先定三个数：完成时间、交接次数、一次改动后的回归耗时。
- 同一个工程、同一个人，在每个平台上各做一遍。
- 每次都记录失败时的处理路径：是确定的三步，还是「看情况」。
这四个动作做完，结论通常自己会浮出来。
七、一张可以带走的对照清单
| 维度 | 该问的问题 | 什么样的答案是证据 |
|---|---|---|
| 上下文连续性 | 工具能否读到工程里实际有什么 | 它能列出你的变量与结构，而不是复述你的输入 |
| 编译一致性 | 重复构建能否复现 | 同一份程序的结果与检查报告逐次对齐 |
| 自动化可重复 | 一次回归里多少步必须由人做 | 可复跑的记录：总耗时与人工步数 |
| 退出成本 | 换平台要重写多少 | 拿真实工程走通一遍，记下改动处 |
| 流程交接 | 一次交付里交接几次 | 现场数一次，逐条列出发生在哪一步 |
填完这张表，选型讨论会从「哪家更好」变成「哪家在我的流程里留下的交接更少」。
八、我们自己的做法
讲方法论容易飘，所以也说一说我们自己的选择。
kVPAC 走的是 AI 原生 PLC 编程平台的方向：让自然语言参与生成，让编译保证生成的结果能运行，让智能诊断把问题指到具体行，让自动化测试把回归交还给机器。
这里的关键不是多加一个对话框，而是让 AI 与工程工具按一条标准通道对接——MCP 做的正是这件事：工具声明自己有什么能力，AI 按协议调用，结果直接落回工程里。
我们用来判断自己是否合格的那把尺，就是这一篇里的那把：数交接。逻辑生成后直接落进工程、编译错误被定位到行、测试用例生成完立刻能跑——这些环节里，交接消失了，时间就还给了工程。
九、现在可以做什么
- 关注我们，拿这套选型清单的可打印版本，以及 AI 原生 PLC 编程的入门示例。
- 在公众号留言区告诉我们，说说你选型时最纠结的那一条——高频问题我们会整理成公开的对照方法。
- 直接下载，在真实工程里把上面那几步各走一遍（Windows / macOS / Linux）：下载 kVPAC IDE
选型比的从来不是谁的功能更多，而是谁在你的流程里留下的交接更少。这把尺，你自己就能拿起来量。
（完）
English version
How to Compare PLC Programming Platforms: A Method, Not a Scorecard
Most platform comparisons start with a feature table, and that is where they go wrong. A feature list answers whether something exists, not whether it works inside your workflow. The real cost lives between the steps.
So break one real delivery into stages: requirement, programming, compile and check, download and debug, diagnosis, regression, maintenance, handover. For each stage ask: who does it, how many handoffs, and is the failure path deterministic?
Then count handoffs: every copy-paste, window switch, export-and-import, or wait for a reply counts as one. They are countable, reproducible, hard to dress up.
Compare platforms on four dimensions. Context continuity: can the tool read what is actually in your project? Build consistency: does the same program build the same way, and can the checker point to a line? Automation: how many regression steps still need a human? Exit cost: how much survives a move?
Avoid three traps: judging by feature presence, by a polished demo, or by a single trial. Run one real project per platform and record the same numbers — time to finish, handoffs, and the cost of one change.
At kVPAC we hold ourselves to the same ruler, in an AI-native PLC programming platform: natural-language generation, compile-enforced results, diagnosis that points to a line, automated regression. MCP makes the connection standard, so generated work lands in the project, not in a chat window.
Follow us for a printable version of this checklist, or leave a comment in the WeChat article comment section with your hardest comparison question.
往期推荐
- 《AI 原生 PLC：让工程师把时间还给机器设计》
- 《MCP 是什么：工业软件为什么都要接这条通道》
声明
本文涉及的产品理念、技术协议与功能描述基于公开资料与 kVPAC 团队实际工程实践整理。文中观点仅代表技术团队的工程判断，不构成任何商业建议或投资决策依据。如有疏漏，欢迎通过公众号「凯控技术」留言指正。