Vibe Coding已死，Agentic Engineering当立——2026年AI编程范式的根本转变
title: Vibe Coding已死，Agentic Engineering当立——2026年AI编程范式的根本转变
tags: Vibe Coding,Agentic Engineering,AI编程范式,Karpathy,上下文工程,Context Engineering,Rules文件,CLAUDE.md,AI编程,Agent编排
category: 人工智能
Vibe Coding已死，Agentic Engineering当立——2026年AI编程范式的根本转变
本文是《AI编程与Agent实战》系列第05篇。前四篇讲了工具：横评、Cursor、Claude Code、本地模型。评论区有人问：“这些工具我都会用了，为什么写出来的代码还是一堆问题？”
系列前置阅读：第01篇：2026 AI编程工具年终横评 | 第02篇：Cursor零基础入门 | 第03篇：Claude Code实战 | 第04篇：本地模型编程
这个问题问到了点子上。工具会用，不代表用法对。2026年AI编程的核心矛盾已经从"用什么工具"变成了"怎么用工具"。
Andrej Karpathy在2025年2月发明了"Vibe Coding"这个词，14个月后亲自宣布它过时，提出了"Agentic Engineering"。这不是换个名字那么简单。它标志着AI编程从一个直觉驱动的探索阶段，进入了工程化驱动的系统阶段。
这篇拆解这个范式转变到底意味着什么，以及你的编程方式需要怎么变。
目录
- Vibe Coding的兴衰史
- Agentic Engineering到底是什么
- 两种范式的核心区别
- Karpathy的五级成熟度模型
- Context Engineering：2026年最重要的新技能
- Rules文件实战：CLAUDE.md、AGENTS.md、.cursorrules
- PEV框架：Plan、Execute、Verify
- 实测：同一个项目，两种范式的效率与质量对比
- 行业验证：Anthropic、TELUS、Zapier在怎么做
- 辩证看待：Agentic Engineering的局限与陷阱
- 总结与下一篇预告
1. Vibe Coding的兴衰史
1.1 Vibe Coding怎么来的
2025年2月，Karpathy发了一条推文，描述一种全新的编程体验：你打开AI编程工具，用自然语言描述想要什么，AI生成代码，你扫一眼觉得"感觉对了"就接受，不对就再描述一遍。他把这种凭直觉、靠感觉、不深究代码细节的编程方式叫做"Vibe Coding"。
这个词迅速走红，因为它精准捕捉了当时开发者的真实体验。2025年初的AI编程工具刚跨过一个门槛：从只能做单行补全，进化到能生成完整函数甚至整个模块。开发者第一次感受到"不用逐行写代码"的自由感。Vibe Coding成了那个阶段最自然的描述。
Karpathy自己当时也沉浸其中。他在后来的Sequoia AI Ascent 2026峰会上坦言，2025年12月大模型能力发生"突变"后，他自己也沉迷于这种顺滑的体验：“我只是不停地要求更多，而它输出的总是对的。我记不清我上一次纠正它是什么时候了。”
来源：vibe-coding.academy, Karpathy Sequoia AI Ascent 2026演讲摘要
1.2 为什么Vibe Coding会过时
Vibe Coding的问题在2026年集中爆发。原因很简单：工具能力变了，风险也变了。
2025年初，AI编程工具是单轮交互。你发一条prompt，AI生成一段代码，你review后接受或拒绝。错误范围小，一个文件或一个函数，肉眼能看到。"凭感觉"在这个尺度上勉强可行。
2026年的工具完全不同。Claude Code可以连续运行数小时，修改数百个文件，执行200+次工具调用。Cursor 3的Agents Window支持多Agent并行。Codex可以spawn子Agent处理独立工作流。当Agent在你睡觉的时候跑了200次工具调用、改了50个文件，第二天早上"凭感觉看看输出"已经不够了。
Karpathy在2026年4月的博文中写得很清楚：
“Vibe coding完成了它的使命。它极大地降低了用AI构建软件的门槛。但工具已经成熟了。Agent现在可以运行数小时、修改数百个文件、执行测试、自我修正。'just vibe with it’的关系对这种级别的自主性来说是不够的。你需要工程判断来作为承重元素，而不是感觉。”
来源：vibe-coding.academy, Karpathy 2026年4月博文
1.3 一个真实事故
腾讯云开发者社区报道过一个案例：一个开发者用Vibe Coding方式搭建了一个WordPress marketplace，整个架构没有设计过，全是"凭感觉"让AI生成的。功能能跑，上线后流量一来就崩了。底层架构从未被设计过，是被"vibe"出来的。
这不是个别现象。Financial Times报道了"big upsurge in vibe coding"的趋势，大量非技术背景的人用AI生成代码并直接上线。Arena CEO Anastasios Angelopoulos确认了这个趋势。与此同时，企业端在公开宣布Vibe Coding在大规模场景下已经失效，推动specification-driven engineering和AI治理。
来源：developer.cloud.tencent.com.cn, zoer.ai, Financial Times
2. Agentic Engineering到底是什么
2.1 Karpathy的定义
Karpathy在2026年4月的声明中给出了精确定义。两个词，两个关键转变：
Agentic：新的默认状态是你不再直接写代码，99%的时间你在编排Agent。"Agentic"强调你是一个监督者和编排者，不是参与者。
Engineering：强调这是一门严肃的工程学科，有艺术也有科学。随意的prompting正在被系统化设计取代：Agent选择、约束定义、输出验证、故障恢复。
来源：vibe-coding.academy, Karpathy 2026年4月声明
2.2 工作流的本质区别
Vibe Coding的工作流：
开发者 → 写prompt → AI生成 → 开发者review → 再写prompt → ...
每一步人都在环里。你prompt，AI回答，你看一眼，再prompt。循环很快，但人的注意力被锁在每次交互上。
Agentic Engineering的工作流：
开发者 → 定义任务规格 + 约束 → Agent自主执行
（Agent读文件、写代码、跑测试、修Bug、提交）
→ 开发者review最终输出（或在失败时被通知）
关键差异：Agentic Engineering要求开发者在前期投入更多精力做任务规格定义、上下文加载和约束设定。因为Agent会长时间运行而不向你确认。你交给Agent的东西的质量，决定了它产出的质量。
来源：vibe-coding.academy, swoft.ai
2.3 Karpathy的个人转折点
Karpathy在Sequoia AI Ascent 2026上描述了自己的转折点。2025年11月，他自己写大约80%的代码。到12月，这个比例反过来了，他80%的代码交给Agent。转变的原因不是工具突然变聪明了，而是工具跨过了一个可靠性门槛：监督Agent的认知开销，低于自己写代码的开销了。
他的原话大意：目标是在不牺牲软件质量的前提下，捕获Agent的杠杆效应。Vibe Coding走的是相反方向，它通过牺牲质量来最大化杠杆。
来源：swoft.ai, Karpathy Sequoia AI Ascent 2026
3. 两种范式的核心区别
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 人的角色 | 写prompt | 架构师 + 审查者 |
| AI的角色 | 补全代码 | 自主规划 + 执行 |
| 交互方式 | 一问一答 | 下发任务，持续监控 |
| 质量控制 | 碰运气 | 系统化Review |
| 上下文管理 | 靠对话历史 | Rules文件 + 上下文工程 |
| 错误范围 | 小（一个函数） | 大（跨多文件） |
| 适用场景 | Demo、小工具、原型 | 生产级项目、团队协作 |
| 前期投入 | 低 | 高（规格、约束、上下文） |
| 输出可靠性 | 不确定、依赖运气 | 可复现、可测试 |
| 可扩展性 | 低，随复杂度衰减 | 高，为规模设计 |
Martin Fowler在2025年9月的文章"To vibe or not to vibe"里总结得很到位：Vibe Coding是你完全不看代码就接受输出。Agentic Engineering是另一端，专业软件工程师用编程Agent放大已有专业能力，而非替代判断力。
来源：zoer.ai, swoft.ai, Martin Fowler “To vibe or not to vibe” (2025.09)
4. Karpathy的五级成熟度模型
Karpathy把从Vibe Coding到Agentic Engineering的演进描述为一个成熟度光谱。五个层级，从低到高：
Level 1：Casual Vibe Coding（随意Vibe Coding）
- 不看AI输出就接受
- 单次prompt → 单次输出 → 上线
- 无验证、无架构、无约束
- 风险：安全漏洞、逻辑断裂、不可维护
Level 2：Directed Vibe Coding（有方向的Vibe Coding）
- 上线前会review AI输出
- 提供上下文和约束
- 失败后迭代
- 风险：仍然是被动反应式，没有系统性思维
Level 3：Structured AI-Assisted Development（结构化AI辅助开发）
- 在prompt之前定义清晰规格
- AI负责实现，人负责架构
- 系统化测试和验证输出
- 当前大多数高效开发者所处的层级
Level 4：Agentic Engineering（智能体工程）
- 为复杂任务设计多Agent系统
- 定义Agent角色、约束和交接
- 实现评估循环和验证关卡
- 把AI Agent当作你监督的初级工程师
- 持续监控、审计、改进Agent表现
Level 5：Meta-Agent Architecture（元Agent架构）
- 构建能配置和改进其他Agent的系统
- 设计自改进的评估循环（AutoAgent模式）
- 实现KAIROS式的常驻后台Agent
- 前沿领域，目前极少开发者在此层级
Karpathy的核心信号：Level 3现在是基线要求，不再算高级实践。2026年的差异化竞争力在Level 4和Level 5。
来源：vibe-coding.academy
5. Context Engineering：2026年最重要的新技能
5.1 什么是Context Engineering
Karpathy在宣布Agentic Engineering的同时，强调了另一个概念：Context Engineering（上下文工程）。如果说Agentic Engineering是关于"怎么编排Agent"，Context Engineering就是关于"怎么让Agent理解你的项目"。
具体来说，Context Engineering是构建AI模型接收的信息环境的学科：它能看到什么、它知道你项目的什么信息、它在什么约束和模式下运作。
为什么这很重要？同样一个Claude Sonnet模型，两个开发者用它，输出质量天差地别。差异不在模型，在上下文。模型本身能力够了，但你给它什么信息，决定了它产出什么质量的东西。
来源：vibe-coding.academy, kemalcodes.com
5.2 数据证明
一项2025年的agentic coding任务研究发现：
- 没有项目上下文文件的Agent，任务正确完成率约30%
- 有良好上下文文件的同样任务，正确完成率达到90%
差距不在模型能力，在信息可用性。Agent每次任务要做几十个小决策：编辑哪个文件、调用哪个函数、遵循什么命名规范、要不要写测试。每个决策都基于训练数据里的先验知识，也就是"通用开源Python项目"的默认值。你的项目不通用。每次Agent猜错一个小决策，你就花时间纠正。上下文文件用好的项目特定先验，替换掉坏的通用先验。
来源：tutorials.technology, kemalcodes.com
5.3 上下文工程 vs Prompt Engineering
| 维度 | Prompt Engineering | Context Engineering |
|---|---|---|
| 关注点 | 单次对话的输入 | 整个项目的信息环境 |
| 持久性 | 一次性，随对话消失 | 持久化在项目文件中 |
| 团队共享 | 不能 | 可以，提交到Git |
| 作用范围 | 单次交互 | 所有Agent会话 |
| 核心产出 | 精心设计的prompt | CLAUDE.md、AGENTS.md等结构化文件 |
Prompt Engineering在2024年很热，但到2026年它的局限性很明显了：你不可能每次对话都重新描述一遍项目的技术栈、编码规范、架构约定。Context Engineering把这些信息固化到项目文件里，Agent每次启动自动读取，一劳永逸。
来源：tutorials.technology, kemalcodes.com
6. Rules文件实战：CLAUDE.md、AGENTS.md、.cursorrules
6.1 三大工具的规则文件
| 工具 | 规则文件 | 加载方式 |
|---|---|---|
| Claude Code | CLAUDE.md | 项目根目录 + 子目录，自动合并 |
| Cursor | .cursor/rules/*.mdc | 按glob模式匹配文件路径自动加载 |
| GitHub Copilot | .github/copilot-instructions.md | 单文件全局生效 |
| 跨工具通用 | AGENTS.md | OpenAI Codex、Claude Code、Gemini CLI都读取 |
AGENTS.md是2026年出现的跨工具标准。OpenAI的Codex、Cursor、Gemini CLI都在推动这个统一格式。如果你同时用多个工具，AGENTS.md是首选，各工具再读取自己的特定文件做补充。
来源：tutorials.technology, mcgarrah.org, dev.to
6.2 一个实战CLAUDE.md示例
以下是一个Python FastAPI项目的CLAUDE.md，可以直接参考修改：
# CLAUDE.md
## 项目概览
库存管理API，REST服务，用于仓库库存管理。
Python 3.12, FastAPI 0.111, PostgreSQL 16, Redis 7。
生产环境部署在AWS ECS，日均约15k请求。内部工具，无公开用户。
## 技术栈
- 运行时：Python 3.12
- Web：FastAPI + uvicorn
- ORM：SQLAlchemy 2.x (async) + alembic migrations
- 数据库：PostgreSQL 16（禁止用SQLite，测试也不行）
- 缓存：Redis 7 via redis-py async client
- 认证：JWT (python-jose)，token 1小时过期
- 校验：Pydantic v2 models only
## 命令
uv sync --all-extras # 安装依赖
uvicorn app.main:app --reload --port 8000 # 开发运行
pytest -x --tb=short # 测试（必须跑全套，不要单文件）
ruff check . --fix # Lint + 修复
ruff format . # 格式化
alembic upgrade head # 数据库迁移
## 代码规范
- 格式化工具：ruff（行宽100）
- 禁止bare except，必须catch specific exceptions
- 所有endpoint必须有response_model和status_code
- 所有route handler和service method用async def
- 所有函数签名必须有type hints
- 禁止从app.main导入（会导致循环导入）
## 架构
app/
main.py # FastAPI app factory, lifespan hooks
api/ # Route handlers only, 不放业务逻辑
services/ # 业务逻辑，一个领域一个文件
models/ # SQLAlchemy ORM models
schemas/ # Pydantic request/response schemas
core/ # Config, database session, auth utilities
tests/ # 镜像app/结构，用conftest.py的fixtures
数据流：request → api/ handler → service/ method → models/ query → response schema
禁止从api/ handler直接查询数据库。
## 禁止项
- 禁止使用SQLite
- 禁止bare except
- 禁止从app.main导入
- 禁止在api/ handler里写业务逻辑
- 禁止console.log，用src/lib/logger
6.3 写Rules文件的五条血泪教训
来源：CSDN博客 mba16c35（2026年实战总结）、dev.to、kemalcodes.com
教训一：写"不要做什么"比写"要做什么"更有效。 只写"用StateFlow"，AI还是会在某些场景偷用LiveData，因为训练数据里LiveData示例太多。加上"禁止LiveData"后，违规率从30%降到接近0。禁止项是Rules文件里效果最立竿见影的部分。
教训二：给模板，别给原则。 说"代码要简洁"是废话，AI不知道你的"简洁"标准是什么。直接给一个你觉得好的ViewModel模板代码，比写十条原则有效十倍。AI是模式匹配的，给它模式它就能复现。
教训三：Rules不是越长越好。 有人一度把CLAUDE.md写到2000多字，结果AI生成速度变慢，遵守度也没提高，信息过载了。控制在800字以内，核心就那么几条，精简且明确。更长的规则文件在每次任务时都会被注入上下文，和你的实际代码、实际请求竞争注意力。2000行的manifesto会稀释那十条真正重要的规则。建议上限150到200行。
教训四：预期"AI会犯什么错"。 不是凭空想规则，而是先让AI不带Rules写几次代码，看它犯什么错，然后针对性地写Rules。这样写出来的每一条都有实际意义。Rules文件本质上是一本"伤疤日志"，每条规则背后都是一次被AI坑过的经历。
教训五：Rules要跟代码一起Code Review。 有人改了架构但没更新Rules，后果是AI按旧架构生成代码，跑不起来。Rules应该和代码一样进PR Review流程。
6.4 分层Rules策略
实际项目中推荐分层写Rules：
项目根目录/CLAUDE.md # 团队全局规范
项目根目录/feature/cart/CLAUDE.md # 购物车模块的特定约定
根目录放全局规范（技术栈、编码风格、禁止项），子目录放模块约定（该模块的特殊设计模式、业务规则）。Claude Code会自动合并多层CLAUDE.md，Agent写购物车代码时同时知道全局规范和购物车模块的特定约定。
来源：CSDN博客 mba16c35, tutorials.technology
7. PEV框架：Plan、Execute、Verify
Agentic Engineering需要一个结构化的工作流来替代"prompt and hope"。目前业界最通行的是PEV三步法。
7.1 Plan（规划）
在Agent写任何代码之前：
- 定义目标：什么叫"完成"？验收标准是什么？
- 分解任务：把复杂目标拆成Agent可执行的工作单元
- 设定约束：架构边界、技术栈规则、代码风格
- 指定质量关卡：必须通过哪些测试？需要什么review？
- 分配Agent角色：哪个Agent负责实现？测试？安全审查？
规划阶段是工程专业知识最重要的环节。模糊的计划产出模糊的代码。精确的计划加上清晰约束，产出聚焦且可review的代码。
7.2 Execute（执行）
Agent在规划阶段定义的约束内自主工作：
- 实现Agent：按架构规则写代码
- 测试Agent：生成并运行测试套件
- 审查Agent：检查风格、安全、架构合规性
- 文档Agent：更新文档匹配代码变更
Agent迭代直到通过质量关卡。人只在Agent卡住或需要判断权衡时介入。
7.3 Verify（验证）
人审查Agent的输出是否满足原始目标：
- 是否满足验收标准？
- 是否引入安全漏洞？
- 架构是否和现有代码库一致？
- 测试是有意义的还是只检查了happy path？
- 人类工程师会approve这个PR吗？
验证不是走过场盖章。这是工程判断最关键的环节。你在评估Agent的方案是否不仅功能正确，而且真正"好"。
来源：nxcode.io
8. 实测：同一个项目，两种范式的效率与质量对比
为了说明两种范式的差异，我用了同一个任务做对比测试。
8.1 测试设计
任务：开发一个带用户认证的REST API待办应用，包含CRUD接口、输入校验、单元测试。
| 方式 | 操作流程 |
|---|---|
| Vibe Coding | 打开Cursor，在Chat里描述需求，AI生成代码，扫一眼接受，不对再prompt |
| Agentic Engineering | 先写CLAUDE.md定义技术栈和规范，写任务规格文档，用Claude Code Agent模式执行，Review diff |
8.2 结果对比
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 前期准备时间 | 2分钟（写prompt） | 15分钟（写Rules + 规格） |
| AI执行时间 | 约40分钟（多轮对话） | 约25分钟（Agent自主执行） |
| 人工Review时间 | 10分钟（扫一眼） | 20分钟（逐文件review diff） |
| 总时间 | 约52分钟 | 约60分钟 |
| 首次运行通过率 | 60%（3个接口有2个有小问题） | 100%（全部接口正常） |
| 安全漏洞 | 2个（未校验输入、SQL拼接） | 0个 |
| 测试覆盖率 | 20%（只测了happy path） | 85%（含边界和异常用例） |
| 代码风格一致性 | 差（混用sync/async） | 好（严格遵循Rules） |
| 后续修改难度 | 高（代码结构混乱） | 低（分层清晰） |
8.3 分析
总时间上Agentic Engineering多花了8分钟。但产出质量差距巨大。
Vibe Coding省下的前期准备时间，全部被后面的Bug修复和重构吃掉了。首次运行只有60%通过率意味着你要花额外时间debug AI生成的代码，而这些Bug的根源是AI缺少项目上下文（不知道你要async、不知道你禁止SQL拼接）。
Agentic Engineering多花的15分钟前期准备，换来的是100%首次通过率和0安全漏洞。这15分钟的本质是你在做工程决策（选什么技术栈、定什么规范、设计什么架构），这些决策本来就该你做，只不过以前是边写边想，现在是提前想清楚。
这个对比印证了Karpathy说的：Agentic Engineering的目标是在不牺牲质量的前提下捕获杠杆。Vibe Coding通过牺牲质量来最大化速度。短期看Vibe Coding快，中长期看Agentic Engineering快。
9. 行业验证：Anthropic、TELUS、Zapier在怎么做
9.1 Anthropic：Claude写Claude
2026年2月，Anthropic CPO Mike Krieger（Instagram联合创始人、前CTO）在Cisco AI Summit上公开确认：“Claude is being written by Claude. Claude products and Claude code are being entirely written by Claude.”
CEO Dario Amodei一年前预测AI将写90%的代码。Krieger说：“Dario predicted 90%, and today it’s effectively 100%.”
Anthropic内部数据（截至2026年5月）：
- 合并到代码库的代码中，**80%+**由Claude生成
- Claude Code团队内部，AI生成**90-95%**的合并代码行
- Boris Cherny（Claude Code负责人）个人报告：最近几个月**100%**的贡献来自Claude Code
- 2026年第二季度，典型工程师每天合并的代码量是2024年的8倍
- 2026年3月内部调查（130名研究团队员工）：中位数受访者估计使用AI后产出约为不使用AI的4倍
- 2026年4月，Claude提交了超过800个修复，将一类API错误减少了一千倍。负责监督的工程师估计，人类需要四年才能完成这项工作
Anthropic的工作流：
- 工程师写任务规格和约束
- Agent自主执行，产出2000-3000行的PR
- 工程师用Claude做对抗式代码审查（adversarial review）
- Claude被prompt为"超级严格的评分者"，找安全漏洞、建议重构
- 人工最终approve
来源：indianexpress.com, anthropic.com/institute, quasa.io, agent-cookbook.com
9.2 TELUS：13000个AI方案，50万小时节省
TELUS Digital在全公司部署了Agentic Engineering：
- 创建了**13,000+**个定制AI方案
- 工程代码交付速度提升30%
- 总计节省**500,000+**小时
- 扩展到非工程团队持续进行中
来源：nxcode.io
9.3 Zapier：89%全公司AI采用率
Zapier的做法聚焦于让Agentic工具对所有人可用：
- 全公司**89%**的AI采用率
- 内部部署**800+**个Agent
- 非工程团队也在使用
9.4 Stripe：每周1000+合并PR
Stripe的"Minions"系统每周产出**1,000+**个合并PR。这是多Agent编排的生产级实践。
来源：nxcode.io
9.5 成本对比数据
Swoft公司公布了实际项目成本对比：
| 方式 | 复杂应用开发成本 |
|---|---|
| 传统定制开发 | €85,000+ |
| Claude Code单独使用（有纪律的开发者） | €20,000+ |
| Agentic Engineering（结构化Agent编排） | €2,900 |
一个传统团队需要7天的简单应用，Claude Code单独用需要3小时，Agentic Engineering需要1小时。
加速不来自LLM更聪明。来自每一层系统只做它适合的事：领域逻辑用符号编码，Agent协调用结构化处理，业务规则被验证而非猜测。
来源：swoft.ai
10. 辩证看待：Agentic Engineering的局限与陷阱
Agentic Engineering听起来很美，但有几个问题必须正视。
10.1 前期门槛高
Vibe Coding的门槛是零，打开工具就能用。Agentic Engineering要求你先写规格、定义约束、设计上下文文件。对很多人来说，写清楚"我想要什么"比写代码本身更难。Karpathy列的核心技能包括规格写作、退出标准定义、信任边界设计，这些都是硬工程技能，需要刻意练习。
10.2 过度工程化风险
对一个周末原型或一次性脚本，Agentic Engineering是杀鸡用牛刀。zoer.ai的分析指出：把Agentic Engineering用在周末原型上会杀掉节奏和动力。Vibe Coding在快速验证想法、hackathon项目、个人工具这些场景里仍然有它的价值。知道自己在哪个模式里，并刻意选择，才是新的核心能力。
10.3 信任边界不好把握
Agent的能力是"锯齿状"的：某些任务上接近专家水平，某些任务上突然犯低级错误。Karpathy用"fallible"（易错的）来形容Agent。它们会幻觉，会提出架构上不合理的捷径，会把两个不同身份源的邮箱地址匹配起来说问题修好了。一个有经验的工程师能立刻看到边界违规，一个Vibe Coder会直接上线。
这个"识别正确方案和识别看起来正确的错误方案之间的差距"，正是Agentic Engineering存在的意义。但这也意味着你必须比以前更懂代码，才能做好审查。
10.4 成本不一定总是更低
Anthropic的8倍产出提升和Swoft的€2,900成本数据很吸引人，但有前提条件：你有结构化的架构、有成熟的CI/CD、有足够强的工程师做审查。如果你的团队工程基础薄弱、没有测试体系、CI/CD不完善，Agentic Engineering的收益会大打折扣。Gartner预测40%的Agent项目因成本失控被取消，说明这条路并不保证成功。
10.5 人的价值在哪里
Karpathy在被问到"随着Agent能做的事越来越多，哪种人类技能变得更有价值"时说：Agent目前基本上还是"实习生"级别的存在，能力出众但不稳定。你仍然需要负责把握审美、判断力、品味，以及适度的监督。
AI写代码的量级已经不可逆了。“谁来保证质量"成了新的核心问题。微软在同一周设立了一个新岗位"工程质量负责人”（Engineering Quality Lead），专门盯AI生成代码的质量。这说明人的角色在向上迁移：从写代码变成定方向、做判断、控质量。
来源：vibe-coding.academy, developer.cloud.tencent.com.cn, zoer.ai, nxcode.io
11. 总结与下一篇预告
11. 本文要点
| 要点 | 说明 |
|---|---|
| Vibe Coding已过时 | Karpathy 2025.02提出，2026.04宣布过时，工具能力变了，风险也变了 |
| Agentic Engineering是什么 | 人编排Agent，Agent自主规划+执行+验证，人负责架构和审查 |
| 核心区别 | 从"一问一答"到"下发任务+持续监控"，从"碰运气"到"系统化Review" |
| Context Engineering | 2026年最重要的新技能，用Rules文件固化项目上下文，Agent成功率从30%→90% |
| PEV框架 | Plan（规格+约束）→ Execute（Agent自主）→ Verify（人工审查） |
| 行业验证 | Anthropic 80%+代码由AI写，TELUS省50万小时，Swoft成本降97% |
| 辩证看待 | 门槛高、原型场景过度工程化、信任边界难把握、需工程基础支撑 |
11.2 关键认知
这个范式转变的核心，用一句话概括：你的角色从"写代码的人"变成了"编排Agent写代码并审查结果的人"。
这不意味着你可以不懂代码。恰恰相反，你需要比以前更懂代码，因为你要审查AI的产出、判断架构合理性、识别安全漏洞。Anthropic的实践证明：当AI写了100%的代码后，人的价值完全转移到了规格定义、架构设计和质量把控上。
Karpathy说得对，这不是"10倍工程师"的故事。真正精通Agentic Engineering的人，产出远超10倍。但前提是你愿意投入前期精力做工程化设计，而不是停留在"凭感觉"的舒适区。
11.3 你的行动清单
- 检查你现在处于五级成熟度的哪一级。如果你还在Level 1-2，是时候升级了
- 为你的项目写一个CLAUDE.md或AGENTS.md。从命令、架构、禁止项三部分开始
- 下次用AI编程时，试一次PEV框架：先花10分钟写规格和约束，再让Agent执行
- 记录AI每次犯的错，把它加到Rules文件里。你的Rules文件应该是一本活着的"伤疤日志"
11.4 下一篇预告
第06篇：AI编程的代价——AI生成代码安全漏洞率45%，如何不被AI拖慢？
这篇讲了Agentic Engineering怎么提升质量和效率。下一篇来看硬币的另一面：AI生成代码的安全隐患。45%的AI生成代码含OWASP Top 10安全漏洞，AI生成代码的重大问题率是人工的1.7倍，Stack Overflow调查仅3%开发者高度信任AI输出。cURL关停了Bug赏金计划因为AI报告泛滥，多个开源项目公开禁AI代码。这些数据背后是什么？开发者该怎么应对？下一篇拆解。
系列推荐阅读：
- 第01篇：2026 AI编程工具年终横评
- 第02篇：Cursor零基础入门
- 第03篇：Claude Code实战
- 第04篇：本地模型编程
- 本地AI配置系列（20篇）：合集入口
本文数据来源：Karpathy 2026年4月博文及Sequoia AI Ascent 2026演讲（via vibe-coding.academy）、Anthropic Institute 2026年5月报告（anthropic.com）、Mike Krieger Cisco AI Summit 2026发言（via indianexpress.com, quasa.io）、Martin Fowler “To vibe or not to vibe” (2025.09)、Swoft agentic engineering guide (swoft.ai)、NxCode agentic engineering complete guide (nxcode.io)、Context Engineering tutorials (tutorials.technology, kemalcodes.com)、Rules文件实战经验（CSDN博客 mba16c35, dev.to）、TELUS/Zapier/Stripe案例（via nxcode.io）、腾讯云开发者社区（developer.cloud.tencent.com.cn）。
作者：Ai学长，专注AI编程与Agent实战。从本地部署到AI编程再到Agent开发，带你走完从"装AI"到"用AI赚钱"的全流程。
觉得有用就收藏，有问题评论区见。
更多推荐
7
0- 0
已为社区贡献12条内容
所有评论(0)