# 驾驭 AI：AI 写代码很快，然后呢？

AI Harness Engineering 系列 · 序章 · 王海涛（公众号：Jia言Yi行 · GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

![00-intro.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/131a0545d1bbd57b1d1d314614aa6f01.jpg)

1968 年，北约在德国加米施开了一次会。会上诞生了一个词——软件危机。

那是软件工程的元年。一群最聪明的程序员聚在一起，第一次承认了一件当时没人敢说破的事：写代码这件事，正在超出人脑的管理能力。项目延期、预算超支、质量失控，成了行业常态，而不是例外。

半个多世纪过去，这场危机被工程化手段驯服了大半——结构化编程、面向对象、测试驱动、持续集成，一套一套的纪律补上来，把混乱驯服成了秩序。行业由此确立了一套共识：质量、速度、成本之间互相制约，没有免费的倾斜，只有认清约束后的权衡。互联网产品押注体验，工控软件押注交付稳定，资源流程类软件押注对变更的及时响应，各有侧重，但没有一个选择会放弃速度。于是出现了两条主流的省时哲学：一条用详细设计减少返工来赢时间（瀑布），一条用快速迭代抢即时反馈来赢时间（敏捷）。

当需求管理（做什么）、方法论（怎么做）、架构（如何收敛边界）、以及一支能扛事的工程团队（如何实现）被有条不紊地铺开时，我们一度以为，软件危机已经被驯服了。

然后 AI 大模型（LLM）和 AI 智能体（Agent）来了。

这一次，认知彻底反转：代码不再写得不够快，而是写得太快了——快到我们根本来不及理解它、信任它、维护它。软件危机回来了，只是这次要驯服的不再是人的代码，而是 AI 的代码——而驯服它，需要一副挽具。

---

## 一、速度背面：理解、信任与维护

![01-speed.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/8b56b8887fd6f4d59928dec85496c8c4.jpg)

过去一年，几乎每个软件工程师都体验过那种"被速度吓到"的瞬间：你给 AI 一句话，它几十秒吐出一个完整功能模块，逻辑通顺、注释齐全、连测试都写好了。

然后问题就来了。你盯着这段代码，心里开始打鼓：它为什么这么设计？它跟隔壁模块的约定一致吗？它处理边界条件了吗？它会不会在某个深夜的某个事务上，静默地崩掉？

AI Coding 用得越多，我越觉得：对 AI 原生的软件管理，与其说是个技术问题，不如说是个管理问题。当文件架构下堆满了 AI 生成的代码文件，过去的"一行行敲出来的踏实"不见了，取而代之的是一种很难定义的情绪——看着满屏 code，心里发虚：这些代码，真的都有用吗？

德鲁克有句话说得很刻薄，我想在这里原句引用：

"把根本不该做的事情高效地做完，是最无用的事。"

AI 正在用极高的效率，帮我们把大量"根本不该写出来的代码"写出来。它把"写"加速到了极致，却把"理解、信任、维护"的负担，原封不动地——甚至加倍地——甩回给了人。

我在过去半年里用 AI 编码交付了几个项目。第一套，现在回头看更像是尝试和学习的，是将一套内部智能运维系统进行 AI 升级——代号 aITMS。原 ITMS 已在生产使用，但没有像 OpenClaw 一样让用户感受到聪明，把类似 OpenClaw 的交互功能内化，是这个项目的初衷。

五个星期的业余时间（累积大概十天），我用 AI Agent（OpenClaw）生成了 18 个 Controller、35 个 Request DTO、38 个 Response DTO、1557 行双语国际化配置、39 个架构决策记录，以及遍布整个项目数百个文件的代码修改。现在看这个成绩并不夸张，但在 2026 年初，这个工作效率是惊人的，甚至带一点"惊悚"效果。

数字很漂亮，但这些 AI Coding 的成绩之所以没有变成灾难，靠的不是 AI 大模型和 AI Agent 有多强，而是我在项目中不断试错、在它背后搭起的一套约束体系。

先交代一句，避免误会：aITMS 是最初的方法论载体和实践项目，后面几乎所有方法论（约束金字塔、门禁、成熟度模型）的演进起点都从这里开始。但判断它们"能不能算方法论"，标准不只是"在 aITMS 里这么用有效"，而是"换个项目还能不能立住"。这一层关系，我在第五节会划一条明确的线。

---

## 二、范式转换：从"编程"到"驯服"

![02-paradigm.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/1351b3f88559480768ab9c6894b46c05.jpg)

传统软件工程，从第一天起就默认一个前提：代码是人写的。

这个前提决定了我们所有质量手段的形状——编译检查、Code Review、测试覆盖，本质都是在"人产出代码"之后，去兜住人的错误。这背后有一套心照不宣的管理逻辑：你信任工程师写代码的过程，但你不信任他写出的每一行——所以你用流程和工具去兜底。

但当代码的产出者变成了 AI 大模型和 AI Agent，这个前提碎了，连带着那套管理逻辑也跟着失灵。

| 维度 | 传统工程 | AI Harness Engineering |
|------|---------|----------------------|
| 代码产出者 | 人 | AI 大模型 + AI Agent（人转为监督者） |
| 产出速度 | 中速 | 高速，AI 并行生成 |
| 主要风险 | 逻辑错误 | 幻觉 + 不一致 + 架构漂移 |
| 约束手段 | 编译检查 + Review | 文件体系约束 + 门禁 + 契约 |
| 质量保障 | 测试覆盖 | 约束覆盖 + 契约验证 + 可观测 |
| 管理重心 | 管人怎么写代码 | 管 AI 怎么被约束 |

关键的变化不在"速度"，而在一个更根本的地方：管理重心从"管人怎么写"变成了"管 AI 怎么约束"。回看开篇的四根支柱——需求管理、方法论、架构、工程团队——在 AI 时代，前三根的内涵全变了：需求管理从"跟人沟通"变成"写进文件让 AI 读"，方法论从"人怎么写代码"变成"怎么约束 AI 写代码"，架构从"人脑里的设计"变成"文件里的边界"。这不是技术细节的调整，而是整个软件工程管理范式的位移。

接受 AI Coding，对非程序员是一种平权——把软件的著作能力普及化。但我们看到，优秀的软件工程师反而是 AI Coding 最积极的使用者。如果 AI 是更可信、更有效率的方式，为什么专业的工程师还要约束和管理它？

也许是因为，AI 大模型生成 token 的方式在本质上是一种概率运算；也许是因为，它生成的代码还难以突破记忆系统（上下文长度）的限制。当下的 AI Coding 仍不完美，而且因为涉及基模底层逻辑，短期内算法突破和工程突破都不太容易。这就导致 AI Coding 在逻辑上可行，却在细节上藏着更隐蔽的缺陷：

1. 数据幻觉——它"觉得"某字段该叫这名，于是就叫了，跟数据库真名对不上；
2. 概念参差——同一个概念，这份代码里叫 A，那份叫 B，第 N 次生成又变 C；
3. 架构漂移——每次生成"顺手"引入一点偏差，三十次之后，代码库已偏离你的设计，而你浑然不觉。

这三种问题，没有一种是传统意义上的"代码质量"问题，它们全是管理失控——你没管住它的数据对齐，没管住它的概念一致性，没管住它的随性发挥，结果自然就偏离了预期。

软件之所以是个工程问题：方向要动态把握，这是管理问题；精度要严格度量，这是"数学"问题。几百行代码、几个静态页面的展示，和几十万乃至几百万行代码是完全不一样的——其难度差异，类似于在沙滩上用塑料铲子挖个坑，和用盾构机开山钻海。

回到软件工程，我能不能用老办法解决新问题呢？比如 Code Review 能不能防住？

如果靠人来 Review，只能防住一部分。AI 生成的速度，已经稳定超过了人类 review 的速度——你 review 一份的时间，AI 能再生成三份。用人力追 AI 的速度，是必输的消耗战，就像用人工审核去对抗流水线：不是审核员不努力，是产线的速度根本不给你审核的窗口。

所以我不追了。我把防线前移——在 AI 生成之前，就用约束体系把它的行为空间圈定好。这才是这个系列真正想讲的事：

**当你不能靠"看得够快"守住质量，你就必须靠"事先圈好边界"守住质量。**

---

## 三、Harness 两面：驾驭与约束

![03-harness.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/8aec44de4fe1e5d508015110bb29b730.jpg)

防线前移之后，需要一件趁手的家伙什——能既圈住 AI 的行为空间，又不勒伤它的生产力。现在有个流行的叫法，把它叫做 AI Harness。这其中的 Harness，原意是"挽具"，套在马匹身上的那套绳索和配件。

人类发展出一套成熟而高效的挽具，是为了掌握远超自身能力的马匹的机动性和速度。这个过程，是一个试验和调教的长期演化，从摸爬滚打到趋于稳定，大概持续了六千年。从驯化第一匹野马，到摸索出既能驾驭力量、又不勒伤牲口的结构，中间凝结的是无数代人试错的智慧。而这个"试错"的过程，正是现在的软件工程师们为 AI 大模型打磨挽具的路径——每一次约束调整，都是一次"这个管不管用"的产品实验。

如同挽具，AI Harness 也从两个方向满足我们对使用 AI 的需求：

- 驾驭：把力量导向，让 AI 在正确或相对准确的方向上"拉车"；
- 约束：管理限制它，不能乱跑、不能"尥蹶子"。

这种限制真的好吗？会不会使 AI 丧失某些原生能力？AI 的力量真实而巨大，不给它套上挽具，它就会在你的代码库里横冲直撞，留下一地烂摊子。第一节里说的那种自我怀疑——看着满屏代码文件，不知道哪些有用、哪些是 AI 的幻觉——本质上就是没套挽具的后果。骑野马也许更有意思，但也伴随着更难以捉摸的个性和不可预知的目的地带来的风险。

AI Harness Engineering，就是研究怎么给 AI 套上这套挽具的工程方法论。它不是某个工具，也不是某条 prompt 技巧，而是一整套文件体系 + 门禁 + 契约 + 成熟度模型的组合拳；它更有可能是一个新的软件工程方法论的开端，是一套未来某天能帮我们解决 AI 时代软件危机的方法论体系。

整套方法论的核心命题，落实到 AI Coding 上是这样一句话：

**当代码由 AI 生成时，人不再通过"写代码"来控制质量，而是通过"构建约束体系"来引导 AI 的行为空间。换句话说，写得快不重要，管得住才是真的。**

---

## 四、规约体系：一座约束金字塔

![04-pyramid.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/e2eda8b0815cab5ed625847d0193ea2f.jpg)

AI Harness Engineering 常被翻译成"驾驭工程"，我觉得这更像是一个愿景。当下比较贴切地用在项目里的约束，是通过一系列文件的规定来实现的——系列文章中多次提到的规约（文件），就是实践方法论的产物。规约体系的核心是一个结构，约束金字塔：

```
战略层  ── README.md（1 个文件：边界 / 命名 / 拓扑）
   ↕
架构层  ── ADR 体系（39 个文件：每个重大决策一个记录）
   ↕
契约层  ── Runbook + Skill（可复制执行的步骤 + 可复用工作流）
   ↕
门禁层  ── Pre-submit 脚本（提交前自动检查）
   ↕
实现层  ── 受约束的 AI 生成代码（N 个文件）
```

战略、架构、契约、门禁和实现，是层次结构的名称。至于文件体系，也许不同的 Agent 里会被叫做宪章、PRD、架构文档、方法论文档、脚本文档和代码主体等多种组合，这些名称不用深究，把更多精力放在理解规约层次上，投入产出比更高。

战略层解决要做什么和是什么的问题，架构层解决边界问题，契约层解决持久化和稳定性问题，门禁层提供质量保障体系，实现层实现战略层、架构层和契约层的目标并接受门禁层的检阅。

这五层不是凭空想出来的，是踩出来的。在 aITMS 项目里，早期 README 只写了两行概括，AI 生成的代码风格每周变一次；后来 README 写到六百多行，再通过索引其他层文件，把模块边界、命名、分层规矩一条条定死，风格漂移几乎消失。金字塔的意义，不是建立一个漂亮的文档结构，而是给 AI 的无序发挥建立一座围栏——围栏立起来了，风格才稳定下来。

这套约束体系有一个"终点"。它不是为了把 AI 管死，而是为了走到一个更远的地方——让系统自己学会变好。这个系列里有一个主角会反复出现：一个服务跨项目编码能力共享的本地知识库副脑，叫 derekinside。它有知识翼和实体节点，超越静态的知识库，是一个会自己记忆、自己检索、自己进化的 AI Native 系统。在第九篇里，我会揭开它的内在机制，让你看到它记忆什么、怎么检索、又靠什么自我进化。

---

## 五、系列地图：十二篇正文

![05-series-map.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/45c515217ec8a5ae43bdd199f4909805.jpg)

加上这篇序章，整套系列一共十三篇。正文十二篇，每篇同一个配方：方法论 + 项目实证 + 一个可复制的清单。

1. 约束金字塔：文件即架构——五层规约全景，为什么"文件"才是 AI 时代的蓝图
2. 战略层：宪章与蓝图——要做什么、是什么；项目宪章与 AI 的行为底线
3. 架构层：决策即边界——为什么"为什么"必须落成文件；决策如何撑起一致性
4. 契约层：从规格到代码——Spec 契约、数据契约与可复制执行的规约
5. 门禁层：让检查先于代码——唯一自动执行的约束层，从五道到十五道的演进
6. 实现层：幂等与退化——接口幂等、降级契约，AI 挂了业务不停
7. 执行前宣言：先立规约，再写代码——Manifest 六问与文件创建的顺序
8. 多 Agent 编排：从单点到分工——swarm 决策与多模型共识
9. 记忆与知识：让系统自己进化——一个会记忆、会检索、会成长的副脑究竟怎么运作
10. 调试与归因：冰山之下——冰山 PDCA 与假设驱动调试
11. 测试自成长：让回归自己跑——全量回归、失败模式匹配与自成长引擎
12. 成熟度模型：自诊断与演进——你的项目到哪一步，约束体系如何度量

这套方法论的经验，来自我手头四个项目：一个订单（交易）系统（TradeOMS）、一个编码方法论框架（derekcoding-framework）、一个量化研究体系（SmartQuant）、和一个本地知识库副脑（derekinside）。前面预览的约束金字塔、后面会展开的成熟度模型，是我在实战中提炼出来的——它们是深度案例，是实施模板，也是对这套方法论自己的思考。完善空间一定存在，拿出来，仅为同侪们继续向深处思考，抛砖引玉。

---

## 六、自检清单：五个第一天问题

![06-checklist.jpg](https://developer.qcloudimg.com/http-save/yehe-11918656/6db5830fa0f2cc67d28bd21ecdcdf19a.jpg)

一个可以立刻动手的检查清单。如果你的项目正在用 AI 编码，逐条对照：

- [ ] 有没有一个定义了模块边界和命名规范的 README？（不是"简介"，而是"AI 生成前必读的蓝图"）
- [ ] 架构决策写下来了吗，还是只存在于聊天记录里、随时被冲走？
- [ ] 有没有提交前自动检查的脚本，还是全靠手动 review？
- [ ] AI 生成接口，考虑过同一请求被重复提交怎么办吗？
- [ ] 有哪些环节硬依赖 AI 的即时响应？如果它今晚不响应，有没有降级或手动兜底？

五个问题里，你有 1-2 个回答不了或者不那么确认，那这个系列就很适合你。

给 AI 套上挽具，不是为了勒住它的力量，而是为了让它的力量拉向你想要的方向。**管得住的快，才是真的快。** 下一篇，从第一块基石讲起：约束金字塔：文件即架构——为什么"文件"才是 AI 时代真正的蓝图。

---

*（《驾驭 AI · AI Harness Engineering》系列·序章，首发腾讯云开发者社区。）*

AI Harness Engineering 系列 · 序章 · 王海涛（公众号：Jia言Yi行 · GitHub：derekwang85 · 腾讯云 TVP / 架构师名人堂）

驾驭 AI · AI Harness Engineering · 序章

AI 写代码比人审核更快，五十年前的软件危机以新形态回归。作者从真实项目提炼出"约束金字塔"体系把 AI 的行为空间事先圈定，从"看得够快"前移到"事先圈好边界"。核心命题：当代码由 AI 生成，人不再靠"写代码"而靠"构建约束体系"控制质量——写得快不重要，管得住才是真得快。

 CTO

人工智能

编程语言

架构设计

AI生成代码速度惊人，但理解、信任与维护的负担却加倍甩回给人。AI Harness Engineering提出全新管理范式：通过约束金字塔（战略、架构、契约、门禁、实现）构建文件体系，在AI生成前圈定行为边界，解决数据幻觉与架构漂移。掌握"管得住才是真的快"的AI驾驭方法论，附五个可自检问题。

驾驭工程

软件工程

代码解释

数据库

智能体

OpenClaw

GitHub

Agent

2026上云采购 | AI焕新·智启新局

llmsgw

lexiang

coding

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

驾驭 AI · AI Harness Engineering · 序章-腾讯云开发者社区-腾讯云

驾驭 AI · AI Harness Engineering · 序章

驾驭 AI · AI Harness Engineering · 序章

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐