分析总览
当组织的动作开始由系统承载，动作本身就变成了数据。分析板块讲的是怎么用这些数据回答三类问题：业务上发生了什么（操作台账）、这套系统花了多少钱（用量与成本）、以及它现在是不是健康的（运行与可观测性）。
// 一句话理解
传统 BI 分析的是「业务系统里留下的结果」，AIDC 还能分析「这些结果是怎么产生的」——谁在什么时候、依据什么材料、做了什么判断。后者才是让组织真正改进的那一半数据，过去它根本不存在。
三个信号面
Action Log · 操作台账企业的动作历史：每次受控变更都沉淀为可分析的记录，用于审计、复盘与后续决策。
用量与成本分析每个数字员工、每个部门、每台服务器分别花了多少，钱花在哪个环节上。
运行健康与可观测性系统现在活着吗、慢在哪、错在哪——以及故障时去哪里查。
三类问题，三种数据
| 你要回答的问题 | 看哪个信号面 | 典型粒度 |
|---|---|---|
| 这个决定当时是依据什么做的？ | 操作台账 | 单次动作 |
| 这个流程哪一步最耗时／最常出错？ | 操作台账聚合 | 按动作类型、按周期 |
| 这个月为什么比上个月贵？ | 用量与成本 | 按数字员工、按模型、按天 |
| 这台服务器还值不值得开着？ | 用量与成本 | 按服务器、按月 |
| 为什么刚才没回复？ | 运行健康 | 按通道、按会话 |
| 上线之后错误变多了吗？ | 运行健康 | 按时间窗、按错误类型 |
分析的三条纪律
可对账优先Reconcilable每个指标都要能追到构成它的原始记录。一个说不清由哪些记录累加而来的数字，在经营讨论里没有说服力——不管它看起来多合理。分析页面上的每个数都可以点开看明细。
口径写在数字旁边Stated basis同一个「本月成本」，按实际账单算和按价目表估算，结果可以差出几倍。系统的做法是两种口径都给，并且各自标注清楚，而不是选一个显示。数据日期、统计窗口、是否含税，全部随数字一起呈现。
元数据不等于内容Metadata only分析层看到的是「关于动作的数据」——谁、何时、什么类型、耗时多少、结果如何——而不是动作涉及的业务内容本身。这条纪律让分析可以集中汇总，而业务数据仍然留在各自的边界内。
从数据到改进：四步
分析本身不产生价值，它的价值在于触发改动。这四步是数据变成改进的标准路径，也是演化闭环的观察端：
- 观察。从台账里找出重复出现的模式：同一类动作反复失败、同一个环节反复卡住、同一个问题反复被问。
- 诊断。判断这是材料问题、定义问题、权限问题还是流程问题。四类的处方完全不同，诊断错了改也白改。
- 提案与审批。把改动写成提案：改什么、影响哪些环节、如何验证、出问题怎么退回。高风险改动必须人工批准。
- 度量。改完之后回到同一组指标看是否真的变好。没有度量的改动只是换了一种做法，不是改进。
// 治理规则
任何对外呈现的经营数字，必须写明数据窗口与口径。「本月成本 X 元」这样的表述在系统里不合法，合法的写法是「本月截至某日，按实际账单口径，未税 X 元」。