今天这篇文章展现了软件工程史上的一个 “奥本海默时刻”：开发的核心矛盾已经从“如何写出复杂的逻辑”转向了“如何构建一个能让智能体稳定输出逻辑的环境”。
作者：Numman Ali，英国FinTech公司RetailBook CTO，专注应用AI、企业级Agentic编码与产品策略。致力于构建AI代理记忆系统、OpenSkills与CC Mirror项目，推动代理原生开发转型。
OpenAI、StrongDM 和我如何在互不沟通的情况下，各自得出了使用编码智能体构建软件的相同流程。
OpenAI 刚刚发布了其工程团队如何用五个月时间构建出一款真实产品的过程——其中的每一行代码都由 Codex 编写。
本月初，StrongDM 公开了他们的“软件工厂（Software Factory）”，这套系统由智能体负责编写和审查所有代码，无需人类干预。
自 2025 年 11 月以来，我也在我的公司实践着同样的事情。
三个团队，没有事先沟通，却得出了相同的结论。
请随我深入了解细节。
OpenAI 的实践
他们的团队从 2025 年 8 月的一个空 Git 仓库开始。五个月后：
- 约 100 万行代码
- 合并了约 1,500 个 Pull Request
- 起始成员 3 名工程师（现为 7 名）
- 预估比纯手工编写快 10 倍
每一行代码都由 Codex 编写：应用逻辑、测试、CI 配置、文档、内部工具。人类从不直接贡献代码。这已经成为核心理念，而不仅仅是一种限制。
最有趣的不是产出量，而是工程师角色发生的转变。
“我们工程团队的首要工作变成了：赋能智能体，使其能开展有效的工作。”
当任务失败时，问题不再是“我该如何写出更好的提示词（Prompt）？”，而是“这个智能体缺失了什么能力或上下文？我该如何让这些信息变得可读/可理解？” 他们把时间花在构建反馈环、结构化文档和设计运行环境上。代码只是副产品。 据报告，单次 Codex 运行可以连续工作六个小时处理一个任务。通常是在团队睡觉的时候。
StrongDM 的实践
这是一个自 2025 年 7 月起工作的三人团队。Justin McCarthy（StrongDM CTO）、Jay Taylor 和 Navan Chauhan。他们在 2 月 7 日公开了项目，当天就登上了 Hacker News 首页，Simon Willison 也随即进行了报道。
他们最硬核的观点是：像对待模型权重一样对待生成的代码。代码是不透明的。不要为了正确性去读它。要通过外部行为来验证它，就像你通过输出来评估神经网络一样。唯一重要的是：这玩意儿能不能跑通。
为了实现严谨的验证，他们构建了“数字孪生宇宙（Digital Twin Universes）”：Okta、Jira、Slack 和 Google Docs 的行为克隆体。这些全量的 API 副本让智能体每小时可以运行数千个集成场景，且没有速率限制、没有 API 成本，也不会触发滥用检测。
测试场景存储在代码库之外，作为“留出集（Holdout Set）”。这是关键的一步：如果测试留在仓库里，智能体可能会改写测试来适配错误的代码。外部留出集是无法被操纵的。 他们的编码智能体 Attractor 仅由三个 Markdown 文件组成。全是自然语言规范（Specs）。把它们交给任何现代编码智能体，它就能完成自我构建。
沉淀出的模式
这些团队并未协作，在发布之前也没看过对方的工作。以下是他们共同的发现：
- “无聊”的技术方案胜出两个团队都选择了可组合、稳定且文档齐全的工具。OpenAI 表示，“无聊”的技术对智能体更友好，因为它们在训练数据中占比高，且 API 稳定。他们甚至不惜重新实现工具库，也不愿引入行为不可预测的第三方包。StrongDM 运行 Go 和 Rust。没人选择冷门技术。
- 代码仓库是唯一的真理如果知识存在于 Slack 讨论、某人的脑袋里或 Google 文档中，智能体就看不见它。看不见即不存在。OpenAI 的
AGENTS.md 只有约 100 行，它不是百科全书，而是一个指向其他结构化文档的目录。StrongDM 使用 Markdown 编写自然语言规范。一切皆可发现，一切皆有版本控制。 - 每个分支都有完整环境在任何人评审之前，智能体需要运行它构建的东西。OpenAI 实现了基于 Git 工作树（worktree）的 App 启动方式，以便 Codex 为每次变更启动自己的实例。他们将 Chrome DevTools 协议接入运行时，让智能体能驱动 UI、截屏并从视觉上验证工作。
- 强制性自动化验证OpenAI 的智能体通过 DevTools 协议和可观测性工具进行验证。StrongDM 通过外部留出场景验证。两个团队都不信任智能体自报的“置信度”。
- 智能体互审（Agents reviewing agents）OpenAI 将几乎所有的代码审查推向了“智能体对智能体”的闭环。人类可以介入，但通常不介入。StrongDM 则彻底取消了人工审查。
- 持续清理OpenAI 团队以前每周五都要花时间修复智能体生成的偏差（他们称之为“AI 废料”）。但这无法规模化。现在他们运行常驻智能体扫描模式违规，并开启小型重构 PR。这是垃圾回收机制，而不是春季大扫除。
为什么是现在？
GPT 5.2 Codex Extra High——改变一切的模型。在这一代模型之前，智能体无法在长时间跨度内处理复杂工作（上下文会腐化/腐烂），无法在无人监管的情况下端到端地交付大功能。 过去你可以完成定义明确的小任务，但无法处理涉及架构决策、需要跨多个功能持续推进的需求。 这个瓶颈刚刚被打破。新的 Codex 模型完全是另一个物种，它能以从未见过的效率摧枯拉朽般地完成工作。
现在，单个智能体可以：
- 接收 Bug 报告 -> 复现故障 -> 录制演示视频 -> 实现修复 -> 驱动应用验证修复 -> 开启 PR -> 回复审查反馈 -> 处理 CI 失败 -> 合并。
一个提示词即可完成。 OpenAI 报告称这种情况已成常态。单次运行持续 6 小时，在团队睡觉时产出可运行的功能。 模型能力跨越这个阈值，才让后续的流程变得可行。如果没有模型持续连贯工作的能力，无聊的技术、结构化仓库或自动化验证都毫无意义。
我现在如何构建软件
我在 2025 年 12 月初（Opus 4.5 和 GPT 5.2 发布时）完成了转变。能力提升到了一定程度，使得经济账发生了反转：我停止了编写代码，开始设计环境。
在 RetailBook，我运行着一个庞大的 TypeScript Monorepo，包含 6 个应用和 20 多个共享包。 实际的工作流如下：
- 规划： 每个功能都由 Claude Opus 4.6 编写计划。Opus 对意图的理解比我用过的任何模型都好。它能捕捉功能背后的“为什么”、边缘case以及集成点。然后由 GPT 5.3 Codex 增强计划的严谨性，填补技术细节。
- 实现： 然后攻守易势。Codex 接手并完成所有的端到端实现工作。写代码、写测试、更新配置、处理依赖。整个链路中没有人类代码。
- UI 审查： 如果涉及前端，Opus 会进行第二次扫描。它查看生成的 Playwright 截图，捕捉 Codex 遗漏的视觉问题。Opus 在理解 UI 观感是否正确方面强得多。这种“双模型”方法能达到单模型无法企及的效果。
- 代码审查： PR 开启后，多个 GitHub Action 支持的智能体（运行不同模型）会进行审查。从不同视角审视同一段代码。任何发现都会路由回 Codex 进行修复。循环往复，直到所有智能体审查通过。
高风险变更仍需人工。 我会查看 PR 并检查预览部署。并非每个 PR 都需要，但有些确实需要，而"知道哪些需要人工"是目前尚未自动化的判断力的一部分。
测试与环境：每个分支都会在整个 Monorepo 中获得一套完整的预览部署——全部 6 个应用、全部 20 多个共享包。 基于场景的种子数据确保一切可覆盖、可复现。不是随机的测试固件（Fixtures），而是经过精心设计的、模拟真实用户旅程的场景。 通过 Playwright 的端到端（E2E）测试是强制性的。没有通过测试，PR 就不能合并。测试套件之所以快，是因为我从一开始就按这个目标设计。 一切对智能体可见可达。功能开关（Feature Flags）由智能体管理。本地开发环境、预发布环境、生产环境、所有日志——如果智能体无法触达，它就无法推理。这与 OpenAI 和 StrongDM 独立发现的原则一致。
一个人就是一支队伍
这是我从未公开说过的：我是一个人的工程团队。我曾尝试招聘三次，但极其困难。现在的岗位已经不再是“软件工程师”了。它是工程师、产品经理和智能体编排者（Agent Orchestrator）的合体。 你需要一个能设计系统、将产品意图转化为规范、并构建能让智能体高效产出的“脚手架”的人。这种组合目前非常罕见。
我最终确定的职位头衔是：资深智能体原生产品工程师（Senior Agent Native Product Engineer）。
我终于找到了第一个雇员，他们下个月入职！一切都为他们准备好了：Monorepo、CI、预览环境、智能体工作流、文档。他们走进的是一个为编排而设计，而非为编码而设计的系统。
随着我发现更多奏效的模式，我会持续分享。这还处于早期，流程仍在成型中。但方向是明确的，OpenAI 和 StrongDM 的独立验证让我确信这条路是对的。
走向何方
三个团队得出了相同的答案，是因为所有人都面临同样形状的问题：如何让智能体在极少人工干预下，完成可靠、持续的工作。工程纪律并未消失，只是转移了。从代码转移到了脚手架。从编写软件转移到了设计环境、反馈环和验证系统——让智能体能写出好的软件。 这并非预言。这是对现状的描述。
注：我希望你能看出来，我真的很喜欢用 Nano Banana Pro。
原文：https://x.com/nummanali/status/2021692332849131738[1]
解读
以下是高可用架构对文章核心要点的总结与解读：
📋 核心总结：开发范式的“三位一体”
文章指出，无论是个体开发者还是顶级 AI 团队，都在 2026 年初达成了一个高度共识，即 “智能体原生开发（Agent-Native Development）” 的三大支柱：
- 基础设施即底座（The Scaffolding）： 工程师不再直接操作代码，而是构建“脚手架”（如
AGENTS.md、自动化环境部署、API 副本）。代码仓库（Repo）成为了智能体的唯一真理来源。 - 验证胜于审查（Validation over Review）： 放弃逐行审阅代码逻辑，转而像测试神经网络模型一样，通过外部的“数字孪生环境”和“留出集测试”来验证程序的行为结果。
- 技术栈的“回归平庸”： 为了降低智能体的理解成本，开发者主动选择了成熟、稳定、甚至有些“无聊”的工具链（如 Go, Rust, TypeScript），避免使用过于前卫或不稳定的库。
💡 深度解读：从“石匠”到“建筑师”的进化
从这篇文章中，我们可以读出软件行业正在发生的深层逻辑转变：
- “代码不透明化”趋势： 文中最激进的观点是“将生成的代码视为模型权重”。这意味着人类正在逐渐丧失（或主动放弃）对每一行代码的微观控制权。这类似于从汇编语言转向高级语言的过程，只不过这次我们跳过的是“逻辑表达”，直接进入了“意图实现”。
- 工程师职能的重定义： “Senior Agent Native Product Engineer” 这个头衔预示着未来的核心竞争力不再是 Debug 的速度，而是系统设计（System Design）和上下文工程（Context Engineering）的能力。你必须能准确地把复杂的产品意图拆解为智能体可执行的任务。
- 经济模型的临界点： 作者提到 2025 年底是“经济账翻转”的时刻。当模型（如 GPT 5.2/Opus 4.5）的上下文保持能力和逻辑一致性跨越某个阈值后，维护一套智能体自动化系统的成本将低于雇佣、沟通和管理人类开发者的成本。
洞察： 这不仅仅是效率的 10 倍提升，它本质上是 “软件工业化”的第二次革命。如果说第一次革命是开源软件和云原生的普及，那么第二次革命就是“智力资源的自动化编排”。
参考阅读
