AI 给出排程建议以后，谁来确认和下达

先分清候选建议和正式计划

一次计算可以给出多套排序、资源选择和预计完工日期。它们先是候选方案，供团队比较交期风险、资源冲突、物料依赖和计划移动。系统生成了结果，不代表工厂已经采用，也不代表工单已经进入车间执行。

SAP 的 PP/DS 文档允许把模拟结果另存而不改变当前 planning version，Siemens 也把 what-if simulation 和 impact analysis 列为计划工具。这些是各自产品里的控制方式，可以说明候选与当前计划能够分开保存，却没有定义一套所有 APS 都共用的审批状态。

凯沃普当前生成可比较的排程方案，由计划员调整和确认。首轮可读取企业提供的 ERP 导出、Excel、SQL 数据、现有排产表和现场规则。第一轮保持只读，候选留在生产系统外供复核，不自动写回 ERP 或 MES，也不会自行成为客户承诺或生产下达。

把这一版为什么这样排交给计划员

复核先固定数据截止时间、时区、订单范围、当前排程、候选版本和规则版本。订单、工艺、资源日历、物料与现场进度来自不同时间时，计划员很难判断差异来自排程方法，还是来自一份已经过期的输入。

逐单视图至少要列出需求节点和候选完工日期。涉及的工序、资源、关键物料、被移动任务、未满足约束和范围外限制，也要同订单关联。Oracle 的排程分析产品可以展示晚单、资源、pegging 和人工调整，具体字段仍要以客户系统与本轮数据范围为准。

解释帮助计划员追查依据，却不能单独证明结果正确。NIST 的自愿 AI 风险管理框架建议记录输出怎样被人使用、知识边界和人工监督方式。团队仍要拿候选同真实订单、主数据和现场规则对账。

人工调整以后，还要重新检查关联影响

计划员可以接受、拒绝、补资料，也可以调整优先级、日期、资源或现场规则。每次改动都要留下旧值、新值、修改人、时间和理由，让下一位复核者知道这一版为什么发生变化。

在 Oracle Production Scheduling 中，用户可以在甘特图上移动工序、选择替代资源并运行 Repair。新的 Solve 会重新计算，并可能丢弃已有的人工工序调整。该行为提醒团队，拖动一条工序并保存，只能证明界面记录了这次操作，不能证明整张计划的上下游关系仍然可行。

Microsoft 的计划订单文档也把人工修改、可选的 Approved 状态和下一次主计划运行分开。不同产品的重新计算方式并不相同，公开流程仍应要求改动后复核相关工序、资源、物料和受影响订单。

异常要交给有权作决定的人

急单、固定区内的移动、加班、替代资源、拆批、外协和关键物料替代，都会把影响带到计划范围以外。计划员可以整理受影响订单和候选处理方式，是否接受成本、质量、客户或现场风险，应由企业指定的人决定。

一项例外至少要写清触发原因、影响订单、原计划、候选变化、未解决风险、需要谁确认和最晚决定时间。销售对外确认的日期、现场允许突破的保护范围，以及系统可以写入的对象，可能分别属于不同负责人。

NIST AI RMF 建议区分人机配置、监督角色、人工覆盖和问题升级责任。它是一套自愿风险管理参考，没有规定制造企业必须由 PMC、销售、厂长或任何固定职位完成逐单审批。

四类决定不要塞进一个确认按钮

选定候选排程、批准现场例外、对外承诺客户日期、发布到执行系统，回答的是四个不同问题。企业可以按自己的组织方式分配权限，但记录里要能看出是谁、在什么范围内、依据哪一版资料作了决定。

Microsoft 的 Approved 是 planned order 在 firming 前可选的人工状态，含义是这张计划订单可以进入 firming。它仍是 planned order，没有因此生成实际采购、调拨或生产订单，也不能拿来代表其他厂商的待审状态。

Microsoft 同时支持人工、自动和按查询条件 firming。自动 firming 要显式配置时界，按查询批量处理可以先 Preview。由此能看到计算、人工状态和订单转换可以分别控制，却不能推出每家企业都必须采用同一种审批方式。

选择排程版本

本项至少需要基线与候选差异、交期风险、硬约束和未解决异常。责任记录应写明企业授权选择版本的人、采用版本、决定时间以及接受或拒绝的理由。系统不得因为某个候选得分最高，就自动把它设为正式计划。

批准现场例外

本项至少需要固定区任务，以及加班、换线、替代资源、拆批和外协对订单与现场的影响。责任记录应写明企业授权批准例外的人、适用范围、条件、决定时间和理由。没有企业明确批准的例外，系统不得自动移动固定区任务或改变已经开工的任务。

对外确认交期

本项至少需要发货或到货节点、数量、拟确认日期、受影响客户和残余风险。责任记录应写明企业授权确认客户承诺的人、获批版本、决定时间和可对外使用的范围。系统不得把模型日期直接写成客户承诺。

发布到执行系统

本项至少需要目标系统、订单范围、写入字段、操作权限、回滚办法和通知对象。责任记录应写明企业指定的发布操作者与批准人、运行 ID、执行时间和结果。系统不得在范围不明时批量写回 ERP 或 MES。

保留版本，也保留每次决定的依据

一次完整记录要连接输入快照、当前排程、候选版本、逐单差异、人工改动、例外授权和最终处理结果。旧版本不能被新结果覆盖，发布失败、跳过、冲突和回滚也要留在同一个批次记录里。

NIST AI RMF Playbook 把历史记录、审计日志、人工覆盖、错误、例外升级和 go 或 no-go 决定列为建议动作。具体字段、保存期限和访问权限仍由企业按风险、系统和法规环境确定，不能把建议清单写成统一的制造合规要求。

日志只能说明谁在何时做过什么。它不能证明输入完整、约束正确、候选可执行，也不能替代计划员和现场对实际订单的检查。需要对外发布的案例或效果数字，还要有独立基线、统计口径与客户许可。

下达以前先写清对象、字段和后果

团队第一次使用下达这个词时，就要说明它指文件导出、人工交接、计划版本采用、实际订单创建、状态变化，还是 ERP 或 MES 字段写回。发布前预览选中的订单、目标系统、写入字段、权限和回滚方式，才能知道一次点击会改变什么。

各家产品的动作并不等义。Microsoft firming 会把 planned order 转成实际采购、调拨或生产订单。SAP adopt 把 simulation version 的变更合并进 planning version，并不等于发布到车间。Oracle Production Scheduling Release 可以更新文档列出的工单与工序日期、资源分配和按配置决定的状态，部分排程覆盖不会写回。

Kavop 当前支持导出，受控发布仍只覆盖部分范围，不替换 ERP 或 MES。公开资料还不足以说明具体接口、审批流、电子签名、写回字段和失败处理，因此第一轮保持只读，由计划员或企业授权人确认结果，再决定后续采用哪种交接或发布方式。

现场反馈进入下一轮复核

正式计划进入执行以后，实际开完工、数量、工时、物料消耗、停机、短缺和质量异常会改变原来的判断。Microsoft 的 production feedback 文档展示了时间、物料、数量、状态和错误等记录对象。这些事实需要带着时间和来源回到下一轮计划。

Oracle 的 Refresh 会从 Manufacturing 更新工单、属性、能力和可用性数据，并丢弃当前 scheduling solution。刷新、求解和人工复核仍是不同动作。团队要先确认新数据覆盖了什么，再决定保持当前计划、局部修补或重新生成候选。

反馈数据能帮助团队修正后续输入，却不能证明系统会自动训练、自动改规则或持续变好。Kavop 的当前边界仍是用现有资料生成候选、解释风险并交给计划员确认。现场数据怎样接入、多久刷新和谁能启动重排，需要在具体项目里另行确认。