谈到组建 AI 落地团队,很多企业第一反应是列一张长长的编制表:算法、后端、前端、测试、产品、项目经理。结果人招齐了,第一个场景还没跑通。FDE 模式的关键不是人多,是能力齐。
第一种是业务翻译。他的工作是把车间主任说的「这批料手感不对」翻译成「含水率超出区间 0.3 个百分点」。没有这个角色,技术方案永远在解决错误的问题。
第二种是动手工程师。他的工作是在现场把想法快速变成能点的东西。不需要架构级别的能力,但必须能独立跑通取数、处理、展示这条链。
第三种是结果验证。他的工作是盯住那个业务指标有没有真的变化,并且敢在没变化的时候喊停。这个角色最容易被省掉,也是项目烂尾最常见的原因。
在中小企业项目里,一个人同时承担业务翻译和结果验证是常见的,甚至三种能力集中在一个人身上也能跑——前提是这个人真的都会,而不是都不会。
在中大型项目里,通常是三到五人的小队:一个业务翻译、一到两个工程师、一个结果验证兼项目推进。再往上加人,边际收益迅速下降。
有个经验值得记:小队规模超过七人,内部沟通成本就会吃掉现场部署带来的速度优势。这时候正确的做法是拆成两个独立小队各打一个场景,而不是把一个场景交给八个人。
3人 最小可行小队规模 | 7人 沟通成本反超的临界点 |
很多项目失败,问题不在服务方队伍,而在客户那边没人接。至少要有两个角色:一个业务对接人,能代表业务部门拍板说这个逻辑对不对;一个数据对接人,能在两天内把要的数据取出来。
如果客户方这两个角色都指向同一个非常忙的中层,项目周期基本要打对折看待。这不是能力问题,是带宽问题。
更理想的情况是客户指定一名接手人,全程跟着学,项目结束后由他承接日常运维。这个人的存在,决定了这套系统是活下来还是慢慢死掉。
服务方的队伍决定项目能不能上线,客户方的队伍决定项目能不能活过半年。
我们做的是轻量版本:一个人负责全流程,加一组配置好的智能体承担重复劳动——数据清洗、文档生成、方案初稿、测试用例,这些原本要占掉大半人力的活,现在交给工具。
这样做的前提是方法必须足够标准。没有沉淀好的流程,一个人是撑不住的。所以我们把每个场景的交付步骤都做成清单,新场景照着清单走,而不是每次靠个人发挥。
AI 落地不是人海战术。三个人各司其职跑通一个场景,胜过八个人开六次会。