AI 做商家预约网站，让顾客和店员看到同一条预约

用一家虚构的手作体验店作为教学样例：每次接待一组顾客，每场体验 45 分钟，场间整理 15 分钟，顾客先选场次再由店员确认。把现有纸质排班、临时休息和电话预约也纳入需求，否则网站上看起来空闲的时间，店员可能早已安排了客人。

首版的可交付结果是一条顾客可查询、店员可处理的预约记录。店铺介绍、地点和服务说明要准确，但它们不能替代订单状态。本页截至 2026-09-12 没有该网站的运行、部署或真实客户使用记录；表格与接口均为教学设计，供你在自己的开发环境逐项实施和验收。

“每天九点到六点营业”还不足以生成预约表。服务时长与整理时间决定资源占用区间，员工请假、门店休息和人工录入预约都会减少可用时间。建议先做明确列出的离散场次，不让第一版处理任意起止时间，这样店员也能直接核对当天日历。

例如 10:00 的体验在 10:45 结束，资源要到 11:00 才再次可用。所有确认记录应绑定场次编号，不能靠用户提交的显示文案决定时间。服务端保存明确的时间点与门店时区，前端负责按门店口径展示；跨日和设备时区变化都进入后续测试。

本例选择“提交申请后人工确认”：pending 表示申请已收到，但不承诺保留名额；confirmed 才表示资源已分配。页面和通知都要用同一口径，否则两位顾客可能拿着“提交成功”截图认为自己已经订到。店员确认时仍要在服务端检查冲突，不能只相信刚刚打开的日历。

普通 POST 请求本身不保证幂等，重复发送可能产生额外记录，参见 MDN POST 方法，核对日期 2026-09-12。下方是建议实现的应用契约：同一个 requestId 与相同资料返回同一申请；同编号不同资料返回明确冲突。它不是可直接调用的 KK 预约接口。

顾客创建并查看自己的申请，店员确认或拒绝，店主调整开放场次。先完成这三个角色的最小权限边界，再增加提醒、优惠和会员。若用查询链接，应使用不可预测的令牌并限制返回字段，不能把连续增长的预约编号当作查看凭证。日志也不应默认记录完整联系方式。

前端的必填与格式提示是交互辅助，服务端还要重新校验请求和权限。这一点见 MDN 客户端表单校验，核对日期 2026-09-12。下面是用于本地开发的任务单，交付时要附实际运行结果，不能仅给生成的页面图片。

店员把已确认预约改到新场次时，应先保证新场次能够分配，再完成原场次释放；如果新场次冲突，原预约必须继续有效。不能先取消旧预约，再发现新时间已满。对第一版来说，可以把改期明确为店员操作，并要求顾客看到更新后的时间及变更记录。

通知发送失败也不能悄悄改变预约结果。业务确认已经持久化，就让顾客在查询页看到 confirmed，店员看到通知待补发；补发只处理通知，不重新创建预约。对人工电话确认，记录操作者和发生时间，区分实际联系与系统尝试发送。这样现场出现争议时才能还原发生了什么。

准备一名店员、两名虚构顾客、一个可约场次和一个关闭场次。先由顾客甲提交申请，店员确认后刷新双方页面；再让顾客乙申请同一场次，记录系统如何说明不可用。随后取消甲的预约，再次尝试预订，并检查管理员记录与顾客看到的状态一致。以下是待执行验收表，尚无整站通过数据。

手机复核要真的打开软键盘，检查底部提交按钮、错误提示和时间选择是否被遮住。断网后重连不能自动连发多次申请；刷新确认页不得再执行提交动作。桌面截图好看，并不能代替这两类使用顺序。

域名、托管、数据库和通知账户的归属在交付前确认，店主应能拿到必要管理权。源码留出环境配置说明，密钥由受控环境注入，不能嵌进公开 JavaScript。对更新版本，记录代码版本、配置变更、数据库迁移、备份位置及恢复步骤，在测试环境先验证恢复，再进入单独授权的发布流程。

维护能力还包括日常操作：店主能否关闭某天营业，能否看懂失败申请，离职员工的权限如何撤销。交付演示应让店主亲手完成这些动作，而不是由开发者全程代点。对现有预约数据的格式迁移，要提前确认旧版本是否仍能读取，不能承诺恢复一个旧前端就能自动恢复全部数据。

将需求确认、预约业务实现、移动端复核、恢复演练和维护窗口分别列入工作单。运行成本包括托管、存储、通知和人工支持；用 AI 写代码的费用属于开发阶段，模型当前单价查看价格页。如果预约流程本身不调用模型，就不要按每笔预约虚构 AI 成本。

教学方案没有商家订单量或转化率证据。首次真实试用可以记录成功完成预约的人次、需要店员纠正的冲突和实际处理时间，但应使用真实记录，避免把访问量当预约量。入口选择仍不确定时看小程序报名路线，开发工具费用则按同任务订阅与 API 比较建立自己的账本。