我用 Fable 5 在不写代码的情况下搭建了一个全栈应用。然后我发现了某些东西，吓了我一跳。

我做软件工程师已经多年了。最近大家都在谈论 Fable 5 有多强大，所以我也想亲自弄清楚。
我做了一个实验。
我用 Fable 5 构建了一个全栈 Web 应用。不需要传统编码。我描述了我想要的功能，查看了生成的代码，然后让 AI 负责实现。
说实话，第一印象非常惊艳。
在很短的时间里，我就得到了一个看起来像真正产品的东西。UI 很精致。身份验证正常工作。数据库连接好了。主要功能都在。若是我把它展示给别人，而不解释我是怎么做出来的，他们大概率不会猜到其中大部分是由 AI 生成的。
我记得当时心里想：“这也太离谱了。也许我们比我想的更接近了。”
接着我像审阅任何真实的生产系统一样，开始审查代码。
就在那时，兴奋感开始消退。
这个应用看起来完成了，但我越深入，就越发现问题。
有些问题很小。有些则可能在之后演变成严重的麻烦。
确实存在安全隐患。一些 API 对用户输入的信任太过了。没有适当的限流。没有针对伪造账号和垃圾信息的防护。部分数据库查询在用户很少时看起来完全没问题，但数据一增大就会变成噩梦。
我发现了 N+1 查询问题、缺失索引、性能瓶颈、在用户请求期间运行缓慢操作而不是放到后台执行，以及在没有正确迁移的情况下对数据库进行变更。
最奇怪的是，表面上什么都不像坏了。应用是能用的。
你可以创建账号。你可以登录。你可以逐个点击浏览功能。甚至还能完成支付流程。
这正是让人感到有趣的地方。
很多用 AI 构建的人并不会上线显然崩溃的应用。他们上线的是看起来已经完成的应用，但在下面埋着隐藏的问题，等着爆发。
漂亮的 UI cứu不了一个糟糕的后端。
上线之前，我会确保你确实做过测试：
• 登录和密码重置
• 真正的信用卡支付（不是仅测试模式）
• 在真实域名上启用 SSL
• 分离开发环境和生产环境
• API key 没有在任何地方被暴露
• 生产数据库备份确实可用
安全问题是另一类通常直到太晚才会显现的问题。很多应用在规模小的时候不会被滥用。它们通常是在开始引起关注之后才遭到滥用。
比如：
• 邮箱验证
• 限流
• 输入校验
• 基本的防机器人保护
这些细节可能会决定差距：是顺利上线，还是在醒来时发现自己面对成千上万的假账号。
性能也是另一个陷阱。只有你自己是用户时，一切都显得很快。等到真正的用户到来，问题就会出现。于是你会突然遇到慢的数据库查询、页面一次性加载成千上万条记录、昂贵的任务阻塞请求，以及完全不知道哪里出错，因为没有任何监控。
分页、数据库索引、后台任务和错误监控，并不是你在成功之后才添加的东西。它们是在你开始增长时能让你活下来的关键。
我吸取到的最大教训之一是：别让 AI 直接修改你的生产数据库架构。
要用迁移。
迁移只是一个小文件，用来描述数据库的变更，比如添加一个列或创建一张表。它按顺序运行，可以追踪，并能让开发环境和生产环境保持一致。起步时它看起来像是在额外增加工作量，但它会在之后避免很多痛苦的问题。
好笑的是，这次实验反而让我对 AI 编码更乐观了。
Fable 5 很强大。它帮我节省了大量时间。
但生成一个应用和构建一个生产系统之间是有差别的。
AI 能快得惊人地写代码。
但它并不会自动理解那些来自多年与真实用户打交道、处理安全问题、解决扩展问题以及应对生产故障所形成的决策。
我一直在记录我发现的所有问题，因为我觉得很多人目前正在构建并上线 AI 生成的应用，却没有意识到这些问题确实存在。
这个周末，我会和一位在 Google 工作的朋友一起举办一次免费的线上 Zoom 直播。我们会一起走查实际的应用，展示我们发现的问题，解释它们为什么重要，并在把它交给真实用户之前讨论我们会如何修复。若你有兴趣，请私信我，我会把 Zoom 会议的详细信息发给你。
总的来说，最让我意外的并不是 AI 会犯错。更让我意外的是，在我开始更深入查看之前，这个应用看起来竟然如此让人信服。
我很好奇：如果你已经做过“氛围编码”的应用，那你在上线之后发现的第一个意外问题是什么？