用 Claude Code 搭建带授权校验的预约页

Calendly 试用到期后，作者用 Claude Code 给自己的产品补了一套预约功能：读取 Google Calendar 空闲时间、核验客户许可证、创建会议，再发送确认邮件。作者称，API 费用最多 $11.54，自己投入约两小时。

吸引人的地方不是「十几美元替代一个 SaaS」，而是这笔账背后的条件：已有组件、明确规则、独立审查，以及主动砍掉的功能。理解这些前提，才能判断你的项目适不适合照着做。

为什么这次值得自己做

作者的 Vuesion Business 许可证包含一次 60 分钟的入门指导，之前通过 Calendly 预约。试用到期后，他才发现自己用到了付费功能，需要付钱，或者重新按免费版的能力配置。

单凭这个理由，自建未必划算。作者也承认，两年前他会重新配置 Calendly，或者寻找免费替代品，因为自己实现大概要花三到四天。

真正推动决策的是业务约束：预约者必须持有有效的 Vuesion 许可证。按作者的描述，通用预约工具无法直接完成这项核验。预约入口放回自己的应用，才能把预约资格和产品授权串起来。

需求因此被限定得很具体：

• 按 Google Calendar 的忙闲状态展示周视图，排除柏林公共假日。
• 按柏林时间开放预约：周一至周四 12:00 到 13:00、17:00 到 19:00，周五和周六 12:00 到 19:00。
• 每个时段为 60 分钟，至少提前 24 小时预约，最远开放未来 28 天。
• 收集会前问题，通过 Lemon Squeezy 验证许可证，并发送自定义样式的确认邮件和 iCal 附件。

取消、改期和提醒都没有做。需要调整时间，直接回复邮件。

低成本的第一步，是把要解决的问题限定到足够小。

它服务于已有产品的一条业务流程，没有承担通用预约平台的完整职责。

预约页面容易写，失败后的状态才难处理

这套实现把 Google Calendar 作为可用时间的唯一事实来源，数据库不保存另一份忙闲状态。页面只允许点击空闲时段，正式预约前再检查一次。

这个选择减少了同步问题：不用解释数据库显示空闲、日历却已有安排时，到底该信谁。不过，提交前重查是否足以避免并发预约，原文没有交代，不能直接当成完整的并发控制方案。

创建预约也有明确顺序：先验证许可证，再创建带 Meet 链接的 Google 日历事件，最后激活许可证。如果激活失败，就删除刚创建的事件。相关人员随后收到带 .ics 文件的邮件。

这里用了补偿操作：多个外部服务无法一起成功或一起撤销，就在后续失败时，尝试撤回前面已经完成的动作。

真正有参考价值的是审查阶段发现的漏洞：

• 访客邮箱里的换行符可能向日历文件注入额外内容。
• 日历 ID 错误或日历未共享时，Google 仍可能返回成功响应，但在响应内部携带错误。忽略它，就会把整本日历误判为空闲。
• Lemon Squeezy 的一种错误响应被误当成「许可证已经使用」，缺失字段又被误当成「无限制许可证」。
• 确认邮件发送失败，会让已经写入日历的预约也被判定为失败。

这些问题指向同一个检查习惯：不能只看请求是否成功，还要确认业务结果是否成立。尤其是邮件发送，它失败后应该如何提示、是否重试，必须和已经成功创建的预约分开考虑。

$11.54 买到的，是已有基础上的最后一步

作者先让 Claude Code 规划需求。规划时，代理准备从零写周历；作者指出 Vuesion 已经有对应组件，代理才改成扩展现有实现。这是作者报告的唯一一次纠正。

实现阶段，代理把计划拆成七项任务。每项由子代理实现，另一个审查者检查，修复发现的问题后再复审。作者称，这个阶段没有再回答问题或修改实现。原文提到通过一条命令启动，但没有给出命令内容。

交付数据也比较完整：约 2,600 行新增代码，另有 645 行加入现有文件，大约一半是测试；新增 82 个测试用例，项目全部 4,256 个测试通过，覆盖率为 100%；lint、类型检查和两项构建均通过。

随后，作者花一小时配置 Google 和 Lemon Squeezy，再花半小时手动测试预约流程及自己能想到的边界情况。后续只调整了一项交互：预约表单由日历下方改为弹窗。加上前期参与，他估计个人投入约两小时。

费用需要分开理解。作者报告的 API 成本上限是 $11.54，其中规划会话还混有无关清理工作；他同时订阅了每月 €20 的最低档 Claude 计划，这次功能消耗约每周额度的 6% 到 7%。原文没有提供足够明细，不能把它直接换算成所有人都能复现的总成本。

更大的前置投入是组件。Vuesion 已有日、周、月视图和 Gantt 图，作者此前在 Claude Code 帮助下，用两个周末、约四天完成；其中周视图就花了好几天，主要难点是时区。Vuesion 本身还是一套基于 Nuxt 4 的 SaaS 基础。

这次便宜的是增量功能，之前积累的组件和工程规则已经付过成本。

作者现在也不逐行阅读代理生成的代码，而是手测行为，再浏览代码是否符合已有的结构、命名、分层和测试规范。他明确承认，这种做法依赖规范已经存在，否则浏览代码也看不出多少东西。

我的判断

我认同作者对复用和范围控制的重视。对于前端、全栈团队，已有组件和业务集成不仅方便人写代码，也能减少代理的实现工作量。但代理不会自动找到所有可复用资源，规划阶段指出已有周历，比后面审查一套新组件更省事。

审查流程同样值得参考。作者列出了具体缺陷，比单报测试数量更有说服力。不过，原文没有提供「单代理实现」与「实现加独立审查」的对照数据，也没有解释覆盖率的统计范围。82 个新测试和 100% 覆盖率说明执行了检查，不能证明业务边界已经穷尽。

两小时对比三到四天，也只是本次投入与作者估计的人工耗时对比，并非受控实验。长期维护、外部接口变化，以及补偿删除失败后的处理，原文都没有展开。

作者保留现成免费工具、继续购买基础设施，也明确不自建 Lemon Squeezy 或 Stripe 这样的支付服务，理由包括法律和监管负担。这个边界很务实：如果自建托管成本高于一个能覆盖大部分需求的免费方案，他仍会选择免费方案。

因此，这篇更适合被理解为一次有条件的自建决策。它支持「小型业务工具可以重新算账」，还不足以支持「订阅软件都该自己写」。

能拿来做什么

• 下次让 AI 做预约页、问卷或表单时，先把现有组件、业务校验入口和代码规范交给它，并检查计划是否真的复用了这些资源。
• 在 Node 服务对接日历、授权和邮件时，把每一步成功后的状态、失败后的补偿写清楚，特别检查「请求成功但业务失败」和「主要动作成功但通知失败」。
• 手测时沿着作者暴露的问题补充用例，包括字段缺失、响应内部报错、输入换行和邮件发送失败，不要只验证正常提交。
• 比较自建与订阅时，同时列出开发投入、已有基础、托管和后续维护成本；优先考虑能嵌入现有应用、又确实需要业务定制的小功能。