Vibe-Code 生产就绪清单

如果你用 Lovable、Cursor、Claude Code、Bolt、v0 或 Replit 做了点东西，而真实用户马上要用上它，先把这个跑一遍。它是一份独立清单，按每一项咬人的频率排序，你可以在叫任何人之前自己走一遍。一条规则：一个勾只有在服务端强制执行时才算数，屏幕上的不算。

这不是在贬低 vibe-coding。我们也是这么起步的。它是一张关于不会自动发生的工作的地图，好让你在事故之前先找出AI 生成代码里的缺口。

我怎么知道我的 vibe-coded 应用是否生产就绪？

按顺序走完下面十项检查。每一项都是一个带通过条件的问题。如果你不能拿出证据回答"是"，它就没完成。前三项是会变成事故的，所以别跳过。

清单

1. 服务端授权。对每个端点、每次读数据，服务端是否确认谁在请求以及他是否被允许？前端校验不算。通过：在请求里改一个用户 ID，确认你拿到的是拒绝，而不是别人的数据。
2. 租户与行隔离。如果应用是多租户的，一个账户能否在物理上触及另一个账户的记录？通过：隔离在数据库或查询层强制执行，而不是在你每个端点都得记得加的应用逻辑里。
3. 客户端没有密钥。API 密钥、数据库 URL 或令牌是否在客户端打包或仓库历史里？通过：扫描打包和 git 历史是干净的，任何曾经暴露过的都已轮换。
4. 每个入口都有输入校验。每个表单和端点是否都干净地拒绝畸形、超大和恶意输入？通过：往里扔垃圾返回一个干净的错误，而不是崩溃或被悄悄吞掉。
5. 失败路径已覆盖。当一个外部调用超时、失败或返回空时，应用是否优雅降级？通过：强制每个外部调用失败，确认屏幕不会因未处理的异常而变白。
6. 能扩展的查询。是否有数据库调用被放进了渲染循环里，或者为了数行数而拉整张表？通过：在真实数据量下做过性能剖析，N+1 查询和无界读取已清除。
7. 并发与幂等。两次点击会不会创建两个订单，或两个并行请求都通过余额检查？通过：任何写入资金或状态的东西都是幂等的，并能处理重复和并行请求。
8. 自有数据层并有备份。数据是否在你掌控的托管数据库里，迁移在版本控制下，并有自动备份？通过：你至少恢复过一次备份。一个你从未恢复过的备份只是一个愿望。
9. 依赖和许可证已审查。是否有某个包带着已知漏洞，或带着禁止你商用的许可证？通过：依赖与许可证扫描是干净的，或被有意识地豁免。
10. 存在回归套件。是否有测试，让下一次改动（无论 AI 写的还是人写的）都不能悄悄破坏已经能用的东西？通过：每次改动都跑一次套件。参见测试驱动开发，了解为什么当模型在写代码时，它更重要而不是更不重要。

"模型写出你要的代码，以及你忘了要的一切之外的、什么都不写。这份清单就是你忘了要的一切，按它通常造成疼痛的顺序排列。"

哪些项会阻断上线？

这十项并不等同。把你的失败项分进三个桶，好先修对的，而不是被整张清单卡住。

• 阻断项。任何暴露客户数据、损失资金或破坏状态的：第 1、2、3、7 项。它们不等。上线等它们。
• 高危项。尚未咬人的真实风险：第 4、5、6 项，以及第 9 项下的已知 CVE。在你长到它之前修掉。
• 清理项。真实但可承受：低风险输入上的薄弱校验、稳定代码上缺失的测试、第 8 和第 10 项的其余部分。值得做，可安全排期。

这样分桶的意义在于对紧迫性诚实。别把清理项打扮成阻断项，也别让一个真正的阻断项藏在长清单里。

我不能直接让 AI 自己修吗？

部分可以。一旦你指出位置，模型会乐意加一个校验或把一个调用包进错误处理。它做不到的是决定该往哪看。它没有你技术债的模型，也没有对真实用户第二天就会撞上的边界情况的直觉。找出缺口是人的工作。补上它们越来越是共担的工作。我们正是这样做的。

清完整张清单要花多少钱？

这取决于哪些项失败，以及产品涉及多少资金或敏感数据。我们在把一个 vibe-coded 应用做到生产可用要花多少钱里拆解了典型工作量区间和时间的去向。简短版本：跑这份清单的审计是便宜的部分，它在你投入之前就告诉你加固的规模。这是我们软件质量保证服务的入口。