四类动作四个角色
口径定义、数据管道、分析解读、模型与评测四类动作，分别对应分析负责人、数据工程、分析师与 AI 运营四个角色。小团队可以合并，但口径定义不能交给写提示词的人，否则容易被工具牵着走，验收时也没有裁判。
最小配置是一种组合
一名懂业务的分析师加半名数据工程，再配少量治理时间，通常能让单域场景跑起来。不要先设 AI 数据科学家这类空岗，职责不清的岗位半年内会变成项目协调员，招聘成本也收不回来。职责写清楚了，招人才不会招错方向。
界面在指标字典上
谁定义指标、谁维护语义层、谁批准对外数字，要写成三行职责。三者混在一人身上时，出错后无法区分是口径错还是实现错，复盘会变成追责，团队随后开始互相留证据。空岗还会让现有成员分心，项目节奏更慢。
权限不归业务自授
数据分级、行级权限与导出审批应由 IT 与安全部门掌握，业务侧只提需求。把权限下放给项目组，短期方便，长期是合规隐患，出事时责任也很难界定到具体岗位。三行职责写进岗位说明书，复盘时才有依据。
适用与不适用
适合谁
- 已有一个业务域数据可用、准备扩到多域的企业
- 分析团队被取数与做表占用大量时间的企业
- 正在设计数据岗位职责与考核的负责人
不适合谁
- 尚无稳定数据源、只能做演示的团队
- 希望用 AI 取代全部分析岗的企业
典型场景
某制造企业的分析团队三人，过去一半时间在取数与对齐口径。团队把指标定义收归分析负责人，数据工程负责管道与权限，AI 运营维护提示词与测试集。三个月后取数时间下降，分析师把精力转向业务解读，例会争议也少了。
可执行步骤
- 盘点口径定义、数据管道、分析解读与评测四类动作，标出当前责任人
- 把口径定义指定给业务分析负责人，不要交给工具维护方或外部服务商
- 数据权限与导出审批划归 IT 与安全部门，业务侧只提需求并留申请记录
- 设 AI 运营岗维护提示词与测试问题集，每季度复盘一次分工是否合理
常见坑
- 把口径交给工具方：供应商按自己的理解建指标，业务方不认，项目卡在验收阶段。
- 设空岗等人才：职责不清的岗位招进来也无事可做，一年后撤销，招聘与磨合成本都沉没，风险留给了自己。
- 分析师兼管权限：为赶进度自行开放数据，埋下合规风险，审计时说不清授权依据。
自检与验收清单
- 口径定义、管道、解读与评测四类动作是否都有责任人
- 指标定义人是否与工具维护人分开，界面是否清楚
- 数据权限审批是否留在 IT 与安全部门，业务侧只申请
- 测试问题集是否有明确维护人，并随指标更新
常见问题
只有 Excel 团队怎么起步？
先把常用指标与口径写成表，指定一人维护；用固定模板做月度分析，再逐步接入系统数据。人少时更要收窄场景，别同时开三条线，否则每条都做不深，也难积累经验。
要不要专职提示词工程师？
通常不必。提示词维护可并入 AI 运营或分析师职责，但要有固定时间与评测机制。专职岗位适合多业务域并行、模型频繁迭代的团队，其他情况容易变成闲置岗。
分析师会被替代吗？
取数与做表的时间会被压缩，解读、口径判断与跨部门沟通的需求上升。企业应提前做能力盘点，把分析师往业务解读方向培养，而不是简单按人数调整编制。