选错技术栈别硬扛：存量 vibe 项目换栈的最小代价实战

选错栈，是 vibe coding 的成人礼

用 AI 写项目的头三个月，一切都很美好。你对着对话框说"给我做个带用户系统的 SaaS"，AI 唰唰唰搭出一套 Next.js + Supabase + Stripe 的架子，部署到 Vercel，一天上线。然后用户来了，数据量上来了，账单也上来了——Supabase 的行级安全策略把你绕晕，某个边缘 case 下查询慢到超时；或者你发现当初图省事选的某个 BaaS，导出数据比登天还难；又或者 AI 给你选的前端方案，定制到第三个页面就开始处处打架。

这不是你笨。这是 vibe coding 的结构性代价：AI 做技术选型时，优化的是"最快跑起来"，而不是"最适合你三年后的样子"。它不知道你的用户会从 100 涨到 10000，不知道你的账单敏感度，也不知道你其实不会 SQL。当初那个"跑起来就行"的选择，迟早会变成每个深夜改 bug 时的叹气。

好消息是：选错栈不是绝症，但"硬扛"和"推倒重写"是两种慢性自杀。本文给你第三条路——一套专为一人团队设计的、最小代价换栈实战流程：旧系统全程可运行，每一步都可回滚，新栈先在"影子"里证明自己，再接管流量。

本文不讲"当初该怎么选"（那是选型指南的事），只讲"已经选错了，现在怎么办"。也不讲数据库 schema 变更那种小手术——那是另一篇指南的地盘。这里讲的是整块换掉：换 BaaS、换框架、换鉴权、换支付，一边开飞机一边换引擎的那种。

第一步不是动手，是诊断：这痛，值得换吗？

换栈最大的坑，不在技术，在决策。一人团队最贵的是时间，换栈是按"周"计的投入，换错了等于把本可以拿来获客的一个月烧掉。所以动手前，先做一次诚实的诊断。

五个"真信号"：出现任意两个，认真考虑换

• 账单信号：基础设施成本增速超过收入增速。不是"贵"，是"贵得不合理"。比如你的 BaaS 账单里 70% 是为你根本用不上的功能付费，或者按行数计费的数据库让你每新增一个用户都在亏钱。算一笔账：未来 12 个月继续用旧栈的总成本（含你的时间）vs 换栈一次性成本 + 新栈 12 个月成本，后者明显更低才值得换。
• 天花板信号：核心需求在旧栈上"做不到"，而不是"不好做"。"不好做"可以忍，"做不到"不能忍。比如你需要自托管数据合规，而 BaaS 不提供导出；你需要 WebSocket 长连接，而 Serverless 平台超时掐死你。注意措辞：很多"做不到"其实是"你还不会"，先花两天确认是平台真限制，而不是文档没读完。
• 心智负担信号：你害怕碰某块代码。这是最被低估的信号。当 AI 生成的某套抽象（比如一套你看不懂的 ORM 魔法、一个黑盒鉴权流程）让你每次改需求都先祈祷，说明这套栈已经超出了你的掌控半径。一人团队的栈，必须是你敢在半夜三点独自改的那种。
• 锁定信号：迁出成本每个月都在涨。数据、用户、文件、webhook，全都绑在单一供应商上，且对方没有提供像样的导出工具。今天不换，半年后数据量翻三倍，换的代价也翻三倍。锁定的可怕之处不在于"现在难受"，而在于"以后更难受"。
• 社区/维护信号：核心依赖已实质停更。不是"更新慢"，是 issue 半年没人回、PR 堆成山、官网文档 404。vibe 项目常被 AI 选进一些"当时很火"的库，火灭了，坑还在。

三个"假信号"：出现了也别换

• "别人都在用 X"。这是技术圈最贵的幻觉。别人的 X 解决的是别人的问题。把"我想换"翻译成"我现在的栈具体哪个需求满足不了"，翻译不出来，就别换。
• "新框架好酷"。酷不能当饭吃。换栈的 ROI 公式里，分子是"解决真问题"，分母是"你的周"。酷炫的新技术，分母巨大，分子多半是零。
• "代码太丑了想重写"。丑和错是两回事。AI 生成的代码大多丑，但只要它跑得稳、你改得动，丑就是审美问题。重写一时爽，还债火葬场——重写的新代码，三个月后一样丑。

诊断交付物：一张纸，写清三件事——(1) 触发换栈的具体痛点（量化：慢了多少、贵了多少、哪次故障）；(2) 不换的代价（未来 6 个月）；(3) 换的目标栈和"换完之后什么变好了"。写不出来，就说明还没想清楚，先别动。

三种换法，没有银弹：先选策略，再谈步骤

诊断通过，接下来选"怎么换"。业界有三种经典策略，区别不在技术高低，在风险和周期的 trade-off。一人团队没有"发布窗口期可以停服两小时"的奢侈，所以默认推荐第一种。

策略一：绞杀者模式（Strangler）——默认选项

名字来自"绞杀榕"：新系统像藤蔓一样，一点点缠住老系统，逐个模块替换，直到老系统被"绞杀"下线。做法是：在新旧之间立一层路由/网关，流量按模块逐步切到新实现。

为什么适合一人团队：每一步都是小步子，每一步上线后系统都是活的，任何一步翻车，回滚就是把路由指回去。你的用户永远不知道你在换引擎。代价是周期长——一个中等项目可能要 4-8 周，且中间有一段时间你要同时维护两套代码，心智负担 double。

适用：已有真实用户、不能停服、老系统是个大单体的情况。也就是大多数 vibe 项目的现状。

策略二：大爆炸重写（Big Bang）——限用场景

另起一个仓库/分支，一口气写完新系统，找个深夜一次性切换 DNS/流量，旧系统直接下线。

为什么一般不推荐：风险高度集中。切换那一刻，所有未知 bug 同时上线，而你只有一个人，没有 on-call 团队兜底。历史上"重写一时爽，上线火葬场"的故事，90% 是这个模式。它的唯一合理场景：项目还小（两周内能重写完）、没有付费用户、旧代码已经烂到读不懂。vibe coding 的早期 demo 阶段重写是划算的——因为代码是 AI 一晚上生成的，再让 AI 生成一晚上就行。但一旦有了真实用户和数据，这条路的期望收益就是负的。

策略三：共存双写（Parallel Run）——数据层的专用解

新旧系统同时跑，写操作双写两份，读流量先走旧系统；跑一段时间对账，确认数据一致后，再把读流量切到新系统。

为什么它是数据迁移的标配：数据丢了是不可逆的，代码 bug 是可以回滚的。双写期的对账日志，就是你信心的来源。代价是双倍的写成本和对账逻辑的开发量——但对账脚本可以让 AI 帮你写，这是 vibe 团队的优势。

一句话总结选型逻辑：有用户选绞杀者，没用户可大爆炸，动数据必双写。三种可以混搭：比如整体用绞杀者，其中数据层那一步用双写。

六步实战流程：旧系统全程活着，每一步可回滚

策略定好，进入执行。下面这套流程是绞杀者模式在一人团队的落地版本，六步走完，旧栈下线。核心原则只有一条：在任何时刻，你都有一个能用的系统，和一条回家的路。

第 1 步：诊断（1-3 天）——输出换栈 ROI 一页纸

承接上一节的诊断，但要落到更细：列出旧栈里所有要被替换的触点。vibe 项目最容易漏的是隐形依赖：定时任务、webhook 回调地址、第三方登录的 redirect URI、邮件模板里的链接、移动端写死的 API 地址。让 AI 帮你全仓库 grep"旧服务域名/旧 SDK 引用"，生成一份《换栈触点清单》。漏掉一个，上线那天就是一次故障。

同时定好回滚触发线：提前写下来，什么情况下回滚（比如错误率超过 X%、核心流程转化率掉 Y%、P0 故障超过 Z 分钟没修好）。写在纸上，而不是"到时候再看"——因为到时候你已经被肾上腺素淹没了，判断力为零。

第 2 步：防腐层（2-5 天）——新接口包住旧实现

这是整个流程里最关键、也最反直觉的一步：先不写新栈的代码，先给旧栈穿上一层"衣服"。在你的代码和旧服务之间，抽象出一层干净的接口（Repository 模式、Adapter 模式，叫什么都行），让业务代码只依赖这层接口，不再直调旧 SDK。

为什么这一步值：第一，它逼你把"业务真正需要的 10 个操作"列出来——很多时候你会发现，旧 SDK 的 100 个 API 里你只用了 8 个，换栈的工作量瞬间从"一座山"变成"一个小土坡"。第二，换栈时你只需要给这层接口写一个新实现，业务代码零改动。第三，万一新栈也选错了（别笑，发生过），有这层衣服，第二次换的代价是第一次的零头。

vibe 团队的技巧：让 AI 按"旧 SDK 调用点"反向生成接口定义，人工只 review 接口是否贴合业务语义。这是 AI 擅长的机械活，别自己手写。

第 3 步：影子双跑（3-7 天）——新栈先在暗处证明自己

新栈的第一个实现写完后，不要接流量。让它以"影子"模式跑：复制一份真实请求（或重放生产日志），同时打给新旧两套实现，对比返回结果，只记录差异，不影响真实用户。

影子期的目标不是"零差异"——那不现实。目标是把差异分类：哪些是预期的（比如新栈返回格式更干净）、哪些是 bug、哪些是旧栈的诡异行为（AI 生成的代码里这种很多，比如依赖某个未文档化的副作用）。每一类差异都要有 disposition（接受/修复/记录），没有"先上线再说"的差异。

影子期跑多久？看量级：一人小项目，影子跑 3 天、覆盖核心流程即可；有付费用户的，至少跑满一个完整业务周期（比如覆盖一次账单日）。

第 4 步：灰度切换（按模块，逐个来）——把大爆炸拆成小鞭炮

按第 1 步的触点清单，一个模块一个模块切。顺序有讲究：先切边缘模块，后切核心模块；先切读，后切写。比如先切"用户资料页"这种读多写少、挂了影响小的，再切"下单支付"这种命脉。

每个模块切换时用最简单的灰度：先 1% 流量观察 1 小时，再 10%、50%、100%，每档至少观察一个业务高峰。别整复杂的 feature flag 平台，一个环境变量 + 反向代理的权重配置就够。一人团队的灰度，糙一点没关系，关键是每一档都有明确的"继续/回滚"判定，而不是"感觉没问题就全量了"。

第 5 步：验证（与第 4 步并行）——指标、预案、演练

切换期间盯三组指标：正确性（错误率、影子对账差异率）、性能（P95 延迟、新旧对比）、业务（核心转化率、支付成功率）。业务指标最重要——技术指标全绿但转化率掉了，说明新栈"正确但不好用"，照样回滚。

另外，回滚要演练，不要只写在纸上。在切第一个模块前，先完整走一遍回滚：把流量指回旧栈，确认旧栈还能接住。这一步 30 分钟，能换来切换当晚的睡眠。很多团队的回滚预案死在"我以为旧环境还在"，结果旧数据库已经被删了——回滚演练就是用来发现这种事的。

第 6 步：清理（1-2 周内，别拖）——下线旧栈，还技术债

全部流量切完、稳定运行两周后，开始清理：删掉旧 SDK、旧防腐层里的旧实现、下线旧服务的账号/订阅（别忘了停掉旧服务的付费账单，这是真金白银）。

清理最容易犯的错是"拖"。因为系统已经跑在新栈上了，旧代码"又不碍事"，就一直留着。三个月后，新来的 AI 助手（或者三个月后的你）看到两套实现，会一脸懵。给清理设个 deadline，写在日历上，当成第 4 步的一部分来执行，而不是"有空再说"。

四类高频换栈场景：vibe 项目的真实现场

理论讲完，看几个 vibe 独立开发者最常撞上的具体场景。每个场景都给出"为什么常发生 + 换法要点"。

场景一：换 BaaS / 数据库（Supabase → 自托管 Postgres 等）

为什么高频：AI 生成项目默认选 BaaS，因为"零配置"。但当你需要复杂查询、数据要进自己的数仓、或者按行计费让你肉疼时，就得走。注意和"数据库 schema 变更"区分开——那是小手术（站内另有指南），这里是整个数据底座搬家。

换法要点：必用"双写 + 对账"策略。先搭新库，双写旧库和新库 1-2 周（用数据库触发器或应用层双写，应用层更可控），每天跑对账脚本比对行数与 checksum；确认一致后，先切读流量，再切写流量，最后停双写。vibe 团队常漏的一点：别忘了迁移定时任务和 Edge Function 里直连旧库的代码，那些藏在角落里的连接字符串，是上线日故障的头号来源。

场景二：换前端框架 / 全栈框架

为什么高频：AI 可能给你选了个"当时流行"但生态萎缩的方案，或者你发现 SSR/SEO 需求在当前框架下处处受限。

换法要点：这是绞杀者模式的教科书场景。用反向代理按路由分流：/app/* 走新框架，旧页面继续走老框架，用户无感知。先换 marketing 页、文档页这种静态内容多的（风险低，还能顺手练手），最后换核心交互页。注意保持视觉与交互一致——用户不应该察觉到"这一页和那一页是两个技术栈"，设计 token（颜色、间距、字体）先对齐再开工。

场景三：换鉴权方案（自研/某 Auth 服务 → 另一个）

为什么高频：vibe 项目早期要么用 AI 手搓了一套"能跑"的鉴权（安全隐患大），要么选了免费额度用完就刺眼的 Auth 服务。

换法要点：鉴权是"动不得"的核心，策略是双轨并行：新用户走新鉴权，老用户的 session/token 在旧系统继续有效，同时提供"静默迁移"——老用户下次登录时，自动在新系统创建账号并绑定。千万别搞"全员强制重新登录/重置密码"，那是对用户的公开处刑，流失率会教你做人。密码哈希如果算法不兼容，迁移时让用户走一次"验证旧密码→写入新哈希"的流程，这是标准做法。

场景四：换 AI 模型供应商

这个场景站内已有一篇 14000 字的深度指南（《模型退役潮生存手册》），讲透了三层抽象、eval 基线、灰度四步。这里只补一句 vibe 视角的忠告：如果你一开始就按"模型是可替换的零件"来写代码（prompt 与调用解耦、输出做 schema 校验），换模型就是改个配置的事；如果你把某家模型的"脾气"（比如它特有的输出格式、幻觉模式）硬编码进了业务逻辑，那每次换模型都是一次小型重写。防腐层的思想，在 AI 层同样适用。

六条反模式：换栈翻车的人，都栽在这些地方

• 反模式一："顺手"扩大范围。"既然要换数据库，不如把前端也重写了吧。"——打住。换栈期间冻结其他重构，一次只换一样。范围蔓延是换栈的第一杀手，因为它把"可控的小手术"变成了"不可控的大手术"，而你诊断阶段的 ROI 计算，瞬间作废。
• 反模式二：新旧并行期没有 deadline。"等稳定了再下线旧的"，结果并行跑了半年，两套账单、两套 bug、一颗崩溃的心。并行期必须在第 1 步就定好结束日期，写在日历上。
• 反模式三：跳过影子期，"直接灰度一点点上"。灰度能控制爆炸半径，但不能提前发现 bug。影子期是免费的（不影响用户），灰度是收费的（影响真实用户）。能用免费的方式发现 bug，就别用收费的。
• 反模式四：回滚预案只存在于脑子里。前面说过，回滚要演练。补充一条：一人团队的回滚预案必须"单人可执行"——如果回滚需要三个人配合，那它在你这里等于没有。
• 反模式五：换栈期间接新需求。换引擎的时候别加新乘客。跟用户/客户明说"这两周只修 bug、不做新功能"，这是专业，不是摆烂。新需求全部排到换栈完成之后，否则你会在两套代码里实现同一功能两次。
• 反模式六：为了"技术正确"而换。"这个新栈的架构更优雅"不是换栈理由，"旧栈让我每个月多花 2000 块/每周多花 5 小时"是。优雅是工程师的虚荣，账单和时间才是独立开发者的现实。

一页纸 Checklist：贴在显示器边上

• ☐ 诊断：痛点量化了吗？不换的代价算了吗？三个"假信号"排除了吗？
• ☐ 触点清单：让 AI 全仓库 grep 出所有旧栈引用，一个不漏
• ☐ 回滚触发线：写下来，错误率/转化率/P0 时长的具体数字
• ☐ 策略：有用户=绞杀者，没用户=可大爆炸，动数据=必双写
• ☐ 防腐层：业务代码不再直调旧 SDK，接口先行
• ☐ 影子双跑：差异全部分类，没有"先上线再说"的差异
• ☐ 灰度顺序：边缘→核心，先读→后写，每档有判定
• ☐ 回滚演练：切第一个模块前，完整走一遍回滚
• ☐ 并行期 deadline：写在日历上，到期必须下线旧栈
• ☐ 清理：删代码、删依赖、停旧账单，三件套别漏

最后说一句大实话：最好的换栈，是让换栈变得没必要。下次让 AI 搭架子时，多花 10 分钟做两件事：一是让数据层保持"可导出"（定期验证备份能恢复到本地），二是把外部服务调用收拢到一层薄薄的封装里。这 10 分钟，是你给未来的自己买的保险——真到要换的那天，你会感谢当初那个不嫌麻烦的自己。

而如果已经选错了，别硬扛，也别推倒重来。按这六步走，旧系统活着，你也活着，这就够了。