AI时代软件工程新范式
从编码效率，到交付效能。
摘要：AI Coding的演进不只是让写代码更快，而是重构了整个软件交付系统。 从Copliot的局部补全，到Oneshot的原型生成，再到Spec Coding的约束施工，最终走向Harness Engineering —— 人不再只是写需求，而是设计能让AI长程受控自治的运行机制。 关键变化在于：从“人盯着AI写”变成“AI在边界内自主推进”。
这两年，AI Coding很热，几乎每隔一段时间，就会有一轮新的讨论：coding agent能不能真正干活，模型的代码能力到底又提升了多少，程序员是不是要被替代了。同时也出现一些新的概念和热潮：Openclaw、MCP、Skill、Context、Harness Engineering。
那到底AI对软件行业有哪些影响，其实视角拉高一点，就会发现，并不是“写代码快了”，而是软件交付这件事情正在被重构。代码生成只是表象，背后更大的变化，是控制权、协作方式、交付节奏，甚至组织结构都在变化。
换句话说，AI Coding真正改变的，不只是程序员怎么写代码，而是软件团队怎么定义价值、怎么组织工作、怎么交付结果。
很多人讨论 AI Coding 时，只关心模型会不会写代码。但在真实工程里，决定 AI 能不能稳定产出的，往往不是代码生成能力，而是任务控制能力。
一、AI Coding的四个阶段
回头看这几年，AI Coding大致经历了四个阶段，对应了四种“人机协作粒度”：
| 阶段 | AI 角色 | 人的主要工作 |
|---|---|---|
| Copilot | 局部补全助手 | 写代码，AI 补片段 |
| Oneshot / Vibe Coding | 一次性交付者 | 描述目标，AI 生成整体 |
| Spec Coding | 受约束施工者 | 写清范围、边界、验收标准 |
| Harness Engineering | 长程自治系统 | 设计执行环境、上下文、验证、状态管理和停止条件 |
越往后，AI 的代码能力不是唯一重点，任务控制能力变得更重要。
1.1 Copilot：AI是局部增效
这个阶段里，AI 主要是代码补全工具。
它的典型价值是：
- 补全函数片段。
- 生成样板代码。
- 提示 API 用法。
- 降低重复劳动。
- 提升局部编码速度。
这个阶段的核心特征是：人仍然是主驾驶，AI 在局部帮助人写得更快。
1.2 Oneshot：AI一次性交付
也就是很多人说的yolo或vibe coding
这个阶段非常适合做demo、原型、小工具，或者生命周期很短的需求。
这个阶段的问题很明显：项目一旦开始变得复杂，需要持续迭代、要遵守很多约束、要和既有系统共存时，oneshot就会迅速碰到天花板。 不是做不出来，而是很难长期做对。
它很适合从0到1，但不适合从1到N。
1.3 Spec Coding：在约束内施工
随着项目复杂度上升，或者很多都是既有的历史系统。对这类项目，迭代是不能直说“我要什么”，还必须把范围、边界、约束、验收标准也说清楚。 于是人给AI的，不再只是prompt，而像是一份缩小版的PRD或者 implementation spec。AI按图施工。
Spec Coding 开始解决复杂系统中的对齐问题。AI 不只是看目标，还要理解：
- 不能动哪里。
- 应该怎么验收。
- 哪些接口必须兼容。
- 哪些既有行为不能改变。
- 哪些 tradeoff 不允许越界。
- 哪些测试必须通过。
很多复杂系统里使用 AI 失败，不是因为模型不会写代码，而是因为只告诉了 AI“我要什么”，没有告诉它边界在哪里、验收线是什么、哪些地方不能乱改。
因此，Spec Coding 本质上是从“愿望表达”进入“工程表达”。
1.4 Harness Engineering：长程受控自治
Spec Coding 仍然有局限。
Spec Coding 解决的是“AI 知不知道该怎么做”；Harness Engineering 解决的是“AI 能不能在长任务中持续正确地做”。
复杂任务的问题不再只是“AI 要不要照着 spec 做”，而是：
- AI 能不能在持续执行几个小时甚至更久的过程中不迷路。
- AI 能不能不乱改。
- AI 能不能减少无效追问，不频繁回来找人。
- AI 能不能在失败后恢复。
- AI 能不能知道什么时候继续、什么时候求助、什么时候停止。
Spec 当然很重要，但它只是 harness 的一部分。
Harness Engineering 强调的是为 AI 的长程执行设计一套受控环境：
- 如何设定目标。
- 如何限制行为。
- 如何安排执行路径。
- 如何选择上下文。
- 如何管理中间状态。
- 如何做验证。
- 如何处理失败和不确定性。
- 如何决定何时继续。
- 如何决定何时求助。
- 如何决定何时停止。
这个阶段里，人不是简单“提需求”，而是在设计一个让 AI 能长期执行而不失控的工作系统。
它关注的是：目标管理、权限管理、上下文管理、工具管理、计划管理、状态管理、验证管理、回滚和恢复策略、人类介入机制。
这已经不是单纯的 prompt engineering，也不只是 spec writing，而是 execution system design。
四阶段不是线性替代
这四个阶段不是后一个淘汰前一个，而是适用于不同任务。
| 任务类型 | 更适合的模式 |
|---|---|
| 写一个函数 | Copilot |
| 做一个 demo | Oneshot |
| 改一个复杂业务模块 | Spec Coding |
| 大规模迁移、重构、测试修复、跨仓库改造 | Harness Engineering |
因此，它们更像是四种协作模式，而不是简单的年代划分。
AI Coding 的演进，不只是模型从弱到强，而是人类对 AI 的控制方式从“补全代码”升级为“设计执行系统”。
关于研发产品形态
以agent为中心。 agent作为数字员工， 尽量较少 点击交互、 需要人手工点击确认的。
一个cli、web-ui 。 与 桌面应用的 区别 和未来的比较。
关于工具的比较
效果的评估
效果到底能提升多少呢？
openclaw到底有没有用？ 什么样的架构用来做什么？