用氛围编码（vibe-coded）开发应用的第 1 天，是你做过最完美的演示。提示词生效了，界面很干净，数据库里有数据，你还发了一条带屏幕录像的推文。我们经历过很多次这样的日子，我们并不是要剥夺这种体验。
我们要聊的是第 2 天，因为没有人的发布帖会提到它。第 2 天是当真实用户登录，做了某些你没想到的测试，你的应用在 “生成” 与 “工程” 之间的差距开始显现的时候。
第 2 天的真实样子
它很少以崩溃开始。它始于一些奇怪的现象：一个接受垃圾数据的表单，一个对某个特定用户失效的页面，一个没人能复现的错误数字。你把错误粘贴到聊天框里，AI 自信地修复了它，结果这个修复又弄坏了其他东西。
欢迎来到提示词打地鼠游戏。因为 AI 修复的是症状而非根源，每次补丁都叠在上次之上，代码库悄然变成了开发者所说的 “弗兰肯斯坦代码”：一个由冲突风格、重复函数和混乱逻辑组成的补丁集，数据库查询直接写在界面代码里。随着项目规模超过 AI 的上下文窗口，模型开始忘记之前的决定，并提出与之矛盾的代码。你不再是在维护一个应用，而是在与它谈判。
还有一种更残酷的情况：静默部署失败。你的托管构建因为一个微小错误而失败，实时 URL 依然显示旧版本，而你 - 因为没看到变化 - 告诉 AI 它的修复 “没起作用”。于是它针对一个已经解决的问题，生成了一个完全不同且更复杂的方案。几轮之后，你得到了一个臃肿的 v5 版本代码，而 v1 版本其实就很好。
你看不见的部分
调试的跑步机至少是可见的。但安全问题不可见，这就是为什么我们在处理商业构建时态度如此严肃。
相关的研究结果令人不安。LLM 生成的代码大约 90% 能成功编译，但其中约 45% 包含 OWASP Top 10 漏洞 - 比如可绕过的登录检查、注入缺陷。AI 工具优化的是演示效果，这导致了可预见的捷径：在浏览器端实现访问控制，用户可以通过编辑页面直接绕过；数据库权限设为全开，以确保构建时不报错；API 密钥直接硬编码在文件中，因为构建者不知道什么是环境变量。随后这些文件被推送到公开的 GitHub 仓库，被凭据抓取工具定时收割。
这就是为什么这特别属于 “第 2 天” 的问题：一个可被利用的应用运行起来非常完美。对于 “客户 A 实际上可以读取客户 B 的记录” 这种情况，没有错误消息。如果你运气好，你会从用户那里得知，否则后果更糟。而标准的建议（“多测试就好！“）在现实面前失效了：非技术构建者测试的是理想路径，而失败隐藏在边缘情况中 - 比如并发 Bug，或者 AI 从未生成的、演示时不需要的忘记密码流程。
没人列入清单的维护债
将这些机制在数月内叠加，你就得到了我们认为的 “技术债高利贷”：现在立即获得软件，以后支付复利。AI 采取的每一个捷径都是未来的修复点。每次修复都要消耗更多额度并增加代码臃肿度。平台更新发布并破坏了你没碰过的东西 - 在提示词转应用平台上的长期构建者报告称，他们必须向客户收取月度维护费，仅仅是为了处理平台本身带来的回归问题。
这就是核心的讽刺之处：氛围编码承诺使软件民主化，但对于生产应用，它在很大程度上使技术债民主化了。非技术构建者最终面对的正是他们使用 AI 试图避免的东西 - 一个需要开发者判断力的代码库 - 只是现在它成了业务的支撑，而他们却读不懂。
诚实的抉择
那么你究竟该怎么做？在经历了大量构建和几次教训后，我们认为这取决于一个分叉，有两条诚实的路径，而那个不诚实的中庸地带是唯一的错误答案。
路径一：学习维护代码。 如果你足够热爱并愿意深入研究，氛围编码将成为一个真正的加速器而非陷阱。阅读 Agent 编写的内容。在发布依赖 RLS 的应用前，先搞清楚 RLS 是什么。从仅限提示词的工具升级到 Cursor 或 Replit，在那里代码就是界面，你可以建立真正的判断力。这条路确实很棒 - 它只是一条路，需要数月的行走，而一边向客户交付未阅读的代码一边假装在走这条路，才是陷阱。
路径二：将危险部分放在非生成的基石上。 诚实地面对你的应用是一个商业工具 - 客户门户、追踪器、内部 CRM - 并意识到其中 80% 正是 AI 生成最糟糕的底层逻辑：认证、权限、密码重置、数据访问。在像 Softr 这样的无代码平台上构建这类功能，这里的底层逻辑是经过测试的、通过视觉配置的基础设施，而 AI Co-Builder 依然能为你提供第 1 天的开发速度。当你需要自定义风格时，它的氛围编码块将生成的代码限制在单个组件中，这样 AI 就可以在不影响屋顶的情况下装修房子。这条路径上的第 2 天是一次简单的编辑，而不是一次考古挖掘 - 这就是为什么它在我们的 客户门户排名 中名列前茅。
继续毫无顾虑地用氛围编码做有趣的事 - 原型、玩具、周末实验正是这些工具的强项。只需在真实用户出现之前决定，你站在分叉的哪一边。第 2 天不会礼貌地询问。