一个反直觉的观察

上周有个现象让我觉得很有意思：一个不到 5 人的创业团队，用 Claude Code 三天搭完了一个 SaaS 产品的核心功能，而隔壁 20 人的工程团队花了三个月才 deliver 相同复杂度的东西。

这不是个案。过去几个月，类似的效率剪刀差在 AI 编程领域越来越常见。但如果你仔细观察就会发现——快的那些团队不是因为「AI 帮他们写了更多代码」，而是因为他们根本不是在「写代码」了。

Karpathy 在本周的最新访谈里给了一个精准的命名：从 Vibe Coding 到 Agentic Engineering。这不是换了个时髦词，而是编程范式本身在发生跃迁——人的角色从「写代码的人」变成了「设计目标并管理 AI Agent 的人」。

今天就来拆解这个跃迁到底意味着什么，以及它如何重新定义了「AI 工具效率」这件事。

Vibe Coding 的瓶颈在哪里

先回顾一下 Vibe Coding 是什么。Karpathy 最早用这个词描述的是一种「凭感觉写代码」的方式：你跟 AI 对话，说清楚你想要什么，AI 给你生成代码，你跑一下看结果，不对就继续调整。本质是人和 AI 的对话式协作。

这在去年已经很强了。Cursor、Copilot、Claude 等工具让很多开发者感受到了 2-5 倍的效率提升。但 Vibe Coding 有一个结构性瓶颈：人是循环中的瓶颈。

每一轮对话，你都需要：

• 看 AI 生成的代码

• 判断对不对

• 决定下一步让 AI 做什么

• 给出新的指令

这意味着 AI 再快也没用——它在等你。你的阅读速度、理解速度、决策速度成了上限。对于复杂任务，一个功能可能需要 20-50 轮对话，每轮你花 30 秒到 2 分钟不等，算下来一个功能还是要花半天到一天。

更根本的问题是：你需要一直盯着。注意力是稀缺资源。你不可能同时 Vibe Coding 三个功能。

Agentic Engineering：让 AI 自己跑循环

Agentic Engineering 的核心思想是：把人从循环中拿出来，让 AI 自己完成「写代码→运行→检查结果→修正→继续」的循环。人的角色变成了定义目标、设定约束、提供反馈——但不参与每一步的执行。

这就是 Codex CLI 0.128.0 刚上线的 /goal 命令做的事。看看它的工作方式：

$ codex /goal "重构 auth 模块，将 session 管理从 Redis 迁移到 JWT，
  确保所有现有测试通过，并添加 token 刷新的单元测试"

# Codex 开始自主循环（Ralph Loop）：
# 1. 分析现有代码结构
# 2. 制定迁移计划
# 3. 逐步修改代码
# 4. 运行测试 → 失败
# 5. 分析失败原因 → 修正
# 6. 再次运行测试 → 部分通过
# 7. 继续修正...
# 8. 全部测试通过 → 编写新测试
# 9. 新测试通过 → 报告完成

# 整个过程中你可以去做别的事

关键变化有三个：

1. 目标导向而非指令导向。你不需要告诉 AI「先看 auth.py 的第 45 行，然后把 redis_client 换成 jwt.encode…」。你只描述最终状态，AI 自己规划路径。

2. 自主验证。AI 不是写完就停，它会自己跑测试、检查错误、修正问题。这消除了最耗时的人工检查环节。

3. 预算控制。你可以设定 token 预算，AI 在预算内尽力完成目标，超出则停下汇报进展。这让你可以放心地让 AI 跑，不担心失控。

范式对比：效率差异到底在哪里

用一个真实场景来对比。假设任务是：给一个 Express 应用添加 rate limiting 中间件，支持基于 IP 和 API Key 两种策略，写好测试和文档。

传统方式（手动编码）：

• 调研方案：30 分钟

• 编码实现：2-3 小时

• 写测试：1 小时

• 调试修正：1 小时

• 写文档：30 分钟

• 总计：约 5-6 小时，全程需要注意力

Vibe Coding 方式（对话式 AI 辅助）：

• 描述需求 + AI 生成代码：20 分钟

• 人工审查 + 修正对话：30 分钟

• 让 AI 写测试 + 人工调整：20 分钟

• 让 AI 写文档：10 分钟

• 总计：约 1.5 小时，全程需要注意力

Agentic Engineering 方式：

• 写目标描述（含约束条件）：5 分钟

• AI 自主执行：15-25 分钟（你去做别的事）

• 最终审查 + 微调：10 分钟

• 总计：约 20 分钟注意力，15-25 分钟 AI 在后台跑

注意最关键的区别不是总时间——而是注意力占用。Agentic Engineering 真正释放的是人的注意力。你可以同时给三个 Agent 设定目标，它们并行跑，你只在最后做审查。这就是为什么 Karpathy 说效率天花板「远超 10 倍工程师」。

写好 Goal 的技术：从 Prompt 到 Spec

如果 Agent 自己跑循环，那输入质量就变得极其重要。一个模糊的目标只会导致 Agent 在错误的方向上自主循环，浪费 token 和时间。

这里有个重要的认知转变：在 Agentic Engineering 范式下，写 Goal 本质上是在写 Spec（规格说明）。不是写 prompt，不是写指令，而是写清楚「完成的定义」。

一个好的 Goal 应该包含：

# 好的 Goal 示例

## 目标
给 /api/v2/* 路由添加 rate limiting 中间件

## 完成标准
- IP 策略：每个 IP 每分钟最多 60 次请求
- API Key 策略：每个 Key 每分钟最多 200 次请求
- 超限返回 429，body 包含 retryAfter 字段（秒）
- 使用 sliding window 算法，存储用 Redis
- 所有现有测试继续通过
- 新增测试覆盖：正常请求、超限、窗口重置、Key 优先于 IP

## 约束
- 不修改现有路由的 handler 逻辑
- 中间件可独立开关（通过环境变量）
- 性能要求：中间件增加的延迟 < 5ms (p99)

对比一个差的 Goal：

# 差的 Goal
"加个 rate limit 功能"

差异显而易见。好的 Goal 有明确的验收标准，Agent 可以用这些标准来自我验证。差的 Goal 让 Agent 自己猜你想要什么，大概率猜偏。

这揭示了一个有趣的事实：Agentic Engineering 对工程师的核心能力要求，从「编码」转向了「设计」和「规格定义」。写不清 spec 的人，用不好 Agent。Karpathy 说的「理解力不可外包」就是这个意思——你得真懂你要什么，才能指导 Agent 做对。

工具格局：三条路线怎么选

2026 年春季，AI 编程工具基本分化为三条路线，每条路线对 Agentic Engineering 的支持程度不同：

维度	Cursor (IDE 原生)	Claude Code (CLI)	Codex CLI (开源终端)
自主循环	部分（Agent 模式需确认）	强（auto-accept 模式）	最强（/goal 原生支持）
上下文管理	IDE 级别（文件树+索引）	项目级别（CLAUDE.md）	会话级别
并行任务	单窗口单任务	多终端并行	多终端并行
适合场景	日常开发、代码导航	重构、复杂功能开发	目标明确的自动化任务
学习曲线	低（GUI 友好）	中（需要终端习惯）	中高（需要写好 Goal）

我的判断：

• 如果你大部分时间在做存量代码的维护和小改动，Cursor 仍然是最舒服的选择。IDE 的上下文优势在这类场景下很重要。

• 如果你经常做中大型重构或新功能开发，Claude Code 的 auto-accept 模式 + CLAUDE.md 项目规范机制是当前最平衡的选择。

• 如果你的工作流可以拆分成独立目标（微服务、独立模块、自动化脚本），Codex CLI 的 /goal 模式让你并行推进效率最高。

实际上最高效的做法是混合使用。用 Codex CLI 跑后台的自动化目标，同时用 Cursor 做当前需要注意力的细节调整。这跟 Cat Wu 在 Anthropic 分享的团队实践一致——他们的工程师平均同时跑 2-3 个 Claude Code 进程。

实操：一个 Agentic Engineering 工作流

把这些概念落地，一个典型的 Agentic Engineering 工作流长这样：

晨规划：拆解今日目标
↓
为每个目标写 Spec
↓
启动 Agent 并行执行
↓
期间→ 做设计/开会/思考
↓
审查 Agent 产出
↓
通过→ 合入主分支
不通过→ 补充约束重跑

具体到 Claude Code，一个多 Agent 并行的 shell 脚本可能长这样：

#!/bin/bash
# morning_agents.sh - 启动今日并行任务

# Agent 1: 重构支付模块
claude-code --auto-accept --session "payment-refactor" \
  "按照 CLAUDE.md 规范，将支付模块从同步改为异步事件驱动。
   完成标准：所有测试通过，新增集成测试覆盖异步回调。" &

# Agent 2: 数据迁移脚本
claude-code --auto-accept --session "data-migration" \
  "编写从 PostgreSQL 到 ClickHouse 的用户行为数据迁移脚本。
   要求：增量迁移，支持断点续传，包含数据校验步骤。" &

# Agent 3: API 文档更新
claude-code --auto-accept --session "api-docs" \
  "根据 src/routes/ 下的所有路由处理函数，
   更新 docs/api/ 下的 OpenAPI 规范文件。
   确保每个端点的请求/响应示例可执行。" &

echo "3 个 Agent 已启动，预计 20-40 分钟完成"
echo "用 claude-code --session  查看进度"
wait

这段脚本启动了三个独立的 Agent，各自处理一个目标。你去开会 30 分钟回来，大概率三个任务都完成了或者在等你审查。

YC 的「AI 软件工厂」和 Anthropic 的一天发布周期

个人效率的提升是一方面，更有意思的是这个范式在团队层面产生的化学反应。

YC 合伙人 Diana Hu 本周提出了「AI 软件工厂」的概念：人定义规范（Spec）和测试（Test），AI Agent 负责实现代码。这听起来像是 TDD 的极端版本——但关键区别在于，写测试的人不需要知道实现细节，而 Agent 可以在测试驱动下自动迭代到正确实现。

Cat Wu 分享的 Anthropic 团队实践更为具体。他们的 Claude Code 产品团队做到了「一天发布周期」，核心方法论是：

• 每个 PR 足够小：一个功能拆成多个 PR，每个 PR 对应一个明确目标

• Agent 处理实现，人处理设计：工程师的时间花在 review 和方向决策上，不花在写代码上

• CI 作为 Agent 的验证环境：Agent 的每次提交都必须过 CI，失败了自动修正

这种方式的结果是：发布节奏从「两周一个 sprint」变成了「每天多次 ship」。不是因为代码质量降低了，而是因为每个 PR 足够小、足够自洽、有完整测试覆盖。

这不是银弹：Agentic Engineering 的边界

说了这么多好处，也得说清楚边界在哪里。根据最新的 ClassEval-Pro 基准测试以及实际使用经验，Agent 当前做不好或风险较高的场景包括：

1. 需要全局架构决策的任务

Agent 擅长在既定架构下执行，但不擅长判断「这里应该用事件驱动还是 RPC」。架构决策需要考虑组织上下文、未来演进方向、团队认知负担等因素——这些目前没法写进 Goal 里。

2. 没有明确验证标准的任务

Agent 的自主循环依赖于能自我验证。如果任务的「对错」很难自动判断（比如 UI 美观度、用户体验流畅性），Agent 容易陷入无效循环或给出「技术上正确但实际体验差」的结果。

3. 跨系统的复杂集成

Agent 在单个仓库内表现很好，但涉及多个服务、多个仓库、需要联调的场景，协调成本会急剧上升。ClassEval-Pro 的测试也证实：LLM 在类级别代码生成已经不错，但跨模块的依赖管理仍是软肋。

4. 安全敏感操作

让 Agent 自主循环执行意味着给它更大的权限。数据库迁移、生产环境配置变更、密钥管理等场景，目前不建议完全自主执行。Codex CLI 的 token 预算机制是个好思路，但权限控制还需要更精细的 sandbox 方案。

落地建议：如何开始转型

如果你想从 Vibe Coding 进阶到 Agentic Engineering，这是我建议的路径：

第一步：练习写 Spec

从今天开始，每次给 AI 下指令之前，先在脑中或文件中写清楚「完成的定义是什么」。包括：预期行为、边界条件、验证方式。这个习惯不依赖任何特定工具。

第二步：在低风险场景试跑自主模式

选一个有完善测试的模块，用 Claude Code 的 auto-accept 或 Codex CLI 的 /goal 试一次完整的自主循环。感受一下「放手让 AI 跑」和「逐步盯着 AI 做」的效率差异。

# 从一个简单目标开始
codex /goal "给 utils/string.ts 中的所有 export 函数添加 JSDoc 注释，
  注释包含函数说明、参数类型说明和返回值说明。
  运行 npm test 确保没有破坏任何东西。"

第三步：建立项目规范文件

无论用哪个工具，项目规范文件（CLAUDE.md / .cursorrules / codex.md）都是 Agent 的「背景知识」。写好规范文件，Agent 的自主执行质量会显著提升。重点包括：代码风格、测试策略、提交规范、禁止事项。

第四步：逐步扩大自治范围

从单文件任务 → 单模块任务 → 跨模块任务，逐步增加 Agent 的自治范围。每次扩大范围时，同步完善验证机制（更多测试、更严格的 CI、更好的 Spec）。

下一步值得关注的方向

Agentic Engineering 目前还在早期。有几个方向值得持续观察：

• Multi-Agent 协作：多个 Agent 之间如何协调？一个负责前端、一个负责后端、一个负责测试，它们之间怎么通信和解决冲突？

• Agent 的持久记忆：当前 Agent 每次启动都是「新的一天」，如何让它记住项目上下文、历史决策、踩过的坑？

• 验证机制的进化：目前主要靠测试来验证。未来是否会出现 AI 审查 AI 的模式？形式化验证能否与 Agent 结合？

• 组织结构适配：当一个工程师可以并行管理多个 Agent，传统的「N 个工程师做 N 个功能」的组织方式是否需要改变？

范式跃迁刚刚开始。快的不一定是最终赢家，但迟迟不动的大概率会被落下。

— 写于 2026.05.01 | 编程范式正在发生的变化，比多数人意识到的更快