AI 写后端最容易误导人的地方，是功能看起来跑了。

接口能通，happy path 过了，代码也能拼成一个项目。很多 demo 到这里就结束。但真实后端不是 demo。它要服从架构分层、数据库 schema、ORM 规则、框架约定和团队已有的文件组织。

arXiv 上这篇新论文切的正是这个缝隙。作者把它叫做 constraint decay：结构性约束一层层加上去之后，LLM agent 的表现会明显下滑。

这篇论文最有用的地方，不是证明“AI 不会写后端”。它没有这么说。它真正提醒的是：功能正确和工程可用，中间隔着一整套秩序。

论文发现：约束越多，agent 越容易掉线

论文评估的是 LLM agents 在多文件后端代码生成里的表现。重点不是单个函数补全，而是生成或修改一个后端项目时，能不能同时满足功能需求和结构要求。

几个关键信息可以压缩成一张表：

问题论文里的设置或发现
发生了什么系统评估 LLM agents 生成多文件后端代码时的约束遵守能力
任务规模80 个 greenfield 任务，20 个功能实现任务
覆盖范围8 个 Web 框架
评估方式端到端行为测试 + 静态验证器
关键现象constraint decay：结构约束累积后，assertion pass rate 下滑
主要故障点数据层，尤其是查询组合错误、ORM 运行时违规等

这里最重要的是评估方法。

它不只看端到端行为测试，也用静态验证器检查结构要求。也就是说，代码“能跑”还不够。目录、分层、ORM 使用、数据访问方式这些规矩，也要被算进成绩。

结果并不温和：从基线任务到完全指定结构的任务，较强配置平均损失约 30 个 assertion pass rate 点；一些较弱配置在强约束下接近归零。

注意，这里说的是 assertion pass rate 点的损失，不是整体准确率下降 30%。这个区别要讲清楚。否则很容易把论文结论夸大成“AI 编程崩了”。

它没有崩。它只是露出了短板：约束越像真实工程，agent 越难稳定。

对后端工程师来说，这意味着不能只用“功能测试过了”来验收 AI 生成代码。对技术负责人来说，采购或推广 AI coding agent 时，也不能只看演示里的 CRUD 项目。要看它在你们自己的架构、数据层和框架约定里，能不能持续守规矩。

框架差异：不是谁好谁坏，是约束负担不同

论文还比较了不同 Web 框架下的表现。一个很现实的现象是：在 Flask 这类更小、更显式的框架里，agents 更容易成功；在 FastAPI、Django 等约定更重的环境里，平均表现更差。

这不是框架优劣排名。

Flask 更容易成功，不等于它天然更适合生产。Django 约定更多，也不等于它更差。论文能支持的判断更窄：不同框架给 agent 施加的约束负担不同。

人类工程师熟悉一个框架后，会把很多约定变成肌肉记忆。哪些文件该放哪里，ORM 查询怎么组合，模型关系怎么走，框架生命周期在哪里介入，这些东西不需要每次重新推理。

agent 不一样。它能拼出看起来合理的目录，也能写出像样的模型和路由。但到了数据层，问题开始集中出现：查询组合不对，ORM 运行时违规，结构上看似顺手，执行时却塌掉。

后端工程的麻烦就在这里。它不是一堆函数，而是一套互相牵制的制度。schema、模型定义、查询语义、事务边界、框架生命周期，错一个点，表面正确的代码就会在运行时露馅。

“法令滋彰，盗贼多有。”这句话放在这里不完全贴切，但有一点相通：规则越多，考验的就不只是聪明，而是守制能力。

这对团队动作有直接影响。

如果你的项目是轻量服务、约束少、边界清楚，agent 可以更积极地用在脚手架、接口草稿、低风险模块上。收益会比较直接。

如果你的项目是已有多年历史的后端系统，框架约定重，数据层抽象复杂，那就别把 agent 直接推到核心链路。更稳妥的做法，是先把它关进更窄的围栏：限定目录、限定数据访问模式、限定可改文件，再用静态检查和 review 接住它。

真正该观察的是约束执行，而不是 demo 漂亮

我更在意的是，这篇论文把 AI 编程的讨论从“会不会写功能”推到了“能不能服从秩序”。

过去很多编程 demo 很顺：输入需求，生成项目，自动修 bug，测试跑绿。它们展示的是生成能力。但真实团队要的是另一件事：代码进入已有仓库后，不要绕过架构，不要污染数据层，不要制造未来三个月的维护债。

这就是 AI coding agent 落地最容易被低估的成本。

如果一个 agent 在约束少的时候表现很好，在约束多的时候迅速衰减，它更像一个高产实习生，而不是可靠同事。高产当然有价值。但高产又不守规矩，成本不会消失，只会转移到 code review、重构和线上排障里。

技术团队接下来该看的，不是又一个“从零生成博客系统”的视频，而是几件更硬的事：

  • 在真实仓库里，agent 是否稳定遵守架构分层；
  • 对数据层的修改，是否能被静态验证器和规则测试拦住；
  • 在框架约定更重的项目中，失败模式是否可预测；
  • 生成代码的 review 成本，是否低于人工从头写的成本。

这些问题比“能不能生成 CRUD”贵得多，也诚实得多。

AI coding 产品团队也应该看见这个信号。下一轮竞争不只是上下文更长、补全更快、模型分数更高。真正能拉开距离的，是把工程约束产品化：规则可声明，验证可自动化，失败可定位，权限可收紧。

铁路早期拼的是谁能把铁轨铺出去。后来真正决定系统能力的，是调度、信号、维护和标准。AI 编程也有类似的一面。生成代码只是铺轨，约束执行才是调度系统。

当然，这个类比不能拉满。软件比铁路更灵活，模型也会继续进步。但今天这篇论文至少说明：只展示“能跑”的 AI 编程，已经不够解释生产环境里的风险。

后端团队不必因为 constraint decay 就停用 agent。更合理的动作是换验收口径：少看一次性成功，多看约束下的稳定性；少看输出速度，多看返工成本；少看模型自信，多看验证器能不能兜底。

功能会跑，只是第一关。工程世界真正要的是：在规矩变多之后，它还能不能不乱。