团队用了 AI，到底省在哪里？

先回答要不要继续，而不是用了多少次

客服团队用 AI 整理帮助中心。初稿很快就有了，但同事还要核对步骤、补漏、修改，再交给负责人。到了周末，负责人真正想知道的是：这套办法值得推广，还是应该先改一改？

这篇练习会产出一份简短复核：人实际投入了多少时间、最终质量是否达标，以及数据完整时才能给出的成本估算。下载包里是四个虚构文档任务的记录，不是真实客户成果，也不是 Onevium 性能测试。

之前的报表教程教你把杂乱记录核对清楚。这次新增的是可比任务的配对、明确的质量门槛，以及一个不会把“费用未知”算成零的小工具。

OpenAI 原文带来的启发

OpenAI 在 9 月 16 日的文章中，把 AI 使用情况与团队想改善的工作联系起来：先建立原有流程的基线，计入检查和修改，再比较收益与 AI、设置和支持成本。释放出的工作容量，还要继续观察它能带来什么业务结果。

我们借鉴这套测量思路，设计了一个独立的本地文件练习。原文提到的管理后台、插件和 API 是 OpenAI 的功能；这里不把它们说成 Onevium 内置能力。准备自己的任务记录和一段普通脚本，就能先练会这套方法。

先约定怎样比才公平

每份任务说明记录一次人工处理和一次 AI 辅助处理，两边的范围和最终验收标准相同。这个例子要求：内容完整、事实符合批准的来源、步骤能操作、没有已知阻断问题。初稿再快，没有达到标准也不能算完成。

把人实际投入的执行、复核、返工分开记，准备和交接也要计入；同一个人的同一分钟不能重复算。等待单列。几个任务同时等待，不能把等待分钟相加就叫“交付周期”；要研究交付速度，应另外记录实际开始和完成时间。

CSV 按明确的任务编号配对，并检查任务类型和难度是否一致。这不能代替人判断任务是否真的可比。同一个人做第二遍可能已经熟悉内容，要记录执行顺序；条件允许时，用不同执行者或交替顺序降低这种影响。

在 Onevium 打开练习并运行

下载并解压练习包。在 Onevium 选择“添加项目 → 打开已有文件夹”，选中解压目录，在该项目下新建会话。先用“浏览全部文件”看看 sample-runs.csv、pilot-costs.json 和 README.md。示例场景是帮助中心内容更新；包里提供的是虚构测量记录，不是已经生成的帮助文章。

需要 Node.js 20 或更高版本。先在终端用 macOS 的 pwd 或 PowerShell 的 Get-Location 确认当前目录是解压后的练习文件夹，再执行 node --version 核对；如果没有 Node，先按你平常使用的方式配置环境。不需要安装依赖包、开通分析后台或连接业务系统。

先执行下面第一行，确认 14 组检查全部通过，再执行第二行。结果会写入 results 目录：summary.json、中英文两份报告。两个命令均不联网、不调用模型；再次执行会覆盖同名报告，保留历史时换一个输出目录。也可以让 Onevium 助手在当前项目中执行这两条命令，并展示实际输出。

node --test test.mjs
node summarize.mjs sample-runs.csv pilot-costs.json results

先核对人花了多少时间

打开 results/report-zh.md，对照 CSV。每个人工任务都用了 30 分钟执行、8 分钟检查、2 分钟修改，合计 40 分钟。AI 辅助记录同样包含人的准备、检查和返工；脚本加总这三项，不把 AI 等待时间算成人工工时。

四组虚构任务，人工共 160 分钟，AI 辅助共 115 分钟，观察差值是 45 分钟。四组最终结果都在所记返工后标为通过。请注意，“通过”是教学数据给定的人工验收假设，不是计算器读过文档后替你判定的质量。

读取当前项目的 README.md、sample-runs.csv、
pilot-costs.json 和 results/summary.json。
用任务编号解释 160 和 115 分钟分别怎样算出。
区分人工执行、复核、返工和等待。
检查质量标记、费用是否完整。
展示金额算式和每一个假设。
不要修改输入，不要补猜缺失值，
不要宣称真实 ROI，也不要外推全年收益。
最后列出还需要负责人核实的事情。

少用 45 分钟，也未必适合马上推广

示例中所有比较记录使用同一个完整用工成本假设：每小时 USD 60，包含相关用工支出。45 分钟对应 USD 45 的工时成本估值。再假设其中只有一半能用于其他有价值的工作，可利用容量估值就是 USD 22.50。这个 50% 是需要核实的假设，不是测出来的生产率。

四次 AI 任务的模型/工具费合计 USD 4.50。另有 15 分钟设置工时，按每小时 USD 60 计，再加 USD 5 的支持/订阅分摊，合计 USD 20。因此净容量估值为：USD 22.50 − USD 4.50 − USD 20.00 = USD −2.00。

在这些假设下，结论更接近“先改善试点，再考虑扩大”。这不能证明现金亏损，也不是工资减少额或新增营收。要继续记录腾出的时间实际做了什么，再用业务证据判断是否少了一笔支出、多完成了工作或带来了收入。设置成本也不能摊给还没发生的未来任务。

证据不完整，就让结论停下来

检查脚本还覆盖了不好看的情况：某笔费用缺失时，仍展示工时，但不算金额；最终质量失败或还没审核的任务，仍留在全部配对的工时记录中，整个试点暂不计算金额。另列的合格任务小计有明确标记，不能拿它把失败任务藏掉。

同一条记录重复、人工或 AI 记录缺一边、同一任务换个配对编号又算一遍，都会报错。先解决数据问题，不选择对 AI 最有利的那次。编号检查只能挡住明显重复，不能证明同一团队处理的任务在统计上彼此独立。

本入门计算器也要求比较记录使用相同小时费率，否则暂缓容量和净估值。低费率的人做得更久，可能成本降低，却没有释放工时。保留真实费率，另行分析人员或成本变化，不要修改记录来通过检查。不同币种不相加。需要汇总时，先建立有依据的统一币种口径；脚本不会自动换汇。未知的小时成本和模型费留空，JSON 中未知假设写 null；只有确认确实为零才填 0。订阅分摊与设置工时都只算一次，保留分摊依据。

换成自己团队的一次真实试点

复制 blank-runs.csv 和 blank-costs.json，选一项已有负责人、会重复发生的工作。先确定观察周期和质量清单，再收集记录。README 写明了每列含义。同一个周期里的失败、难任务和慢任务，都要和顺利的任务一起保留。

只使用获准的必要记录。模型费从对应账单或使用导出中获得，本练习不会自动抓取。文件放在本地，不代表让助手读取时不会把内容发送给你所配置的模型服务商。

复盘时也要看实际产物。多次稳定达到质量要求、完整投入能接受，再考虑继续；复核和设置占比过大，就先优化；重要错误持续出现，就缩小范围或暂停。小规模观察可以帮助决定下一次试验，不能证明通用提效百分比或全年 ROI。

把它放在团队实践的第四步

先把一个复杂需求拆成职责与验收标准；如果是开发工作，再查清测试瓶颈；流程跑通后，把共享 Skill 整理成容易理解、可以验证的规则；最后，用已经产出的工作来评估价值。

这样，测量有实际流程作为依据。下一次复盘，带上任务记录、最终产物、费用依据，以及一个明确决定：扩大、改善，还是暂停。