Claude Code重写Claude App：AI编程代理的能力边界在哪里

引言：当AI编程工具挑战自身

Anthropic的Claude Code核心开发者Boris Cherny分享了一个颇具话题性的实验——尝试用Claude Code去重写Claude App本身。这个看似简单的想法背后，触及了当前AI编程工具最本质的问题：一个AI编码代理，究竟能在多大程度上处理真实、复杂、大规模的生产级代码库？

这不仅是一次技术演示，更是一场对AI编程能力边界的压力测试。用工具重构生成它的产品，本身带有"自我迭代"的意味，也让整个行业得以窥见AI辅助编程从"玩具级"走向"工程级"的真实差距。

Claude Code是什么：从补全到代理的跃迁

Claude Code是Anthropic推出的命令行AI编程代理（agentic coding tool），它不同于传统的代码补全插件，而是能够以"代理"模式自主执行多步骤的编程任务。

传统AI编程助手（如早期的代码补全工具）本质上是"被动"的——你写一行，它猜下一行。而Claude Code这类代理型工具则是"主动"的：你给出一个目标（例如"给这个模块添加单元测试"或"重构这段逻辑"），它会自主阅读代码库、理解上下文、编辑多个文件、运行命令并根据反馈调整。

代理型AI编程工具的技术基础

Claude Code之所以能以"代理"模式运行，依赖于大语言模型（LLM）的几项关键能力突破。首先是工具调用（Tool Use/Function Calling）能力，模型可以自主决定何时调用外部工具，如文件读写、终端命令执行、代码搜索等；其次是规划与推理能力，模型能将复杂任务分解为可执行的子步骤，并在执行过程中动态调整计划；最后是长上下文窗口的支持，Claude模型支持200K token的上下文，使其能一次性"阅读"大量代码文件。

这种架构通常被称为ReAct（Reasoning + Acting）范式——模型在思考和行动之间交替循环，每一步都基于前一步的观察结果做出下一步决策，形成一个持续的"思考→行动→观察→再思考"的循环。ReAct范式由Yao等人在2022年提出，其核心洞察是：单纯的推理（如Chain-of-Thought）缺乏与外部环境交互的能力，而单纯的行动（如直接调用API）缺乏深思熟虑的规划。将两者交织在一起，模型可以在推理中引导行动的方向，又能从行动的结果中获取新的信息来修正推理。在Claude Code的具体实现中，这意味着模型可能先"思考"需要了解某个函数的实现细节，然后"行动"去读取对应文件，"观察"文件内容后再"思考"下一步应该如何修改，形成一个可能持续数十轮的自主工作循环。

值得注意的是，工具调用能力的实现并非简单地在提示词中嵌入工具描述。现代LLM通常经过专门的微调（fine-tuning）来学习何时、如何调用工具，训练数据中包含大量工具使用的示例对话。模型需要学会判断：当前任务是否需要外部工具介入，需要哪个工具，以及如何正确构造工具调用的参数。这种能力的鲁棒性直接决定了代理型工具的可靠性——如果模型频繁误调用工具或传入错误参数，整个代理循环就会崩溃。

这种能力上的跃迁，使得"让AI重写整个App"这样的宏大任务从理论上变得可能。但正如Cherny的实验所揭示的，理论上的可能与工程上的可行之间，仍存在不小的鸿沟。

重写Claude App的实验难在哪里

让Claude Code重写Claude App，是一个典型的"自举"（bootstrapping）式挑战。

自举概念的计算机科学渊源

自举在计算机科学中有深厚的历史渊源。最经典的案例是编译器的自举：第一个C语言编译器最初用汇编语言编写，一旦它能编译C代码，就可以用C语言重写编译器自身，然后用旧编译器编译新编译器的源码，从而实现"自我编译"。类似地，GCC、Rust编译器、Go编译器等都经历过自举过程。这种模式的核心价值在于：如果一个工具足够强大到能够创建或改进自身，就证明了它的通用性和成熟度。

自举的思想甚至可以追溯到更早的理论计算机科学。图灵在1936年提出的通用图灵机概念，本身就蕴含了"计算系统描述和模拟自身"的思想。在实践层面，Ken Thompson在1984年图灵奖演讲"Reflections on Trusting Trust"中展示了编译器自举的深层安全隐患——如果在自举过程中植入后门，后续所有由该编译器编译的程序都可能被感染，即使审查源代码也无法发现问题。这个经典案例提醒我们，自举虽然证明了工具的强大能力，但也带来了信任链条的复杂性问题。

Claude Code重写Claude App虽然不是严格意义上的自举（它不是在重写自己的源代码），但具有相似的哲学意味——用AI编程工具去处理AI产品的代码库，是对工具能力的终极信任测试。更准确地说，这是一种"准自举"：Claude Code（编程代理）和Claude App（用户界面应用）共享同一底层模型，但属于不同的产品层，如果Claude Code能成功重写Claude App的前端和后端服务代码，就意味着AI编程工具已经具备处理自身生态系统复杂性的能力。

这个任务的难度体现在以下几个层面。

大规模代码库的理解挑战

一个成熟的应用往往包含数十万行代码、复杂的依赖关系和历史遗留的技术债务。AI代理需要在有限的上下文窗口内理解整个系统的架构，这对模型的长上下文处理能力和代码理解能力都是极大考验。当代码库规模超过模型的"认知带宽"时，代理容易出现局部正确、全局失控的情况。

上下文窗口与代码理解的技术瓶颈

即便Claude拥有200K token的上下文窗口（约相当于15万词或数百页文档），面对真实的大型代码库仍然捉襟见肘。一个中等规模的生产级应用可能包含数十万到数百万行代码，远超任何模型的单次处理能力。为应对这一限制，代理型工具通常采用RAG（检索增强生成）策略——先通过代码搜索、AST（抽象语法树）解析、依赖图分析等方式检索相关代码片段，再将其注入上下文。

AST（抽象语法树）是编译器前端的核心数据结构，它将源代码的语法结构表示为树形结构，每个节点代表一个语法构造（如函数定义、条件判断、循环等）。在AI编程工具中，AST解析的价值在于它提供了比纯文本更结构化的代码理解——工具可以通过AST快速定位函数定义、追踪变量引用、识别模块间的导入关系，而不必依赖模型自身对文本的理解。结合依赖图（Dependency Graph）分析，工具可以构建出"如果修改了模块A，哪些模块B、C、D可能受到影响"的传播链，从而帮助AI代理在重构时不遗漏相关联的代码。

此外还有"代码地图"（codebase map）技术，即让模型先建立对整体架构的摘要理解，形成文件级和模块级的功能索引，再按需深入具体模块获取细节。这类似于人类工程师接手新代码库时的认知过程：先浏览目录结构和README获取全局观，再根据具体任务深入相关模块。一些工具（如Aider）会自动生成仓库的"树状摘要"（tree-sitter based map），列出每个文件的类和函数签名，让模型在不阅读完整代码的情况下就能把握整体结构。

但这些方法都面临信息损失和注意力分散的问题——模型可能遗漏关键的跨模块依赖，或者对远距离的代码耦合关系缺乏感知，这也是为什么AI在大型代码库中容易出现"局部正确、全局失控"的现象。研究表明，即便在200K token的上下文中，模型对中间位置信息的注意力也会显著下降（即"lost in the middle"现象），这意味着即使相关代码被检索并放入上下文，模型也可能因为注意力分配的偏差而忽略它。

生产级质量的门槛

重写一个真实产品，不同于生成一个演示Demo。它要求生成的代码不仅能运行，还要保持原有功能不退化、性能不下降、边界情况得到妥善处理。这要求AI具备工程师级别的严谨性，而不仅仅是"写出看起来正确的代码"的能力。

在软件工程中，这种要求被称为"功能等价性"——新代码必须在所有输入输出组合下与旧代码表现一致，包括那些文档中未明确记录但用户已经依赖的隐性行为。这种隐性行为在软件工程中被称为"Hyrum's Law"（海勒姆定律），由Google工程师Hyrum Wright提出：当一个API有足够多的用户时，API的所有可观察行为（无论是否在合约中承诺）都会被某些用户所依赖。这意味着即便是看似无关紧要的实现细节——如错误消息的具体措辞、返回列表的默认排序、超时时间的精确值——在重写时都可能导致下游系统的兼容性问题。

对于AI代理而言，这类隐性约束是最难以自动发现的。它们通常不存在于代码注释或文档中，而是隐藏在集成测试、用户反馈历史和生产环境的监控数据中。这也解释了为什么"AI写的代码看起来对，但部署后就出问题"是一个常见的投诉——模型可以生成语法正确、逻辑通顺的代码，但无法感知那些未被显式编码的"系统记忆"。

编写—测试—修正的闭环验证

真正有价值的AI编程代理，必须能形成"编写—测试—修正"的完整闭环。Cherny的实验实际上是在检验：当代码出错时，Claude Code能否自主发现问题、定位根因并修复，而不是把烂摊子留给人类开发者。

这种能力要求模型不仅能生成代码，还要能理解测试失败的错误信息、分析堆栈追踪、推断出错误的根本原因，并生成有针对性的修复——整个过程可能需要多轮迭代才能收敛到正确的解决方案。在实践中，这个闭环的成功率取决于几个关键因素：测试覆盖率的充分性（是否有足够的测试来捕获回归）、错误信息的信息量（模糊的错误提示会使AI难以定位问题），以及修复搜索空间的大小（简单的类型错误容易修复，但涉及架构设计缺陷的问题可能需要推翻重来）。

值得注意的是，这个闭环中隐含着一个"收敛性"问题：如果AI的修复引入了新的bug，然后对新bug的修复又引入更多bug，整个过程就会发散而非收敛。经验表明，当前的AI代理在简单到中等复杂度的bug修复中通常能在3-5轮迭代内收敛，但面对涉及多个相互依赖组件的复杂bug时，发散的风险显著增加。高效的代理设计需要内置"回退机制"——当检测到修复在发散时，能够回滚到之前的稳定状态并尝试完全不同的修复策略。

这场实验对AI编程行业的启示

虽然公开细节有限，但这次实验折射出当前AI编程领域几个值得关注的趋势。

AI工具自我改进的飞轮效应

用AI工具改进AI工具本身，是通往更强能力的重要路径。如果Claude Code能有效参与Claude App的开发，意味着开发效率的复利式增长——工具变强，产品变好，产品又反哺工具的训练数据，形成正向飞轮。

飞轮效应（Flywheel Effect）概念来自吉姆·柯林斯的《从优秀到卓越》，描述的是一个自我强化的正反馈循环。在AI领域，这个概念有了更深层的含义：如果AI工具能参与改进自身或其底层产品，就可能产生"递归式自我改进"（recursive self-improvement）。具体到Anthropic的场景，这个飞轮可以描绘为：Claude Code辅助开发Claude App → 产品体验提升带来更多用户和使用数据 → 更丰富的交互数据反哺模型训练和对齐 → 模型能力提升使Claude Code更强 → 更强的Claude Code能更好地辅助开发。这一循环虽然每一步的增量有限且存在衰减，但持续运转可产生显著的复利效应。

从AI安全的角度看，递归式自我改进也是一个被广泛讨论的风险因素。如果AI系统能持续改进自身能力而人类无法充分理解每一步改进的后果，可能导致能力增长超出人类监督能力的情况。Anthropic作为一家将AI安全作为核心使命的公司，在推进这类飞轮的同时，也需要确保每一步改进都在可理解、可审计的范围内。这也是为什么他们采用了"Constitutional AI"（宪法AI）等对齐方法，试图让AI系统在自我改进的同时保持对人类价值观的遵循。

OpenAI、Google DeepMind等公司也在内部大量使用自家AI辅助代码编写和研究工作，本质上都在追求类似的飞轮。据公开信息，OpenAI内部约有相当比例的代码提交涉及AI辅助，Google的内部工具链也深度整合了Gemini模型的代码建议能力。这种"AI辅助AI开发"的模式正在成为顶尖AI实验室的标准实践。

人机协作编程才是当前最优解

目前的现实是，即便最先进的编程代理，也更适合作为"高能力的助手"而非"独立的工程师"。它擅长处理明确定义的、边界清晰的任务，但在需要架构决策、权衡取舍和领域直觉的场景中，人类工程师的价值依然不可替代。这类实验的意义，在于不断探明人机分工的边界线究竟在哪里。

从工程实践角度看，当前最有效的人机协作模式呈现出明显的分层结构：人类负责系统设计、需求拆解和关键决策，AI代理负责具体实现、测试编写和重复性重构。人类工程师的角色正在从"代码编写者"向"AI工作流的编排者和审查者"转变——他们设定方向、拆分任务、审查AI的输出质量，并在AI遇到模糊性时提供判断。

这种协作模式可以类比为"建筑师与施工队"的关系：建筑师负责整体设计、关键结构决策和美学判断，施工队（AI代理）负责按图施工、处理大量具体的建造工作。但与真实的建筑行业不同，AI"施工队"偶尔会自作主张地修改设计（生成不符合架构意图的代码），或者在遇到图纸模糊时做出错误假设，因此"建筑师"（人类工程师）需要保持频繁的检查和校正。

这种模式在一些场景下已经能将开发效率提升数倍，但前提是人类工程师对代码库有足够深的理解，能够快速识别AI输出中的微妙错误。一个值得关注的悖论是：如果工程师过度依赖AI生成代码而减少了自身对代码库的深度理解，那么他们审查AI输出的能力也会退化，最终可能导致质量问题被延迟发现——这被一些研究者称为"自动化讽刺"（Irony of Automation），即自动化系统越可靠，操作者越疏于监督，而当系统偶尔出错时，操作者反而越来越难以发现和纠正错误。

内部Dogfooding：最严苛的产品检验

用Claude Code重写Claude App，本质上是一种极为严苛的"内部dogfooding"（吃自家狗粮）。开发团队亲自用自己的产品去攻克自己产品的开发难题，能最直接地暴露工具的短板，这也是许多顶尖工程团队推崇的产品打磨方式。

Dogfooding这一术语源自1980年代的微软，当时的经理Paul Maritz发送了一封标题为"Eating our own dog food"的邮件，鼓励团队更多使用自家正在开发的产品。此后这一实践成为科技公司的核心文化：Google员工长期使用早期版本的Gmail和Chrome，Meta员工被要求使用自家的内部协作工具，Apple工程师在新iPhone发布前数月就开始日常使用原型机。

Dogfooding的价值在于它创造了一个"痛感反馈环路"——当开发者本身就是用户时，产品的痛点会被直接、频繁、强烈地感知到，修复的优先级也会自然提升。这与依赖外部用户反馈的模式形成鲜明对比——外部反馈通常经过了客服、产品经理等多层过滤和延迟，到达开发者时可能已经失真或降温。

对于AI编程工具而言，dogfooding尤其有价值——因为AI产品的能力边界模糊、失败模式难以预测，标准化的benchmark测试往往无法覆盖真实使用中的复杂场景。只有在真实高压的工程任务中持续使用，才能发现那些合成测试无法揭示的深层问题，比如在多文件重构中丢失上下文、在并发代码中引入竞态条件、或者在处理遗留代码时做出不兼容的假设等。此外，dogfooding还能帮助团队发现那些"死于千刀"的体验问题——单独看每一个小问题都不致命，但累积起来严重损害了工具的可用性和信任度，这类问题在标准化测试中几乎不可能被捕获。

结语：AI编程正从辅助走向参与

Boris Cherny的这次实验，为我们提供了一个观察AI编程能力真实水平的珍贵窗口。它提醒我们：AI编程正从"辅助写代码"迈向"参与做工程"的新阶段，但距离完全自主的软件工程仍有相当距离。

这个"相当距离"可以从多个维度理解：当前最先进的AI编程代理在SWE-bench等标准化基准测试中的解决率已经超过50%，但这些测试题通常是边界清晰的bug修复或功能添加任务。SWE-bench是由普林斯顿大学研究者创建的基准测试集，从真实的GitHub开源项目中收集了2294个实际的Issue-Pull Request对，每个任务都要求AI系统在真实代码库中定位问题并生成正确的修复补丁。这一基准测试之所以受到广泛关注，是因为它比传统的代码生成基准（如HumanEval）更贴近真实工程场景——模型不仅需要写出正确的代码，还需要理解issue描述、在大型仓库中定位相关文件、理解现有测试逻辑，并生成通过所有测试的补丁。2024年初，最好的AI系统在SWE-bench上的解决率不到5%，而到2025年中已超过50%，这一跃升反映了代理型工具在代码理解和多步推理方面的快速进步。

面对真实工程中的模糊需求、跨团队协调、渐进式架构演化等挑战，AI的表现仍然远不及经验丰富的工程师。这些挑战的本质在于它们涉及大量的隐性知识（tacit knowledge）——那些存在于工程师头脑中但从未被写入文档的理解，如"为什么这里选择了这个设计模式""这个看似冗余的检查是为了防止两年前那个线上故障的重现""这个API的命名虽然不够优雅但为了保持向后兼容不能改"等等。这些知识目前很难被AI系统捕获和利用。

然而，进步的速度同样惊人——一年前的AI编程工具还主要停留在单文件级别的代码生成，如今已经能够处理跨多文件的复杂重构任务。如果这一进步速度持续，我们可以合理预期在未来2-3年内，AI编程代理将能独立完成中等复杂度的功能开发任务（如开发一个完整的CRUD模块或集成第三方服务），而人类工程师的介入点将进一步上移到更高层次的系统设计和产品决策层面。

对于开发者而言，与其纠结AI是否会取代自己，不如思考如何更好地驾驭这类工具，将自己从重复劳动中解放出来，专注于更高维度的架构设计与创造性工作。而对于像Anthropic这样的公司来说，敢于用自家工具挑战自家产品，本身就是对技术自信与产品诚意的最好证明。