Anthropic 与 Simon Willison 之辩：更多代码不等于更好的软件

Simon Willison 重新启用了一个曾被视为禁忌的生产力指标。他认为，尽管这一指标数十年来饱受质疑，编程代理仍能让代码行数重新变得有意义。他在 8 月 19 日发表的文章源于一期关于 AI 辅助开发的播客讨论。搜索短语 anthropic simon 概括了这场争论背后的两股力量：Willison 的论点，以及 Anthropic 日益强大的编程工具。

Willison 并非声称程序越长就一定越好。他更狭义的观点是，软件生产曾长期受制于人类吞吐量的硬性上限。一名开发者在高效的一天里，或许只能完成数百行可投入生产的代码；如今，代理却能在同一时间内生成、测试并修改更多代码。

这种变化暴露了另一种限制。Fred Brooks 将其称为概念完整性，即一个系统应体现一套连贯统一的设计理念。编程代理能够提升实现能力，却无法自动在不断扩大的代码库中保持这种一致性。

因此，真正的较量并不是人类程序员与 Anthropic 或其他模型提供商之间的对抗，而是实现吞吐量与架构理解之间的博弈。团队如今生成代码的速度，已经快过他们能够自信地解释、审查和维护代码的速度。

Simon Willison 实际上如何改变了代码行数之争

Willison 将代码量视为生产约束被解除的证据，而非评判个体程序员的评分标准。

在他于 8 月 19 日发表的文章中，Willison 重新审视了软件团队因充分理由而长期拒绝的一个观点。统计代码行数会鼓励臃肿的实现、惩罚复用，并忽视最终系统是否解决了预期问题。

当管理者用它比较员工时，这些反对意见依然成立。删除一个脆弱子系统的开发者，可能比新增数千行代码的人创造了更多价值。紧凑的实现也可能更易于测试、理解和运行。

Willison 的论证从另一个角度出发。在编程代理出现之前，一名熟练工程师能够亲自产出的可运行代码量，构成了一道现实上限。输入代码只是其中一部分限制。开发者还必须浏览代码库、查阅文档、运行测试、调试故障，并审查最终变更。

代理将其中多项活动压缩进了一个交互循环。开发者可以描述一项变更，让代理检查相关文件，并要求其实现和测试结果。随后，人类审查补丁、纠正方向，或让它进入下一轮迭代。

代码行数在这里重新变得值得关注，因为上限已经移动了。如果一名工程师一天内可以监督多个规模可观的实现，代码量就记录了生产能力的真实变化。但这并不能证明产出的每一行代码都有用。

这种区分类似于工厂吞吐量。统计生产线上产出的单位数量，能说明产能的重要信息；但它无法告诉我们客户是否需要这些产品、它们是否符合规格，或是否会在使用中失效。

这一更狭义的主张很重要，因为围绕 AI 生产力的讨论常常走向极端。一方将每一行生成的代码都视为新增经济产出；另一方则彻底否定代码量，以至于无法描述实现吞吐量明显提升这一事实。

Willison 提出了一种更有用的中间立场：当问题是代理是否扩大了开发者能够尝试的实现规模时，可以统计代码；当评估可维护性、用户价值、正确性或工程判断时，则应停止统计。

这一解读也解释了为什么 Simon Willison 的 AI 实验会吸引开发者关注。他经常发布可运行的原型、工具，以及有关其构建过程的详细笔记。这些成果表明，代理能帮助一个人探索更多想法，即便这些成果并不等同于成熟产品。

因此，这种变化可以衡量，但衡量有其边界。更多可运行代码可以表明更高的生产能力，却无法判断团队是否明智地使用了这种能力。

为什么 Anthropic Simon 搜索指向 Claude Code 生产力

Anthropic 与 Simon 的关联在于工作流的变化：开发者正越来越多地监督实现，而不是亲手写出每一行代码。

Anthropic 将 Claude Code 描述为一款代理式编程工具，这意味着它可以检查项目、修改文件、运行命令，并朝着所要求的结果迭代。这种工作流不同于基础自动补全，后者只会预测光标附近的一小段续写内容。

这种差异改变了工作单元。使用自动补全时，开发者仍需一步步构建实现；使用代理时，开发者可以委派一个边界明确的结果，例如新增一个端点、编写一次迁移，或调查失败的测试。

Anthropic 的编程指南强调代码库探索、书面指令、测试和验证。这些实践揭示了一个重要现实：代理需要上下文和反馈，因为仅仅生成代码并不能保证变更正确。

一次现实的会话通常从侦察开始。代理会阅读项目说明，搜索相关接口，并梳理现有约定；随后，它会提出或创建补丁，再运行代码库中的测试。

人类仍然对目标负责。他们决定任务是否定义清晰、所选抽象是否适合系统，以及最终行为是否可以接受。随着生成代码量增加，这些决策会变得更加重要。

因此，Claude Code 的生产力包含两个组成部分。显性的部分是实现速度；不那么显性的部分，是开发者提供约束、识别偏离并拒绝看似合理却不合适的工作的能力。

Anthropic 更广泛的经济研究持续考察人们如何在不同职业任务中使用 AI。编程尤为突出，因为软件工作会产出可执行、可测试、可比较和可修改的成果。

这种反馈循环使编程特别适合代理。模型可以生成一项变更，观察编译错误，然后再次尝试，而无需等待人类解释每一次失败。自动化测试则提供了另一种即时纠正来源。

然而，可执行反馈只能覆盖代码库能够检查的内容。通过测试套件并不能证明新的抽象属于该架构，也无法揭示所有安全问题、运营成本或令人困惑的维护路径。

正是在这里，Willison 的论点比“编码更快”这样的简单主张更具影响力。代理如今能够产出足够多看似合理的软件，从而将瓶颈推向下游。审查、架构与验证必须承接新增的产出量。

承受压力的不只是拒绝使用 AI 工具的团队。缺乏更强控制机制就部署代理的组织，也会面临自身的不利处境。他们积累实现的速度，可能快过积累信心的速度。

这正是 Claude Code 生产力面临的核心挑战。该工具可以扩展一名开发者能够尝试的范围，但周围的工程体系决定了其中有多少产出能成为经久耐用的软件。

概念完整性是代码生成无法消除的约束

概念完整性意味着，即使有许多贡献者参与构建，系统各部分仍遵循一套连贯的设计。

Fred Brooks 在研究大型软件项目为何会变得困难时提出了这一理念。在他那篇经典的软件工程文章中，Brooks 认为，任何一种新的表示法、语言或工具，都无法消除本质复杂性。

编程代理改善了编程中许多偶然性的部分。它们可以编写样板代码、在 API 之间转换、定位定义、生成测试，并执行重复性的迁移任务。这些任务会消耗时间，却不总是需要新的架构构想。

本质复杂性依然存在。必须有人决定系统应当做什么、应暴露哪些概念，以及各部分应如何关联。这些决定定义了开发者和用户必须理解并持有的心智模型。

代理可以生成局部合理的代码，却削弱这一模型。它可能为已有概念创建第二套抽象，在两个模块中以不同方式处理同一错误，或引入与先前设计选择冲突的依赖关系。

每一个补丁都可能通过测试，但系统仍会变得更难理解。

代理的速度会放大这种失效模式，因为不一致性会不断累积。一个重复的辅助函数似乎无伤大雅；多个并行的领域模型、配置路径和重试机制，最终会让每一项变更都更加昂贵。

这一问题并非 AI 独有。大型人类团队长期以来都在与架构漂移斗争。编程代理增加了这样一种实现决策的数量：在资深审查者检查之前，它们就可能进入代码库。

这使概念完整性成为一种稀缺资源。它依赖于明确的所有权、文档化的不变量、一致的接口，以及理解早期选择原因的人。当 token 输出增加时，这些资源不会自动扩张。

一个有用的代码库会让代理以更少的有效方式解决同一个问题。它拥有既定模式、可执行测试和简洁的代码库说明。其模块边界传达的是意图，而不只是整理文件。

一个混乱的代码库则会产生相反效果。代理会看到多种先例，并可能选择看上去最接近提示词的一种。这一选择可能强化团队本已想要移除的偶然模式。

这种动态赋予了经验丰富的工程师另一种杠杆作用。他们的价值转向定义系统、减少歧义并审查关键决策。他们需要为代理运行环境的质量负责。

同样的经验也适用于项目知识。架构决策往往分散在问题追踪器、设计文档、会议记录和代码审查讨论中。一个可搜索的工程知识库可以帮助团队在另一条实现路径扎根前找回这些上下文。

代理仍然需要精确的指令。知识检索无法取代技术判断，但它可以降低新补丁忽略代码库外隐藏决策的可能性。

概念完整性将 Willison 的生产力论点转化为一个管理问题：当创建代码变得更便宜时，团队将如何维护那套让代码保持可理解的共享模型？

真正的对手是没有理解力的吞吐量

只有当人类理解、自动化检查和运营反馈能够同步跟上时，更高的实现能力才能创造价值。

Anthropic Simon 争论背后的核心冲突正在于此。编程代理可以生成更多变更，但组织评估这些变更能否构成一个连贯系统的能力依然有限。

审查是一个显而易见的瓶颈。无论由谁编写，大型 pull request 都需要时间理解。当审查者认为测试通过已提供充分证据时，生成代码可能会让问题更加严重。

测试必不可少，但其覆盖范围反映的是此前的预期。它们最擅长发现已知的失效模式。当补丁引入错误的需求、不合适的依赖，或让未来变更更困难的设计时，测试的作用就会变弱。

安全审查面临同样的不对称性。代理可以快速添加认证逻辑、数据处理和网络调用。审查者则必须检查这些元素如何与应用其余部分及其威胁模型相互作用。

运维提供了另一种延迟测试。在本地条件下运行正确的代码，可能会在生产负载、不完整数据或异常用户行为下失效。更频繁的发布可以加快学习，但前提是团队能够观察并解读结果。

因此，代理最适合用于边界明确且反馈迅速的工作。例如，更新经过充分测试的 API 客户端、转换重复性配置、围绕既有接口添加测试用例，或创建一次性原型。

当任务需要未文档化的产品判断或新的架构边界时，代理的适用性最弱。它依然能够生成答案，但其流畅性可能让答案看起来比实际更为确定。

研究同样警示，不应将自我报告的速度视为充分证据。2025 年的一项随机研究——developer productivity trial——发现，尽管经验丰富的开源开发者预期 AI 工具会提升速度，他们使用 AI 工具完成选定任务的速度反而更慢。

这一发现并未否定 Willison 的观察。该研究衡量的是特定人群、特定代码库、特定代际工具和特定任务选择。它表明，生成的输出、主观感受到的速度与实际完成的工作可能彼此背离。

经验丰富的维护者对项目拥有细致的心智模型。阅读和修正代理输出的成本，可能高于直接编写一项熟悉的变更。对于不那么熟悉的任务，结果可能不同，因为代码库探索会占据更大比例的工作。

因此，团队至少应区分四项指标。

实现吞吐量

统计已完成的补丁、变更行数或交付的任务单元。这些数字反映代理是否扩展了产出能力。

验证负担

衡量审查时间、测试失败、安全发现和修订周期次数。这些数字表明信任输出需要付出多少成本。

系统质量

跟踪事故、漏网缺陷、回滚率和维护工作。这些结果揭示更快的实现是否削弱了产品。

用户价值

衡量采用率、任务完成率、留存率或其他特定于产品的结果。这些信号表明新增软件是否真正产生了价值。

代码行数属于第一类指标。当组织将这一指标提升为通用生产力评分时，问题便随之开始。

这种区分也改变了管理者应如何解读个人产出。监督大型代理生成补丁的工程师，可能只写了很少的手工代码，却作出了有价值的架构贡献。另一位工程师可能产出更多代码，却制造了数月的清理工作。

统计代码行数可以揭示工厂发生的变化，却无法识别最优秀的工厂经理。

这些数字依然无法证明什么

最有力的怀疑论观点是，更高的代码量可能衡量的是被转移的劳动，同时掩盖了被转移的风险。

代理承担了输入、代码库搜索和初步调试。开发者则继承了理解结果的责任。若组织只统计生成量，它记录了节省的劳动，却忽略了额外增加的验证义务。

当代码存活的时间长于产生它的上下文时，这一问题会变得严重。原始提示词可能无法保留。即便保留了，提示词也很少能捕捉生成与审查过程中发现的每一项权衡。

未来的维护者面对的仍是普通源代码。他们必须推断其假设，区分刻意采用的模式与模型习惯，并安全地修改它。生产力仪表盘庆祝首次合并数月后，成本才会显现。

生成的测试同样需要谨慎对待。它们可以改善覆盖率并暴露遗漏的情况，也可能复刻实现本身的假设，为错误行为披上一层具有说服力的自动化确认。

文档也可能以相同方式失效。代理可以用清晰的文字描述代码当前的行为，但这种描述并不能证明该行为符合最初的产品需求。

问题关乎认识论，而不只是技术。团队需要知道自己为何相信某项变更是正确的。当测试源自同一种解读时，“代理生成了它，而且测试通过了”这项证据比初看时更薄弱。

独立检查会有所帮助。人类可以在实现前编写验收标准。另一位审查者可以检查行为而非风格。团队也可以使用不同的工具或提示词进行对抗性测试，同时记住第二个模型并非独立权威。

代码库规模带来了另一层不确定性。当代理能够识别相关上下文时，它们表现令人印象深刻；当关键约束横跨许多服务、私有运维知识或相互冲突的历史惯例时，其表现就更难预测。

更长的上下文窗口减少了检索阻力，却无法决定哪些信息应当优先。模型可以阅读多份设计文档，却仍可能无法识别哪项决策仍具权威性。

2025 年的 AI-assisted development report 将 AI 采用置于更大的交付系统之中。这才是正确的分析层次。工具使用会与文档质量、审查实践、平台工程和组织信任相互作用。

成熟团队可以将更强的实现能力转化为更快的实验和更短的队列。不成熟的团队则可能将同样的能力转化为更大的 pull request、更嘈杂的代码库和延迟暴露的失败。

这使得关于 AI 生产力的宽泛主张难以验证。结果取决于任务类型、开发者熟悉程度、模型行为、代码库健康状况以及反馈循环的质量。

Willison 的主张经得起这种批评，因为它并未要求代码行数证明一切。它要求这一指标记录一个历史性约束已经发生变化。

风险在于雇主如何解读这一观察。细致的工程信号很快可能变成配额。一旦如此，团队就会获得生成可见体量而非降低复杂性的激励。

正确的怀疑论结论并不是代码量毫无信息价值，而是当这一数字脱离审查成本、系统结果和概念完整性时，就会变得危险。

Anthropic Simon 争论之后该关注什么

下一阶段将由代码库结果决定，而不是越来越戏剧化的编程演示。

第一个信号是独立的任务级衡量。更多受控研究应比较熟悉与不熟悉的代码库、不同经验水平，以及多种代理工作流。结果应包括审查时间和缺陷，而不只是任务完成情况。

如果这些研究在计入验证成本后仍显示持久收益，Willison 关于吞吐量的论点将更有力。如果一旦把维护和审查纳入计算，收益便消失，那么代码量看起来就更像是被转移的工作。

第二个信号是变更规模和架构集中度。团队应观察，代理辅助开发究竟会产生更小、更聚焦的补丁，还是会产生横跨多个子系统的大范围变更。

更小的补丁表明开发者正在清晰边界内使用代理。更大的补丁则可能意味着生成能力正在超过组织维持连贯设计的能力。

第三个信号是代码库的长期健康状况。有用指标包括回滚频率、重复抽象、依赖增长、事故率，以及后续修改所需的时间。

如果这些指标均有所改善，将表明更多生成代码可以与概念完整性共存。若情况恶化，则会支持这样的担忧：代理创建软件的速度快于团队真正吸收它的速度。

这些信号比单独的基准测试分数更重要。模型可以更擅长解决孤立的编程问题，却未必更擅长理解一家公司的演进中架构。

开发者应将代理输出视为实现方案。为工具提供边界明确的任务、明确的约束和可靠的测试。在润色生成代码前，先审查设计决策。

工程领导者应抵制简单的产出配额。他们可以将变更行数作为新能力的一项指标，但应同时考量验证投入、生产结果和用户价值。

工程领域之外的知识工作者也应关注这一点。软件日益介入内部运营、分析和客户体验。更便宜的代码可以扩大团队自动化的范围，同时也会扩大他们必须理解的系统。

Anthropic Simon 的讨论最终重新框定了 AI 编程，并未否认任何一方的证据。代理能够产出远多于个人过去能够输入、测试和调试的实现代码。这是真实的生产力转变。

尚未解决的问题是，组织能否将这种能力转化为连贯的软件。请关注代码生成之后发生的事情：谁来审查它，哪些假设得以保留，以及下一位开发者是否仍能解释这个系统。