AI试点项目为何在部署前停滞？

一个能在会议室里打动高管的试点项目，在周二早上可能毫无用处。它有精致的界面、狭窄的数据集、配合的用户，还有一支随时纠正每个错误的团队待命。然后有人问出那个显而易见的问题：既然技术在演示中明显有效，AI试点项目为何会停滞？

因为演示证明的是可能性。部署则需要围绕这种可能性建立一套运行系统：足够干净的数据、人们愿意真正改变的工作流、愿意承担风险的决策负责人、集成能力，以及一个经得起推敲的财务论证。大多数试点具备第一项，极少数具备其余各项。

这并不是反对AI，而是反对把一个受限的实验当作一门生意的证据。

AI试点项目为何停滞？它从一开始就没有为规模化设计

许多组织启动AI试点是为了释放势头信号，而非回答某个决策。项目简报里含糊地写着“探索机会”或“建设AI能力”之类的话。没有人明确规定项目结束时必须满足什么条件才能赢得生产预算。没有人指明哪个工作流将被淘汰、加速，或大幅提升准确度。

这种含糊在政治上很方便，却也让成功无法被诚实衡量。

一个严肃的试点从一开始就想清楚生产决策。如果工具在既定流程内、由指定操作员为采用负责，并达到既定阈值的表现，公司就会为部署提供资金。如果达不到，公司就会终止它。评判标准应当足够严苛，让供应商无法靠一个漂亮的仪表盘和几个轶事就蒙混过关。

然而，组织往往因为某些用例容易演示而选择它们。总结文档、起草邮件、对支持工单分类、在一小批语料上回答问题，这些都可能有用。但有用并不等于有经济后果。一个只能为志愿者节省几分钟的试点，很难在预算、安全审查、流程重设计和变更管理面前站住脚，而这些都是投入生产所必需的。

问题不在于模型能否生成一个答案。问题在于一个更好的答案，更快或更便宜地交付，是否会改变某个决策，或是否能消除足够多的人力工作以至于值得投入。

隐藏的产品是工作流

创始人常把自己的产品描述为AI智能体、副驾驶或模型层。买家也可能使用同样的说法。这两种描述都没有触及真正必须奏效的东西。

产品是围绕模型的工作流：输入从哪里来、谁来核实、随后采取什么行动、行动记录在哪里、如何处理异常，以及系统出错时会发生什么。模型只是其中一个组件。它或许是技术上最令人惊艳的组件，但它不是整个产品。

这正是试点与现实碰撞之处。模型也许能给出一个可信的建议，但建议出现在团队工作的系统之外。或者它需要来自三个定义相互冲突的系统的数据。或者它无法把结果解释得足够清楚，让一位受监管的审核人接受。又或者本应使用它的人早已有了变通办法，看不出有理由再采用一个新标签页。

这些问题没有一个是光鲜的，但它们全都是产品问题。

因此，在任何人讨论模型选型之前，试点应当先绘制出完整的工作。什么触发这项任务？需要哪些信息？哪些步骤属于判断，哪些是重复性的，哪些受政策约束？边缘情况如何处理？错误由谁负责？如果答案是“我们会在概念验证之后再弄清楚”，那么这个概念验证测试的正是问题中最廉价的那部分。

能访问数据不等于数据已就绪

路演材料里常见的一句话是，客户拥有独特的数据优势。有时确实如此。但更常见的情况是，客户拥有大量来源不明的数据、不一致的标签、无人理顺的权限，以及一个各部门定义各异的业务口径。

连接到数据与让数据可用不是一回事。一个检索系统可以让内部知识库看起来很聪明，直到它检索出一份过时的政策、一份重复的文档，或一份被当作运营事实呈现的销售材料。一个自动化系统可以完美地处理干净的案例，同时悄然在那些占用团队大部分时间的异常情况上失败。

试点之所以能撑下去，是因为有人在挑选源材料、缩小任务范围，并盯着每一个输出。生产环境会拆掉这些护栏，波动会一下子全部涌来。

这正是为什么评估不能是事后才想起的事。团队需要一套用真实工作构建的、有代表性的测试集，包括那些丑陋的案例。他们需要就准确度、完整度、延迟、每任务成本和可接受的升级率达成一致的定义。对于生成式系统，他们还需要把流畅的回答与正确的回答区分开来。前者比比皆是，后者才是买家掏钱要买的东西。

如果一位创始人无法解释系统在上线之后（而不只是演示之前）如何被评估，那么这款产品尚未从技术能力跨越到可靠的基础设施。

没有人对商业结果负责

试点往往有热情的赞助人，却没有担责的负责人。创新团队可以采购实验。IT可以批准访问权限。业务部门可以提供用户。法务可以识别风险。然而没有人对损益影响负责，也没有人有权在采用停滞时调整工作流。

这种结构产出的是会议，而不是部署。

担责的负责人必须有理由容忍这种颠覆。他们需要一个可衡量的结果，在系统奏效时会改善，同时也需要一项授权，在系统不奏效时去改变行为。没有这些，工具就变成了可选项。可选的工具是拿来跟习惯较量的，而不是跟现状的成本较量的。习惯获胜的频率，比幻灯片承认的要高得多。

对投资者而言，这是一个藏在明处的尽职调查问题。要问一问：这家初创公司的客户拥护者能否批准生产推广，预算是否掌握在那个职能部门手中，以及是否存在一条可信的实施路径。一个客户标志和一则试点公告回答不了其中任何一个问题。

对创始人而言，这是一个资格甄别问题。一个说不出生产负责人、源系统、评估标准和部署预算的潜在客户，并不是一笔正在推进的企业级销售。它是一项披着采购外衣的调研。

令人兴奋的部分过去之后，经济账变得更糟

早期试点看起来便宜，是因为它们的成本并不完整。供应商吸收了实施工作。客户提供了一小群配合的用户。使用量很低。人工审核会在错误造成损害之前将其拦下。还没有人为集成、治理要求、支持负担，以及实际用量下的模型使用定价。

然后生产方案来了，经济账变得清晰可见。

有些用例仍能轻松跨过门槛。高频、重复、有可衡量质量阈值和清晰记录系统的工作，能产生令人信服的回报。另一些则不行。一个低频、集成昂贵、且强制人工审核的工作流，可能在战略上有用，但不太可能证明一笔广泛的平台采购的合理性。

这正是有纪律的运营者把一项功能与一门生意区分开来的地方。他们计算现有流程的全负担成本、新流程的预期成本、错误成本、实施成本，以及采用曲线。他们不会仅仅因为某项任务变快了就假设能节省人力。只有当组织能够重新调配人力或避免增加人力时，产能才会变成节省。

相关的问题不是“这能节省时间吗？”几乎任何东西在受控环境里都能节省时间。真正的问题是：“如果这项技术被大规模采用，什么经济事件会因此改变？”

试点应当证明什么

最好的试点是刻意狭窄的，但它们并非做做样子。它们测试那些将决定产品能否赢得在生产环境中存在权利的约束条件。

这意味着使用实时或有代表性的数据，尽可能连接到真实的工作流，并将表现与当前流程对比衡量，而不是与一个想象出来的手工基线对比。这意味着纳入那些并非因热情而被精挑细选出来的用户。这意味着追踪纠正率和失败模式，而不仅仅是参与度。它还意味着在把这项工作称为成功之前，先厘清谁付钱、谁对采用负责，以及实施需要什么。

这里存在一个取舍。测试真实的约束会让试点更慢、更不上镜。它也可能暴露出这个机会比最初的叙事所暗示的要小。这很好。这比在一年的企业级销售或一笔七位数的平台承诺之后才学到同样的教训要便宜得多。

沃创（SproutVest）的观点很简单：试点应当减少关于部署的不确定性，而不是制造关于某个技术门类的乐观情绪。如果它无法告诉创始人接下来该造什么，或告诉投资者采用是否真实，那它就不是试点。它是一场配了API密钥的表演。

对任何团队来说，有用的收尾问题不是试点是否成功了。要问：什么证据能让组织在下个季度为生产提供资金，然后就好像有人必须用自己的预算去为那个决策辩护一样去运行这个试点。真正的工作从那里开始。

您的领导方式在哪里有效，又在哪里正在消耗公司？

这个博客讨论的多数问题，最终都回到创始人如何经营公司这一点上。藤架领导力诊断把它拆成六个维度共24道行为锚定题：约12分钟，即时出结果，自助版免费。

开始藤架领导力诊断 →

想了解兼职高管或顾问合作？预约探索性通话 →