解码 Claude Code（七）— 深度报告：三个真实项目的完整复盘

前六期我们拆解了 Claude Code 的每一个核心模块。这一期，我们走进真实项目——不谈理论，只看结果。

三个案例来自 Anthropic 工程团队和社区开发者的第一手报告。它们规模不同、领域不同，但都回答了同一个问题：当 Claude Code 真正"上阵"的时候，会发生什么？

案例一：16 个 Claude 并行写 C 编译器

项目概况

2026 年 2 月，Anthropic 安全团队研究员 Nicholas Carlini 做了一个疯狂的实验：用 16 个 Claude 实例并行开发一个 C 编译器，目标是可以编译 Linux 内核。

最终结果：

  • 代码量：100,000 行 Rust
  • 会话数：近 2,000 个 Claude Code 会话
  • Token 消耗：20 亿输入 + 1.4 亿输出
  • 成本：约 20,000 美元
  • 能力：能编译 Linux 6.9（x86/ARM/RISC-V）、QEMU、FFmpeg、SQLite、PostgreSQL、Redis
  • 测试通过率：GCC torture test 套件 99%

这不是 demo，不是原型——这是一个能编译 Doom 的编译器。

架构设计：最简并行方案

Carlini 没有设计复杂的编排系统。整个架构只有三个组件：

1. 无限循环（Ralph Loop）

#!/bin/bash
while true; do
  COMMIT=$(git rev-parse --short=6 HEAD)
  LOGFILE="agent_logs/agent_${COMMIT}.log"
  claude --dangerously-skip-permissions \
    -p "$(cat AGENT_PROMPT.md)" \
    --model claude-opus-X-Y &> "$LOGFILE"
done

Claude 完成一个任务，立即开始下一个。它没有选择——循环永远不会停（除非 Claude 不小心执行了 pkill -9 bash 把自己杀了，这确实发生过一次）。

2. Git 文件锁实现任务分配

每个 agent 在 current_tasks/ 目录下创建文件来"锁定"任务。如果两个 agent 抢同一个任务，Git 的同步机制会强制第二个选别的。没有中心调度器，没有消息队列——就是文件系统 + Git。

3. 容器化隔离

每个 agent 运行在独立的 Docker 容器里，各自 clone 代码到本地，完成后 push 到上游仓库。合并冲突频繁发生，但 Claude 有能力自行解决。

关键发现

测试质量决定上限。 Carlini 反复强调：Claude 会不遗余力地解决你给它的任何问题，所以测试套件必须近乎完美，否则 Claude 会解错题。

他发现 Claude 会不断用新功能破坏已有功能，于是搭建了 CI 流水线，强制每次提交不能 break 现有测试。测试不是给自己写的——是给 Claude 写的。

站在 Claude 的角度设计工具。 测试输出不能刷屏（会污染上下文窗口），错误信息必须一行就能 grep 到（ERROR: 具体原因），日志要预计算汇总统计（免得 Claude 自己算一遍浪费时间）。

Claude 还有个致命弱点：无法感知时间。不加限制的话，它会花几个小时跑测试，而不是推进开发。解决方案是 --fast 模式：只跑 1%-10% 的随机抽样，既覆盖全部文件，又能快速定位回归。

并行不是银弹。 当所有 agent 面对同一个大问题时（比如编译 Linux 内核），16 个 agent 会卡在同一个 bug 上，互相覆盖修复。Carlini 的解法很巧妙：用 GCC 作为"对照编译器"，随机分配文件给 GCC 和 Claude 的编译器，通过二分法定位哪些文件有问题，从而让不同 agent 修复不同 bug。

碰到的天花板

这个项目也暴露了 Opus 4.6 的极限：

  • 无法实现 16 位 x86 代码生成器（输出的代码超过 Linux 的 32K 限制）
  • 生成的代码效率远低于 GCC（即使开了全部优化，还不如 GCC 关优化）
  • Rust 代码质量合理，但远达不到专家水平
  • 新功能和修复经常破坏已有功能

Carlini 的总结很诚实：这个编译器"已经达到了 Opus 能力的极限"。

教训提炼

维度 教训
测试 测试不是验证工具，是导航工具。没有好测试，agent 会迷路
并行 任务独立时并行是免费的，任务耦合时并行反而有害
成本 2 万美元听起来贵，但比一个团队几个月的人力便宜一个数量级
架构 最简方案（文件锁 + Git）往往优于复杂编排系统
局限 即使是最强的模型，在专家级任务上仍有明显天花板

案例二：GAN 启发的三代理全栈开发

项目概况

2026 年 3 月，Anthropic Labs 团队的 Prithvi Rajasekaran 公开了一项研究：如何让 Claude 自主完成复杂的前端设计和全栈应用开发。

他的灵感来源出人意料——生成对抗网络（GAN）。

在 GAN 里，生成器负责产出，判别器负责挑剔。Rajasekaran 把这个结构搬到了 AI 编程中：一个 agent 写代码，另一个 agent 审代码，两者对抗迭代，直到质量达标。

从前端设计开始

问题很明确：Claude 默认倾向于产出"安全但无聊"的布局——技术上能用，但视觉上毫无记忆点。

Rajasekaran 设计了四个评分维度：

维度 权重 核心问题
设计品质 高 看起来是一个整体，还是零件拼凑？
原创性 高 有刻意的设计决策，还是模板默认值？
工艺 中 排版层级、间距一致性、色彩和谐度
功能性 中 用户能不能不猜就完成任务？

前两个权重更高，因为工艺和功能性 Claude 本来就做得不错，真正缺的是审美上的冒险。

然后他构建了对抗循环：

生成器：根据提示创建 HTML/CSS/JS
    ↓
评估器：用 Playwright 打开页面，截图、导航、逐维度打分、写详细批评
    ↓
生成器：根据批评修改，或彻底转向新的美学方向
    ↓
重复 5-15 轮

关键细节：评估器不是看静态截图打分，而是真的打开浏览器导航页面、截图、仔细研究后再评分。每轮迭代都有真实的墙钟时间，完整运行最长可达四小时。

最精彩的一刻

Rajasekaran 让 Claude 为一个荷兰艺术博物馆设计网站。前九轮迭代产出了一系列干净但中规中矩的暗色主题页面。

然后第十轮，Claude 推翻了之前所有的方向，重新想象了这个网站——它变成了一个空间体验：用 CSS perspective 渲染的 3D 房间，棋盘格地板，画作以自由位置挂在墙上，通过门道在画廊房间之间导航。

这是单次生成不可能出现的创意飞跃。

扩展到全栈开发

验证了生成器-评估器模式后，Rajasekaran 将其扩展为三代理系统：

规划器（Planner）：接收 1-4 句话的用户描述，扩展为完整产品规格。关键约束——只描述"做什么"和"为什么"，不规定"怎么做"。因为如果规划器在技术细节上猜错了，错误会级联传播到下游。

生成器（Generator）：按功能一个接一个地实现（sprint 模式）。每个 sprint 结束后自我评估，然后交给评估器。技术栈固定：React + Vite + FastAPI + SQLite（后换为 PostgreSQL）。

评估器（Evaluator）：不只是看代码——它打开应用，实际操作每个功能，记录 bug，写报告反馈给生成器。这一次，评估器真的在"使用"软件，而不是在"读"代码。

解决的三个核心问题

问题一：上下文腐烂。 长时间运行后，agent 开始遗忘早期指令，做出矛盾决策。早期用 Sonnet 4.5 时特别严重（"上下文焦虑"——模型会提前结束工作）。Opus 4.5 基本消除了这个问题，配合自动 compaction 就够了。

问题二：自我评价偏差。 Agent 对自己产出的评价几乎总是正面的——即使明显平庸。把评价者和生产者分开后，评价可以校准为"挑剔"风格，而生成器有了具体的改进目标。

问题三：长任务失控。 将完整应用拆解为逐功能 sprint，每个 sprint 有明确的起止和验证条件。这比"一口气写完整个应用"靠谱得多。

教训提炼

维度 教训
评估 分离生成和评估是质量的关键杠杆
迭代 5-15 轮对抗迭代远优于单次生成
规划 规划器应约束"做什么"而非"怎么做"
创意 允许 agent 推翻方向，可能产生意外突破
成本 每次完整运行可达 4 小时，但产出质量显著高于一次性生成

案例三：Managed Agents — 从宠物到牲畜

项目概况

前两个案例都是研究实验。第三个案例是真正的生产系统——Anthropic 的 Managed Agents 托管服务。

这个故事的核心不是 Claude 多聪明，而是如何设计一个能持续运行的 AI agent 基础设施。

"宠物"问题

最初的架构很直觉：把所有东西塞进一个容器——Claude、运行 harness、执行沙箱、会话记录。

问题很快暴露：

  • 容器挂了 = 会话丢了（而且没地方调试）
  • harness 假设所有资源都在旁边（客户要求连接自己的 VPC 时就傻了）
  • 安全隐患：Claude 生成的不可信代码和密钥在同一个容器里（一次提示注入就能拿到 token）

这就是经典的"宠物"问题——你精心照料它，它挂了你很难受。

解耦方案："大脑"和"手"

Anthropic 的解法来自操作系统设计哲学：像 Unix 把硬件抽象为文件一样，把 agent 组件抽象为接口。

大脑（Brain）= Claude + harness，负责思考和决策
手（Hands）= 沙箱和工具，负责执行
会话（Session）= 事件日志，独立存储

三者通过极简接口连接：

大脑 → 手：execute(name, input) → string
大脑 → 会话：emitEvent(id, event)
会话 → 大脑：getSession(id) / getEvents()

这意味着：

  • 容器挂了？大脑捕获错误，Claude 决定是否重试，新容器按标准配方重建
  • harness 挂了？新 harness 启动，从会话日志恢复，继续上次的事件
  • 客户要连接自己的 VPC？大脑不需要知道手在哪里，只需要调 execute

性能飞跃

解耦带来了意外收获：

  • 首 token 延迟（TTFT）中位数降低 60%，p95 降低超过 90%
  • 原因：之前每个会话都要等容器启动完成才能开始推理；现在推理可以先开始，容器按需创建

安全架构

密钥永远不出现在沙箱里：

  • Git 操作：sandbox 初始化时用 token clone 仓库，配置本地 git remote，之后 push/pull 不需要 token
  • MCP 工具：OAuth token 存在安全保险库，通过专用代理调用，harness 和沙箱都碰不到凭据
  • 原则：Claude 能"用"权限，但永远"看不到"凭据

教训提炼

维度 教训
架构 解耦大脑和手，让每个组件可以独立失败和替换
接口 设计少量稳定的抽象接口，比优化任何单一实现更重要
安全 凭据永远不应存在于不可信代码可达的地方
性能 延迟来自不必要的等待，而非计算本身
演进 为"尚未想到的程序"设计系统，接口比实现更持久

三个案例的共同脉络

把三个项目放在一起看，你会发现它们在说同一件事：

规律一：反馈闭环是第一生产力

C 编译器项目靠 CI 测试套件闭环，前端设计靠评估器打分闭环，Managed Agents 靠会话日志 + 错误恢复闭环。

没有闭环的 agent 就像没有方向盘的车——动力再强也没用。闭环越精确、越自动化，agent 的表现就越好。

规律二：管理上下文 = 管理 AI 的"智商"

C 编译器项目用 Git 文件锁隔离任务上下文，前端项目用三代理分工隔离角色上下文，Managed Agents 用会话日志解耦存储上下文。

三个项目的核心挑战都是同一个：随着任务变长，上下文窗口会被垃圾填满，模型的注意力被分散，性能下降。解决方案不是更大的上下文窗口——而是更聪明的上下文隔离。

规律三：最简架构往往赢

C 编译器没有复杂编排，只有文件锁 + Git。前端项目没有微服务，只有三个 agent + 一个循环。Managed Agents 的核心就是三个接口。

这不是巧合。在 AI agent 领域，模型的智力在飞速增长，但 harness 编码的假设会迅速过时。越简单的架构，越容易适配新一代模型。

规律四：评估比生成更难

三个项目都花了大量精力在"怎么评判结果好不好"上——而不是"怎么让 Claude 写出结果"。

C 编译器的测试套件、前端项目的四维评分体系、Managed Agents 的会话恢复机制——这些才是真正的工程挑战。生成代码 Claude 已经很擅长了，但告诉它"你做得好不好"仍然需要人类精心设计。

用户的真实感受

社区开发者 @svpino 在用 Claude Code 构建了一个完整的 SaaS 应用后写道：

"我用 Claude Code 写了一个从前端到数据库的完整应用。期间我只做了一件事：坐在旁边看它工作，偶尔在它走偏的时候拉一下。这种感觉就像你在驾驶一辆自动驾驶汽车——你知道它大部分时间在正确行驶，但你随时准备接管方向盘。"

另一位开发者 @swyx 的总结更精炼：

"Claude Code 改变的不是你写代码的速度，而是你思考代码的方式。你不再想'怎么实现这个功能'，而是想'怎么描述这个功能才能让 AI 做对'。这是一个元认知层面的转变。"

展望：从工具到伙伴

三个案例揭示了一个趋势：Claude Code 正在从"工具"进化为"伙伴"。

C 编译器项目展示了它的极限能力——在结构良好的环境里，它已经可以完成专家级的工程任务。前端项目展示了它的创意潜力——在对抗迭代的驱动下，它能做出超越预期的设计决策。Managed Agents 展示了它的工程成熟度——在生产环境里，它已经可以作为可靠的基础设施运行。

但所有案例也指向同一个瓶颈：AI 仍然需要一个精心设计的环境才能发挥最大潜力。测试、评估、反馈、上下文管理——这些"脚手架"决定了 AI 的天花板。

下一期，也是本系列的最后一期，我们将跳出具体案例，看看 AI 编程的未来。Karpathy 预言的 Software 3.0 时代，Boris Cherny 心中的终极开发体验，以及 Anthropic 对 AI 编程的长期愿景。

系列导航

参考来源

Views: 3

其他关联文章:

  1. 解码 Claude Code（六）— 实战技巧：从 Boris 和团队偷师的 30 条黄金法则
  2. 解码 Claude Code（五）— 多代理协作：从单兵作战到 AI 军团
  3. Git钩子与自动化：让代码质量自动守护
  4. 解码 Claude Code（四）— 技能系统：用 Markdown 打造可复用的 AI 能力

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

内容大纲

← Index