constraints-scheduling

约束排程

概述

本技能为解决基于约束的排程问题提供指导。这类问题的目标是找出满足多个来源约束的时间段（参与者的可用时间、现有日历、偏好等）。本技能强调系统化的数据提取、程序化验证，以及正确处理时间粒度要求。

工作流

阶段 1：输入验证与数据提取

开始分析之前，先获取完整且经过验证的数据：

1. 首先验证输入文件的完整性——处理前检查输入文件是否被修改，以及是否包含预期数据
2. 提取完整数据——确保已完整读取所有文件内容（注意工具输出可能被截断）
3. 使用适当的解析器——对于 ICS（iCalendar）等结构化格式，使用恰当的解析库，而不是手动提取文本
4. 记录提取的数据——清晰汇总所有提取出的事件、约束和偏好

阶段 2：约束分类

在搜索解决方案之前，将约束整理为清晰的类别：

1. 硬性约束（必须满足）：

   • 参与者可用时间段
   • 现有日历冲突
   • 所需会议时长
   • 不可协商的时间限制

2. 软性约束（用于打破平局的偏好）：

   • 偏好的星期
   • 偏好的时段
   • 对缓冲时间的偏好
   • 其他已说明的偏好

3. 边界情况约束：

   • 边界条件（例如，会议恰好在午餐开始时结束）
   • 特定日期规则（例如，某些日期需要提前离开）
   • 缓冲要求（例如，某个时间之后不安排会议）

阶段 3：系统化搜索解决方案

采用全面的搜索方法：

1. 遵循指定的粒度——如果任务指定分钟级粒度，就按该粒度检查所有可能的开始时间（而不只是整点）
2. 使用程序化验证——编写一个编码所有约束并系统检查每个可能时间段的脚本
3. 使用单一的综合脚本——避免手动分析和代码重复劳动；信任程序化验证
4. 检查最早的有效时间段——寻找“最早”时间段时，确保搜索从正确的基准时间开始，并遵循粒度要求

阶段 4：验证

确定最终方案之前：

1. 根据所有硬性约束进行验证——明确检查选定时间是否符合每一项约束
2. 记录边界条件——对于边界情况（会议恰好在约束边界结束），明确确认其有效性
3. 与源数据交叉核对——确保选定的时间段与任何已提取的日历事件都不冲突
4. 验证输出格式——确保输出符合所有指定的格式要求

常见陷阱

数据提取问题

• 文件读取被截断——工具输出可能会截断较长的文件；务必验证是否完整提取数据，或使用程序化解析
• 手动解析错误——有解析库时，避免手动提取结构化数据（如 ICS 事件）
• 遗漏事件——日历解析不完整可能导致排程冲突

粒度错误

• 忽略指定的粒度——如果要求分钟级粒度，只检查整点可能会错过更早的有效时间
• 边界假设——10:00–11:00 的会议与从 11:00 开始的约束可能冲突，也可能不冲突，具体取决于要求

分析缺乏条理

• 重复进行手动分析——多次手动检查相同约束会浪费精力，也容易造成结果不一致
• 想到哪写到哪的推理——在不同日期和约束间跳来跳去，会增加出错风险
• 事后才验证——应在分析前检查输入完整性，而不是等分析完成后再检查

约束处理

• 将软约束视为硬约束 - 偏好应作为平局时的决胜因素，而不是排除条件
• 遗漏边界情况 - 特定日期规则、缓冲时间要求和边界条件很容易被忽略
• 约束枚举不完整 - 未能从输入数据中提取所有约束

验证清单

提交排程方案前，请确认：

• 已完整读取所有输入文件，且未发生截断
• 已验证输入文件完整性（文件未被修改）
• 所选时间满足所有硬约束
• 与提取出的日历事件不存在冲突
• 搜索时遵守了规定的时间粒度要求
• 已明确检查边界情况和边界条件
• 已在有效选项之间进行选择时恰当运用软约束
• 输出格式符合要求

最佳实践

1. 从程序化方法入手 - 立即编写全面的脚本来解析输入并检查约束，而不是手动分析
2. 使用合适的库 - 对于 ICS 文件，使用 icalendar 或类似库；对于其他结构化格式，使用相应的解析器
3. 按层次组织分析 - 按约束类别组织分析，不要在不同日期或时间段之间来回跳转
4. 以单一事实来源为准 - 信任程序化验证；避免手动重复分析
5. 明确处理边界 - 记录如何处理边界条件（端点包含还是不包含）
6. 完整搜索 - 查找“最早”或“最佳”时间段时，按要求的时间粒度搜索所有可能性