01

"现在 CC 这么厉害，直接让它写订阅逻辑不就行了？"

我理解这个想法，做订阅之前，我也是这么想的。

因为之前我做的是一次性支付的纯积分制，买 N 次收一定钱，永不过期，这其实很简单，没有周期、没有权限重置、没有等级重置，AI 写起来确实够用，描述清楚丢给它，很快就出来了，看起来能跑，看起来没问题。

毕竟现在 Claude 写代码确实很强，但订阅不一样。订阅有生命周期，有状态流转，有复杂的业务逻辑链条，不是数据库正确、看起来不报错就行，还要看是否和支付平台的用户订阅对准了。

Pay4SaaS 的 2 个订阅模块，是用 AI 开发的，但质量是我一点点抠出来的，不是它一次给到位的。

每一个边界情况，每一个异常场景，都是我反复结合行业常规做法、业务逻辑，用户体验三个维度，和它确认、修改、再测试，来来回回，才最终定下来的。

02

不敢完全信任 CC，是因为，只要我们频繁用 CC，就能发现的以下问题。

一、AI 会丢三落四。

很多社群朋友都吐槽过，说 CC 有丢三落四的毛病。

其实，做一些所见即所得、逻辑闭环简单的，是没问题的，比如，像做个页面，引入 fumadocs 做 docs/blog，统计分析，这些不到半天都能搞定的很好，但一旦牵涉关联多、逻辑复杂起来，它的丢三落四就开始显现了。前面漏一个判断，后面链条就断了，而且断的地方你不一定能马上找到。

这个丢三落四就像一个偶尔粗心、幻觉的同事一样，而在支付这么严肃的事情上，我们心里就更要打一个问号了。可怕的是什么呢？

就那么 1、2 次的丢三落四，足以让一个订阅链条走不完全。走不完全，就大概率会出错，这是必然的嘛。

它给我们说测试通过了，但其实，测的时候还是一堆问题的。AI 的工作在它输出代码的那一刻就结束了，后面所有的责任，都是我们的了。

二、AI 不知道我们的业务逻辑。

比如，降级是立即生效还是下个周期生效？AI 大概率直接改 plan_type，但用户这个月付的是高级套餐的钱，立即降级等于吃了用户的差价啊。

我用 pending_plan_* 字段记下来，等续费 webhook 到了才切换——这个 AI 想不到，是我反复测，反复修，才得以正确实现。

而有些问题呢，没有标准答案，取决于我们自己的产品策略。AI 只能猜，猜错了，代码跑起来了，逻辑是歪的，用户感受到了，我们还不一定知道哪里出了问题。

三、AI 覆盖不到边界场景。

而边界场景恰恰是支付最容易出事的地方。

它生成的代码看起来能跑，逻辑上也说得通，但边界情况它不一定想得到。比如——

• 它不知道 Paypal 和 Creem 的试用期产品，其实是需要创建 2 个的，否则就会让用户陷入无限试用。

• 两个请求几乎同时到达，一个是续费成功的 Webhook，一个是用户手动取消订阅的请求，AI 没考虑这种竞态条件，最终状态取决于谁后写入数据库——纯靠运气。

这些场景它没覆盖到，而我们也不一定发现，直到用户真的遇到了，才知道出问题了。那时候已经晚了。

03

既然 AI 靠不住，那就只能我们自己来。

支付是产品最后一道门，用户把钱给我们的那一刻，是信任度最高的时刻，也是最脆弱的时刻。这道门出了问题，前面所有的努力都白搭。

用户对支付问题的容忍度几乎是零，没有人愿意在钱的问题上将就。

04

其实，在工作中，真实的标准开发流程其实也是如此啊，需求、产品、UI、开发、测试，测试通过了才能上线，开发完不算结束。

而支付的测试呢，不是随便点几下看看能不能跑。光是订阅部分，正常流程要测，异常流程要测，边界情况要测，Webhook 要测，升降级要测，年付转月付要测，试用期各种情况要测。

我自己整理下来，光订阅部分就有 60 多个测试用例，每一个都要过，一个都不能跳过。

只有完成这些，才是真正的做完且做对。