AI 做得越来越多，企业服务里人如何判断：品位与决策

一家工厂提出「加一张缺料预警表」，要解决的可能是库存不准，也可能是到料时间没更新，或工单下发前没有核对齐套。表做出来了，现场仍可能继续救火。

我们用 AI 协同开发的体会是：写代码、出原型可以更快，但一套系统有没有用，还要看是否找到了真实问题、业务取舍是否合适、上线效果有没有核实。人的品位和决策能力，就落在这些具体工作里。人也会误判，判断必须能说明依据、接受检查，并随结果修正。

一、客户提出一个功能，怎样找到背后的真实问题？

客户提出的功能需求值得认真听。它表达了现场的困难，也包含一种解决办法；这个办法是否合适，还需要验证。比如「加预警表」可以先记下来，接着请客户拿出最近一次缺料事件，沿着实际过程追问：

先把问题写成可检查的一句话：在哪一步，因为什么尚未确认或已经有证据的原因，造成了什么影响。再决定先改哪一段。频率高、损失大、原因和责任较清楚的问题，通常更值得先处理；涉及安全、质量或合同责任的低频事件，也不能只按次数排序。

用一个假设场景，走完从需求到验证的过程

以下是假设场景，只用于说明方法，不代表客户案例或已取得的效果。

最初需求： 计划员希望系统每天发一张缺料预警表，减少开工后的临时改排。

现场核实： 先选取双方约定时段的缺料事件，对照工单下发时间、采购到料时间的修改记录和实际开工时间，再请计划、采购、仓库说明各自做了什么。既要看缺料的订单，也要看正常开工的订单，检查两者有什么差别。

原因判断： 如果记录显示库存数量能够对上，但采购已经修改到料日期，计划员下发工单时仍用了旧日期，那么可以把「下发前未取得最新到料信息」作为待验证的原因。若记录反而显示账实不符，就要先处理库存数据；不能为了做预警表，硬把所有异常归到同一个原因。

方案取舍： 针对前一种情况，可以比较每日汇总表、到料变化提醒、下发前齐套核对。汇总表便于集中查看，但两次查看之间仍可能漏掉变化；提醒更及时，但过多会增加处理负担；下发前核对接近出错的那一步，但要有可信的数据和清楚的例外处理。先选择哪一种，要看现场是否有人维护到料信息、处理提醒，以及谁有权决定例外下发。

效果验证： 改动前先约定观察时段、缺料事件的定义和验收标准。改动后检查异常是否在下发前被发现、提醒是否被处理、开工后的缺料改排是否减少，同时记录误报、额外操作和数据维护的负担。订单规模、品种或供料情况变了，也要写清，不能把前后差异全部算成系统的功劳。如果异常仍在发生，就回到原因判断，而不只继续加功能。

这套过程可以很朴素：几张真实单据，一份异常记录，相关岗位一起核对。AI 可以协助整理事件、找出记录中的矛盾、提出其他原因，但每条结论都应能追溯到现场证据。

二、正确性和品位，分别要回答什么？

数据、计算和业务流程正确，是基本交付要求。 同样叫「交期」，可能指出货日，也可能指到达客户仓库的日期；合格率的分子、分母和返工如何计入，也要先写清。定义确认后，应拿真实单据和包含异常的样本独立核对结果，检查权限与流程是否按约定生效。这些要求不能靠「我觉得这样好」来放宽。

品位体现在多个符合要求的方案之间。 都能正确完成业务时，哪一种更适合这家工厂？操作员要多录几次，计划员每天要处理多少提醒，维护人员能否接手，工艺变化后需要改哪里？这些问题有取舍，需要说明为什么这样选。

比如缺料信息可以用列表、看板或提醒呈现。哪种好，要看使用者是在办公室集中核对，还是在车间短暂查看；是否容易看见关键异常；是否需要反复跳转才能完成处理。我们在《我们的界面设计理念：风格克制，操作顺手》里讲过界面克制的考虑。这里的克制也要经实际操作检验，不能仅凭设计者喜欢。

品位因此不是个人感觉或资历的代名词。方案应写明适用条件、代价和放弃的选项，请实际使用者走一遍，再用上线后的操作负担与维护情况复核。现场经验帮助提出判断，证据帮助发现判断错在哪里。

三、哪些事需要人拍板，哪些可以自动执行？

业务目标、风险边界、授权和重大利益取舍，需要有责任、有权限的人决定。例如急单是否挤占其他订单的产能，是否改变对客户的交期承诺，是否接受某种质量风险。这些事项的后果涉及不同岗位和外部对象，服务商应把选项、依据、不确定性和代价讲清，让有权负责的人选择。

日常事项可以按已授权、已验证的规则自动执行。例如按确认的口径汇总报表，依据约定条件发送提醒，或执行经过验证的常规处理。规则应说明适用范围、例外和停止条件，留下执行记录；超出授权或发现数据异常时，再交给相应的人处理。把规则定清，不必让每一步都等待批准。

AI 也可以帮助人判断：整理问题、比较方案、核对来源、找遗漏和提出反例。人的经验同样可能过时，AI 的建议则可能遗漏条件或引用错误，双方的判断都需要核验。

对于影响测算，要区分计算、估计和未知。数据完整、约束已经核实、计算方法通过验证时，系统可以计算方案在这些条件下的交期或资源占用；供料时间、故障或操作行为仍不确定时，应列出假设，比较假设改变后的结果。大模型生成的解释还要与实际计算结果对照。不能把一段流畅的说明称为「已经算清后果」。

我们在《急单插进来之后：为什么给几套方案，由人来拍板》和《排程为什么交给确定性求解内核，大模型只在外围工作》中，分别讨论了业务取舍与排程计算的分工。计算结果可供决策参考，仍以录入的数据和建模约束为条件。

《权力与预测》的作者阿格拉沃尔、甘斯和戈德法布，将预测和判断作为理解决策的两个关键要素 [1]。本文借用这个区分：对可能发生什么的估计，与对结果的价值和代价作出取舍，需要分别说明。把它应用到制造业软件交付，是我们的理解；它不等于「所有开发都是预测」，也不能推出人的每一项判断都更可靠，或 AI 不能协助判断。

四、怎样让判断留下可核对的交付结果？

从问题到上线，我们看重的是一条能回头检查的过程：异常依据在哪里，为什么选这个方案，验收按什么口径，实际结果是否符合要求。原型能演示，只能证明部分功能做了出来；数据核对、真实岗位操作和业务效果观察，各有自己的验收任务。

我们使用自研工作平台 APSer-Atelier 作为主控，组织 AI 编程工具执行、记录工作状态和验证结果，并登记需要人决定的事项。对客户有用的是：改动的来由和检查结果可以追溯，需要业务取舍时能看到选项与代价，问题出现后有依据继续处理。具体机制和覆盖边界见《APSer-Atelier 的技术架构与选型决策机制》。有记录仍要检查记录所指的产物和现场结果，不能只看一个完成标记。

上线后的恢复也要事先说明。代码版本可以退回，不代表业务数据随之恢复。如果新版本已经写入数据、改变数据结构，或向其他系统发送了指令，恢复要核对兼容性、备份及这些动作的后果。应在交付中约定恢复步骤和责任，并验证适用条件；不能承诺退回代码就一定让业务恢复正常。

自己的感觉也不能代替测量。METR 于 2025 年 7 月发表的随机对照研究，使用 2025 年 2 月至 6 月的数据：16 位有经验的开源开发者，在自己熟悉的成熟项目里完成 246 个任务。开工前预计使用 AI 能缩短时间 24%，事后估计缩短 20%，实测允许使用当时 AI 工具的任务耗时却增加了 19% [2]。这个结果限于该样本、任务和时期的工具，不能推广到所有 AI 开发。

2026 年 2 月 24 日，METR 更新了从 2025 年 8 月开始的后续实验：57 位开发者、143 个仓库、800 多个任务。更新明确指出，不愿脱离 AI 的开发者或任务较少进入实验，报酬变化影响参与选择，并行使用多个 AI 工具使任务耗时难以可靠计量。作者认为提速可能比早期更多，但数据对当前提速幅度的证据很弱 [3]。这里引用研究，是提醒我们区分感受与实测；一项交付是否有效，仍要用自己的任务、质量标准和业务结果验证。

五、选型时，怎样比较不同做法？

标准产品、低代码平台、AI 编程工具和服务商交付可以组合使用。前三者涉及实现手段，服务商交付涉及由谁组织和负责；服务商也可以采用标准产品或低代码，并使用 AI 协同开发。选型时可以分别问：

无论采用哪种组合，恢复能力都取决于具体部署、数据变化、备份和运维安排。应检查恢复步骤是否验证过、数据可能丢失到什么时点、谁执行恢复；采购方式本身不能回答这些问题。

六、您可以用哪些问题评价服务商？

听完方案或看完演示后，您可以请服务商围绕一个真实问题回答：

• 这个功能要解决哪次异常？ 谁遇到、谁补救，频率和损失有哪些记录？还有哪些原因没核实？
• 为什么先做这一段？ 比较过什么办法，暂不做什么，分别有什么代价？
• 怎样证明结果正确？ 数据和业务口径由谁确认，正常与异常样本怎么验，什么结果算通过？
• 现场多了多少负担？ 谁维护数据、谁处理提醒，实际使用者是否走过完整操作？
• 哪些需要我方决定？ 哪些可按授权规则自动执行，什么情况停止并上报？
• 上线后如何看效果、如何恢复？ 观察什么业务结果，发现无效怎样修正，代码和数据分别怎么处理？

服务商未必在第一次交流时就有全部答案，但应能说明下一步到哪里找证据、由谁确认。品位让方案更适合现场，决策让取舍有人负责，验证则帮助双方知道这次判断是否站得住。您可以据此评价服务商，也可以据此组织企业自己的软件工作。

参考来源