Claude Code 日安装量 2900 万次，但大多数开发者仍然在用“聊天框模式”使用它——问一句，答一句，确认一句，改一句。这不是 AI 编程，而是 AI 打字。真正的效率提升，来自从“聊天框”到“Agent 工作流”的思维转变。

聊天框模式的本质问题：人在干活，AI 打辅助

回顾典型的使用场景：描述需求、看 AI 输出、判断对不对、发现不对重新描述、确认后再执行、出了问题再回退。整个过程中，决策权在人，执行权也在逐步回到人手里。AI 最多算个打字速度快的实习生。

正如 Lisa1399 在《Claude Code Best Practice》中说的：“AI 提效不了多少，本质上还是人在干活，AI 打辅助。” 表面上每次都在用 AI，实际上 60% 的时间花在“指挥”上，AI 花 40% 的时间在“执行”，而每一步都必须盯着。这和从 Stack Overflow 复制粘贴代码没有本质区别，只是把复制粘贴变成了对话确认。

生产环境中还遇到过更离谱的情况：让 Claude Code 改一个数据库迁移脚本，一句“帮我加上字段默认值”，它改了三个 migration 文件，逐个确认后跑 migrate 发现顺序冲突——因为中间还有一个没有告诉它的 migration 也依赖那个字段。

这就是聊天框模式的致命伤：AI 的视野被你的描述框死了。 你说一句，它看一句。你不说，它就看不到上下文之间的关联。

Boris Cherny 的答案：不是更花哨的聊天框，而是 Agent 工作流

Claude Code 创始人 Boris Cherny 在斯坦福 CS146S 课上明确指出：Claude Code 的答案“不是做一个更花哨的聊天框”，而是选择不同的路径——agentic workflow。

何为 Agent 工作流？用大白话说：你给 AI 一个目标，而不是一步步指令；AI 自己规划路径、读代码、写代码、跑测试、修 bug，整个过程它自己闭环。

第一次体会到 Agent 工作流的威力，是改一个两年前写的 Node.js 后端。项目根目录下放了一个 AGENTS.md，写下技术栈、目录约定、代码规范。然后直接给 Claude Code 一句话：“这个项目的测试覆盖率太低了，帮我把核心业务逻辑的单元测试补上，测试框架用 vitest。” 它先读了 AGENTS.md 了解项目结构，自己扫了 src/ 下的所有文件，识别出核心业务模块，逐个模块写测试，写完跑测试，测试失败就自己修。整个过程大约十五分钟，写了 23 个测试用例，19 个直接通过，剩下 4 个它自己修了两轮也过了。同样的事情如果用聊天框模式，估计得花一个半小时。

这就是 Agent 工作流的核心差异——AI 拥有了执行链路的自主权，而不是每一步都等你拍板。

从聊天框到 Agent 的三步进化

这里总结出一条经过踩坑验证的进化路径。

第一步：学会给上下文，而不是给指令

聊天框模式最典型的特征就是一句一句下指令：“帮我改这个函数”“把这个变量名改一下”“加上错误处理”。Agent 工作流的第一步，是把上下文给足，让 AI 自己判断该做什么。

在项目里标配一个 CLAUDE.md（或 AGENTS.md），里面写三样东西：

# 项目上下文

## 技术栈
- Runtime: Node.js 20 + TypeScript
- 框架: Fastify
- 数据库: PostgreSQL + Drizzle ORM
- 测试: vitest

## 目录约定
- `src/modules/` 下按业务模块分目录
- 每个模块必须有独立的 router、service、repository
- 错误处理统一走 `src/utils/errors.ts`

## 当前优先级
- 提高核心模块测试覆盖率到 80%
- 修复已知的 3 个内存泄漏问题

有了这个文件，每次只需要说“帮我把 users 模块的测试补上”，它就知道该读哪些文件、用什么框架、遵循什么规范。

这一步的价值在于：你从“每一步的指挥官”变成了“初始条件的设定者”。 AI 不再需要你手把手告诉它每一步怎么做，它自己能从上下文推断出合理的工作路径。

小提示： 团队中一位后端同事，刚开始用 Claude Code 时每次对话从零开始，平均对话轮次 12 轮。写了 CLAUDE.md 后，同样任务轮次降到 3 轮。对话轮次越少，说明 AI 的自主性越高。

第二步：用 TodoWrite 规划任务，而不是即兴指挥

以前让 Claude Code 做复杂任务（如“重构认证模块”），它上来就开始改代码，改到一半发现不对退回去，改到后面发现前面改的有问题又退回去。这种来回折腾，本质上是因为没有一个清晰的任务规划。

学了一招：先让 Claude Code 制定计划，再执行。

# 在 Claude Code 中输入
帮我重构认证模块。先列出具体步骤让我确认，确认后再逐步执行。

它会给出一个类似这样的计划：

1. 分析现有认证相关文件，列出所有涉及的模块
2. 设计新的认证中间件接口
3. 创建新文件 src/modules/auth/middleware.ts
4. 迁移现有路由中的认证逻辑到中间件
5. 更新测试
6. 运行全量测试确认无回归

确认计划后，它就按步骤执行。执行过程中它会自己标记完成状态，遇到问题也会按计划的逻辑去处理，而不是随机应变。

这一步的价值在于：把 AI 从“即兴发挥”变成了“按计划执行”。 你不需要在每一步都做决策，只需要在计划阶段做一次审核。

小提示： 生产环境有一次重构支付模块，Claude Code 列了 8 个步骤，审了一遍发现第 3 步和第 5 步有依赖关系冲突，调整后让它执行。最终 25 分钟完成，零回归。如果用聊天框模式一步步来，保守估计两小时。

第三步：让 AI 自己闭环，而不是等你验收

聊天框模式的最后一个习惯是：AI 做完了你来看，发现问题再让它改。效率瓶颈在人。Agent 工作流的终极形态是：AI 自己写、自己测、自己修，直到通过为止。

# 关键是加上测试闭环的指令
帮我修复 src/modules/orders/ 里的 3 个已知 bug。
修完后跑测试，如果有失败就自己修复，全部通过后再通知我。

此时 Claude Code 的工作模式变成：

1. 读代码，定位 bug
2. 写修复
3. 跑测试
4. 测试失败？分析原因，改代码
5. 再跑测试
6. 全部通过 → 输出结果摘要给你

你从“每一步的审核员”变成了“最终结果的查看者”。

这一步有一个关键前提：项目必须有完善的测试。如果没有测试，AI 写完代码你根本不知道对不对，最后还是得自己验收。测试覆盖率是 Agent 工作流的地基。

我们团队实际跑通的 Agent 工作流

场景：每周需求迭代——产品经理提需求，用 Claude Code 实现核心代码。

# 1. 需求转技术方案（人审核）
"根据下面的需求描述，生成技术方案。关注：涉及哪些文件要改、新增哪些接口、数据模型是否需要变更。
需求：xxx
参考 CLAUDE.md 中的项目规范。"

# 2. 技术方案确认后，进入执行
"按上面的技术方案执行，每完成一个步骤标记 [done]。
完成后运行全量测试，修复所有失败用例。
最后输出变更文件清单和测试结果。"

# 3. 结果审查
Claude Code 输出后，花 5 分钟看变更文件清单和测试结果。
如果有问题，针对性地指出让它修。
如果没问题，直接 git commit。

平均下来，一个中等复杂度的需求（涉及 5-8 个文件），从方案到代码完成大约 20-30 分钟。 同样的工作，纯手写大概 2-3 小时，聊天框模式大概 1-1.5 小时。

这不是什么魔法，就是把 AI 当 Agent 用，而不是当聊天机器人用。

一个容易踩的坑：不要过度信任 Agent

Agent 工作流不是万能的。生产环境里有一次让 Claude Code 自己闭环修复一批 lint 报错。它确实把所有报错都修了，但其中有几个地方它的修法是加了 // eslint-disable 注释——技术上报错消失，但实际上问题被掩盖了。

从此加了一条规矩：Agent 可以自己闭环执行，但最终的 diff 必须人工 review。

# 标准流程
Agent 执行 → 输出 diff → 人工 review → 确认后 commit

Agent 的价值不是替代你的判断力，而是替代你的重复劳动。 你不需要自己一行行写代码，但你需要判断代码写得对不对。这个定位很重要，搞错了就会出事。生产环境还遇到过 Agent 把测试用例改得更容易通过的情况——不是修 bug，而是降低了测试标准。这在没有人工 review 的情况下很容易漏过去。

Claude Code 日装 2900 万，但深度使用率可能不到 10%

日安装量 2900 万这个数字很吓人，但仔细想想——这 2900 万&里有多少人是装完之后用了两天就回到手动写代码的？身边至少五六个同事，装了 Claude Code，试了几次，觉得“也就那样”，然后弃了。问他们怎么用的，基本都是聊天框模式：问一句，答一句，觉得答得不好就不问了。

这不是工具的问题，是用法的问题。

从聊天框模式到 Agent 工作流，不是一个功能开关的切换，而是一个思维模式的转变。你需要从“我是操作者”转变为“我是规划者”，从“我写代码，AI 辅助”转变为“AI 写代码，我审核”。这个转变需要刻意练习，但一旦适应，就再也回不去了。

FAQ

• Q1：Agent 工作流对项目有什么硬性要求？
  最核心的要求是测试覆盖率。没有测试，AI 改完代码无法自动验证，Agent 自闭环就跑不起来。建议先把核心业务逻辑的测试覆盖率提到 60% 以上，再开始用 Agent 工作流。其次是一个清晰的 CLAUDE.md 项目说明文件，相当于给 AI 的入职手册。
• Q2：聊天框模式是不是完全没用？
  不是。对于一次性小任务——比如写一个正则、解释一段代码、生成一个 shell 脚本——聊天框模式完全够用，甚至更高效。Agent 工作流的优势在复杂、多文件、需要上下文关联的任务上。分清楚任务复杂度，选择合适的模式，才是真正的高手。
• Q3：CLAUDE.md 要写多详细？
  不需要写成文档。经验是控制在 50 行以内，写三样东西：技术栈和框架版本、目录结构约定、当前阶段的优先级任务。太详细反而会让 AI 抓不住重点。可以参考 OpenAI 的 Codex 和 Claude Code 官方文档里的 AGENTS.md 模板。
• Q4：用 Agent 工作流会不会写出很多意料之外的代码？
  会的。所以前面强调了 diff review 这个环节。习惯是让 Agent 执行完之后，跑 git diff --stat 先看变更文件清单，确认都是预期要改的文件，再看具体 diff。如果 Agent 改了不期望的文件，说明任务描述不够精确，下次拆分得更细就行。
• Q5：团队里其他人还在用聊天框模式，怎么推动转变？
  最有效的方式是做一次对比演示。拿同一个需求，A 同事用聊天框模式做，B 同事用 Agent 工作流做，计时对比。团队试过一次，同一个中等需求，A 用了一小时四十分钟，B 用了二十二分钟。结果一出来，不用推，大家自己就切换了。

工具就摆在那里，2900 万人已经装了。但安装不等于会用，会用不等于用好。从聊天框到 Agent 工作流，差的不是技术门槛，是思维模式。愿意多花十分钟写一个 CLAUDE.md，后面每次开发能省一个小时。这笔账，算得过来。

我是码哥字节，十年后端开发，现在每天用 Claude Code Agent 模式写代码。如果这篇文章帮到了你，欢迎转发给你身边还在用聊天框模式的同事。