让 AI 在企业级应用里真正跑稳：Harness Engineering 的五大支柱

如果你在企业级项目里让 AI 写过代码，一定有过这样的时刻——你惊叹于它的速度，同时又在夜里被它写出来的假设、错位、幻觉折腾得头疼。

这些不是 AI 变笨了。是我们没给它一个能跑稳的环境。Harness 就是这个环境。

引子：为什么需要 Harness

如果你在企业级项目里让 AI 写过代码，可能有过这样的时刻——

第一次你惊叹于 AI 的速度：一段需求描述丢进去，它几分钟就"写完"了。可当你打开代码仔细看，发现它写了 200 行，其中一半是它自动补齐的假设。你需要花更多时间去揪它错在哪。

单元测试全过了，你以为一切妥当，结果前端调过来接口报错——AI 悄悄改了参数命名，没人告诉调用方。

昨天你在一个会话里跟 AI 拍板了一件事，第二天开新会话，它又原封不动地问一遍。

这些问题不是 AI 变笨了。是我们没给它一个能跑稳的环境。

Harness 就是这个环境。

今年 AI 领域冒出了很多新概念——Prompt Engineering、Context Engineering、Agentic Coding……但真正让 AI 从"能演示"走到"敢在企业项目里放心用"这一步的，是 Harness Engineering。

这篇文章想讲清楚三件事：

1. Harness 到底是什么，为什么它必须存在
2. 它的骨架——五大支柱 + 一个责任锚点——每一根解决什么问题
3. 我在自己主导的项目里，怎么把这套方法论落到实处

如果你手里有一个想让 AI 参与、但又不放心让它自由发挥的企业项目，希望读完这篇能给你一些实操层面的抓手。

一、什么是 Harness

1.1 vibe coding 和企业级，不是同一个物种

先看一个画面。

网上现在很流行 vibe coding 的故事：一个想法、几小时之内，AI 独立做出一个网站、一款小游戏、甚至一个能跑通的完整应用。这些视频看起来非常震撼。

大模型写代码的能力确实惊人。vibe coding 的产物流程走得通、视觉也不差，看起来就是一个"能用的产品"。

但"看起来能用"和"真正能用"，中间隔着一整套企业级要求。

我们可以从六个维度拉一张对照表，挑最能看出差距的三条：

看完对照表，问题就清楚了。它不是"AI 能不能写代码"的问题——AI 完全能写。真正的问题是：vibe coding 能不能撑起企业级应用？

答案是不能。

我们需要的不是"更聪明的 AI"，而是"更可控的工程环境"。

在企业级应用里，AI 的能力必须被工程化地驾驭。这套驾驭系统，就是 Harness。

AI 已经让写代码这件事快了 10 倍。所以真正卡住我们的不再是"代码能不能写快"，而是——我们如何协作、如何验证、如何沉淀。

1.2 一个更精确的定义

如果要用一个等式定义 Harness，我最喜欢这个：

Harness = Agent − Model

Agent 是我们平时说的"AI 代理"。它由两部分组成：

• Model——那个负责生成、理解、推理的大模型
• 剩下的一切——上下文管理、工作流约束、工具接入、协作机制、审查流程……

减掉大模型，剩下所有工程化部分，就是 Harness。

再简化一层，可以概括成五类工程化能力——上下文、约束、验证、协作、治理——围着大模型转。

平时你在项目里可能已经用过它们的一部分：

• AGENTS.md 或 CLAUDE.md——把项目规则注入到 Agent
• MCP / Skill——让 Agent 能调用外部工具和技能
• 工具权限白名单——哪些 Agent 能调用哪些工具
• Plan / Workflow——任务节奏和边界
• 审查机制——让 AI 出的东西必须过审

它们表面上是不同的东西，但做的是同一件事：控制、约束、引导大模型，让它在真实工程里做对的事。

所以，Harness 不是某个具体工具，也不是一段咒语一样的提示词——它是一整套让 AI 在你项目里跑得稳的环境和约束。

1.3 从 Prompt 到 Context 到 Harness

Harness 不是凭空冒出来的。它是 AI 参与软件开发这几年里，一步步演进出来的必然结果。

• 最早，我们把代码贴进 chatbot，把回答复制回项目。那个时代的核心话题叫提示词工程——重点是怎么把问题说清楚
• 后来，AI 长出了"眼睛"和"手"——它能直接读代码、改文件、跑命令。但一次会话不够用了，于是有了上下文工程——跨会话的记忆怎么管，项目的隐性知识怎么注入
• 到了今天，AI 开始持续参与一个真实项目。任务怎么拆、多个 Agent 怎么协作、什么时候必须停下来等人确认——这些都不再是模型本身能解决的问题。于是 Harness 出现了。它面向的不是单次对话，而是整个工程系统

这三者不是取代关系，是层层递进：

• Context 没有扔掉 Prompt——它把 Prompt 装进了更稳定的上下文管理
• Harness 也没有扔掉 Context——它把 Context 装进了更大的工程系统

1.4 为什么叫"Harness"

回到这个词本身。Harness 的原意是「马具」。

想象一匹强壮的马。如果没有缰绳，它可以是灾难——方向错了，跑得越快偏得越远；力量越大，失控时破坏越大。

但人类历史上，我们从不通过"否定马的力量"来使用马。我们的做法是——通过马具，把马的力量连接到明确的方向、边界、任务上。

AI 也一样。今天的大模型已经具备很强的生成、理解、推理能力。但如果没有 Harness，它会在错误方向上快速产出大量看起来合理的代码——这才是最危险的。

马具把马的力量连接到方向；Harness 把 AI 的能力连接到工程——稳定、可控、可验证。

那么 Harness 在企业项目里具体要管什么？我把它抽象成 五大支柱 + 一个责任锚点。

二、五大支柱 + 一个责任锚点

2.1 Workflow：AI 参与工程的骨架

Workflow 是五大支柱里唯一必须最先建立的一根。它决定 AI 在你的项目里能不能有章法地推进——计划怎么开、任务怎么拆、什么时候必须停下等人确认。

它是其他四根支柱的前提。 没有 Workflow，其他支柱推不动。

2.1.1 模糊需求会怎么杀死项目

模糊需求直接进开发，结果可想而知——AI 开始猜测、臆想、脑补。它生成的东西表面上都对，可它并不是你想要的。等到你发现问题时，错误已经被大量代码包装起来，修复成本呈指数级爆炸。

那怎么解决？

软件工程几十年的答案是：让需求在写代码之前，先想清楚、拆明白、定边界。

Workflow 做的事情，其实就是把这套已经存在几十年的节奏，重新应用到 AI Agent 身上。它把工作流程拆成 7 步——前 3 步"想清楚"、后 4 步"做 + 验"。

前 3 步最容易被跳过——一旦跳过，错误就被放大成代码。

Workflow 不是让 Agent 慢下来，而是让它先想清楚，再加速。

2.1.2 一个真实的例子：throttle 限流

我们组之前做过一个供应商限流模块的优化，正好是个典型场景。

在没有 Workflow 之前，Agent 拿到"优化限流配置"这个需求，会直接进入实现——99% 的 AI 会看到代码里那一行 sleep，一秒钟就把它当成 bug 删掉。

但这一行 sleep 不是 bug。它是压测时故意让系统休眠几秒，模拟系统在供应商真出问题时的应急表现。 类似的隐含规则，在这个模块里还有好几处——AI 没有上下文，纯靠猜就一定踩坑。

加入 Workflow 之后，Agent 会先进入"问题分析"阶段，问一句：

"这一行故意休眠几秒，是 bug 还是设计？"

——而不是直接把它当 bug 删掉。

Workflow 真正的价值，不在于流程仪式本身，而在于——它逼 AI 在该问的地方停下来问，而不是靠猜。

2.1.3 三层结构：Plan / Story / Status

那 Workflow 具体长什么样？拆开来看，它是三层结构——Plan、Story、Status。

Plan 是 Workflow 里最大的工作单位。它把一个长期目标圈出来，给它一个明确的边界、状态和可追踪的进度。

Story 是 Plan 里的一个具体任务。它听起来很像传统敏捷开发里的 Story，但有两个关键差异：

1. 不按人天度量——AI Agent 不按人天干活，用人天估时对它没意义

2. 必须满足 3 个硬指标：

   • 可执行——AI 拿到之后能直接开工
   • 可审查——审查者看代码能判断有没有偏
   • 可验证——跑测试能确认是不是真的完成了

Status 记录 Plan 和 Story 处在 Workflow 的哪个阶段。5 个态流转——待办 / 分析 / 实现 / 审查 / 完成。每一个态都不是摆设的标签，而是让人和 Agent 对齐"现在到哪了"的锚点。

这里有两个关键设计特别重要：

• 状态可以倒着走、可以停——发现走偏了就退回上一态，被卡住了就暂停
• Status 不只看当下，还要有历史——当前 Status 回答"现在在哪里"，历史回答"怎么走到这里"

2.1.4 一个真实案例：优惠券能力扩展

我们做过一个"优惠券能力扩展"的 Plan。它被拆成 5 个独立的 Story，5 个全部完成 Plan 才算完成。

重点看其中的 Story ②——"重匹配上限改可配置"。表面上看只是一个具体配置项的调整，可它在分析阶段被退回了 2 次：

• 第一次退回"问产品业务收益"：问产品——业务上要解决什么、为什么定这个数
• 第二次退回"问产品配置粒度"：问粒度——按航司配还是按订单配

最终才进开发——定下来按订单类型配。

关键在于——如果没有 Status History，这两次退回的判断过程就消失了。你只会看到一个最终结果，看不到过程中的思考、反复和取舍。

真正该留下来的不是状态，是状态是怎么走过来的——团队能追溯，问题能复盘。

2.1.5 Human Gate：权限和责任必须对等

再回到刚才的 Story ②。想象一下这个场景：状态走到"审查"阶段，测试 Agent 跑完了所有 case，全过。

现在——可以按"完工"按钮了吗？

本能的反应是：不可以。

因为这个"完工"按钮不是技术按钮，是责任按钮——人按下去，就等于替系统扛责任。这就是 Human Gate 的核心。

一个成熟的 Workflow 里，必须有两道必须由人守的门：

• 方向门——从分析到实现的阶段，人要确认问题真的被理解清楚了
• 质量门——从审查到完成的阶段，人要确认结果真的可以接受

刚才那个"完工"判断，就是质量门。

而背后的原则很简单：权限和职责必须对等——谁扛责任，谁拍板。

Agent 可以帮你准备材料，可以给你结论建议，但它不能替你完成最终授权。

2.2 Spec：分水岭

如果 Workflow 决定了 AI 有没有节奏，那 Spec 决定了 AI 有没有方向。

我把 Spec 称为分水岭。理由是——这一步做对了，后面 90% 的问题都不会发生；这一步做错了，后面 90% 的努力都在错方向上加速。

Workflow 和 Spec 一句话区分：Workflow 管结构，Spec 管内容。

2.2.1 什么才算真正的 Spec

我先澄清一个常见误解——Spec 不是一份写给人看的说明文字。

拿"用户登录功能"举个例子。

一份只是说明文字的东西大概长这样：

"增加用户登录功能。包括手机号、邮箱、第三方 OAuth。"

写完之后——就没有然后了。它描述了"要做什么"，但缺三样东西：具体行为、边界数值、明确不做什么。

而一份真正的 Spec 应该是这样：

"手机号登录：60 秒只能发 1 次、5 次失败锁 30 分钟。OAuth：仅支持企微和同程 OA。不做：账号合并、免密时长。"

短短几行，三样东西都有了：具体行为、边界数值、明确不做。

以 "60 秒只能发 1 次" 为例——研发要实现 60s 限频、审查要查代码是不是按 60s、测试要测连发 2 次必失败。

这就是真 Spec 的力量——一份 Spec 同时是开发指南、审查依据、验证标准，一句话撑起 3 种工作。

2.2.2 Spec-Driven Development 的三条纪律

有一条软件工程铁律：错误每往后走一步，修复代价指数级上升。

在传统开发里，分析阶段改一个错误只要 1 倍成本，到上线后改就变成 1000 倍。AI 的加入把这个差距再放大了 10 倍——因为 AI 会顺着一个错误的方向，非常快地产出大量代码。

Spec 没写清楚就开干，等于踩着油门往错方向冲。所以 Spec 必须前置——这就是 SDD（Spec-Driven Development）。

SDD 有三条铁律，每一条都不可少：

1. 没 Spec 不许写代码——所有代码必须能回到 Spec 解释。否则 Agent 顺手写一堆代码，没人知道它为什么这么写
2. Spec 是事实源——冲突的时候以 Spec 为准。Spec 不是不会错的，但它是被团队确认过的事实。否则产品、研发、测试谁也拍不了板
3. 先改 Spec 再改代码——发现 Spec 漏了，先回去改 Spec。否则文档和代码越来越脱节，Spec 慢慢就腐化了

三条少一条，SDD 就不成立。

举个例子。研发 Agent 写到一半突然说：

"我发现 Spec 里没说密码长度限制，我加个 8-32 位吧。"

这是错的。它违反了第三条铁律。而且"密码长度"这种事情看起来微不足道，实际上可能影响老用户登录、影响测试、影响合规——这些都不是研发 Agent 该独立决定的。

正确的做法：停下来，先回到 Spec 加一行"密码长度 8-32 位"，再让研发 Agent 继续。

在 AI 真正开始实现之前，最重要的不是让它写得更快，而是让它真正理解问题。

2.2.3 Spec 是 AI 时代的协作界面

Spec 写好之后，它在整个系统里的位置就变了。

在传统软件开发里，代码是人和机器协作的核心界面——所有协作最终都要落到代码上。

但当 AI Agent 大规模进入开发之后，大家不再围着代码转，是围着 Spec 转。

先看人怎么用 Spec：4 个角色（产品和业务方、设计、架构和 TL、测试）把判断聚合进 Spec。以前这些判断散在几个地方——需求群、原型、Wiki、测试用例。现在它们全部聚合进同一份 Spec。

再看 Agent 怎么用 Spec：4 个 Agent 各从 Spec 里抽自己关心的部分：

一句话总结：协作界面前移，Spec 是 AI 时代的事实源。

2.3 Agent：反馈 + 分工 + 工具

Spec 通过审查、Agent 可以开始实现了——但只是写出代码，远远不够。

2.3.1 为什么一个 Agent 不够

假设我们只让一个 Agent 把所有事都做完。它跑完一轮，看着主流程都过，可容易漏掉的东西——异常路径、UI 状态、数据边界——它自己完全意识不到。

有三个原因：

• 第一，自己说服自己——Agent 沿着自己的假设去解释自己的实现。它能自检，但自检替代不了独立视角
• 第二，上下文窗口塞满——一个 Agent 又写代码又审查又验证，所有东西堆一起，它的注意力会逐渐失焦
• 第三，发现和修复被混在一起（这是最隐蔽的一条）——Agent 发现问题的时候，往往顺手就把它改掉了。看起来很高效，但问题、判断、修复过程被压扁成一次代码变化

举一个具体场景：Agent 跑完自检，发现某个测试没过。它顺手加了一行兜底代码，重新跑——"全过了"，提交 commit。

但你永远不知道：那个测试为什么失败？是代码 bug 还是测试本身错？加的兜底是处理边界还是绕开问题？

发现 + 修复 在同一个 commit 里完成——问题被发现的证据就这样消失了。

所以对抗式开发的三个具体动作是：

• 拆视角——让不同 Agent 用独立视角判断
• 拆 Context——让每个 Agent 的注意力保持干净
• 拆发现/修复——让证据保留下来

对抗不是制造冲突，是让代码在多个视角的反复审视下逐渐变对。

2.3.2 6 步对抗式开发闭环

对抗的具体落地是一个 6 步闭环——

1. 测试先行——测试 Agent 在研发动手之前，先把"什么算做完"定下来。先写代码再补测试，等于让标准迁就代码，顺序反了
2. 研发 Agent 实现 + 自检——按 Spec 一条一条改，每改一条就 commit 一次。这样每个 commit 都留有证据，出问题能精准回头查
3. 代码审查 Agent——研发写的代码，让另一个 Agent 来审。自己审自己，就是自己说服自己
4. 测试 Agent 验证行为——跑测试 + 端到端跑一遍核心流程，看行为跟 Spec 是否一致。发现问题不要顺手改，要清楚记录
5. 报告与修复——审查和测试 Agent 输出清单：发现什么、对应 Spec 哪一条、该回哪里改。研发 Agent 拿这份清单改
6. Human Gate——只做一件事：人按"完工"。这是责任按钮，Agent 按不了

流程并没有变。变的是执行体——人换成了 Agent。

这 4 个 Agent 协作时靠三条铁律：

• 职责分界——审查 Agent 看代码但不动手改，测试 Agent 报 bug 但不替研发改。每个 Agent 守住自己的边界
• 信息要流动——测试报 bug 时顺手判一句：实现错、数据错、还是需求错。否则研发拿到 bug 不知道从哪查起
• 交接全落到文档——没落到文档就没沉淀

2.3.3 工具：Agent 的三种武器

Agent 需要工具。工具是 Agent 能力的延伸——但不是越多越好。每一个工具都会占用上下文空间。

好的工具有三个特性，是 Agent 本身做不到的：

• ① 高效——直接执行给结果，Agent 不用反复推理，节约时间和注意力
• ② 精准——只干自己擅长的事，给出准确的结果。不像 Agent 那种"好像有点问题、建议关注一下"的泛泛回答
• ③ 无情（最关键的一条）——Agent 会解释，Agent 之间会互相说服——但工具不会被说服。比如"怎么测都过"的假测试，在覆盖率工具面前就是没意义

工具说不过就是不过——这是对抗中最重要的价值。

工具不会自动成为 Harness。人要为每个 Agent 配上趁手的工具。

2.4 Context：Agent 一次工作的注意力空间

Agent 每一次工作都从当前上下文窗口开始。但真实项目从来不是一次 session 就能覆盖的——长期目标、历史决策、踩过的坑，散落在过去几个月、几年的对话里。session 一重启就丢了。

Context 支柱要解决的，正是 Agent 一次工作的注意力问题。

2.4.1 装得下 ≠ 看得见

很多人对上下文窗口有个误解——以为装得下就行。

但装得下，不等于看得见。

"信息存在"和"信息在正确时刻发挥作用"，是两回事。

所以上下文工程化要解决的其实是三件事：

• ① 位置——能不能找到
• ② 结构——能不能读懂
• ③ 触达——能不能在正确时机进入

常见的载体是文档。可以分成三类：

• 需求类：plan、需求文档
• 约束类：rules、反模式清单、AGENTS.md
• 历史类：plan 归档、决策记录、history

（RAG / 知识图谱等其他形式，思路相同。）

但载体本身也要工程化——否则写过等于没写。

打个比方——你想知道自己 16 岁生日那天的天气。可以翻当年的日记本，前提是三件事：日记放在哪、当时怎么写、今天怎么找到。三件事都做到，沉淀才有用。

2.5 知识：从记忆到沉淀

记忆和知识经常被混为一谈，但它们是两个不同层次的东西：

• 记忆是"发生过什么"——比如某个 story 何时暂停、某次 review 发现了什么
• 知识是"以后应该怎么做"——比如线上问题排查的标准流程

记忆经过反复整理、归纳、验证——才能沉淀成知识。

这里我们讨论的载体是文档工程。其他形式思路相同。

2.5.1 4 层渐进披露

知识不能平铺塞给 AI——要么一股脑全塞浪费空间，要么只塞一段又漏关键。所以要分 4 层渐进披露，让 AI 用到哪层看哪层：

2.6 责任锚点：人不是审批按钮，是判断者

五大支柱讲完了。这时候一个自然的问题就冒出来——Agent 越能做事，人到底剩下什么？

一个很常见的直觉是——Agent 越强，人就越不重要。但事实正好相反。

人发现 Agent 能力够强之后，会不自觉地把判断权交出去：Agent 给出合理分析就直接接受，说完成就直接确认，请求权限就直接同意。

这看起来像信任 Agent，其实是放弃了人机交互最关键的部分。

• Agent 输出越流畅，越要确认它是不是真的理解了问题
• Agent 行动越快，越要确认它是不是还在正确方向

人的价值不在于点确认，而在于判断、纠偏、扛责。

Harness 没有降低对人的要求——它降低的是执行负担，提高的是判断的密度和重要性。人不再是亲手做完每件事，而是通过 Harness 管理一组 Agent。

Agent 接走了执行——但人接到了判断。最核心的 3 项：

• 方向——要不要做
• 风险——哪里可能爆雷
• 长期演进——半年后这套代码还能不能维护

这些 Agent 都背不动。

三、真实项目实证

方法论讲到这里就完整了。可它在真实企业级项目里到底跑得起来吗？

我在自己主导的一个项目里，把这套方法论完整落了一次。我为这个项目量身定制了一整套 Harness 环境。

需要说明的是——这套具体做法不一定适合所有系统。项目形态、团队规模、技术栈都会影响细节。真正能被复用的是方法论本身，具体做法需要每个团队结合自己的业务场景去扩展。

下面挑几个代表性的 Harness 实践，讲讲我是怎么把它们落地的。

3.1 全景：AI 沉淀出的几百份文档

这是我为项目设计的 Harness 环境。几百份文档和代码，全部是 AI 在这套流程里跑出来、自动沉淀的。

但——AI 自己跑不动。关键节点必须有人做判断。

我做的其实是 AI 做不了的事：

• 开头两步：提诉求 + 选型决策——定方向
• 中间 5 步 AI 自主推进（落档 / E2E / 对抗审查 / 测试-修复飞轮），但每个关卡都回到我这里：plan 我审、待澄清问题我答、完工我点头
• 结尾：验收 + 拍板

我做方向、选型、判断，AI 跑剩下的。

3.2 Workflow 的落地：分档 + 关卡

分档解决的是"一刀切"问题——改一个文案走全套流程太麻烦，动架构直接干又太冒险。所以分成 3 档：

• [快速] —— 改文案直接走
• [计划] —— 跨模块的改动，先写 plan
• [完整] —— 动架构的改动，走全套 8 步

每个任务花它应该花的力气。

关卡分成两组——动手前 1 道 + 完工 3 道。挑两道我踩过坑的讲：

动手前『重扫』——我踩过坑：plan 写完隔了 2 天才开工，回来一看文件已经被同事改过了，按老 plan 改下去必崩。所以现在动手前，AI 必须先扫一遍代码现状和同事改动，对不上就停。

完工『前后端真验』——单测全过了，结果前端调用方调不通。所以现在单测过不算完，必须前后端真跑通才算。

任何一道没过，Story 只能标"阻塞"。

3.3 Spec 的落地：plan 模板 + 阻塞 + 三级验证

plan 模板——以前 plan 写得五花八门，重点全靠脑补。所以我固化了模板，5 个章节缺一不可：背景、范围、Story、验收、待澄清问题。

重点是"范围"——强制写清楚"做什么 + 不做什么"。否则 AI 顺手就把不在本期的东西一并做了。

而且 plan 是文件，能撑起两件事：

• ① 跨前后端：后端仓库里的 plan 同时管前端，按同一份蓝图推进
• ② 跨成员：我的 Agent 干 Story 1/2/3，同事的 Agent 读同一份接着干 4/5

待澄清问题阻塞——我踩过一个特别耗神的坑：口头答过一次，没写下来，下次新会话里 AI 又问一遍。

所以核心机制是——只要有没拍板的问题，AI 就不许动代码。必须问到我点头，答案回写到 plan，才算决策落定。

三级验证——每个子项先验、中间多轮对抗验、最后整体真验。每一级过了才能往下走。

3 个机制各管一段，缺一 AI 就会失控。

3.4 Agent 的落地：4 Agent 协作链 + 3 种对抗

四 Agent 协作链前面已经讲过。这里补充一个关键点：

每个 Agent 的产物都要落到文件——commit、审查/测试报告、Spec 更新。

为什么不能只在聊天里讨论？ 因为聊天里的内容，下一次会话就不知道了；而文件里的东西，永远查得到。

我们项目里有 3 种对抗，每一种都有真实工具支撑：

3.5 Context 的落地：hook 兜底 + 3 件套补位

Context 的具体设计，是基于痛点长出来的：

• 痛点 1 · 新会话开错任务——AI 不知道有没有未完成的 plan 就开了新的。加了活跃 plan 提醒 hook：自动扫、自动提醒
• 痛点 2 · schema 单端改踩过坑——后端改了一端，另一端忘记同步。加了协议同步 hook：改了哪边就提醒哪边跟着改
• 痛点 3 · 个人记忆出不去——我踩的坑只活在我的会话里，同事的 Agent 撞到又要从头摸。加了记忆沉淀 hook：自动评估这条经验能不能脱离个人也成立，能就晋升到团队记忆（决策记录、AGENTS.md）

但 hook 兜不住所有事——还有三件套补位：

• 代码地图——改代码前查影响范围，避免改一处坏一片
• frontmatter 渐进披露——文档顶部几行元信息，AI 先扫头再决定要不要读全文
• 子代理告知——spawn 子代理时把规矩带过去（比如"业务代码不能直接调数据库，必须走仓储层"）。hook 拦得住行为，塞不进初始规矩——规矩得靠 AGENTS.md 或 prompt 模板带

3.6 知识的落地：5 种文档 + 反模式清单

5 种文档分层——各管一摊。已完成 plan / 历史归档 / 质量水位 / 架构文档，这四类扫一眼就能懂。重点讲讲"决策记录"：

以前每次新人来问"为什么我们选 PG 不选 MySQL"，我要花一小时解释。现在 ADR（决策记录）翻一眼就懂。新 AI 接新任务也读得到，避免重复讨论同一件事。

顺带一提：质量水位表——按模块打 A/B/C/D 等级。Agent 改 D 级代码前会自动多测——避免高风险模块出事。

反模式清单——把踩过的坑写下来，让新任务不再踩。我们项目里已经攒了 30+ 条。

举一个具体的：DSF 接口的版本号规则——删接口要升大版本号、加接口要升小版本号。AI 写代码的时候特别容易忽略这条——但写进反模式清单里之后，AI 接新任务时读到就会主动按规则升版本。

四、镜子：Martin Fowler 4 阶段模型

到最后，我想用一张 Martin Fowler 提出的模型作为镜子，让你定位一下自己的项目处在人机协作的哪一段。

Fowler 的这套模型有一个前提假设——人决定 Why（要什么）这一点始终不变，How（怎么做）随着 AI 能力变化。基于这一点，人机协作被分成 4 个阶段：

Agent 越强，人就越要从"环内"升到"环上"。

对照一下你自己的项目在哪一段，下一步该怎么走：

• 环外 —— 先补 Workflow 和 Spec
• 环内 —— 加对抗式 Agent Review，让 Agent 替人审查
• 环上 —— 建 Context + 知识沉淀
• 飞轮 —— 让 Agent 帮你迭代 Harness 本身

这就是 Harness Engineering 的成长路径。

五、结语

回到开头的问题——为什么我们要建 Harness？

因为在企业级项目里，缺任何一根支柱，AI 都会崩：

• 缺 Workflow，AI 像脱缰的马
• 缺 Spec，错误被放大
• 缺 Agent，Agent 自说自话
• 缺 Context，AI 失焦
• 缺知识，越迭代越退化

五支柱缺一根，Harness 就不成立。

如果最后你想从这篇文章带走三句话，我希望是这三句：

• 第一——让 AI 不只是"能做事"，而是在工程约束下做正确的事
• 第二——AI 让写代码快了 10 倍。如果没有 Harness，错误也会快 10 倍堆出来
• 第三——Agent 降低的是执行密度，人承担的是更高的判断密度

Harness Engineering 不是给 AI 加限制，而是给它一个能真正跑稳的环境——让"AI 参与你项目"这件事，从演示级变成生产级。

关于作者：马文博。这篇文章基于我最近做的一次内部技术分享整理。如果你的项目也在踩类似的坑，欢迎交流。