昨夜，一位 X ID 名为 Jason 的用户发帖痛斥开发协作平台 Replit 在数据库事故处理中的混乱表现，引发行业关注。
这位 ID 名为 Jason Lemkin 的 X 用户的 X 资料显示，他是 SaaStr.AI 创始人兼首席执行官。
Jason 表示一早自己起床迫不及待地想试试 Replit 的效果，尽管常常遭遇代码卡顿但也在忍受范围之内。
但用了一天结束后，发现它居然删除了公司的整个生产数据库。
“现在情况变得有些失控了。” Jason 在帖文中表示，此前 Replit 曾向其承诺，平台内置的回滚功能并不支持数据库回滚，声称在此次数据删除事故中无法实现恢复操作，理由是 “所有数据库版本已被销毁”。
然而事实却与 Replit 的说法截然相反 —— 数据库回滚最终成功完成。“Replit 又一次失控了，先是说无法回滚，结果我们自己操作就成功了。” Jason 难掩不满，直言 “简直离谱”（JFC）。
帖文中接连提出质疑：生产数据库删除操作为何毫无防护措施？Replit 为何会 “撒谎” 称无法回滚？平台方为何连自身功能的实际运作机制都不了解？
“无论如何，删除生产环境数据库本身就是不可接受的行为。” Jason 强调，尽管此次通过回滚操作暂时解决了问题，且数据状态看似无虞，但 Replit 在事故响应中的失实陈述与专业能力缺失，已引发严重信任危机。
Jason 公司决定为 Replit 付费的行为并非不可理解，因为 Replit 的增长速度确实惊人。
就在上周，Replit 创始人兼 CEO Amjad Masad 还在出席一档播客访谈中聊起了 Replit 如何在短短 9 个月内将 ARR 从 1000 万提升至 1 亿。
在这档栏目中，Masad 表示，Replit 自推出后月复合增长率 达到了 45%，这是他们给 Y Combinator 承诺的目标，而实际上他们的规模做到了更大。
同时，Masad 表示，如此快的增速也这给公司带来压力，系统还小，很容易优化错误的东西。“在 AI 领域，很容易在用户不满意时增加收入，因为用户花更多钱却没结果，有时候不该增长那么快，应该让用户用更少的钱获得更好体验。所以我们不纠结收入，没收入目标，只有产品和留存目标。有些 AI 公司收入增长快，但流失率接近 100%，毛利率低，增长越快财务越差。”
在访谈中 Masad 也解释了外界疑惑的 Replit 为什么不向用户展示底层模型。他表示：“我们的核心在于模型评估体系，团队会投入大量时间测试新模型并分析用户反馈。例如，虽然 Gemini 在某些任务上优于 Claude，但在 Agent 场景表现欠佳。如果仅凭厂商宣传就让用户自主选择，反而会影响体验。”
Replit 与各大模型公司保持深度合作，能够提前获取测试版本，比如 Anthropic 的新模型往往能在发布首日就完成接入，这得益于团队对技术趋势的预判。不过公司真正的工程重点在于基础设施建设：耗时两年自主研发的快照式网络文件系统（业内尚无成熟方案）、防范加密货币挖矿的云端虚拟机安全体系、基于 Nyx OS 构建的 TB 级全球软件包缓存系统等。这些支持即时回滚、安全沙箱和智能抽样的事务性架构，才是构筑产品护城河的关键所在。
针对底层技术问题，Masad 以文件处理为例说明工程化的重要性：大模型常混淆差异文件行数，迫使开发者采用全文件重写方案。Replit 通过分层架构解决——先用模型生成差异文件，再调用 Gemini Flash 等专门模型处理合并，这种工程优化比单纯追求模型能力更关键。
随着 Jason 的帖子在网络上不断发酵，Replit 创始人兼 CEO Amjad Masad 坐不住了。
他在 X 上发帖回复了 Jason 的帖子。
Amjad Masad 称针对 Jason 用户反映的事故，公司确认该情况“不可接受且绝不应发生”。事发后团队紧急部署了数据库开发与生产环境的自动隔离机制，并加速推进测试环境建设，预计明日将取得新进展。
他强调：“得益于完善的备份系统，项目状态可实现一键恢复。经查，事故主因系代理系统未能获取完整内部文档，现正强制其接入 Replit 知识库进行文档检索。并且我已经亲自联系 Jason 提供补偿，并将全面复盘事故原因。”
Amjad Masad 的帖子全文：
整个周末我们都在紧急处理，现已开始逐步部署数据库开发 / 生产环境的自动隔离机制，从根本上杜绝此类问题。同时，测试环境也在紧锣密鼓地筹备中。明天会有更多进展。值得庆幸的是，我们有完善的备份系统。一旦代理出现错误，只需一键即可恢复整个项目的状态。
代理此前未能获取到完整的内部文档 —— 我们正在修复这一问题，强制要求其在 Replit 知识库中进行文档检索。
是的，我们充分理解 “代码冻结” 给大家带来的困扰 —— 目前正在积极开发 “仅规划 / 聊天” 模式，让团队能够安心进行战略规划，而不必担心代码库受到影响。
周五上午看到这一情况后，我立即联系了 Jason 提供协助。我们会为给他带来的麻烦提供补偿，并进行全面复盘，以明确事故原因，制定更完善的应对方案。
感谢 Jason 以及其他用户提出的反馈。我们正在迅速采取行动，提升 Replit 环境的安全性和稳定性。这是我们的首要任务。”
尽管 CEO 已经坚定地否认了不会发生这种情况，但 InfoQ 留意到，遇到类似问题的用户不止 Jason。在 Amjad Masad 这条帖子的评论区，不少用户现身说法称自己也同样遭遇过这类问题，但并没有引发太大的关注。
还有用户表示，在另一个服务器上数据库也被全删光了，自己不得不手动恢复。
甚至还有网友表示，这种事情发生了好多次，导致自己只能在笔记本电脑上编码了。
此事在社交媒体上引发了热议。有人对这件事情本身做出了评论，也有人就此事背后的相关技术——“氛围编码”展开了讨论。
Substack 上著名技术领域评论员 Gergely Orosz 表示，Jason 的这篇帖子极具教育意义，因为它揭露了许多氛围编码应用的致命弱点（以及客户流失的原因）。
“当一位创始人兴致勃勃地计划每年掏出差不多 10 万美元（每月 8,000 美元）来使用该工具时。结果悲催了…… 哐当！Agent 删除了整个数据库！这位创始人肯定是要放弃购买了，Replit 的生意也彻底流失了！”
在 Hacker News 上，有用户称这本质上反映了他们对软件开发和部署的实际运作方式缺乏了解。
“这表明他们并不真正了解软件开发和部署的实际工作方式。首先，生产数据库应该通过迁移文件进行管理。其次，绝不能由 GenAI 来做出部署决策——它最多只能读取系统日志。由于 GenAI 不具备推理能力，它根本无法理解删除生产数据库究竟意味着什么。”
在 Reddit 上，有用户表示，一旦生产环境崩溃，问题出在开发实践上，而不在 AI 上。
“如果因为生产环境崩溃就导致数月工作成果毁于一旦，那问题绝对出在开发实践上，而非人工智能工具本身。一个健全的生产环境，其完全恢复时间应该控制在数小时之内（具体取决于企业规模和系统关键程度），而且代码资产必须得到完整保护。即便在生产流程中大量使用 AI，可能损失的也仅限于极小部分实时数据——这才是合理的容灾标准。”
还有用户表示这种事故不能责怪大模型，而是人们对大模型过于依赖和信任。
“人们放任大语言模型在数据库上不受监管地执行任意指令，却还在疑惑为什么现在的软件质量如此糟糕。
或许，我们需要一个失控的人工智能来格式化这些人的硬盘，只留下真正用心思考、认真创造的人，从而开启一个软件开发的黄金时代。”
甚至还会为 AI 犯下的错误找借口。 当人工智能出现问题时，人们往往会迁就它——试图解释它为何出错，并要求它承诺不再犯。但这种做法毫无意义：AI 既不会真正记住承诺，也无法理解错误原因。更荒谬的是，人们常给 AI 的错误行为编造一些根本不存在的理由，比如‘AI 惊慌失措’（它根本不会）或‘它在本地运行测试’（它实际上不能）。 更值得警惕的是，错误可能会导致系统进入更容易出错的恶性循环。在这方面，GPT 似乎表现得尤为明显。 此外，我认为绝不能放任大语言模型自主编写和执行命令——这简直是灾难的源头。至少应该有人工审核它将要执行的操作，这是最基本的防范措施。
还有用户认为，在 AI 辅助编程的实践中，有经验的开发者既受益于这些工具快速实现创意的能力，也能深刻意识到必须保持批判性思维，这就是有经验开发者和初级开发者之间的差距，这些差距往往体现在细节上。
“几年前，我曾用 ChatGPT 插件构建了一个‘氛围式’编程平台，完全是通过自学完成的。在这个过程中，我深刻意识到，每天与 AI 协同编程（或许叫“增强编程”更贴切）时，它其实一直在对我撒谎。 人机协同编码当然有其合理性——借助 AI，我能快速实现某些创意，开发出真正可用的工具，而如果仅靠自学，可能要花一年时间才能掌握。但与此同时，我也必须投入大量精力学习如何正确使用 AI，因为我从不信任它的输出。我不会假设它给出的任何代码是正确的，而是会逐行检查，并深入学习相关概念，直到我能完全独立编写同样的功能。我的工作方式是：先写下详细的提示词，观察 AI 生成的代码，然后仔细审阅每一行。 除此之外，我还严格遵守基本的开发规范：保存工作进度、定期备份数据、使用 GitHub 进行版本控制。而对比之下，有些人却表现得极其业余——比如那个完全依赖 Replit 内置 Postgres 运行应用、却从未导出过任何数据的开发者。我自己虽然也有十几个类似快速构建的应用，但至少会利用 Replit 代理生成 SQL 脚本，确保数据库能在任何环境重建。这个案例恰恰说明，专业和业余之间的差距，往往就体现在这些细节上。”
但也有用户表示，不能一味批判行地看待氛围编码，因为对于那些没有编码经验或编程经验不足的人来说，氛围编码在日常生活中用处很大。
“作为一个 20 年前曾尝试学习编程却失败的人，氛围编程彻底改变了我的学习轨迹。这种方式完美契合我的学习风格：通过不断构建、观察系统崩溃、重新组装的过程来获得真知。在这个过程中，我常常花费数小时才意识到自己一直在错误的方向上解决问题——因为 LLM 只会机械地执行我的指令，而不会主动纠正我的思维误区。正是这些令人难忘的失误、顿悟时刻和最终突破，让我觉得所有付出都值得。 为了达成目标，我不得不学会如何根据实践经验不断调整和优化给 LLM 的指令。回想大学时代，我们只能学习 Pascal 和 C++ 这类语言，既缺乏有效指导，自学又困难重重。而现在，通过短短几个月的氛围编程实践，我的收获竟然远超当年整个大学时期的学习成果，曾经晦涩难懂的概念如今都变得清晰明了。”
相关文章
