多部门 AI场景交付与治理

业务问题

AI 需求不是从一张整齐的需求表里出现的。它们散落在访谈、群聊、会议和一线反馈中：有人想少做一次复制粘贴，有人需要从图片里取数，也有人把一个仍在演示的工具称为“已经落地”。如果不先统一口径，项目越多，判断反而越混乱。

真实约束

不同部门的工作节奏、风险与数据条件完全不同。同一个“能运行”，可能只是开发者在样例上跑通过，也可能已经有人每天使用。项目不能只用完成数量排序，还要知道证据来自哪里、目前缺什么、下一步由谁确认。

我的职责

我负责把口头需求还原成可跟进事项，记录角色、频率、输入、输出、异常和验收方式；再以“跑通、上线、采用、稳定、结果”五个公开阶段审查证据。不能确认的内容保留为缺口，不替业务方下结论。

处理方式

1. 先按部门和流程收集问题，不从工具能力倒推需求。
2. 把每个问题拆成最小可验证事项，明确当前状态和责任人。
3. 对已有材料去重，区分原始描述、独立场景与可公开案例。
4. 每次进展都补充证据来源；没有运行记录或业务确认，就不提升状态。
5. 把仍未解决的问题留在台账中，作为下一轮验证条件。

运行状态

目前覆盖 8 个业务部门，台账中有 38 个线上事项持续跟进；从现有材料中去重并审查出 22 个独立场景。这个数字用于说明工作范围，不代表所有事项都已经稳定采用，更不代表都产生了可量化业务结果。

仍未解决的问题

• 部分早期事项缺少持续使用记录，只能确认曾经跑通或上线。
• 跨部门的收益口径尚未完全统一，不能简单相加。
• 业务结果需要更长的观察周期，也需要业务负责人共同确认。

可复用方法

企业 AI 项目先需要一套证据语言，再需要更多项目。统一阶段、来源和缺口后，团队才能决定继续投入、补证据、暂停，还是停止。

披露边界

这里展示的是经过脱敏的范围与方法。公司名称、部门名称、客户信息、员工身份、内部系统、经营指标和原始需求材料均不公开。