企业 AI 项目该配哪些角色，缺了哪个就推不动？
最少五个角色：业务负责人，对要改善的业务指标负责、有优先级拍板权；一线用户代表，每天真用这个工具的人；技术或数据负责人，管系统约束、数据条件和权限审批；内部推广角色，组织培训、收集反馈、统计使用数据；立项决策人，管预算和验收签字。缺前两个，项目容易做成技术演示；缺后两个，试点转不成日常使用。动手前先逐个把名字填进立项书，给每个角色写清每周投入，五项合计通常在 2 到 4 人日（经验值）；哪一格填不出名字，那里就是最先出问题的地方。
先把五个名字填进立项书
- 先指定一名业务负责人，要求其对业务结果负责且有优先级拍板权
- 从目标部门抽一名高频用户代表，参与需求确认与试用评审
- 指定技术或数据负责人，负责接口清单、数据条件与权限审批
- 指定内部推广角色，负责培训组织、反馈收集与使用数据统计
- 给每个角色写清投入方式，例如每周半天还是每天到场
边界与提醒角色可以兼任但不能空缺：小团队里业务负责人兼决策人很常见，但一线用户代表若由管理者兼任，收集到的需求会偏向管理视角，一线真实卡点进不了清单，此时要单独保留一线用户的试用与反馈通道，否则上线后用起来的还是管理层。上线后第一个月再统计一次各角色实际投入，与立项书核对偏差。
业务牵头还是 IT 牵头，立项挂在谁名下？
判断标准是一条：谁对要改善的业务指标负责，谁牵头。改善客服响应、销售跟进这类指标的项目挂业务部门，IT 做支撑；知识库治理、研发效率类项目挂 IT。两个部门都不牵头、由独立项目组挂空的立项，验收时往往找不到对数字负责的人。动手前先做两件事：把拟改善的指标写进立项书并指定认领人；核对数据与系统约束涉及哪些部门、权限审批要走几道，超过三道的提前约 IT 排期。
谁背指标，谁牵头
| 牵头方 | 适合的项目 | 常见风险 |
|---|
| 业务部门 | 客服、销售、审核等业务指标类场景 | 技术选型与数据接入需要 IT 提前介入 |
| IT 部门 | 知识库治理、研发效率、数据类场景 | 需求停留在功能层面，业务指标缺人认领 |
| 联合立项 | 跨部门流程、涉及写回业务系统的场景 | 分工没写清，验收时互相指认 |
边界与提醒联合立项不是平均分责：要写清业务方对指标负责、IT 方对系统与数据负责，验收时各查各的那一半；立项书里只写共同负责四个字的，出问题时最容易变成双方都不负责，这类写法宁可拆成两条单列。
一线用户该在什么阶段进来，怎么用起来？
真实用户要在验证阶段就进来，而不是上线前培训时才见到产品。深云官网的 FDE 页把「让真实用户完成一次完整工作任务」作为验证阶段的输出要求——试用者要能用它跑完自己的真实任务，而不是按演示脚本点一遍。用户进得晚，返工集中在上线前，正好是最贵也最赶的时段；进得早，卡点在原型期就能消化掉大半。
试用即验收，别等上线再看
- 在验证阶段安排 3 到 5 名一线用户各完成一次真实任务，全程记录卡点
- 把试用反馈按改交互、改知识、改流程三类归口，逐条指定责任人与期限，单个条目处理期限不超过 3 个工作日
- 复测卡点清单并逐项核对，上线前把未消除项写进已知问题与规避方法
边界与提醒用户参与不等于用户决策：交互细节可以按多数意见调整，但涉及权限、数据边界和流程改动的意见必须回到业务负责人与技术负责人那里裁决，否则试点需求会越堆越多，范围在验证期就失控，常见信号是需求清单超过 20 条且过半与验收指标无关。
供应商侧的角色怎么算，边界划在哪？
客户侧不需要面对割裂的咨询、产品、开发、实施与运维多方。深云公开的 FDE 页面把交付写成由 FDE 统一协调、对同一业务结果负责的联合团队，同时写明客户仍要出业务负责人、一线用户和技术或数据负责人。也就是说，联合团队不是外包甩手：谁出数据、谁出人、谁拍板，逐项写进一张双方都签字的责任表，边界才算划清。
联合团队，不等于甩手
- 把双方角色写成一张责任表，逐项标注甲方责任人与乙方责任人
- 明确数据与权限的提供方和时限，接口清单逐条写清排期
- 约定每周例会与升级路径，卡住超过两个工作日就升级到决策人
边界与提醒联合团队模式下甲方不是没有活：数据整理、权限审批、用户组织这三类工作乙方替代不了，甲方投入不足时进度卡点通常出在自己这边；排人力计划前先核对自己这三项能不能按时到位：数据提供逾期超过一周、权限审批超过 5 个工作日，就先压缩场景范围再谈排期。
从试点到推广，团队编制要不要变、怎么变？
试点期 3 到 5 人够用：业务负责人、用户代表、技术对接加上交付方。进入推广期要补两类人：分部门的种子用户，每部门 1 到 2 名，负责本部门的示范与答疑；固定的运营角色，统计使用数据、组织反馈、跟进知识更新。动手前先核对试点数据里哪个部门用得最多，把种子用户先配在那里。没补运营角色的推广，通常停在第二个月。
试点期小团队，推广期补运营
| 阶段 | 团队构成 | 关键动作 |
|---|
| 试点期（常见 2 到 4 周，经验值） | 3 到 5 人小团队 | 每周记录使用与卡点，留存人工基线对比 |
| 推广期 | 增设种子用户与运营角色 | 按部门组织培训，逐周统计采用数据 |
| 稳定期 | 运营角色为主，团队收缩 | 每月复盘知识更新与效果指标 |
边界与提醒表中人数与周次为经验值，不是效果承诺：跨部门流程多的企业，推广期可能拉长到一两个月；种子用户若由各部门随手指派而不确认投入时间，培训会走过场。指派前先和部门负责人核对该人选每周可投入的工时。
角色都配齐了还是推不动，先查什么？
依次查四样：决策人是否挂名不出席，例会连续两次缺席就要换授权人或换会；指标是否有人认领，认领人是否还在岗、口径是否改过；例会是在看数字还是听汇报；升级路径是否真的通，卡点能不能在两个工作日内到达能拍板的人。多数推不动的项目卡在第一条，而不是技术问题。
推不动，先查决策机制
- 查例会出席记录，决策人连续两次缺席就约单独汇报或换授权人
- 核对立项书里的指标认领人是否还在岗、指标口径是否被改过
- 把例会议程改成只看数字与卡点，汇报材料提前一天发出
- 测试一次升级路径：把当前最大卡点直接提交决策人，记录多久有回复
边界与提醒推不动也可能是场景本身不成立：指标改善空间小、数据条件不满足时，组织再齐也推不出结果。决策机制修完连续四周仍无改善，应回到场景评估重新判断是否停用，把资源让给更成立的场景，不要靠加人会去硬推。
内容说明
角色构成与交付分工的表述引自深云官网 WorkBuddy 服务、FDE 模式、企业 AI 应用开发与智能体开发服务四个公开页面；文中人数、周次、天数为经验值，不是效果承诺。
需要评估这类场景的落地路径？
深云做企业 AI 生产化交付，可以先给一版场景判断与实施路径，再决定要不要做。
了解深云的交付方式