Spec 写好了怎么落地？Harness Engineering 实战
Harness Engineering 是知识沉淀的自动化，让 AI 在正确的约束下执行，人在正确的时机介入。五层架构 + 五个关键时刻 + 24周落地路线。
核心问题
很多人写好了详细的 Spec，但让 AI 执行时仍然各种问题：
- AI 用错第三方 API
- 人不知道何时介入（打断 AI 节奏 vs 放任跑偏）
- 想自动化但不知道从哪开始
根本原因：不是 Spec 没用，是缺了 Harness Engineering 这层。
Harness Engineering 是什么？
定义：不是工具堆砌，是知识沉淀的自动化
比喻：AI 模型是马，Harness 是缰绳/马鞍/笼头——不是阻止跑，是引导力量朝正确方向
公式：
coding agent = AI model + harness业界定义：
- Martin Fowler: “让 AI agent 保持规范的 tooling 和实践”
- Louis Bouchard: “prompt 工程 → 上下文工程 → harness 工程的演进”
- HumanLayer: “coding agent = AI model + harness”
Harness 五层架构
| 层级 | 功能 |
|---|---|
| 1. Spec 管理层 | 分层存储 + 版本控制 + 第三方文档 |
| 2. Agent 调度层 | PM/Arch/Dev/QA/SRE 角色化 + 上下文隔离 |
| 3. 质量门控层 | 测试金字塔（单元60%/集成30%/E2E10%） |
| 4. 自动化执行层 | CI/CD 集成 + Spec 变更触发流水线 |
| 5. 监控反馈层 | 日志 + 监控 + 告警 + 数据驱动优化 |
核心就一点：让 AI 在正确的约束下执行，人在正确的时机介入
人介入的五个关键时刻
| 时刻 | 时长 | 触发条件 | 关键点 |
|---|---|---|---|
| Spec 评审 | 30分钟 | AI 完成 Spec 编写 | 覆盖所有场景 |
| 架构决策 | 15分钟 | AI 提出技术方案 | 技术选型有理由 |
| 测试审查 | 15分钟 | AI 完成测试编写 | 覆盖率 > 80% |
| 上线验收 | 10分钟 | 代码合并前 | 特性开关检查 |
| 故障响应 | 按需 | 监控告警触发 | 自动回滚机制 |
每个时刻都有明确的：
- 进入条件
- 退出条件
- 介入方式
- 超时处理
第三方系统三层文档法
| 层级 | 内容 | 示例 |
|---|---|---|
| L1 API契约 | 接口定义、参数、返回值 | /pay 接口文档 |
| L2 业务语义 | 调用时机、副作用、幂等性 | 确认订单后调用 |
| L3 实战经验 | 坑点、降级方案、历史故障 | 签名算法易错、证书过期 |
AI 执行时依次读取三层 → 不靠猜，一次过
24周落地路线
阶段 1：框架选型（第 1-2 周）
- 评估项目类型（绿地/褐地/企业合规）
- 选一个框架（建议 GStack 或 ECC）
- 搭建基础目录结构
阶段 2：试点项目（第 3-6 周）
- 选一个中等复杂度项目试点
- 100% 按选定框架执行
- 记录痛点和问题
量化指标：
- AI 一次通过率（目标 >70%）
- 评审时长（目标 <30 分钟）
- 返工率（目标 <20%）
阶段 3：针对性改进（第 7-12 周）
- 每周复盘会，记录痛点
- 每次只改一个点
- A/B 测试验证改进效果
阶段 4：Harness 工程化（第 13-24 周）
- 把成熟流程固化为脚本/工具
- 集成到 CI/CD
- 形成团队专属 Harness
实际效果
| 指标 | 改进前 | 改进后 |
|---|---|---|
| AI 执行成功率 | 40% | 85% |
| 人介入时间 | 随机 | 可控 |
| 上线失败率 | 35% | 8% |
核心观点
Harness 不是约束 AI，是赋能 AI
它解决不了需求模糊、技术债、团队能力问题，但能解决一件事：
让 AI 在正确的约束下执行，人在正确的时机介入
总结
Harness Engineering 与 Spec 驱动开发不是非此即彼，而是相互依存的飞轮：
- Spec 为 Harness 提供校验的标准
- Harness 为 Spec 提供执行和反馈的引擎
读完这篇文章，你可以直接拿走：
- 五层架构
- 介入时机
- 24周落地路线
回去就能试！