# 别只给员工买 AI 工具：互联网公司转型 AI Native 的完整方法论

> 从 Loop Engineering、Harness Engineering 到 AI-DLC 2.0 与 AI-PLC：互联网公司转型 AI Native 的四层完整方法论，以及岗位、KPI、制度、中层与团队结构的组织重构路线图。

- 作者: zhuermu
- 发布: 2026-07-18
- 网页版: https://zhuermu.com/blog/ai-native-org/

---

Loop Engineering · Harness · AI-DLC 2.0 · AI-PLC · 组织重构

上一篇[**《Agentic AI 时代，AI Coding 软件工程该怎么做？一套完整的 AI-DLC 方法论》**](https://mp.weixin.qq.com/s/IAZ1KUNAPTvHCRTLIMleEw)发出后，后台被问得最多的是同一个问题：**"方法论看懂了，可我们公司工具也买了、账号也开了、培训也做了，为什么整体还是没变快？"**

 今天这篇是它的续集，也是升级：从研发流程，上升到整个组织。写给每一个想把公司真正带进 AI 时代的人。

## 引子：工具买了一堆，公司为什么没变快？

2026 年，几乎每家互联网公司都在"All in AI"。

买最贵的 AI 编程工具，给全员开账号；组织培训，请专家讲提示词技巧；发红头文件，要求"人人拥抱 AI"。

半年过去，复盘会上的数据很尴尬：**代码产出确实快了，但产品上线速度几乎没变。**需求还是堆在评审会里，测试还是卡在发布前，事故还是半夜打电话找人。

更扎心的是一组研究数据：METR 在 2025 年做过一个随机对照实验，让资深开源开发者使用 AI 工具干活，结果平均**慢了 19%**——而他们自己坚信变快了 20%。（METR 在 2026 年初的后续研究中承认，随着工具进化，"变慢"这个数字已经改观；但另一个发现至今没被推翻：**人对 AI 提速的自我感觉，和秒表测出来的现实，可以差出近 40 个百分点。**）

问题出在哪？

**✦ 一个比喻**

 把喷气发动机装在马车上，得到的不是飞机，而是散架的马车。AI 模型就是那台发动机，性能每几个月翻一番。但发动机不等于交通工具——你还需要底盘、传动、刹车、仪表盘，以及一套全新的交通规则。大多数公司的"AI 转型"，只做了买发动机这一步。

这篇文章想讲清楚一件事：**从"用 AI 的公司"到 AI Native（AI 原生）的公司，中间隔着四层改造**——

![From Using AI to AI-Native: Four Layers of Change](https://zhuermu.com/images/wx/ai-native-org/img-01-d130ccf4.png)

这四层的方法论，分别来自 2026 年最重要的几份公开实践：OpenAI 的 Harness Engineering 实验、Addy Osmani 命名的 Loop Engineering、AWS 开源的 AI-DLC 2.0 规范和 AI-PLC 工作流。

我们一层层来。

• • •

## 1先看两个标志性事件：发动机已经就位

### 事件一：三个人，五个月，一百万行代码，零手写

2026 年，OpenAI 内部一个团队做了个实验：从零构建一个软件产品的内部版本，全程不允许人手写任何代码。应用逻辑、测试、CI 配置、文档、监控、内部工具——每一行都由 Codex（OpenAI 的编程 Agent）生成。

五个月后，这个产品有了内部日活用户和外部测试者。它正常发布、部署、出故障、被修复。团队从 3 个工程师扩到 7 个，累计合并了约 1500 个 PR（代码合并请求），人均每天 3.5 个。他们估算，比手写代码**省了 90% 的时间**。

这个实验的总结只有六个字：**Humans steer. Agents execute.**（人类掌舵，智能体执行。）

### 事件二：两句宣言，一个新学科

同样在 2026 年，两位顶级工具的作者先后说了两句话。

OpenClaw 的作者 Peter Steinberger 说："你不应该再给编程 Agent 写提示词了。你应该设计『替你提示 Agent 的循环』。"

Claude Code 的作者 Boris Cherny 说得更直接："我已经不再 prompt Claude 了。"

注意，这两位是**全世界最会用 AI 编程工具的人**——工具就是他们自己写的。连他们都不再逐句指挥 AI 了。

6 月，Google Chrome 工程负责人 Addy Osmani 把这个转变正式命名为 **Loop Engineering（循环工程）**，一个新学科就此诞生。

这两个事件说明同一件事：发动机已经足够强，瓶颈转移到了发动机之外。接下来的问题是——那个"之外"到底是什么？

• • •

## 2Loop Engineering：从"会用 AI"到"设计循环"

先用一个厨房里的例子理解什么是"循环"。

**烧饭有两种方式。**一种是柴火灶：你得守在灶边，随时看火候、添柴、搅拌，人不能走开——这就是逐句 prompt AI 的状态，AI 每做一步你都要盯着、纠正、再下一条指令。

另一种是电饭煲：你放米加水，按下按钮就可以去干别的。为什么敢走开？因为电饭煲内部有一个**闭环**——温度传感器持续检测，没熟就继续加热，熟了自动跳闸保温。

**✦ Loop Engineering 就是给 AI 造电饭煲**

 设计一个让 AI 自己转、转到"熟了"自动停的循环，而不是人守在旁边一步步指挥。

一个设计良好的循环长这样：

![Anatomy of a Well-Designed Loop](https://zhuermu.com/images/wx/ai-native-org/img-02-05c1d145.png)

图里有四个要素：每一轮做什么、什么触发下一轮、**什么算"完成"**、卡住了怎么办。其中**第三个最难，也最重要**。

"报告写完了"不是完成标准——AI 会在第一轮就宣布写完了。"报告包含执行摘要、三个论证章节、每章至少两处数据引用、且通过与原始需求的一致性检查"才是完成标准。**完成标准越是清晰可检验，AI 能独立走的路就越长。**

这就是那两句宣言的真正含义。Cherny 说"我不再 prompt Claude"，不是他不用 AI 了，而是他把功夫花在了别处：定义任务的完成标准、搭建自动触发的机制、设置卡住时的升级路径。之后 AI 在循环里自己转，他只处理循环"抛出来"的异常。

Osmani 总结了支撑循环的六个构件，不用记名字，看功能就懂：

• **Automations（自动化触发器）**：定时或事件触发，循环不需要人来启动

• **Worktrees（并行工作区）**：多个循环各占一个隔离空间，互不干扰

• **Skills（技能包）**：把"怎么做某类事"的经验写成 AI 可加载的文件

• **Connectors（连接器）**：让 AI 够得着真实系统——数据库、日志、工单

• **Sub-agents（子智能体）**：大任务拆给多个专职 AI 分头干

• **External state（外部状态）**：进度记在文件里而非对话里，随时可断可续

**对个人来说，这是工作方式的翻转：**你的价值不再是"很会给 AI 下指令"，而是"设计出不需要你下指令的系统"。一个人从"操作一台机器"变成"管理一个车间"。

但循环只解决了"AI 自己转"的问题。转起来之后，新问题马上出现：它转的时候能碰什么？转坏了谁知道？转出来的东西凭什么信？

这就到了第二层。

• • •

## 3Harness Engineering：循环需要一个"世界"

Harness 原意是马具、安全带——把烈马变成可用运力的那套装备。在 AI 语境里：

**Loop 定义 AI 的行为**（做什么、何时停），**Harness 定义 AI 的环境**（能碰什么、坏了怎么办、如何被看见）。

一个循环设计得再精妙，没有环境也活不下去：工具调用超时怎么办？上下文窗口塞满了怎么办？AI 改了不该改的文件怎么办？老板问"AI 上周二到底干了什么"，你答得上来吗？

回到 OpenAI 那个百万行代码的实验。真正值得抄的不是"3 个人 5 个月"，而是他们造的那套 Harness，一共三层：

**第一层：让仓库本身成为唯一事实来源（Context Engineering，上下文工程）。**所有 AI 需要知道的信息——架构说明、规范、决策记录——都放在代码仓库里，结构化、可索引。AI 不靠人口头交代背景，自己去仓库里读。反过来说：**凡是存在某人脑子里、聊天记录里、PPT 里的知识，对 AI 等于不存在。**

**第二层：用机器强制执行架构约束。**他们写了自定义的检查工具（linter），把"哪个模块不许调用哪个模块"这类架构规矩变成一提交代码就自动检查的硬规则。更妙的是，报错信息是写给 AI 看的——不光说"你违规了"，还说"应该改成什么样、参考哪个文件"。AI 读到报错就能自己修好，不用人插手。

**第三层：用 AI 的速度对抗 AI 的混乱。**AI 生产代码的速度太快，文档过时、死代码堆积的速度也跟着变快，人类根本清理不过来。所以他们养了一批"垃圾回收 Agent"：每天扫描文档和代码的不一致、每周清理没人调用的死代码——**用自动化的熵减对抗自动化的熵增。**

HashiCorp 联合创始人 Mitchell Hashimoto 给 Harness Engineering 下过一个朴素的定义：**每当 Agent 犯一次错，就工程化地解决一次，确保它永远不再犯这个错。**

 人的犯错处理方式是"批评教育下次注意"；Harness 的处理方式是"改造环境让这个错误无法再发生"。前者依赖记性，后者沉淀为资产。

### 人的位置：一部四级阶梯

Thoughtworks 的 Kief Morris 把人和 AI 循环的关系画成了一部阶梯，这也是每个技术人未来几年的职业路线图：

![Where Do Humans Stand? A Four-Step Ladder](https://zhuermu.com/images/wx/ai-native-org/img-03-9c51e624.png)

大多数公司卡在第二级：员工用上了 AI，但每个产出都要人肉审查，审查者成了新瓶颈，于是得出结论"AI 不省时间"。**从第二级到第三级的跃迁，才是 AI Native 转型的真正门槛**——人的精力从"检查产出"转向"建设那个自动检查产出的系统"。

Ruby 社区名宿 Chad Fowler 把这个转变放进了软件工程史：当年敏捷取代瀑布时，工程纪律并没有消失，而是从厚重的文档搬进了自动化测试。今天同理：

**✦ 纪律不会消失，只会搬家**

 这一次，它从"人的审查"搬进"机器的验证"。公式是：内部概率化，边界确定化——让 AI 在边界内自由发挥，但边界本身必须严格、明确、由机器强制执行。

到这里，个人有了循环，团队有了环境。但一家公司几百上千人，总不能每个团队各造一套轮子。**怎么把 Loop 和 Harness 升级为全公司的标准流程？**这就是 AWS 的 AI-DLC 2.0 要回答的问题。

• • •

## 4AI-DLC 2.0：把循环和缰绳制度化成一条流水线

AI-DLC（AI-Driven Development Lifecycle，AI 驱动的软件研发生命周期）是 AWS 开源的研发方法论。1.0 版验证了一件事：把研发过程组织成"AI 执行、人在关键节点把关"的阶段序列，是可行的——上一篇文章讲的就是它。

今年发布的 2.0 规范（在 GitHub 的 awslabs/aidlc-workflows 仓库公开）目标激进得多：**随着机器可校验的范围不断扩大，逐步减少人的介入，向自主软件交付渐进。**

以下是 2.0 规范里最值得所有公司借鉴的五个设计。这五个设计每一个都不只关乎写代码——记住这一点，第 6 节我们要拿它们重构组织。

### 设计一 & 设计二：三舱模型 + 两种验证

2.0 规范把任何一个研发环节的定义拆成三个"舱"：生成规格（吃什么进来、吐什么出去）、验证规格（怎么知道产出是对的）、学习规格（运行时学到了什么）。而验证规格又分成两类——能算的交给机器，要品的暂留给人：

![AI-DLC 2.0: The Three-Compartment Model](https://zhuermu.com/images/wx/ai-native-org/img-04-6f6c0b50.png)

看出来了吗？**第二舱就是 Loop Engineering 里的"完成标准"，整个三舱模型就是被制度化的循环。**电饭煲的跳闸条件，从个人手艺变成了公司标准件。

而且这个模型不挑工种。"需求澄清"可以这么定义（输入：模糊需求；输出：结构化需求文档；验证：每个需求都有可测的验收标准），"架构设计"可以，"部署上线"也可以。**凡是能说清"输入、输出、怎么算对"的工作，都能装进循环。**

两种验证的区分极其关键。**计算式验证**写成脚本和检查程序，非黑即白、零容忍，比如"任何接口不得裸奔上线（无鉴权）"——由机器强制执行，AI 说了不算，AI 也改不了。**推断式验证**写成自然语言规则让 AI 判断，比如"代码可读性良好"——是质量启发式，不是硬性关卡。

规范里有一个非常清醒的设计：**一个环节如果只有推断式验证（AI 自己评自己），它无权自我放行，必须交人审。**这防住了 AI 最阴险的失败模式：自己生成、自己打分、自己宣布合格——应付了检查的字面，绕过了检查的本意。

### 设计三：停机条件——自治的前提是刹车

每个自我修正循环都必须带停机条件：最多迭代多少轮、最多花多少预算。达到上限还没收敛，不许继续烧，立刻升级找人。这个设计一石二鸟：**既防 AI 跑飞（无限循环烧钱），也防人变瓶颈（事事请示）。**AI 在边界内完全自主，人只在真正需要判断时出现。

### 设计四：Skills——把流程拆成乐高积木

AI-DLC 1.0 的教训是流程定得太死：规范说"构建与测试"是一个阶段，但几乎每家客户实际上把它拆成评审、构建、功能测试、安全测试好几摊。2.0 的解法：不再规定死板的大阶段，把最小构件降级为 **Skill（技能）**——一个离散的能力单元，对应过去由某类专家提供的判断力：数据库设计、代码评审、安全分析……每个 Skill 内部都按三舱模型定义，公司可以自由组合、替换、新增。

**流程从"一条固定的流水线"变成"一盒可以自由拼装的乐高"。**这是对"每家公司都不一样"这个现实的正面回应。

### 设计五：Orchestrator——循环之上的循环

Skill 多了，谁来编排？规范定义了一个 **Orchestrator（编排者）**角色，它有五项职责，请仔细读——第 6 节它会再次登场：

• **目标持有**：对端到端结果负总责，不把目标跟踪甩锅给某个环节

• **流程编排**：按意图性质动态组装流程（新项目和修 Bug 走不同的路径），计划可变

• **路由与管控**：给每个环节喂正确的输入、跟踪状态、执行停机条件、管理升级、留存完整审计轨迹

• **抽象边界**：把每个环节当黑盒，不插手内部实现，只验收产出是否满足后置条件

• **跨环节守恒**：命名规范、安全策略这类横跨全流程的规则，由编排者在关键检查点统一把守

如果你觉得这五条读起来像某种"管理者职位说明书"——没错，先记住这个感觉。

• • •

## 5AI-PLC：转型不是工程部门的独角戏

讲到这里，敏锐的读者应该发现一个漏洞：前面讲的全是"怎么把东西做出来"。可是**做什么、为什么做，还是老样子**——PM 写 Word 版 PRD，拉会评审，层层传话，三个月后工程团队用最先进的 AI 流水线，高效地做出了一个没人要的功能。

上游不变，下游再快也是空转。这就是 AWS 开源 AI-PLC（AI-Driven Product Life Cycle，AI 驱动的产品生命周期，GitHub 上的 sample-ai-plc 项目）的原因：**把产品经理和业务角色也放进循环。**

AI-PLC 是一套纯自然语言对话的工作流，不需要写代码，专为 PM、业务负责人设计。它支持三个入口，覆盖产品思考的不同起点：

• **从客户痛点出发**：你手里有客户反馈、差评、调研素材。AI 引导你提炼痛点，用亚马逊经典的 Working Backwards（逆向工作法）生成 PR/FAQ——先写产品发布那天的新闻稿和常见问答，倒逼你想清楚"客户凭什么在乎"

• **从一堆想法出发**：团队攒了 10 个、20 个 AI 用例不知道先做哪个。AI 帮你逐个建档，用打分框架排出优先级，选出 Top 3，为每个生成一份 PROTOTYPE-*.md 原型规格文件

• **从规格文件直接开工**：拿到别的团队生成的 PROTOTYPE 文件，跳过所有讨论，直接让 AI 把可点击的原型做出来

注意两个精妙的设计。

**第一，交接物是"可执行的文件"，不是"开会传的话"。**产品和工程之间的接口，从"会议 + 文档 + 反复对齐"变成了一份 AI 可以直接执行的契约。产品循环的出口，严丝合缝地接上研发循环的入口：

![The Full Chain: Product Loop Meets Dev Loop](https://zhuermu.com/images/wx/ai-native-org/img-05-e38b45a7.png)

**第二，每个决策都有审计轨迹。**所有的输入、选择、否决，全程记录在 audit 文件里。三个月后有人问"当初为什么砍掉那个方案"，不用考古聊天记录。

看懂 AI-PLC 的结构了吗？它就是给产品工作装的循环：输入（痛点/用例）、迭代（AI 追问澄清、打分、生成）、完成标准（规格文件 + 审批通过）、升级机制（关键决策必须人拍板）。**三舱模型，一模一样，只是对象从代码换成了商业判断。**

从"听到客户抱怨"到"可点击的原型"，一个 PM 加一个 AI 工作区，**一周之内**。这在三年前是一个部门一个季度的工作量。

• • •

## 6组织架构到底怎么变（本文的重点）

铺垫完毕。现在回答标题里的问题：一家互联网公司，组织架构到底要怎么改，才配得上"AI Native"三个字？先给出本文最核心的一个判断：

**✦ 核心判断**

 AI-DLC 2.0 表面上是一份研发流程规范，实际上是一份 AI Native 组织的设计蓝图。它里面每一个技术概念，都对应一项组织制度的重写。

这个判断并不孤立。2025 年底以来，几家头部机构的研究几乎同时收敛到同一方向：麦肯锡把人与 AI 智能体并肩工作的新范式命名为 **Agentic Organization（智能体化组织）**，称其为工业革命与数字革命以来最大的组织范式迁移；微软在 Work Trend Index 里提出 **Frontier Firm（前沿企业）**，给出"AI 当助手 → 人机混合团队 → 智能体运营、人类掌舵"的三阶段路线，并预言每个员工都会变成管理一群智能体的 **Agent Boss**；BCG 在 2026 年中发布的客户数据显示，先行的智能体化企业已经做到约 3 倍的生产率提升和 80% 的周期缩短。

方向上，共识已经形成。但这些报告大多停留在"愿景与阶段划分"层面——**AI-DLC 2.0 的独特价值，是把"具体怎么改"写成了可执行的规格。**对照表如下，逐行展开：

| AI-DLC 2.0 的概念 | 组织层面的对应物 |
| --- | --- |
| 三舱模型（生成-验证-学习） | 岗位职责说明书的重写 |
| 后置条件 / 完成标准 | KPI 与验收标准的重写 |
| 两种验证（计算式/推断式） | 公司制度的分类改造 |
| Orchestrator 五职能 | 中层管理者的新职位说明书 |
| Skills 库 | 隐性知识的资产化 |
| 停机条件 + 升级机制 | 授权体系的重写 |
| 渐进式注水（Hydration） | 转型路线图本身 |

### 6.1 岗位说明书重写：从"做什么"到"三舱定义"

传统岗位说明书写的是职责清单："负责后端开发""负责活动策划"。AI Native 组织的岗位说明书按三舱模型重写：你的输入输出是什么（第一舱）？你的产出怎么验证是对的（第二舱）？你的工作会为组织沉淀什么规则（第三舱）？

第二舱说得越清楚的岗位，AI 能接管的比例越高，这个岗位上的人就越应该往"设计验证规则"的方向走。**说不清第二舱的岗位才真正危险——不是会被 AI 替代，而是没人说得清它创造了什么价值。**

### 6.2 KPI 重写：从"人汇报进度"到"机器可校验的完成"

"本周进度 80%"是典型的旧世界汇报——80% 是谁量的？拿什么量的？AI Native 组织里，工作的完成标准尽可能写成机器可校验的条件：测试通过率、检查规则零违规、性能指标达标、文档与代码一致性检查通过。

**凡是能自动校验的，不再开会同步；凡是不能自动校验的，才值得开会。**会议数量的下降幅度，是转型成色的一个诚实指标。

### 6.3 制度分类改造：员工手册里，哪些条款能变成代码？

拿出公司的规章制度、安全红线、审批流程，逐条问一个问题：**这一条能写成机器自动执行的检查吗？**

• **能**——比如"生产数据库变更必须有回滚方案"——那就写成计算式验证，装进流水线，从此不需要人审批这一项。违规根本提交不上去，审批会自然消失

• **不能**——比如"重大品牌活动的调性把控"——那就保留人的判断，但要求判断者持续把判断理由沉淀成文字，喂给第三舱，看未来能否逐步规则化

**制度从"写给人看、靠人自觉、靠抽查兜底"，变成"一部分编译成代码强制执行，一部分保留人判但持续蒸馏"。**这是 AI Native 组织和传统组织在治理上最深刻的分野。

### 6.4 中层的重生：管理者就是人肉 Orchestrator

回看第 4 节 Orchestrator 的五项职能——目标持有、流程编排、路由管控、抽象边界、跨环节守恒。把"环节"换成"下属团队"，这就是一份优秀中层管理者的职位说明书：对总目标负责而不甩锅；根据任务性质灵活组队而不是套死流程；给每个团队正确的输入、跟踪状态、该升级时升级；**不微观管理**（把团队当黑盒，只验收产出）；亲自把守跨团队的规矩。

区别在于：过去这些职能靠管理者的个人素质，时好时坏；现在其中大半——状态跟踪、路由、审计、停机——可以由编排系统机械执行，**管理者只保留最难自动化的两项：目标持有和跨环节守恒。**

所以中层不会消失，但会分化：把自己活成"信息中转站"的中层会被编排系统直接替代；能定义目标、能把守横向规则、能设计流程的中层，会成为组织里最稀缺的角色。

这个新角色已经有了名字。2026 年 2 月，Martin Fowler 与 Thoughtworks 召集的"软件开发的未来"闭门会上，与会者把这类"既不是写代码、也不是发布管理"的新工种命名为 **Supervisory Engineering（监督工程）**：指挥智能体、评估产出、校准信任、把标准编码进系统、定义智能体可以安全活动的边界。逐条对照，这正是"人肉 Orchestrator"的技术版职位说明书。

### 6.5 知识资产化：人可以走，Skill 留下

传统组织最怕资深员工离职——他脑子里的判断力（怎么评审代码、怎么排查故障、怎么谈客户）跟着人走了。AI Native 组织把这些判断力做成 Skill：一个可加载、可组合、可持续改进的能力单元。资深 DBA 的经验变成"数据库设计 Skill"，风控专家的直觉逐步蒸馏成"风控检查 Skill"的验证规则。

**组织能力第一次可以脱离具体的人而存在、而复利。**这也改变了"资深"的含义：资深者的价值不再是垄断判断力，而是把判断力写成 Skill 的能力——教得越多，越不可替代，因为最难的第二舱规则永远需要最懂的人来定义和迭代。

### 6.6 团队形态：三种新部门

综合以上，AI Native 组织的研发侧大概率长这样：

• **业务交付团队：小而全才。**每个方向 3-7 人，人人都能横跨产品-开发-运维（因为具体执行由 Agent 承担，人负责掌舵）。OpenAI 那个实验就是原型：7 个人干过去 50 人的活，靠的不是加班，是每人管理一群循环

• **Harness 平台团队：新的基建部门。**过去平台团队维护 CI/CD 和中间件，现在的核心资产是公司级 Harness——上下文基础设施、验证规则库、Skill 库、编排系统、审计系统。**这是 AI Native 组织真正的护城河所在：模型人人都买得到，Harness 只能自己长出来**

• **规则工程团队（或虚拟职能）：制度的编译器。**由最资深的工程师、风控、合规、安全专家组成，专职干一件事——把公司的红线、标准、品味翻译成机器可执行的验证规则

而在业务上游，PM 团队用 AI-PLC 跑产品发现循环，输出可执行规格直接对接交付团队。产品和工程的部门墙，被一份 PROTOTYPE 文件打穿。

• • •

## 7转型路线图：不搞大爆炸，搞"渐进注水"

看到这里你可能会问：道理都懂，但我们公司一堆历史包袱，从哪儿开始？

AI-DLC 2.0 对此有一个非常清醒的立场：**没有任何组织能一夜之间达到自主交付，妄图大爆炸式改革的都会失败。**规范给出的路径叫渐进式注水（Hydration）——像往水库里蓄水一样，一点点扩大 AI 能自主活动的水域：

![Progressive Hydration: The Transformation Roadmap](https://zhuermu.com/images/wx/ai-native-org/img-06-d2f1ba08.png)

**第一步：从已有的规则开始。**每家公司都有现成的、已经明确的规则：编码规范、命名约定、基本安全红线。先把这些写成机器可执行的验证，让 AI 在这个小水域里自主工作，其他一切照旧走人工。**不要等宏大的转型方案，今天就能开始。**

**第二步：持续蒸馏，让实践自动产生规则。**这是 2.0 规范里最精彩的设计，叫 Compound Engineering（复利工程）：每一次人工纠正都不该白费。如果评审者总是重写 AI 产出的某一类段落，系统就该提议一条新的验证规则；如果某个设计决策反复被人推翻，就该沉淀一条新的守则。规则提案经人批准后进入规则库——**组织的验证能力从实践中自动生长，而不是全靠专家闭门手写。**

传统组织的经验教训写在复盘文档里，三个月后没人记得；AI Native 组织的经验教训直接变成流水线上的检查规则，**从此这类错误物理上无法再发生**。这是两种组织学习速度的本质差距——一个靠记性，一个靠复利。

**第三步：扩大安全增量。**规则库越丰满，AI 可以连续自主执行的链路就越长。过去每一步都要人把关，后来只在关键节点把关，最后人只处理循环升级上来的异常。信任不是一次性授予的，是一条规则一条规则挣来的。

### 老组织的"债务体检"：Brownfield 现实检查

软件工程里把带着历史包袱的老系统叫 Brownfield（棕地），干净的新项目叫 Greenfield（绿地）。所有光鲜的实践案例——包括 OpenAI 那个——都是绿地。而你的公司大概率是棕地。

行业共识很诚实：**棕地系统直接上高级自动化，几周内必然翻车**——AI 制造混乱的速度会超过人类清理的速度。在架构不清的老代码库上跑 Agent，就像在没有车道线的路上开自动驾驶。2026 年初的一项对照案例研究（arXiv:2601.22667）比较了传统企业的棕地环境和 AI 原生初创的绿地环境，结论一致：组织能从 AI 中兑现多少收益，首先取决于既有工程资产和组织结构"可被 AI 消化"的程度，而不是买了多贵的工具。

技术侧有一份"Harness 就绪度"体检清单，同样适用于组织。上高强度 AI 自动化之前，先回答三个问题：

| 代码库体检 | 组织体检 |
| --- | --- |
| 每个模块的职责能一句话说清吗？ | 每个部门/岗位的职责能一句话说清吗？ |
| 模块间的依赖边界是强制执行的吗？ | 部门间的协作接口是明确的，还是靠拉群和喊人？ |
| 测试覆盖够 AI 自验产出吗？ | 工作成果有客观的验收标准，还是靠领导拍脑袋？ |

三问不过关，先花力气做"就绪度改造"——好消息是，AI 本身可以大幅加速这个整理过程（用 AI 梳理文档、补测试、理清接口）。**磨刀不误砍柴工，在这里是字面意思。**

**一个反直觉的提醒：转型水位由最短的板决定，而不是最长的板。**有团队上下文建设做到了顶级（AI 能读到一切），验证却全靠人肉评审——结果 AI 产出的代码架构漂亮，集成测试没人跑，照样天天炸。补上自动验证后，之前所有的上下文投入才开始兑现。诊断转型卡点时，找最弱的那个维度，别再给最强的维度加码。

• • •

## 8写在最后：组织本身，就是最大的那个 Harness

把四层收拢成一段话：**个人**设计循环，而不是敲提示词；**团队**建设环境，而不是审查产出；**流程**用三舱模型 + Skills + 编排 + 渐进注水制度化；**业务**让产品发现也进循环，规格即契约；**组织**的岗位、KPI、制度、中层、知识，全部按上面四层重写。

最后三个判断，供决策者参考：

**第一，AI Native 不是"人变少了"，是"杠杆变了"。**OpenAI 的团队从 3 人变成 7 人——人数在增加，因为每个人的产出杠杆是过去的十倍。转型的目标从来不该是裁员省钱，而是让同样的人做出十倍的事。以裁员为目标的"AI 转型"，会先裁掉那些本该去设计循环和 Harness 的人。

**第二，模型是租来的，Harness 是自己的。**所有竞争对手都能用上同款模型，正如当年所有公司都能买到同款服务器。差距长在别处：你的验证规则库有多厚，你的 Skill 库沉淀了多少判断力，你的组织制度有多大比例已经"编译"成了机器可执行的规则。**这些东西买不到、抄不走，只能从自己的实践里一天天长出来——这就是 AI 时代的组织护城河。**

**第三，管理这门手艺，正在变成一门工程。**目标怎么定、完成怎么验、异常怎么升级、经验怎么沉淀——这些过去依赖优秀管理者个人天赋的东西，正在被写成规格、规则和编排逻辑。未来的组织设计者要同时精通两件事：人性，和后置条件。

一百多年前，电动机取代蒸汽机，最初二十年工厂的生产率几乎没有提升——因为工厂主只是把蒸汽机原地换成了电动机，围绕中央传动轴的整个厂房布局纹丝没动。直到有人意识到电动机可以分散安装、每台机器自带动力，重新设计了整个工厂的布局和流程，生产率才真正爆发。

 今天的 AI 就是那台电动机。**买发动机的钱，每家公司都出得起；重新画厂房图纸的决心，才是稀缺品。**

• • •

### 参考资料

1. OpenAI, Harness engineering: leveraging Codex in an agent-first world, 2026
[openai.com/index/harness-engineering](https://openai.com/index/harness-engineering/)

2. Addy Osmani, Loop Engineering, 2026.6
[addyosmani.com/blog/loop-engineering](https://addyosmani.com/blog/loop-engineering/)

3. AWS, AI-DLC Workflows 2.0（本文仅转述其公开方法论概念）
[github.com/awslabs/aidlc-workflows](https://github.com/awslabs/aidlc-workflows)

4. AWS, AI-PLC: AI-Driven Product Life Cycle
[github.com/aws-samples/sample-ai-plc](https://github.com/aws-samples/sample-ai-plc)

5. Kief Morris, Humans and Agents in Software Engineering Loops, 2026.3
[martinfowler.com/articles/exploring-gen-ai/humans-and-agents](https://martinfowler.com/articles/exploring-gen-ai/humans-and-agents.html)

6. Mitchell Hashimoto, My AI Adoption Journey, 2026.2
[mitchellh.com/writing/my-ai-adoption-journey](https://mitchellh.com/writing/my-ai-adoption-journey)

7. Thoughtworks, The Future of Software Development Retreat, 2026.2
[thoughtworks.com/en-us/about-us/events/the-future-of-software-development](https://www.thoughtworks.com/en-us/about-us/events/the-future-of-software-development)

8. METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, 2025.7（2026.2 已发布后续数据）
[metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/)

如果这篇文章对你有帮助，欢迎**点赞、在看、转发**三连 🙏

关注我，持续分享 AI 时代的软件工程实战与深度思考