为什么你给 AI 的“规矩”越多，它写的代码就越烂？

想象一下，你请了一位米其林大厨来家里做饭。 你对他说：“大厨，我想吃个蛋炒饭。” 没过几分钟，一份金黄诱人、粒粒分明的蛋炒饭就端上来了。味道好极了！ 第二天，你又想吃蛋炒饭了。但这次你加了一些“规矩”： 1. “大厨，你必须用这口生铁锅，不能用不粘锅。” 2. “饭必须是从左往右翻炒，不能乱搅。” 3. “盐必须精确到 3.2 克，且必须在关火前 5 秒钟撒入。” 4. “炒饭的过程中，你左手必须一直插在兜里。” **结果会怎样？** 这位大厨可能会因为这些古怪、繁琐的限制，分心到忘了关火，最后端上来一份烧焦的、咸淡不均的米饭。 在大模型（LLM）的世界里，这被称为 **“约束衰减（Constraint Decay）”**。 2026 年 5 月，一份名为 **《Constraint Decay: The Fragility of LLM Agents in Backend Code Generation》** 的论文揭示了一个让开发者扎心的事实：**随着你给 AI 的工程限制（架构模式、特定的库、数据库约束）增加，AI 解决核心业务问题的成功率会呈断崖式下跌。** ## 什么是“约束衰减”？ 论文作者 Francesco Dente 发现，现在的 AI 智能体在面对“裸题”时表现极佳。比如，你让它写一个简单的注册接口，它能写得飞起。 但一旦你给它戴上“工程枷锁”，比如： - “请使用干净架构（Clean Architecture）模式。” - “数据库必须用 PostgreSQL，且必须通过 SQLAlchemy 2.0 异步驱动。” - “所有实体必须经过 DTO 层的转换。” **AI 的表现就像是被捆住了手脚的舞者。** 实验数据显示，即便是在最强的 GPT-5.2 模型上，当你从“简单任务”切换到“全约束任务”时，它的代码正确率（Assertion Pass Rate）会平均暴跌 **30 分**。而那些稍弱一点的模型，成功率甚至会直接归零。 ## 为什么 AI 怕“规矩”？ 让我们用 Feynman 的方式来拆解这背后的脑力逻辑： ### 1. 脑容量（上下文窗口）被“非功能性需求”占满了 写代码需要消耗“注意力（Attention）”。当你要求 AI 既要写对逻辑，又要遵循复杂的架构风格时，它的注意力被大量分散到了这些“形式主义”上。这就好比你在解一道复杂的微积分题，同时还要按照特定的格律写成律诗，你的数学逻辑很可能会因此乱掉。 ### 2. “数据层”是 AI 的噩梦 论文发现，AI 跌跟头跌得最惨的地方在于**数据持久层（Data Layer）**。 AI 经常能写出逻辑通顺的代码，但在处理 ORM（对象关系映射）的细微规则时（比如 Session 管理、关联查询、层与层之间的边界隔离），它就会频繁产生“幻觉”。它可能会写出一段看起来很精美的代码，但一运行就会报各种数据库错误。 ### 3. “约定”比“显式逻辑”更难 有趣的是，AI 在简单的框架（如 Flask）里表现更好，而在那些“约定大于配置”的框架（如 Django 或 FastAPI）里表现更差。因为这些框架里有很多“魔法（Magic）”和隐式规则，AI 需要在脑子里记住太多的上下文背景，稍有不慎就会触碰禁忌。 ## 为什么这篇论文很重要？ 在以前，我们评价一个 AI 写的代码好不好，只看它“能不能跑通”。 但这篇论文提醒我们：在真实的工业界，**“能跑通”只是最低要求，代码是否符合团队的工程标准、架构规范，同样重要。** 如果一个 AI 写的代码功能全对，但把数据库查询逻辑直接塞进了前端展示层，那这段代码对于工程来说就是一份“负债”。 **总结一下：** 目前的 AI 还是一个优秀的“战术执行者”，但它还不是一个合格的“架构师”。 你给它的每一个约束，本质上都是在它的脑力天平上加了一块砖头。当砖头多到一定程度，天平就会彻底失衡。 所以，下一次当你让 AI 写代码时，如果它写得一塌糊涂，别急着骂它笨。先看看你自己是不是像那个古怪的食客一样，给大厨加了太多不必要的“左手插兜炒饭”的规矩。 **真正的智能，不仅是解决问题，更是在重重枷锁下，依然能优雅地解决问题。** 显然，AI 离这一步，还有很长的路要走。