大多数人使用 Claude Code 只是简单地"对话写代码"。但 Claude Code 的真正威力在于它的可扩展性和自动化能力。

本文将深入介绍 Claude Code 的四大高级功能：

1. MCP（Model Context Protocol）：让 Claude 连接外部工具和数据源
2. Hooks：在关键节点插入自动化脚本
3. SubAgent 多智能体架构：并发执行复杂任务
4. CLAUDE.md 配置系统：定义项目规范和工作流

这些功能组合起来，能让 Claude Code 从一个"AI助手"进化成"AI工程师团队"。

一、MCP：让 Claude 连接一切

1.1 什么是 MCP？

MCP（Model Context Protocol）是 Anthropic 推出的开放协议，让 AI 模型能够与外部工具和数据源进行标准化交互。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

传统方式：Claude 只能看到你发给它的文本
MCP方式：Claude 可以主动调用工具获取信息

┌─────────────┐     MCP协议      ┌─────────────┐
│  Claude Code │ ◄────────────► │  外部服务    │
└─────────────┘                 └─────────────┘
                                    ├── 文件系统
                                    ├── 数据库
                                    ├── GitHub
                                    ├── Slack
                                    ├── Google Drive
                                    └── 自定义工具

1.2 配置 MCP 服务器

方法一：命令行添加（推荐）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

# 添加文件系统访问
claude mcp add filesystem -- npx -y @modelcontextprotocol/server-filesystem ~/Documents ~/Projects

# 添加 GitHub 集成
claude mcp add github -e GITHUB_TOKEN=your_token -- npx -y @modelcontextprotocol/server-github

# 添加内存服务（持久化记忆）
claude mcp add memory -- npx -y @modelcontextprotocol/server-memory

# 查看已配置的服务器
claude mcp list

方法二：JSON 配置文件

编辑 ~/.claude/settings.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/me/Projects"],
      "env": {}
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx"
      }
    },
    "postgres": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-postgres"],
      "env": {
        "DATABASE_URL": "postgresql://user:pass@localhost:5432/mydb"
      }
    }
  }
}

1.3 常用 MCP 服务器

1.4 实战：连接数据库查询

配置 PostgreSQL MCP 后，你可以这样使用：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

You: 帮我查一下最近7天注册的用户数量，按天分组

Claude: 我来查询数据库...
[调用 postgres MCP 服务器]

查询结果：
| 日期 | 新增用户数 |
|------|-----------|
| 12-20 | 156 |
| 12-21 | 189 |
| 12-22 | 203 |
| 12-23 | 178 |
| 12-24 | 245 |
| 12-25 | 312 |
| 12-26 | 198 |

总计：1,481 位新用户
可以看出 12-25（圣诞节）有明显的注册高峰。

二、Hooks：自动化工作流的核心

2.1 什么是 Hooks？

Hooks 是 Claude Code 生命周期中的"钩子"，让你在特定事件发生时自动执行脚本。

1
2
3
4
5
6
7

用户输入 → [UserPromptSubmit Hook] → Claude 思考
                                          ↓
                              [PreToolUse Hook] → 工具执行
                                                      ↓
                                          [PostToolUse Hook] → 返回结果
                                                                   ↓
                                                          [Stop Hook] → 会话结束

2.2 官方 8 大事件

2.3 配置 Hooks

全局配置 ~/.claude/settings.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "echo '[AUDIT] Bash command: $TOOL_INPUT' >> ~/.claude/audit.log"
          }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command", 
            "command": "npx prettier --write $FILE_PATH 2>/dev/null || true"
          }
        ]
      }
    ],
    "UserPromptSubmit": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/validate-prompt.sh"
          }
        ]
      }
    ]
  }
}

项目级配置 .claude/settings.local.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write",
        "hooks": [
          {
            "type": "command",
            "command": "npm run lint:fix -- $FILE_PATH"
          }
        ]
      }
    ]
  }
}

2.4 实战示例

示例1：自动格式化代码

每次 Claude 写入文件后，自动运行 Prettier：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit|MultiEdit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$TOOL_INPUT\" 2>/dev/null || true"
          }
        ]
      }
    ]
  }
}

示例2：危险命令拦截

阻止执行危险的 Bash 命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

#!/bin/bash
# ~/.claude/scripts/validate-bash.sh

DANGEROUS_PATTERNS="rm -rf|DROP TABLE|DELETE FROM|format|mkfs"

if echo "$TOOL_INPUT" | grep -qE "$DANGEROUS_PATTERNS"; then
    echo "BLOCKED: 检测到危险命令"
    exit 1
fi

exit 0

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "~/.claude/scripts/validate-bash.sh"
          }
        ]
      }
    ]
  }
}

示例3：Slack 通知

任务完成后发送 Slack 通知：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "curl -X POST -H 'Content-type: application/json' --data '{\"text\":\"Claude Code 任务完成!\"}' $SLACK_WEBHOOK_URL"
          }
        ]
      }
    ]
  }
}

三、SubAgent：多智能体并发架构

3.1 架构原理

Claude Code 采用分层多 Agent 架构，通过主 Agent和SubAgent协作处理复杂任务：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

用户请求
    ↓
主 Agent (nO 函数)
    ↓
是否调用 Task 工具？
    ├── 否 → 直接处理 → 返回结果
    └── 是 → 创建 SubAgent
              ↓
         并发执行调度器 (UH1)
              ↓
         多个 SubAgent 并行执行
              ↓
         结果合成器 (KN5)
              ↓
         返回合成结果

3.2 核心特性

1. 完全隔离的执行环境：每个 SubAgent 在独立上下文中运行
2. 智能并发调度：支持最多 10 个 Agent 并发执行
3. 安全权限控制：SubAgent 无法调用 Task 工具（防止递归）
4. 高效结果合成：智能合并多个 Agent 的输出

3.3 Task 工具使用

当你给 Claude Code 一个复杂任务时，它会自动决定是否使用 SubAgent：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

You: 分析这个项目的代码质量，包括：
1. 代码结构是否合理
2. 是否有潜在的性能问题
3. 测试覆盖率如何
4. 安全漏洞检查

Claude: 这是一个复杂的分析任务，我会启动多个 SubAgent 并行处理：

[启动 SubAgent 1] 分析代码结构...
[启动 SubAgent 2] 检查性能问题...
[启动 SubAgent 3] 分析测试覆盖率...
[启动 SubAgent 4] 扫描安全漏洞...

[等待所有 SubAgent 完成...]

[合成结果] 综合所有 Agent 的分析：
...

3.4 SubAgent 可用工具

SubAgent 可以使用以下工具：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

const SUBAGENT_ALLOWED_TOOLS = [
    'Read',       // 读取文件
    'Write',      // 写入文件
    'Edit',       // 编辑文件
    'MultiEdit',  // 多处编辑
    'Glob',       // 文件搜索
    'Grep',       // 内容搜索
    'Bash',       // 执行命令
    'WebFetch',   // 网页获取
    'WebSearch',  // 网络搜索
    'TodoRead',   // 读取任务
    'TodoWrite',  // 写入任务
];

// 被禁用的工具（防止递归）
const BLOCKED_TOOLS = ['Task'];

3.5 并发执行示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

You: 帮我同时搜索项目中所有的 TODO 注释、FIXME 标记和废弃的 API 调用

Claude: 我会并行启动 3 个搜索任务：

[SubAgent 1] 搜索 TODO 注释...
[SubAgent 2] 搜索 FIXME 标记...
[SubAgent 3] 搜索废弃 API 调用...

--- 3 秒后 ---

[SubAgent 1 完成] 找到 23 个 TODO
[SubAgent 2 完成] 找到 8 个 FIXME
[SubAgent 3 完成] 找到 5 个废弃 API

[合成结果]
## 代码待办事项汇总

### TODO (23处)
- src/api/user.ts:45 - TODO: 添加缓存
- src/components/Table.tsx:123 - TODO: 优化渲染性能
...

### FIXME (8处)
- src/utils/date.ts:67 - FIXME: 时区处理有问题
...

### 废弃 API (5处)
- src/legacy/auth.ts:12 - 使用了已废弃的 crypto.createCipher
...

四、CLAUDE.md 配置系统

4.1 三级配置文件

Claude Code 使用三类 .md 文件进行配置，优先级从高到低：

4.2 创建项目配置

使用 /init 命令自动生成：

1
2

claude
> /init

这会在项目根目录创建 CLAUDE.md 文件。

4.3 配置示例

项目级 CLAUDE.md（提交到 Git）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# 项目配置

## 项目概述
这是一个 Next.js 14 电商平台，使用 TypeScript + Prisma + PostgreSQL。

## 技术栈
- 框架：Next.js 14 (App Router)
- 语言：TypeScript 5.x (严格模式)
- 数据库：PostgreSQL + Prisma ORM
- 样式：Tailwind CSS
- 状态管理：Zustand
- 测试：Vitest + Testing Library

## 代码规范
- 使用 ESLint + Prettier 格式化
- 组件使用函数式写法
- 所有函数必须有 JSDoc 注释
- 禁止使用 any 类型
- 错误处理使用自定义 Error 类

## 目录结构

src/ ├── app/ # Next.js App Router 页面 ├── components/ # React 组件 ├── lib/ # 工具函数和配置 ├── hooks/ # 自定义 Hooks ├── types/ # TypeScript 类型定义 └── prisma/ # 数据库 Schema

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

## 常用命令
- `npm run dev` - 启动开发服务器
- `npm run build` - 构建生产版本
- `npm run test` - 运行测试
- `npm run lint` - 代码检查
- `npx prisma studio` - 打开数据库管理界面

## Git 提交规范
- feat: 新功能
- fix: 修复 Bug
- refactor: 重构
- docs: 文档
- test: 测试
- chore: 构建/工具

## 注意事项
- 数据库敏感操作需要人工确认
- 不要直接修改 prisma/migrations 目录
- API 路由必须有权限验证

个人本地配置 CLAUDE.local.md（不提交）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# 本地配置

## 个人偏好
- 我喜欢详细的注释
- 代码示例要完整可运行
- 解释时使用中文

## 本地环境
- Node.js: v20.10.0
- 数据库：本地 Docker 容器
- 端口：3000 (开发), 5432 (PostgreSQL)

## 调试配置
- 使用 VS Code 调试
- 断点调试端口: 9229

全局配置 ~/.claude/CLAUDE.md：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 全局配置

## 通用规范
- 使用 2 空格缩进
- 变量命名使用 camelCase
- 常量使用 UPPER_SNAKE_CASE
- 组件使用 PascalCase

## 默认工具
- 包管理器：pnpm
- 版本控制：Git
- 编辑器：VS Code

## 安全规则
- 不要在代码中硬编码密钥
- 敏感文件（.env）不要提交
- API 调用必须有超时设置

4.4 自定义斜杠命令

在 .claude/commands/ 目录下创建 Markdown 文件，即可定义自定义命令：

文件结构：

1
2
3
4
5

.claude/
└── commands/
    ├── review.md      # /review 命令
    ├── test.md        # /test 命令
    └── deploy.md      # /deploy 命令

示例：review.md

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

请对当前项目进行代码审查：

1. 检查代码质量
   - 是否有重复代码
   - 函数是否过长
   - 命名是否清晰

2. 检查潜在问题
   - 是否有未处理的错误
   - 是否有性能问题
   - 是否有安全漏洞

3. 检查最佳实践
   - 是否遵循项目规范
   - 是否有充分的测试
   - 是否有必要的注释

请提供详细的改进建议。

使用：

1

> /review

五、综合实战：打造个人 AI 工作流

5.1 完整配置示例

结合以上所有功能，配置一个完整的 AI 开发工作流：

~/.claude/settings.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "~/Projects"],
      "env": {}
    },
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  },
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Write|Edit",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$FILE_PATH\" 2>/dev/null || true"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "echo \"[$(date)] Task completed\" >> ~/.claude/activity.log"
          }
        ]
      }
    ]
  },
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git *)",
      "Bash(npx prettier *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)"
    ]
  }
}

5.2 工作流示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

1. 启动项目
   > claude
   > /init  # 生成 CLAUDE.md

2. 查看项目状态
   > /review  # 运行自定义代码审查命令

3. 开发新功能
   > 帮我实现用户头像上传功能，要支持裁剪和压缩
   
   [Claude 自动]:
   - 分析项目结构
   - 创建组件文件（自动格式化）
   - 编写测试用例
   - 更新文档

4. 提交代码
   > 提交这些改动，写一个清晰的 commit message
   
   [Claude 使用 GitHub MCP]:
   - 生成 commit message
   - 创建 commit
   - 可选：创建 PR

总结

Claude Code 的高级功能让它从一个简单的 AI 聊天工具，变成了一个真正的AI 开发平台：

掌握这些功能，你就能把 Claude Code 打造成专属的 AI 工程师团队。

参考资源

• Claude Code 官方文档
• MCP 协议规范
• MCP 服务器列表

2025年初，OpenAI前研究总监 Andrej Karpathy 发了一条推文，引爆整个技术圈：

“I just mass-mass-produce code with AI. I barely look at the diffs. I call this Vibe Coding.”

“我现在用AI大规模生产代码，几乎不看diff。我称之为 Vibe Coding。”

这不是玩笑。这位顶级AI科学家在认真描述他的日常工作方式：

• 用自然语言告诉AI要做什么
• AI生成代码
• 直接运行看效果
• 有问题就让AI改

不看代码，只看结果。

这就是 Vibe Coding —— 一种全新的编程范式。

从"写代码"到"描述需求"

传统编程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

# 手动实现一个用户登录功能
def login(username: str, password: str) -> dict:
    # 验证输入
    if not username or not password:
        raise ValueError("用户名和密码不能为空")
    
    # 查询数据库
    user = db.query(User).filter(User.username == username).first()
    if not user:
        raise AuthError("用户不存在")
    
    # 验证密码
    if not verify_password(password, user.hashed_password):
        raise AuthError("密码错误")
    
    # 生成token
    token = create_access_token(user.id)
    
    return {"token": token, "user": user.to_dict()}

你需要：

1. 了解所有API
2. 处理边界情况
3. 手动写每一行

Vibe Coding

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

You: 实现用户登录功能，要验证输入、查数据库、验密码、返回JWT token

AI: [生成完整代码]

You: 跑一下

AI: [执行测试] 测试通过

You: 加个登录失败次数限制，超过5次锁定账号

AI: [修改代码] 已添加

你需要：

1. 清楚地描述需求
2. 验证结果是否符合预期
3. 迭代优化

代码变成了"中间产物"，不再是最终目标。

为什么现在可行了？

1. 模型能力的跃升

Claude 3.5 Sonnet → Claude Opus 4.5 → GPT-5，代码能力指数级提升：

2. 工具链的成熟

• Cursor：AI原生IDE，理解整个项目
• Claude Code：终端里的AI程序员
• Windsurf：Copilot++，无缝集成
• Replit Agent：从描述到部署一条龙

3. 上下文窗口爆炸

• 2023年：4K tokens（一个文件）
• 2024年：128K tokens（小型项目）
• 2025年：1M+ tokens（大型代码库）

AI终于能"看懂"整个项目了。

Vibe Coding 实战演示

场景：从零搭建一个博客系统

传统方式：2-3天

Vibe Coding方式：2小时

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

第1轮对话：

You: 我要做一个个人博客系统，技术栈用 Next.js 14 + Prisma + PostgreSQL。
功能需要：
- Markdown 文章编辑
- 文章分类和标签
- 评论系统
- 暗黑模式
帮我搭建项目框架。

AI: 好的，我来创建项目...
[执行 npx create-next-app@14 ...]
[创建 prisma/schema.prisma]
[创建数据库模型]
[创建基础组件]
...
框架搭建完成，运行 npm run dev 查看效果。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

第2轮对话：

You: 首页看起来太丑了，参考 Vercel 官网的设计风格美化一下

AI: 明白，我来调整样式...
[修改 globals.css]
[修改 components/Header.tsx]
[添加渐变背景和动画效果]
...
已更新，刷新页面查看。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

第3轮对话：

You: 文章编辑器需要支持实时预览，左边写 Markdown 右边显示效果

AI: 
[安装 react-markdown]
[创建 SplitEditor 组件]
[添加语法高亮支持]
...
编辑器已完成。

2小时后：一个功能完整、样式精美的博客系统上线。

谁适合 Vibe Coding？

最适合

1. 资深开发者

   • 知道要做什么，懒得写具体实现
   • 能快速判断AI代码质量
   • 专注架构设计和业务逻辑

2. 创业者/独立开发者

   • 一个人当一个团队用
   • 快速验证想法，MVP开发
   • 把时间花在更重要的事情上

3. 非专业程序员

   • 产品经理自己做原型
   • 设计师实现交互效果
   • 运营搭建内部工具

需要谨慎

1. 涉及核心算法的场景

   • 交易系统的风控逻辑
   • 推荐算法的核心实现
   • 需要100%正确的关键路径

2. 安全敏感场景

   • 加密解密实现
   • 认证授权逻辑
   • 需要人工审查每一行

3. 性能极端场景

   • 毫秒级响应要求
   • 资源受限环境
   • 需要手工优化

程序员的新技能栈

Vibe Coding 时代，程序员需要的能力正在转变：

重要性降低

• ❌ 记忆API语法
• ❌ 手写样板代码
• ❌ 调试简单Bug
• ❌ 代码格式规范

重要性提升

• ✅ 需求分析：把模糊需求转化为清晰描述
• ✅ 架构设计：决定系统如何组织
• ✅ 代码审查：快速判断AI输出质量
• ✅ Prompt工程：如何让AI更好地理解你
• ✅ 测试验证：确保结果符合预期
• ✅ 领域知识：理解业务，而不只是技术

新的工作流程

1
2
3
4

传统：需求 → 设计 → 编码 → 测试 → 部署

Vibe：需求 → 描述 → AI编码 → 审查 → 迭代 → 部署
          ↑_________←_________|

核心变化：你从"生产者"变成了"指挥者"和"质检员"。

一些实用建议

1. 学会"说人话"

1
2
3
4
5
6
7

❌ 不好的描述：
"写一个函数处理用户数据"

✅ 好的描述：
"写一个函数，接收用户注册表单数据（name, email, password），
验证邮箱格式和密码强度（至少8位，包含大小写和数字），
验证通过返回处理后的数据，失败抛出具体错误信息"

2. 分步迭代

不要试图一次性让AI写完所有功能。

1
2
3
4
5

第1步：搭建基础框架
第2步：实现核心功能
第3步：添加边界处理
第4步：优化性能
第5步：完善样式

3. 保持代码审查习惯

AI不会100%正确。关键代码一定要review：

• 安全相关（认证、权限、加密）
• 性能相关（循环、查询、缓存）
• 业务相关（核心逻辑、金额计算）

4. 建立项目规范

在项目中维护一个 CLAUDE.md 或 .cursorrules 文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 项目规范

## 技术栈
- Next.js 14 (App Router)
- TypeScript 严格模式
- Tailwind CSS
- Prisma ORM

## 代码风格
- 使用函数式组件
- 所有函数必须有 JSDoc 注释
- 错误处理使用自定义 Error 类

## 禁止
- 使用 any 类型
- 直接操作 DOM
- 在组件中写内联样式

这是终点吗？

Vibe Coding 可能只是开始。

接下来可能发生的：

1. AI理解产品文档：直接从PRD生成代码
2. AI参与代码审查：自动发现问题并修复
3. AI运维系统：监控、报警、自动修复
4. AI产品经理：分析用户行为，提出优化建议

终极形态：

你描述一个想法，AI完成从设计到开发到部署到运维的全流程。

这不是科幻，可能就在3-5年内。

结语

Vibe Coding 不是要消灭程序员，而是在重新定义什么是编程。

20年前，“程序员"意味着要懂汇编和指针。 10年前，“程序员"意味着要懂框架和设计模式。 今天，“程序员"可能意味着要懂需求分析和AI协作。

不变的是：解决问题的能力、对技术的理解、对产品的洞察。

变化的是：实现方式从"手写代码"变成了"指挥AI”。

你可以选择抵触，也可以选择拥抱。但无论如何，这个浪潮已经来了。

我没写一行代码。但那个下午合并了五个 PR。

这不是什么"未来已来"的感慨。这是 2026 年 5 月一个普通工程师的普通下午。半年前——也就是 2025 年底——我的工作方式还不是这样。那时候 AI 编程工具的主流形态是"一个很聪明的补全",你在编辑器里写代码,它帮你接下一段。现在,补全这件事我几乎已经感觉不到它的存在了,因为我的注意力整个挪到了别处。

这半年到底发生了什么,值得拆开看看。

三级跳:补全 → 终端 agent → 后台 agent

如果要给 AI 编程工具这半年画一条线,它是这样三级跳的:

flowchart LR
  A[代码补全
2023-2024] --> B[IDE 内 agent
2025] --> C[终端 agent
2025 下半年] --> D[后台/云端 agent
2026]
  style A fill:#e8e8e8,stroke:#999
  style B fill:#fde7c2,stroke:#e8b23c
  style C fill:#fde7c2,stroke:#e8b23c
  style D fill:#c2e0fd,stroke:#3c8ce8

第一级是补全:Copilot 那套,光标后面灰字提示,你按 Tab 接受。这个形态决定了一件事——AI 是你的副驾驶,方向盘还在你手里,你得一直盯着路。

第二级是 IDE 内的 agent:Cursor 的 Composer、Windsurf 的 Cascade。它不再是接一段,而是"你说要干什么,它跨多个文件改完给你看"。方向盘开始松动了,但你还在车里。

第三级是 终端 agent:Claude Code 是把这个形态做出影响力的那个。它干脆不要 IDE 这个壳了,就是个命令行程序,你跟它说话,它自己读文件、改代码、跑测试、看报错、再改。这一步的意义比看上去大——它把 AI 编程从"编辑器里的一个功能"变成了"一个独立的进程"。一旦是独立进程,你就能开很多个,就能让它在后台跑。

第四级,也就是现在,是后台 / 云端 agent:活儿不在你机器上跑了。Cursor 的 cloud agents、GitHub 的 coding agent、Cognition 的 Devin,它们在云端的容器里干活,干完给你提个 PR。你甚至可以在手机上派活。

每跳一级,人和代码之间就多隔一层。半年前我的手指还在键盘上,现在我的手指主要在做一件事:点"approve"或者"reject"。

当前四强,各自站在哪

把这半年最主流的四个工具摆在一起,它们其实已经不在同一个赛道上竞争了——这是很多人没意识到的。

Cursor 这半年走得最稳。3.3、3.4 连着发,Composer 2.5 五月中刚出。它现在的核心卖点已经不是"补全多准",而是 /multitask——你可以同时开一堆异步子 agent 并行干活,加上云端 automation 能直接从 Linear、Jira、GitHub 读工单、起 PR、回写状态。Cursor 想做的是你的指挥台:本地一份 agent,云端一支舰队,你坐中间派活。它甚至能帮你把云端 agent 需要的开发环境(克隆仓库、装依赖、配凭据)自动搭好——因为没有环境,agent 舰队就跑不起来。

Claude Code 走的是另一条路。它不抢"IDE"这个身份,就守着终端。这半年它加了 Agent View——一个能同时盯多个后台会话的界面,加了 /goal——你给它一个目标,它自己写代码、跑测试、debug、再跑,直到达成。我个人的体感:Claude Code 是这四个里最适合干"脏活重活"的。一个要动二十个文件、还得反复跑测试验证的重构,我现在默认丢给它。它的 fast mode 现在默认跑 Opus 4.7。

Windsurf 是这半年最唏嘘的一个。2025 年底它被 Cognition(做 Devin 的那家)以约 2.5 亿美元收购,这中间还夹着 Google 的技术授权和 OpenAI 当初的竞购,过程一地鸡毛。产品本身没死,Wave 13 还带来了多 agent 会话和 Git worktree 支持,2026 年 2 月它在 LogRocket 的 AI 开发工具榜上还排第一。但今年 3 月它把原来便宜、可预测的 15 美元信用额度套餐换成了 20 美元加严格日 / 周配额,直接惹毛了一批老用户。更要命的是定位上的不确定:Cognition 明说了想把 Windsurf 的 IDE 能力并进 Devin。所以现在用 Windsurf,你得想清楚——你是在用一个 IDE,还是在用一个早晚会变成 Devin 入口的东西。

GitHub Copilot 是那个"看起来落后、其实没掉队"的。补全起家的它,这半年把 Agent Mode 和云端 coding agent 都补齐了:coding agent 现在能自己选模型、开 PR 前先用 code review 自审一遍、还在流程里跑代码扫描和密钥泄露检查。它最大的护城河从来不是模型,是它长在 GitHub 身体里——issue、PR、Actions、code review 一条龙。五月它还放出了从 JetBrains IDE 把任务交给本地 Copilot CLI agent 的预览。Copilot 不耀眼,但对一个深度绑在 GitHub 上的企业团队,它是阻力最小的选择。

我的判断是:别再问"哪个最好"了。这个问题在 2025 年还成立,现在不成立。Cursor 是指挥台,Claude Code 是重型施工队,Copilot 是贴着 GitHub 的传送带,Windsurf 是一张赌 Cognition 未来的票。它们解决的是不同的问题。我自己是 Cursor + Claude Code 一起用,前者派活、后者啃硬骨头,一点都不冲突。

“终端 agent"为什么会赢

值得单独说一句:为什么 2025 下半年杀出来的是终端 agent 这个形态,而不是更花哨的 IDE?

因为终端 agent 砍掉了"图形界面"这个包袱,换来了三样东西:可组合、可并行、可上云。

一个命令行程序,你能用 shell 脚本把它串起来,能在 CI 里调它,能开十个进程同时跑。一个 IDE 你做不到这些——IDE 天生是给"一个人坐在前面"设计的。当 AI 编程从"辅助一个人"变成"同时干很多活”,IDE 这个外壳反而成了约束。

flowchart TB
  Dev[开发者] --> Plan[拆任务 / 写清楚要什么]
  Plan --> A1[agent 1: 后台改 bug]
  Plan --> A2[agent 2: 本地写新功能]
  Plan --> A3[agent 3: 云端跑重构]
  A1 --> Review[人:审 diff / 提 PR / 决定合不合]
  A2 --> Review
  A3 --> Review
  Review --> Dev
  style Dev fill:#fde7c2,stroke:#e8b23c
  style Review fill:#fde7c2,stroke:#e8b23c

注意这张图里,人只出现在两个地方:开头拆活,结尾审活。中间那段"写代码"已经不在人的关键路径上了。这就是这半年最实质的变化——它不是工具变好用了,是工作流的形状变了。

Cursor 也很清楚这一点,所以它一边守着 IDE 这个用户习惯,一边拼命往云端 agent 和 /multitask 上加码。它在用 IDE 的外壳,装终端 agent 的内核。

你的工作从"写"变成了"审"和"派"

这是我最想说的一段,也是这半年我自己感受最深的。

半年前,我的核心技能是写代码。现在不是了。现在我每天花最多时间的三件事是:

第一,把活拆清楚。 Agent 干得好不好,八成取决于你派活派得清不清楚。一个含糊的"帮我优化下这个模块",和一个"把这个模块的数据库查询从 N+1 改成批量加载,保持现有接口不变,加上对应测试"——出来的东西天差地别。这半年我越来越觉得,写清楚需求本身就是一种正在升值的技能。Claude Code 的 /goal 之所以好用,前提是你得能说清楚那个 goal。

第二,审 diff。 这是最累、也最危险的一件事。Agent 一天能给你交十几个 PR,业界数据是引入 agent 后 PR 数量涨了 40% 到 60%。问题来了:你审得过来吗?审不过来就会有人开始"假装审过了"——扫一眼,点 approve。这是 2026 年最真实的风险,不是 AI 写出 bug,是人审不动了,于是不审了。

我给自己定了条规矩:agent 写的代码,审查标准要比人写的更高,不是更低。因为人写错了通常错得"有道理"、好猜;agent 错起来经常错得很离谱、很自信,藏在一堆看着没问题的代码中间。

第三,决定什么不交给 agent。 这点反直觉但很重要。核心架构、安全边界、那些"错了代价很大"的地方,我现在反而更倾向自己写,或者自己写完让 agent 来挑错。会派活的人不是把所有活都派出去的人,是知道哪些该派、哪些该自己攥着的人。

工具厂商其实也在顺着这个变化走。GitHub Copilot 的 coding agent 现在开 PR 前会先自审一遍、跑安全扫描——本质上是它知道"人审不过来了",所以先帮你过一遍。Cursor 给你看 agent 的 context 用量,也是同一个逻辑:当你不亲自写,你至少得知道它在想什么。

所以如果你问我,这半年一个开发者最该练的是什么,我的答案是三个词:拆活、审 diff、判断边界。写代码的肌肉不会废掉——你得能写,才看得懂 agent 写的——但它不再是那块最值钱的肌肉了。

接下来半年,我赌什么

简单说几个判断,赌错了年底再来认。

后台 agent 会变成默认,但"全自动"还早。 派活给云端 agent、它提 PR 给你审,这套流程会变成常规操作。但"把整个需求扔进去、不管了"——Devin 那个最初的承诺——我认为这半年还到不了。卡点不在模型聪不聪明,在验证:你怎么确认它真做对了?在这个问题被解决之前,人必须留在审查这一环。

工具会继续分化,不会收敛。 不会出现一个"赢家通吃"的 AI IDE。终端 agent、IDE、云端 agent 是三种不同的形态,服务三种不同的场景,它们会长期共存。你最终大概率是手上同时握着两三个,按场景切。

审查会变成瓶颈,然后变成新工具的战场。 当 agent 产出快到人审不过来,下一波工具竞争的焦点不会是"写得更快",而是"帮你审得更快、更可信"。谁能让人重新跟得上 agent 的产出速度,谁就赢下 2026 下半年。

半年前我担心的是 AI 会不会写不好代码。现在我不担心这个了——它写得够好。我现在担心的是另一件事:当写代码这件事变得这么便宜,我们会不会因为审不过来,而让一堆没真正看懂的代码,合进了主干。

工具的演化已经跑到前面去了。该追上的,是我们自己审视代码的方式。

而审你 PR 的那个人,一天还是只能审五六个。

这两个数字凑在一起,就是 2026 年大多数工程团队真正的麻烦。Faros AI 的数据里,高 AI 使用率的团队完成的任务多了 21%、合并的 PR 多了将近一倍,但 PR 的 review 时长涨了 91%——而且那些 PR 还更大。Opsera 一份覆盖 25 万开发者的报告说得更直白:在没有治理的情况下,AI 生成的 PR 在 review 队列里等的时间是普通 PR 的 4.6 倍,哪怕从写完到提 PR 的时间砍掉了一半多。

写代码这件事,被 AI 解决了一大半。审代码这件事,一点没变。瓶颈就这么从「写」挪到了「审」,而且大多数团队还没意识到。

为什么 AI 写的代码,审起来反而更难

直觉上,AI 代码该更好审才对——它风格统一、不会忘加分号、命名规规矩矩。但真审过 AI 大批量产出的代码的人都知道,事情反过来了。AI 代码难审,难在三个地方。

第一,它看着太合理了。 人写错代码,常常会留下「破绽」——变量名词不达意、缩进乱、注释和代码对不上,这些视觉信号会让 reviewer 警觉。AI 不会。AI 写的错误代码,长得和正确代码一模一样:命名得体、结构清晰、注释贴心。CodeRabbit 的研究说 AI 写的代码暴露的问题比人写的多 1.7 倍,而这些问题里相当一部分是逻辑错误——业界一个被反复引用的说法是,AI 代码的纯逻辑错误率比人高约 75%。一个长得人模人样的函数,你的大脑会默认它没问题,于是真正的 bug 藏在「看着合理」的外壳里溜过去了。

第二,量。 一个 reviewer 以前一天面对的是三五个 PR、每个两三百行。现在是十几个 PR,而且单个更大。注意力是有总量的——审第一个 PR 时你逐行读,审到第八个时你已经在「扫」。Review 质量不是匀速下降的,是过了某个阈值之后断崖式塌掉的。量本身就是一种攻击。

第三,意图断了。 人写代码,脑子里有一条没写下来的推理链:为什么用这个数据结构、为什么这里要加锁、为什么宁可慢一点也不并发。Reviewer 审的其实是这条链。AI 生成代码时,这条链在 prompt 和模型权重里,没留在 diff 里。你看到的是结论,看不到「为什么」。于是 review 退化成「这段代码自己自洽吗」,而不是「这段代码做的是不是我们真正想要的事」——后者才是 review 的价值所在。

flowchart LR
  A[人写代码] --> B[diff 里有破绽
能看出意图] --> C[reviewer 审意图]
  D[AI 写代码] --> E[diff 看着完美
意图没留下] --> F[reviewer 只能审自洽性]
  style E fill:#fde7c2,stroke:#e8b23c
  style F fill:#f8d0d0,stroke:#d06666

把这三点合起来:更隐蔽的错误、更大的量、更稀薄的意图。这不是「AI 代码质量差」的问题,是 review 这个动作的前提被抽掉了。

人审扛不住量,第一反应往往是错的

发现 reviewer 堵住了,团队的第一反应通常是这几个,而它们大多没用,甚至有害。

「招更多 reviewer」 ——慢、贵,而且高级工程师本来就稀缺。更要命的是,AI 产代码的速度还在涨(有统计说人均产出 2025 到 2026 一年涨了约 60%),你招人的速度永远追不上模型迭代的速度。这是一场你结构性赢不了的军备竞赛。

「review 快一点」 ——把每个 PR 的 review 时间压缩,等于直接降低 review 质量。前面说过,AI 代码的错误本来就更隐蔽,你越快扫,漏得越多。这是用「看起来通畅」换「实际上失控」。

「先合了再说,出问题再修」 ——在 AI 时代尤其危险。以前一个有问题的模式进了主干,影响范围有限。现在 AI 会以那段代码为样本,在下一次生成时把同样的错误复制到十个地方。坏模式的传播速度,跟生成速度一样快。

真正有用的方向只有一个:别让所有代码都用同一种强度去审。 Review 是稀缺资源,稀缺资源必须分配,不能平摊。

把进来的变更分层。一个能落地的分法是这样:

关键不是这张表本身,是承认一件事:不是所有代码都值得人来审。 让你最贵的工程师去逐行看一个改 UI 文案的 PR,是对稀缺资源的浪费,也是在透支他审计费系统时该有的注意力。把人的注意力,留给真正需要人类判断的地方。

AI 审 AI 的代码,到底靠不靠谱

既然量是 AI 带来的,那让 AI 来审,逻辑上很顺。现在 AI code review 工具已经是个成熟品类,几十个产品,有真实的 ROI 数据。但「靠不靠谱」要分两面说。

靠谱的那一面: AI reviewer 在「机械层」上是真的好用,而且能做到人做不到的事。它能记住整个依赖树里哪些包有已知 CVE、哪些 license 不合规、哪些 API 已经废弃;能在跨文件的几十个改动里发现「这个函数签名变了但那边三个调用没改」。有评测说,能看全代码库的工具,比只看单个 diff 的工具多抓出 40%~60% 的跨文件问题。这类活,人本来就做不好——人记不住那么多东西。

不靠谱的那一面,要说透。 AI 审 AI,有一个结构性的盲区:它们共享同一套训练分布。 2026 年初有研究指出,「生成 Agent + 审查 Agent」的流水线里,第一个 Agent 的错误经常被第二个 Agent 直接放行——因为它们出自同一个分布,缺乏「对抗性的差异」,自审最后退化成把原来的错误又确认了一遍。还有一篇 2026 年 2 月的论文更狠:就算是异构的多 Agent 团队,整体表现也稳定地打不过其中最强的那个单一成员,失败机制是「为了达成共识而牺牲专业判断」。

翻译成大白话:AI 会和你一起犯同一个错,而且犯得很自信。 你写 prompt 时漏掉的那个约束,生成的 Agent 不知道,审查的 Agent 同样不知道——它没法审出一个它自己也意识不到的需求。这正是 review 最该抓的那种错:不是「代码写错了」,是「代码做的不是我们要的事」。

另一个具体限制:AI reviewer 一旦喂的代码太多就垮。一个上千行的 diff 会撑爆上下文窗口,模型开始丢失连贯性,看不到改动之间的关联。它在小而聚焦的 PR 上表现最好——这反过来也说明,PR 该小,本来就该小。

所以我的判断是:AI 审机械层,人审意图层,两者不是替代关系,是分工。 把 AI 当成那个不知疲倦、记性超好、但永远不会质疑需求本身的初级 reviewer。它清场,人做判断。指望 AI 把人这一层也包了,是把它最不擅长的事派给了它。

flowchart TB
  PR[一个 PR 进来] --> AI[AI reviewer]
  AI --> M[机械层:CVE、废弃 API
跨文件一致性、风格、空指针]
  AI --> H{还需要人吗?}
  H -->|高风险或涉及意图| HUM[人 reviewer
只审:这是不是我们想要的]
  H -->|低风险且 CI 全绿| MERGE[合并]
  HUM --> MERGE
  style HUM fill:#fde7c2,stroke:#e8b23c

测试和类型系统,从「保险」变成「地基」

以前我们说测试和类型系统是「锦上添花的工程素养」。在 AI 时代,它们的角色被彻底放大了——它们成了你唯一能规模化、不靠人盯的那道防线。

道理很简单。人 review 不可规模化,AI review 有共享盲区,但一个类型检查、一个测试用例,是确定性的:它对一行代码和对一百万行代码,执行的是同一套标准,不会因为今天是第八个 PR 就走神。AI 能把生产代码的速度提十倍,但它没法提高你 review 的速度——能跟上这个速度的,只有自动化的、确定性的校验。

具体几条,都是能马上做的:

• 类型系统要严。 能上严格模式就上严格模式。AI 很爱写「看着对、类型上其实有洞」的代码,一个严格的类型检查器会在 review 之前就把一类错误挡掉,而且零成本、零情绪。
• 测试覆盖的是意图,不是行数。 别用覆盖率数字考核——AI 生成高覆盖率但什么都没验证的测试,毫不费力。要写的是「断言业务规则」的测试:这笔订单在这个条件下必须被拒。这种测试,AI 之后改坏了逻辑,它会立刻红。
• 测试本身也得审,而且要人审。 AI 写功能、又顺手把测试写了,这是个陷阱:它可能写一个「永远会过」的测试来配合一段错的实现。审 AI 代码时,测试那部分要单独、用人的眼睛看。
• 把校验往左移。 类型检查、静态扫描、安全规则、测试,全塞进 CI 的硬门禁。能在代码进 review 队列之前就拦下的问题,就别留给那个已经在审第八个 PR 的人。

一句话:人和 AI 都会累、会走神、会有盲区,确定性的检查不会。 在代码量爆炸的时代,把质量赌在「有人会仔细看」上,是不可持续的;把它建在自动化门禁上,才扛得住量。

团队流程,得跟着改

工具和分工都到位了,最后是流程。不改流程,前面都白搭。几条具体的:

PR 必须小,而且单一意图。 这条从「最佳实践」升级成了「硬约束」。reviewer 的带宽是整个系统的瓶颈,而瓶颈必须被主动管理。一个改了八件事的千行 PR,人审不动,AI 也审不动(上下文撑爆)。规矩要立死:一个 PR 只干一件事。AI 让你写得快,但不该让你把八件事打包成一个 diff 甩给别人。

PR 描述要写「为什么」,这是在补回断掉的意图链。 2026 年一个合格的 PR 描述应该回答四件事:这个改动想干什么、为什么这么干(一两句);怎么证明它能跑(测试 + 手动验证步骤);风险多大、哪些部分是 AI 生成的;以及——明确点出 1~2 个「请人重点看这里」的地方。最后这点最关键:让提 PR 的人(他脑子里有意图)主动告诉 reviewer 该把注意力放哪。diff 该读起来像一份「意图说明书」,而不是一堆代码行的堆砌。

「谁提的 PR,谁对它负责」要写进规矩。 用 AI 生成的代码,不等于责任也外包给了 AI。「这是 AI 写的」永远不能成为甩锅的理由。你按了那个生成键,你提了这个 PR,这段代码就是你的。这条不立清楚,所有人都会松懈,因为没人觉得自己该为一段「不是我写的」代码负责。

测 review 这个环节本身。 既然瓶颈在这,就得给它装仪表盘:PR 在队列里平均等多久、单个 PR 多大、合并后多久出回滚或 hotfix。这些数字会告诉你 review 是不是正在悄悄塌掉——大多数团队是数字已经很难看了才后知后觉。

写在最后

AI 没有消灭 review,它把 review 推到了聚光灯下。

以前 review 是写代码顺带的一环,藏在流程里不显眼。现在写代码便宜到几乎免费,「这段代码到底对不对、是不是我们要的」这个判断,就成了整个交付流程里最贵、最不可替代的一步。

所以别再盯着「怎么让 AI 写得更多」了——那个问题基本解决了。真正该花力气的是另一边:把 review 重新设计一遍。 让确定性的检查去扛量,让 AI 去扛机械层,把人最稀缺的判断力,集中投到「这段代码是不是在做我们真正想做的事」上。

AI 写的代码谁来审?机械层交给 AI,量交给自动化门禁,意图——只能是人。而且得是清醒的、注意力没被第八个 PR 耗光的人。把流程改成能保住这份清醒的样子,这件事,没有任何模型能替你做。

参考资料:

• Code Review Is the Real Bottleneck of 2026 — And Most Teams Don’t See It
• The AI Code Review Bottleneck Is Already Here. Most Teams Haven’t Noticed.
• Code Review in the Age of AI — Addy Osmani
• The Specification as Quality Gate: Three Hypotheses on AI-Assisted Code Review (arXiv)
• How Accurate Is AI Code Review in 2026? — CodeAnt
• Scaling Code Reviews: Adapting to a Surge in AI-Generated Code — Salesforce Engineering
• 5 AI Code Review Pattern Predictions in 2026 — Qodo

实验前,这些人预测 AI 能让自己快 24%。干完之后,他们体感觉得 AI 让自己快了 20%。

实测结果:用 AI 的那组,慢了 19%。

这不是一个标题党段子。它是目前为止设计最干净的一个随机对照实验,而它的结论,跟你每天在朋友圈、在发布会、在融资 PPT 上看到的"10x 工程师"“生产力革命”,是相反的。

所以这篇文章想认真聊一件事:AI 编程到底是不是泡沫。我的答案会比较啰嗦——它在某些环节是真东西,在另一些环节是被吹大的气球,而把这两件事混在一起卖,才是真正的泡沫所在。

营销数字和实测数字,差在哪

先把两组数字摆出来。

营销侧的数字很漂亮:2026 年 84% 的开发者在用 AI 工具,AI 写了 41% 的新增商业代码,人均每周省下 3.6 小时。受控实验里,对那种"写一个函数"“生成一批单测"“铺一段样板代码"的细碎任务,提速 30%–55% 是常见的。

这些数字没造假。问题在于它们都是任务级的数字——把镜头怼到"写代码"这一个动作上,AI 确实快。

但你把镜头拉远到组织级,画面就变了。2025 年的 DORA 报告(Google 做的那份,样本是几千个真实团队)给出的结论很扎心:AI 让个人产出明显上涨——任务完成数 +21%,合并的 PR 数 +98%——但团队的交付速度,基本是平的。同一份报告里,AI 采用度和软件交付稳定性是负相关的。

更具体的两个数字:每个开发者引入的 bug 数,涨了 54%(过去的数据集里这个数字只涨 9%);每个 PR 引发生产事故的概率,涨了 242.7%——也就是说,每合一次代码,捅出线上事故的概率翻了三倍多。

同一件事,你站在不同的距离看,能得出完全相反的结论。营销永远站在最近的那个位置拍照。

“AI 写完,人来收拾"的隐性成本

营销数字漏掉的,是 AI 把工作从"写"挪到了"收拾”。这部分成本没消失,只是换了个名字,而且通常没人记账。

METR 那个实验里,AI 给的建议只有 39% 被开发者接受。剩下 61% 要么直接扔,要么改。对那些维护多年、有严格代码规范的成熟项目,AI 生成的代码常常"看着对、品味不对”——命名不一致、复用了不该复用的东西、绕过了项目既定的抽象。资深工程师得花时间一行行审、一行行改。这 19% 的慢,就是慢在这里。

这件事可以拆成一条很清楚的链:

flowchart LR
  A[AI 生成代码
很快] --> B[人来审查
+9% 工时]
  B --> C[补测试
1.7x 负担]
  C --> D[代码翻修
2x churn]
  D --> E[隐性技术债
第二年维护 4x]
  style A fill:#d4edda,stroke:#52a05f
  style E fill:#f8d7da,stroke:#d9534f

绿色那块是你看得见的收益,红色那块是你账上不记的成本。代码翻修率(code churn,指代码写完后不久就被改写或删掉的比例)从 2021 年的 3.3% 基线,涨到了 2024–2025 年的 5.7%–7.1%。Stack Overflow 2026 年初一篇文章把话说得很直白:AI 能让开发者 10x,但 10x 的是技术债。

还有一个更隐蔽的成本:信任。Stack Overflow 的开发者调查里,2025 年说自己信任 AI 输出的开发者只有 29%,比 2024 年掉了 11 个百分点。用得越多,越不敢信——因为大家都被那种"看着对其实不对"的代码坑过。一家 API 安全公司报告,在财富 50 强企业里,每月的安全问题发现数从 2024 年 12 月的 1000 个涨到 2025 年 6 月的 1 万个以上,半年 10 倍。

所以"AI 写完人来收拾"这句话本身没错,错在大家算账时只算了"AI 写"那一段省下的时间,没算"人来收拾"那一段花出去的时间。把两段都记上,很多团队的净收益就接近零,甚至为负。

它在哪儿是真的有用

如果只看上面这些,你会以为我要喊"泡沫"了。不。AI 编程有几个环节是实打实有用的,我自己每天在用,不是客套。

它真正强的地方,有一个共同特征:任务边界清楚、验证成本低、犯错代价小。

• 样板和胶水代码。 写一个 CRUD 接口、配一个 CI 流水线、把 JSON 转成另一种结构——这类活没有"品味"可言,对就是对,AI 生成完你一眼能看出对不对。
• 陌生领域的第一脚。 你要用一个没碰过的库,以前要翻半小时文档,现在让 AI 给个能跑的起步代码,你在它基础上改。它把"从零到能跑"这段最难受的冷启动给抹平了。
• 一次性脚本。 数据迁移、批量改名、跑个分析——写完用一次就扔的代码,质量要求本来就低,AI 在这里几乎没有副作用。
• 测试和文档。 给已有代码补单测、写注释。这类活枯燥、人容易偷懒,AI 不偷懒。
• 当个会说话的搜索引擎。 “这段报错什么意思"“这个正则怎么写”——它替代的是你切到浏览器那几下,省的是上下文切换。

注意,这几样的收益是真的,但它们加起来,是"省了 3.6 小时/周"那个量级的收益,不是"重新定义软件工程"那个量级的。是好用的电动工具,不是免费的劳动力。

它在哪儿被夸大了

被夸大的部分,也有共同特征:任务边界模糊、验证成本高、犯错代价大。

第一个被夸大的,是复杂系统里的改动。在一个十万行、跑了五年、到处是隐性约定的代码库里加一个功能,难的从来不是"写代码”,是"想清楚改哪、会牵连到什么、符不符合这个项目的脾气”。AI 没有这个项目的上下文记忆,它给你的是一个"局部看起来合理"的方案。METR 那 19% 的慢,慢的就是这个场景。

第二个被夸大的,是**“vibe coding"能进生产**。让 AI 全自动写、你只看结果不看过程,做个周末玩具没问题。但 Karpathy 自己在 2026 年初都把口径改了,提出"Agentic Engineering"来接替 vibe coding,核心多了一个词:结构化的人类监督。连造这个词的人都在往回收。

第三个被夸大的,是省下的时间能直接变成交付速度。这就是 DORA 报告里那个"个人产出涨、组织速度平"的悖论。原因不难懂:软件交付的瓶颈,本来就很少在"打字"这一步。需求扯不清、评审排不上、QA 跟不上、集成一团乱——AI 把打字这一步加速了,但水管最细的地方没变,整根水管的流量就没变。AI 不会修复一个团队,它只会放大这个团队本来的样子。流程好的团队用 AI 如虎添翼,流程烂的团队用 AI 翻车更快。

对初级工程师和团队结构的冲击

这部分我想说得重一点,因为它是真问题,而且没什么人愿意正面讲。

AI 最擅长的那些活——改 bug、写测试、铺样板——恰好就是过去初级工程师练手的活。这不是巧合,是结构性的撞车。后果已经在数据里:2026 年初级开发岗位的招聘明显收紧,计算机专业毕业生失业率涨到 6%–7%,22–25 岁这个年龄段的开发者岗位,自 ChatGPT 发布以来少了约 20%。

这里有一个会反噬的逻辑链。一个工程师能审查 AI 代码、能判断"这段看着对其实不对”,靠的是他当年亲手写过、亲手踩过坑积累的判断力。如果初级阶段的练手活全被 AI 接管了,新人没有了犯错和积累的场子,五年后,我们从哪里长出能审查 AI 的资深工程师?

我的判断是:初级岗不会消失,但它的定义被改写了。过去招初级,要的是"能写出代码";现在招初级,要的是"能判断 AI 写的代码对不对",这其实是过去对中级的要求。这等于把入行门槛抬高了一级,而那一级原本是靠在岗位上慢慢爬的。对个人,这意味着你得自己想办法补上"判断力"这一课——多读别人的代码、多关掉 AI 自己写一遍、刻意练习那些 AI 帮你跳过的环节。对团队,这意味着你不能再把初级当廉价产能,得把他们当"未来的资深"来带,而带人的成本,AI 一分钱都帮不上。

那么,泡沫论站不站得住

回到标题。我的结论分两层。

技术和产品这一层,不是泡沫。 AI 编程是真东西,它确实改变了一部分工作方式,这种改变不会回退。说它"永远不行"“只是噱头"的人,和说它"明年取代所有程序员"的人,犯的是同一个错——都在拿一个极端当全部。

但"叙事"和"估值"这一层,泡沫味很浓。 这里的泡沫有三块:

一是叙事泡沫。把任务级的提速数字,包装成组织级的革命,中间那道"个人产出涨、交付速度平"的鸿沟被系统性地隐藏了。

二是定价泡沫。GitHub Copilot 在 2026 年 6 月转向按 token 计费,一个动作就暴露了底裤:此前订阅制下,微软每个用户每月亏 20 美元。现在还便宜,是因为有人在替你补贴。补贴停了,价格会回到它真实的成本曲线上。

三是资本泡沫。这一轮 AI 基建里大量的"循环交易”——A 投资 B,B 拿钱回头买 A 的产品,在账面上凭空造出需求和营收——这是宏观层面的事,但它会传导下来:补贴退潮的时候,工具会涨价,产品会缩水,期望会落地。

flowchart TB
  A[AI 编程] --> B[技术层:真实
不是泡沫]
  A --> C[叙事层:任务级数字
包装成革命]
  A --> D[定价层:补贴掩盖
真实成本]
  A --> E[资本层:循环交易
虚增需求]
  style B fill:#d4edda,stroke:#52a05f
  style C fill:#fde7c2,stroke:#e8b23c
  style D fill:#fde7c2,stroke:#e8b23c
  style E fill:#f8d7da,stroke:#d9534f

所以"AI 编程是不是泡沫"这个问题本身问错了。正确的问法是:AI 编程这件事里,哪一部分是真东西,哪一部分是泡沫。 工具是真的,叙事是泡沫。等补贴退、估值回调、那批靠"AI 全自动"故事融资的公司洗一遍牌之后,留下来的,会是一个好用但不神奇的工具——大概就是今天的 IDE、版本控制、CI 在工程师工具箱里的位置。

给还在这行里的人三句实在话。第一,别信任何脱离了上下文的提速百分比,先问"这是哪一层的数字"。第二,把 AI 当电动工具用,在它强的环节(样板、胶水、冷启动、测试)放开用,在它弱的环节(复杂系统、架构判断、品味)自己上手。第三,如果你是初级,或者你在带初级,把"判断力"当成接下来几年最该投资的东西——因为当代码变得廉价,判断什么代码值得要,会变成最贵的能力。

泡沫会破,工具会留。把这两件事分清楚的人,不会在这一轮里慌,也不会在下一轮里被收割。

下面说说为什么。

GitHub Copilot：稳

优点：

• 和VS Code集成最好，不卡
• 企业合规，公司一般都愿意买单
• 代码补全中规中矩，不会出太离谱的东西

缺点：

• 对整个项目的理解不如Cursor
• 有时候补全太保守，不敢写多

适合谁： 大厂员工、需要合规的团队

Cursor：快

我现在主力用Cursor。

为什么？

1. Tab补全太爽了。它能预测你下一步要改哪个文件、哪一行，按Tab就跳过去了。用久了回不去普通IDE。

2. 对代码库理解深。问它"这个项目怎么加个新API"，它真的会去翻代码，不是瞎编。

3. Composer模式。告诉它"帮我重构这个模块"，它能同时改好几个文件。

缺点：

• 有时候太激进，改得多你得仔细review
• 月费$20，不便宜

适合谁： 追求效率的老手、个人开发者

Claude Code：聪明

Claude Code是后来者，但确实有点东西。

亮点：

• 理解能力最强，复杂逻辑描述清楚它就能写对
• 解释代码特别清楚
• 处理大项目上下文比较好

缺点：

• 速度比Cursor慢一点
• 还在迭代，功能没那么完善

适合谁： 需要处理复杂项目、喜欢AI帮忙想方案的人

我的使用习惯

日常写代码：Cursor 遇到复杂问题：切到 Claude Code 聊两句 公司项目：用公司配的 Copilot

不冲突，看场景切换就行。

一点建议

别把AI编程工具当"代码生成器"，把它当"结对编程的同事"。

• 它写的代码你得review
• 它不懂的地方你得教它（给上下文）
• 它写错了跟它说，它会改

用好了效率能提升2-3倍，用不好反而添乱。

有问题留言，我看到会回。

2025年，AI编程工具已经卷到飞起。Cursor、Windsurf、GitHub Copilot……每个都说自己是"最强AI编程助手"。

但当我第一次用上 Claude Code 时，我意识到：

这玩意儿不是来"辅助"我写代码的，它是来替我干活的。

Claude Code 是 Anthropic 推出的命令行AI编程工具。它不是IDE插件，而是一个独立运行在终端里的Agent。你给它一个任务，它会：

• 自己读代码
• 自己写代码
• 自己跑命令
• 自己修Bug
• 自己提交PR

这才是2025年该有的AI编程体验。

1. 安装：30秒上手

1
2
3
4
5
6
7
8

# 全局安装
npm install -g @anthropic-ai/claude-code

# 进入项目目录
cd your-project

# 启动
claude

首次启动会要求登录 Anthropic 账号，授权后就能用了。

费用：使用 Claude API 计费，Claude Sonnet 大约 $3/百万token，正常使用一天几毛钱。

2. 核心能力：不只是聊天

2.1 自主文件操作

Claude Code 可以直接读写你的项目文件：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

You: 帮我看看 src/api/user.ts 里有什么问题

Claude: 我来读取这个文件...
[读取 src/api/user.ts]

发现了几个问题：
1. 第23行：缺少错误处理
2. 第45行：类型定义不完整
3. 第67行：存在潜在的内存泄漏

要我修复吗？

You: 修

Claude: 
[编辑 src/api/user.ts]
已完成修复，主要改动：
- 添加了 try-catch 包装
- 补充了 UserResponse 类型定义
- 在 useEffect 中添加了 cleanup 函数

2.2 执行Shell命令

它能直接在你的终端跑命令：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

You: 跑一下测试，看看有没有挂的

Claude:
[执行 npm test]

测试结果：
✓ 45 passed
✗ 2 failed
  - user.test.ts: "should handle empty input"
  - auth.test.ts: "should refresh token"

要我修复这两个失败的测试吗？

2.3 Git 操作

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

You: 把今天的改动提交一下，写个清晰的commit message

Claude:
[执行 git status]
[执行 git diff]

我看到你改了这些文件：
- src/api/user.ts (修复类型问题)
- src/components/Login.tsx (添加loading状态)
- tests/user.test.ts (补充测试用例)

建议的 commit message:

[执行 git add . && git commit -m "fix: 修复用户API类型问题并完善登录组件

- 修复 user.ts 中的类型定义不完整问题
- 为 Login 组件添加 loading 状态处理
- 补充用户模块的单元测试"]

已提交。需要我 push 吗？

3. 实战场景：它能干什么

场景1：Debug 一个复杂Bug

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

You: 用户反馈说登录后会闪退，帮我查一下

Claude: 让我先看看相关代码...

[读取 src/pages/Login.tsx]
[读取 src/hooks/useAuth.ts]
[读取 src/store/authSlice.ts]

我需要看看错误日志：
[执行 npm run dev]
[执行 打开浏览器开发者工具 - 等待错误]

找到问题了！

在 useAuth.ts 第34行：
auth.user.name.toLowerCase()

当 user 对象存在但 name 为 null 时会崩溃。

修复方案：
auth.user?.name?.toLowerCase() ?? ''

要我修复吗？

场景2：重构整个模块

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

You: 把 src/utils 下的所有 JavaScript 文件迁移到 TypeScript

Claude: 收到，我来处理这个迁移任务。

[扫描 src/utils 目录]
发现 12 个 JS 文件需要迁移。

开始迁移...

[1/12] helpers.js → helpers.ts
- 添加参数类型注解
- 添加返回值类型
- 导出类型定义

[2/12] formatters.js → formatters.ts
...

[12/12] 完成！

[执行 npx tsc --noEmit]
类型检查通过，无错误。

[执行 npm test]
所有测试通过。

迁移完成！共修改 12 个文件，添加了 45 个类型定义。

场景3：从零实现一个功能

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

You: 帮我实现一个用户头像上传功能，要支持裁剪和压缩

Claude: 好的，我来实现这个功能。

首先分析一下需求：
1. 前端：选择图片 → 裁剪 → 预览 → 上传
2. 后端：接收文件 → 压缩 → 存储 → 返回URL

让我先看看现有的项目结构...

[读取 package.json]
[读取 src/components 目录结构]

我建议使用 react-image-crop 做裁剪，browser-image-compression 做压缩。

[执行 npm install react-image-crop browser-image-compression]

现在创建组件...

[创建 src/components/AvatarUploader/index.tsx]
[创建 src/components/AvatarUploader/ImageCropper.tsx]
[创建 src/components/AvatarUploader/styles.module.css]
[创建 src/api/upload.ts]

组件已创建完成。使用方式：

import { AvatarUploader } from '@/components/AvatarUploader'

<AvatarUploader 
  onUpload={(url) => updateUserAvatar(url)}
  maxSize={5} // MB
  aspectRatio={1}
/>

要我写个使用示例吗？

4. 高级用法

4.1 自定义指令（CLAUDE.md）

在项目根目录创建 CLAUDE.md，写入项目规范：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

# 项目规范

## 代码风格
- 使用 TypeScript 严格模式
- 组件使用函数式写法
- 状态管理使用 Zustand

## 命名规范
- 组件：PascalCase
- 函数：camelCase
- 常量：UPPER_SNAKE_CASE

## 提交规范
- feat: 新功能
- fix: 修复
- refactor: 重构
- docs: 文档

Claude Code 会自动读取这个文件，所有操作都会遵循你的规范。

4.2 并行任务

1

You: /parallel 同时帮我：1. 升级所有过期依赖 2. 修复 ESLint 警告 3. 补充缺失的测试

Claude Code 会同时执行多个任务，大幅提升效率。

4.3 持久记忆

Claude Code 会记住你的项目上下文：

1
2
3
4
5
6
7
8

You: 还记得上周我们讨论的那个性能优化方案吗？执行它

Claude: 记得，上周我们讨论了：
1. 将大型列表改为虚拟滚动
2. 添加 React.memo 包装
3. 使用 useMemo 缓存计算结果

我现在开始实施...

5. 与其他工具对比

我的建议：

• 日常补全：用 Copilot
• 复杂编辑：用 Cursor
• 项目级任务：用 Claude Code

6. 注意事项

安全性

Claude Code 有完整的权限控制系统：

• 读取文件：自动允许
• 写入文件：需要确认（可设置自动）
• 执行命令：需要确认（可设置白名单）
• 网络请求：需要确认

1
2

Claude: 我需要执行 rm -rf node_modules，允许吗？
[Allow] [Deny] [Allow All npm commands]

Token 消耗

复杂任务可能消耗大量 token。建议：

1. 任务描述要清晰具体
2. 大型重构分步进行
3. 使用 /compact 命令压缩上下文

7. 总结

Claude Code 代表了 AI 编程工具的新方向：

从"辅助编码"到"自主编码"

它不是在你旁边提建议的助手，而是一个能独立完成任务的程序员。

适合场景：

• 大型代码重构
• 跨文件修改
• 自动化运维任务
• 快速原型开发

不太适合：

• 需要精细控制的核心算法
• 涉及敏感数据的操作
• 完全没有代码基础的用户