按交付链路分工，不按销售漏斗分工
这一页给的是职责结构，不是人员名单，也不标人数与编制
我们把一个 AI 项目要走的路拆成四段：把需求问清楚、把模型与数据做出来、把系统跑稳、上线之后接着运营。每一段有人主责，但同一个项目从头到尾由同一批人跟，不在中途换手——换手丢的是上下文，而 AI 项目的效果恰恰取决于上下文。
所以这张图看的是"一件事该找谁、谁对什么负责"，而不是"谁向谁汇报"。
负责人
定方向、对外签约、对交付质量兜底；方案评审与否决权在这里
需求与方案
把业务问题翻译成可验收的技术方案
- 场景梳理、数据现状盘点
- 可行性判断与风险提示
- 方案书、里程碑、分项报价
- 验收标准与评估集定义
算法与数据
负责效果能不能达到约定水位
- 模型选型、微调与推理部署
- 文档解析、切片与检索链路
- 数据清洗与标注规范
- 错例分析与效果迭代
工程与部署
负责系统能在真实环境里稳定跑
- 前后端与业务系统集成
- 容器化部署与上云架构
- 权限、日志、监控与备份
- 产线设备与相机对接
运营与支持
负责上线之后不掉链子
- 操作培训与文档交付
- 知识库维护与内容运营
- 数据看板与使用分析
- 故障响应与 GEO 监测
六个业务方向分别由谁主责
主责指对结果负责的那一组，参与组按项目实际范围拉进来
| 业务方向 | 主责 | 通常一起干的人 | 交付看什么 |
|---|---|---|---|
| AI 大模型研发 | 算法与数据 | 工程与部署 | 事先约定的评估集通过率 |
| AI 工业应用 | 算法与数据 | 工程与部署、需求与方案 | 产线漏检/误检的实测口径 |
| 软件开发 | 工程与部署 | 需求与方案 | 功能清单与验收用例 |
| 云服务 | 工程与部署 | 运营与支持 | 可用性、恢复演练与成本账单 |
| SaaS 产品与运营 | 运营与支持 | 工程与部署、需求与方案 | 活跃与留存数据、迭代节奏 |
| GEO 生成式引擎优化 | 运营与支持 | 需求与方案 | 主流 AI 问答里的引用与提及变化 |
三件事在图之外，靠机制保证
不靠某个人的责任心，靠固定动作
方案评审
每个项目开工前过一次评审，重点不是怎么做，而是该不该做。
- 数据拿不拿得到、够不够、干不干净
- 做成了用什么数字判断成功
- 当前技术做不到的部分当场写明
效果验收
AI 相关的交付不接受"演示时看着挺好"，只接受按评估集跑分。
- 评估集在方案阶段就与业务方共同确认
- 错例逐条归类：数据问题、检索问题还是模型问题
- 达不到约定水位就如实说明，不悄悄降标准
故障响应
上线后按事先约定的响应时限处理，责任落到人而不是落到群。
- 监控与告警在部署阶段就配好，不等出事再补
- 响应时限与升级路径写进合同或运维约定
- 每次故障出复盘，改进项进下一个版本
我们没有的设置
说清楚不设什么，比列一堆头衔有用
不设的岗位
专职销售售前 PPT 岗
转包中介纯项目管理岗
为什么
谈需求的人后面要负责把东西做出来，所以不会为了签单先答应下来。项目由干活的人自己排期、自己对进度负责，中间不再加一层传话的人。承接范围之外的需求，我们在方案阶段就当场说明做不了和为什么。