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