摘要：最近有人拆开了 Claude Code 的源码——它的核心逻辑并没有深度加密，翻出来读了一遍。yml 不要修改

测试策略

• Service 层：必须单测，用 MockK mock 依赖 -Claude Code 好用，不是因为 Claude 模型比别人聪明多少，是因为工具的设计范式更接近真实的开发工作流。

说一个很多人不愿意承认的事：GitHub Copilot 给了我们一个巨大的安慰剂。

它让我们觉得"AI 在帮我写代码"，但实际上，它只是在帮你打字。你还是得想清楚写什么、怎么写、改哪里——AI 只是把你脑子里已经有的东西更快地打出来。

这不是 Copilot 的问题，这是它的设计目标就是如此。问题在于：很多开发者用了两年，效率提升有限，却不知道原因在哪。

原因很简单：你没有用对工具范式。

最近有人拆开了 Claude Code 的源码——它的核心逻辑并没有深度加密，翻出来读了一遍。结论是：Claude Code 和 Copilot 之间的差距，本质上不是 Claude 模型比 GPT-4 更聪明，而是工具的设计范式完全不同。这篇文章就聊这个。

一、补全器 vs Agent：解决的根本就不是同一个问题

Copilot 解决的是：你知道要写什么，但懒得打字。

Claude Code 解决的是：你有一个任务，不知道从哪入手，也不确定该怎么做。

两个工具的差距，不在于谁的模型更聪明，而在于它们对"开发效率瓶颈在哪"的判断完全不同。

现实中，一个经验丰富的开发者，一天里真正"手速不够"的时间少得可怜。绝大多数时间在做的是：读代码、查文档、理解报错、做设计决策、写注释、搭测试环境……这些事情，一个只会补全的 AI 帮不上任何忙。

Claude Code 的定位是 Agent：你给它一个任务，它来执行。具体来说，它会：

• 自己读你的代码库，找到相关文件

• 自己执行终端命令，确认环境状态

• 自己写代码、运行测试、看报错、修改

• 遇到需要人拍板的决策，暂停等你确认

• 直到任务完成

这不只是"更强的补全"，这是工作方式的切换。就像从自己开车变成打车——你不需要关心怎么走，只需要说目的地。

二、源码里的三个关键设计

Claude Code 并非完全开源，但核心逻辑在社区的逆向分析中已经相当清楚。以下三个设计，是它和竞品拉开差距的关键。

设计1：工具 description 是给模型看的指令，不是给人看的注释

这听起来像废话，但绝大多数自研工具都没做到这一点。

很多工具在定义工具调用的时候，description 写的是"读取文件内容"这种给人看的说明。Claude Code 的 description 写的是"Use this when you need to understand existing code before making changes, not when you just want to check if a file exists"——它在告诉模型什么时候该用，什么时候不该用。

# 差的工具定义（大多数实现是这样的）
{
    "name": "read_file",
    "description": "Read a file",  # 没用
    "parameters": {...}
}

# Claude Code 的思路
{
    "name": "read_file",
    "description": (
        "Read the contents of a file at the given path. "
        "Use this when you need to understand existing code, "
        "check implementation details, or verify file contents "
        "before making changes. Prefer this over bash cat for "
        "source code files."
    ),
    "parameters": {...}
}

description 是模型决策的一部分。写得越精准，模型的工具选择就越准确，幻觉就越少。这个细节，大多数"AI 编程工具教程"从来不提。

设计2：上下文管理——不是塞得越多越好

有个流传很广的错误认知：模型 context window 越大越好，塞的内容越多越好。

错。上下文的质量比数量重要得多。把整个代码库塞进去，模型的注意力会被大量无关内容分散，反而比精心裁剪过的上下文表现差。

Claude Code 的上下文策略大致是：

• 任务开始时，只加载最相关的文件，其他的按需读取

• 每次工具返回大量内容，会智能截断：保留关键部分，丢弃重复和无关信息

• 接近 context 上限时，对早期对话做摘要压缩，保留关键决策点而不是逐字保留

• System prompt 和当前任务描述永远不压缩

// 上下文管理的核心思路（伪代码）
class ContextManager {
  private MAX_TOKENS = 100_000; // 留 buffer 给模型输出

  addToolResult(toolName: string, result: string) {
    const processed = this.smartTruncate(toolName, result);
    this.messages.push({ role: 'tool', content: processed });

    if (this.tokenCount > this.MAX_TOKENS * 0.8) {
      // 不是直接截断，而是对早期对话做摘要
      this.summarizeOldMessages();
    }
  }

  private smartTruncate(toolName: string, content: string): string {
    // 针对不同工具类型，有不同的截断策略
    // 代码文件：保留结构（函数签名、类定义），省略实现细节
    // 命令输出：保留最后 N 行 + 错误信息
    // 搜索结果：保留最相关的 K 个匹配
  }
}

设计3：可逆/不可逆的操作边界

这是最容易被忽视但最影响使用体验的设计。

Claude Code 的原则非常简单：可逆的操作自己做，不可逆的先确认。

读文件、搜索代码、运行测试——可逆，直接做，不问。

写文件、修改配置——展示 diff，确认后执行。

删除文件、执行有副作用的脚本、生产环境操作——强制暂停，要求用户明确确认。

这个设计让用户有安全感，不会觉得"AI 不知道在干什么"，也不会因为 AI 频繁问"这样可以吗？"而烦躁。找到这个平衡点，大多数 Agent 工具都没做到。很多工具要么完全不问（容易搞坏东西），要么每步都问（比自己做还慢）。

三、CLAUDE.md：被严重低估的效率杠杆

如果你现在在用 Claude Code，有一件事如果还没做，立刻去做：在项目根目录创建 CLAUDE.md。

这个文件的作用是给 AI 建立项目上下文——你的规范、约束、已知坑、不该碰的地方。每次 Claude Code 开始工作，它都会先读这个文件。

不写这个文件，你会发现 AI 每次都在犯同样的错：用了你明确不想用的 API，写的代码不符合项目风格，在你特别说不要动的地方动手脚。这些问题不是模型智力问题，是没给它足够的项目上下文。

# CLAUDE.md 实战示例

## 项目概览
Kotlin + Spring Boot 后端服务，PostgreSQL + Redis。
前端独立仓库，不在这里。

## 必须遵守的规范
- 所有 Service 必须有接口（为了 mock）
- Repository 用 Spring Data JPA，禁止直接写 JDBC
- 异常处理：业务异常 BusinessException，系统异常 SystemException
- 日志：INFO 给生产，DEBUG 本地调试，禁止在循环里打 DEBUG
- 禁用 @Autowired，统一构造器注入

## 禁止操作
- DatabaseMigration 相关文件不要动，数据库迁移单独处理
- application-prod.yml 不要修改

## 测试策略
- Service 层：必须单测，用 MockK mock 依赖
- Controller 层：MockMvc 集成测试
- Repository 层：@DataJpaTest，不需要全量集成测试

## 已知坑（操作前必看）
- UserService.updateProfile() 有并发问题，不要修改直到锁的问题修完
- OrderService 有内部 RPC 依赖，测试时必须 mock PaymentClient

这个文件写好之后，相当于你给 AI 做了一次完整的项目 onboarding。它之后的操作会更准，你需要纠正它的次数会大幅减少。

这个思路可以推广到任何 AI 工具：把项目上下文结构化，让 AI 每次都能读到，而不是靠人口述。

四、用对任务分解方式，效率翻倍不是夸张

工具好不代表你用得好。AI 编程工具用得溜和用得一般的人，差距不在"提示词技巧"——那些都是小技巧——真正的差距在任务分解的方式。

一个经典的错误：把一个大任务直接扔给 AI。

# ❌ 容易翻车
"帮我把整个用户模块重构一下，同时加上单元测试，
顺便把 API 文档也写了，对了还要兼容旧版本"

# ✅ 正确分解
Step 1: "读 src/user/ 目录，告诉我现在的模块结构和主要问题"
Step 2: "按照你的分析，重构 UserService，不动其他文件"  
Step 3: "给重构后的 UserService 写单测，覆盖 happy path 和主要 error case"
Step 4: "生成 UserService 的 API 文档，基于现在的实现"

大任务扔进去，AI 会生成一大堆代码，看起来很对，细看到处是问题——因为它对整个任务没有全局视角，只能靠猜测填补信息缺失。小任务分步做，每一步你都能 review，每一步 AI 都有充足的上下文，出错率会低得多。

除了任务分解，还有几个工作流场景值得关注：

提交 PR 前的 AI 自检

"看一下这次的改动（git diff main），检查：
1. 有没有明显 bug 或边界条件没处理
2. 有没有违反 CLAUDE.md 里的规范
3. 异常处理是否完整
4. 新的公共方法有没有注释"

这一步通常能抓出 2-3 个自己没注意到的问题，减少 code review 来回次数。而且因为 AI 的 review 是即时的，你在提交前就能修掉，不用等 reviewer 帮你找。

批量迁移和重构

把一个废弃的工具类换成新实现，或者把一堆 if-else 换成策略模式——这类任务对人来说极其枯燥，对 AI 来说是最拿手的。

"搜索所有使用 OldHttpClient 的文件，
逐个改成 NewHttpClient。
注意 NewHttpClient 的 timeout 参数单位是毫秒不是秒。
每改一个文件就跑一次相关测试，确认没有破坏。"

这类任务人工做需要一天，AI 做半小时搞定，而且不会因为疲劳出错。这是 AI 工具效率提升最明显的场景，比"写新功能"的提升大得多。

五、有一件事我想说直白一点

AI 编程工具的讨论里有一个很虚伪的现象：大家说"AI 改变了我的工作方式"，但实际用法还是在用补全器打字，偶尔让 AI 解释一段代码。这不是"改变了工作方式"，这是换了个更聪明的 autocomplete。

真正的改变需要你愿意把工作流重构一遍：

• 不再是"写代码的时候开着 Copilot"，而是"给 AI 一个任务，去做别的事，等它完成"

• 不再是"让 AI 帮我完成这行代码"，而是"让 AI 帮我把这个模块从头写到测试"

• 不再是"有问题了问 AI"，而是"先让 AI 读懂代码，再一起讨论方案"

这个转变是有心理成本的——你需要愿意"放手"，愿意 review 而不是自己写，愿意接受 AI 产出的代码不完全是你想要的风格。

但代价是真实的：你的判断力会被懒惰侵蚀。如果每段代码都让 AI 写，慢慢地你就不知道那段代码为什么这么写。AI 的代码"看起来总是正确的"——整洁、有注释、符合规范——但这是它最大的陷阱。越是看起来对，越需要你仔细看。

正确的姿势是：低价值的操作交给 AI，判断和设计留给自己。什么该写、怎么架构、这个方案有什么取舍——这些不能外包，也不应该外包。

六、下一步值得关注的方向

AI 编程工具还在快速演化，几个值得盯着的方向：

多 Agent 协作：一个 Orchestrator 拆分任务，分配给多个 Worker Agent 并行跑，最后合并。这个模式对复杂项目的潜力还没被充分探索，目前实验性工具已经出现，距离生产可用越来越近。

持久化项目记忆：所有现在的工具都是无状态的，每次对话要重建上下文。未来工具会记住你上周做了什么决定，为什么这么设计，哪个模块有什么历史问题。这个功能一旦成熟，CLAUDE.md 这类手工维护的方式会被替代。

AI 驱动的测试驱动开发：先写测试，让 AI 来实现让测试通过的代码。这个工作流理论上把 AI 完全锁在约束里——只要测试是对的，代码也会是对的。幻觉代码的概率大幅降低。目前有几个团队在内部实验这个模式，效果据说不错。

最值得行动的一步：把 AI Agent 引入 CI/CD 流程。不只是生成代码，而是在代码合并前跑一遍 AI 自检，自动处理 lint 修复，对低风险的 trivial 改动自动 approve。这个方向目前落地的团队还不多，但工具已经基本成熟了——如果你的团队还没做，这可能是性价比最高的一个切入点。

Claude Code 好用，不是因为 Claude 模型比别人聪明多少，是因为工具的设计范式更接近真实的开发工作流。理解这一点，你就能看懂为什么某些工具好用、某些不好用，也能更快地上手未来更好的工具——而不是每次都在重新学"提示词技巧"。