上下文工程——Vibe Coding 之后的下一个战场
Site Owner
发布于 2026-04-16
Vibe Coding的下半场不是更好用的AI代码工具，而是上下文工程——建环境让AI自主工作，而非告诉AI做什么。OpenAI Frontier团队5个月100万行代码、1500个PR的实战揭示：代码已变成消耗品，上下文才是真正的护城河。
上下文工程——Vibe Coding 之后的下一个战场
OpenAI Frontier 团队，5 个月，100 万行代码，零行人类编写。代码评审不靠人，合并前的 PR 全部由 AI 自主完成。
这个团队每天消耗 10 亿 token——大约 2000 到 3000 美金。团队负责人 Ryan Lopopolo 在 Latent Space 播客里说，如果你不这么做，就是"疏忽"。吝啬 token，就是吝啬效率。（来源：Latent Space 播客）
这不是 POC，不是 demo。这是 OpenAI 内部正在跑的生产系统。
洞察一：当 AI 评审比人靠谱，人的角色变了
Ryan 团队最开始只有三个人，产出了接近百万行代码、1500 个 PR。他们是怎么做到的？
答案听起来很反直觉：不写代码，建环境。
他们的产品叫 Symphony，被外界称为"幽灵库"——代码库里没有任何实际代码，只有让 AI agent 自主生成代码所需的所有上下文、规范和工作流。
代码评审？AI 自己做。Ryan 说他们已经不太依赖"人类做代码评审"这件事了，大多数评审发生在 merge 之后，更像是一种让自己"安心"的仪式。
"我对代码细节已经没有执念了，更像是在管理一个 500 人的团队——你不可能逐个 PR 深入细节。"——Ryan Lopopolo
这不是偷懒，而是角色转移。当你每天并行跑四个 Codex 实例，每个都能独立完成一个完整的 PR 生命周期——创建、等待 review、修复 flaky、处理冲突、重新合并——人的角色就从"执行者"变成了"系统设计师"。你不再关心代码怎么写，只关心系统怎么运转。
洞察二：MCP 已死（在他们的场景下）
Ryan 对 MCP 的态度很直白："MCP 已经死了。"
需要加一个限定——这是在 OpenAI Frontier 团队的高并发 agent 场景下的判断。原因很具体：MCP 会强制往上下文里注入大量 token，影响自动压缩，agent 甚至可能忘记怎么用这些工具。而他们实际需要的 Playwright 调用可能就三种。
他们后来直接写了一个本地 daemon，封装 Playwright，暴露极简 CLI。Ryan 说他完全不知道这件事发生过——对他来说，"只是运行 Codex，然后它变得更强了"。
更激进的是 Ryan 对软件依赖的判断：几千行代码的中低复杂度依赖，AI 可以在一个下午内重写。 通用库为了通用性引入了大量冗余，自己实现只需要最小集。
OpenAI 董事会主席 Bret Taylor 也呼应了这个判断：软件依赖可能会消失，未来可以直接"内嵌"。
代码从资产变成了消耗品。 不需要维护，不需要升级依赖，不需要等上游发版——直接重写比修改更便宜。
洞察三：上下文工程 ≠ 提示词工程
很多人把 Ryan 的做法理解成"写更好的 prompt"。Ryan 自己纠正了这个误解：
"当 AI 失败时，不要上来就想着改进提示词，而是问：缺少什么能力、上下文或结构？"
提示词工程是"告诉 AI 做什么"。上下文工程是"给 AI 建一个工作环境"。
Ryan 团队的幽灵库拆成七层架构，但真正值得展开的是两端：顶层的策略层和底层的**"第零层"**。
策略层是"机构知识"——不需要写代码就能保证 CI 通过、构建时间不超过一分钟、PR 流程自动运转。这些约束不是靠人盯着，而是靠文本规范驱动 agent 自觉遵守。
"第零层"更激进——skill 蒸馏机制。agent 回顾自己的 session log，分析"我该如何更好地被使用"，然后把改进反馈回代码库。每个 agent 的 bug 都意味着有某个"尚未被写下来的规范"，找到它、写下来，系统就进化了一步。每个人的经验都会自动变成团队的能力。
开源项目 GSD（Get Shit Done，5 天 5 万 Star）走的是同一条路。它解决的是"上下文腐烂"——对话一长，AI 输出质量断崖式下跌。GSD 的做法是每个子任务在全新的 200k token 上下文窗口里独立执行，主窗口始终干净。让 AI 永远在巅峰状态干活，不会越干越差。
洞察四：一分钟构建纪律——代码是为 AI 写的
Ryan 团队有一条硬性规则：构建时间超过一分钟，就停下来重构。
这条规则背后的逻辑链条很清晰：模型需要快速验证改动是否正确 → 构建越快，内部循环越短 → agent 迭代效率越高 → 整体产出越多。
他们为此在一周内从 Makefile 切到 Bazel，再到 Turbo，最终停在 NX。对 7 人团队来说拆成 500 个 npm package 是严重过度设计，但如果把每个"人"看成 10 到 50 个 agent，这个规模就合理了。
Ryan 说了一个关键概念：未来的软件必须首先对 Agent 可读。 "如果软件充满了隐性上下文，Agent 就无法有效工作。"
传统 MVC 的 AI 原生版本是 Model-View-Claw——Claw 就是 harness。
洞察五：核心竞争力从"写好代码"变成"定义好问题"
Ryan 把人类的价值浓缩成一张二维坐标：问题是"简单/复杂"和"已有/全新"。"复杂 + 全新"的问题，仍然需要人类。其他象限，agent 已经可以处理了。
这意味着核心竞争力的转移：从"写好代码"变成"定义好问题"，从"实现功能"变成"设计系统"。
Ryan 说，agent 的每一个 bug 都意味着有某个"尚未被写下来的规范"——找到它，写下来，agent 下次就不会再犯。人的价值不再是写代码，而是把脑子里"什么是好"的隐性知识，显性化为系统的一部分。
这和 GSD 的逻辑完全一致：拆任务、给上下文、设验收标准、让 AI 在干净环境里执行。人类不碰代码，只碰结构。
Vibe Coding 让所有人都能写代码。上下文工程让 AI 不需要你写代码。
这两个变化叠加在一起，指向一个清晰的未来：代码本身会变得极其廉价，而为 AI 设计上下文环境这件事，会成为最贵的能力。 这不是让 AI 写更好的代码，是让自己不再需要关心代码。