AI编程为何让代码越改越烂？HumanLayer CEO拆解真相

当编程Agent成为代码质量的隐患

一个被广泛忽视的事实正在浮出水面：AI编程Agent在持续迭代同一个代码库时，往往会让代码质量不断退化。在与HumanLayer创始人兼CEO、"上下文工程"（context engineering）一词的提出者Dex Horthy的对话中，这个判断从模糊的"感觉"变成了可以量化的现实。

Dex提到了一个由威斯康星大学研究者Gabe Orlansky实验室打造的基准测试——Slop Code Bench。它的设计目标非常直接：证明模型会随着时间推移让代码库变得更糟。这与过去主流的几类编程基准测试形成鲜明对比，也揭示了当前AI编程能力评估体系的一个结构性盲点。

现有基准为何无法反映真实开发

Dex把过去的编程基准大致分为三类。第一类是以SWE-bench为代表的"小切片"测试：把真实开源仓库回滚到某个PR之前，丢给模型一个历史issue，让它修复，再用基准自带的测试来验证。"一个模型在SWE-bench上拿了95%，于是大家说编程被解决了——但这根本不是真实编程的样子。"

第二类是"马拉松式"任务，比如从规格书从零重建整个Redis或Excel的所有功能，单个任务可能长达4到400小时。第三类来自Cognition的思路：用更大的任务，并引入一个"裁判模型"在事后评估代码是否违反了代码库的规则、约定和模式。

但这三类有一个共同缺陷：它们都在一开始就把完整问题交给模型。而真实软件开发恰恰相反——你很少能提前知道全部需求。

SWE-bench是目前最具影响力的代码能力评估基准之一，由普林斯顿大学研究团队于2023年发布。它从GitHub上真实的开源项目（如Django、scikit-learn等）中抽取已解决的issue，将代码库回滚到问题出现时的状态，要求模型仅凭issue描述生成修复补丁，再用原仓库配套的单元测试验证。这套设计的优点是贴近"有明确答案的现实问题"，但正如Dex所指出的，它本质上是一个封闭式的单次修复任务——起点干净、目标明确、测试现成，与工程师日复一日面对不断演化、历史包袱沉重的生产代码库的处境相去甚远。此外，由于该基准广为人知，模型训练数据可能已包含相关issue和PR，导致评估存在数据污染风险，进一步削弱了分数的参考价值。

Slop Code Bench的巧妙之处

Slop Code Bench的做法是：先让模型从零构建一个项目（Greenfield），然后不断追加功能——"现在给这个代码库加这个特性，再加这个特性，再加这个"。每个挑战包含3到10个检查点，模拟模型在不了解全局的情况下持续无人值守地工作。

结果颇具说服力：所有模型的失败测试数量都呈上升趋势。Dex透露，GPT-5.5 Codex在某次测试中仅得约15%，而他独立测试的Astra约为16.5%——仅高出一个百分点。这个基准目前尚未被大量模型卡（model card）采用，部分原因是它运行起来既慢又贵，但它第一次为"模型不擅长长期维护代码库"提供了可量化的证据。

值得警惕的是，Dex指出模型在计算机操作、游戏生成等方向进步显著，但在写可维护代码、控制复杂度、删减代码、改变抽象这些真正体现工程功力的能力上几乎原地踏步。

"Slop"在英语俚语中指粗劣、泛滥的低质量内容，近年在AI社区被借用来描述大模型生成的冗余、表面正确却难以维护的"垃圾代码"。Slop Code Bench的命名直接点明了它的批判靶心：不是测试模型能否一次性解决问题，而是测试模型是否会随着任务迭代持续"产出糟粕"。Greenfield开发（绿地开发）是指在没有任何历史遗留代码约束下从零搭建新项目，是最理想的起点条件；Slop Code Bench正是从这一最优条件出发，逐步累加需求来观察代码质量的衰减曲线，使退化趋势更加清晰可辨。该基准运行成本较高的根本原因在于，它需要多轮完整的代码生成与测试执行，而非单次推理，因此难以像SWE-bench那样被大规模快速跑通。

不要"抵押"你的代码库

一个曾经流行的侥幸心理是："代码乱就乱吧，等到真出问题时，那就是GPT-7的事了。"Dex的回应一针见血："我们已经到了GPT-6这一代，这方面并没有太大进展。"

他的核心建议是：不要把你的代码库抵押在"一年后会出现一个足够聪明、能修复所有问题的模型"的幻想上。 各大实验室明显更热衷于在计算机操作等新前沿上"爬坡"，而软件可维护性的最后10%，可能和前90%一样难，甚至更难。

协作而非一次成型：Design Doc的价值

谈到企业落地，Dex强调HumanLayer对百人以上工程团队影响最大——因为这些团队有十年历史、数百个仓库、复杂的开发环境和各种"特殊约定"，云端Agent在这里会遭遇大量摩擦。

他反对"一次成型"（one-shot）的幻想："没有任何努力能让你开五小时会做出完美计划，然后喂给Agent就得到完美结果。"真正有效的，是过去三四十年工程团队一直在做的事——在动手前对齐要构建什么。

HumanLayer把这套流程称为"设计文档"（design doc），刻意区分"我们要去哪里/最终状态"与"我们如何到达/具体改动"。关键思路是：从2.5万英尺的高空视角，一个一页纸的概览就能消除50%可能出错的方向；再缩放到1万英尺视角，再消除80%的糟糕方案。这样当代码产出时，返工率可以从常见的25%–75%降到0%–10%。

"Instagram阶段"：大部分AI工程秀是假的

Dex对当前行业氛围的批评毫不留情。他引用另一位嘉宾的说法，称现在是AI工程的"Instagram阶段"——一切都是滤镜、花哨和表演。你若说"这东西对我没用"，别人就甩你一句"skill issue（你技术菜）"。

他亲历的一幕很典型：一家拥有数千工程师的老牌公司，部门负责人听闻别家宣称"90%代码由AI编写"，而他手下的首席工程师却在被AI生成的"3万行垃圾PR"淹没。于是高管圈陷入一种"我是第90百分位还是第99百分位、我是不是被甩下了"的攀比焦虑。

对所谓的token maxing（比拼烧了多少token、一周用爆六个Codex订阅），Dex直言："你到底交付了什么？" 他认为把"没榨干六个订阅就是烂工程师"的论调强加于人，对整个行业是一种伤害。他的立场始终是：从第一性原理出发搞清楚什么真正有效、什么实用，而不是从网上看到的东西倒推。

现实的生产力倍数：别追100x

当被问到合理的生产力倍数时，Dex给出了一个清醒的判断："如果每个工程师都能快2到4倍，对人类社会就是变革性的。"但很多人会错过这份收益，因为他们"忙着去追100x"。

他主张先稳稳地快2到3倍，再在此之上叠加2到3倍，如此复利式增长。试图推翻过去所有工程实践、从零重建整个工程体系，"行不通"。这本质上还是经典的YAGNI（You Ain't Gonna Need It）原则——不要为了想象中的完美去过度设计。

代码审查与"品味"的传承难题

Dex区分了审查代码的两个目的：确保正确和确保可维护。截图和视频可以验证功能是否正确，确定性工具（如圈复杂度检测）能拦下大类垃圾代码，但"我从没见过任何prompt或确定性工具，能在没有人类介入的情况下，有意义地对抗模型写不可维护代码的倾向"。

可维护性依赖"品味"，而品味来自被坏架构折磨的经历——那些凌晨三点救火、发誓"再也不让人合并这种模式"的时刻，积累成资深工程师的判断力。问题是：在Agent时代，新一代工程师如何建立品味？

过去靠PR review传承，但如今最糟的情况是：开发者没读懂自己提交的代码，审查意见直接粘给AI改掉，"那我就相当于在替你做所有重要的工作"。Dex欣赏Mitchell Hashimoto的做法——在PR里只说"去问你的Claude这为什么错"，不给任何提示，强迫对方真正去理解。他还预判：随着设计文档标准化，"设计阶段的教学与辅导"会变得和代码审查一样重要，甚至更重要，因为design doc本质上就是一个prompt。

圈复杂度（Cyclomatic Complexity）由Thomas McCabe于1976年提出，是度量代码逻辑复杂程度的经典指标，其数值等于代码控制流图中线性独立路径的数量。一个函数的圈复杂度越高，意味着其中嵌套的分支和循环越多，理解、测试和维护的难度也越大——通常建议单个函数的圈复杂度不超过10。这类确定性静态分析工具（还包括代码行数、函数耦合度、重复率检测等）能够自动拦截明显的结构性问题，是CI/CD流水线中常见的质量门禁。然而正如Dex所言，这些工具能识别"形式上的混乱"，却无法判断"在这个特定代码库里，这个抽象层是否符合整体设计哲学"——后者正是只有经历过架构债务之痛的工程师才能形成的直觉判断。YAGNI（You Aren't Gonna Need It）是极限编程（XP）中的核心原则，主张只实现当前确实需要的功能，避免为假想的未来场景过度设计，与Dex关于"不要为想象中的完美模型押注"的主张一脉相承。

Dex的真实Agentic工作流

抛开表演，Dex给出了HumanLayer的真实工作流拆解：

• 50%–60%的工作基本是一次完成：几百行以内的改动不做前期规划，直接做，然后测试、再补几个prompt。
• 约10%由"看门狗机器人"（janitor bots）在夜间完成：基于"代码库期望的最终状态"设置控制循环，像恒温器一样自动产出清理、重构、迁移端点等小型PR。每类PR同时最多只开一个，用标签避免重复修复，且刻意保持小巧——"PR太大就永远合不进去"。
• 约30%通过RPI流程（Research-Plan-Implement，其演进版本称为crispy/cordoy等）完成：先做代码库研究，构建查询计划，再用不知道原始ticket的新会话做研究，层层递进地规划。

对于上万行的大改动，Dex的做法是分段检查甚至拆成堆叠PR（stacked PR）："每一千行检查一次，比写完一万行发现全坏了再调试要省力得多。" 他还提到跨供应商的子Agent编排技巧（如让一个模型编排另一个模型的子Agent）。

Stacked PR（堆叠式拉取请求）是一种大型改动的工程管理策略：将一个巨型变更拆解为一系列相互依赖的小型PR，后一个PR以前一个为基础分支，形成"栈"结构。这种做法的好处是每个PR范围小、易于审查、合并后即可快速发现问题，避免数千行改动积压后才暴露设计缺陷。在Agent时代，Dex推荐这一模式有其特殊意义：模型在长上下文中容易"漂移"，分段提交可以为人类提供天然的检查点（checkpoint），在每个关键节点介入评估，而不是等Agent跑完整个任务才发现方向已经偏离。RPI流程（Research-Plan-Implement）则是将Agent任务显式拆解为三个独立阶段，其核心理念是用"不了解原始需求的新会话"做研究，以避免首轮对话中的偏见和路径依赖污染后续规划——这与软件工程中"关注点分离"的经典思想在方法论层面高度一致。

少做并行，专注最重要的一件事

关于并行执行，Dex的观点反直觉却务实："我不想每天早上醒来面对一万行代码。" 真正的工作应该更多地保持human-in-the-loop。

他反对盲目并行：与其同时在飞10件事、最后忘了两件、拖了四天只交付两件，不如"两件两件地做"，端到端的价值交付反而更快。他的原则是——永远清楚什么是最重要的那件事，一旦它解除阻塞就立刻放下手头其他事去推进它；其余任务只是等待时填补空隙用的。

关于token焦虑，Dex指出了一个关键错位：Twitter上"榨干六个订阅"的狂欢，与真实世界完全脱节——出于安全与数据留存要求，几乎所有企业都是按token付费，没有订阅计划。他预测我们终将回望这个"订阅榨取"的时代，意识到那不过是模型分发方式造成的短暂幻象。

正如他反复强调的那句话："工程中一直成立的道理，在所有工作中依然成立。"