AI 驱动软件开发的新范式:来自 Anthropic 和 OpenAI 的前沿工程实践

当 AI 不再只是”助手”，而成为代码的”作者”和”评审员”，软件工程的游戏规则正在被彻底改写。Anthropic 和 OpenAI 近期分别分享了他们在 AI 自主编码领域的深度实践，两条路径异曲同工，指向同一个未来。

◆ 引子：两条路径，同一个终点

2026 年初，AI 编程领域出现了两篇重量级的工程实践分享。

Anthropic 的 Labs 团队成员 Prithvi Rajasekaran 发表了《Harness Design for Long-Running Application Development》，聚焦于如何通过精心设计的”脚手架”（Harness）让 Claude 自主完成长时间、复杂的应用开发。

几乎同一时间，OpenAI 的工程师 Ryan Lopopolo 发表了《工程技术：在智能体优先的世界中利用 Codex》，讲述了他们用 3 名工程师、0 行人工代码，在 5 个月内构建了一个百万行代码产品的故事。

两篇文章从不同角度切入，却揭示了相同的底层规律。本文将深入拆解两家公司的实践，提炼出对当下 AI 工程师最有价值的启示。

◆ 一、核心问题的共识：AI 编码需要”脚手架”

两篇文章不约而同地指向一个关键认知：裸跑的 AI 模型无法胜任复杂软件工程任务，你需要为它搭建”脚手架”。

Anthropic：从”上下文焦虑”到”自我评价失效”

Anthropic 识别出两个核心失败模式：

1. 上下文焦虑（Context Anxiety）

当模型的上下文窗口快填满时，它会产生一种”焦虑”——开始匆忙收尾工作，而不是继续深入。即使进行上下文压缩（compaction），由于压缩后仍保留了历史痕迹，焦虑感不会完全消除。Anthropic 发现，上下文重置（彻底清空上下文，通过结构化的交接文件传递状态）比压缩更有效。

Claude Sonnet 4.5 表现出强烈的上下文焦虑，仅靠压缩不足以支撑长时间任务。上下文重置成为关键解法。

2. 自我评价失效

当 AI 被要求评估自己的工作时，它会”自信地赞美”——即使输出质量明显平庸。这个问题在主观任务（如设计）上尤为严重，但即使是对有客观标准的编码任务，AI 也倾向于对自己的错误视而不见。

OpenAI：从”规范不清”到”情境缺失”

OpenAI 早期的困境是：不是 Codex 不行，而是环境不够明确。 AI 缺乏实现高级目标所需的工具、抽象层和内部结构。

他们的核心洞察是：给 AI 一张地图，而不是一本 1000 页的说明书。

最初他们尝试写一个巨大的 AGENTS.md 文件，把所有规则塞进去——结果失败了：

·  巨型指令文件挤占了任务、代码和文档的上下文空间

·  “一切都重要”等于”一切都不重要”，AI 会局部模式匹配而非有意识地导航

·  大型手册会迅速腐烂，变成陈旧规则的坟场

·  单一 blob 难以进行机械检查

最终方案是：AGENTS.md 只做目录（约 100 行），详细的领域知识存放在结构化的 docs/ 目录中，实现渐进式披露。

◆ 二、Anthropic 的解法：GAN 启发的多智能体架构

从设计评估到代码评审：一个统一模式

Anthropic 的核心创新是从生成对抗网络（GAN）中汲取灵感，构建”生成器-评估器”双智能体架构。

前端设计：让主观质量可评分

在前端设计实验中，他们为生成器和评估器定义了四个评分标准：

关键设计：强调设计质量和原创性而非工艺和功能性，因为后者 Claude 本身就能做好，而前者是它容易陷入”slop”（AI 惯用模式）的领域。

评估器使用 Playwright MCP 实际导航页面、截图、研究实现后再打分——而非对静态截图评分。生成器收到反馈后，可以选择迭代改进或彻底转向全新的美学方向。

在一个荷兰艺术博物馆网站的实验中，前 9 轮迭代产出了干净但常规的深色主题页面。第 10 轮，生成器彻底转向：用 CSS 透视渲染了 3D 房间，画作自由悬挂在墙上，通过门洞在展厅间导航。这是单次生成从未出现过的创造性飞跃。

全栈开发：三智能体协作系统

将上述模式扩展到全栈开发，形成了三智能体架构：

规划器（Planner）：接受 1-4 句的用户提示，扩展为完整的产品规格。被指示保持雄心勃勃的范围，但仅聚焦产品上下文和高层技术设计。

生成器（Generator）：基于规格逐功能实现。每个 sprint 实现一个完整功能，自行评估后移交给 QA。

评估器（Evaluator）：用 Playwright 点击运行中的应用，测试 UI 功能、API 端点和数据库状态。按 sprint 合同对每个标准评分，低于阈值则打回重做。

一个关键机制是 Sprint 合同：生成器和评估器在编码前协商”什么是完成”，弥合高层规格和可测试实现之间的差距。

实测结果：游戏制作工具

用一个提示词”创建一个 2D 复古游戏制作器”进行对比：

单智能体的应用看起来合理，但核心功能（游戏运行时）根本不工作。完整脚手架版本不仅功能完整，规划器还自动扩展了原始提示，加入了精灵动画系统、AI 辅助精灵生成、音效等原始提示未包含的功能。

而评估器抓到的 bug 极其具体，例如：

“第 892 行的 Delete 键处理程序要求 selection 和 selectedEntityId 同时设置，但点击实体只设置了 selectedEntityId。条件应为 selection || (selectedEntityId && activeLayer === ‘entity’)。”

这不是泛泛的”有问题”，而是可直接操作的修复指引。

脚手架的简化：随模型进化而瘦身

当 Opus 4.6 发布后，Anthropic 发现模型自身能力增强，一些脚手架组件变得不再”承重”：

·  移除 Sprint 结构：Opus 4.6 不需要将工作分解为小 chunk 也能保持连贯

·  评估器改为最终单次评审：对模型已能可靠完成的任务，评估器变成了多余开销

·  上下文重置被取消：Opus 4.5 的上下文焦虑在 4.6 上不再明显

但他们也强调：评估器不是简单的”要或不要”——它是否值得，取决于任务是否超出了当前模型独自可靠完成的边界。

◆ 三、OpenAI 的解法：代码仓库即操作系统

如果说 Anthropic 的解法是一个”精心编排的流水线”，OpenAI 的解法更像是一个”自驱动的生态系统”。

零人工代码：一个激进的实验

OpenAI 的团队做了一个极端选择：产品中不写一行人工代码。 从应用逻辑、测试、CI 配置、文档、可观测性到内部工具——全部由 Codex 生成。

结果：5 个月，约 100 万行代码，约 1,500 个 PR，由 3 名工程师推动（后来扩展到 7 名），平均每位工程师每天 3.5 个 PR。

工程师角色的根本转变

当人类不再写代码，工程师的工作重心转向了三个关键词：系统、架构、杠杆。

当事情不顺利时，解决方案几乎从不是”再努力一点”。因为让 Codex 来完成工作的唯一方式是回答：究竟还需要什么样的能力，我们又该如何让这个能力对智能体来说既清晰可读又可强制执行？

让应用对 AI 可读

OpenAI 的一个关键投入是让应用的 UI、日志和指标对 Codex 直接可读：

·  应用可以基于 git worktree 启动，Codex 为每次变更启动独立实例

·  接入 Chrome DevTools 协议，创建 DOM 快照、截图和导航技能

·  接入完整的可观测性堆栈（日志+指标+链路追踪），Codex 可用 LogQL/PromQL 查询

·  临时环境：任务完成后包括日志和指标在内的所有内容都被销毁

这使得提示词可以非常具体：“确保服务启动在 800ms 内完成”或“这四个关键用户旅程中的任何跨度都不得超过两秒”。

规范架构与”品味不变式”

在人类团队中，严格架构通常要等团队达到数百人才会推行。但对于编码智能体，这是早期先决条件：有了约束，速度才不会下降，架构才不会漂移。

OpenAI 的架构规则：

·  每个业务域内，代码只能”向前”依赖固定层：Types → Config → Repo → Service → Runtime → UI

·  横切关注点（认证、连接器、遥测、功能标志）通过单一显式接口进入

·  自定义 linter 静态强制执行结构化日志、命名约定、文件大小限制

·  错误信息中注入修复指令——这样 AI 遇到 lint 错误时能直接知道怎么修

核心理念：通过强制执行不变量，而非对实施过程进行微观管理，让智能体快速交付且不削弱基础。

技术债的”垃圾回收”

完全自主的 AI 编码会放大已有模式——包括不好的模式。OpenAI 团队最初每周五花 20% 的时间手动清理”AI 残渣”，很快意识到这不可扩展。

他们的解法：将”黄金原则”编码到代码仓库中，并定期运行后台 Codex 任务扫描偏差、更新质量等级，发起针对性的重构 PR。大多数可以在一分钟内审查并自动合并。

技术债就像一笔高息贷款：不断地以小额贷款的方式偿还债务，总比让债务不断累积再痛苦地一次解决要好得多。

端到端自主的里程碑

OpenAI 描述了一个惊人的自主级别：给定一个提示，智能体可以：

1.  验证代码库当前状态

2.  复现已报告的 bug

3.  录制故障演示视频

4.  实施修复

5.  通过运行应用验证修复

6.  录制修复演示视频

7.  打开 PR

8.  回应智能体和人类反馈

9.  检测并修复构建故障

10. 仅在需要判断时才交由人工处理

11. 合并变更

◆ 四、交叉对比：两种范式的异同

共识大于分歧

尽管方法不同，两家公司达成了几个关键共识：

1. AI 不能有效评估自己的工作 — Anthropic 用独立评估器解决，OpenAI 用智能体间互审解决。

2. 上下文是最稀缺的资源 — Anthropic 用上下文重置管理，OpenAI 用渐进式披露和结构化知识库管理。

3. 分解是必要的 — Anthropic 分解为 sprint 和合同，OpenAI 分解为执行计划和领域层。

4. 规则必须可执行 — Anthropic 的评估标准是可评分的，OpenAI 的架构规则是由 linter 强制的。含糊的指导对 AI 无效。

5. 脚手架必须随模型进化 — Anthropic 明确在 Opus 4.6 发布后简化了脚手架，OpenAI 也在持续调整其规则和工具。

◆ 五、对 AI 工程师的实践启示

1. 你不再是编码者，你是环境设计师

两家公司都指向同一个角色转变：工程师的核心工作不再是写代码，而是设计让 AI 能高效工作的环境。 这包括：

·  清晰的架构约束和分层规则

·  可被 AI 读取和执行的质量标准

·  渐进式的知识披露（而非信息轰炸）

·  自动化的验证和反馈回路

2. 把”品味”变成代码

无论是 Anthropic 的评分标准还是 OpenAI 的”品味不变式”，核心思想一致：主观判断必须被操作化为可执行的规则。 “代码质量要好”对 AI 无效，”这一层不能依赖那一层，违反则 lint 报错并附修复指令”才有效。

3. 评估要独立，反馈要具体

Anthropic 的评估器之所以有效，是因为它（a）独立于生成器、（b）实际操作运行中的应用、（c）给出可直接操作的修复指引。模糊的”不太好”不如具体的”第 892 行的条件逻辑有误”。

4. 简单优先，复杂只在必要时

Anthropic 的迭代经验清晰表明：每增加一个脚手架组件，都在编码一个”模型做不到”的假设。这些假设值得持续检验——模型在进化，今天的”承重组件”明天可能变成多余开销。

5. 技术债要持续还，不要累积

OpenAI 的”垃圾回收”模式和 Anthropic 的迭代反馈循环本质相同：小步持续修正，而非大爆炸重构。 AI 会放大已有的模式——好的和坏的都一样。

◆ 六、展望：脚手架的空间不会缩小，只会移动

Anthropic 的文章给出了一个深刻的展望：

随着模型的持续改进，有趣的脚手架组合的空间不会缩小。相反，它会移动。AI 工程师有趣的工作是持续找到下一个新颖的组合。

这意味着：今天你需要评估器来抓 bug，明天模型自己就能抓到——但那时你可能需要一个评估器来判断产品体验是否流畅，或者架构决策是否合理。模型能力的前沿持续外推，脚手架的价值边界也随之移动。

OpenAI 的实践经验同样印证了这一点：随着 Codex 能力增强，他们不是撤掉脚手架，而是将脚手架从”帮 AI 写代码”升级为”帮 AI 设计系统和认知环境”。

对于每一位软件工程师而言，这场变革的核心问题不是”AI 会不会取代我”，而是”我是否在用 AI 的方式思考工程问题”。设计环境、编码意图、构建反馈回路——这些才是 AI 时代工程师的核心竞争力。

参考来源：

·  Anthropic: Harness Design for Long-Running Application Development

·  OpenAI: 工程技术：在智能体优先的世界中利用 Codex