Harness Engineering落地指南：把AI当员工管的六大模块详解

核心问题：AI是工具还是员工？

你有没有遇到过这种情况——你跟AI说了800遍要编译、要测试，它每次都说"好"，然后每次都不干。你问它为什么？回答永远是："我忘了"、"我觉得这次不需要"、"我觉得没问题啊"。

这不是在跟工具打交道，而是在管一个能力极强但不靠谱的新员工。

全网都在讲Harness Engineering，但大多数人看完只觉得是一堆抽象概念。Harness Engineering 是近年来随着 AI 编程助手大规模落地而兴起的工程化管理方法论，核心思想是将软件工程中成熟的流程管控手段移植到 AI Agent 的行为约束上。Harness 一词本意是"驾驭、套具"，暗示这套方法论的本质是给 AI 套上可控的工程框架，而非单纯依赖模型能力。其出现源于一个现实困境：当 LLM（大语言模型）被用于真实工程任务时，其输出的不确定性、上下文遗忘和自作主张行为，会让整个开发流程变得不可预测。

用职场类比就能秒懂：

• Rule = 员工守则
• Skill = 标准作业流程（SOP）
• Subagent = 分工协作
• Workflow = 交接流程
• Scripts = 质检部门
• MCP = 开权限

下面逐一拆解每个模块的作用和落地方式。

Rule：员工守则，用底线减少AI的混乱行为

改完代码去编译，编译完去跑测试，三步全部做完才算完成。听起来简单，但AI犯错的模式非常固定：

1. 忘了——上下文一长就丢步骤
2. 觉得跟需求无关——自作主张跳过
3. 偷懒没做——直接说"我觉得没问题"

一个员工活没干完，跟你说"我觉得没问题"——这种话在职场里太熟悉了。Rule的本质不是拿来创造价值的，而是拿来减少混乱的。它画的是底线，不是天花板。

在Cursor或Claude Code中，Rule通常写在.cursorrules或CLAUDE.md文件里，明确告诉AI哪些步骤必须执行、哪些行为绝对禁止。这两个文件的作用是在每次对话开始时将规则注入 AI 的系统提示（System Prompt），从而在模型层面建立行为约束。值得注意的是，这种机制存在固有局限：规则本质上仍是自然语言，AI 在长上下文中可能因注意力分散而"遗忘"规则。这也是为什么 Rule 需要与 Scripts 配合——Rule 是软约束，Scripts 是硬约束，两者互补才能真正管住 AI 行为。

Skill：标准作业流程，告诉AI具体怎么做

Rule说"必须做"，Skill说"具体怎么做"。

编译不是简单一句dotnet build。实际工程中需要：对齐MSBuild固定配置、先还原依赖、识别错误模式。你让AI自由发挥20次，它20次的手法都不一样——自己猜命令 vs 按Skill走，结果天差地别。

Skill本质上是把高级工程师的经验固化成可执行的标准操作。这与制造业、医疗、航空等高可靠性领域广泛使用的 SOP（Standard Operating Procedure，标准作业程序）逻辑完全一致——其核心价值在于将专家经验转化为可复现的操作步骤，消除个体差异带来的质量波动。以 .NET 编译为例，MSBuild 的固定配置、NuGet 依赖还原顺序、错误码识别模式，都是高级工程师踩坑后积累的隐性知识。将其显式化为 Skill，AI 每次执行的路径就从"随机漫步"变成"按图索骥"。AI 不需要"理解"为什么这样做，只需要严格按照 Skill 定义的步骤执行。

好的Skill文档应该包含：触发条件、执行步骤、预期输出、异常处理方式。写得越具体，AI执行的一致性越高。

Subagent：角色拆分，别让AI一个人干所有事

如果让一个AI同时承担需求分析、方案设计、代码开发、审查测试，会发生什么？

它会自己解释需求，自己给方案打满分，自己写代码，自己说自己没问题。一个人又做产品、又做架构、又做开发、又做QA——质量一定收不了口。

解决方案是拆分角色：

• 需求分析Agent：负责澄清和拆解需求
• 方案设计Agent：负责技术选型和架构决策
• 代码开发Agent：负责按方案实现功能
• 审查测试Agent：负责Code Review和测试验证

各管一段，互相制约。拆开以后AI反而老实了，因为它不用再自己给自己打分了。这和现实中"不能既当运动员又当裁判"是同一个道理。

这一设计有其认知科学依据：单一智能体承担过多角色时，会因目标冲突产生决策偏差。在 LLM 中，这种偏差表现为"自我确认偏误