写代码，还是上平台？POC 之后的那道选择题

演示很顺利，演示向来都很顺利。团队里有人接上一个模型，对准一个真实问题，当着满屋子的人拿出了一个确实管用的东西。在场没有一个人问：十八个月后，它归谁管？

这个问题总是姗姗来迟，多半出现在预算会上，问法大致是：我们是老老实实用代码把它做出来，还是放到自动化平台上？它常被当成技术选型，其实不然。它关乎的是：出了故障谁能打开它，凌晨三点坏了会怎样，以及到底有没有人能证明它值得做。

接下来会发生什么，业界不缺数字，只是多数被引用得走了样。下面这个经得起推敲。

企业每启动 33 个 AI 概念验证，只有 4 个走到了生产环境。

来源：IDC 与联想联合研究，CIO 报道，2025 年 3 月

一年之内，放弃大部分 AI 项目的企业比例从 17% 跃升至 42%；平均每家企业有 46% 的概念验证未及投产便被放弃。

来源：标普全球市场财智（S&P Global Market Intelligence），《Voice of the Enterprise》，2025 年 10 月

先看清这两个数字量的是什么。前者统计的是从未上线的试点，后者统计的是中途放弃的项目。两者都没说模型不行。再读那些追溯根本原因的研究，结论高度一致：技术大体行得通，掉链子的是技术周围的组织。

超过 80% 的 AI 项目以失败告终，大约是不涉及 AI 的 IT 项目失败率的两倍。

来源：兰德公司（RAND Corporation），《AI 项目失败的根本原因》，2024 年

所以，自建还是上平台，说到底不是工具之争，而是要看您正走向这两种失败中的哪一种。

两条路线，一个决定

这张表把真正的决定藏了起来，本文后半部分正是为此而写。两列都能让您在周五前拿出一个能跑的东西，但明年还在跑的只有一个；是哪一个，全看您对下面几个问题的回答。

您的项目偏向哪一边？

在线页面上有一个交互式罗盘，会把四个倾向换算成指针的位置。下面列出同样的四个问题，以及每个选项的倾向。

1. 出故障时，什么会受损？
   • 倾向代码：业余项目，不碰客户数据，不涉及资金
   • 倾向平台：受监管或涉及资金，牵涉记录、支付与信任
2. 十八个月后谁来负责？
   • 倾向代码：搭建者一直维护，始终是同一个人
   • 倾向平台：换人接手，交接迟早会来
3. 运行频率多高，数量多少？
   • 倾向代码：只有一个，偶尔运行，是您的第一个自动化
   • 倾向平台：整批自动化，几十个，高频运行
4. 谁在做判断？
   • 倾向代码：固定规则，无需判断
   • 倾向平台：模型嵌在循环里，重复之中需要判断

四个问题，按序作答

这类决策通常被做成一张核对清单，而清单暗含各项分量相等的意思。事实并非如此。下面的问题按顺序排列：哪个问题先给出明确答案，讨论就到此结束，后面可以不读。

一旦出错，代价有多大？

从这里谈起，因为这个问题压倒后面所有问题。

如果只是闲置服务器上的业余项目，不碰客户数据，也不碰钱，风险承受度几乎没有上限。怎么快就怎么做。本文其余部分与您无关，不必再读，直接动手。

如果是受监管企业中的流程，涉及客户记录或资金往来，问题会立刻成倍增加。它能对外发送，还是只能读取？出错能否撤回？故障是当场暴露，还是悄无声息地拖上六周？谁能看到凭据？还有决定多数此类项目命运的那一问：安全部门会批准一个他们无法查验的东西吗？

AI 抬高风险的方式很具体：决策路径越不可见，风险越高，不管底层用的是什么。后果一旦是真实的，AI 的决策就必须留痕、有边界，还要让搭建时不在场的人也看得懂。代码能做到，只是多数团队没有为此留出预算；而且无论选哪一列，这份工作量都一样。

• 显性失败：流程停下并报警，周二前就能修好。这种不足为惧。（周二前修好）
• 静默失败：字段被改名、API 超时、模型吐出貌似合理的胡话，却没有任何地方发出提示。（一跑就是五周）

这就说到凌晨三点的问题，因为系统确实会在凌晨三点出故障。该担心的不是显性失败。流程停下并报警，周二前就能修好。代价高昂的是静默失败：一个字段被改了名，一次 API 调用超时，模型开始吐出貌似合理的胡话，却没有任何地方发出提示。这种故障能持续五周，等到有人发现，四分之一的数据已经错了。重试、告警，加上一份真有人看的日志，都不是上线后再补的功能。自动化是资产还是负债，差别就在这里；可工期一紧，最先被砍的偏偏也是它们。

十八个月后由谁负责？

这个问题最常改变答案，也最适合由高管来回答，因为它根本不是技术问题。

如果搭建者和维护者始终是同一个人，选最快的方案即可。如果不是，就有了交接问题，而自动化往往就死在交接上。这里有三种角色，各有各的需求：

1. 谁来搭建：开发人员可以任选方案。市场或运营人员想亲自搭建，只有一条路可走，而且必须借助他们看得见的东西。
2. 谁来维护：一年后，某个 API 变了，或某条提示词需要调整。接手的人如果不是搭建者，就得在一个下午之内把它打开、读懂。可视化工作流，连一辈子也写不出等效代码的人都能读懂。这一点不可小看。
3. 谁来修改：这比读懂的门槛更高。不懂技术的同事，能否不提工单就自行更换凭据、调整计划任务？如果每个小改动都得经过同一位技术人员，此人就成了整个职能的瓶颈，到头来往往会厌烦自己亲手搭的东西。

交接测试很直接：搭建者下个月要是离职，它还活得下去吗？同事能打开、能看懂的东西，活得下去。只有作者自己看得懂的代码，会一直跑到出故障那天，然后谁也不想碰。

眼下还有一个新变数，值得点明。AI 生成的代码产出极快，却往往没有人（包括写提示词的人）真正吃透。代码写得便宜，维护问题并不会因此消失，反而更尖锐，因为惯常的退路（作者记得当初为何这样写）已经不在了。

运行多频繁？这类东西您有多少？

这其实是两个问题，需要分别回答。

频率决定成本，这笔账并不复杂。确定性流程每天跑 500 次，单次成本几乎为零。同样的任务交给模型，每天推理 500 次，就是每天 500 次模型调用，没有尽头，而且是在重新决定一件早已定下的事。只要写得出覆盖所有情况的规则，就把规则写下来。花钱让模型一遍遍重新推导规则，不只是浪费，还可能让第 79 次运行给出不一样的答案。

自动化的规模，总要等到为时已晚才有人过问。第一个自动化放在哪里都行，第四十个就不行了。几十个自动化同时运行之后，就需要一个地方把它们统统摆出来：哪些跑了，哪些失败了，修好之后又如何重跑失败的那次。这个需求说来就来，要在四十个定制脚本上逐一补建，本身就是一个项目。企业之所以统一采用编排层，最常见的原因正在于此，与单个自动化放在那里是否更好毫无关系。

接下来这部分，平台厂商宁愿您晚点再想明白。多数编排工具按执行次数、按任务或按席位计费，而包含您真正需要的治理功能（审计日志、基于角色的访问控制、私有部署）的那一档，很少是起步时用的那一档。拍板之前，先拿候选产品的定价页，把一个每天运行 500 次的流程算一遍，再按 5,000 次算一遍，因为让合作走到尽头的，往往是第二个数字。自托管会改写这笔账，同时带来另一种成本：平台也得由您自己运维。

比价格更硬的约束是天花板。逻辑装得进平台的框框时，平台很好用；装不下的时候，失败不是一头撞上墙，而是变通办法一点点堆积：这里塞一个代码节点，那里接一个通往旁路服务的 webhook，直到您发现自己在维护一套分布式系统，只不过它碰巧画在别人的产品里。流程若有真正的算法复杂度，这一天会来得很早。退路也要在一开始就算清：导出工作流容易，导出它所依赖的运行环境却难，“不锁定”是有待验证的说法，不能照单全收。

这里刻意不点产品名。今天开出的任何候选名单，等您读到时多半已经洗牌，而上面这些问题会比它们活得更久。无论哪些工具上了名单，都做同一个测试：在上面搭一个真实流程，交给一个没参与搭建的人，然后看会发生什么。

谁来判断：规则、模型，还是人？

这个问题放在最后，因为它最有意思，却最不具决定性。人人都从它谈起，也正因如此，许多项目最后落错了地方。

• 规则：无需判断。每天把每一张发票从邮箱转存到存储空间，方式始终如一。做成确定性流程，然后不必再操心。
• 人：全程都要判断。做调研、写初稿、清理一份杂乱的一次性数据集。由您掌舵，每一步都取决于您对上一步的判断。这是一次有您参与其中的智能体会话，硬套流程只会徒增负担。
• 模型：重复之中的一次判断。每天 500 张客服工单以同样方式进来、按同样方式分派，但总得有人逐张读过，判断它讲的是什么。这个人可以是模型：在一个其余部分完全确定的结构中间，它占据一个看得见的步骤。

还有一个常被跳过的子问题：决定何时做出？模型起草回复交由人批准，与模型直接发出，两者差别很大。如果由人批准，这个检查点就是流程的一部分，不管用什么搭建，都要让它清晰可见。

答案通常落在哪里

四个问题，多数人会发现，往往还没轮到其他问题，其中一个就已经给出了全部答案。

这是速度与可逆性之间的取舍。损失不大时，速度占上风，答案指向代码。损失越大，能看清并撤回发生过的事就越比速度要紧，答案指向平台。多数企业处在中间，所以答案常常是“两者兼用”。这不是推诿。拆分点通常落在一个明确的位置：反复运行的骨架交给工作流，唯一需要判断的那一步，是嵌在其中的一次模型调用，您可以在那里盯住它。

究竟快了多少，没人说得清

2026 年 2 月，一家非营利研究机构发文说明，它被引用最多的研究结论已不再符合现实，而它给出的替代数字同样不宜轻信。这是本文最有价值的一条信息，可引用原结论的人几乎都没留意到。

先看结论本身：

作者已于 2026 年 2 月宣布过时

资深开发者获准使用 AI 工具后，完成真实任务反而多用了 19% 的时间，事后却估计 AI 让自己快了 20%。

来源：METR 随机对照试验，2025 年 7 月，16 名开发者，246 项任务

这项结论被四处引用，成了 AI 编程工具不管用的证据，本月仍有人这样引用。但 METR 后来用更新的工具重做了研究，并公布了结果。

对于参与后续研究的原有开发者，我们目前估计其提速 18%；对于新招募的开发者，估计提速为 4%。

来源：METR，2026 年 2 月，针对 2025 年末的工具

他们甚至在原研究页面的摘要上方加了一个红框，注明该结果已经过时。

同一项研究里，两个本该一致的数字：

• 感觉更快：+20%
• 实际更慢：−19%
• 偏差（向有利于自己的方向）：39 个百分点

由此可得两点。其一，今天仍把 19% 当作现状来引用的人，引用的是一个连作者都已声明不再反映现状的数字。拿这一点检验厂商是否只看标题，成本低，效果好。其二，也更有用：首次研究中的开发者，对自身效率的判断偏差达 39 个百分点，而且偏向自我美化。他们可都是经验丰富的人，面对的是自己熟悉的代码。

您的团队不会例外，我们也一样。所以，“这样更快吗？”的答案从来不靠举手表决，而要靠测量：开工前测一次，之后用同样的方法再测一次，并把两次的日期都记下来。

先写下叫停标准

上面每一个决定，都预设这个东西应当存在。有时它不应当存在，而确认这一点的时机就是现在，趁大家仍然乐观，因为也只有此刻，叫停标准才能写得坦诚。

选定哪一列之前，先写下一旦出现就叫停的结果。不是“如果行不通”，而是一个数字，外加一个日期。格式总是同样的三项：

1. 质量底线：第六周时，分派准确率低于 X。
2. 成本上限：业务量真正起来后，单次运行超过 Y。
3. 交接测试：到第四周，搭建团队以外仍无人打开过它。

您的数字不会和我们的相同。要紧的是，在任何人对答案产生利害关系之前，这些数字已经白纸黑字地写下来。

第三项最常被漏掉，预示性却最强。如果只有搭建者能打开它，您得出的结论并不是需要更多工程时间，而是第二个问题的答案，再多的工程投入也改变不了。

这是 AZIMUTH 方法中的定方位（Bearing）阶段，详见“方法”页面。客户对这一阶段抵触最大，直到它第一次为他们省下一个季度。

上述研究所能证明的，比人们通常据此宣称的要窄。IDC 把 33 比 4 的比例归因于组织准备度，即数据、流程和基础设施。兰德公司则指向领导力与沟通。这些研究里，没有人说过“没人被允许叫停”。这是我们自己的判断，来自我们自己参与的项目，在此特别注明：我们所见最烧预算的项目，很少是快速失败的那些，而是从未就“何为失败”达成共识的那些。它们一路随波逐流，直到某位高层失去耐心，把整个项目群一刀砍掉，而不只是砍掉其中押错的那一注。站得住脚的叫停，比缓慢的放弃代价更低，而看着您干净利落地叫停一个项目的董事会，批准下一个时也会更快。

所以，工具问题要认真回答，它确实重要。只是请先回答另一个问题，而且要写下来，趁所有人还相信项目会成功：要发生什么，我们才会叫停？如果没人愿意把这句话写下来，选什么工具都救不了您。

最近审阅：2026 年 7 月。这些页面每季度复读一次，更正会留档，不会悄悄改动。若这里某个数字已经过时，那就是我们的差错，请发邮件至 hello@bearingbridge.com 告诉我们。