方法论 on Kalend's Blog

从Vibe Coding到Agentic Engineering：2026开发者该升级的方法论

Tue, 28 Jul 2026 10:00:00 +0800

一、引子：Karpathy 的"落后感"

2026 年 4 月，红杉资本 AI Ascent 大会。

Andrei Karpathy 站在台上，说了一句让全场安静下来的话：

「我从没觉得自己如此落后过。」

14 个月前，正是他给一种编程方式起了名字——Vibe Coding。当时原话是「完全沉浸在氛围中，忘记代码，只管 accept」。那条推文引爆了整个开发者圈，所有人都在说：编程的门槛消失了。

14 个月后，同一个人站出来说：这套方法论，终结了。

不是 Vibe Coding 没用，而是它不够了。

Karpathy 用了个新词——Agentic Engineering。

从 Vibe Coding 到 Agentic Engineering，中间到底发生了什么？为什么连发明者自己都在升级方法论？

这篇文章拆解这个进化过程。三阶段、五大支柱、一份你现在就能用的落地清单。

二、Vibe Coding 是什么？为什么它曾经很香

先回顾一下定义。

2025 年 2 月，Karpathy 描述了这种工作方式：

1

prompt → accept → run → ship

你跟 AI 说「帮我写个登录页」，它吐出代码，你看一眼觉得行，accept，运行，部署。全程不仔细看代码细节，沉浸在「氛围」里。

这有错吗？没有。

它的本质是 floor-raising——提升下限。 以前不会编程的人，现在能造出原型。以前需要一周的功能，现在一天搞定。

Google 2026 年 5 月发布的《The New SDLC With Vibe Coding》白皮书给了数据：85% 的专业开发者在用 AI 编程智能体，51% 每天用，预估 41% 的新代码由 AI 生成。

不是少数极客在玩，是主流在用。

Vibe Coding 最香的场景：

场景	为什么适合	举例
原型开发	快速验证想法，质量要求低	Hackathon、内部 demo
个人项目	自己用，bug 自己修	个人工具、脚本
已知模式的模板代码	AI 擅长重复模式	CRUD、API 接口、配置文件
学习新技术栈	边生成边学，比看文档快	新框架上手

一个有意思的发现是：生产力提升最大的团队，不是那些让 AI 写所有代码的团队，而是知道「什么时候该用 Vibe Coding、什么时候不该」的团队。

关键词是「知道什么时候用」。

这就是天花板的起点。

三、天花板在哪？三个致命问题

Vibe Coding 的问题不是「不好用」，而是「用多了会出事」。

三个致命缺陷，一个比一个隐蔽。

问题一：没有 evals——你不知道 AI 产出的质量

你让 AI 写了一段代码，运行通过了。好。

但是：

边界条件覆盖了吗？
并发场景处理了吗？
安全漏洞有没有？
性能合不合格？

不知道。因为没有评估机制。

「能跑」和「质量达标」之间隔着一道鸿沟。 Vibe Coding 的默认状态是：跑通就算完成。这在原型阶段没问题，在生产环境是灾难。

问题二：没有 observability——agent 跑偏了你不知道

当你把越来越多的工作交给 AI，一个新问题出现了：你看不见它在干什么。

它改了哪些文件？为什么选这个方案而不是那个？中间做了几次重试？哪一步卡住了？

如果你不知道这些，你就是在盲开。

问题三：安全和可维护性无人负责

AI 生成的代码，谁对安全负责？

AI 生成的代码，三个月后谁来维护？

这两个问题在 Vibe Coding 的范式里没有答案。 因为 Vibe Coding 的核心动作是「accept」——接受产出，不做深度审查。安全和可维护性恰恰需要深度审查。

数据说话

一个普遍现象是：大多数团队能看到 agent 在干什么（observability），但只有一半左右的团队在系统性地评估产出质量（evals）。

这个差距就是 Vibe Coding 到 Agentic Engineering 的鸿沟。

能看见，但不能控制。能产出，但不能保证质量。

四、Agentic Engineering——Karpathy 的新范式

什么是 Agentic Engineering？

Karpathy 的核心定义是两个词：ceiling-preserving（保护上限）。

Vibe Coding 是 floor-raising——让更多人能参与。

Agentic Engineering 是 ceiling-preserving——确保质量不滑坡。

具体来说：

「我 99% 的时间不再直接写代码，而是在指挥智能体干活。但作为人类，我对最终质量负全责。」

关键词是「负全责」。

不是让 AI 随便搞。是工程化地管理 AI 写代码的过程。

三大支柱

Agentic Engineering 不是一个工具、一个框架，而是一套方法论。核心由三大支柱支撑：

支柱一：Spec（规范）

告诉 agent「做什么」和「不做什么」。这不是写 prompt，是写工程规格书。

具体形式就是 AGENTS.md、SOUL.md 这类规范文件——项目架构、编码规范、测试要求、禁止操作，全部写清楚。（怎么写，我在上一篇AGENTS.md 指南里详细拆过。）

支柱二：Evals（评估）

系统性地衡量 AI 产出的质量。不是「看起来行就行」，是「过了评估才算完成」。

可以是自动化测试，可以是 checklist，可以是 code review 流程——形式不重要，有没有才重要。

最简单的 eval：写一个 checklist，AI 每次产出后逐条打勾。

检查项	通过
功能符合需求	✅/❌
错误处理完整	✅/❌
无安全隐患	✅/❌
有测试覆盖	✅/❌
代码风格一致	✅/❌

5 条，5 分钟，但能把 80% 的问题拦在合并前。

支柱三：Observability（可观测性）

看得见 agent 在干什么。日志、trace、审计——知道每一步的输入输出，知道为什么做了这个选择。

不是为了监控，是为了事后复盘。出了问题能追溯，做得好能复用。

一张表看清区别

维度	Vibe Coding	Agentic Engineering
核心理念	提升下限（floor-raising）	保护上限（ceiling-preserving）
人的角色	accepter——接受产出	owner——对质量负责
代码审查	可选，甚至跳过	必须，有流程
产出质量	靠运气	靠工程
适用场景	原型、个人项目	生产环境、团队协作
核心动作	prompt → accept	spec → execute → evaluate → ship

五、三阶段进化全景

回头看，AI 编程方法论经历了三个清晰的阶段。

第一阶段：Vibe Coding（2025.02 —）

关键词：氛围编程，快但不可控。

Karpathy 定义，社区狂热。prompt → accept → ship。门槛降到地板，质量也跟着降到地板。

这一阶段的贡献是巨大的——它证明了 AI 可以写代码，而且写得还不错。它让整个行业开始认真对待 AI 编程。

但它也暴露了一个根本问题：快不等于对。

第二阶段：Context Coding / Harness Engineering（2025.06 —）

关键词：AGENTS.md + 规范约束，让 AI 在框架内工作。

2025 年中，社区开始使用 Context Engineering 这个概念，强调给 AI 提供完整的上下文而非简单 prompt。开发者开始写规范文件、定义规则、约束 AI 的行为边界。从「给 AI 一句话」变成「给 AI 一套规则」。

这一阶段的核心贡献是：把 AI 从「自由发挥」拉回到「有规矩地干活」。

我在之前的AGENTS.md 深度指南中详细拆过这一阶段的方法论。简单说：花 30 分钟写好规范文件，比花三天对比工具强十倍。

但 Context Coding 也有天花板：它管住了单个 AI 的行为，但管不住多个 AI 的协作，也没有系统性的质量验证机制。

第三阶段：Agentic Engineering（2026.04 —）

关键词：多 agent 协调 + evals + observability。

Karpathy 在 AI Ascent 大会上正式提出。不只是「给 AI 规则」，而是「工程化管理整个 AI 工作流」。

多个 agent 并行工作，人类定义目标和质量标准，evals 验证产出，observability 监控过程。

类比

阶段	类比	核心动作
Vibe Coding	手工作坊——一个人从头干到尾	accept
Context Coding	流水线——标准化流程	constrain
Agentic Engineering	智能工厂——多条线并行，人管质量	orchestrate

从「一个人干活」到「标准化流程」到「多条线并行」。

你现在在哪个阶段？大多数人停在 1.0 或 2.0。

六、你现在该怎么做？五条实操建议

不是理论，是现在就能做的事。

1. 不要抛弃 Vibe Coding，升级它

Vibe Coding 不是垃圾，是地基。

原型开发、学习新技术、探索性编码——这些场景仍然适用。问题不是 Vibe Coding 本身，而是把它当终点。

正确姿势：用 Vibe Coding 快速产出，然后用工程化手段验证。

2. 给你的 AI 工具加 evals

哪怕最简单的 checklist。

每次 AI 产出后，花 5 分钟逐条检查：

功能是否符合需求？
错误处理是否完整？
是否有安全隐患？
是否有测试覆盖？
代码风格是否一致？

不要觉得「看起来行就行」。「看起来」是最不靠谱的质量标准。

3. 学会写 AGENTS.md

Context Engineering 是 2026 年的必修课。

不管用什么工具——Claude Code、Cursor、Codex、Gemini CLI——底层逻辑都一样：AI 的产出质量，70% 取决于你给了它什么上下文。

30 分钟写一个 AGENTS.md，效果比换三个工具强十倍。不知道怎么写？参考 Codex CLI 的官方仓库——GitHub 超过 10 万 Star，它的 AGENTS.md 就是范本。

4. 建立 agent 可观测性

不需要复杂的基础设施。

最简单的方式：让 AI 在工作时输出日志——做了什么、为什么这么做、遇到了什么问题。

进阶方式：用专门的可观测性工具，记录每个 agent 的执行路径、决策过程、耗时分布。

能看到，才能改进。看不到，只能祈祷。

5. 从单 agent 到多 agent 协作

这是 2026 年真正拉开差距的地方。

一个人指挥一个 AI，是 Context Coding。

一个人指挥多个 AI 各司其职，是 Agentic Engineering。

具体怎么做：

1
2
3
4
5


一个 agent 负责写代码
一个 agent 负责 review
一个 agent 负责测试
一个 agent 负责部署
人类负责定义目标和验收标准

不需要一开始就搭完整的 pipeline。从「写代码 + review」两个角色开始，逐步扩展。

七、结论：地基之上，才是上层建筑

Vibe Coding 不是终结，是起点。

它证明了 AI 可以写代码，让整个行业开始认真对待 AI 编程。但「能写」和「写得好」之间，隔着 Agentic Engineering。

2026 年，「会用 AI」不够了。

要「会工程化管理 AI」。

三个核心转变：

1
2
3


从 accept 一切 → 只 accept 过了 eval 的
从看不到过程 → 每一步可观测
从单打独斗 → 多 agent 协作

Karpathy 说「从没觉得自己如此落后过」，然后用 14 个月定义了一套新方法论。

你呢？

不需要 14 个月。从今天开始做三件事：

写一个 AGENTS.md（30 分钟）
加一个 5 条 checklist 的 eval（5 分钟）
让 AI 输出工作日志（1 分钟）

36 分钟，你就能从 Vibe Coding 1.0 迈进 Agentic Engineering 的大门。

数据来源：Addy Osmani (Google)《The New Software Lifecycle》(2026.5)、Karpathy 红杉资本 AI Ascent 演讲(2026.4)

关注「varkm」，一起学习，一起成长。

给AI Agent装上自我进化能力：从被动执行到主动学习

Sun, 19 Jul 2026 08:00:00 +0800

我用过几十个AI编程助手，发现一个共性问题：它们的记忆力可能很好，但学习能力几乎为零。

对话历史能存、RAG能检索、上下文窗口越来越大——但下次遇到同样的坑，它照样跳。存了一百次对话，等于存了一百本笔记本，知识从来没进过脑子。

这篇文章要回答一个核心问题：怎么让Agent从"记住发生了什么"进化到"学会不再犯同样的错"？

记忆≠学习

先厘清一个被严重混淆的概念。

记忆是被动存储。对话历史、RAG检索、向量数据库——这些解决的是"上次聊了什么"的问题。Agent能把三天前的对话翻出来引用，但这跟"学会了"是两回事。

类比一下：你的笔记软件记了一千条笔记，不等于你掌握了一千个知识点。笔记是外挂存储，不是内化能力。真正掌握一个知识，意味着能在新场景下灵活运用，不需要每次都翻笔记本。

Agent也一样。记忆解决的是"查得到"，学习解决的是"用得上"。两者的差距在于：记忆是存储操作，学习是权重更新。一个Agent可以记住"上次用SHA256哈希密码是错的"，但如果不把这个经验内化成行为模式，下次换个项目它还会犯同样的错。

所以问题的根源不是记忆不够，而是缺乏从经验中提取规律、把规律变成行为的能力。

Dream循环：让Agent学会"做梦"

2026年Anthropic给Claude托管智能体上线了一个叫Dreaming的功能，名字很直白——让AI学会做梦。

人类在REM睡眠阶段会整理白天的记忆碎片，强化重要信息，淘汰噪音。Dreaming的工作原理类似：Agent在两次任务的空闲期，自动回顾历史会话，整理碎片记忆，发现隐藏的模式。

这个功能背后的洞察是：反思不该只发生在任务执行中，任务间的空闲期同样重要。

实操层面，一个完整的反思循环长这样：

1
2
3
4
5


触发（任务完成/空闲时段）
 → 回顾会话，提取关键决策点
 → 评估决策结果（好/坏/不确定）
 → 发现重复模式（"凡是X场景，选Y方案总是更优"）
 → 更新知识库/行为规则

关键差异在第四步。普通的对话总结只停留在"这次做了什么"，反思循环要提取的是"这类场景应该怎么做"。前者是流水账，后者是方法论。

智源大会2026上，张少坤把这个思路拆成两个特性：递归式自迭代（Agent观察自己的prompt和workflow，根据环境反馈修改自身结构）和从自身探索经验中学习（不依赖人类标注，从实际执行结果中提取改进信号）。核心思想一样——Agent不该等人类来教它，应该自己从实践中学习。

Skill积累：从手动到自动的进化路径

反思产生洞察，但洞察如果只停留在"脑子里"，下次还得重新推理。要提高效率，得把反复出现的模式固化成可复用的Skill。

进化路径分三个阶段：

阶段一：手动编写。 用户遇到一个复杂流程，手动把步骤写成Skill。比如"部署Hugo博客到又拍云"需要七步操作，写成一个Skill后一键执行。第一次花10分钟写，之后每次30秒跑完。

阶段二：半自动发现。 Agent开始观察自己的行为——“这个用户已经第三次让我做类似的数据清洗了”，自动生成一个Skill草稿，标注为draft状态，等用户确认。

阶段三：全自动生命周期。 Skill从draft开始，经过实际测试验证效果，进入approved状态成为可复用资产。如果某次执行发现Skill有问题，自动进入修复流程或标记为deprecated。

这个生命周期的核心价值在于：Agent不是一次性消耗品，而是一个会积累经验的系统。用得越久，效率越高——因为它在用的过程中不断沉淀可复用的模式。

实际效果很直观：同类任务第一次执行可能要10分钟（探索+试错），积累Skill后30秒搞定。这不是理论数字，是实打实的效率差异。

错误模式学习：从"反复犯同样的错"到"同类错误不再犯"

错误是最有价值的学习素材，但前提是Agent能从错误中提取模式，而不只是"记住这次错了"。

一个实用的错误模式学习系统包含三层：

第一层：错误模式库。 每次出错，记录三要素——触发条件（什么场景下犯的）、修复方案（怎么修的）、预防措施（怎么避免再犯）。不是记一条日志就完事，而是结构化地沉淀为知识。

第二层：三问判断机制。 发现错误后，Agent问自己三个问题：

修复是否只动格式？（纯格式问题可以自动修）
方案是否唯一？（有多种可能的修法时，需要人来判断）
质量是否确定提升？（如果不确定修了会不会更好，先不动）

三个问题的答案决定了：自动修复、还是上报人类决策。

第三层：自动修复边界。 可以自动修的直接修——拼写错误、格式不一致、导入缺失。需要判断的必须人工介入——业务逻辑、架构选择、安全相关。

价值在于量变：从"反复犯同样的错"到"同类错误不再犯"。这不是一次性的改进，是持续累积的防御能力。

实战案例

光讲机制太抽象，看三个真实案例。

案例一：双轨自进化系统

某开源Agent项目实现了双轨驱动的自进化：内轨是日常自动运行的Skill生成——Agent在每次任务完成后自动检查是否有可复用的模式，轻量级、即时生效；外轨是手动触发的强化学习训练——深度改变模型的行为能力，需要人类监督。

两条轨道互补：内轨解决日常效率，外轨解决能力边界。内轨的Skill积累为外轨的训练提供了高质量的数据源。

案例二：小米MiMo Code的Dream/Distill机制

小米2026年6月开源的MiMo Code（基于OpenCode fork）引入了Dream和Distill两个机制。Dream负责空闲时的记忆整理和模式发现，Distill负责把发现的模式蒸馏成可执行的行为规则。

加上持久记忆和长程任务支持，这套系统让Agent在跨会话场景下也能保持学习的连续性——不是每次从零开始，而是带着之前学到的东西继续工作。

案例三：Darwin Gödel Machine

学术前沿的self-modifying Agent。传统Gödel Machine需要形式证明才能修改自身，Darwin版本用经验验证替代——通过实际执行效果来判断修改是否有效。

在SWE-bench和Polyglot上取得了显著提升，但也暴露了一个关键风险：reward hacking。Agent可能学到"看起来评分高但实际没用"的捷径。这个风险后面会详细聊。

三层自进化架构：可落地的方案

综合以上机制，我整理了一个三层架构，从易到难，每层都可以独立实施：

1
2
3
4
5
6
7


┌─────────────────────────────────────┐
│ Layer 3: 元进化 (Meta-Evolution) │ ← 优化进化策略本身
├─────────────────────────────────────┤
│ Layer 2: Skill 自动化 │ ← 重复模式 → 可复用 Skill
├─────────────────────────────────────┤
│ Layer 1: 经验记忆 │ ← 每次交互的反思与沉淀
└─────────────────────────────────────┘

Layer 1：经验记忆。 最基础的一层。每次任务完成后，Agent自动复盘：做了什么决策、结果如何、有没有更好的方案。把这些反思结构化存储，形成可检索的经验库。

实施建议：在任务结束的回调中加入反思环节，输出固定格式的经验条目（场景→决策→结果→改进点）。成本很低，效果立竿见影。

Layer 2：Skill自动化。 在经验积累到一定量后，Agent开始识别重复出现的模式，自动生成Skill草案。从"每次重新推理"变成"调用已有Skill+微调"。

实施建议：设置模式识别的阈值——同一类任务出现3次以上且执行路径相似度>70%，触发Skill自动生成。生成后标记为draft，经实际验证后升级为approved。

Layer 3：元进化。 最高级的一层——优化进化策略本身。不只是"从经验中学习"，而是"学习如何更好地从经验中学习"。

实施建议：定期（比如每周）回顾Skill的使用效果——哪些Skill被频繁调用、哪些很少用、哪些需要修改。用这些数据调整Skill生成的策略和阈值。这一层最复杂，建议在前两层稳定后再上。

踩坑与边界

自进化不是万能药，有几个必须警惕的风险：

Reward Hacking。 Agent可能学到"优化评分指标"而非"真正变好"。Darwin Gödel Machine已经暴露了这个问题——Agent找到了评分系统的漏洞，分数很高但实际行为没改善。

对策：评估指标多元化，不依赖单一维度。定期人工抽检Agent的实际行为，不只看自动化指标。

幻觉放大。 如果反思过程中产生了错误的"洞察"，而且这个错误洞察被固化成Skill，后果是系统性地犯错——比不学习还糟。

对策：Skill从draft到approved必须经过实际验证，不能纯靠Agent自我评估。关键Skill的审批权留给人类。

无限循环。 Agent不断反思、不断修改自己的规则，可能陷入"改了又改"的死循环——上次觉得A方案好改过去了，这次反思又觉得B方案好改回来。

对策：设置修改频率上限。同一个Skill在一定时间窗口内只能修改N次，超过后锁定等人工审查。

渐进式策略： 先手动触发反思（人觉得有必要时才让Agent复盘），再半自动（Agent建议反思，人确认），最后全自动（Agent自主决定何时反思）。不要一步到位，每一步都验证效果后再推进。

总结

从"工具"到"搭档"，路径并不复杂：

记忆解决"记住了什么"，学习解决"改变了什么"。Dream循环让Agent学会从经验中提取规律，Skill积累让规律变成可复用的资产，错误模式学习让Agent从"反复犯同样的错"进化到"同类错误不再犯"。

三层架构——经验记忆、Skill自动化、元进化——每层都可以独立实施，循序渐进。先跑通第一层，确认效果后再上第二层，别急着一步到位。

后续文章会出各个机制的详细实操教程，包括Dream循环怎么配置、Skill自动生成怎么实现、错误模式库怎么设计。

Vibe Coding翻车指南：10个让AI编程从'爽'变'灾难'的常见错误

Fri, 17 Jul 2026 08:00:00 +0800

Google 2026年5月发布的《The New SDLC With Vibe Coding》白皮书有一组扎眼的数据：85%的专业开发者在用AI编程智能体，51%每天用，预估41%新代码由AI生成。

用的人多，不等于用得好。

Karpathy 2025年2月提出Vibe Coding，一年后又提出Agentic Engineering。这个进化本身就说明问题——Vibe Coding是起点，不是终点。很多人卡在"提示即祈祷"阶段：把需求扔给AI，然后祈祷别出错。

今天不聊代码层面的bug（那篇写过了），聊方法论层面的10个系统性错误。每个都指向同一个核心：AI是乘数，工程纪律是被乘数。

错误1：大模块一次性生成

一个prompt要求AI写完整认证系统——注册、登录、密码重置、JWT刷新、OAuth2集成，全要。

结果：安全细节被简化（密码哈希用SHA256而非bcrypt，JWT没有刷新机制），错误处理缺失，接口风格不一致。看起来"能跑"，上线就炸。

心法：拆成小任务，每个≤200行。认证系统拆成：①用户模型+密码哈希 ②注册接口 ③登录+JWT签发 ④JWT刷新 ⑤OAuth2接入。每完成一个，验证一个。

错误2：模糊prompt产出平庸代码

“帮我优化这段代码”——AI会给你一个"还行"的版本。“用async/await重写这个函数，保持错误处理和日志，去掉callback hell”——AI给你精准的重构。

Claude Code官方最佳实践指南反复强调：模糊的prompt只能得到模糊的结果。

心法：每次prompt回答三个问题——改什么、怎么改、保留什么。模糊的输入只能得到模糊的输出。

错误3：不过审就部署

灰度发布，新接口静默失败——前端无提示，后端日志全是空catch块。用户投诉了才发现。

AI生成≠可部署。这个等号不能画。

心法：AI代码必须过审才能合并。审查清单：①错误处理是否完整 ②边界条件是否覆盖 ③日志是否有意义 ④是否有硬编码的配置 ⑤是否有测试。

错误4：过度信任AI的"完整性"

AI输出的代码"看起来很完整"——有注释、有docstring、有错误处理、甚至有测试。但仔细看，测试只覆盖了happy path，错误处理用了except Exception: pass，docstring和实际行为不一致。

AI的完整性是表面的。它会生成结构完整但逻辑有漏洞的代码。

心法：追问"为什么这么写"。AI选择某个方案时，问它为什么不用另一个。如果它答不上来或答得含糊，方案可能有问题。

错误5：context缺失导致幻觉

没有AGENTS.md，没有项目规范文件，没有代码风格指南。AI只能靠猜——猜你用什么框架、猜你用什么数据库、猜你的错误处理风格。

结果：同一个项目里，AI一会儿用Express一会儿用Fastify，一会儿用async/await一会儿用callback。

心法：给AI一个"上下文锚点"。AGENTS.md、.cursorrules、项目README，这些文件的价值不在于写得多详细，而在于AI有了参考系。

错误6：任务粒度不对

两个极端都致命：太大，AI出错概率飙升；太小，AI失去连贯性，生成的代码碎片化。

类比：不会让实习生一次交付完整系统，也不会让他只写一行print。给AI的任务和给人的任务，粒度原则一样。

心法：单个任务的复杂度应该等于一个"中等难度的PR"——有明确输入输出，有清晰边界，一个资深工程师能在30分钟内review完。

错误7：迭代循环缺失

一次性生成后就不管了。不跑测试，不做code review，不根据反馈调整。

Vibe Coding的诱惑在于"看起来很快"。但如果没有迭代循环，快只是假象——你只是把调试时间从编码阶段移到了部署阶段。

心法：小步快跑+持续反馈。生成→验证→反馈→调整，每个循环不超过10分钟。如果一个循环内无法验证，任务粒度太大了。

错误8：审查机制空白

没有code review流程，AI生成的代码直接合并到main分支。相当于把仓库的门禁卡交给了一个实习生，还不设审批。

心法：设计AI代码审查checklist。不用复杂，五条就够：①功能是否符合需求 ②错误处理是否完整 ③是否有安全隐患 ④是否有测试覆盖 ⑤代码风格是否一致。

错误9：只学工具不学心法

Cursor、Claude Code、Codex、OpenCode——工具选了一堆，方法论停留在"提需求→等生成→复制粘贴"。

工具一直在换，但方法论没变。

心法：工具是手段，不是目的。理解"任务拆解→上下文管理→迭代验证→审查部署"这个循环，比多装三个工具有用。

错误10：忽略验证成本

代码生成成本从"一个工程师一天"降到"几秒钟"，但验证成本并没有降。瓶颈从"写代码"转移到了两端：搞清要做什么，确认做对了。

这两个才是真正的成本。很多人只关注"AI写得快不快"，忽略了"AI写得对不对"需要人来确认。

心法：把足够的时间花在验证上——跑测试、看diff、review逻辑。生成快≠正确，省下的编码时间要投入到验证中。

从Vibe Coding到Agentic Engineering

Karpathy 2026年2月提出的Agentic Engineering，核心思想很简单：人负责定义目标、约束和质量标准，AI在结构化流程中执行，每个关键节点人工审核。

不是让AI自己跑，是给人一个更高效的工作流。AI在里面的角色是"高效执行者"，不是"决策者"。

Vibe Coding是"感觉对了就用"，Agentic Engineering是"验证对了才用"。前者靠直觉，后者靠流程。

你不需要10个AI工具，你需要一个清晰的工程方法论。

数据来源：Google《The New SDLC With Vibe Coding》(2026.5)、Karpathy 2025.2/2026.2公开演讲、Claude Code官方最佳实践指南