2026年造个百万行代码的产品，零行人工手写，三个月干完，凭啥？
OpenAI内部团队搞了个狠活：从空的Git仓库起步，五个月堆出百万行代码，全靠Codex智能体，人类一个字符没敲。这篇东西不是讲AI写代码多快，而是讲怎么给AI搭个笼子让它不乱飞。
这套方法叫Harness Engineering，核心就一句话：别指望AI自觉，把规矩写进环境里。
团队从空仓库起步把人类代码彻底清零
Ryan Lopopolo团队最初在一个空荡荡的Git仓库里做了第一次提交。这次提交没有一行人类写的代码，全是Codex CLI用GPT-5生成的，连指导AI怎么干活的AGENTS.md文件都是AI自己写的。他们的核心理念就六个字：不手动写代码。
五个月后，这个仓库膨胀到一百万行代码，从应用逻辑、测试、CI配置、文档到内部工具全齐了。期间开合了大约1500个Pull Request，推动这一切的只是个三人工程师小团队。换算下来平均每个工程师每天处理3.5个PR，而且团队扩到七个人之后吞吐量还在涨。最关键的是这产品真有几百个内测用户在天天用。
人类在整个过程中唯一干的事就是设计环境、明确意图、构建反馈回路。代码生成、测试、修复、甚至审查全是智能体在跑。人类的时间和注意力成了唯一稀缺资源，所有精力都花在让AI能干活上，而不是自己动手写。
早期进度慢得像蜗牛爬因为环境没搭好
刚开始那会儿进展慢得让人想砸电脑。不是Codex不行，是环境太糙了。智能体想干活但缺工具、缺抽象层、缺内部结构，根本推不动。团队很快就悟了：工程师的主要任务变成了帮智能体扫清障碍。
具体怎么扫？把大目标拆成小块，提示智能体去构建这些小块，然后用小块解锁更复杂的任务。遇到卡壳的时候，解决方案再也不是"再努力一点"，因为唯一推进方式就是让Codex完成工作。人类工程师只能追问：还缺什么能力？怎么让这个能力对智能体来说清晰可读又可强制执行？
人类几乎完全通过提示跟系统交互。工程师描述任务，Codex跑起来，打开Pull Request。为了让PR能合进去，Codex被指示在本地审查自己的改动、请求其他智能体审查、响应所有反馈、循环往复直到所有审查者满意。整个过程人类可以审核PR但不必需，到后来绝大部分审查都改成智能体对智能体了。
瓶颈从写代码变成人测不过来于是让AI自己测
代码生成速度上来之后，新的瓶颈冒出来了：人工QA根本测不过来。人类的时间和注意力就那么多，Codex一晚上能生成的代码人两天都测不完。解决方案很反直觉：让应用程序对Codex直接可读。
他们让应用程序能根据git worktree启动，Codex为每次改动都能启动并驱动一个实例。还把Chrome DevTools协议接入智能体运行时，创建了处理DOM快照、截图和导航的技能。Codex能自己复现错误、验证修复、直接推理UI行为。日志、指标、追踪记录都通过本地可观测性堆栈展示给Codex，每个工作树都是临时的，任务跑完全删。Codex能用LogQL查日志、PromQL查指标。提示词可以写成"确保服务启动在800毫秒内完成"这种级别。
经常能看到单次Codex运行在一个任务上连续干六个多小时，通常是人类睡觉的时候。这就等于你睡觉AI加班，第二天起来PR已经躺在仓库里了。
地图比说明书管用因为智能体记不住那么多
最早他们试过一个巨型AGENTS.md文件，把所有规矩全塞进去。结果翻车翻得很彻底。情境是稀缺资源，大指令文件挤占了任务和代码的空间，智能体要么漏掉关键约束要么对着错误约束使劲优化。指导太多反而无效，什么都重要就等于什么都不重要。而且巨大手册腐烂得飞快，过时规则堆成坟场，智能体分不清哪个还管用。
解决方案很聪明：把AGENTS.md当目录用，不当百科全书。知识库放结构化docs目录里当记录系统，AGENTS.md只有大约100行，主要当地图使，指向更深处的真相来源。实现了渐进式披露：智能体从小而稳的切入点开始，指导它下一步去哪看，不被信息淹没。
他们还用专职linter和CI作业验证知识库更新状况、交叉链接和结构正确性。定期跑个文档园艺智能体，扫描过时废弃文档并发起修复PR。这套机制保证了规矩不会烂在角落里。
代码仓库成了唯一真相来源所有知识往里塞
从智能体角度看，运行时情境里访问不到的东西统统不存在。Google Docs里的、Slack聊天里的、人脑子里的，系统一概看不见。仓库本地的、版本化的工件就是全部世界。那次让团队达成架构共识的Slack讨论，如果智能体发现不了，它就跟你迟来三个月入职一样啥都不知道。
把系统的更多部分转化成智能体能检查、验证、直接修改的形式，直接提高了杠杆效应。这不仅对Codex管用，其他参与仓库的智能体也受益。存储的知识越来越多，Codex推理的起点越来越高，每次跑任务不用从零瞎猜。
架构约束靠检查器硬管而不是靠文档苦口婆心
光靠文档没法保持完全由AI生成的代码库不散架。Ryan团队的做法是通过强制执行不变量来保持连贯性，不微观管理实施过程。比如要求Codex在边界处解析数据形状，但不规定用哪个库。智能体在严格边界和可预测结构的环境里效率最高。
他们围绕严格架构模型构建应用，每个业务域分固定层，依赖方向严格验证，只允许有限边。这些约束通过自定义linter和结构测试机械强制执行。特定领域里代码只能向前依赖固定层，横切关注点通过单一显式接口进入，其他都不允许，自动工具直接拦。
这种架构通常要有几百个工程师时才考虑搞，但对于编码智能体来说是早期先决条件。有了约束速度才不会降，架构才不会飘。他们在代码里还编码了一小组品味不变式，比如结构化日志命名约定、文件大小限制、平台可靠性要求。linter出错信息直接注入修复指令，AI看到报错就知道怎么改。
审查门禁变少了因为AI吞吐量碾压人类注意力
Codex吞吐量上来之后，传统工程规范不适用了。Pull Request生命周期变得很短，测试偶发失败直接后续重跑解决，不无限期阻塞进展。在一个智能体吞吐量远超人类注意力的系统里，纠错成本低而等待成本高。低吞吐量环境这么做不负责任，但在这里这通常是对的。
吞吐量改变的不只是节奏，还有整个工程文化的底层逻辑。以前怕犯错是因为人修起来费劲，现在AI改代码跟喝水一样快，犯错成了学习信号而不是灾难。每一次跑偏都被记录、被分析、被编码成新规则，下次AI自己就绕开了。
智能体已经能端到端驱动整个功能开发流程
随着越来越多环节被编码进系统，仓库最近跨过了重要门槛。给定一个提示，Codex现在能验证代码库当前状态、重现已报告漏洞、录故障视频、实施修复、跑应用验证、录修复视频、开Pull Request、回应审查反馈、检测修复构建故障、只在需要判断时交给人、最后自己合并更改。
整套流程完全自动化，人类只在关键判断点介入。这种行为高度依赖此仓库的具体结构和工具，不能随便泛化，但方向已经很清楚了。智能体自主水平在持续提高，每次新规则加入都让它们少撞一次墙。
熵和垃圾回收成了新问题因为AI会复制坏模式
完全自主的智能体也引入了麻烦。Codex会复现仓库里已有的模式，包括那些不均衡不理想的。时间一长漂移不可避免。最初人类手动清理，每周五花20%时间收拾AI残渣，根本不具备可扩展性。
解决方案是把黄金原则直接编码进仓库，建立循环清理流程。原则是带主观意见的机械规则，保持代码库可读性和一致性。比如倾向于共享实用程序包集中管理不变式，不搞YOLO式探测数据，验证边界或依赖类型化SDK。定期运行后台Codex任务扫描偏差、更新质量等级、发起针对性重构PR，大多数一分钟就能审查完自动合并。
这功能像垃圾回收。技术债务像高息贷款，不断用小额偿还比累积起来一次痛苦解决强得多。人类品味一旦捕捉就持续应用于每行代码，每天发现并解决不良模式，不让它们在仓库里传播数天数周。
微调不如搭环境因为换模型不丢规矩
Ryan在Hacker News回复里直接挑明了：Harness Engineering本质上是一种RSI，但比微调高明太多了。微调是花钱花时间把规矩塞进特定模型脑子里，换新模型版本就得重来。但环境规则写在仓库里，今天用GPT-4守这些规矩，明天换GPT-5，检查器还在、规则还在、历史教训还在。花一次功夫搭环境，后面所有模型版本通吃。
便宜模型也能在这套护栏里干活。先用大模型把静态验证规则和检查脚本搭好，然后让便宜模型在里面跑。违规就报错，重试到过为止。重试成本低得可以忽略。大模型花一次钱把规矩钉死，后面每次执行都用便宜模型试错，总成本肉眼可见往下掉。
harness-engineering
github：lopopolo/harness-engineering：这个GitHub仓库，就是OpenAI官方博客文章的“实操落地版”、“工具箱”和“现场施工图”。
它们的关系，简单说就是“理论方针”与“实战弹药”的关系。你可以把博客文章看作“为什么要打这场仗”的战略宣言，而这个仓库就是“具体怎么打”的武器库和战术手册。
博客文章（点击标题）提出了Harness Engineering（ harness engineering，即“引导工程”或“ harness 工程”）的完整理念：通过塑造环境（上下文和工具），而不是修改模型本身，来成倍提升AI智能体的工作表现。
而这个GitHub仓库 (github.com/lopopolo/harness-engineering) 正是作者Ryan Lopopolo为了让这套理念能被直接“使用”而建立的。它不是一个空有理论的说明文档，而是一个可以直接喂给AI智能体的“上下文包”。
仓库里的“干货”直接对应文章里的“方法”
文章里提到的核心方法，在这个仓库里都能找到对应的“实体文件”：
- 文章说：要用一个精炼的AGENTS.md作为“地图”来路由任务。
- 仓库里就有： 根目录下的 AGENTS.md 文件。它就像一个总调度员，告诉被“投放”到这个仓库的AI智能体：“你的任务目标在这里、主要的论证索引在那里、具体案例请去行动手册（playbooks）目录查找。”
- 文章说：要构建结构化的docs/目录作为“记录系统”，实现知识的渐进式披露。
- 仓库里就有： docs/ 目录。里面按主题（如durable-systems/, playbooks/）清晰组织了更深入的文档，智能体可以根据需要逐层深入，不会被海量信息淹没。
- 文章说：要将“品味和不变量”编码成可执行的检查器（如linter）。
- 仓库里就有： evals/ 目录。这里包含了用于评估和验证的脚本，正是将抽象规则转化为具体“护栏”的代码实现。
- 文章说：要提供“行动手册（playbooks）”来指导具体应用。
- 仓库里就有： playbooks/ 目录。这里存放着针对不同场景的“操作指南”，智能体可以直接参照里面的步骤来执行复杂任务。
一个可“投喂”给AI的知识库
如果你想让你的AI编程助手（比如Codex）学会Harness Engineering这套方法论，你不需要让它去反复读那篇长文章，而是直接把GitHub上这个仓库的地址“喂”给它。
仓库里的 README.md 第一句话就点明了这个用法：
“Most people do not know that they can just point their agents at my writing, tweets, podcasts, and talks and improve the output of their agents by 100x.”
这个仓库就是Ryan把自己的思想、文章、演讲浓缩成的、AI可以直接消化吸收的结构化“饲料”。它让“教你如何引导AI”这件事，本身也变成了一个可以工程化、可复制的“引导工具”。
有网友感慨：它是The mother of all prompt injections