AI 时代，两个值得对比的工作场景

先说结论

• 排程系统 APSer-Aps 从开发、上线到使用，有两件事反复出现：核实数据和排产逻辑，准备客户演示。过去这两件事多靠表格、SQL 脚本和人工，费时，过程也很少留下记录。
• 现在由 AI 编程助手按我们定下的标准写核查脚本、对照数据，在副本上按脚本彩排演示，并把每一步的数据和截图记下来；APSer-Atelier 作为主控登记每一件事、派出执行、留下核查记录。
• 一次核查发现的问题类型，会固化为以后每次都跑的检查：排产结果核查现有 89 条规则，全部由程序判定，每一批改动都要跑。
• 人的时间换了地方：事先定标准和口径，事后看报告、按 PPT 验收、做决定。AI 的判断也要核实：两个 AI 分头查、互不参看，高风险的问题再单独复现。

我们的排程系统 APSer-Aps 从开发、上线到使用，有两件事会反复出现。

一件是核实：数据对不对，排出来的计划合不合规则。开发时要核，导入客户资料时要核，上线后每改一处还要核。

另一件是演示：给客户看系统，要事先准备数据、走一遍流程、做好讲解材料。演示里的操作会真实改动数据，演示前后都要能回到一个确定的状态。

这两件事都不直接产出功能，却很耗人：过去多是一个人对着表格和脚本熬出来的，做完留在脑子里的比留在纸面上的多。最近几个月，我们把这两件事交给 AI 编程助手去做，人负责定标准、看结果、做决定。AI 编程助手是执行器；组织它们的，是我们自研的工作平台 APSer-Atelier，它作为主控登记每一件事、派出执行、记下每一条要求、留下核查记录，见《APSer-Atelier 的场景锚定与价值定位，以及实践总结》。下面把新旧两种做法放在一起对比。

这里说的 APSer-Atelier 主控包括两部分：面对我们的主控会话（一段 Claude Code 或 Codex 对话），负责组织和派出；Atelier 平台，负责登记每一件事、挂起待拍板、记下要求、按规矩放行并留下记录。

场景一：核实数据和排产逻辑，过去和现在怎么做？

过去的做法

把数据从系统里导出来，放进表格，一列一列比；复杂一点的，就写 SQL 查询，把几张表关联起来对照。排产逻辑的核实更难：要从成百上千道工序里找出「先后顺序不对」「用了不该用的设备」这样的个别情况，往往要一边查、一边在脑子里推演规则。

这样做有三个问题。一是费时，一次完整的核实要占去大段时间。二是烧脑，查询要人写、结果要人看，漏看一处就可能放过一个问题。三是难以复现：查询散在各处，结论写在聊天记录或记事本里，下一次再核，多半要从头来一遍。

现在的做法

现在，我们先把「按什么标准核」讲清楚：客户提供的原始资料、已经定下的业务规则、系统的设计方案。然后由 AI 编程助手自己写核查脚本、自己查数据、自己对照，把发现的问题连同证据写成一份核查报告：查了什么、怎么查的、数据是多少、哪里不符、建议怎么改。涉及页面的，还会在浏览器里打开页面，把操作前后的截图一并存下。

下面是最近几次真实的核查。

一套演示数据的全面核查。 这套演示数据一部分来自客户提供的物料清单，其余为模拟生成。核查由两个 AI 分头进行、互不参看，各自只读核查后再合并；高风险的问题，再单独复现一遍确认。数量、引用关系、班组值守等大部分项目核对通过，同时列出 18 条问题，其中高风险 3 条、中等 7 条、低风险 8 条。修复后复核：在途采购单挂错物料的 16 处、承诺交期早于下单日期的 31 行、生产履历与当前预计发货不一致的 174 行，都降到了 0。

其中一条最能说明问题。表面上看是「系统在后台找到了更好的方案，却没有替换」，顺着查下去，根源在排程逻辑：把父件第一道工序的换型往前挪时，只看了同一张工单上的前一道工序，没有看子件什么时候做完，于是可能出现子件还没做完、父件已经开工的计划。系统的复核环节把这样的计划拦下了，这才表现为「不替换」。修正后，同样的求解连续跑了 20 次，没有再出现先后违规。

客户物料清单的导入检查。 客户从 ERP 导出了几份多层物料清单。导入之前，检查工具只读解析这些文件，按十几类规则逐项检查，输出异常清单，发现了单位口径不一致、疑似重复计算、物料编码规则与层级不符等情况，交给客户确认，不在导入时自行改动。

交付前的全站核查。 用浏览器把系统的 28 个页面在浅色、深色两种主题下逐一打开，把页面上显示的数字和系统接口返回的数字逐项对照；关键操作在副本环境里真实点一遍。同一次核查里，还查到大模型写的月度解读被系统的核验环节连续拦下 5 次：模型自己做了减法，得出的数字在报告里找不到，其中一个还算错了 0.01。这类说法不会展示给用户，页面上改用规则生成的文案，并注明原因。

一次核查发现的问题类型，会固化为以后每次都跑的检查。现在这套系统的排产结果核查有 89 条规则，全部由程序判定，不调用大模型，每一批改动都要跑。

对比

场景二：准备客户演示，过去和现在怎么做？

过去的做法

演示前，先备份数据库；演示中，确认计划、下发工单这些操作会真实改动数据；演示后，再从备份恢复。备份、恢复、记录下每一步，几乎全靠脚本加人工。彩排是人自己点一遍，截图靠手工，讲解材料再单独整理。完整点一遍很花时间，发现问题改完，往往没有精力再从头点一遍。

现在的做法

备份和恢复由 AI 执行，并且逐表校验。 备份时连同代码、配置一起保存，每张表记下行数和内容指纹。恢复之后逐表对照，最近一次恢复演练中，32 张表、20 万余行数据的行数与内容指纹全部一致。我们还故意改掉一行、删掉一行，确认对照能报出差异，以此证明这道校验本身是有效的。

彩排在副本上进行。 从当前的运行环境复制一份数据，在副本上走演示流程，走完就丢弃，正在运行的环境不受影响。每一遍都从同一个起点开始，这样人验收时看到的，和 AI 彩排时看到的是同一个状态。

AI 按演示脚本操作系统，并全程记录。 最近一次演示的脚本分 16 段，约 60 分钟。AI 在浏览器里按脚本逐段操作，记录每一步的等待时间和屏幕上的数字，并截图。第一遍按段探索，摸清操作路径和先后顺序；第二遍从头连续走完。这一版脚本配了 113 张截图。

彩排能发现单看代码发现不了的问题。一次补充彩排里修了 5 处缺陷：在别的页面刚建好的评审单，跳到评审中心却定位不到；全部确认后的提示落进了另一个分支，文字写错了；选中一张单后，列表被详情挤得只剩半行；同一个页面上同时出现「无需新开生产订单」和「试算新开补单 6 张」两种说法；一个部件缺件，却被当成整台成品去补产。也有两条路径起初没走通，查下来是操作顺序的问题，代码没有错，这个结论同样写进了演示脚本，提醒演示时按正确的顺序操作。

人按脚本走查。 AI 彩排之后，负责人再按脚本亲自走一遍，遇到问题随手发来，由 AI 逐条登记、定位。开始走查后没多久就登记了 4 条，其中一条是 AI 准备环境时自己发现的：演示环境里一直在模拟派工、报工、收货，屏幕上的数字与脚本里记录的数字对不上，于是规定演示时只讲屏幕上的数；一个内部用语出现在了客户能看到的页面上，而文案检查的词表没有收这个词；彩排工具少带了一项配置，下拉框里会露出别的演示账套；还有一处操作体验要改。

输出 PPT，按 PPT 验收。 现在的流程是：AI 在副本上按脚本走一遍，截图，自己先审一遍问题，整理成 PPT；负责人按 PPT 验收、提问题；AI 给出整体修复计划，批准后修复；再从同一个起点走一遍，再出一份 PPT 确认。写这篇文章时，这一轮准备正在进行。

对比

两个场景有什么共同点？

放在一起看，变化不只在于快。

过程留了下来。 过去的核实和彩排，做完只剩一个结论；现在每一步的数据、截图、判断依据都在，出了分歧可以回头查，下一次可以照着再做一遍。

人的时间换了地方。 写查询、点页面、截图这些事交给了 AI，人的时间用在两处：事先把标准和口径讲清楚，事后看报告、做决定。

机器的判断也要核实。 AI 写出的核查报告不等于问题成立。我们的做法是让两个 AI 分头查、互不参看，高风险的问题再单独复现；大模型写的解读，数字要能在原始数据里找到，找不到就不采用。

还有哪些地方要注意？

• 截图多不等于看过。 113 张截图，人不看就没有意义。按 PPT 验收，就是为了让人真正把每一步看一遍。
• 演示数据的来源要讲清楚。 哪些是客户提供的真实资料、哪些是模拟数据，系统页面上要标明，演示开场也要先说。
• 只在副本上操作。 AI 彩排和核查一律用副本或只读方式，不直接改正在运行的环境。
• 客户资料留在客户资料的地方。 客户提供的原件和含客户数据的报告，只放在专门的目录里，不进代码仓库，也不外发。

以下是我们的看法

AI 让「证明」变便宜了。 核实数据、彩排演示，本质上都是在证明系统是对的。过去这类工作成本高，常常只做到「大致看过」；现在可以做到逐项对照、全程留痕，而且可以重做。

标准仍然要人来定。 按什么核、演示讲什么、哪些问题必须改、哪些可以带着说明上场，这些决定需要了解业务的人来做。AI 做得越多，这些决定越重要。

记录本身就是交付的一部分。 一份写明了方法、数据和截图的核查报告，一份从真实操作整理出来的演示材料，客户看得懂，接手的人也用得上。

本栏目的《AI 写代码快了，交付怎么才靠得住：我们踩过的坑和现在的做法》《每一次升级都要能证明：排程系统的发布前检查与发布后验证》写过开发和发布环节的做法，本文补上核实与演示这两个日常场景。