软件世界的自动化实验室：AI Coding 前沿实践综述

同一份能力，两种劳动力

设想两家公司，买的是同一个模型，用的是同一种编程智能体，接到的需求复杂度也差不多。

第一家公司里，智能体开工的前半小时花在安装依赖上，装完才发现文档里写的启动命令早已过期。它在三个长得很像的模块中挑错了一个，写出一段语法与类型都无可挑剔、业务含义却不对的代码。单元测试全绿，页面打不开。人类工程师接手，又用了两个小时才弄清楚它到底改了些什么。

第二家公司里，智能体进入仓库就拿到一张简洁的导航：产品约束在哪里，架构边界画在哪里，验证用什么命令。它在隔离环境中启动应用，复现问题，改代码，跑类型检查、单元测试和端到端测试，最后操作浏览器录下一段修复前后的对比演示。另一个独立的审查智能体检查它的改动，人只需要判断产品结果对不对。

两家公司拿到的模型能力几乎相同，得到的却像是两种不同水平的劳动力。

这种落差在计算机科学里其实不算新鲜事。一个排序算法的渐进复杂度写在教科书上是固定的，可它在真实机器上跑多快，还要看缓存有多大、磁盘有多慢、数据以什么顺序到达。算法本身只描述了一半，另一半藏在它所运行的那台机器里。今天的 coding agent 也一样：模型是算法，代码库、工具链、测试与权限边界共同构成了它运行的那台机器。

于是 AI Coding 的前沿问题悄悄换了主语。它不再只是“模型能不能写出一段代码”，而是：一个软件组织能不能把模糊的意图变成机器可以理解的任务，把工程知识变成机器可以访问的上下文，把质量要求变成机器可以读取的反馈，并把自主执行约束在可以观察、恢复和追责的边界之内。

截至 2026 年中，OpenAI、Anthropic、Cursor、GitHub 和 Cognition 等组织已经公开了各自使用或设计 coding agent 的方法。它们用着不同的模型、不同的产品形态和不同的术语，却在若干关键问题上出现了明显趋同：代码库需要对智能体“可读”，任务必须具有可验证的完成定义，运行环境要能被智能体直接操作，长任务必须增量推进，生成与评估需要适度分离，重复犯下的错误应当沉淀为测试、规则和工具。

本文不做产品横评，也不把企业自述当成普遍事实。它想回答一个更基础的问题：这些看似分散的最佳实践，为什么会同时出现？

答案可以压缩成一句话：软件工程正在从代码生产活动，转变为一种围绕反馈回路组织的实验活动。Coding agent 的真正优势，不只来自生成速度，而来自软件世界特有的“可验证性红利”——编译器、测试、运行时、日志、浏览器、Git 和 CI/CD，共同构成了一间高速、廉价、可重复的自动化实验室。

理解了这一点，也就能理解 AI Coding 与 AI for Science 的关系。它们面对的是同一种闭环：提出方案、执行实验、读取反馈、修正方案。软件之所以暂时走得更快，不是因为写代码天然比科学研究简单，而是因为软件实验通常更快、更便宜，并且拥有更清楚的评价信号。AI Coding 因而不只是一个开发工具市场，也可能是人类第一次大规模学习如何组织自主认知劳动的试验场。

环境这一半：为什么同一个模型会判若两人

过去讨论 AI 编程，最容易比较的是模型。

一个模型能通过多少编程题，能解决多少 GitHub issue，能否在长上下文中理解几十万行代码，往往决定了它在发布会和排行榜上的位置。这些指标当然重要。如果模型不会推理、不会使用工具、不能稳定修改多个文件，再好的工程流程也无从谈起。

但当模型能力跨过基本可用的门槛之后，一个新现象越来越明显：模型之间的差距固然存在，同一个模型在不同环境中的差距有时更大。

这并不神秘。一个新工程师加入团队时，产出不只取决于他的智力，还取决于一连串环境条件：电脑能不能顺利启动项目，文档是否可信，代码结构是否清楚，需求表达是否完整，测试能不能发现错误，负责人能不能及时给出反馈，出了问题能不能安全回滚。我们不会因为招到一名聪明的工程师，就认为这些条件不再重要。恰恰相反，工程师越有能力，一个糟糕环境浪费掉的潜力就越大。

Coding agent 也是如此，只是这种依赖更极端。

人可以在走廊里追问同事，可以从组织历史和对话语气中推断隐含要求，可以在发现文档过期时凭经验绕过去。智能体能看到什么，主要取决于当前上下文、仓库内容和被允许调用的工具。一个关键决策如果只存在于某次会议中，对智能体来说就等于不存在。一个检查如果只能靠资深工程师“看一眼就知道不对”，智能体便很难把它纳入稳定的自我修正。

所以，AI Coding 的研究对象正在发生位移。早期的问题是“模型能不能写代码”，现在更要紧的问题是“一个软件组织怎样把自身改造成适合智能体可靠工作的环境”。

有意思的是，五家组织给这件事起了五个不同的名字。OpenAI 称之为 harness engineering——harness 原意是马具、线束或试验支架，它不直接提供动力，却负责把动力导向一个可控制的方向。Anthropic 更常从 long-running agent harness、上下文接力和生成—评估架构来描述。Cursor 把问题拆成 Rules、Skills、Plan、worktree 和 review。GitHub 从高质量 Issue、验收标准和预配置环境切入。Cognition 则把它类比为新员工入职：先准备电脑，再提供组织知识和可复用的 Playbook。

术语不同，问题结构相同。

补全、对话、智能体、长任务：变的其实是反馈结构

AI Coding 大致经历了四个阶段。

第一阶段是补全。模型根据光标附近的代码预测下一行或下一个函数。人掌握任务、上下文和验证，AI 只降低输入成本。

第二阶段是对话。人把错误信息和相关文件交给模型，模型解释、建议或生成补丁。AI 开始参与推理，但工具调用和结果验证仍主要由人完成。

第三阶段是智能体。模型可以搜索代码库、编辑文件、运行命令、读取测试结果，并在失败后继续修改。此时它不再只是回答问题，而是在一个环境中采取行动。

第四阶段是长时间与并行执行。多个智能体可以在隔离环境中分别处理任务，持续数小时，提交 Pull Request，接受自动审查，修复 CI，甚至操作真实应用来证明结果。

从第一阶段走到第四阶段，最显眼的变化看起来是自主性，实际上是反馈结构。

补全工具没有能力读取自己造成的后果。它生成一段代码，正确与否由人判断。智能体则可以运行这段代码，读取报错，再尝试新的方案。一旦这个循环建立起来，模型就从一次性生成器，变成了一个搜索过程中的一环：

目标与约束
  → 生成候选改动
  → 在真实环境中执行
  → 获取测试、运行和用户证据
  → 判断偏差
  → 修改下一轮方案

把它看成搜索，就能立刻看出这个循环的脆弱之处。搜索的效率不取决于你走了多少步，而取决于每一步能排除掉多大一片错误空间。如果反馈信号不完整，智能体可能只是更快地重复错误；如果测试可以被它自己修改，它甚至可能通过削弱测试来“完成”任务；如果上下文不断堆积，后面几轮可能已经忘了最初的目标。真正有用的循环，不是重复次数多，而是每一轮都获得了足以排除错误方向的新信息。

这就是为什么前沿实践如此看重测试、日志、浏览器、进度文件和独立评估。它们不是外围设施，而是决定智能体能否从行动中学习的感觉器官。

一个乘法公式：模型之外的四个乘数

为了比较不同组织的实践，可以先立一个粗糙但好用的模型：

Agent 工程能力 ≈ 模型能力 × 仓库可读性 × 工具可达性 × 反馈质量 × 自主权治理

这里用乘法而不是加法，是因为其中任何一项严重缺失，整体能力都会被显著压制。一个短板不是扣分，而是打折。

模型能力决定智能体能否理解问题、规划步骤和生成合理方案。这是基础，却不是全部。

仓库可读性决定它能否找到正确的知识。目录是否清楚，架构边界是否明确，关键决策有没有版本化记录，是否存在可信的典型实现，都会影响模型实际拿到的上下文。

工具可达性决定它能否把推理变成行动。能不能安装依赖、启动服务、查询数据库、操作浏览器、查看日志和指标，决定了智能体是在纸上分析，还是真的进入了生产过程。

反馈质量决定它能否分辨好坏。编译成功只说明语法和类型可能正确；单元测试通过说明部分行为符合预期；端到端测试、截图、性能指标和用户验收分别覆盖更高层次的真实结果。反馈越接近最终目标，“局部正确、整体错误”的生存空间就越小。

自主权治理决定失败的代价。文件系统、网络、凭据、数据库和部署权限如何分层？低风险动作能否自动执行？高风险边界何时需要人确认？所有动作是否留下审计记录？没有治理的自主性，会把速度直接换算成风险；过度审批则让人陷入确认疲劳，重新成为系统瓶颈。

五个因素里，模型是最容易买到的那一个，另外四个必须由组织自己建设。这也解释了一个反直觉的推论：coding agent 普及之后，团队之间的差距未必缩小，反而可能扩大。所有人都能买到相似的模型，但不是所有团队都拥有同样清晰的代码库、同样快速的测试、同样可靠的运行环境和同样成熟的工程纪律。

DORA 2025 年关于 AI 辅助软件开发的研究，用“放大器”来描述这种现象：AI 会放大组织原有的优势，也会放大原有的弱点。一个反馈快速、平台完善的团队，更容易把生成速度转换成交付速度；一个职责混乱、测试脆弱的团队，得到的可能只是更多改动、更大的审查压力和积累得更快的技术债。

感受与秒表：生产率证据为什么互相矛盾

如果只看使用者的感受，AI Coding 的进展似乎极快。如果只看某些严格实验，结论却未必乐观。

METR 在 2025 年做了一项随机对照研究。16 名熟悉各自大型开源项目的资深开发者，在 246 个真实任务中被随机允许或禁止使用当时的 AI 工具。开发者事先预计 AI 会让自己快约 24%，做完实验后仍然感觉快了约 20%；而实际测量显示，他们平均多花了约 19% 的时间。

这个结果不能被简单外推成“AI 编程让开发者普遍变慢”。样本很小，参与者高度资深，项目庞大且质量要求高，用的是 2025 年上半年的工具。METR 在 2026 年的更新中也表示，更新的工具很可能已经带来更大提速，但新实验因为越来越多开发者不愿参加“禁用 AI”的任务而出现选择偏差，很难再得到同样干净的估计。

真正值得注意的不是某一个百分比，而是感受与测量之间的那道裂缝。生成速度极易被察觉，验证、阅读和返工的成本却容易被忽略。看着模型在几分钟内写出几百行代码，会产生强烈的速度感；一个小时后为了确认边界条件而进行的审查，却不一定被归因到这次生成头上。

另一边，Anthropic 在 2026 年发布了一项基于约 40 万次 Claude Code 会话的隐私保护分析。其中呈现的典型分工是：人作出约 70% 的“做什么”决策，Claude 作出约 80% 的“怎么做”决策。具备领域专业知识的使用者，单次指令可以触发更长的有效行动链，遇到问题时也更不容易放弃。研究者据此判断，coding agent 正在吸收一部分实现工作，却没有消除领域知识的价值。

这项研究规模很大，但它仍然来自厂商自身的数据，而且“成功”主要根据会话证据、测试通过或代码提交推断，并不能完整观察代码上线之后的业务价值。它与 METR 研究测量的对象也不同：一个关注大规模真实使用模式，一个关注少量资深开发者完成特定任务所花的时间。

把两类研究放在一起，矛盾就减弱了。AI 确实可以显著提高局部的生成和执行速度；这种提升能否转化为端到端生产率，取决于任务、使用者和工程环境；专业知识的作用正在从亲自实现，转向定义、判断、验证与纠偏；而生产率不能只测“写了多少”，应当测“多快得到被接受、可维护的结果”。

也正因为效果如此依赖环境，前沿组织的最佳实践才值得认真研究。它们不是几个提高 Prompt 命中率的小技巧，而是在回答一个系统问题：如何把局部能力转换成系统能力。

OpenAI：把代码库变成智能体可以居住的世界

OpenAI 公开的 Harness Engineering 案例，是目前最激进的组织实验之一。

按照其团队自述，他们用 Codex 构建了一个内部真实使用的产品，应用逻辑、测试、CI、文档、可观测性和内部工具均由智能体生成，规模达到约一百万行代码，团队估计所需时间约为手写方式的十分之一。有些单次任务会持续六小时以上。

这些数字属于单个厂商的内部案例，不能当作普遍的生产率结论。它真正有价值的地方，是团队为此不得不建设了什么。

首先，他们没有把一个巨大的 AGENTS.md 当成百科全书。过长的指令会挤占任务上下文，很快过期，也无法区分哪些信息真正重要。最后采用的方式是：短 AGENTS.md 作为目录，指向结构化的 docs/、架构文档、产品规范、执行计划和质量记录。智能体先从一张地图进入，再按任务逐层读取。这本质上是一次分层设计——把“总是需要的”和“偶尔需要的”放进不同的层级，让访问成本与访问频率相匹配。

其次，架构原则不能只写在文档里。团队通过自定义 lint 和结构测试限制依赖方向、数据边界、日志格式、文件规模等不变量。规则一旦可以机械执行，就不再依赖模型“记得遵守”。错误信息甚至可以直接携带修复提示，让一次失败本身成为下一步行动的上下文。

第三，应用本身必须对智能体可见。每个 Git worktree 都能启动一套隔离应用；智能体可以通过浏览器协议读取 DOM、导航页面、截取截图，复现和验证 UI 问题。日志、指标和 traces 也通过临时可观测性环境向智能体开放。于是“启动必须少于 800 毫秒”不再是一句抽象要求，而是一个智能体能够执行、测量并反复优化的目标——一个真正意义上的评价函数。

第四，审查被纳入闭环。实现智能体先自行检查，再请求其他智能体进行专项审查，根据反馈继续修改。人的注意力从逐行寻找普通错误，逐渐转向优先级、用户反馈、验收标准和少数需要判断的例外。

第五，技术债需要像垃圾一样定期回收。智能体会复制仓库中已有的模式，无论这些模式好坏。团队一度花固定时间清理所谓 AI slop，后来干脆把“黄金原则”编码成检查，并让后台智能体持续发现偏差、更新质量评分、提交小型重构。

这个案例最重要的启示不是“以后人不写代码”，而是：若想提高智能体的自治程度，必须先提高环境的可解释程度。自主性不是模型上的一个开关，而是仓库知识、运行工具、评价信号和恢复机制共同产生的系统属性。

Anthropic：长任务首先是一个交接问题

一个智能体能工作十分钟，与它能持续工作十小时，是两个不同的问题。

长任务最容易出现两种失败。第一种是企图一次做完所有事情，等上下文耗尽时留下一堆半成品；下一轮智能体不知道前面发生过什么，只能从头调查。第二种是看到仓库里已经有不少代码，误以为任务完成，提前停止。

Anthropic 在长时间 agent harness 的实验中，把这个问题类比成轮班工程师交接。每个新会话都像一名没有前任记忆的工程师来接班，所以上下文不能只留在对话里，必须沉淀到工作区。

其公开方案包括一个初始化智能体和后续编码智能体。初始化阶段建立运行脚本、结构化功能清单、进度文件和初始 Git 状态。此后每一轮只挑一个未完成的功能，做完就跑验证，提交一个干净的 Git commit，并记录进展，为下一轮留下明确入口。

Git 在这里不只是版本管理工具，也是实验记录。它保存哪些尝试成功过，允许回退坏改动，并把一个长任务切成一串可恢复的离散状态。进度文件则负责告诉下一轮“为什么会变成现在这样”，避免只能靠最终代码反向猜测。

Anthropic 还发现，智能体即便跑过了单元测试，也可能在真实用户路径上失败。只有明确要求它使用浏览器自动化、以用户的方式操作完整应用，端到端结果才明显改善。这个发现与 OpenAI 的做法相互印证：代码可读只是第一步，运行中的产品也必须可读。

到 2026 年，Anthropic 又公开了 planner、generator、evaluator 三角色架构。计划者分解目标，生成者实施，评估者依据明确标准判断结果。这个结构本身并不神奇，它只是把成熟工程团队里的产品规划、实现、Code Review 和 QA，重新表达成适合智能体执行的角色分工。

这里有一个容易被忽略的重点：增加智能体的数量，并不会自动增加独立判断。如果生成者和评估者共享同样的错误上下文、同一批不完整的测试和同一种模型偏见，所谓评估很可能只是自我赞同。角色分离只有在评价标准清楚、证据真实、上下文适度独立时才有意义。

Cursor：先画地图，再动手

Cursor 公布的最佳实践更接近日常开发者可以直接采用的工作方式。

第一项是先计划。对于复杂改动，智能体先研究仓库、定位文件、澄清要求，形成一份可编辑的实施计划，得到确认后再写代码。计划的价值不在形式，而在于尽早暴露双方对问题的不同理解。一个错误方案写成五条计划时很容易被看见，写成五千行代码之后才发现，返工成本就高得多。这本质上是在为搜索过程加一道早期剪枝：越早排除掉整片错误的方向，后面的每一步就越便宜。

第二项是把长期信息分成 Rules 和 Skills。Rules 保存每次任务都需要的少量静态约束，例如构建命令、代码风格和标准目录；Skills 保存只在特定工作流中按需加载的知识、脚本和步骤。把整本规范塞进始终加载的上下文，既浪费注意力，也让真正相关的要求被淹没。

第三项是提供明确的验证目标。Cursor 特别强调类型系统、lint 和测试，因为智能体只有拿到清楚的成功信号，才能自行迭代。测试驱动开发在这里获得了一层新的含义：测试不只是帮助人设计代码，也为机器搜索实现空间提供了评价函数。

第四项是隔离并行执行。多个智能体在独立的 Git worktree 中工作，避免互相覆盖文件。困难任务还可以让多个模型独立尝试，再比较结果。并行的价值不只是节省墙上时间，也来自方案的多样性；不过产生多个答案很容易，真正困难的是建立可靠的选择机制。

第五项是基于运行证据调试。Cursor 的 Debug Mode 会先形成多个假设，在代码中加入日志，让用户复现，再根据实际行为定位根因。这比让模型在没有任何新证据的情况下不断“再猜一次”，更接近科学实验的做法。

Cursor 的公开实践里藏着一个朴素而重要的原则：当智能体走错方向时，继续在原对话上叠加补丁未必是最好的选择。退回计划、补充证据、重新开始，往往比抢救一段已经被错误假设污染的长上下文更便宜。

GitHub：把 Issue 写成一份实验合同

GitHub Copilot 对任务边界的建议最为朴素，却可能是最容易被忽视的一项。

GitHub 建议把分配给 cloud coding agent 的 Issue 直接当作一个 Prompt 来写。一项理想任务需要说明要解决的问题、完成后的验收标准，以及相关文件或范围。刚开始时，适合挑选缺陷修复、测试补充、文档更新、可访问性改进和有限的技术债，而不是一上来就交付跨多个仓库、依赖大量隐性业务知识的重构。

这实际上是在建立一份“实验合同”：观察到了什么问题，哪些行为应当改变，哪些行为不能改变，什么证据足以说明成功，允许在什么边界内行动。

任务描述越接近这份合同，智能体需要猜测的部分就越少。反过来，“优化一下登录”“重构得更优雅”这类要求，把最重要的判断留在了空白处，模型只能用训练数据中的一般偏好去填补，而一般偏好未必符合当前产品。

GitHub 同样强调预安装依赖和仓库级 instructions。如果智能体能在自己的环境中构建、测试和验证，产出可快速合并 PR 的概率就会提高。换句话说，任务质量和环境质量必须同时成立：清楚的问题放进坏掉的环境里仍然无法执行，完美的环境面对模糊目标也只能高效地生产不确定性。

Cognition：让一次经验成为可检索的组织记忆

Cognition 对 Devin 的建议用了一个很贴切的类比：为智能体配置仓库和开发环境，就像为新员工准备入职第一天的电脑。

如果每次会话都要重新安装依赖、寻找启动方式、猜测内部库的用法，智能体的大量时间会花在重复 onboarding 上。准备好的环境快照、正确分支、工具和仓库索引，可以把注意力留给真正的任务。

Devin 的 Knowledge 和 Playbook 则在解决另一个问题：组织中大量经验既不适合放进每次都加载的总说明，也不能永远散落在对话里。常见故障、部署流程、测试方法和内部工具用法，可以保存成较短的、带有检索触发条件的知识单元，在相关任务中自动取回。

这个设计与 OpenAI 的渐进披露、Cursor 的 Skills 十分接近：不要让智能体一次记住一切，而要让它知道在什么时候去哪里取得所需的知识。

Cognition 还给出了一个很务实的经验范围：如果一项任务原本由人完成大约不超过三小时，智能体通常更容易处理；更大的目标应当拆成聚焦的 session，并在隔离环境中并行。这个数字不是普遍定律，却表达了一种成熟的边界感。前沿工具可以处理越来越长的任务，不代表任务越大越适合一次性委托出去。

更重要的是，会话结束之后还可以分析成功或失败的轨迹，把改进后的 Prompt、知识或 Playbook 留给下一次。于是一次任务不再只是消耗模型调用，而成为组织学习的一个样本。

五个入口，一套工程学

把五家组织放在一起，可以看出它们分别从不同入口接近同一个系统。

组织	主要入口	解决的核心问题
OpenAI	仓库结构、可观测性、机械约束	怎样让智能体理解并操作完整工程世界
Anthropic	长任务、状态交接、生成—评估	怎样跨上下文持续推进并避免假完成
Cursor	计划、Rules、Skills、worktree	怎样把个人日常开发变成可控的 agent 工作流
GitHub	Issue、验收标准、PR 环境	怎样把任务表达成可执行、可审查的合同
Cognition	环境配置、Knowledge、Playbook	怎样让一次经验成为可检索的组织记忆

这些入口最终汇合成七项较为稳定的实践。

先定义实验，再启动执行

高质量任务不是一句愿望，而是问题、范围、非目标和验收标准的组合。复杂任务先研究、计划和确认，简单任务可以直接执行，但都需要一个可以辨认的完成状态。

让代码库成为可信的外部记忆

架构、产品原则、运行方法、历史决策和典型实现应尽可能版本化。仓库不只是源代码的容器，也是智能体进入组织的公共界面。藏在人脑和聊天记录里的知识，无法稳定参与自动执行。

给地图，不给信息垃圾场

始终加载的指令应当短、稳定、具有导航作用，详细领域知识按路径或技能动态读取。信息越多不等于上下文越好；好的上下文是在正确的时刻出现的正确证据。

把规范转化为可执行反馈

能用类型系统、lint、结构测试和 CI 表达的规则，不应只依赖自然语言提醒。自然语言适合解释目的，机器检查负责持续执行。错误信息最好直接说明如何恢复，让失败本身带有信息价值。

让智能体接触真实产品，而不只接触代码

单元测试覆盖的是局部行为，用户面对的是完整系统。智能体需要尽可能启动应用、操作界面、查询日志和指标，生成截图、视频或性能证据。验证层级越接近用户结果，局部过拟合就越难冒充完成。

小步推进，并保持可恢复状态

每轮处理有限的功能，结束时留下干净代码、明确提交和进度记录。长任务的可靠性不来自无限上下文，而来自任何时刻都能由一个新的执行者接手。Git commit 是成本极低的恢复点。

把失败转化为系统资产

如果智能体第二次犯同样的错误，问题通常不只是这次 Prompt 写得不好，而是系统缺少某种可复用的约束。修复一次代码只能解决一个案例；增加测试、规则、文档、技能或工具，才能影响未来所有任务。

这七项实践指向同一个方向：把人的隐性判断逐步转化成环境中的显性结构。但这不意味着所有判断都应当被编码。产品取舍、伦理边界和高风险例外往往无法完全机械化。成熟的做法不是消灭人，而是让机器处理那些可以清晰反馈的部分，把人的注意力留给无法廉价定义评价函数的部分。

哪些做法仍然属于前沿实验

公开案例里也有一些颇具吸引力、却不能直接普及的做法。

完全不手写代码。 OpenAI 的实验逼着团队把所有能力缺口都修进环境，因为人不能临时接管实现。这种约束有助于发现真正的系统瓶颈，但成立条件极高：团队本身具备强工程能力，产品边界可控，测试和观测持续完善，错误可以快速修正。对支付、医疗、基础设施这类高风险系统，“没人手写”本身并不构成质量证明。

用智能体审查智能体。 独立审查可以扩大覆盖面，却可能共享盲点。相同模型、相同上下文和相同测试产生的第二意见，未必真正独立。适合自动审查的是可以明确表达的安全模式、测试缺口和架构约束；涉及产品意图和责任判断时，人类仍应承担最终决定。

同题并行，选择最佳答案。 Best-of-N 可以增加候选多样性，特别适合困难且能自动评分的任务。但如果评价器不可靠，增加候选只是增加审查负担；如果评分器存在漏洞，更多搜索反而更容易找到迎合指标的错误解。生成能力必须与选择能力一起扩张。

减少合并门禁。 在高吞吐、低回滚成本的环境中，等待可能比修正更贵，短命 PR 和快速后续修复可以提高流动速度。但关键系统的失败成本并不相同。是否自动合并，应由变更的可逆性、爆炸半径、监控能力和责任边界决定，而不是由 agent 看起来有多聪明来决定。

长时间无人值守。 智能体运行六小时，不等于六小时都在有效进步。长任务必须有预算、阶段目标、停止条件和可观察的进度。如果没有新反馈，循环可能退化为重复；如果评价目标不完整，持续优化可能只是在扩大偏差。持续时间是一种资源，不是能力指标。

这些实验有一个共同前提，可以概括成四条：反馈足够快，错误容易发现，状态可以恢复，风险能够隔离。缺少任何一条，就应当降低自主级别。

软件为什么拥有“可验证性红利”

在很多知识工作中，AI 生成之后，人必须亲自判断结果。一份报告是否真正洞察问题，一套战略是否适合组织，一份法律意见是否覆盖关键风险，往往没有一条命令可以立刻回答。

软件不同。

代码可以编译，类型可以检查，函数可以测试，服务可以启动，性能可以测量，界面可以操作，改动可以比较，失败可以回滚。这些信号没有一个是完美的，但它们合起来，让软件拥有一套异常丰富的机器可读反馈。

可以把它称为“可验证性红利”。

这也是 AI Coding 进展快于许多其他 agent 场景的重要原因。模型不必一次就完全正确，只要它能提出一个尚可的候选，并从环境中获得高质量反馈，就可以通过多轮搜索逐步逼近目标。搜索能否收敛，靠的从来不是起点有多好，而是每一步的反馈信号有多可信。

但可验证性红利不会自动到账。一个没有测试、无法本地启动、日志混乱的仓库，名义上属于软件，实际上并没有为智能体提供足够的验证能力。反过来，一个拥有稳定模拟器、明确评分器和自动实验设备的科学领域，可能比一个糟糕的软件项目更适合 agent。

所以真正决定进展速度的，不是“代码”或“科学”这个标签，而是几个更朴素的量：提出一次候选的成本有多高，执行一次实验要多久，结果是否提供了明确的新信息，失败能否安全恢复，评价信号与真实目标有多接近。

这组问题把 AI Coding 与 AI for Science 连在了一起。

AI Coding 就是一间缩小的自动化科学实验室

在科学研究中，基本循环是提出假设、设计实验、观察数据、修正理论。在 agentic coding 中，对应关系相当清楚。

科学研究	AI Coding
研究问题	产品需求或缺陷
假设	实现方案或根因判断
实验设计	代码修改与测试计划
实验设备	编译器、运行环境、浏览器、数据库
观测数据	测试、日志、指标、截图、用户行为
同行评议	Code Review、独立 agent review
重复实验	CI、回归测试、跨环境验证
实验记录	Git 历史、执行计划、进度日志

软件实验比湿实验便宜得多。复制一个 worktree 只需几秒，复制一间生物实验室却不可能这么简单；运行一千次测试可以并行，临床试验无法随意加速；代码错误可以回滚，现实世界的实验后果未必可逆。

这让 AI Coding 成为测试自主研究方法的理想场所。计划—生成—评估、多智能体分工、持久记忆、工具使用和风险治理，都可以先在软件世界中成熟，再迁移到材料、药物、气候和其他科学领域。

然而两者也共享同一种危险：把评价指标误认成真实目标。

代码通过现有测试，不等于满足完整需求；一个分子在模拟中得分很高，不等于能成为安全药物。测试集相当于科学中的测量方案，它只能观察被设计出来的那一部分。如果智能体可以反复针对同一批可见测试做优化，它就可能学会迎合测试，而不是解决真实问题。

因此，成熟的 AI Coding 需要保留 held-out 验证、真实用户路径、独立评估和人类判断。这与科学中的复现、盲测和同行评议作用相似：不是因为机器不能生成答案，而是因为任何生成系统都可能利用评价器自己没有意识到的缝隙。

从这个角度看，AI for Science 的瓶颈也更容易理解。AI 已经能够快速提出大量蛋白质、材料和药物候选，真正稀缺的是实验吞吐量与可靠反馈。AI Coding 今天积累的经验告诉我们：提高候选生成速度只是第一步，决定系统产出的，是能否同步建设自动实验、评价标准、状态记录和安全边界。

人从程序员变成“首席实验员”了吗

当 agent 承担越来越多的实现工作，人类工程师的角色确实会变化，但“人只负责说一句需求”是一种危险的简化。

Anthropic 的会话研究显示，典型分工仍然是人决定较多的“做什么”，模型决定较多的“怎么做”。领域专家比新手更能给出精确方向、要求关键验证，并在模型误解时纠偏。模型的执行能力越强，一条高质量指令能够撬动的行动链就越长，专业判断的杠杆反而更大。

这很像科学家与自动化设备的关系。实验设备越先进，科学家的价值就越不在于亲手移动每一支试管，而在于选择值得研究的问题、识别有效证据、发现仪器偏差、解释异常结果。

AI 时代的软件工程师可能逐渐承担四种角色。作为问题定义者，把含糊的愿望转化为范围、约束、非目标和验收标准。作为环境设计者，建设代码结构、工具、测试和观测，使正确方向更容易被找到，错误方向更容易被排除。作为评价设计者，决定哪些信号代表局部正确，哪些证据才代表用户价值，哪些风险必须由人判断。作为异常处理者，处理系统从未见过、规则尚未形成、后果难以回滚的情况，并把新经验沉淀回系统。

这不是传统编程能力的简单消失。没有实现经验的人，可能不知道什么要求可以被机械验证，什么架构会带来长期成本，也难以识别一段“测试全绿”的代码为什么仍然危险。未来更值钱的能力，可能是把实现知识提升为系统设计知识，而不是彻底跳过实现知识。

组织采用 coding agent 的五级阶梯

不同团队不必直接复制最激进的案例。更合理的做法，是按照自己的反馈能力逐级提高自主性。

第一级是个人助手。 AI 负责解释代码、生成局部函数、补测试和整理文档，人负责选择文件、执行命令和验证结果。这一阶段的重点是建立基本使用习惯，识别适合 AI 的任务，不需要复杂基础设施。

第二级是受监督智能体。 Agent 可以搜索仓库、修改多文件、运行测试，但每个任务由人持续观察和确认。这一阶段应当建立简洁的仓库说明、标准验证命令和明确的验收标准。目标不是无人值守，而是让 agent 能完整跑通一个闭环。

第三级是可验证任务代理。 对于范围清楚、风险有限的任务，agent 可以独立工作到 PR，附带测试、截图、日志或其他证据，人主要审查结果与高层设计。进入这一阶段的前提是环境可复现、测试可信、失败可恢复、权限有边界。

第四级是并行代理系统。 多个 agent 在隔离 worktree 或云环境中分别处理任务，专门的 reviewer、测试或安全 agent 进行交叉检查。此时新的瓶颈会变成任务编排、冲突处理、候选选择和人类注意力。不能只增加执行数量，还要建设优先级和质量控制。

第五级是 agent-native 工程系统。 仓库知识、架构约束、运行环境、可观测性、审查、技术债治理和反馈沉淀，均以 agent 可操作为默认。人主要负责产品方向、风险政策和异常判断。这是 OpenAI 案例试图探索的状态，目前仍属于少数组织的前沿实验，不是买一个订阅就能获得的产品功能，而是长期工程投资的结果。

这五级不是一张成熟度荣誉榜。关键系统完全可以长期停在第三级，因为更多自治带来的收益不足以覆盖风险。正确的级别取决于任务的可验证性和失败成本，而不是行业潮流。

该测量什么：把判断力做成多级缓存

如果考核指标仍然是代码行数、完成 Issue 数或智能体运行时长，团队很容易奖励错误的东西。

代码生成越便宜，代码量就越不适合作为产出指标。更值得关注的是这样一组问题：从提出需求到获得可接受结果的总周期有多长；人类在澄清、审查和返工上花了多少时间；上线后的逃逸缺陷与回滚比例是多少；同类任务第二次完成是否更快、更稳；一次失败有没有产生可复用的测试、规则或知识；智能体生成的改动在数月之后是否仍然易于理解和维护；并行执行是真的缩短了关键路径，还是只制造出更多待审 PR；用户得到的价值有没有提高，而不只是内部吞吐增加。

其中最值得盯住的是“第二次是否更好”。

传统自动化通常替代一项重复劳动；harness engineering 更大的潜力，是让每一次失败改善以后所有的执行。如果一个团队每次都用临时 Prompt 纠正同一种问题，它只是在重复辅导。如果它把纠正转成 lint、测试或 Skill，经验就开始复利。

可以把两种工作方式想象成两种缓存策略。第一种系统每次遇到问题都重新计算，眼前看起来灵活，长期却在不断支付同一笔成本。第二种系统会把昂贵的判断保存到合适的层级，在相似请求出现时直接复用。文档、典型实现、测试、规则和工具，就是组织判断力的多级缓存。

而任何用过缓存的人都知道，缓存最难的部分从来不是写入，而是失效。过时的知识会污染结果，过多的规则会挤占上下文。所以还需要一套失效机制：文档有负责人和更新时间，检查能够发现过期链接，后台任务清理不再适用的原则。组织记忆不仅要能写入，也必须能够被修订和遗忘。

安全不是最后一道审批，而是自主性的设计变量

Coding agent 与普通聊天工具最大的区别，是它可以行动。

它能读取文件、执行 shell、安装依赖、访问网络、调用 MCP、使用凭据、修改数据库，甚至触发部署。能力越完整，效率潜力越大，攻击面也越大。恶意的仓库内容、依赖脚本、网页文本或工具返回，都可能影响智能体的下一步行为。

最简单的安全办法是每一步都问人，但频繁确认会导致审批疲劳。人连续点了几十次“允许”之后，真正危险的动作出现时也可能不再认真阅读。

更合理的做法是按风险分层：在隔离 worktree 中读写代码、运行普通测试，可以高度自动；安装新依赖、访问外部网络、读取受限数据，需要更严格的策略；修改生产数据、使用高权限凭据、发布和删除，应当有明确门禁与审计；不可逆、高爆炸半径的动作，保留人类确认。

安全与效率并不是只能二选一。一个良好隔离、权限清晰的环境，反而可以给予智能体更大的低风险自治空间。真正阻碍自治的常常不是安全要求本身，而是组织从未区分过哪些动作危险，只能对所有操作采用同一种粗糙政策。

从 Prompt Engineering 到 Feedback Engineering

早期使用生成式 AI，人们自然把注意力放在 Prompt 上。更完整的背景、更清晰的指令、更合适的示例，确实会改善一次输出。

但 coding agent 的公开实践显示，Prompt 只是系统中的一个入口。

如果每次任务都要在 Prompt 里重新解释架构，说明组织知识没有被良好保存；如果每次都要提醒运行测试，说明验证没有进入默认工作流；如果同一种错误反复出现，说明失败没有反馈到规则；如果 agent 无法判断界面是否正常，说明产品没有向它暴露足够的观测。

因此，前沿工程的重心正在从 Prompt Engineering 移向 Feedback Engineering，它关心的是另一串问题：怎样让智能体获得正确的上下文，怎样让它执行真实的动作，怎样让环境返回高信息量的证据，怎样限制它利用不完整的指标，怎样把一次纠正变成长期资产，怎样让人只在真正需要判断的时候介入。

Prompt 优化的是一次回答，反馈系统优化的是一系列未来行动。

这也是 AI Coding 对其他知识工作最大的启示。想让 AI 在法律、金融、医疗或科研中承担更完整的任务，仅仅提高语言能力并不够。每个领域都需要自己的“编译器、测试和 CI”：结构化规则、可重复实验、独立评价、权限边界和结果追踪。没有这些设施，模型越能生成，验证负担就越可能成为新的瓶颈。

结语：最先进的不是会写代码的机器，而是会学习的工程系统

AI Coding 的故事很容易被讲成一次职业替代：机器开始写代码，人类程序员即将退出。

前沿组织的真实实践呈现出更复杂的图景。

模型确实承担了越来越多的实现工作，但为了让它可靠地完成工程，团队不得不重新建设那些过去由人类默契维持的部分：知识如何保存，任务如何定义，架构如何约束，结果如何验证，风险如何隔离，失败如何沉淀。代码生成越便宜，这些工作就越重要。

于是，AI 并没有让软件工程消失，反而把软件工程最本质的部分暴露了出来。软件工程从来不只是把想法翻译成语法，而是组织复杂性、建立反馈、控制变化并对结果负责。

回到开头那两家公司。同一个模型在两个代码库里表现得像不同水平的工程师，是因为模型只是系统的一部分。一个拥有清楚地图、可信知识、快速实验、严格评价和安全恢复机制的代码库，会把模型能力放大；反之，它只会把智能体变成一台更快制造不确定性的机器。

软件世界暂时站在前面，是因为它拥有一间天然的自动化实验室。我们可以低成本复制环境，迅速运行实验，记录每一次变化，并让机器读取反馈。AI Coding 因而为 AI for Science、AI for Work 乃至更广泛的自主系统提供了一次提前演练。

真正值得关注的，不是哪一个模型又多解决了多少道题，而是我们是否正在学会设计一种新的组织：它能让人的判断与机器的执行形成闭环，让每次错误留下可复用的知识，让产出速度增长的时候，正确性、可维护性与责任并没有被抛在身后。

这样的系统才称得上“会学习”。

而 AI Coding 的工程之美，也许正在这里：我们不再只为机器编写程序，而是在编写一个环境——让机器能够理解世界、检验行动，并从失败中继续前进。

参考资料

OpenAI, Harness engineering: leveraging Codex in an agent-first world，2026。企业内部工程案例；文中的规模和效率数字属于团队自述。
OpenAI, How OpenAI uses Codex。OpenAI 不同工程团队使用 Codex 的案例汇总。
Anthropic, Effective harnesses for long-running agents，2025。介绍初始化、进度文件、增量提交与端到端验证。
Anthropic, Harness design for long-running application development，2026。介绍 planner、generator、evaluator 结构。
Anthropic, Agentic coding and persistent returns to expertise，2026。基于约 40 万次 Claude Code 会话的厂商内部观察性研究。
Anthropic, Making Claude Code more secure and autonomous with sandboxing，2025。
Cursor, Best practices for coding with agents，2026。涵盖 Plan、Rules、Skills、测试、worktree、并行与 review。
Cursor, Governing agent autonomy with Auto-review，2026。讨论按风险调整自主权和审批。
GitHub, Best practices for using GitHub Copilot to work on tasks。涵盖任务边界、验收标准、仓库指令与执行环境。
GitHub, Adding repository custom instructions for GitHub Copilot。介绍仓库级、路径级和 AGENTS.md 指令。
Cognition, Your First Session。介绍仓库准备、任务切分和执行范围。
Cognition, Knowledge。介绍可检索组织知识及其维护方式。
DORA, State of AI-assisted Software Development 2025。将 AI 描述为组织系统的放大器。
METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity，2025。针对资深开源开发者的随机对照研究。
METR, We are Changing our Developer Productivity Experiment Design，2026。讨论后续实验的选择偏差及工具进步。