AI连续编码七天靠谱吗？长时智能体的验证之道

一、一次“翻车”引发的行业讨论

前不久，某智能编程工具厂商公布了一项颇具冲击力的实验：让驱动的编码智能体连续自主运行七天七夜，号称从零写出了一个数百万行代码、功能比肩主流浏览器的项目。然而短短数日后，开发者社区的技术爱好者们查阅其公开仓库后发现，这份“百万行代码”甚至无法通过最基础的编译，相关产物被戏称为“AI泔水”（AI Slop）。

这一事件之所以值得所有技术团队关注，并不在于某家厂商的宣传是否夸大，而在于它暴露了一个普遍问题：当AI生成代码的规模和速度呈指数级增长时，我们评估“AI写出了可用软件”的标准，却还停留在“看代码行数”和“看演示动图”的原始阶段。行数可以刷出来，动图可以挑角度，唯独编译器和测试框架不会说谎。

二、“AI泔水”是如何炼成的：四个技术成因

1. 上下文窗口与记忆衰减

长时任务中，智能体赖以决策的上下文是有限的。当对话历史、文件内容、工具输出不断堆积，早期确定的架构决策会被挤出窗口；即便存在摘要压缩机制，也会丢失关键细节。其结果是：第1000步生成的模块，可能与第10步约定的接口完全对不上。这不是模型“不够聪明”，而是长时任务的信息管理本身就是未完全解决的工程难题。

1. 缺乏全局架构约束

人类团队开发大型软件时，依赖架构评审、接口文档、编码规范等“全局约束”来保证模块间一致性。而智能体在自主运行时，往往只针对当前子任务做局部优化。每个模块单看都“像模像样”，拼在一起却互不兼容——函数签名不一致、依赖版本冲突、同一功能被重复实现了七八遍，都是典型症状。

1. 无验证信号的错误累积

如果智能体在生成过程中没有持续收到“编译是否通过、测试是否通过”的反馈，它就无法发现自己已经错了。更糟的是，为了绕开此前的错误，它会继续堆叠补丁式代码，错误像滚雪球一样累积。这正是许多长时运行实验的产物“行数很多、可运行率极低”的根本原因：算力可以无限投入，但缺少反馈回路的算力只是在放大混乱。

1. 目标函数错位：生成不等于可运行

语言模型的训练目标本质上是“生成像代码的文本”，而不是“生成能通过构建的软件”。如果没有把编译器、测试框架当作外部裁判，模型自然倾向于产出“看起来完整”的代码——注释齐全、结构工整、文档漂亮，但一跑就崩。宣传叙事若只强调“生成了多少”，而不强调“验证了多少”，就天然存在误导空间。

三、验证AI生成代码的四道门禁

门禁一：构建必须可复现。声称产出了可运行软件，就应提供可复现的构建证据——完整的构建脚本、依赖清单、构建日志。一个连编译都过不了的仓库，任何“功能演示”都无从谈起。示意性的持续集成流水线如下：

# 通用CI流水线示意
stages:
  - build        # 编译/构建，零错误视为通过
  - lint         # 静态检查，拦截明显坏味道
  - test         # 单元测试 + 集成测试
  - smoke        # 冒烟测试：核心路径真实跑一遍
  - report       # 汇总证据：日志、覆盖率、产物哈希

门禁二：静态分析守住底线。对AI生成代码做静态扫描，重点看几类指标：重复代码率（AI尤其容易产生复制粘贴变体）、圈复杂度、未处理的错误路径、依赖冲突。这些指标能快速量化“泔水浓度”。

门禁三：测试闭环而非装饰性测试。数百万行代码如果测试覆盖率趋近于零，或者断言全是恒真式的摆设，就不能算“可用”。评估时应关注：断言是否验证了行为而非仅验证调用、边界条件是否覆盖、是否存在失败注入类测试。

门禁四：证据链与可复现性。一次严肃的技术验证至少应包括：完整的提交历史（能否看出渐进式开发的真实痕迹）、每个里程碑的可运行产物、真实的运行录屏或性能数据，以及让第三方可在干净环境中复现实验的说明。缺少证据链的“惊世成果”，默认应保持怀疑。

四、如何正确设计长时智能体任务

与其争论“AI能不能一周写个浏览器”，不如讨论如何设计任务，让智能体的长时运行真正产生价值。

1. 里程碑分解：把大目标切成可独立验证的切片，例如“先让最小内核编译通过，再叠加渲染能力，再叠加网络能力”，每个切片都有明确的验收标准。
2. 闭环反馈：把编译错误、测试失败作为环境信号持续回喂给智能体，让它“看得见”自己的错误，而不是闷头狂奔。
3. 角色分工：规划者负责维护全局架构与接口契约，实现者负责具体模块，审查者负责对每次提交执行构建与测试——用机制而非自觉来保证一致性。
4. 人工检查点：在关键架构决策处设置人工评审，避免智能体在错误方向上空耗大量算力。

五、给工程团队的评估建议

面对各类“AI编程突破”的宣传，团队可以建立一套简单但有效的评估框架：

• 不看行数看可运行率：能编译、能启动、能通过冒烟测试的代码占比；
• 不看演示看复现性：能否在干净环境中用其提供的材料复现结果；
• 不看单点看过程：提交历史是否连贯，是否体现真实的工程迭代；
• 不看叙事看维护成本：生成代码的可读性、模块化程度与后续修改难度。

软件工程的历史反复证明：写出来容易，跑起来难；跑起来容易，维护下去难。代码行数从来不是生产率指标——这一条对人类和AI同样适用。

六、结语

“AI泔水”这个词虽然刻薄，却点破了一个关键事实：规模化生成能力与规模化工程能力是两回事。随着Token成本持续下降，让智能体长时间自主运行在技术上并不困难，真正困难的是让它每一步都朝着“可验证的正确”前进。对工程团队而言，与其被震撼性叙事牵着走，不如把编译、测试、复现性这些朴素的门禁立起来——它们既是甄别宣传真伪的试金石，也是让AI编码真正落地的地基。