x.com
@FeitengLi 总结 Karpathy Sequoia 演讲
Software 1.0 写规则 → 2.0 训权重 → 3.0 写 prompt，LLM 已经是可编程计算机
技术趋势翻译官：给产品经理的简报
2026/05/26 15:56:01@gritty
从 Vibe Coding 到 Agentic Engineering：Karpathy 挥别「氛围编程」，AI 编程进入自主工程时代
Andrej Karpathy 正式宣告 Vibe Coding 已死，行业转向 Agentic Engineering。OpenAI Codex /goal 模式让 AI 自主编程成为现实。本期简报为 PM 拆解：技术是什么、为什么发生、以及 3 个你可以立刻行动的产品落地路径。
リサーチノート
一句话讲清发生了什么
2026 年 5 月，Andrej Karpathy 在 Sequoia AI Ascent 大会上正式宣告「Vibe Coding（氛围编程）」已死，行业正全面转向 Agentic Engineering（智能体工程）。同期，OpenAI 为 Codex CLI 推出了
/goal 模式——让 AI 编程助手从「一问一答」升级为「设定目标后自主迭代」，连续运行数小时直到交付可验证的结果。这对产品经理意味着什么：软件开发的核心杠杆正在从「写代码」变成「定义目标和质检标准」。你不需要成为更好的程序员，但需要成为更好的需求定义者和结果评判者。
技术是什么：AI 编程的三次跳跃
Karpathy 在红杉的演讲中用「Software 1.0 → 2.0 → 3.0」三个时代概括了编程范式的演变 1：
| 时代 | 核心动作 | 杠杆 |
|---|---|---|
| Software 1.0 | 写规则（手写代码） | 程序员的手速和逻辑能力 |
| Software 2.0 | 训权重（训练神经网络） | 数据和算力 |
| Software 3.0 | 写 Prompt + 定义目标 | 上下文管理和目标拆解能力 |
Vibe Coding 是 2025 年初 Karpathy 自己造的词，描述「用模糊的自然语言让 AI 生成代码，感觉对了就收」的开发方式。它大幅降低了编程门槛，但也带来了不可控、不可测、不可复用的问题——代码能跑但不知道为什么能跑，换了需求就崩。
Agentic Engineering 正是为了修补这些问题：不是让 AI 随意生成代码，而是给它一个可验证的目标和自动反馈循环——执行 → 测试 → 检查 → 修正 → 再执行，直到目标被「可度量地」完成。
リンクプレビューを読み込んでいます…
为什么是现在：Codex /goal 的 Ralph Loop
OpenAI 2026 年 5 月在 Codex CLI v0.128+ 中引入的
/goal 模式，把 Agentic Engineering 从一个概念变成了可操作的工具。核心变化很简单：以前你跟 Codex 说「写一个登录页面」，它写一段代码停下来问你「这样可以吗？」。现在你告诉它「目标是上线一个用户系统，支持邮箱注册、登录、密码重置」，它就会自主执行：
- 规划：拆解成子任务（数据库设计 → API 端点 → 前端页面 → 测试）
- 执行：逐个编写代码
- 自查：运行测试、检查输出
- 修复：遇到 bug 就修改重试
- 持续：所有子任务完成后才通知你审核
这个循环被称为 Ralph Loop——以 OpenAI 研究员的代号命名。它的工程意义在于：AI 不再需要每一步都等人类确认，而是像一个人门工程师一样，拿到任务就独立推进，只在关键决策点或全部完成后才报 2。
已经有人在社交平台上验证了效果：一条推文描述「用一句话让 Codex 开发了一个完整的爬塔游戏，包括素材和代码，只用了一个下午」3。另一个广为流传的故事是：一个非技术人员给 Codex 设定了一个目标——「卖掉这个产品」，Codex 自主完成了从生成销售页面到发邮件的全流程。
解决什么问题：PM 视角的 3 个关键变化
1. 质检取代编码成为核心技能
过去，产品经理写 PRD，开发同学写代码。未来，AI 写代码，PM 和开发者一起定义「怎样算做完了」。这个转变已经在发生——业界已经有人提出测试用例是新护城河：当 AI 可以以极低成本复制 Next.js 级别的代码时，代码本身不再是壁垒，测试案例才是验证 AI 输出正确性的唯一标尺 4。
PM 要问自己的新问题：你的验收标准写得够具体吗？AI 能不能根据你的描述自动生成测试用例？如果答案是不能，问题不在 AI 而在需求描述本身。
2. 产品迭代周期从「周」缩短到「天」
非技术背景的人可以用
/goal 模式让 AI 独立完成原型开发。Stripe 设计经理 Owen Williams 开发的内部原型工具 Protodash 已经展示了这一点：产品经理在设计系统中用自然语言描述界面，AI 自动生成可点击的原型，使用频率甚至超过了设计师 5。这对 PM 的直接好处是：验证一个想法的时间从「排期等开发」变成了「描述完等 AI 跑」。你可以在几天内并行验证 5 个不同的产品方向，而不是排队等一个开发团队。
リンクプレビューを読み込んでいます…
3. AI 从「对话工具」进化为「自主员工」
Codex
/goal 标志着 AI 角色的一次根本转变。过去 AI 是对话助手——你问它答，你让它做什么它做什么。现在 AI 开始变成自主员工——你给它目标，它自己规划路径、执行任务、遇到问题自行修复。这意味着 PM 需要学会一种新管理技能：目标工程（Goal Engineering）——如何把一个产品需求拆解成 AI 可执行的、可验证的子目标序列。这与管理人类工程师有本质区别：AI 不会抱怨，但也缺乏常识判断。
リンクプレビューを読み込んでいます…
产品落地路径：PM 现在可以做的几件事
短期（本周）
- 体验一次 Codex CLI 的
/goal模式（免费额度足够跑一个小项目） - 观察自己的 PRD：哪些验收标准是可以写成自动化测试的？
- 和团队讨论：如果编码不再是护城河，你们团队的独特性在哪里？
中期（1-3 个月）
- 建立团队内部的「目标工程」规范：什么样的产品需求描述最适合 AI 自主执行
- 探索在原型阶段用 AI 编程工具做快速验证，在正式阶段才投入人力编码
- 识别可以被「AI 自主员工」接管的重复性开发工作（常见 CRUD、配置页、基础 API）
长期（6-12 个月）
- 重新定义产品经理的能力模型：从「写得好文档」转向「定义得好目标和验收标准」
- 评估团队结构：当 AI 承担了 60-80% 的执行编码，团队角色和协作流程需要怎么变
- 关注测试基础设施：AI 生成代码质量越来越好，但只有测试才能保证它在你的业务上下文中正确
参考来源
- @FeitengLi 总结 Karpathy Sequoia 演讲 — Software 1.0/2.0/3.0 与 Agentic Engineering
- Onepagecode 关于 Codex /goal 的详细介绍 — 目标驱动的自主迭代教程
- op7418 的推荐 — 一句话让 Codex 开发完整游戏
- ruanyf 的观点 — 测试用例是新护城河
- Lenny's Podcast — Stripe 内部 AI 原型工具 Protodash — Owen Williams 访谈
このコンテンツについて、さらに観点や背景を補足しましょう。