那天晚上我赶着重构一个用户权限模块思路是把原来散落在十几个文件里的权限校验逻辑收拢成一个 middleware。我打开 Claude Code敲了一句「帮我重构一下用户权限校验的代码」。它给了我一堆建议列了五个文件要改哪些函数。我说「好的改吧」。它改了第一个文件改得还行。然后我继续说「下一个」。改完第二个发现和第一个改法有冲突。我退回去重新说「先看下整体结构再改」。它又给我分析了一通。我又说「好按这个来」……如此反复了四十分钟最后我关掉 Claude Code自己动手写二十分钟搞定了。这一刻我才真正理解 Claude Code 创始人 Boris Cherny 在斯坦福 CS146S 课上说的那句话——很多人把 Claude Code 用成了「纯聊天框」看似提效实则效率不高。更扎心的是Claude Code 日安装量已经达到 2900 万次。这意味着有海量开发者每天都在用这个工具但其中绝大多数人可能还在用我凌晨两点的那种方式问一句答一句确认一句改一句。这不是 AI 编程这是 AI 打字。聊天框模式 vs Agent 工作流模式对比聊天框模式的本质问题人在干活AI 打辅助我回顾了自己那四十分钟到底在干什么。拆解下来大概有这么几个动作描述需求、看 AI 输出、判断对不对、发现不对就重新描述、确认后再让它执行下一步、出了问题再回退。整个过程中决策权在我执行权也在逐步回到我手里。AI 最多算个打字速度快的实习生。Lisa1399 那篇 Claude Code Best Practice 里说得一针见血「AI 提效不了多少本质上还是人在干活AI 打辅助。」我当时的状态就是这种——表面上每次都在用 AI实际上我花 60% 的时间在「指挥」AI 花 40% 的时间在「执行」而它执行的每一步我都得盯着。这和我用 Stack Overflow 复制粘贴代码没有本质区别区别只是把复制粘贴变成了对话确认。聊天框模式下的人力分配流程我们生产环境里还遇到过更离谱的情况。有一次让 Claude Code 帮我们改一个数据库迁移脚本我一句「帮我加上字段默认值」它把三个 migration 文件都改了我逐个确认完跑 migrate 发现顺序冲突。原因是它改的是最新三个 migration但中间还有一个我没告诉它的 migration 也依赖那个字段。这就是聊天框模式的致命伤AI 的视野被你的描述框死了。 你说一句它看一句。你不说它就看不到上下文之间的关联。Boris Cherny 的答案不是更花哨的聊天框而是 Agent 工作流Boris Cherny 在斯坦福那节课上讲了一个关键判断Claude Code 的答案「不是做一个更花哨的聊天框」而是选择不同的路径——agentic workflow。这句话我花了一个多月才真正消化。什么叫 Agent 工作流用大白话说就是你给 AI 一个目标而不是一步步指令AI 自己规划路径、读代码、写代码、跑测试、修 bug整个过程它自己闭环。我第一次体会到 Agent 工作流的威力是改一个从没碰过的老项目。那是一个两年前写的 Node.js 后端我自己都记不清代码结构了。如果用聊天框模式我得先自己读一遍代码再告诉 AI 每个文件要怎么改。那我换了个方式。我在项目根目录下放了一个 AGENTS.md把项目的技术栈、目录约定、代码规范写在里面。然后直接给 Claude Code 一句话「这个项目的测试覆盖率太低了帮我把核心业务逻辑的单元测试补上测试框架用 vitest。」它先读了 AGENTS.md 了解项目结构然后自己扫了 src/ 下的所有文件识别出核心业务模块接着逐个模块写测试写完跑测试测试失败就自己修。整个过程我泡了杯咖啡回来看结果大概十五分钟它写了 23 个测试用例19 个直接通过剩下 4 个它自己修了两轮也过了。Agent 工作流执行时序同样的事情如果用聊天框模式我估计得花一个半小时。 因为我得一个个文件告诉它「这个要测」一个个函数告诉它「用什么 mock」一个个失败告诉它「哪里错了」。这就是 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 的时候每次对话都是从零开始——新开一个对话重新描述一遍项目背景。后来我让他写了 CLAUDE.md同样的任务对话轮次从平均 12 轮降到了 3 轮。对话轮次越少说明 AI 的自主性越高。第二步用 TodoWrite 规划任务而不是即兴指挥这个是我踩坑最深的一个点。以前我让 Claude Code 做一个复杂任务比如「重构认证模块」它上来就开始改代码。改到一半发现不对退回去重新来。改到后面发现前面改的有问题又退回去。这种来回折腾本质上是因为它没有一个清晰的任务规划。后来我学了一招先让 Claude Code 制定计划再执行。在 Claude Code 中输入帮我重构认证模块。先列出具体步骤让我确认确认后再逐步执行。它会给你一个类似这样的计划分析现有认证相关文件列出所有涉及的模块设计新的认证中间件接口创建新文件 src/modules/auth/middleware.ts迁移现有路由中的认证逻辑到中间件更新测试运行全量测试确认无回归你确认了计划它就按步骤执行。执行过程中它会自己标记完成状态遇到问题也会按计划的逻辑去处理而不是随机应变。Agent 任务规划的树形分解结构这一步的价值在于把 AI 从「即兴发挥」变成了「按计划执行」。 你不需要在每一步都做决策只需要在计划阶段做一次审核。我们生产环境有一次重构支付模块用的就是这个方式。Claude Code 列了 8 个步骤我审了一遍发现第 3 步和第 5 步有依赖关系冲突调整后让它执行。最终整个重构用了 25 分钟零回归。如果用聊天框模式一步步来保守估计得两个小时。第三步让 AI 自己闭环而不是等你验收聊天框模式的最后一个习惯是AI 做完了你来看你看了发现问题再让它改。这个过程本质上还是人在做验收效率瓶颈在你。Agent 工作流的终极形态是AI 自己写、自己测、自己修直到通过为止。具体操作很简单关键是加上测试闭环的指令帮我修复 src/modules/orders/ 里的 3 个已知 bug。修完后跑测试如果有失败就自己修复全部通过后再通知我。这时候 Claude Code 的工作模式就变成了读代码定位 bug写修复跑测试测试失败分析原因改代码再跑测试全部通过 → 输出结果摘要给你你从「每一步的审核员」变成了「最终结果的查看者」。这一步有一个关键前提你的项目得有完善的测试。如果没有测试AI 写完代码你根本不知道对不对最后还是得自己验收。所以我一直跟团队说测试覆盖率是 Agent 工作流的地基。 没有测试Agent 就是一辆没有刹车的车。Agent 自闭环测试修复循环
