Harness Engineering — 马达工程
v1.0.0Harness Engineering — Generator/Evaluator 双 Agent 编码工作流。用于任何需要规划、编码、评审、质量门禁的编程任务。将执行任务的 Agent 和评估任务的 Agent 分开，每个阶段通过质量门禁才能进入下一阶段。
by @cindypapa运行时依赖
安装命令
点击复制技能文档
Harness 工程 — 编码工作流体系 "如果它不能被机械化地执行，Agent 就会偏离。" 核心理念 Harness 工程是一套项目约束体系，用于规范化 AI 辅助编程流程。核心原则： Generator ≠ Evaluator — 写代码的 Agent 和审代码的 Agent 必须分开 质量门禁 — 每个阶段必须通过检查才能进入下一阶段 变更审计链 — 每次需求都有完整的规划 → 编码 → 评审 → 交付记录 工程化纠错 — 每发现一个错误，就消除它再次发生的可能性 项目结构 每个使用 Harness 的项目，根目录下有 .harness/ 目录： project/ ├── .harness/ │ ├── rules/ # 编码规范、工作流、质量门禁（始终加载） │ │ ├── quality-gates.md # 各阶段门禁标准 │ │ └── -rules.md # 项目特定规则 │ ├── skills/ # 可复用 SOP（如 evaluator.md 独立评审） │ ├── wiki/ # 项目知识库（按需查询） │ ├── changes/ # 变更审计链（每次需求自动创建） │ │ └── {type}-{name}-{date}/ │ │ ├── planning/ │ │ │ ├── spec.md # 需求规格 │ │ │ └── tasks.md # 任务拆分清单 │ │ ├── review/ │ │ │ ├── code_review_v1.md # Evaluator 评审报告 │ │ │ └── revision_report.md # Generator 修复报告 │ │ └── summary.md # 变更摘要（SSOT） │ └── agents/ │ └── project-agent.md # Agent Index & Map（启动必读） └── ... 变更目录命名规则 .harness/changes/{type}-{简述}-{日期}/ type: feat | fix | refactor | chore | docs 简述: 短横线分隔的英文描述 日期: YYYYMMDD 格式 五阶段工作流 规划 → 评审 → 编码 → 自审 → 独立评审 → 修复 → 交付 阶段 1：规划（Planning） Generator Agent 负责： 需求规格（planning/spec.md） 目标、范围、验收标准、非目标 任务拆分（planning/tasks.md） 每个任务：描述、输入、输出、验收标准 变更摘要（summary.md） 基本信息表、阶段状态表 质量门禁： spec.md 包含目标、范围、验收标准 tasks.md 每个任务有明确的输入/输出/验收标准 summary.md 已创建并填入基本信息 阶段 2：编码（Coding） Generator Agent 按 tasks.md 逐条实现： 先读现有代码，理解模式 写代码前说明计划（改什么、为什么、风险） 完成后产出 coding_report.md 完成 self_review.md 自查 质量门禁： 每个任务都有对应的代码实现 自审 checklist 全部通过 没有遗漏文件、破损 import、未测试路径 阶段 3：独立评审（Review） 关键：必须用不同的 Agent（Evaluator）评审 Generator 的产出。 Evaluator Agent 负责： 读取 spec.md、tasks.md 理解需求 审查 Generator 的代码改动 产出 review/code_review_v1.md，问题分级： 级别 含义 处理 MUST FIX 安全漏洞、功能缺陷、数据损坏 必须修复，否则不能交付 SHOULD FIX 边界情况、可维护性问题 强烈建议修复 LOW 代码风格、小优化 建议修复 INFO 观察、建议、未来改进 记录即可 质量门禁： 所有 MUST FIX 问题必须修复 SHOULD FIX 问题需说明不修复的理由 健康检查/API 测试通过 阶段 4：修复（Revision） Generator Agent 根据评审报告修复： 逐条修复 MUST FIX 和 SHOULD FIX 问题 产出 review/revision_report.md，说明每个问题的修复方案 最多 2 轮修复循环 质量门禁： 所有 MUST FIX 已修复并验证 revision_report.md 逐条对应评审意见 健康检查再次通过 阶段 5：交付（Delivery） Evaluator 确认修复通过 → 状态改为 APPROVED Generator 执行 git commit + push 更新 summary.md 为 DELIVERED 状态 向用户报告交付结果 Dispatch Routing — 任务分级 根据任务复杂度选择不同流程： 级别 判断标准 流程 SIMPLE <10 行代码，单文件 直接 spawn 执行 MEDIUM 多文件，方案明确 gstack-lite（规划 + 自审） HEAVY 需要特定方法论 运行对应 gstack skill FULL 完整功能，多日工作量 双 Agent（Generator + Evaluator） PLAN 先规划后实现 只产出计划，不写代码 决策启发式 <10 行代码？ → SIMPLE 多文件但方案明显？ → MEDIUM 用户指定了 skill（/qa, /review）？ → HEAVY 功能/项目/目标（不是任务）？ → FULL 用户只想规划不想实现？ → PLAN gstack-lite 规划纪律 注入到所有编码 Agent 的基础纪律： # gstack-lite Planning Discipline
- Read every file you will modify. Understand existing patterns first.
- Before writing code, state your plan: what, why, which files, test case, risk.
- When ambiguous, prefer:
- completeness over shortcuts
- existing patterns over new ones
- reversible choices over irreversible ones
- safe defaults over clever ones
- Self-review your changes before reporting done. Check for:
- Report when done: what shipped, what decisions you made, anything uncertain.
目标 {一句话描述要实现什么}
范围
包含 - {功能点 1} - {功能点 2}
不包含 - {明确排除的内容}
验收标准
- {可验证的标准 1}
- {可验证的标准 2}
非目标 - {不在此范围内的内容}
tasks.md 模板 # 任务拆分清单Task 1: {任务名}
- 描述: {具体做什么}
- 输入: {依赖什么}
- 输出: {产出什么文件/功能}
- 验收标准:
- {可验证的检查点 1}
- {可验证的检查点 2}
Single Source of Truth for this change.
创建时间: YYYY-MM-DD
状态: PLANNING | CODING | IN_REVIEW | FIXED | DELIVERED
基本信息
| 字段 | 值 | |------|-----| | 类型 | feat/fix/refactor/chore/docs | | 需求描述 | {一句话} | | 负责人 | Generator Agent + Evaluator Agent | | 创建时间 | {时间} | | 最后更新 | {时间} |阶段状态
| 阶段 | 状态 | 完成时间 | 备注 | |------|------|---------|------| | 1. 规划 | ⏳ 进行中 | — | — | | 2. 评审 | ⏸ 待开始 | — | — | | 3. 编码 | ⏸ 待开始 | — | — | | 4. 自审 | ⏸ 待开始 | — | — | | 5. 独立评审 | ⏸ 待开始 | — | — | | 6. 修复 | ⏸ 待开始 | — | — | | 7. 交付 | ⏸ 待开始 | — | — | code_review.md 模板 # 代码评审报告 v1 评审对象: {功能名} 评审时间: YYYY-MM-DD 评审 Agent: 独立 Code Reviewer评审结论
状态: APPROVED | REVISION_REQUIRED发现的问题
问题 N: {问题标题}
- 严重程度: MUST FIX / SHOULD FIX / LOW / INFO
- 位置:
文件路径— 描述 - 描述: {问题说明}
- 当前代码: ```{language} {当前代码}