过去两年,我们在一线观察到一个反直觉的现象:同样一个 AI 嵌入业务的项目——比如把 OCR、LLM 抽取、RAG 检索接进现有 ERP——一家二十人左右的精干团队,往往八到十周就能让它跑在真实业务上;而一家上千人的大型组织,同等复杂度的事情可能要花二十二到二十八周才能上线。中间这十几周的差距,并不来自工程能力,也不来自预算。它来自一个被严重低估的东西——决策路径的长度。

这篇文章不是反对规模化。规模化在很多场景仍然必要——比如需要全国分仓部署、需要七十二小时不间断巡检、需要做合规审计与三级等保的项目。我们要讨论的是另一个更具体的问题:当一个 AI 项目的核心矛盾是「不确定性」时,更短的决策路径会显著降低试错成本。而 AI 落地的早期阶段——v0 到 v1 之间——恰恰是不确定性最大的阶段。

所以这篇文章的对象,不是「请不要找大公司做 AI」,而是:当你面对一个还没跑通的 AI 场景,请慎重评估,更大的资源池是否会换来更慢的迭代速度

§ 01决策路径越短,迭代成本越低

我们做过一个简单的统计。把过去一年接触的十二个咨询客户分成两类:A 类是「需求方→实施方」中间最多隔一层(比如业务负责人直接对接实施团队);B 类是「需求方→中台→采购→IT→外包→实施方」中间至少四层。同样规模的 v0(八到十二周交付),A 类客户平均反馈一轮的耗时是1.4 天,B 类客户是9.2 天

这个差距并不是来自任何人不专业,而是来自一个无法回避的现实:每一层关系链都会增加「需要被同步」的人数,每一次同步都需要会议、文档、确认邮件。当你的项目本身只有十周,而单次反馈循环要消耗一周半,意味着你只能跑六轮迭代——而 AI 项目从 v0 到 v1 通常需要十五到二十轮真实业务样本的对照与调参。

A · 短路径 · 1-2 天/轮 · 高频迭代 B · 长路径 · 8-10 天/轮 · 低频迭代 业务负责人 实施团队 真实业务 回环 v0.X 业务方 中台 采购 IT 外包 实施方 真实业务 v0.X
Fig. 01 — 决策路径长度与迭代轮次上限 · 同样十周交付窗口

这就是为什么大型项目里,团队往往会用「先把需求冻结」来对冲决策路径太长的问题——但 AI 项目的需求恰恰无法在 v0 阶段冻结,因为我们不知道模型会在哪个具体的业务样本上失灵,也不知道客户的真实数据会以哪种方式偏离预期。需求只能在跑起来之后被发现。

§ 02内部协调成本是隐性税

规模化团队的第二个隐性成本,是协调税。当一个项目涉及五个以上的内部部门,每个部门都要安排一名对接人,每周至少要开一次「项目对齐会」,每个对齐会平均一小时。这种协调本身不创造产出,但消耗的工时却是真实的。

我们在一家上市制造企业做过测算:他们一个十二周的 AI 项目,工时总投入是 1,420 小时,其中真正写代码、跑模型、清数据的工时只有 660 小时——剩下 760 小时全都消耗在内部协调、PPT 汇报、跨部门确认上。换句话说,项目的有效产出率不到 47%

工时类型
大型组织 · 12 周
精干团队 · 8 周
实施工程(代码 / 模型 / 数据)
660 h
520 h
内部协调与对齐会
420 h
48 h
跨部门确认与流程审批
240 h
22 h
汇报材料与高层沟通
100 h
18 h
合计工时
1,420 h
608 h
有效产出率
46.5%
85.5%

Tab. 01 — 同一类 AI 嵌入项目 · 两类组织的工时分布对比 · 数据脱敏

这不是组织管理问题,而是组织规模的结构性副作用。你无法让一家大公司像小团队那样运作,就像你无法让一艘货轮像快艇那样转向。结构本身就在那里。

「规模化的真正成本,不是钱,是毫秒级别的决策摩擦累积出来的时间。」

— 现场观察 · 2026·03

§ 03聚焦不是规模小,是路径短

这里要澄清一个常见的误解:聚焦的团队不等于「人少」。我们见过五个人的团队反而比两个人的更高效,因为五个人之间的角色分工足够清晰——一名业务理解者、一名工程实施者、一名数据清洗者、一名前端集成者、一名客户对接者,正好能形成一个独立闭环;而两个人会陷入「我又写代码又对接客户又写文档」的疲劳轮换。

所以聚焦的核心不在人数,而在从需求到代码到反馈的路径长度。判断一个团队是否真正聚焦,可以问三个问题:

·当业务方临时改一个判断条件,多久能体现在 v0 的真实运行上?精干团队是几小时,大型组织是几天甚至几周。

·当一个模型在某个边缘 case 上失灵,谁来负责定位、谁来修、谁来回放?如果回答里出现「需要先找一下负责那块的同事问问」,路径就已经太长了。

·当客户的真实数据格式发生变化(比如他们升级了 ERP),多久能完成对接的同步修改?这个数字最能反映团队的反应灵敏度。

· · ·

§ 04一个反例:当聚焦反而拖慢

当然,聚焦的团队不是万能的。我们在 2026 年初遇到过一个反例——客户是一家全国连锁餐饮企业,门店一千两百多家。最初我们按惯例上了一个精干小组,八周做了一个不错的 v0 demo,跑在三家试点门店上效果很好。但当要推广到全国一千两百家时,我们立刻撞墙了。

原因是规模本身就是一个独立的工程问题。一千两百家门店意味着一千两百套不同的网络环境、二十多种不同版本的本地 POS 系统、上百种被门店店长私下改过的工作流。这不是一个「聚焦」可以解决的问题,这是一个需要专门的运维团队、专门的部署管线、专门的灰度发布机制的问题。

这时候我们做的,是把项目交接给客户原本的 IT 团队,由我们继续做提示词维护与模型迭代,由他们做规模化部署与一线运维。两个团队各自做自己擅长的事,分工清晰。这个项目最终在三十二周内完成了全国上线——比客户最初担心的「四十八周」要快不少,但也远比 v0 时的八周要长。

这个反例告诉我们的不是「聚焦没用」,而是聚焦适用于不确定性高的阶段,规模化适用于不确定性已收敛、需要复制的阶段。两者不是对立,是接力。

§ 05怎么判断你需要哪种团队

所以回到开头那个问题。当你面对一个 AI 落地项目,怎么判断该找什么样的团队?我们的经验是看三个维度。

第一·业务场景是否已被验证。如果这是行业里已经有十个标杆案例的场景(比如电商客服意图分类),大公司的标准化方案足够;如果这是你们独有的、行业里没人做过的场景,精干团队的快速迭代更适合。

第二·数据是否已经稳定。如果你的数据格式三个月内不会变、数据量足够大、清洗规则已经稳定,大型团队的工业化方案能压低单位成本;如果数据正在变化、规则在持续被发现,短路径的精干团队能更快响应。

第三·失败成本是多少。如果项目失败的代价是「损失几百万」,请走大型组织的合规与质保路线;如果失败的代价是「一个 v0 推倒重来」,请用短路径快速试错。

这三个维度判断下来,大部分中型企业的 v0 阶段都更适合精干团队。等到 v0 验证通过、需要复制到二十个分公司或一百家门店时,再切换成规模化交付——那时候不确定性已经大幅收敛,规模化的优势才真正显现。

AI 落地这件事,最大的浪费不是工时,而是用错节奏的团队,做不该现在做的事