EA之家——最专业的企业架构知识库;最全面的数字化转型案例库。

AI时代的软件范式变革,Harness Engineering(驾驭工程)带来的启示,附北大研究报告105页

附件为105页PPT

2026 年 2 月 11 日,OpenAI 在工程博客发布了一篇文章:Harness engineering: leveraging Codex in an agent-first world(原文链接见文末参考引用)

文章提出了一个值得软件工程领域认真思考的问题:

“What changes when a software engineering team’s primary job is no longer to write code, but to design environments, specify intent, and build feedback loops that allow Codex agents to do reliable work.”— OpenAI Engineering Blog, Harness Engineering

简单翻译就是:

当软件工程团队的主要工作不再是写代码,而是设计环境、表达意图,并构建反馈循环,让 AI 智能体能够可靠工作时,软件工程会发生什么变化。

在这篇文章中,OpenAI 记录了一个实际工程实验:一个由 3–7 名工程师组成的团队,在 5 个月时间内,使用 Codex + GPT-5 构建了一款真实的软件产品。整个项目最终形成了 约 100 万行代码的代码库,而在开发过程中,人类工程师 没有手写任何一行代码

在这样的开发模式下,AI 负责生成和修改代码,工程师主要负责 定义任务、设计系统结构,以及监督整个工程过程。团队在文章中提到,这种方式的开发效率 大约是传统开发方式的 10 倍

但这项实验真正重要的地方,并不是“AI 会写代码”。

真正重要的是,它提出了一种新的软件工程方式:

Harness Engineering(驾驭工程)。

一、软件工程的生产方式正在改变

如果回看软件行业的发展历史,会发现软件工程一直在变化。

最早的软件开发几乎完全依赖程序员个人能力。程序员直接面对机器,写算法、写逻辑、写程序结构。

那时候的软件生产力基本等于:写代码的能力。

后来软件规模越来越大,复杂度远远超过个人能力,于是软件工程进入工程化阶段。模块化设计、分层架构、自动测试、CI/CD、DevOps 等方法逐渐成熟。

开发效率不再依赖某个程序员写得多快,而依赖:系统架构和工程组织。

而今天,大模型又带来了新的变化。AI 编程工具可以在极短时间内生成大量代码。

当代码生成速度远远超过人工编码时,软件工程的瓶颈自然会发生转移。

代码本身不再稀缺。真正稀缺的开始变成:系统架构。

二、Harness Engineering 的真正含义:驾驭智能体的工程

“Harness” 在英语中的意思是 马具

它不是动力本身,但它决定了动力能否被稳定地使用。

OpenAI 用这个词,其实是在表达一个很直观的概念:

AI 像一匹很快的马,但需要一套缰绳才能被驾驭。

所以 Harness Engineering 的重点不是“生成代码”,而是:

构建一套让智能体能够稳定工作的工程系统。

在这种工程模式下,代码只是结果。真正被设计的是:智能体读什么信息、智能体可以调用哪些工具、智能体必须遵守哪些规则、智能体犯错后如何被发现、智能体偏离架构时如何被拉回、也就是说,软件工程的对象发生了变化。

过去工程师直接组织代码。现在工程师越来越多地在组织 生成代码的条件

Harness Engineering 本质上就是:

让一个不完全确定的系统,持续产生可控结果。

三、AI开发不再是线性流程

传统软件开发流程大致是线性的:需求 → 编码 → 测试 → 发布

但当 AI 参与开发之后,流程更像一个持续运行的循环。

任务被拆解之后,AI 生成代码;系统运行测试或调用工具;结果被评估;如果发现问题,系统会继续修正并再次生成。

整个过程更像一个工程控制回路,而不是一次性的生产流程。

这种模式下,人类工程师的角色开始变化。

工程师不再是每一行代码的作者,而更像是一个系统的设计者。

四、程序员角色的变化

在传统开发模式中,程序员的主要工作是实现功能。写代码、修 Bug、实现需求,是日常工作的核心。

但当代码生成成本迅速下降之后,工程师的价值开始更多体现在系统层面。

问题拆解、架构设计、工程规则、系统稳定性,这些能力开始变得更加重要。

程序员的角色正在从 实现者 转向 系统设计者

AI 可以生成代码,但它并不会天然理解:模块之间应该如何依赖、哪些边界不能被打破,这些仍然需要人来决定。

五、真正改变和没有改变的东西

AI 的确正在改变软件工程,但这种变化并不像很多讨论中描述得那么彻底。

真正改变的是 编码方式

写代码这件事,正在越来越多地由机器完成。工程师可以把更多时间投入到系统设计、问题分析和架构决策上。

但软件工程中真正重要的能力,其实并没有改变。

理解需求、分析问题、设计系统结构、选择合适的技术路径,这些能力在 AI 出现之前就是核心能力,在 AI 时代依然如此。

如果工程师不理解系统原理,不理解架构约束,也不理解问题本身,那么无论代码是自己写的,还是 AI 生成的,最终都很难构建出可靠的系统。

从这个角度看,AI 更像是一种放大器。它可以放大效率,也会放大工程能力的差距。

对真正理解系统的人来说,AI 会让他们更强。对只依赖工具的人来说,AI 只会让问题出现得更快。

软件工程的很多东西在变化,但最核心的部分其实一直没有改变。

理解问题、设计系统、解决问题。

这些能力,过去是软件工程的核心,今天仍然是。

六、北京大学智能编程范式报告,105页PPT

1772981786-cfcd208495d565e
1772981790-cfcd208495d565e
1772981795-cfcd208495d565e
免责声明:解读章节属EA之家原创,享有内容版权。《案例》章节来源于各文库类平台,内容无法找到真正来源,如有标错或文章所使用的图片文字链接等涉及侵权,请尽快与我们联系处理,谢谢。
EA之家 » AI时代的软件范式变革,Harness Engineering(驾驭工程)带来的启示,附北大研究报告105页
升级VIP尊享更多特权立即升级