为什么多数APS计划'好看却难执行'？------无限产能假设的工程代价
多数APS在算法层面默认一个未经验证的前提：设备永不故障、人员永不请假、班次永无差异。这实质是将工厂建模为'无限产能'的理想系统。该简化虽利于数学求解，却割裂了计划与现场执行的物理一致性。
当生产日历、人员技能、设备状态等约束被设计为'可选配置'而非强制校验项，就会导致三套逻辑并行：销售凭经验承诺交期、PMC在Excel中手动腾挪、车间按缺人缺模现状开工。结果就是'甘特图很美，一插单就崩，一执行全是例外'。
根本问题在于：传统APS常把真实约束当作锦上添花的功能开关，而非雪中送炭的计算基线。例如，未启用日历模块时，系统仍会把设备维保日排满任务；未绑定工序技能要求，高负荷产线可能分派给无资质人员------计划'能生成'，但无法执行。
刚性约束不是功能点，而是排产引擎的启动前提
JVS-APS的7类刚性约束，不是UI上的勾选项，而是排产引擎启动前必须通过的'物理安检门'。它重新定义'有限产能'：不是算得快，而是所有调度运算必须先完成对真实工厂边界的穿透式校验。
- 设备停机窗口未排除？不生成任何计划；
- 工序所需工种资质未匹配？该人员不进入资源池；
- 模具数量不足或换型时间未计入？该工序排程直接中止。
这些字段（如maintenanceStartTime、skillCode、availableWorkingHours）并非静态元数据，而是作为扩展维度直接参与调度算法的输入变量。系统不提供'跳过约束检查'的快捷键，也不依赖人工事后修正；相反，生产日历、人员技能、设备状态等全部设为建模必填项------缺失即阻断，异常即告警。
定位：不是ERP插件，也不是MES外挂，而是计划中枢
JVS-APS在IT架构中承担计划中枢角色：一头承接ERP的订单、BOM与工艺路线，一头驱动MES的任务下发、报工反馈与实绩采集。
它的核心目标不是渲染一张视觉友好的甘特图，而是确保计划从诞生起就具备三重确定性：
- 车间能执行（人员/设备/模具就绪）；
- 采购能跟上（物料齐套与交付节奏联动）；
- 管理层能看懂（风险前置暴露、瓶颈路径可追溯）。
7类刚性约束的工程落地机制
这7类约束不是抽象概念，而是可配置、可联动、可追溯的具体技术实现：
生产日历：多层级时间基座，不止于节假日表
支持全局、产线、设备三级独立日历，自动识别并排除法定假日、临时停产、设备维保窗口。不同产线可配置差异化三班倒规则，午休分段亦纳入工时计算，使排产结果天然贴合企业实际作息。
工种技能绑定：'谁来干'成为工序前置条件
每道工序可绑定多项技能标签（如CNC_Programming_L3、Laser_Cutting_Certified），系统实时比对HR/培训系统同步的人员资质库。无对应资质者不在可选资源池内，从源头杜绝'人到了、活干不了'的执行断点。
人员事件规避：动态工时折算，实时响应人力波动
HR系统同步的请假数据、车间提报的调班/培训申请，均通过API实时注入排产引擎。系统按实际在岗人数动态折算有效工时，并支持夜班产能按系数衰减（如0.8），避免计划虚高。
主资源状态联动：设备状态变更即触发重排
设备状态变更为maintenance、decommissioned或locked时，其负载自动置为0，并立即触发关联工序的资源重分配与局部重排。管理层可在负荷热力图中直观识别瓶颈转移路径。
对IT负责人和选型小组的三个可验证判断标准
判断一套APS是否'真可落地'，关键不在参数列表长度，而在以下三项可工程化验证的动作：
- 能否自动排除非工作时段？ ------ 不需人工干预日历配置，系统基于真实班次与维保计划，自动跳过无效时间；
- 异常约束是否需手动绕过？ ------ 当模具冲突或人员缺勤发生时，系统应主动告警并提供替代方案（如推荐备用设备、可调配人员），而非静默生成不可行计划；
- 是否支持约束穿透式追溯？ ------ 点击任一排产任务，可下钻查看其排产依据：具体是哪条日历规则、哪个技能标签、哪台设备状态共同决定了该开工时间。
架构与实践：轻量化起步 + 主辅资源联合建模
JVS-APS采用轻量化微服务架构与本土化适配策略，支持从单条急单产线起步验证，降低初期试错成本。
更重要的是，它坚持主辅资源一起排：模具数量、夹具安装耗时、换型时间（SMED）、人员资质等，全部作为刚性输入变量参与排产计算，而非留待执行阶段靠人工协调的'灰色地带'。这种设计让排产结果天然具备物理可行性。
一线PMC的真实诉求是：'我们不是缺一张表，而是缺一个能把订单、产能、物料、日历和报工真正串起来的闭环。'
老板最痛的点更直白：'风险总在开会时才暴露，交付总在发货前才卡住。'
这背后，是计划与执行之间那道未被填平的物理鸿沟------而JVS-APS的设计哲学，正是用工程化的刚性约束去弥合它。