当 AI 项目分散在多个部门时，最容易得到的数字是“做了多少个”。它适合说明需求热度，却很容易制造错觉：一个现场演示、一个刚上线的工具和一个稳定运行的流程，可能被记成三个同等成熟的项目。
数量没有错，错的是把数量当成结果。
先统一阶段，再讨论进度
我在项目跟进中使用五个公开阶段：跑通、上线、采用、稳定、结果。
跑通要求方案在样例上产生可检查结果。它回答技术可行性，不回答真实使用。
上线要求工具进入真实环境，有明确入口和基本反馈。它回答能否被访问，不回答是否有人持续采用。
采用要求业务人员在真实工作中持续使用。最好有业务确认、运行记录或交付痕迹，而不是只依据开发者描述。
稳定要求异常处理、维护方式、权限和责任边界已经明确。一次没有报错的运行不等于稳定。
结果要求经过足够周期，有可以解释的业务影响，例如处理时间变化、错误率变化或交付周期变化。结果必须说明基线、口径和来源。
这五级不是为了把项目管理做复杂，而是为了避免一个词承担太多含义。
证据来源也要一起记录
同一个数字，依据不同，可信度也不同。我会至少区分三类来源：
- 系统记录：由台账、日志、问卷或运行结果直接支持。
- 业务确认：由真实使用者确认，但尚未形成完整系统数据。
- 内部估算：基于现有信息给出的区间，用来辅助判断，不对外包装成精确结果。
例如，“连续使用约一个月”可以来自业务确认；“每次大约十余分钟”如果没有完整日志，就应该标为内部估算。把来源写出来，不会削弱案例，反而让读者知道结论能走多远。
把证据缺口当作下一步工作
项目审查不只是给现状打标签，更重要的是找到缺口。
如果方案已经跑通但没上线，下一步通常是补入口、权限和错误反馈。如果已经上线但没有采用，要回到业务路径，检查结果是否进入原有工作位置。如果已被采用却无法证明价值，就需要补基线、运行记录和复核数据，而不是继续堆功能。
证据缺口让优先级从“谁声音大”变成“哪一步最值得验证”。它也允许团队停止：如果使用者不采用，或者维护成本长期高于收益，结束项目也是一种有效结论。
对外案例同样需要分级
公开案例最容易在结果表述上失真。开发团队知道一个项目的来龙去脉，访客只能看到几句话。只写“提效”“赋能”和“全面落地”，读者无法判断它是技术演示，还是已经产生稳定结果。
更诚实的案例应该同时写清楚当前状态、证据来源、本人职责、仍未解决的问题和披露边界。能公开多少就写多少，不能证明的部分保留为限制。
项目数量适合回答“我们正在处理多大的范围”；证据等级才回答“这些工作真正走到了哪里”。两者一起看，企业 AI 的进展才不会被一个漂亮数字遮住。