多部门 AI 场景交付与治理
背景
需求散落在访谈、群聊、会议和一线反馈里。有人想减少重复处理，也有人把还在演示阶段的工具叫作「已经落地」。如果不先统一口径，项目越多，判断反而越乱。
我做了什么
我负责把口头需求还原成可跟进的事项，记录角色、频率、输入、输出、异常和验收方式，再按跑通、上线、采用、稳定、结果五个阶段审查证据。业务结果由业务负责人共同确认。
怎么做的
先按部门和流程收集问题，再拆成最小可验证的事项；已有材料完成去重，区分原始描述、独立场景与公开项目。每次进展都补充证据来源，缺少运行记录或业务确认时，不提升项目状态。
不同部门的工作节奏、风险和数据条件不同。同一个「能运行」，可能只是样例跑通，也可能已经有人持续使用。所以项目不能只数数量，还要看证据从哪来、下一步谁来确认。
现在的状态
2026 年 7 月的台账快照覆盖 8 个业务部门、38 个线上事项；从现有材料中去重并审查出 22 个独立场景。这些数字用于说明当时的工作范围和审查进度，不代表 38 个事项目前仍然活跃，也不代表它们都已稳定落地。
尚未解决的问题
- 部分早期事项缺少持续使用记录。
- 跨部门收益口径尚未统一。
- 业务结果需要更长观察周期。
角色与职责
需求拆解、项目跟进与证据审查
- 访谈业务人员，拆解问题、角色、输入输出和异常责任
- 建立事项台账，记录进度、使用状态与证据缺口
- 用统一阶段审查项目，避免用演示结果替代业务结果
边界与限制
- 38 个事项来自 2026 年 7 月台账快照，不代表当前仍有 38 个事项活跃
- 部门覆盖说明需求广度，不说明每个部门达到同一成熟度
- 业务结果仍需更长周期和业务负责人共同确认
当前进展与证据
- 场景覆盖：8 个业务部门（系统记录）
- 台账快照：38 个线上事项（系统记录；2026 年 7 月统计口径）
- 已审查案例：22 个独立场景（系统记录；从现有材料去重并完成初步证据审查）
项目材料
公开说明
只公开部门数量、事项数量和治理方法；不公开公司、客户、人员、内部系统、经营数据或原始材料。