Timefold：企业 AI 更有价值的一面，是把计划问题工程化

企业软件里最被低估的一类问题，是计划问题。不是把数据存进去，也不是把页面画出来，而是在有限资源、复杂约束和业务偏好之间做一个可执行方案。排班、路径、床位、教室、订单、机台，表面上都是不同系统，底层其实都是同一类难题：组合空间巨大，规则之间冲突，结果还必须能解释。

Timefold Solver 的意义就在这里。它不是“AI 自动排班”的营销词，而是把计划优化变成一种工程结构：领域模型、规划变量、硬/中/软约束、增量评分、求解生命周期和结果解释。

为什么这类问题不能交给普通规则代码

很多团队会先写一个贪心算法：先排优先级最高的，再塞剩下的，冲突了就修。开始很快，后面很痛苦。每增加一个例外，算法就多一条补丁；每调一次优先级，就可能破坏另一个部门的规则。最后系统没有“约束模型”，只有一堆历史事故留下的 if-else。

Timefold 的价值是反过来：先定义可行性，再定义偏好，再让 solver 搜索。它不会让业务规则变简单，但会让规则变得可见、可测试、可讨论。

一个好的 Timefold 项目，首先是业务建模项目

• 哪些数据是不变事实？例如员工、车辆、房间、时间窗。
• 哪些对象需要安排？例如班次、课程、访问点、订单。
• 哪些字段是规划变量？例如员工分配、时间段、车辆、路线位置。
• 哪些约束绝不能破？例如容量、资质、时间冲突、法律限制。
• 哪些只是偏好？例如少走路、少换教室、均衡工作量、满足个人偏好。

这一步做不好，后面调算法没有意义。Timefold 最适合的团队，不是算法最强的团队，而是愿意把业务规则拆清楚、写成测试、让领域专家参与验收的团队。

架构建议：把优化服务隔离出来

官方文档推荐的一种方式是 run as a service：优化服务只负责接收数据、求解、返回结果，不拥有数据库，不管理用户状态。这一点很重要。优化任务天然更像批处理或异步任务，而不是普通 HTTP CRUD。

把优化器隔离出来，能让主业务系统继续负责数据、权限和流程；solver 负责计算。以后要扩容、限流、取消任务、比较不同规则版本，也会清楚得多。嵌入式当然也可行，尤其是已有 Spring Boot / Quarkus 系统，但要更重视线程、超时、资源占用和求解生命周期。

Timefold 和 LLM 的分工

大模型可以辅助理解需求，却不应该直接决定最终排班。排班和路径优化是可审计决策：谁被安排夜班、哪条路线被放弃、哪个订单没服务，都需要理由。LLM 的输出不稳定，Timefold 的约束和 score 才能进入工程验收。

更好的模式是：LLM 把自然语言需求整理成候选约束，人类确认业务含义，工程师写成 Constraint Streams 和测试，Timefold 负责求解。这样 AI 是需求和交互层，不是黑箱决策层。

结论

Timefold 深刻的地方在于，它提醒我们：企业 AI 不一定是聊天框，很多时候是把核心决策流程变成可建模、可解释、可优化的系统。真正有意义的自动化，不是替人生成一个答案，而是让组织能持续改进“什么是好方案”的定义。