误区一：按人头对标
拿同行几个人做 AI 当标准，忽略了场景密度与既有能力差异。纠正做法是先算本企业的任务量，再决定人数；对标只能用于校验量级，不能作为起点。用别人的编制解释自己的预算，通常说不清也站不住。
误区二：把团队当外包
业务提单、团队实现，做出来的东西没人用。纠正：业务方必须出人参与判定与验收，团队对可用性负责，不对业务结果单方面负责。这条边界不写清，项目一旦效果不佳，双方都会认为是对方的问题。
误区三：缺业务负责人
没有人为场景的业务价值负责，优先级只能靠谁声音大。纠正：每个场景指定一名业务负责人，写清其判定权与每周投入时间。这一条比增加工程师更能提升交付率，也更容易在预算评审时讲清楚。
误区四：只配开发
让工程师兼做知识整理、评测与运维，交付期一忙就全线停摆；系统上线三个月后无人维护，退化成演示。纠正：配置表里必须含运营与知识维护的投入比例，并在预算与考核中体现，否则它永远排在最后一位。
适用与不适用
适合谁
- 正在组建或重组 AI 团队的企业
- 团队已成立但交付率持续走低的组织
- 需要向管理层解释为何要增加非技术岗位的负责人
不适合谁
- 尚未启动 AI 场景规划的企业
- 只做一次外部采购、不打算建立内部团队的组织
典型场景
某制造企业的 AI 小组有六名工程师，交付率却持续走低。复盘发现所有场景都由工程师兼做知识整理，也没有业务负责人，需求每周都在变。调整后每个场景配一名业务负责人，知识维护交给两名一线员工兼职，工程师专注集成，季度交付数明显回升。
可执行步骤
- 盘点现有成员每周的实际工时去向，算出技术工作与杂务的比例，作为起点。
- 为每个在途场景指定一名业务负责人，写明其判定权与投入时间与验收责任。
- 把知识维护与评测拆成两项独立职责，指定人选与每周固定时段，并写进配置表。
- 用任务量而不是同行人数校验现有配置，看角色是否与工作量匹配。
- 每季度回看一次职责分工，防止悄悄回到工程师兼做一切的老样子。
常见坑
- 用同行人数作依据申请编制，批下来后没有对应任务，团队随后被拆散，招聘成本也收不回来。
- 业务负责人只挂名不投入，需求仍然反复变动，工程师疲于返工，最后把原因归到模型不好用。
- 知识维护长期由工程师兼任，交付期一忙就停更，回答质量下滑却无人认领，直到客户投诉才被发现。
自检与验收清单
- 配置是否按任务量对标，而不是按同行人数规模
- 每个在途场景是否都有业务负责人且有时间投入
- 知识维护与评测是否已独立成职责并指定人选
- 工时去向是否可查，是否每月复核并留记录归档
常见问题
业务负责人要投入多少时间？
视场景复杂度，通常每周两到四小时，用于判定口径、抽检样本与协调资源。挂名不投入的负责人比没有负责人更糟，因为责任看起来有人承担，实际问题仍然无人处理，团队也会失去方向感。
一定要设专职知识管理员吗？
不一定。场景少时可由一线兼职并固定时段；当知识条目超出维护能力、过期率上升时再考虑专职。判断依据是缺口大小，而不是组织规模或同行做法，早设也未必有用。
团队人数有没有参考值？
没有通用值。可先用场景数乘以单场景所需工时，再除以可用工时估算量级，用于讨论而非定编。具体编制由客户结合预算与业务节奏决定，外部方案无法替代内部判断。