1. Stripe 计费模块不是“调个 API”就能上线的——Claude Code 辅助开发时，我亲手删掉了 37 行它生成的、看似完美却会引发月结账单错乱的代码Stripe 的文档写得足够清晰，SDK 也足够成熟。但 SaaS 计费模块真正上线前踩过的坑，90% 不在 Stripe 官方文档里，而在「业务状态机」和「AI 编程上下文边界」的夹缝中。去年 Q3，我们给一个面向中小企业的协作平台接入订阅计费。团队用 Claude Code（v4.2，配合 VS Code 插件 2.8.1）辅助开发后端计费服务。第一版交付只用了 2.5 天——比纯手写快了近 3 倍。但上线第 4 天凌晨，财务同事发来截图：某位升级为 Pro 的用户，系统同时扣了两笔首月费用，一笔走的是 Stripe 正常支付流程，另一笔是通过 webhook 重放触发的重复结算。更糟的是，该用户后续所有账单周期都偏移了 1 天，导致下个月初自动续订失败，触发了 12 个用户的降级通知。问题根源不在 Stripe，而在我们让 Claude Code “理解”了一个它根本无法 hold 住的上下文：计费状态迁移的原子性、幂等性约束、以及 webhook 事件与数据库事务的最终一致性边界。这不是 AI 写错了某一行if判断，而是它在缺乏显式、分层、带副作用标注的 prompt 指导下，把「创建订阅」、「处理支付成功 webhook」、「更新用户权限」三个强耦合但必须解耦的操作，揉进了一个函数里。它生成的代码逻辑自洽、语法无误、甚至单元测试全绿——但它在并发场景下必然崩溃。这件事让我彻底放弃“让 AI 写完就提测”的幻想。真正的效率提升，不来自“生成更多