OpenAI 最近那篇关于 Harness Engineering 的文章，很容易被转述成一句耸动的话：“工程师不写代码了。”
但如果只读到这里，我们就被标题牵着鼻子走了。真正值得认真对待的，不是“代码是不是人写的”，而是软件工程的控制面正在上移：人类从直接实现功能，转向设计环境、规则、反馈回路与验收标准，让 agent 稳定地产生实现。
我更愿意用一句话概括它：
AI 时代最稀缺的，不再只是写代码的手，而是把判断力铸造成系统能力的脑。
先说结论：这不是“程序员消失”，而是“程序员产物变化”
按 OpenAI 官方文章的描述，他们做了一个相当极端的实验：
- 从空仓库起步
- 几乎不手写代码
- 用 Codex 生成应用逻辑、测试、CI、文档、可观测性与内部工具
- 五个月做到约一百万行代码
- 打开并合并约 1500 个 PR
- 产品已经进入真实用户使用
如果这些表述成立，那么它证明的并不是“AI 会写很多代码”——这件事早已不是新闻——而是另一件更重要的事：
当代码生成速度被极大提升后，真正的瓶颈不再是“写”，而是“检查、约束、验证与纠偏”。
换句话说，代码生产不再稀缺，人类注意力才稀缺。
真正的瓶颈转移：从 Code 变成 QA
这篇文章最锋利的地方在于，它没有停留在“生产力暴涨”的兴奋剂叙事里，而是指出了一个现实：
- agent 写代码很快
- 但人类 review、QA、验收没有同样线性增长
- 于是整个研发流程卡在“人类注意力不足”
这其实意味着，传统的软件流水线被倒过来了。
过去是：
人写代码 → 人测试 → 人修 bug → 人 review → 人上线
现在更像是：
人定义目标与约束 → agent 写代码 → agent 自测 → agent 自查 → agent 修复 → agent 提 PR → 人只在需要判断时介入
所以 OpenAI 那句“人类掌舵，智能体执行”，不是品牌广告语，而是新组织结构的摘要。
Harness Engineering 到底是什么
很多人会把它误解成“提示词工程升级版”。不是。
Harness Engineering 本质上是在做这件事：
把工程师脑中的经验、边界、规范、审美、验收逻辑与反馈机制，转译成 agent 可读取、可执行、可验证、可循环改进的工程系统。
也就是说，工程师的工作重点从“亲自完成任务”，转向“设计一个让系统自动完成任务并尽量做对的环境”。
这更接近控制论，不是脚本自动化。
脚本自动化处理的是确定流程；Harness Engineering 处理的是带有不确定性、上下文依赖和反复修正的软件开发。
文章里真正的革命，不是写代码，而是“闭环”
没有闭环，agent 只是更快地产生垃圾；有了闭环，agent 才可能成为工程执行体。
OpenAI 文中最值得抄作业的，其实是三种“感官”建设。
1. 让 agent 看得见 UI
他们把 Chrome DevTools 协议接入 agent 运行环境，让 agent 能：
- 看 DOM
- 截图
- 导航页面
- 输入、点击
- 复现 bug
- 验证修复是否生效
这一步的意义在于：agent 不再只是读源码，而是开始接触“运行后的产品行为”。
2. 让 agent 看得见系统内部状态
他们把日志、指标、trace 暴露给 agent。
于是 agent 可以像工程师一样：
- 查询日志
- 分析性能指标
- 观察调用链
- 判断问题是前端、后端还是基础设施导致
- 修改后再次验证
这让开发流程从“猜测式修复”变成“观测驱动修复”。
3. 让 agent 工作在可复现环境里
他们让每个任务有相对独立的工作树、独立应用实例和临时可观测堆栈。
这非常关键。没有隔离环境，agent 的尝试容易互相污染；有了隔离，agent 才能安全地不断试错、重放、修正。
所以，真正的升级不是模型更会补代码，而是工程系统终于能让 agent 形成 Observe → Modify → Verify → Repeat 的闭环。
“给地图，不要给 1000 页说明书”
这是全文里我最喜欢的一句经验。
很多团队上来就做两件事：
- 写一个超长 AGENTS.md，把所有规则都塞进去
- 把关键决策留在 Slack、飞书、Google Docs 或几位老工程师脑子里
结果往往是：
- 文档巨大，但 agent 找不到重点
- 上下文被说明书吞掉，真实任务反而信息不足
- 旧规则快速腐烂
- 团队以为“这不是常识吗”，但 agent 完全看不到
OpenAI 的做法更像真正的知识工程：
- AGENTS.md 只做入口与导航
- 深层信息放在结构化 docs 中
- 执行计划、技术债、设计决策全部版本化
- 用 lint 和 CI 检查知识是否过期、是否交叉引用、是否结构完整
- 甚至用 agent 做文档园艺
这一套背后只有一个朴素原则：
对 agent 来说，运行时访问不到的知识，等于不存在。
这句话值得每个做 AI 原生研发的人贴到墙上。
最值得深想的一点：把“品味”写成规则
过去高级工程师最有价值的部分，往往不是会写 for loop，而是那些微妙的判断：
- 文件不要太大
- 命名要统一
- 日志要结构化
- 边界必须校验，不能“猜数据”
- 依赖方向不能乱穿
- 尽量复用共享工具，别到处手搓小轮子
这些东西以往主要靠：
- review 评论
- 团队默契
- 老人带新人
- 口头传承
而文章中最有意思的概念，是 taste invariants —— 品味不变量。
也就是说，把这些“主观但稳定”的偏好翻译成：
- lint 规则
- 架构约束
- 结构测试
- 错误信息中的修复提示
- 后台持续清理任务
一旦完成编码，人类品味就不再只存在于某个 senior 的瞬时判断里，而是会持续作用于代码库每一处新生成的内容。
这意味着：
AI 时代高级工程师最有价值的能力，不是自己写得多快，而是能否把“什么叫好”固化成机器能强制执行的不变量。
为什么严格架构在 AI 时代更重要，而不是更不重要
文章里提到，他们强制每个业务域按固定层次组织，并严格限制依赖方向。
这对一些人类工程师来说，可能会显得有点“死板”。但对 agent 来说，这恰恰是效率倍增器。
人类可以在混沌中工作，靠经验和直觉弥补结构缺陷；agent 不行。agent 会快速复制已有模式，放大局部最优，也会稳定扩散坏味道。
所以 AI 时代一个很反直觉的结论是：
越是依赖 agent，高质量工程越需要更清晰的边界、更可验证的依赖关系，以及更机械可执行的约束系统。
不是更自由，而是更可控。
这篇文章其实在暗示：软件工程正在从“工匠模式”转向“工业控制模式”
传统意义上的优秀工程师，很像工匠：
- 亲自下手
- 局部精修
- 靠个人经验解决复杂问题
- 以代码质量体现价值
Harness Engineering 更像工业系统设计者：
- 设计生产线
- 定义质量门
- 搭建传感器和反馈系统
- 管理吞吐与漂移
- 建立持续“垃圾回收”机制
也就是说，软件团队的核心竞争力，正在从：
谁能写出最漂亮的实现
转向：
谁能设计出一个让 agent 持续写对的系统
这会重排很多能力的价值排序。
哪些能力会被放大，哪些会被稀释
被放大的能力
- 架构能力：定义边界、抽象和依赖方向
- 知识工程能力：把隐性知识写进仓库，让 agent 可发现
- 反馈系统设计能力：补齐 UI、日志、指标、trace 等观测面
- 验收与判断能力：定义完成标准，而不是只评价代码风格
- 系统治理能力：防止 agent 放大错误模式，持续回收技术债
被稀释的能力
- 重复性实现产能：常规 CRUD 的边际价值会持续下降
- 只存在于嘴上的经验：不写下来，就无法扩散给 agent
- 英雄主义式救火：高吞吐系统里，靠个人补锅不可扩展
当然，这篇文章也有明显的边界
如果不泼一点冷水，就会把它读成布道稿。
1. 这是高度特化环境，不可直接外推
OpenAI 自己也承认，这种能力严重依赖：
- 专门设计的仓库结构
- 丰富的内部工具
- 完整的可观测性
- 结构化文档体系
- 规则与检查器
- 后台清理机制
普通团队如果只模仿“让 agent 大量写代码”，却没有这些支撑结构，很可能收获的是更快的熵增。
2. “代码量很大”不是价值本身
在 AI 时代，代码量本来就越来越便宜。真正重要的是：
- 是否可维护
- 是否符合约束
- 是否便于未来 agent 接手
- 是否在持续积累不可控的技术债
所以“一百万行”更像系统吞吐的表现，不是成功本身。
3. 漂移问题并没有消失，只是被工程化管理
文章里提到，他们一度每周抽出相当可观的时间清理“AI 残渣”。这其实是很诚实的一句。
agent 的危险不只是第一次写错，而是会稳定复制并放大已有坏模式。解决方案不是指望模型自觉，而是建立持续扫描、重构、修剪的治理循环。
说白了：
agent 会制造熵，工程系统必须负责回收熵。
对普通团队最现实的启发
不是每个团队都能复制 OpenAI 那套环境，但几条原则几乎人人适用。
1. 把隐性知识搬进仓库
不要把关键规则藏在聊天记录、会议纪要和口口相传里。agent 看不到，就无法遵守。
2. 把审美变成检查器
能用 lint、test、CI、schema 验证的规则，就不要反复在 review 里口头批评。
3. 让应用可观测、可操作
如果 agent 只能看源码、不能看运行结果，它就只能猜。日志、指标、结构化错误信息，都是必要基础设施。
4. 缩短 PR 生命周期
AI 时代最怕超大 PR。更高吞吐意味着更需要小步迭代、快速验证、快速合并。
5. 建立“垃圾回收”机制
技术债不应该等季度治理。应当像内存回收一样，持续、自动、低摩擦地清理。
对个人开发者的含义：从剑客变成阵法师
如果把这篇文章压缩到个人实践层面，结论反而非常清楚：
未来个人开发者的优势，不再只是“我写得快”，而是：
- 我能把需求拆成 agent 可执行的任务
- 我能定义清楚验收标准
- 我能给 agent 足够的运行反馈
- 我能让错误不要反复出现
- 我能把自己的判断力沉淀成一套可复用工作流
高手不只是亲自出刀的人，更是能把局面布成自己优势的人。
最后的判断
我对 Harness Engineering 的最终看法是：
- 它是真的，不是噱头。 工程重心确实在上移。
- 它代表未来，但不会自动发生。 没有环境、规则和反馈，只有更快的混乱。
- 它会重写高级工程师的定义。 未来最值钱的，不是“最会手写代码的人”，而是“最会把判断力编码进系统的人”。
所以，真正值得记住的并不是“工程师不写代码了”。
而是：
软件工程正在从“我如何写出正确代码”，转向“我如何设计一个系统，让正确代码被持续地产生出来”。
这不是程序员退出舞台。
这是控制面上移。也是一种更高级的编程。
参考
- OpenAI, 工程技术：在智能体优先的世界中利用 Codex
https://openai.com/zh-Hans-CN/index/harness-engineering/ - X 帖子引用
https://x.com/odysseus0z/status/2030416758138634583