为什么 AI 有时看起来很能干有时又完全不靠谱为什么它能写出一段像样的代码却经常交不出一个可验证的结果为什么同一个任务换个人问、换种说法结果差异会这么大如果把 AI 只当成一个“更会说话的搜索框”这些问题几乎无解。因为问题不只出在模型本身更出在我们给它的工作环境太松散任务定义不清、上下文不完整、工具边界不明确、验证机制缺失最后只能得到一个“像完成了”的回答。Harness Engineering 想解决的正是这类问题。它不是某种新奇技巧也不只是把 prompt 写得更复杂。更准确地说它是一套把 AI 纳入工程流程的方法给任务加边界给执行加路径给结果加验证给经验加沉淀。一句话概括Harness Engineering 关注的不是“AI 会不会回答”而是“AI 能不能稳定交付”。二、什么是 Harness Engineering可以把 Harness Engineering 理解成给 AI 搭一套“任务运行框架”。在这套框架里AI 不再只是被动响应问题而是要在明确目标、范围、上下文、工具和验收标准的前提下完成任务。它的关注点不是模型的单次表现而是整个执行链路是否可控任务有没有被定义清楚项目背景有没有被准确提供AI 能调用哪些工具边界在哪里执行是否遵循固定流程结果有没有经过真实验证成功经验能不能复用所以AI 是执行者Harness 是执行环境。没有 HarnessAI 更像一次临场发挥有了 HarnessAI 才有可能成为工程流程里稳定的一环。三、它和 Prompt Engineering 到底差在哪Prompt Engineering 当然重要但它解决的主要是“怎么问”。Harness Engineering 解决的是另一层问题“当问题已经提出后AI 应该在什么环境里、按什么方式、用什么工具、经过哪些检查把事情做完。”两者的区别可以放在一张表里看维度Prompt EngineeringHarness Engineering关注点优化模型输入设计 AI 的执行环境核心目标提高回答质量提高任务交付稳定性主要手段Prompt 模板、上下文组织任务定义、工具、流程、验证、沉淀输出更好的文本结果可执行且可验证的工程结果失败后的处理继续改 prompt复现、诊断、修复、重试典型场景问答、生成、摘要编码、调试、评审、自动化更简洁一点说Prompt Engineering 解决“表达问题”。Harness Engineering 解决“交付问题”。用户目标Prompt Engineering优化提问方式Harness Engineering设计执行环境更好的回答可执行任务流工具调用验证与反馈可交付结果团队真正需要的通常不是一个更会“说”的 AI而是一个更会“做”的 AI。四、一个不带 Harness 的 AI通常会怎么失手这件事在工程里很常见。比如我们给 AI 一个任务“帮我实现登录功能。”这句话看起来没问题但实际缺了太多关键约束登录是账号密码、SSO还是短信验证码允许改哪些目录需不需要兼容旧接口是否允许改数据库前后端分别在哪里验收标准是什么需要跑哪些测试于是 AI 往往会陷入一种典型状态能写代码但不确定是不是该这么写能输出方案但没有依据现有项目结构能给出结论但没有真实验证能说“完成了”但没有留下可复查的证据这并不是模型“笨”而是任务环境没有工程化。Harness Engineering 的价值就是把这些本来靠经验补齐的隐含条件变成显式结构。五、Harness Engineering 的核心组成在实际工程里Harness Engineering 可以拆成七个部分。它们合在一起构成了 AI 的执行框架。5.1 Task Harness先把任务定义成可执行规格AI 并不怕复杂任务它更怕模糊任务。相比“帮我实现登录功能”下面这种写法明显更适合执行目标 - 实现用户登录功能 范围 - 只修改 backend/auth 和 frontend/login 相关代码 - 不修改数据库 schema除非需求明确提出 输入 - 项目路径 - 登录接口文档 - UI 设计稿 输出 - 可运行代码 - 测试用例 - 变更说明 约束 - 复用现有 auth middleware - 不引入新的状态管理库 - 保持向后兼容 验收标准 - 单元测试通过 - e2e 登录流程通过 - 错误密码返回 401 - 登录成功后跳转 dashboard好的任务定义至少要回答六件事做什么改哪里参考什么不能做什么交付什么怎么算完成任务一旦被定义成“规格”AI 的行为就更容易收敛执行结果也更稳定。5.2 Context Harness别让 AI 靠猜理解项目真实工程里任务本身通常只占问题的一半另一半是上下文。如果没有上下文AI 只能根据经验做“平均化推断”这也是很多结果看上去合理、落到项目里却不合适的原因。常见上下文包括项目目录结构技术栈和关键依赖模块边界代码规范测试命令历史设计文档CI 日志和报错信息业务约束和兼容性要求项目里最好有一些稳定的上下文载体比如AGENTS.mdREADME.mddocs/设计文档测试脚本与 CI 配置例如一个简单但有效的AGENTS.md可以是这样# Agent Instructions ## Tech Stack - Backend: FastAPI - Frontend: React Vite - Database: PostgreSQL - Tests: pytest, playwright ## Rules - Do not change public API without updating docs. - Always run uv run pytest before finishing backend changes. - Prefer small, focused commits. - Do not add dependencies unless necessary. ## Useful Commands - Backend tests: uv run pytest - Frontend tests: npm test - Type check: npm run typecheck这类文件的意义并不在于“写文档”而在于把原本只存在于资深开发者脑子里的默认规则变成 AI 可以直接消费的工程上下文。5.3 Tool Harness工具要给边界也要给如果 AI 只能输出文本它很难真正完成工程任务。它至少需要一些基本能力读写文件搜索代码修改代码运行测试查看日志执行脚本查看 diff调用浏览器或接口但工程里另一个常见误区是只想着“让 AI 能做更多”却忽略“让 AI 不能乱做”。所以 Tool Harness 的关键不是工具数量而是权限边界。比如允许 - 读取项目文件 - 修改 src/ 和 tests/ - 运行 pytest - 运行 npm test - 查看 git diff 禁止 - 删除数据库 - 强制 push - 修改 secrets - 直接部署生产环境 - 未经确认安装系统级依赖工具的本质是执行能力边界的本质是风险控制。两者必须同时存在。5.4 Execution Harness让执行过程有固定路径很多 AI 任务失败并不是因为它不会写而是因为它执行顺序错了。功能开发任务通常至少应该经过下面这条路径理解任务检查项目结构定位相关代码阅读现有实现制定计划修改代码添加或更新测试运行验证命令修复失败项总结变更和结果是否理解任务检查项目结构定位相关代码阅读现有实现制定计划修改代码补充或更新测试运行验证命令验证通过?整理变更说明定位失败原因不同任务可以有不同流程Bug 修复强调先复现、再定位、再回归验证重构强调先保护行为、再渐进修改、再持续回归代码评审强调证据指向、风险分级和结论可复查但无论是哪类任务最怕的都是“想到哪做到哪”。Execution Harness 的意义就是把执行方式从临场发挥变成标准路径。5.5 Verification Harness没有验证就没有完成这是整个方法里最关键的一环。工程任务最大的误区之一是把“生成了结果”和“完成了任务”混为一谈。对 AI 来说更是如此它很容易写出一个看起来正确的答案但这不等于结果真的可用。一个合格的交付应该附带真实验证记录例如已执行 - uv run pytest tests/auth - npm run typecheck - npm run test:e2e login.spec.ts 结果 - 42 tests passed - typecheck passed - login e2e passed如果没有验证成功也应该明确说明未能完成验证 - npm test 失败 - 原因缺少 node_modules - 已尝试安装依赖但当前环境网络不可用 - 已完成代码修改尚未完成运行验证团队要建立一个共识AI 的“我完成了”没有价值测试、构建、类型检查和回归结果才有价值。5.6 Memory / Skill Harness把成功做法沉淀下来如果某类任务反复出现就不该每次从零开始组织输入。例如这些高频场景修 API bug做代码评审写技术方案修 CI生成测试排查线上问题