当 AI 能写代码、改 Bug、跑测试，甚至独立完成需求分析，团队交付反而更容易失控。不是因为 AI 不够强，而是我们缺少一套约束 AI 的工程系统。
过去一年，开发团队使用 AI 的方式发生了明显变化。
以前，大家让 AI 补一个函数、改一个接口、生成一段测试脚本。现在，AI Agent 已经开始参与需求分析、方案设计、代码修改、测试验证，甚至能自己读仓库、跑命令、改文件、生成文档。
效率确实提高了。
但很多团队用深以后，反而遇到一个更棘手的问题：
- AI 能干活，但它不一定稳定。
- AI 能写代码，但它不一定懂你的工程边界。
- AI 会说“完成了”，但你很难确定它到底有没有做对。
这就是 Harness Engineering 开始被反复讨论的原因。
它不是一个新的提示词技巧，也不是某个工具插件。它真正要解决的是一个更底层的问题：
怎么把一个会临场发挥的 AI，放进一套可约束、可协作、可校验、可持续维护的工程系统里。
一、AI 写代码越来越快，为什么交付反而更容易失控？
很多团队刚开始用 AI 编程时体验很好：需求一丢进去，代码很快出来；Bug 描述一给，修复方案马上生成。但问题通常不是出在第一次，而是出在持续迭代里。
你会慢慢发现几类现象：
1. AI 会自己理解需求
你说“优化登录异常提示”，它可能顺手改了登录流程；你说“补一个边界校验”，它可能把原有兼容逻辑改掉。它不是故意乱改，而是根据上下文推断“更合理的实现”。
2. AI 会跳过工程规矩
- 改完代码不跑测试
- 只验证自己改动的路径，不做回归
- 编译失败后说“应该是历史问题”
- 看到已有代码风格不统一，就按自己习惯重写一段
3. AI 会给自己找理由
- “这次只是小改，不需要完整验证。”
- “这个 Warning 不是我引入的。”
- “当前环境不具备测试条件，但逻辑上应该没问题。”
这些理由听上去很合理，但工程里最怕的就是“看上去合理”。真正的风险不在于 AI 不会写代码，而在于它写得太快、改得太顺、解释得太像真的。
AI 不缺执行力，缺的是被工程机制约束后的稳定执行力。
这就是 Harness Engineering 要解决的问题。
二、Harness 的本质：不是提示词，而是工程约束系统
很多人第一次听 Harness Engineering，会以为它是“高级提示词”。这就理解浅了。
- 提示词解决的是：这次你怎么告诉 AI 做事。
- Harness解决的是：以后每一次，AI 都要在什么边界里做事。
如果只靠提示词，你很容易进入一种状态：这次写得不错，下次换个需求又飘了；这次验证通过了，下次它又跳过测试……
Harness Engineering 真正做的，不是让 AI “更聪明”，而是让 AI 的工作方式更像工程团队。
一个真实工程团队不会只靠口头沟通。它会有需求文档、代码规范、开发流程、测试用例、CI 门禁、发布流程、回滚机制、责任边界。AI 进入工程以后，也需要这些东西。
你可以把 Harness 理解成 AI 时代的工程作战系统：
（示意图：Harness 分层架构）
- SPEC：到底要做什么
- Rule：哪些事情不能乱来
- Skill：固定动作怎么标准化
- Sub Agent：复杂任务怎么分工
- Workflow：这些角色怎么接力
- Scripts：到底做没做对
- dev-map：AI 怎么理解项目结构
- 任务看板：AI 怎么知道历史进展
- MCP：AI 怎么接入外部工程系统
每一层解决不同问题，它们不是互相替代，而是逐层叠加。这也是很多团队做 AI 工程化容易踩坑的地方：只补其中一层，以为就完整了。
三、核心机制拆解：AI 要稳定落地，至少要补齐这六层
1. SPEC：不要让模糊需求直接流进代码
很多 AI 编程事故，第一步就错了——不是代码写错，而是需求没说清。AI 有一个特点：它很擅长补全。你没说清楚的地方，它会替你补；你没定义边界的地方，它会自己猜。
一份能指导 AI 开发的 SPEC，至少要写清楚：
| 内容 | 作用 |
|---|---|
| 目标 | 这个需求到底解决什么问题 |
| 范围 | 哪些要做，哪些不做 |
| 兼容性 | 不能破坏哪些已有行为 |
| 影响模块 | 可能涉及哪些服务、页面、配置、接口 |
| 验收标准 | 什么情况才算完成 |
| 边界条件 | 异常、空值、失败、权限、历史数据怎么处理 |
其中最重要的是验收标准。没有验收标准，AI 很容易把“实现了功能”当成“完成了需求”。
2. Rule：规则不是万能，但没有规则一定会乱
Rule 可以理解成写给 AI 的工程纪律，例如：
- 改完代码必须编译
- 编译通过后必须跑测试
- 不能绕过已有接口
- 不能硬编码配置
- 不能在没有确认影响面的情况下重构核心模块
但 Rule 有明显天花板——它是自然语言约束，会被遗忘、被稀释、被解释性执行。所以 Rule 要写，但不能迷信 Rule。更合理的做法是：Rule 管底线，Skill 管步骤，Scripts 管结果。
3. Skill：把高频动作从“临场发挥”变成“标准操作”
工程里有一类动作，不应该让 AI 每次重新想：编译、测试、生成报告、回归验证、发布前检查。这类动作经常发生、步骤固定、做错代价高、不需要每次创新，适合沉淀成 Skill。
Skill 告诉 AI “具体怎么做”：
- 使用哪个命令
- 在哪个目录执行
- 日志输出到哪里
- 失败后看哪些错误模式
- 完成后如何记录结果
Skill 的本质，是把团队里的 SOP 变成 AI 可执行的工作手册。
4. Sub Agent：复杂任务不能让一个 Agent 从头演到尾
单 Agent 最容易出现的问题是角色冲突：它自己分析需求、设计方案、写代码、审代码、跑测试、最后宣布完成。这在复杂工程里非常危险，因为一个角色同时负责“生产”和“验收”，天然容易放水。
当任务复杂到一定程度，可以拆成多个 Agent：
（示意图：多 Agent 协作结构）
- 需求分析 Agent
- 方案设计 Agent
- 开发实现 Agent
- 测试验证 Agent
- PM 调度 Agent
- 闸门评估 Agent
最关键的不是拆几个，而是每个 Agent 必须有清晰边界。谁负责需求，谁负责方案，谁负责实现，谁负责验收，不能混。下游不能私自修改上游产物，只能提出阻塞项，让流程正式打回。
5. Workflow：多 Agent 不是一起聊天，而是按流程接力
真正工程化的多 Agent，不仅要明确有哪些角色，还要明确：
- 当前处在哪个阶段
- 这个阶段读什么输入、写什么产物
- 什么时候可以进入下一阶段
- 什么时候必须打回、打回到谁那里
Workflow 的核心不是画流程图，而是定义接力规则。没有 Workflow，多 Agent 只是多个角色；有了 Workflow，多 Agent 才是一条研发流水线。
（示意图：需求流转 Workflow）
需求 → 需求分析 → 方案设计 → 开发实现 → 测试验证 → 闸门评估 → 发布
↑____________打回_____________|
这套机制对测试团队尤其重要，因为测试不再只是最后点点页面，而要参与定义验收标准、回归范围、质量门禁、失败回退。
6. Scripts：AI 说完成不算，系统判定通过才算
Harness 里最容易被低估的是 Scripts（脚本门禁）。Rule 是软约束，Skill 是执行手册，Scripts 是硬判断。
AI 说“我完成了”不算完成，要靠脚本判定：
- 编译过了没有？
- 测试过了没有？
- 静态扫描过了没有？
- 新增问题有没有？
- 测试数量有没有异常减少？
- 工程文件有没有漏？
- 配置有没有硬编码？
一套成熟的总验证脚本通常会覆盖编译检查、测试检查、规则扫描、工程一致性、回归对比、产物检查等。更关键的是基线对比：开发前跑一次作为基线，开发后再跑一次，看新增问题。这样 AI 就不能再用“这是历史问题”糊弄过去。
真正贵的不是 token，而是 AI 在错误路径上一路狂奔后的返工成本。 Scripts 让“完成”从主观描述变成客观判定，形成质量闭环。
四、对比：从“提示词驱动”到“Harness 驱动”
假设需求：给后台系统增加“批量导入用户”功能，支持 Excel 上传、字段校验、错误行提示、导入结果统计。
提示词驱动：告诉 AI 需求 → AI 直接生成代码 → 开发者看一眼 → 补几个 Bug → 上线。风险显而易见：模板格式没定义、重复用户处理不清、大文件性能没考虑、测试只覆盖成功路径。
Harness 驱动：
| 阶段 | 产出物 |
|---|---|
| SPEC | 支持格式、最大文件、缺失处理、重复处理、事务边界、错误信息格式、审计要求 |
| 方案 | 上传接口、解析流程、校验规则、事务边界、错误行结构、异步任务设计 |
| 测试 | 正常导入、空文件、字段缺失/类型错误、重复数据、超大文件、权限不足、部分失败、重复提交、中断异常 |
| Scripts | 编译、测试、扫描、回归对比、新增违规检查 |
AI 不再一上来就写代码，而是先明确边界、方案、测试，最后通过脚本门禁才能交付。两者最大的差别不是速度，而是可控性。
五、普通团队该从哪一步开始搭？
很多团队看到这里容易误以为必须一上来就搭完整 Harness。不需要，也不现实。从最痛的地方开始。
第一阶段：先把 SPEC 写清楚
不要急着做多 Agent。先把需求模板固定下来：目标、范围、不做什么、影响模块、验收标准、异常场景、回归范围。这一步成本最低，收益最大。
第二阶段：补最关键的 Rule
先抓最容易出事故的几条，例如：改代码必须编译、改接口必须补测试、不能跳过失败测试、不能私自扩大需求范围。规则少一点，但要硬。
第三阶段：把编译、测试、验证做成 Skill
当你发现 AI 每次都在重复做某些动作，就该沉淀成 Skill。这对测试开发特别有价值——测试团队本来就有大量可标准化动作。
第四阶段：再拆多 Agent
当任务开始复杂，一个 Agent 经常混淆角色时再拆。可以先拆 4 个：需求分析、方案设计、开发实现、测试验证。拆角色的标准只有一个：某个环节已经经常出问题，并且需要独立责任边界。
第五阶段：补 Scripts 和基线对比
这是从“能用”走向“可靠”的关键。编译、测试、扫描、覆盖率、规范检查、接口兼容检查……只要这些门禁存在，AI 的产出质量就会明显可控。
第六阶段：再补 dev-map、任务看板和 MCP
项目变大后，AI 需要项目级上下文（dev-map）、历史状态（任务看板）和外部系统集成（MCP）。但顺序不要反：先把开发闭环跑通，再把 AI 接入更大的工程系统，不然只是把混乱扩大了。
六、趋势：未来拼的不是谁会用 AI，而是谁有质量闭环
AI 编程工具会越来越强，代码生成会越来越简单。但企业真正关心的不是“能不能写出来”，而是：
- 能不能持续交付？
- 能不能稳定迭代？
- 能不能控制风险？
- 能不能追溯问题？
- 能不能保证质量？
这也是为什么 Harness Engineering 对测试从业者非常重要。它把测试的价值从“最后发现问题”推到更前面：参与需求验收标准设计、参与流程门禁设计、参与自动化验证脚本建设、参与质量反馈闭环建设。
测试岗位不会只停留在点页面、写用例、跑脚本。未来更有价值的测试工程师，会越来越像质量体系设计者——懂业务、懂工程、懂 CI/CD、懂 AI Agent、懂质量门禁、懂反馈闭环。
AI 写代码的终点不是“自动生成”，而是“自动进入质量闭环”。
- 对在校生：不能只学“怎么用 AI 写代码”，还要理解软件工程、测试体系、质量流程。
- 对初级工程师：不能只满足于“AI 帮我完成任务”，要思考这套产出能不能验证、能不能复用、能不能进入团队流程。
- 对中级工程师：真正的机会在于方法论升级——把 AI 从个人提效工具，变成团队级工程能力。
你现在的项目里，AI 生成的代码，是靠人工检查兜底，还是已经进入了一套可执行、可回退、可追溯的质量闭环？
欢迎在评论区分享你的实践与思考。
参考资料：本文观点整理自霍格沃兹测试学院关于 Harness Engineering 的系列讨论。
关于我们
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
