一句话看懂：前 Meta 工程师 Evan X. Merz 撰文复盘自己转向 AI 编码的经历，认为过度依赖大模型会生成“脆弱代码库”。他列出四个机制和四个信号，核心问题是：AI 擅长解决局部问题，却很难顾及长期可维护性。
事件核心：发生了什么
Merz 在 2026 年 11 月 7 日的文章里提到，他今年 5 月离开 Meta，并猜测部分原因是他对 AI/LLM 编码工具的态度比同事更保守。到新公司后，他已按“今天的预期”切换为 100% 用 AI 生成代码。但他观察到，部分重度依赖 AI 的同事提交的代码变得脆弱，存在会被忽视的隐患，例如用 JavaScript 事件实现鼠标悬停效果，而不是 CSS 的 :hover 选择器。
他归纳出 AI 造成代码库脆弱的四个方式：测试写得浅，只覆盖 get/set 和已覆盖的 e2e 路径，覆盖率数字好看但有盲区；代码过度复杂，为遵循 DRY 而叠加不必要的辅助方法；开发者理解下降，长期依赖生成代码后，人难以判断新抽象是否兼容既有结构；提交速度超过评审能力，细节被略过并累积成技术债。
为什么重要
这是来自一线开发者的经验判断，不是同行评审研究，但它点出一个行业性张力：大模型的上下文窗口能很好地解决局部问题，却看不到跨模块、跨时间的维护成本。对大型 SaaS 产品而言，这种错位可能表现为事故增加、恢复变慢。文章也提醒，AI 并没有像宣传那样把个人产出放大十倍，至少作者自述没有两倍。
对用户/开发者/创作者的影响
对开发者来说，测试质量不能只看行覆盖率，评审 AI 生成的 PR 时要重点看抽象是否多余、命名是否准确；对团队来说，需要给评审留出时间，避免提交速度压过人的判断。对企业而言，文章建议留意四个信号：事故数量是否逐月上升、故障恢复是否变长，以及测试和命名等小问题是否持续堆积。这些都是可观察的工程指标。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
目前公开信息显示，这仍是个人观点，尚无系统数据验证。后续可观察：是否有团队公布 AI 编码前后的缺陷率、事故率对比；主流 AI 编程工具是否针对测试深度和代码复杂度提供约束；企业在推广“100% AI 生成代码”时，是否配套更严格的评审和可观测性流程。
