今年 2 月，OpenAI 在一篇题为《Harness engineering: leveraging Codex in an agent-first world》的博文中，总结了一项持续数月的工程实践。文章并不聚焦某个具体技术点，而是试图回答一个更基础的问题：当软件工程进入以智能体为中心的阶段，工程团队的工作方式会发生怎样的变化？

本文对这次实践中的经验做了梳理，希望能为同样面临这一转变的团队提供一些参考。

一个反直觉的工程决定

过去五个月里，OpenAI 的一支工程团队完成了一项在软件行业极为罕见的实验：构建并交付一款内部产品，而这款产品的代码库中，没有任何一行代码出自人类工程师之手。

这个约束并非噱头，也不是为了证明某种技术上的可能性。团队选择这条路，是因为相信它会催生出真正有价值的东西——一套能够将工程效率提升一个数量级的方法论。这款产品如今拥有稳定的内部日常用户和外部 Alpha 测试者，持续上线、部署、出现故障，也在被持续修复。让它与众不同的，只是这一切的幕后执行者：每一行应用逻辑、测试代码、CI 配置、技术文档、可观测性工具，乃至内部脚手架，全部由 Codex 生成。

据估算，这种方式使团队在约十分之一的时间内完成了通常需要手工编写的工作量。人类负责方向，智能体负责执行。

从一个空仓库开始

第一次提交发生在 2025 年 8 月下旬。那是一个真正意义上的空仓库，没有任何历史代码，没有任何人工编写的基础设施可以依赖。仓库的初始结构——包括目录层级、CI 配置文件、代码格式化规则，以及应用程序框架——全部由 Codex CLI 在 GPT-5 的驱动下，参照一批现有模板生成。甚至连引导智能体工作方式的 AGENTS.md 文件，也是由 Codex 自己写成的。

五个月后，这个仓库已经包含约一百万行代码，横跨应用逻辑、基础设施、工具链、技术文档和内部开发工具。在此期间，一支最初只有三名工程师的小团队共合并了约 1500 个 Pull Request，平均每名工程师每天提交 3.5 个 PR。随着团队规模扩展到七人，这一吞吐量持续上升。更重要的是，这些输出并非为了堆砌数字——这款产品已经被数百名内部用户使用，其中不乏每天高强度依赖它的内部核心用户。

整个开发过程中，人类工程师从未直接贡献过任何代码。这逐渐成为团队的核心信条。

工程师的职责被重新定义

当工程师不再亲手写代码，他们究竟在做什么？这个问题的答案比想象中更加丰富，也更加挑战人的直觉。

项目早期，进展比预期缓慢。但原因并不在于 Codex 能力不足，而在于它所处的环境还没有做好准备。智能体缺乏必要的工具、缺乏对系统的抽象理解、缺乏可以依赖的内部结构，因此无法从高层目标出发持续推进工作。人类工程师的核心工作，随之转变为：让智能体能够有效地完成有意义的事情。

在实践中，这意味着一种"深度优先"的工作方式——将宏观目标拆解为具体的构建模块，让智能体依次完成设计、编码、测试、审查等环节，再用这些模块解锁更复杂的任务。当某件事出了问题，解决方案几乎从来都不是"再试一次"，而是追问一个更根本的问题：这里缺少的是什么skill？如何让这个skill变得可描述、可执行？

工程师与系统的主要交互方式，是通过提示词。工程师描述一项任务，运行智能体，等待它开启一个 Pull Request。为了让 PR 顺利走完整个流程，团队要求 Codex 在本地自行审查改动，在本地和云端向其他智能体审阅者发起审查请求，响应来自人类或智能体的反馈，并循环迭代，直到所有智能体审阅者都表示满意。Codex 可以直接调用标准开发工具，无需人类从旁复制粘贴。人类工程师可以审阅 PR，但并非必须。随着时间推移，越来越多的审阅工作被推向了智能体之间的对等处理。

把仓库本身变成知识系统

让智能体在大型复杂任务中保持高效，上下文管理是最核心的挑战之一。这支团队早期得到的教训简单而深刻：给 Codex 一张地图，而不是一本一千页的操作手册。

“单一超级 AGENTS.md”的方案曾被尝试，结果果不其然地失败了。上下文是稀缺资源，一个巨大的指令文件会把任务本身、相关代码和具体文档全部挤出去；当所有内容都被标注为"重要"，没有任何内容是真正重要的；随着代码库演进，这份文件会迅速腐烂，成为充斥着过时规则的墓地，而智能体无法分辨哪些仍然有效；这样的文件也无法通过固定的手段进行校验，偏差的积累只是时间问题。

因此，AGENTS.md 被改造为一份目录，而非百科全书。仓库的知识库被组织在一个结构化的 docs/ 目录中，并作为系统的唯一事实来源。一份约 100 行的 AGENTS.md 被注入到上下文中，主要作用是提供导航指引，指向更深层的知识节点。

知识库的结构大致如下：设计文档目录包含核心信念和验证状态；架构文档提供领域划分和分层结构的全局视图；质量文档为每个产品领域和架构层打分，并持续追踪差距。计划被视为核心产物。轻量计划用于小型变更，复杂工作则通过包含进度和决策记录的执行方案来推进。这些内容与技术债等信息一起，统一纳入版本管理。

这种结构实现了"渐进式披露"——智能体从一个稳定、精简的入口点出发，被引导去寻找下一级的信息，而不是在启动时就被铺天盖地的内容淹没。专用的 Linter 和 CI 任务始终保证知识库的及时性、交叉链接的完整性和结构的一致性。一个定期运行的"文档园丁"智能体会扫描不再反映真实代码行为的文档，并自动开启修复 PR。

代码库的第一读者是智能体

随着代码库持续扩大，Codex 做设计决策的框架也必须同步演进。

由于整个仓库都是智能体生成的，它首先被优化为对智能体可读。就像工程团队会持续改善代码库对新入职工程师的友好度，这支团队的人类工程师核心目标是：让智能体能够直接从仓库本身推断出完整的业务领域知识。

从智能体的视角来看，任何在运行时无法访问的内容，实际上都不存在。那些存储在 Google Docs 里的讨论、沉没在 Slack 频道里的架构决策，以及只存在于人们脑海中的隐性知识，对系统来说都是隐形的。只有仓库本地的、经过版本控制的代码、Markdown、数据库 Schema、可执行的计划文件——才是智能体能够"看见"的。

架构约束取代微管理

仅靠文档无法维持一个完全由智能体生成的代码库的内在一致性。真正奏效的方式，是通过强制架构约束来划定边界，而不是对具体实现进行微观管理。

智能体在边界严格、结构可预测的环境中效果最好，因此整个应用围绕一个刚性的架构模型构建。每个业务领域被划分为固定的层级，依赖方向受到严格约束，允许的依赖边被限制在一个很小的集合内。这些约束通过定制化的 Linter 和结构测试重复执行。

架构规则是：在每个 business domain 内部，代码只能沿固定的层级方向“向前”依赖，从 Types → Config → Repo → Service → Runtime → UI 逐层流动。对于 cross-cutting concerns（如 auth、connectors、telemetry、feature flags），统一通过一个显式的 Provider 接口接入，其余依赖一律被约束禁止。

除了架构约束，团队还维护了一套风格约束——静态强制结构化日志记录、Schema 和类型的命名规范、文件大小上限，以及针对特定平台的可靠性要求。由于这些 Lint 规则是定制的，错误消息中直接注入了修复指引，使其对智能体同样可读。在以人为主的工作流中，这些规则可能显得繁琐甚至多余。在智能体驱动的工作流中，它们是乘数效应的来源：一旦被编码，就在每一处同时生效。

智能体接管全流程

这支团队所说的"代码库由 Codex 生成"，指的是字面意义上的一切：产品代码及其测试、CI 配置和发布工具、内部开发者工具、技术文档和设计历史、评估框架、审查评论及回复、管理仓库本身的脚本，乃至生产环境的监控面板定义文件。在这些环节中，没有任何一行是人类直接落笔的。

这一转变不仅改变了代码的来源，也从根本上改变了工程团队与代码库的关系。人类始终处于loop中，但工作发生在更高的抽象层级：决定优先级，将用户反馈转化为验收标准，验证最终结果。当智能体遇到困难，团队将其视为信号，而非障碍——识别缺少的是什么能力，把答案编码回仓库，由 Codex 自己写出那个修复。

吞吐量的提升也倒逼工程规范随之演变。传统工作流中，一个 Pull Request 可能在 CI 代码审查意见面前停滞数天，因为修复的成本远高于等待的成本。在智能体主导的系统中，这个等式完全翻转：修正是廉价的，等待才是昂贵的。仓库如今以最少的阻塞性合并运行，测试抖动通常通过后续重跑来处理而非无限期阻塞，Pull Request 的生命周期极短。在传统的低吞吐量开发环境中，采用这种快速合并策略可能显得不负责任；但在当前系统中，这往往是正确的权衡。

随着开发闭环的越来越多的环节被编码到系统，仓库最近跨越了一个具体的门槛：给定一个提示词，Codex 现在可以独立完成从复现 Bug、录制失败视频、实现修复、驱动应用验证效果、再次录制，到开启 Pull Request、响应反馈、处理构建失败、在需要判断时上报人类，最终完成合并的完整流程。

完全自主开发的问题

完全自主也带来了新型问题。Codex 会复制仓库中已有的模式，即使这些模式并不理想。随着时间积累，不可避免地导致了漂移。

起初，团队以手动方式处理这个问题，每个周五都要花费整整一天——相当于一周工作量的 20%——清理AI 遗留的冗余代码。这种方式显然无法持续。

解决方案是将所谓的"黄金原则"直接编码到仓库，并构建一个周期性的清理流程。这些原则是有主见的、固定的规则，用于保持代码库对未来智能体运行时的可读性和一致性。例如：倾向于使用共享的工具包，而不是手写重复的辅助函数，以便集中管理。

在固定节奏下，一组后台 Codex 任务会扫描偏差、更新质量分数，并开启针对性的重构 PR。其中大多数可以在一分钟内完成审阅并自动合并。

这套机制的运作方式类似于垃圾回收。技术债务更像高利贷：持续以小额增量偿还，远优于任其累积后再一次性清理。工程师的“品味”只需被编码一次，随后便可以在整个代码库中自动、持续地执行。那些问题通常能在一天内被识别并修正，而不是在代码库中扩散数周之后才被发现。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】