从写代码到设计代码生产系统：Ryan Lopopolo 的 Harness Engineering 给中文工程师的十条提醒
最近 OpenAI 有一个工程师叫 Ryan Lopopolo，他和团队做了一件挺刺激的事：从空仓库开始，五个月时间，没有人手写一行代码，全部用 Codex 生成了一个差不多一百万行规模的内部产品仓库。1500 个 PR，应用、测试、CI、文档、可观测性、内部工具，全是 agent 写的；他自己估计相当于人手写代码十分之一的时间成本。
这件事我先看到的是 OpenAI 官方博客的那篇《Harness engineering: leveraging Codex in an agent-first world》（2026 年 2 月 11 日），后来又听了 Latent Space 在 4 月 7 日对他的长访谈。看完之后我有一个明显的感觉：这不是又一个“AI 让程序员失业”的故事，而是一份关于“AI 时代工程师该怎么重新组织自己的生产系统”的实地报告。
下面这篇文章，我想用平时跟工程师朋友聊天的口吻，把 Ryan 这套观点拆给你看，再补一些我自己对中文工程师的具体建议。如果你已经在用 Cursor、Codex、Claude Code，但总觉得“提效不够丝滑”——这篇可能正好对上。
一、先把那句最容易被误读的话说清楚：humans steer, agents execute
Ryan 在文章里反复用一句话来描述这套实验：人类掌舵，agent 执行。 中文圈很多人看到这句话，第一反应是“那不就是 AI 干活、人当甲方吗”。
这个理解不对。
我把 Ryan 的真实意思翻译一下，应该是这样：工程师还在 loop 里，只是不再坐在 implementation layer，而是上移到 systems layer。 他还在做判断、还在定优先级、还在拍架构、还在守边界，只是不再把“在键盘上敲源代码”当成主要的产出形态。
为什么这一点重要？因为它直接决定了你怎么使用 AI。如果你把“humans steer”理解成“我提个需求然后等 AI 交活”，你大概率会很失望——因为 AI 不会自动知道你的业务、你的代码风格、你的部署环境、你不想踩的那些坑。Ryan 那个团队恰恰相反：他们花了大量时间，把这些“人脑里的东西”全部翻译成 agent 能读、能执行、能验证的系统组件。
所以这个故事的副标题，与其叫“无人工程”，不如叫“无人工手写源码”。人没有走，只是从打字员的位置，挪到了 tech lead、平台 owner、QA 系统设计者、组织记忆维护者这几个位置。
我的体会是：如果你想用 Ryan 这套方法的十分之一红利，先把“我作为人做什么”重新定义清楚。 你的产出不再是 diff，而是约束、反馈回路、文档、工具和可机械验证的验收标准。
二、Ryan 的起点：先给自己设一个看上去离谱的约束
Ryan 在访谈里讲了一个细节，我觉得特别值得抄作业。他给自己设的初始约束是：完全不写任何代码。
他的理由很冷静：如果 OpenAI 要把 agents 部署到企业里，那 agents 理论上就应该能做我自己能做的事；既然我和 coding harness 已经一起工作了大半年，那我就反过来设计自己的工作方式——唯一能完成工作的办法，就是让 agent 完成工作。
这个约束的妙处在哪里？妙在它封死了“我下次自己上手”这条退路。
很多人用 AI 编程之所以提不上去，就是因为退路太多。AI 写得不好怎么办？我自己改两行就行了。AI 找不到那个 bug 怎么办？我打个断点自己看一下。AI 不知道项目结构？我口头跟它解释一下。这些在单次任务里都很合理，但一旦你有这个退路，你就不会真的去补齐 agent 缺的那些系统能力。
Ryan 把这条退路砍掉之后，每一次 agent 出错都被迫升格成“环境缺陷”——不是 prompt 不够好，而是这个 repo 没有给 agent 配齐它该有的工具、上下文、文档和反馈通道。是缺一个 lint？缺一段 doc？缺一个 screenshot script？缺一个 CLI wrapper？缺一个 typed SDK？缺一个 trace 入口？还是 PR 的生命周期没有 agent 化？
他把这种工作起名叫 harness engineering——驾驭工程。它的对象不是 prompt，不是模型，是整个软件生产环境。
中文工程师可以怎么用：你不需要真的禁止自己写代码，但可以试一个更弱的版本——这一周，凡是 agent 能做的事，我就不自己做；它做不好的，我不直接动手改代码，先去补一条规则、一段文档或一个工具。 一个礼拜下来，你就知道你的 repo 离 agent-first 还差多远。
三、模型可以并行，token 可以扩，人类注意力才是真正的瓶颈
Ryan 在访谈里反复讲一件事：模型 trivially parallelizable，你愿意花 GPU 和 token，就能让一群 agent 同时干活；真正稀缺的是团队白天能同步投入的那点注意力。
这句话的含义比表面更深。
过去做软件工程，稀缺资源是工程师的写代码时间和 review 代码时间。所以我们的所有流程默认：每个 PR 都要认真看，每个改动都要严格阻塞，每个 merge gate 都要尽量保守。 这套流程在人是瓶颈的时候没毛病。
可一旦 agent 把代码产能拉到人类 review 容量的十倍，这套流程就会瞬间反过来变成最大的瓶颈。Ryan 团队后来被迫调整了 merge philosophy：PR 的寿命变短，阻塞性的 gate 减少，flaky test 有时先合后修。OpenAI 那篇文章里有一句很实在的话：这种选择放在低吞吐环境里就是不负责任，但放在高吞吐环境里常常是正确取舍。
注意，他不是在劝大家放弃 review。他真正在说的是：当人类 review 变成瓶颈，质量控制就必须前移、机械化、agent 化。 人不应该再花大量时间逐行检查代码，而是要把过去常见的 review 意见，转成 lint、structural test、文档规则、review agent、验收脚本。这样人类的判断只需要被捕捉一次，就能在所有未来 agent 生成的代码上持续生效。
我自己在带团队和做开源时一个反复验证过的判断是：判断什么是“高级工程师”的最简单标准，是看他每次解决一个问题时，是只解决这一次，还是顺手让这一类问题再也不会出现。 Ryan 这套就是把这个标准放大到 agent 时代——agent 一犯错，你的第一反应不是骂它，而是问自己“以后怎么让这种错更难发生”。
中文工程师可以怎么用：每次你在 Cursor 或 Codex 里反复跟 AI 说“别那么写”、“那个目录不要碰”、“这个字段叫 xxx 不是 yyy”——都是一次提示。凡是你说过两次以上的话，都应该写进 AGENTS.md 或者一条 lint。
四、AGENTS.md 不是百科全书，而是一张目录页
Ryan 文章里我觉得最实操、最容易抄的一条经验是：给 Codex 一张地图，而不是一千页说明书。
他们最早试过那种“什么都往里塞”的巨型 AGENTS.md，结果如你所料：上下文被挤占、所有规则都“重要”等于没有规则、文件很快腐烂、而且没法机械验证。后来他们把 AGENTS.md 砍到大约一百行，定位从“百科全书”降级为“目录”——一个稳定入口，指向 repo 内更深的 source of truth。
真正的知识被搬到结构化的 docs/ 目录里：design docs、execution plans、product specs、references、quality score、reliability、security 等等。计划被当成一等公民——复杂工作有 execution plan，active plans、completed plans、tech debt 都跟代码一起 versioned。
我特别想强调他这套做法背后的一个底层原则：从 agent 的视角看，运行时拿不到的知识就等于不存在。
这条原则一旦你接受了，它会改变你对很多东西的态度。
Slack 上某次架构讨论达成的一致——agent 看不到，等于不存在。Google Doc 里那份 design doc——agent 没把它拉进 context，等于不存在。某位大佬脑子里“我们这里就是这么干的”的 tacit knowledge——只要他没把它写进 repo，等于不存在。code review 留下的那条意见——只要没沉淀成规则，下次另一个 PR 还会犯同样错误。
Ryan 团队为了保证这些文档真的有用，还做了两件事很值得学：
第一，用专门的 lint 和 CI 检查文档的健康度——是否最新、是否交叉链接、结构是否符合规范。
第二，有一个常驻的 doc-gardening agent——定期扫描“文档说的”和“代码做的”是否一致，发现偏差直接开 PR 修。
中文工程师可以怎么用：从今天起，别再写那种动辄几千行的 AGENTS.md。把它砍成 100 行的索引：项目目录怎么走、关键约束在哪、找架构文档去哪、找质量规则去哪、找运行命令去哪、找 owner 去哪。剩下的内容拆到 docs/ 里，每个文件单独管一件事。
五、Agent legibility：代码不是只写给同事看，也要写给模型看
Ryan 提了一个我很喜欢的概念，叫 agent legibility——“对 agent 的可读性”。
他说，因为他们的仓库完全由 agent 生成，所以首要优化目标已经从“对新员工友好”，变成了“对 Codex 可读”。这听起来挺极端，但他的态度其实很微妙：代码不一定要符合人类的所有审美偏好，但只要它正确、可维护、对未来 agent runs 可读，就达标了。
换句话说，human taste 没有消失，只是被重新定义了：从“我喜欢这个实现长什么样”，变成了“这个实现是否可验证、可维护、可被 agent 稳定理解和复用”。
这个观念会反过来影响你的技术选型。OpenAI 文章说，他们偏好那些 agent 能完整 internalize 的依赖和抽象。传统上被称为“无聊”的技术——组合性强、API 稳定、训练集中出现得多——反而更容易被 agent 建模。文章举了个例子：他们没有引入一个通用的 p-limit 风格并发包，而是自己写了一个 helper，跟 OpenTelemetry 集成得好、测试覆盖完整、运行时行为可预期。
Ryan 在访谈里把这个逻辑往前推了一步——内部化依赖。他说，一个几千行的小依赖，可能可以让 agent 一个下午重写一遍，只保留你真正需要的部分；这样以后做安全审查、修 bug、做适配时，Codex 能直接深入修改，而不必等 upstream patch、发布、升级。
但他也老实承认：内部化依赖意味着你回到零，需要重新建立信心和测试。这不是免费的。
我的解读是这样：当代码本身的生成成本下降，软件的价值就从“代码资产”转向“可验证的系统形状”。 以前我们倾向于复用第三方库，是因为重写很贵；Ryan 这套世界里，重写的边际成本下降了，但验证、可观测、边界、安全的成本仍然很贵。所以“用不用第三方库”这个决策，不再只是“不要重复造轮子”，而是要问：这个轮子对 agent 是不是透明？我能不能用我自己的 harness 去约束、测试、审查、修复它？
六、让 agent 能看见应用：UI、日志、指标、trace 都要变成可操作反馈
Ryan 团队后来吞代码量上去之后，很快撞到下一个瓶颈：人类 QA 跟不上。
他们的解法不是雇更多 QA，而是让 agent 自己能 QA。具体做了几件事：
- 应用支持按 git worktree 启动，每个 change 都能对应一个隔离的实例。
- 把 Chrome DevTools Protocol 接入 agent runtime，给 Codex 写处理 DOM snapshot、screenshot、navigation 的 skill，让它自己去复现 bug、验证修复、推理 UI 行为。
- 每个 worktree 配一个隔离的 observability stack，Codex 可以查 logs、metrics、traces，会用 LogQL、PromQL。
这一套搭起来之后，“确保服务启动低于 800ms”、“这四条关键用户路径里没有 span 超过两秒”——这种 prompt 才真正变得可执行。
Ryan 在访谈里讲了一个我觉得很有代表性的例子：他们让 Codex author Grafana dashboard 的 JSON，然后发布 dashboard；Codex 也响应 page。因为 dashboard、alert、log、code 都被 collate 在一起，告警发生时 agent 能知道是哪个 alert 被哪条 log 触发的；如果某个 outage 没有 page，它还可以根据已有 dashboard 找到观测缺口并修复。
这就是“agent-first 可观测性”的真正含义：可观测性不是给人类 on-call 看图用的，而是给 agent 闭环修复用的。
他还说了一个反直觉的观察：他们工程师有人花了一个下午做了个漂亮的 trace visualization 工具，结果后来发现，直接把 trace tarball 丢给 Codex 让它分析修复，反而更符合 agent-first 的路线。 因为最终修代码的是 Codex，而不是人类盯着图看完再去改。
中文工程师可以怎么用：下次你在 chat 里给 AI 贴日志、贴报错、贴截图——都是一次信号。这意味着这条反馈路径还没进 agent 的工具链。 与其每次手动复制粘贴，不如花半小时给 agent 写一个能直接拉日志、跑测试、截图、读 trace 的小工具。
七、不要 micromanage 实现，要机械化边界
Ryan 还有一条很硬核的观点：文档本身不足以让一个完全 agent-generated 的 codebase 保持一致。 你不能只跟 agent 说“请写得优雅”，也别指望它自然遵守团队的 tacit taste。那些不可妥协的架构边界和 invariant，必须机械化。
OpenAI 那篇文章里讲了他们怎么做的：把业务 domain 切成固定层级，用 custom lint 和 structural test 强制依赖方向。大致是 Types → Config → Repo → Service → Runtime → UI，横切关注点通过 Provider 这种显式接口进入，其他边一律禁止。
但 Ryan 的关键判断是：约束 invariant，不要 micromanage implementation。 比如他们要求 Codex 在边界上解析数据形状，但不指定一定要用某个库。这样 agent 既能快速出货，又不会破坏地基。
这种“七人团队做五百人公司架构”的做法，初看显得过度。Ryan 在访谈里直接回应过这个质疑：他们的仓库有差不多 500 个 NPM packages，按普通七人团队标准是过度分解；但如果每个工程师实际上在驱动 10 到 50 个 agent，那这就更像一个 350 人的团队了。深度 decomposition、sharding、清晰接口边界，这些“大公司病”的产物在 agent-first 团队里反而是必需品。
这里其实藏着一个对小团队特别有指导意义的判断：agent-first 团队的人数不能按 head count 计算，要按并发执行单元计算。 七个人加几十个 agent，已经是几百人协作的规模问题；命名、边界、依赖、复用、日志、测试、文档、ownership，必须提前结构化。
中文工程师可以怎么用：如果你已经开始让一个人挂 5–10 个 agent 干活，赶紧把你那种“小团队就别搞这些虚的”的心态收回去。你已经是大团队了，只是 head count 没涨。
八、PR review 的未来：从逐行审查转向“可信任的证据包”
Ryan 对 review 的看法在中文圈应该会有点争议。他在 OpenAI 文章里说：人类可以 review PR，但不总是必须；随时间推移，他们把几乎所有 review 努力推向 agent-to-agent。访谈里他更直白：大部分 human review 已经是 post-merge。
听到这里你可能本能不舒服，但他自己也明确补了一句限定：他们做的是 native application，不是连续部署的高可靠基础设施；发布分支和分发前 smoke test，仍然有人类批准。
所以 Ryan 真正想说的不是“取消 review”，而是审查对象和信任机制要变。
他在访谈里有一句话我很喜欢：他希望 coding agent 在 PR 上附一个视频，展示功能在真实产品里能跑起来。 这相当于把 agent 完整的工作轨迹压缩成一个 reviewer 可读的“信任包”。
这个类比特别精准：人类同事提 PR 时，我们不会要求他屏幕录制整个写代码过程；我们只要他给出足够证据，让我们相信代码可以 merge。 Ryan 把 agent 也当 teammate 看：不要 shoulder-surf 它每个动作，而要让它产出 reviewer 需要的压缩证据。
证据可以是什么？——单元测试、E2E 测试、trace、video walkthrough、log 摘要、review agent 给出的结论、CI 状态、structural check 结果、quality score、tech debt 更新。人类 review 的价值，就从“逐行检查生成物”，转向了“检查验证体系是否覆盖了风险”。
中文工程师可以怎么用：下次你提 PR 给 AI 写的代码做 review 时，不要再老老实实一行行看。问自己：这个变更动了什么风险面？这些风险有没有被自动化覆盖？如果没有，第一件事是补覆盖，而不是用人眼去当 lint。
九、错误不是一次性修补，而是进入“垃圾回收”系统
Ryan 很清楚完全 agent autonomy 会带来新问题。OpenAI 文章里提过：Codex 会复制 repo 里已有的模式，包括不均匀或次优的模式；时间一长会 drift。他们最早每周五花 20% 时间清理“AI slop”，但很快发现这种打地鼠模式不可扩展。
后来他们做了两件事：
第一，把 golden principles 编码进仓库——这些是有观点的机械规则，目标是维持代码对未来 agent runs 的可读性和一致性。比如偏好 shared utility package、不允许 YOLO 猜数据形状、网络调用必须有 timeout 等等。
第二，建立 recurring cleanup process——后台 Codex 任务定期扫偏差、更新 quality score、开 targeted refactoring PR；很多可以 review 一分钟之内就 automerge。
Ryan 把这事叫 garbage collection。我觉得这个比喻特别到位——技术债像高利贷，最好持续小额偿还，而不是让它复利增长到痛苦爆发。
这个概念之所以重要，是因为它把“AI slop”从一个道德议题变成了一个工程对象。Ryan 不否认 slop 存在，他说的是：如果 agent 会复制坏模式，那就要设计持续回收坏模式的系统。所谓 human taste，不是每次人类出来骂一句“这个写得丑”，而是把 taste 捕捉成原则、lint、review prompt、quality score 和后台清理任务。
这一点，跟 Mitchell Hashimoto 在 2026 年 2 月那篇《Engineer the Harness》里讲的几乎是一回事——发现 agent 犯错，就工程化一个解决方案让它以后别再犯。Ryan 这边是在更大规模上展示了它怎么变成一个团队系统。
十、Symphony：让 issue tracker 成为 agent 的 control plane
Ryan 最近还有一项工作值得单独拿出来讲，叫 Symphony。OpenAI 在 2026 年 4 月 27 日发布了 Symphony 文章，虽然不是 Ryan 单独署名，但它直接继承了 harness engineering 实验：团队在“无人手写代码”的工作流里继续撞墙，下一个瓶颈是 context switching。
Ryan 在访谈里说，到了 GPT-5.2 之后，每个工程师每天能稳定推 5–10 个 PR；但代价是不断在 tmux pane 之间切换，人开始疯。同时管理 3–5 个 Codex session 就开始痛苦：忘记哪个 session 在做什么、agent 卡了你不知道、复杂的长任务总是要回头检查。
Symphony 的核心设计很 elegant：不要直接监督 agent，让 agent 从任务系统里拉活。 Linear 上的每个 open task 对应一个 agent workspace；Linear 的状态本身变成了一台状态机；agent crash 或 stall 了，Symphony 自动重启；新 work 出现，Symphony 自动拾取；复杂任务可以让 agent 先分析 codebase + Slack + Notion 产出 implementation plan，再把 plan 拆成任务 DAG，未阻塞的任务自然并行。
OpenAI 文章给了一个数字：有些团队上 Symphony 三周后 landed PRs 增加了 500%。 但更深层的变化是：每个 change 的感知成本下降了。人不再亲自驱动实现，所以 speculative task 变得便宜——试一个想法、探索一个 refactor、测试一个假设，不行就丢掉。产品经理和设计师甚至可以直接向 Symphony 提 feature request，拿回一个包含真实产品视频 walkthrough 的 review packet。
Ryan 在访谈里特别提了一个 Symphony 的 rework state 设计，我觉得非常符合 agent-first 思维：如果 PR 不可 merge，就把 worktree 和 PR 整个丢掉，从头再来。然后追问“它为什么是垃圾”——先修 prompt、skill 或 guardrail，再把 ticket 重新推入 progress。
这背后是一个非常不一样的成本观：当代码便宜时，保留错误路径不一定值得。 有时丢弃、补护栏、重跑，反而比 patch 干净。这种思路在传统工程师脑子里很难一下接受，但在 token 便宜、模型够强的世界里，是合理的。
十一、不要把 agent 关进过度僵硬的盒子，要给它目标、上下文和工具
Ryan 还有一个我觉得很重要的演进判断：早期的 agent 适合放在预定义 scaffold 或状态机里；但 reasoning model 一旦变强，过度僵硬的 scaffold 反而会限制它。
他们后来“反转”了系统：不是先搭一个环境再把 coding agent spawn 进去，而是让 Codex 本身成为入口，再通过 skill 和 script 给 Codex 启动 stack、设置环境变量、查询 observability 数据的能力。
在 Symphony 那边，他们也意识到把 agent 当成状态机里的 rigid node 效果不好——模型变聪明后，能解决的问题比你试图塞给它的 box 更大。早期只让 Codex implement task 太限制；后来给它 gh CLI、读 CI logs 的 skill，让它去关掉旧 PR、拉报告、做更多事情。最终他们更倾向于给 agent 一个 objective，而不是一串严格的 transition。
但他立刻又补了一句关键限定：给它 context 和 tools。 也就是说，box 不是没有，box 变成了整个 harness：权限、工具、repo 结构、workflow policy、observability、CI、lint、skill、sandbox、human escalation——共同构成一个可操作的环境。
我看到很多团队失败的 agent workflow，都掉在两个极端里：要么把 agent 关进过窄的工具箱，期待它 magically 完成复杂任务；要么给它完全开放的环境，却没有日志、测试、边界和 policy。 Ryan 的中间道路非常清晰——不要 micromanage 每一步，但要严肃设计 agent 可见的世界。给目标，也给观测；给自由，也给 invariant；给工具，也给反馈；给上下文，也给可机械执行的验收标准。
十二、文本是 agent 的血液：把经验、失败、评论、日志都“吸回仓库”
Ryan 在访谈里有句话我觉得特别准：模型 fundamentally crave text。
他们做的很多事，本质上都是在把文本注入这个系统让 agent 能用。比如某次缺 timeout 导致 page，他们直接在 Slack 里 @ Codex，让它不光是给那个调用加 timeout，还要更新 reliability documentation，把“所有网络调用都必须有 timeout”写进规则。这样团队不只是修了一个点，而是把“什么是好”持久编码进流程知识。
他们还做了一件挺有意思的事：对 session log 做 skill distillation。Codex 自己的 session log 收集到 blob storage，每天跑 agent loop 分析“团队哪里做得不够好”，再把结论反馈回 repo。PR comment、failed build——所有这些都是信号，代表某个时刻 agent 缺上下文；这些信号要被吸收，然后塞回 repo。
这件事让 harness engineering 有了一种自改进的味道。它不是一次性配置，而是持续学习系统——agent 失败 → 失败变成文本信号 → 文本信号被分析 → 规则、skill、文档、工具更新 → 未来 agent 更少失败。这个循环越顺畅，团队的经验复利越强。
Ryan 还说了一个我觉得很反共识但其实很对的观察：改 agent behavior 比改 human driver behavior 便宜得多。 团队里每个人都去养成新习惯很难；但你把新习惯写进 shared skill、lint、workflow prompt 或 CI，所有 agent 立即继承，所有人间接受益。
十三、CLI-first 与 token 效率：给 agent 的工具，要少废话、结构化、只吐失败信息
Ryan 对工具输出格式有非常具体的偏好：CLI 对 agent 友好，因为 token efficient，而且容易被改造得更 token efficient。
他举了个例子：构建输出常常是一大墙文本；过去 dev productivity team 会写工具把真正异常抽出来放到顶部。给 agent 的 CLI 也应该这样——格式化命令不必输出每个已格式化文件，agent 只要知道 formatted or not；测试输出尽量只吐失败部分。
听起来是小优化，但在 agent-first 系统里是大事。人读日志可以扫一眼跳过；LLM 处理日志时，无关 token 会占 context、干扰注意力、增加成本，还可能触发错误推理。 好的 agent tooling 应该把输出压缩成“下一步行动所需信息”。
他还提了一个相关的细节：让非文本的事物也尽量适配文本形态。讨论 agent 怎么“看” UI 时他说，agent 不是像人一样用视觉感知 layout 的——有时候 rasterize 图像 + OCR、或者把 DOM/截图/导航事件一起喂进去，模型才能更好地理解它在操作什么。
我把这点单独拎出来，是因为它给所有做工具的人指了一个明确方向：未来的软件工具不只要 human-readable，也要 agent-readable。 日志、CLI、错误消息、lint message、dashboard、trace、PR comment、issue description——都应该考虑一个问题：模型看到这一段输出后，能不能直接做出正确的下一步？
这可能是 Ryan 整套观点里最容易被低估的一点：agent-first 不只是“使用 agent 写软件”，还意味着整个软件生态的接口都要为 agent 优化。
十四、Ghost Libraries：当代码便宜时，软件可以以 spec 的形式分发
Ryan 在访谈里还谈到一个挺未来感的概念：Ghost Libraries。
Symphony 的开源形式很特别，它不是先给一个完整实现，而是先给一个高保真的 spec，让 coding agent 可以在本地重新组装出来。OpenAI 那篇 Symphony 文章里说，仓库第一眼看到的是一个 SPEC.md，定义问题和预期解法，而不是只给一个复杂的监督系统。
Ryan 描述他们提取 spec 的过程也挺有意思：从内部 proprietary repo 里抽 scaffolding，开新仓库，让 Codex 参考原 repo 写 spec；再让一个断开的 Codex 实现 spec；再让另一个 Codex 比较实现与 upstream，更新 spec 让它更少偏离；如此循环，直到 spec 能高保真地复现系统。
这是一种非常不同的软件分发观。过去我们分发软件，主要分发 source code、binary、library、API。Ryan 设想里，如果 agent 足够会写代码，spec 本身就可能成为软件资产——它描述问题、边界、流程、接口、状态机、成功标准和非目标，由本地 agent 根据具体环境生成实现。
OpenAI 的 Symphony spec 就强调：它是 scheduler / runner 和 tracker reader，ticket 写入通常由 coding agent 在 workflow runtime 里完成；它不强制单一 sandbox 或 approval policy，而要求实现者明确自己的 trust and safety posture。
这有两个我觉得很值得想一想的后果：
第一，软件变得更 adaptable。 spec 可以让 Jira、Bitbucket、Linear、GitHub 等不同环境替换具体集成，只保留更柏拉图式的抽象。
第二，工程里“实现细节”的价值在下降，“可复现的高质量规格”的价值在上升。 如果 agent 能从 spec 生成不错的实现，那么真正稀缺的是：问题定义是否准确？边界是否清晰？验收标准是否可执行？安全姿态是否明确？观测是否足够？——这又回到 Ryan 的主线：工程师的价值从写代码转向设计可执行环境。
十五、Ryan 也承认限制：hard + new、复杂重构、长期一致性，仍然要人
Ryan 的观点激进，但他不盲目。OpenAI 那篇文章在结尾很坦诚地说：他们也不知道完全 agent-generated 系统的架构一致性多年后会怎么演化；也还在学人类判断在哪里最有杠杆、怎么把判断编码进去。文章的结论不是“软件工程不需要纪律了”，而是纪律更多体现在 scaffolding 上，而不是代码本身——工具、抽象、反馈回路对维持代码库一致性越来越重要。
访谈里 Ryan 把任务分了象限。他认为 hard and new 的问题仍然需要人类驱动；其他象限在合适 scaffold + drive-to-completion 的系统下，已经大体可解。人类有限的注意力，应该放在 hardest stuff——纯白纸的问题，或者最深的 refactoring——因为这些地方的接口形状还不清楚，正是人类判断最有价值的地方。
他还提到，当前模型对某些“从零到一”的产品想法和最复杂的重构，仍然需要同步互动。原因是：如果你脑子里的东西没进到模型 context 里，模型也不知道；white space 项目常常要在 agent trajectory 中才显露出缺失信息，需要 harness 或 scaffold 把这些非功能要求、模板和框架偏好提取出来。
我觉得这里的边界感非常重要。Ryan 不是要把人完全移走，他是把人放到更难、更新、更高杠杆的问题上。
按这条思路反过来看普通工程师：routine implementation、QA smoke、CI 修复、merge queue、文档 gardening、技术债清理、dashboard 定义、review comment 处理——这些都该逐渐交给 agent；目标选择、架构方向、产品 taste、风险边界、复杂拆解、组织约束——这些仍然需要人类强参与。
十六、给中文工程师的五条可操作建议
这套实验直接照搬到普通团队风险很大。它发生在 OpenAI，token / 模型 / Codex 资源、团队能力、greenfield 条件、产品类型、风险承受能力都很特殊。Ryan 自己也承认不该泛化成“所有场景都适用的脚本”。
但你不需要复制极端形式，只需要复制工程原则。 我把它翻成五条可以这周就开始做的建议：
第一条，每次 agent 犯错，都问“如何让这个错误以后更难发生”。 答案可能是一条 AGENTS.md 入口、一条 docs 规则、一个测试、一个 screenshot script、一段 lint、一个 CLI wrapper、一个 issue template、一个 PR checklist、一个 eval harness，或者一个 recurring cleanup agent。不要原地修了就走。
第二条，把不可见的知识变成 repo-local 的知识。 只在你脑子里的约定，对 agent 不存在；只在聊天记录里的架构决策，对未来 agent 不存在；只在某次 review comment 里的判断，没被吸收成规则就不会复利。把隐性经验逼成可版本化、可链接、可验证的文本和工具。
第三条，把验证权尽量交给 agent 能调用的工具。 如果 agent 能自己跑应用、看 UI、查 log、看 trace、生成视频、重跑 CI、处理 review comment，它就能端到端完成更大任务。没有这些工具，再强的模型也会反复问人、反复猜、反复产生不可验证输出。
第四条，把 human taste 编码成边界，而不是审美抱怨。 人类有品味没问题，但在 agent-first 系统里，品味必须落成 invariant：结构化日志、schema 命名、文件大小、依赖方向、数据边界解析、可靠性要求、测试质量、文档新鲜度。否则你就会一辈子在 review 里重复那句“我们这里不这样写”。
第五条，不要 babysit agent，而是设计它不需要 babysit。 你未必要上 Symphony，但可以从最小版本开始：为每类任务准备清晰的 issue、验收标准、运行命令、测试脚本、失败输出摘要、重跑规则。让 agent 自己跑、失败、重启、提交、附证据、必要时升级给人。
结语：把判断变成系统，是 AI 时代工程师的真正护城河
Ryan Lopopolo 这套观点真正预示的，不是程序员马上失业，也不是代码不再重要，而是软件工程的重心在移动。代码越来越容易生成，真正稀缺的是：目标定义、环境设计、反馈回路、架构边界、验证机制、组织知识、风险判断。人类工程师仍然重要，但重要的方式变了。
在这个范式里，优秀工程师不是亲自写最多代码的人，而是能让一群 agent 稳定产出高质量代码的人；不是每次都能救火的人，而是能把火灾模式变成传感器、护栏和自动修复的人；不是拥有最多隐性经验的人，而是能把隐性经验转化为 repo-local、agent-legible、mechanically enforced 系统的人。
Ryan 自己在文章最后说得很谨慎——他们最困难的挑战已经集中在 designing environments、feedback loops 和 control systems 上，以帮助 agent 大规模构建和维护复杂可靠软件。也就是说：未来的软件工程纪律没有消失，只是从代码文本本身，转移到了代码产生、验证、合并、修复和演化的系统。
如果让我用一句话总结 Ryan 的 Harness Engineering 观给中文工程师的启示，我会这样写：
AI 时代的软件工程，不是让模型替你写代码，而是把你的工程判断、团队规范、产品品味和质量标准，变成一群 agent 可以持续执行的生产系统。
懂这件事的人，未来十年会越走越轻。不懂的人，会发现自己在跟一个永远写不完代码的 AI 比手速——这比赛你赢不了，也不该参加。