- 员工用了多少次 AI，算不上成果，就像发出去的邮件数量算不上销售额。
- 先选定业务上看得懂的成果单位，比如每份报价单的成本或每个工单的处理时间，然后再开始衡量。
- 成本要算全：系统费用、维护费用，以及人工检查所花的时间，光算省下的时间是不够的。
先定成果单位，再算收益
报告说团队这个月用了三千次 AI，您还是答不出公司到底得到了什么。能拿来做决策的数字，必须用业务看得懂的单位来表示，比如每份报价单的成本，或者从客户提问到得到答复的时间。
写给开发团队 · 技术细节
提示词（Prompt）数量、登录次数和培训时长只是使用信号，衡量不了生产率（Productivity）。先定义合格成果（Accepted Outcome），比如已审批的报价单、已关闭的工单、良品或可投产的机时，再计算通过质量检查的产出与总投入之比，同时设定护栏（Guardrail），规定投诉、合规或安全指标不得变差。
用 2–4 周时间采集基线数据，按复杂程度分组，看中位数和 P90。要从接单一直量到交付，AI 负责的那一段只是其中一部分。如果起草时间少了 30 分钟，检查时间却多了 20 分钟，净收益就是 10 分钟；而且在把这 10 分钟用于增加产出、减少加班，或者省掉原本计划增加的产能之前，它还不等于钱。
把总成本和覆盖率（Coverage）都算进去
算值不值的时候，很多人只算省下的时间，却忘了三样东西：每月的系统费用、人工检查所花的时间，以及系统还做不了、只能退回手工处理的工作。
| 成本 | 包含项目 |
|---|---|
| 建设 | 流程设计、数据清理、系统集成、测试 |
| 运行 | 软件许可、API、托管、监控、技术支持 |
| 人工 | 审核、例外处理、培训、推广使用 |
| 风险 | 差错、返工、事故、停机 |
| 变更 | 政策、数据或模型变化时的调整 |
写给开发团队 · 技术细节
按每个合格成果的成本（Cost per Accepted Outcome）计算，不要按每次调用的成本（Cost per Call）计算，并把收益乘以覆盖率。如果系统只能接下 40% 的工作，就不能拿每个工单省下的时间去乘全部工作量。多个应用场景（Use Case）服务同一批员工时，要小心重复计算工时。
写给开发团队 · 技术指标
收入增量（Revenue Uplift）要用提升的转化率 × 受影响的业务量 × 边际贡献（Contribution Margin）来算，不能把全部收入都算进去。省下的招聘（Avoided Hire）必须以已批准的人力计划为依据。员工体验这类软性收益（Soft Benefit）应该单独衡量，没有证据就不要硬折算成钱。
用试验确认改善真的来自 AI
写给开发团队 · 技术细节
使用对照组，或者在同一时期内逐个团队上线（Rollout），并按季节、产品组合和员工经验做调整。开始之前先定好误差范围和样本量。系统拒绝处理或转为人工处理的工单也要计入，不能只挑成功案例。数据由流程负责人（Process Owner）和财务部门共同确认。
| 衡量层级 | 示例 |
|---|---|
| 采用情况 | 活跃用户、工作流使用量 |
| 流程 | 交付周期（Lead Time）、人工处理时间（Touch Time）、例外情况 |
| 质量 | 一次做对率（Right-first-time）、差错、人工改判 |
| 业务 | 单位成果成本（Cost/Outcome）、产能、利润率 |
| 客户 | 响应、解决、留存 |
把价值真正兑现，并按项目组合（Portfolio）来管理
试点之前就要定好省下的时间用在哪里：减少加班、空缺岗位不再补人、多做客户跟进、多跑几轮产品试验，或者把人调去做价值更高的工作。运营部门要安排产能，HR 要调整岗位职责，财务部门要确认结果。否则省下的工时会散成零碎的空档，在财务报表上看不出来。
写给开发团队 · 技术细节
项目组合仪表盘显示基线、目标、实际值、负责人、投入、收益和风险，每季度据此决定扩大（Scale）、改进（Improve）、暂缓（Hold）还是停止（Stop）。把一次性收益（One-time）和持续性收益（Run-rate）分开，等系统稳定后再核查。第一周团队还在挑简单的工单做，别拿那时的数据宣布 ROI。
好的衡量方法不负责证明 AI 一定划算，它帮企业把资金和人力投到真正见效的应用场景上。敢于叫停不划算项目的企业，扩大好项目的速度，会比为了维持成功形象而保留每个试点的企业更快。
FINANCE NOTE · 别让数字好看得失真
从业务成果倒推到 AI，画出价值树（Value Tree）
从利润、成本或产能出发，拆解出需要改变哪些 KPI。比如因为更快回复销售线索（Lead）而增加的收入，就必须看到响应时间缩短、转化率提高，以及受影响的线索数量，然后再对应到 AI 省掉了哪一步。这样倒推，可以防止有人把省下的工时直接说成收入，中间却没有任何依据把两者连起来。
给商业论证打个折扣（Haircut）
做一个保守情景，老老实实地扣掉采用率、覆盖率、差错和爬坡期（Ramp-up）的影响。如果在保守情景下仍能回本，这个项目就比那种只有在所有人 100% 使用、模型从不出错时才划算的项目稳健得多。
提示：在仪表盘上把收益分成“潜在”（Potential）、“已验证”（Validated）和“已兑现”（Captured）三类。管理层能看清每个项目走到了哪一步，多个团队重复计算收益的情况也会减少。
从知识到真正能解决问题的系统
问题的根源
ROI 出现在企业把省下的时间转化为产能、更低的成本或更好的客户结果的时候，光是 AI 省了时间还不算。
分步解决方案
- 建立价值树，从业务结果倒推到流程指标和 AI 的贡献
- 采集基线和对照组数据，包括覆盖率、采用率、差错和总成本
- 指定价值兑现负责人（Value Capture Owner），设置项目组合关卡：扩大、改进、暂缓、停止
建立能把使用量和业务价值分开来看的衡量系统
财务价值由财务部门或流程负责人来定，DNA Maker 不替他们做这个决定。我们帮助做的，是让从使用系统到产生结果的整条路径可以核查：一起设计要记录的事件、基线、质量护栏和价值树，说明改动一个步骤应该怎样影响处理周期（Cycle Time）、产能或客户。这样管理层就能分清潜在收益、经试验确认的效果，以及企业真正兑现的价值。
衡量计划（Measurement Plan）明确之后，DNA Maker 可以开发埋点（Event Tracking）、成本与质量遥测（Telemetry）、试验仪表盘和收益登记表（Benefits Register），直接从实际运行的系统中取数，并配上 AI 智能体（AI Agent）汇总变化、指出需要核实的假设。我们能负责数据与软件架构、Web 仪表盘、系统集成、开发，以及上线后的调优。如果您手上有好几个 AI 项目，却还比较不出哪个该扩大、哪个该停，我们可以帮您建立一套共同的语言和工具，让投资讨论都基于同一份证据。
SOFTWARE ENGINEERING GLOSSARY
软件工程术语表
这张表用不着背。它的用处是让管理层、工作负责人和开发团队沟通时，对同一个词不会有两种理解。请把释义、示例和右侧的问题一起看，这些问题常常能在开发开始之前，把隐藏的范围、风险和成本揭示出来。
| 术语 | 是什么 | 通俗示例 | 高管应问开发团队的问题 |
|---|---|---|---|
| Event Tracking | 记录系统里的关键事件 | 记录接单、审批和结单的时间 | 要衡量成果，除了使用量，还需要记录哪些事件？ |
| Telemetry | 系统持续发出的状态和使用数据 | 查看报错次数和 API 费用 | 哪些数据有助于排查问题，哪些超出了需要？ |
| Baseline | 系统改变之前的数值 | 使用 AI 之前的平均结单时间 | 试验之前那段时间的数据，能代表正常的工作状态吗？ |
| A/B Test | 在条件相近的两组之间比较两种做法 | 一个团队用新工作流，另一个团队照旧 | 两组怎样保证可比？怎样避免影响客户？ |
| TCO | 系统整个生命周期的总拥有成本 | 包括开发、云服务、技术支持和检查时间 | 集成、模型和人工检查的维护费用都算进去了吗？ |