前言：一个让整个开发者社区炸锅的数字

9天，100万行 Rust 代码，6755 次提交。

这是 Bun 团队用 Claude Code 智能体完成的「史上最大 AI 重构」的成绩单。消息一出，Hacker News 直接炸了，讨论帖 708 分热度，PR 的点赞和点踩几乎各占一半。

说实话，当我第一次看到这个数字的时候，第一反应不是「AI 太强了」，而是——为什么我用 Claude Code 写个稍微复杂点的项目，连 Demo 都撑不过去？

后来我想明白了。问题不在 Claude Code，而在我自己。

你的 Claude Code 为什么只能写 Demo？

说几个你大概率踩过的坑：

坑一：每次开新会话，AI 就失忆。 上次说好用 Fastify，这次它又给你生成 Express。你提醒它，它说「好的我记住了」，下次还是忘。这不是模型的问题，是你没给它「记忆」。

坑二：代码风格飘忽不定。 一会儿用 async/await，一会儿用 .then()，变量命名昨天 camelCase 今天 snake_case。CI 跑一次挂一次，PR 被打回来三次。

坑三：稍微大点的代码库就迷路。 项目超过几千行，Claude Code 开始「选择性失明」——明明前面定义过的函数，后面又重新写了一个功能差不多的。重复代码越来越多，架构逐渐失控。

这三个问题的共同根源是什么？

你只把 Claude Code 当成了一个高级聊天窗口，而不是一个需要工程化管理的开发工具。

Harness Engineering：2026 年的新共识

2025 年是 Vibe Coding 的狂欢期。大家发现「凭直觉 + AI」就能快速搞出 Demo，效率爆表。

但 2026 年，风向变了。

企业开始关注一个词：Harness Engineering（驾驭工程）。核心思想很简单——

Agent = Model + Harness

模型本身只负责生成文本。真正让它能读文件、执行命令、管理上下文的，是包裹在模型外面的那层「编排框架」——也就是 Harness。

这里有一个反直觉的结论：

同一个模型在不同 Harness 下的表现差异，远大于不同模型在同一 Harness 下的表现差异。

换句话说，你花时间优化 Harness，比你换一个更贵的模型，收益大得多。

Claude Code 的四层架构

Claude Code 的技术栈可以抽象成四层大楼：

第一层：记忆层 —— CLAUDE.md 是基石

这是最关键、也是最容易被忽略的一层。

CLAUDE.md 就是给 Claude Code 写的「项目说明书」。它不是可选的，它是必须的。

# CLAUDE.md 示例

## 技术栈
- 前端：React 18 + TypeScript
- 后端：Fastify（不要用 Express）
- 数据库：PostgreSQL 15
- 包管理：pnpm（不要用 npm）

## 代码规范
- 变量命名：camelCase
- 组件命名：PascalCase
- 所有 API 必须有错误处理
- 禁止使用 any 类型

## 项目结构
- src/components/ — React 组件
- src/api/ — 后端接口
- src/utils/ — 工具函数

三问框架：WHY、WHAT、HOW

写 CLAUDE.md 的时候，只记录 AI 无法自行推断的信息：

• WHY：为什么选这个技术栈？（团队决策，不是技术问题）
• WHAT：项目的核心约束是什么？（不能用 xxx，必须用 yyy）
• HOW：具体执行规范是什么？（命名规则、目录结构、测试要求）

别写废话。别写 AI 已经知道的东西。「少即是多」原则——信息过载会消耗宝贵的 Token，反而让效果变差。

第二层：扩展层 —— Commands、Skills、SubAgents、Hooks

这四个组件是正交的，各管各的：

• Commands：自定义命令，比如 /deploy、/test
• Skills：可复用的技能模块
• SubAgents：子智能体，实现上下文隔离。大项目拆成多个子任务，每个子任务用独立的 SubAgent 处理，避免上下文溢出
• Hooks：防御性编程的关键。在代码生成前后插入检查逻辑，比如自动 lint、自动测试

第三层：集成层 —— Headless 模式 + MCP

Headless 无人值守模式：让 Claude Code 在 CI/CD 管道里自动运行，不需要人盯着。

MCP（Model Context Protocol）：连接外部世界的桥梁。数据库、API、文件系统——通过 MCP，Claude Code 可以直接操作它们。

第四层：编程层 —— Agent SDK

从使用者变成构建者。用 Agent SDK 构建自己的 AI 工具链。

实战：如何让 Claude Code 接管一个真实项目

说了这么多理论，来点实操。

Step 1：初始化项目上下文

# 在项目根目录创建 CLAUDE.md
touch CLAUDE.md

# 让 Claude Code 自己分析项目并填充内容
claude "请分析这个项目的结构和技术栈，生成 CLAUDE.md 的初始内容"

Step 2：配置五层记忆体系

项目级：CLAUDE.md（团队共享，提交到 Git）
用户级：CLAUDE.local.md（个人偏好，不提交）
会话级：当前对话上下文
工具级：MCP 连接的外部资源
运行时级：SubAgent 的临时上下文

Step 3：用 Hooks 构建防御

{
  "hooks": {
    "postGenerate": "npm run lint && npm run test:unit"
  }
}

每次 Claude Code 生成代码后，自动跑 lint 和单测。不过关的代码，直接打回。

Step 4：用 SubAgent 处理大任务

# 把一个大功能拆成多个子任务
claude "把用户认证模块拆成三个子任务：注册、登录、JWT 中间件，分别用 SubAgent 处理"

每个 SubAgent 有独立的上下文，互不干扰。这就是 Bun 团队处理百万行代码库的秘诀——不是让一个 AI 一口气写 100 万行，而是用大量子任务并行推进。

Bun 案例的教训：99.8% 通过率 ≠ 安全

回到 Bun 的案例。

99.8% 的测试通过率确实惊人，但这里有个陷阱：测试只能验证行为一致性，不能验证内存安全性。

这次迁移要求 Agent「忠实移植」Zig 代码——保持相同架构、相同数据结构、逐文件转换。结果就是：

• 行为一致 ✅（测试全绿）
• 惯用 Rust ❌（超过 1 万个 unsafe 代码块）

作为对比，同生态的 uv 项目只有 73 个 unsafe 块。差了整整两个数量级。

这告诉我们什么？

1. AI 的忠实执行能力很强——你让它怎么干，它就怎么干
2. 但 AI 不会主动帮你做正确的决策——你没说「禁止 unsafe」，它就会用 unsafe
3. Harness 的质量决定了产出的质量——约束条件比模型能力更重要

给普通开发者的行动清单

1. 今天就开始写 CLAUDE.md，哪怕只有三行——技术栈、禁止项、命名规范
2. 配置 Hooks，让每次生成的代码都自动跑 lint
3. 大任务拆子任务，用 SubAgent 隔离上下文
4. 别迷信测试通过率，测试通过 ≠ 代码安全
5. 定期 review AI 生成的代码，别真的「好几个月不敲代码」

写在最后

Bun 用 9 天证明了 AI 编程的上限可以有多高。但开发者 dreamreal 的质疑也提醒我们：代码生成的速度正在指数级增长，而代码审查的速度却没有跟上。

这种不对称，才是真正值得关注的问题。

2026 年，AI 编程的竞争不再是「谁的模型更强」，而是「谁的 Harness 更好」。

与其羡慕 Bun 的 100 万行，不如今天就开始打磨你自己的 CLAUDE.md。

---

参考文章：

• 《为什么你的 Claude Code 只能写 Demo？答案藏在 Harness Engineering 里》
• 《Bun Has Been Converted to Rust. Now What?》
• Claude Code 官方文档