让AI写预约逻辑，再像资深开发者一样审查它

当AI接手预约系统最棘手的那段代码

预约系统里最难写的不是界面，而是那段决定“这个时段到底能不能订”的逻辑。它要处理30分钟粒度的时间步进、时间段重叠判断、过去时间过滤，还要跨时区正确换算。在这个系列的第16集里，作者已经手写实现了时段选择器，现在把同一件事交给AI重做一遍，然后用资深开发者的方式逐项验收。

这个流程本身就值得关注：AI写代码的价值不在于一次写对，而在于你能多快、多系统地发现它错在哪。

提示词决定了代码的下限

作者的提示词明确列出了几个关键输入：30分钟的时间步长、重叠判断、过去时间过滤，以及指定时区库。原文对此有一句很直白的警告：提示词含糊，就会得到凌晨3点的预约。

这是预约类功能最典型的失败模式。时间段边界、时区归属、过去时间这些约束，如果不写进提示词，模型就会按最“顺”的默认逻辑生成代码，而这些默认值在真实场景里几乎总是错的。把约束显式化，等于提前把测试用例翻译成了需求描述。

三项审查：像资深开发者一样验收

代码生成之后，作者没有直接运行看效果，而是做了三项针对性检查。

检查一：时区归属对不对

产出的函数在构造时间时，用的是这场预约所属的时区，而不是服务器时区。这个区分很关键：服务器通常跑在UTC，如果直接 new Date(9am)，整个夏令时期间都会偏差一小时。这类bug在本地开发时往往看不出来，上线后在特定季节才集中爆发。

夏令时（DST） 是许多地区在夏季将时钟拨快一小时的做法，目的是更充分利用日照。对预约系统而言，这意味着同一个本地时间（如上午9点）在一年中可能对应两个不同的UTC时刻。如果代码用服务器默认的UTC时区去构造本地时间，那么在整个夏令时期间，所有预约都会偏移一小时。更隐蔽的是，这类偏差只在特定季节出现，本地开发时若恰逢非夏令时月份就完全无法复现，直到上线后进入夏令时才集中爆发。因此，使用显式指定时区的日期库（如Luxon、date-fns-tz）并始终以预约所属时区构造时间，是避免此类季节性bug的关键。

检查二：重叠判断的边界符号

重叠测试的逻辑是：新预约的开始时间早于已有预约的结束时间，且结束时间晚于已有预约的开始时间。两个不等式里只要有一个符号方向写反，首尾相接的紧凑预约就会被误判为冲突。这种错误不会让功能完全失效，而是以“偶尔订不上”的形式出现，排查成本很高。

重叠判断通常采用区间相交的经典公式：两个半开区间 [start1, end1) 和 [start2, end2) 重叠，当且仅当 start1 < end2 且 start2 < end1。注意这里用的是严格小于号（<）而非小于等于（<=）。如果误写成 <=，那么当新预约的开始时间恰好等于已有预约的结束时间（即首尾相接）时，就会被误判为冲突，导致本可预订的紧凑时段被拒绝。反之，如果误写成 > 或方向颠倒，则可能让真正冲突的预约通过。这种边界符号错误不会让功能完全崩溃，而是表现为“偶尔订不上”或“偶尔重复订”，排查时往往需要构造精确的边界用例才能复现，因此审查时必须逐字符确认不等号方向。

检查三：数据库约束兜底

即使这个函数存在bug，数据库层的约束仍然会拒绝重复预约。作者由此给出的原则是：永远不要让一段代码成为你唯一的防线。应用层校验负责体验和清晰报错，数据库约束负责最终正确性，两层各司其职。这是纵深防御在业务逻辑里的具体落地。

纵深防御（Defense in Depth） 是安全与可靠性工程中的核心原则：不依赖单一防护层，而是让多个独立层各自提供保护，即使某一层失效，其他层仍能阻止错误。在预约系统中，应用层校验负责用户体验——快速给出清晰错误提示、避免无效请求打到数据库；数据库约束（如唯一索引、排他约束）负责最终正确性——即使应用层代码有bug、被绕过或出现并发竞态，数据库仍会拒绝重复或冲突的预约。两层职责不同，缺一不可。只靠应用层校验，一次并发请求就可能写入重复数据；只靠数据库约束，用户会收到晦涩的底层错误而非友好提示。

对AI编程的一点判断

这个案例展示了一种务实的协作姿态：让AI承担样板密集的逻辑实现，把人的精力集中到验证上。审查的三个点——时区、边界符号、兜底约束——都不是靠“感觉”能发现的，而是靠明确知道这类代码会在哪里出错。换句话说，AI降低了写代码的成本，但没有降低判断正确性的成本，后者反而成了开发者更核心的竞争力。

作者在结尾提到，产品主体已经完成，下一步是接入Stripe订阅开始收费。对于跟着这个系列搭建SaaS的人来说，从功能完成到商业闭环，收款环节是下一道坎。

常见问题

为什么预约时间不能用服务器时区？

服务器普遍运行在UTC，直接用服务器时间构造本地时刻，在夏令时期间会产生一小时偏差，且只在特定季节暴露。

应用层已经校验了，数据库约束还有必要吗？

有必要。应用层逻辑可能被改动、被绕过或出现并发竞态，数据库约束是最后一道不依赖业务代码的正确性保证。

让AI写这类逻辑，最容易漏掉什么？

边界条件。重叠判断的等号归属、首尾相接的时段、过去时间的判定基准，这些是提示词里必须显式写明的部分。