当工程师告诉你"AI一天就写完了"，你的第一反应是什么——Loss of control，还是 opportunity？本文基于OpenAI内部实验（3人团队、100万行代码、0行人工编写）和Harness Engineering方法论，拆解AI开发范式的三阶段演进，提出产品经理的四个角色转变和可直接落地的行动清单。核心判断：未来PM的竞争力不是写PRD，而是设计让AI能可靠执行PRD的环境。

一个让我重新审视自己价值的瞬间

周一早会，工程师老张给我看了一个PR——372个文件变更，新增8000多行代码。

我说：”这个需求我估了两周，你们什么时候开始做的？”

老张说：”昨天下午。AI写的，我review了一遍，改了几个边界条件。”

我当时的感受很复杂。一方面，这意味着我们的交付速度可以大幅提升。另一方面，一个不舒服的问题浮上来：如果工程师的工作从“写代码”变成了“review AI的代码”，那产品经理的工作会变成什么？

带着这个问题，我读到了OpenAI在2026年2月披露的一个内部实验——结果比我想的更极端。

二、一个颠覆认知的实验

OpenAI披露了一个内部实验：一个3人工程团队，在5个月内构建了一个100万行代码的产品。其中，0行代码由人工编写。

这不是Demo，不是概念验证。这是一个有真实日活用户的内部产品。所有代码——从业务逻辑、测试、CI配置到内部工具——全部由AI智能体Codex生成。

OpenAI用一句话总结核心理念：

“人类掌舵，智能体执行。”——Ryan Lopopolo, OpenAI

工程师的工作不再是写代码。他们的工作变成了：设计环境、明确意图、构建反馈回路——让AI能够可靠地完成任务。

这套方法论，OpenAI称之为Harness Engineering（驾驭工程）。

对于产品经理来说，理解这个转变比理解任何具体技术都重要。因为它正在重新定义一个根本问题：工程团队能做什么，以及需要多少人。

三、驾驭工程是什么？从提示词到驾驭的三阶段演进

过去四年，AI辅助开发经历了三个阶段：

1. 提示词工程（2022-2023年） 的核心问题是”如何问问题”，人扮演的是提问者的角色。
2. 上下文工程（2024-2025年） 将焦点转向”给AI看什么资料”，人的角色也随之变为资料整理者。
3. 驾驭工程（2026年至今） 阶段，核心问题演变为”如何让AI自主可靠地工作”，人则成为系统设计者。

一句话定义驾驭工程：设计让AI智能体能够自主、可靠、持续完成复杂任务的整体系统。

有一个关键区分必须理解清楚：

• 上下文工程解决的是”AI知道什么”——给AI投喂正确的信息
• 驾驭工程解决的是”AI能做什么”以及”做错了怎么办”——设计整个执行环境

类比理解：上下文工程像是给新员工准备入职文档；驾驭工程像是设计整个公司的组织架构、流程制度和绩效考核体系。前者让新人”了解情况”，后者让新人”能持续产出可靠的工作成果”。

四、Harness的四个核心组件

驾驭工程不是一个抽象概念，而是一套具体的工程实践。它包含四个核心组件。

4.1 上下文工程（进阶版）

这是驾驭工程的信息基础，但比传统的上下文工程更进一步。

静态上下文包括：

• AGENTS.md：放在代码仓库根目录的文件，告诉AI项目的构建步骤、测试命令、编码规范、架构约束、常见陷阱。每次AI犯错后就更新。
• 架构文档：模块划分、依赖关系、数据流向
• 设计决策记录：为什么选择A方案而不是B方案

动态上下文是更大的突破：

• AI能读取运行时日志、性能指标、错误追踪
• AI能通过浏览器自动化操作产品界面，验证功能是否正常
• AI能查询数据库状态，理解实际数据情况

类比理解：传统的上下文工程像是给员工一本公司手册；进阶版像是给员工配了工位电脑、内网权限、监控大屏——他能直接看到系统运行状态，而不只是读文档。

PM视角：你写的PRD、定义的验收标准、记录的产品决策，正在成为AI的直接输入源。它们的结构化程度、清晰程度，直接影响AI的执行质量。存在Slack里、会议纪要里、你脑子里的知识，AI看不到，也就无法利用。

4.2 架构约束（机械化执行）

这是驾驭工程的”护栏”，确保AI不会跑偏。

关键原则是：不靠文档提醒，而是靠工具阻止。

OpenAI团队在代码仓库中强制执行严格的分层架构。每个业务领域有固定的代码层级，依赖方向被严格验证，只允许特定的模块调用关系。

这些约束不是写在Wiki里让人遵守的，而是通过自定义Linter和结构测试机械化执行的。违反规则的代码根本无法提交。

更聪明的是：Linter的错误信息本身就是修复指令。当AI触发一个架构违规，错误提示不只是说”你违反了规则”，而是告诉AI”你应该这样修复”。

类比理解：这像是高速公路的护栏。它不是在路边立个牌子写”请勿偏离车道”，而是物理上让你无法开出去。护栏的存在反而让你能开得更快，因为你知道不会冲下悬崖。

PM视角：产品规范也需要”可执行化”。模糊的规范（”界面要简洁”）对AI没有约束力；明确的规范（”单页信息密度不超过X，主操作按钮必须在首屏”）才能被编码成检查规则。

明天就能做的一件事：翻开你最近写的PRD，找出所有”体验要好””性能要快”之类的模糊描述，把它们改成可量化的验收标准。

4.3 反馈回路（错误编码为规则）

这是驾驭工程的”学习机制”，让系统越来越可靠。

核心原则是：每次AI犯错，不是只修正这一次，而是更新系统，确保这类错误不再发生。

“每当你发现Agent犯了一个错误，你就花时间设计一个解决方案，让Agent永远不会再犯同样的错误。”——Mitchell Hashimoto, Terraform创始人

具体来说：

• 简单问题：更新AGENTS.md，添加新的指导规则
• 模式问题：添加新的Linter规则
• 架构问题：调整约束定义

类比理解：这像是航空业的”事故调查-规则更新”机制。每次事故后，不只是处罚责任人，而是分析根因、更新操作手册、修改飞机设计、调整训练流程。整个行业的安全性因此持续提升。

PM视角：验收标准的复用性变得关键。如果每个需求的验收标准都是一次性的，AI无法积累”什么是好的”的判断力。把验收标准抽象成可复用的检查项，它们就能成为持续生效的质量约束。

明天就能做的一件事：建一个文档叫”AI踩过的坑”，每次AI产出不达标，就记录一条：问题是什么、根因是什么、以后怎么防。

4.4 熵控制（持续垃圾回收）

这是驾驭工程的”维护机制”，对抗系统腐化。

AI生成的代码会积累技术债务，但方式与人类不同。AI会复现代码库中已存在的模式——包括那些不够理想的模式。随着时间推移，小问题会累积成系统性的混乱。

最终方案是：定期运行“清理智能体”，自动扫描过时文档、架构违规、不一致的代码模式，并主动发起修复。

类比理解：这像是城市的垃圾回收系统。你不能指望市民永远不产生垃圾，但你可以建立定期、可靠的清理机制。

PM视角：技术债务的管理逻辑变了。过去主要来自”人赶工期走捷径”，现在还要考虑”AI重复不良模式导致的累积偏移”。需要和工程团队建立新的债务识别和清理节奏。

明天就能做的一件事：和工程leader聊一次，问他”AI生成的代码里，你最常手动修正的问题是什么？”——这些就是你的熵控制优先级。

五、产品经理的四个角色转变

驾驭工程不只是工程团队的事。当开发范式发生根本转变，产品经理的角色定位也必须随之调整。

5.1 从”需求翻译者”到”执行环境设计者”

传统上，产品经理把业务需求翻译成工程师能理解的PRD。在驾驭工程范式下，PRD可能直接被AI读取并执行。这意味着：

• 需求的结构化程度直接影响AI执行质量
• 验收标准必须机器可读：“用户体验要好”对AI没有意义；“页面加载小于2秒，关键操作不超过3步”才有效
• 边界条件要显式定义，AI不会自动脑补

明天就能做的一件事：用”如果…那么…”句式重写你最近一个需求的边界条件，把隐含假设全部显式化。

5.2 从”验收把关者”到”反馈回路设计者”

AI的产出速度远超人工验收速度，逐个检查会成为瓶颈。新的模式是：设计反馈回路，让验收尽可能自动化。

• 定义可自动验证的质量标准
• 把验收知识编码成规则，而不是每次手动发现
• 分层验收：机器验收基础质量，人工验收需要判断力的部分

明天就能做的一件事：列出你上个月验收时发现的所有问题，标记哪些是”规则可检查的”——这些就是你应该自动化的部分。

5.3 从”资源协调者”到”Harness成熟度评估者”

项目效率不再只取决于人头，而是取决于Harness的成熟度。

同样的功能需求：在一个harness成熟的代码库，AI可能一天完成；在一个没有harness的代码库，可能需要先花两周搭建基础设施。

产品经理需要能评估团队的harness覆盖程度，以及harness投资的ROI。

明天就能做的一件事：下次排期时，多问一句”如果我们先花3天完善harness，后面的需求能省多少时间？”

5.4 从”功能定义者”到”可观测性规划者”

可观测性成为AI能否自主工作的前提条件。

如果AI看不到系统运行状态，它就只能盲写代码，无法验证效果。这意味着：监控和日志设计需要在产品规划阶段考虑，而不是上线后再补。

明天就能做的一件事：在你下一个需求文档里，加一个”可观测性要求”小节——AI需要看到什么数据来验证这个功能是否正常工作？

六、一个反直觉的判断

说到这里，我想给出一个可能让你不舒服的判断：

未来PM的核心竞争力，不是“会用AI”，而是“能设计让AI可靠工作的环境”。

这两件事的差距，比很多人以为的大得多。

“会用AI”意味着你能写出好的prompt，能让AI生成还不错的方案、还不错的代码。这是2024年的能力。

“设计让AI可靠工作的环境”意味着：你能定义结构化的需求、可量化的验收标准、可复用的质量规则、分层的验收机制、持续演进的反馈回路。你设计的不是一个需求，而是一个让AI能持续产出高质量工作的系统。

这就是为什么Harness Engineering对PM如此重要——它不是工程师的专属话题，它直接定义了PM的新价值边界。

七、现在可以做的三件事

立即行动：开始结构化记录产品决策

每次做出产品决策后，用简短格式记录：背景、选项、决定、原因。存放在团队知识库中。这是让AI能”学习”你们团队决策风格的基础。

短期规划：评估团队的”AI就绪度”

和工程团队一起回答这些问题：

• 我们有AGENTS.md或类似的AI指导文件吗？
• 架构约束是靠文档说明，还是有工具强制执行？
• AI能读取运行时的日志和监控数据吗？
• 验收标准有多少是可以自动化检查的？
• 当AI犯错时，我们有把教训编码成规则的机制吗？

长期转变：学会设计”反馈回路”

改变思维习惯：

旧思维

• AI出错了，修正这次，继续
• PRD写完交给开发就行
• 验收是一次性的事

新思维

• AI出错了，这类错误怎么防止？更新规则/工具/文档，确保不再发生
• PRD要能被AI直接读取和执行
• 验收标准要沉淀为可复用的自动化检查

最后

回到开头老张给我看的那个PR。

372个文件，8000行代码，一个下午。

后来我想明白了：让我不安的不是AI写得快，而是我意识到——如果我的PRD不够结构化、边界条件不够清晰、验收标准不够量化，那AI写得再快，返工的成本也会把效率优势吃掉。

AI的执行力已经不是瓶颈了。人类的表达精度，才是。

现在，打开你最近写的一份PRD，问自己三个问题：

1. 如果把这份PRD直接交给AI执行，它能做出来吗？还是会在第一步就开始猜？
2. 你的验收标准，有多少是可以写成自动化检查的？有多少只存在你脑子里？
3. 上一次AI产出不达标，你是只修了这一次，还是更新了规则确保下次不再犯？

如果三个答案都让你犹豫，那说明你已经知道下一步该做什么了。

参考资料

1. OpenAI – Harness Engineering： Leveraging Codex in an Agent-First World
2. Anthropic – Effective Harnesses for Long-Running Agents
3. Martin Fowler – Harness Engineering