01

俩月前，在打通了和后端的握手后，我发布了这样的一篇文章，标题是，「有了 Supabase，前端可以原地秒变全栈了（附打通教程）」。

然后呢，2 个月后，真的成真了。我，真的成了全栈。

但你要问我写了多少后端代码？

一行都没写。

02

代码是 CC 写的。但每一个决策，是我做的。

这 2 件事，我想说清楚。

做支付系统，难的不是把代码跑起来，难的是知道哪里会出问题，为什么会出问题，出了问题往哪里找。这些判断，AI 不会主动告诉你，是我自己在真实的问题里逼出来的。

来 3 个例子。

03

我质疑了数据库设计。

有一天我在看数据库，发现 profiles 表里有三个字段专门存订阅状态——订阅是否有效、订阅计划、订阅到期时间。我的第一反应是，「这些不是都能从订阅表查到吗？为什么要在这里重复存一遍？」

我去测试了一下。删掉一条有效订阅，再去看 profiles 表，里面的订阅状态还是显示「有效」。

数据不一致了。

后来查代码，确认了这三个字段在整个项目里完全没有用到，是死代码。它们存在的唯一效果，就是在关键时刻给你一个错误的数据。

我没有写发现这个问题的代码，但我看到了问题在哪里，用实际测试证实了它，然后把它干掉了。

04

我从产品角度推翻了技术方案。

PayPal 支付失败的时候，AI 给的方案是：只记录日志，不更改订阅状态，因为 PayPal 还会自动重试。

我说不对。「支付失败就应该是 past_due，该支付的没支付，这是事实。」

然后我给出了状态流转的完整链条——

支付失败 → past_due → 如果继续不处理 → expired。

这不是工程思维，是产品思维。

past_due 状态的意义是告诉用户「你有一笔钱没付，去更新付款方式」。

如果等到 PayPal 重试三次失败之后再改状态，用户根本不知道发生了什么，等收到「订阅已停止」的通知，已经晚了，体验也极差，是吧。

技术上「重试机制」没有错，但用户体验上「及时告知」更重要。这个判断，是我做的。

后来业务逻辑又迭代了一次，past_due 直接走 expired——但那，是另一个故事了。

05

我追着一个问题问了三层。

升降级判断逻辑用的是一个抽象打分公式：tier × 10 + cycle（年/月）。所以 pro 年付 = 22分，max 月付 = 31分，系统判定 pro年 → max月 是「升级」。

我看了界面，觉得不对劲。

「我选了 pro 年的，现在选 max 月的，界面上显示升级……这不对吧？年付收费高，max 月付明显更便宜啊。」

我没有被抽象的评分体系糊弄，直接回到最朴素的商业直觉——用户少花钱了，那就是降级。于是把整个打分公式砍掉，改成直接比较实际价格。

但我没停在这里。

我又问了一层，「行业里普遍的做法是什么？允许年付中途切月付吗？」

查完之后发现，大多数 SaaS 不允许年付中途切月付——年付有折扣，退款计算复杂，支付平台升降级容易出问题。对我来说，想清楚的瞬间就是行动的时刻，于是，拍板加了拦截。

一个只管修 bug 的人，会停在第二层——价格比较逻辑改好了，收工。

但第三层才是真正重要的——这种操作，到底该不该被允许？

这是产品策略问题，不是代码问题。

从我这么多年的从业经验来看，永远是策略决定执行，而不是反过来。代码写得再漂亮，方向错了，全部推倒重来。

06

我想主动说出来，不想回避——这两个月，代码几乎全是 CC 写的，CC 确实帮我干了不少活。

但我知道每一行代码为什么要这么写？以及，出了问题，我知道去哪找。遇到边界情况，我能判断怎么处理。

以前「会后端」的定义是会写代码。我觉得这个定义正在变——能判断、能决策、能把系统跑通、出了问题能找到根因，这才是核心。代码只是执行层。

我没有写代码，但我指挥了整个系统的建造。就像一个建筑师，不需要自己砌砖，但他需要知道每一面墙为什么在那里，如果拆掉会怎样，如果地基有问题往哪里看。

07

俩月前随口说了一句「前端可以原地秒变全栈」。

现在，它成真了。

我从高中就会设计，我是前端，作为一个 BUG 中间件，所以，我懂审美和用户体验，我能做产品决策，在公司时这点也常被领导认可，我把整个支付系统跑通了，我还会搞服务器后台，阿里云部署也在 2 天学会，并提交代码自动部署 2 个域名，等等，这不是运维的工作么，哈哈。

接下来，我还要做一件从来没认真做过的事——把它卖出去。

「前端」这个岗位，大概已经装不下我了。