Claude Code 实战复盘：从 Vibe Coding 到 Agentic Engineering，我的血泪教训与工作流升级

2025 年 2 月，Andrej Karpathy 在推文中抛出一个新词——“Vibe Coding”（氛围编程），意味着一种全新的编程方式：完全凭感觉，用自然语言向 AI 描述需求，“忘掉代码的存在”。这条推文瞬间引爆了开发者圈。短短几周，Y Combinator 里 25% 的创业公司已经开始用这种方式写代码。整个社区都在沸腾：AI 终于让编程变成了“动动嘴皮子就行”的事。

仅仅一年后，Karpathy 自己却说：Vibe Coding 这个词已经过时了。 他提出一个新概念——“Agentic Engineering”，即智能体工程。究竟发生了什么？为什么“开口就能写代码”这么爽的事，不到一年就被认为不够用了？

我使用 Claude Code 做日常开发已有大半年，完整经历了从“天哪这也太爽了”到“等等，好像哪里不对”再到“原来如此”的过程。这篇文章不是概念科普，而是踩了无数坑之后的真话。

Vibe Coding 的爽感，真实不虚

先说好的一面。Vibe Coding 确实爽，特别爽。

我第一次用 Claude Code 大概在去年下半年。在此之前我用过 Copilot、Cursor，体验就是“有个聪明的补全工具”。但 Claude Code 完全不同——它在终端里直接操作你的整个代码仓库。你说一句“帮我把这个项目加上用户注册功能”，它就自己去读文件、理解架构、写代码、跑测试、修 bug，你在一旁端着咖啡看戏就行。那种感觉就像从手动挡直接切换到了自动驾驶。

Karpathy 说过一段非常精准的话：

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

忘掉代码的存在——这句话太对了。你不需要操心用什么设计模式，不用纠结变量命名，更不需要在脑子里模拟程序的执行流程。你只需要说出你想要什么，剩下的全部交给 AI。

那个阶段我做了一个小实验：把一个以前需要两天才能完成的 CRUD 模块，从建表到接口再到前端页面，全过程用 Claude Code 两小时搞定。代码能跑，测试通过，我当场就在工作群里发了一句“效率起飞”。

’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

这种效率提升是真实的，并非我一个人的幻觉。Claude Code 的创造者 Boris Cherny 曾公开分享过他的数据：30 天完成了 259 个 PR，每一行代码都由 AI 编写。 40,000 行新增，38,000 行删除，497 次提交，他自己一行代码都没动。Stack Overflow 2025 年调查显示，84% 的开发者已经在使用 AI 编程工具，这件事已经不需要再争论，AI 编程已是主流。

数据揭示的残酷真相：你可能更慢了

接下来要说点让人不舒服的了。

独立研究机构 METR 做过一项对照实验：他们找来 16 位经验丰富的开发者，让他们用 AI 完成 246 个任务。结果令人意外：使用 AI 的开发者整体慢了 19%。 更扎心的是，这群人自己感觉快了 20%。 慢了将近两成，却觉得快了两成。你细品这个反差。

这并非孤例。Google DORA 2024 报告覆盖了更广泛的样本，发现：AI 采纳率每增加 25%，团队交付速度下降 1.5%，系统稳定性下降 7.2%。此外，AI 协作生成的 Pull Request 出现问题的概率是人类独立完成的 1.7 倍。

’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

我自己就踩过这样的坑。有一次我用 Claude Code 一口气生成了整个通知模块——消息队列、推送服务、模板引擎，差不多两千行代码。当时觉得爽爆了，半个小时搞定了原本一个星期的活儿。然后噩梦就开始了。上线第二天，消息重复发送；第三天，模板变量解析出错；第四天，队列积压吃光了内存。每一个 bug 我都必须回头去读 AI 写的代码，花在调试上的时间远比一开始自己动手写还要多。更要命的是，因为代码不是我亲手写的，我对那段逻辑完全没有直觉——哪里可能藏着坑、哪个边界条件没处理、哪个依赖是隐含的，我一无所知。

这就是 Vibe Coding 的真相：它让你写代码的速度飞起，但不一定让你交付软件的速度更快。

Google Chrome 的工程经理 Addy Osmani 说了一句大实话：

“You wouldn’t let a first-year junior dev architect your entire system unsupervised; similarly you shouldn’t blindly trust an AI’s code without oversight.”

换成人话：你不会让一个刚毕业的实习生独自去做整个系统的架构，那你凭什么让 AI 这么干？

转折时刻：我为何放弃 Vibe Coding

我的转折点出现在一次代码评审。团队里一位伙伴也用 Claude Code，他提交了一个用户权限模块的 PR，大约 800 行。我 review 时第一眼看过去挺整齐——命名规范、有注释、测试也覆盖了。但我问他：“为什么这里用 RBAC 而不是 ABAC？”他愣住了。他不知道，AI 选的。我再问：“这个权限缓存的失效策略是怎么设计的？”他还是说不上来。他说：“我就跟 Claude 说‘加个权限系统’，它自己弄的。”

那一刻我意识到一个核心问题：Vibe Coding 的致命伤不是代码质量，而是知识断层。 当你不知道 AI 为什么做出某个决定时，你就无法评估这个决定是否正确，更无法在出问题的时候动手修复。

’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

Peter van Hees 说得更加直接。他提出了一个 AI 开发者成熟度模型，把人与 AI 的协作方式分成五级：

级别 名称 做什么
Level 1 Prompter 给提示词，拿结果
Level 2 Planner 稍加规划再给提示词
Level 3 Interrogator 不急着让 AI 写代码，先逼问它理解需求
Level 4 Architect 自己做架构决策，让 AI 执行
Level 5 Orchestrator 编排多个 AI Agent 协作完成复杂系统

他的原话很刺耳：“Vibe coding is Level 1 and Level 2 behavior dressed up as a movement. The serious work starts when you stop vibing and start specifying.”氛围编程就是把一级和二级行为包装成一场运动。真正的工作，从你停止氛围、开始写规格的那一刻才开始。

智能体工程：不只换个名词，而是工作方式的质变

2026 年初，Karpathy 与红杉资本合伙人 Stephanie Zhan 在一次对谈中提出“Agentic Engineering”（智能体工程）。这不仅仅是换个说法，而是根本性的思维转变。Vibe Coding 的核心是：“我描述需求，AI 写代码”——你是个说话的人，AI 是写代码的机器。Agentic Engineering 的核心则是：“我设计系统，AI 是系统的一部分”——你仍是工程师，AI 是你的工程工具，不是替代品，而是能力的延伸。

Karpathy 自己的解释是：Agentic Engineering 的关键在于“保留了专业软件工程的质量标准，同时用 Agent 来大幅加速。你依然负责方向、判断和质量把控”。坦白讲，一开始我也不太理解这个区别。后来读了 Addy Osmani 的文章才顿悟——差别不在工具，而在于工作流。

Vibe Coding 的工作流

你：帮我写个登录页  
AI：[噼里啪啦写代码]  
你：看起来能跑，提交了

Agentic Engineering 的工作流

你：[先写一份 spec]  
  - 需求：用户登录页  
  - 支持微信 OAuth 和 GitHub OAuth  
  - 错误处理：超时 3 秒重试，最多 3 次  
  - 验收标准：测试覆盖率 >80%  
你：按照 spec 实现  
AI：[读 spec → 规划步骤 → 逐步实现 → 跑测试 → 修 bug]  
你：[审查结果，确认质量]

看出区别了吗？前者是扔一个模糊的需求然后祈祷，后者是先想清楚再让 AI 执行。 Addy Osmani 归纳得很精辟：最好的结果来自于把“经典的软件工程纪律”应用到 AI 协作中：设计先于编码、写测试、用版本控制、维护标准。 这些实践不仅没有过时，反而在 AI 替你写一半代码的时候变得更加重要。

Claude Code 如何落地 Agentic Engineering：我的实战方法

讲概念没意思，直接说我现在的做法。

第一步：CLAUDE.md——给 AI 的项目百科

我用 Claude Code 做的第一件事，不是让它写代码，而是帮我建立 CLAUDE.md。这个文件就是项目的百科全书——代码规范、架构决策、禁止事项、团队约定，全部写进去。Boris 的原话是：“每当我们发现 Claude 做错了什么，就会记录进 CLAUDE.md，这样它下次就知道该怎么做了。”这叫作复利工程：知识持续积累，AI 犯过的错误不会重犯。

’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

第二步：规约先行，代码后置

现在我再也不会说“帮我写个 XX”这种指令了。我改成了：

在开始写代码之前，请你先读一下现有架构，
然后给我一份实现计划。我们讨论确认后再动手。

这就是 Boris 所说的“Plan 模式”——连按两次 Shift+Tab，Claude 只做规划，不写代码。你在这个模式下跟它来回讨论方案，确定了再切换到自动执行模式。这一步看着慢，实际省下的调试时间远超你的想象。

第三步：Git Worktree + 多终端并行

Vibe Coding 时期，我一个终端只跑一个 Claude 实例。现在我用 Git Worktree 开出多个工作区：

终端 1（worktree: feature-login） → 实现登录功能  
终端 2（worktree: fix-bug-123）   → 修 bug  
终端 3（worktree: add-tests）     → 写测试

每个终端跑一个独立的 Claude Code 实例，互不干扰。Boris 自己同时跑 10-15 个会话，我没有那么极端，通常 3-5 个就够了。但关键是——每个任务都有明确的 scope 和验收标准，不是“随便搞搞”。

第四步：反馈闭环

Boris 说过一句掏心窝子的话：“只要有反馈闭环，最终结果的质量会提升 2-3 倍。”反馈闭环就是给 AI 一个验证自己工作成果的方法。让 Claude Code 写完代码后自己跑测试、自己检查类型、自己验证输出，而不是写完了扔给你，让你亲自去看对不对。

具体做法？Hooks。在 Claude Code 里配置一个 PostToolUse 钩子，每次 AI 写完文件就自动跑格式化和 lint：

{  
  "hooks": {  
    "PostToolUse": [  
      {  
        "matcher": "Write|Edit",  
        "hooks": ["npm run lint --fix $FILE_PATH", "npm run test"]  
      }  
    ]  
  }  
}

这样 AI 每次改动，立刻就知道自己的修改有没有破坏什么，它自己就能纠错，无需等你过来发现问题。

实际效果：这些改变到底值不值得

说了这么多方法论，来看数据。Anthropic 内部有一个很硬核的数字：Claude Code 这个项目本身，大约 90% 的代码是由 Claude Code 自己写的。 但注意这个“但”——“写代码”这个环节由 AI 完成，而架构决策、需求拆解、质量把控，仍然由人类工程师来做。这就是 Agentic Engineering 的精髓：不是 AI 替代你，而是 AI 在明确的框架内自主执行，你在框架外做判断。

Boris 的 30 天 259 个 PR 也是同样的逻辑。他不是打开 Claude Code 说“帮我写个编程工具”然后就撒手不管。他做的事情是：

  1. 维护一份持续更新的 CLAUDE.md
  2. 每次任务开始前先进入 Plan 模式
  3. 用 Git Worktree 隔离每个任务
  4. 用 Hooks 建立自动验证闭环
  5. 用斜杠命令把重复流程自动化

他把自己变成了一个编排者，而不是一个写代码的人。

再看 StrongDM 的案例。2025 年 7 月，他们成立了一个 AI 团队，只立下三条规则：

  1. 代码不能由人类编写
  2. 代码不能由人类审查
  3. 仓库里只允许存在三个 Markdown 规格文件和零行人类代码

Simon Willison（Django 联合创始人）把这种模式叫作“Dark Factory”——暗黑工厂。一个没有人写代码、没有人审查代码的软件生产系统。但我对这个案例持保留态度。成本是每个工程师每天 1000 美元的 token 费用，而且 ThoughtWorks 在其技术雷达里将“AI 编码 Agent 团队”放在“评估”阶段——值得探索，但不建议在生产环境大规模使用。Gartner 也预测到 2027 年底，40% 的 AI Agent 项目会被取消。Dark Factory 是极限，不是目标。 绝大多数团队，包括 Anthropic 自己，走的都是“人做判断、AI 做执行”的中间路线。

必须吐槽：Claude Code 的槽点也不少

夸了半天，该骂的也得骂。

槽点一：Token 费用真的贵。 用 Opus 模型做日常开发，一天的 token 费用能让你肉疼。Boris 那种 10-15 个并行会话的玩法，普通开发者根本烧不起。我自己是日常任务用 Sonnet，只有复杂的架构决策才上 Opus。

槽点二：长任务还是会跑偏。 虽然 Opus 4.7 在长任务执行上进步巨大，但超过一小时的自主运行，AI 仍然有概率偏离原定计划。它不会告诉你“我跑偏了”，而是自信地继续往下走。所以长时间任务必须设置 checkpoint——Boris 的 Stop Hooks 就是干这个的。

槽点三：对项目的理解有天花板。 Claude Code 的上下文窗口再大，也不可能吃透一个运行了十年的老项目的所有隐含逻辑。我曾经让它重构一个有五年历史的模块，它改完后编译通过，但破坏了一个从未被写进文档的边界条件，结果线上直接炸了。

槽点四：社区的真实反馈也不全是好评。 Hacker News 上有人说了句大实话：“AI 生成的代码有一种独特的味道——看起来很干净，但缺少意图。每个函数都在做正确的事，但整个系统缺少一个统一的灵魂。” Reddit 上更直白：“Vibe coding 让你觉得快了，但你花在调试和返工上的时间，抵消了所有节省。” Stack Overflow 2025 调查显示，84% 的开发者在用 AI 工具，但 46% 不信任 AI 输出的准确性。

’ fill=’%23FFFFFF’%3E%3Crect x=‘249’ y=‘126’ width=‘1’ height=‘1’%3E%3C/rect%3E%3C/g%3E%3C/g%3E%3C/svg%3E)

说这些槽点不是为了劝退你，而是想说——弄清楚工具的边界，比知道工具的能力更重要。

谁适合，谁不适合

给一个明确的判断。

适合用 Agentic Engineering 方式的人

  • 独立开发者 / 小团队：人少事多，AI 能帮你一个人掰成三个人用。前提是你愿意花时间建立 CLAUDE.md 和 spec 文档体系。
  • 做大量 CRUD / 重复性工作的后端开发者：这是 AI 最擅长的领域，效率提升立竿见影。
  • 愿意改变工作方式的人：从“写代码”到“编排 Agent”，这可不是买一个工具就能搞定的事，而是工作习惯的全面重构。

不适合的人

  • 刚入行的初级开发者：你自己还不知道什么是对的时候，怎么判断 AI 给你的对不对？Addy Osmani 那句“不让一年级实习生架构系统”说的就是这个道理。
  • 做核心算法 / 高频交易 / 安全关键系统的人：这些领域的错误成本太高，AI 生成的代码必须逐行审查，反而比手写更慢。
  • 不想改变工作流的人：如果你就想在 IDE 里按 Tab 补全代码，那 Copilot 可能比 Claude Code 更适合你，不用折腾什么 Agentic Engineering。

我的最终判断

用了大半年 Claude Code，从 Vibe Coding 走到现在的 Agentic Engineering 方式，我最大的体会是：工具从来不是瓶颈，思维方式才是。 Vibe Coding 和 Agentic Engineering 的区别，不是“用不用 AI”的区别，而是“被动接受 AI 输出”与“主动设计 AI 工作流”的区别。前者你是在消费 AI 的能力，后者你是在构建一个包含 AI 的工程系统。

Karpathy 说 2025 年 12 月是 Agentic Coding 的拐点——“他已经不记得上一次纠正模型是什么时候了”。这话有点乐观，我自己几乎每天都在纠正 Claude Code。但趋势是对的：AI 越来越强，它能自主完成的事情越来越多，人类工程师的角色正在从“写代码”转向“设计系统、做判断、把控质量”。

Boris 说过一句我认为最有价值的话：“Claude Code 能够完美地开箱即用，所以我个人并没有做太多的定制化修改。使用 Claude Code 并没有所谓的唯一正解。” 这话的深意在于：工具本身不是答案，你怎么用工具才是。

如果你还停留在 Vibe Coding，我的建议是：现在就停一下，花一整天时间把你的项目规范写进 CLAUDE.md，给你下一个任务写一份 spec，然后在 Plan 模式下跟 Claude 讨论方案。做完这些再动手写代码。试试看，你可能会发现，在动手之前多想的半个小时，比动手之后省下的五个小时更值钱。

参考资料：

  • Andrej Karpathy, Vibe Coding 推文, 2025.02
  • Andrej Karpathy & Stephanie Zhan, From Vibe Coding to Agentic Engineering, Sequoia Capital 对谈, 2026
  • Addy Osmani, Agentic Engineering, 2026
  • Addy Osmani, Vibe Coding is not an excuse for low-quality work, 2025
  • Peter van Hees, AI Developer Maturity Framework: 5 Levels to Orchestrator, 2026
  • METR, Measuring the Impact of AI on Experienced Developer Productivity, 2025.07
  • Google DORA, Accelerate State of DevOps Report 2024, 2024
  • Stack Overflow, Developer Survey 2025, 2025
  • Boris Cherny, 259 PRs in 30 Days, 2026.01
  • Simon Willison, StrongDM’s AI Software Factory, 2026.02