什么是 Harness Engineering
大家好，我是 alien， 今天和大家聊一下我对 Harness Engineering 的看法，提到 Harness Engineering 是今年的比较火的一个热点话题，我先抛砖引玉，介绍一下它的由来。
如果我们用传统的 Prompt 工程开发，那么会遇到的什么：
举一个例子，如果你通过传统的 Prompt 喂给 AI,让它去帮忙实现一个页面：
1.你没有说清楚意图，AI 也没有弄清楚你想要的效果，结果和预期相差甚远；
2.走完第一步，你通过很多轮对话，终于搞定了，但是发现，项目里面的可维护性，模块应用根本不符合预期，很多逻辑你都不懂什么意思，而且文件超大；
3.为了赶进度，你用第二步的方式勉强蒙混过关，结果后面有新的迭代，发现根本没法维护。
如上，本质上我们需要的是 AI 能够生成系统性 ，可控性的 ，能够可拓展，可迭代的工程模块
那么这个时候 Harness Engineering 就派上用场了。Harness 中文含义是"马具"，如果 AI 是马，那么 Harness 就是控制马的马具------它不会让马变得更聪明，但能让马按你想要的方向、力度、节奏去跑。
我们来看一下 Harness Engineering 的官方解释：
Harness Engineering 是围绕 AI 编码代理（Agent）构建的一套工程化基础设施------包括结构化提示、工具集成、验证门控、上下文管理、测试驱动循环、错误恢复机制等------其目标是让 AI 在真实工程环境中产出可信赖、可维护、可演进的代码。
再回头看前面那个"三步走"的例子，Harness Engineering 是怎么一一解开的：
- 意图不清 → 系统性：Harness 强制要求需求以结构化模板（用户故事、验收标准、影响面）输入，AI 在动笔前必须先反述方案，把"做一个页面"这种模糊描述变成可对齐的具体规格。
- 可维护性差 → 可控性：Harness 把工程规范（lint、type check、模块边界、单测覆盖率）固化为门控，任何不符合规范的输出在 CI 阶段就被拦下，文件超大、逻辑不明的代码根本进不了主干。
- 无法扩展 → 可拓展：Harness 在生成代码前会先读项目既有架构（依赖图、接口契约、目录约定），强制新代码复用已有抽象，而不是另起炉灶。
- 无法迭代 → 可迭代：Harness 跑的是一个闭环------生成 → 测试 → lint → review → 反馈，AI 不是一次性输出，而是带着反馈循环不断打磨同一份代码。
Harness Engineering 能替代我们吗？
那么 Harness Engineering 既然能够让 AI 往预期良好的方向发展，那么它能够代码研发工程师吗？ 或者说后面 Harness Engineering 发展逐渐成熟，会不会取代大部分的开发者？
对于这个问题和以往我最近的工作经验上来看，我的观点不是那么乐观：
Harness Engineering 真的能够解决很大一部分事情，只不过现在还不够成熟
首先我们盘点一下，一个普通的工程师，每天的工作内容都有什么？
- 日常的开发迭代，接需求，消化需求；
- 日常问题答疑，解决疑难杂症；
- 沟通需求，沟通资源，承接业务需求，推动项目逻辑；
如上可能覆盖研发工程师的大部分工作，但是我们仔细想一想，如上第一点和第二点，Harness Engineering 可以完全自己实现，只不过现在不够成熟而已。
首先说一下研发流程，对于 Harness 可以定制专向的 workflow， 完成从 prd -> 系统设计 -> 制定研发规范开发 -> 测试用例生成，自动修复 -> 代码 pr cr ---> 上线整个流程。 在这个过程中，开发者可以通过 skills 和 reference 让 ai 学会参考，叫 ai 用正确的规范，正确的设计模式，正确的代码结构。
回到前面的案例：对于一个需求，可以通过 plan skills 把 PRD 拆成结构化需求点，再叠加 研发规范 / 设计规范 / 系统架构 skills 把 AI 约束到既有方向上，最后用 e2e skills 做端到端验证，跑完"PRD → 需求落地"的全过程。具体来看：
Plan 阶段：plan skills 接收 PRD 文本后，会先做"反述对齐"------把"做一个营销活动页"这种模糊表述，拆成用户故事（As a 用户，I want 看到活动倒计时，so that 知道还剩多久）+ 验收标准（倒计时精度、异常态行为、埋点要求）+ 影响面（涉及登录态、分享链路、AB 实验位）。AI 必须先产出对齐文档，再进入下一步。
Design 阶段 ：design skills 把项目里沉淀的视觉规范（Design Token、组件库版本、栅格断点）、系统架构规范（包结构、命名约定、状态管理选型）作为门控输入。AI 生成代码前必须先 grep 项目里的 package.json、tsconfig.json、既有模块结构，强制新代码复用已有抽象，而不是另起炉灶。
Build 阶段 ：研发规范 skills（如 ESLint + TypeScript strict + 单测覆盖率阈值）作为硬约束，AI 每写完一段代码就立刻跑 lint + type check + unit test，任何不达标的部分在本地就被拦下，根本走不到 PR 阶段。
Verify 阶段：e2e skills 接管------用 Playwright / Cypress 跑端到端验证，把"用户从首页进入活动页 → 看到倒计时 → 分享 → 回到首页"这条主链路完整跑通，再把截图与录屏作为 PR 的强制附件。AI 不是一次性输出，而是带着这条反馈闭环不断打磨同一份代码。
对于日常答疑，排查问题场景，Harness 可以结合 MCP Tools 来和公司的各种平台打通，同样制定专属的 workflow，来解决大部分的问题，由此不再需要研发者，取而代之的是各种智能体的诞生。
比如：业务同学问"为什么昨天那个订单的状态变了"，过去你需要登录运维平台 → 查订单系统 → 看日志 → 回复 IM，至少 15 分钟。现在你可以让 AI 构建团队知识库（沉淀过往的问答、Runbook、故障复盘），再通过 MCP 能力把知识库、监控、日志、订单系统串起来，业务问问题时，智能体直接调 MCP 工具查订单、调监控、检索知识库，几秒钟就把答案喂回来------业务问的其实是你的"数字分身"。
这件事在 Harness 里通常用一个 oncall-bot workflow 落地：监听 IM 群消息 → 用意图识别判断是否属于已知问答 → 是，走知识库 RAG 检索 → 否，升级到真人。这种机制下，80% 的"在吗？问个事"会被无声消化，你只需要处理剩下 20% 的真问题。
再比如：要解决一个线上问题，可以定制一个 incident-response workflow：第一步，AI 接告警 → 自动拉取错误堆栈、错误率曲线、最近一次发版记录；第二步，结合监控的 MCP 能力查询 Prometheus / Grafana / Sentry，识别受影响应用与版本；第三步，对照 Runbook 与历史相似故障，给出根因假设 + 修复方案；第四步，针对 P0/P1 自动开 PR（带修复代码 + 回归测试），人工确认后走流水线灰度发布。整个过程从"告警响"到"修复 PR 提上来"，可以压到分钟级，研发不再是被叫醒的那一个，而是最终的复核者。
最后剩下的可能只是一些需求的沟通和推进成本，那么我们不妨试想一下，如果 ai 发展的越来越快，自动流程化的环节越来越多，那么沟通的成本是不是也就越来越少了。
我们应该怎么做
Harness Engineering 发展的如此迅速，那么对于普通的研发者来说，我们应该做些什么？
Harness Engineering 发展如此迅速，不考虑转行的情况下，我觉得传统的研发工程师，可能有三个方向需要准备：
1. 成为超级个体------AI 降低了研发的"深度门槛"，但放大了"广度杠杆"。
AI 发展下，可能不再需要每个研发者都有足够的单点深度，取而代之的是一定的技术广度：AI 让研发的入门门槛变低了，你可以结合 AI 完成从前端到后端、从数据到运维的整条链路。正所谓"一个人的公司"、AI Native 的初创公司会大量出现------一个人 + 一套 Harness，跑出一个原本需要 10 人团队才能撑住的产品。这里要求研发者从"某条线的专家"转身为"整条链路的整合者"。
Harness Engineering 会帮助研发者处理很多的工作，取而代之的是研发者要核心参与到 Harness 建设中。
2. 成为 Harness Engineering 的建设者------从"show my code"到"show my idea"。
过去一直是 talk is cheap, show me the code；现在是 code is cheap, show my idea。AI 把代码的边际生产成本压到了接近零，真正稀缺的是对工程链路的判断力 ：哪些环节该用 plan skills、哪些该用 e2e 校验、门控该放在哪个阶段、上下文该怎样切片供给------这些"看不见的工程决策"才是 Harness 时代最有价值的东西。投身 Harness Engineering 建设，意味着你要去设计别人使用的工具 ，而不只是使用别人设计的工具。
3. 做 Harness Engineering 的使用者 + 业务发展底线的"守门人"------AI 兜不住责任，人来兜。
AI 发展得再好，也需要人来 check 标准；出了问题、问责的时候，AI 承担不了责任。所以最终还是需要研发者：上要串联业务，把模糊的需求翻译成 AI 可消费的规格；下要守住最后一道门槛------代码 Review、架构决策、安全合规、上线把关。这一层不是"AI 替代不了"那么简单，而是"AI 不被允许替代"------因为责任主体必须是自然人，这也是 Harness 体系里必然存在 human-in-the-loop 的根本原因。
Harness Engineering 并不是要代替我们。如果把 AI 比作一匹马，那么 Harness 就是那副马具------缰绳、嚼子、笼头、脚镫------它决定了马往哪个方向跑、以多大力度、用什么节奏。但请记住，没有骑手的马具只是一堆皮革。再聪明的马、再精致的辔头，也需要一个人坐在马背上，握住缰绳，做出方向判断。Harness Engineering 时代，研发工程师就是那个骑手------AI 是马力，Harness 是马具，而决定这匹马走向何方的，还是我们。
最后祝大家端午安康，后面会陆续分享 AI 场景下的一些实践。