Harness Engineer系列（三）：Harness工程化——AI编程的最后一里地

前两篇我们说了：Vibe Coding搞不定核心业务逻辑，解法是渐进式DDD让代码结构AI可理解。 但架构演进只是让AI"能写"，写出来的对不对、敢不敢上线，还需要工程化治理。 这就是Harness Engineering。 技术自研，转载请注明出处。

一、Harness Engineering不是概念，是落地体系

2026年3月，Harness Engineering概念提出。而且经过了Openai，Authropic大厂验证。

但大部分公开资料------包括OpenAI、Anthropic的原始实践------要么只谈Agent（怎么构建智能体），要么只谈Harness（怎么加约束），没有人把两者作为一个统一体来定义。

只谈Agent → Vibe Coding，速度起飞但失控。 只谈Harness → 空架子，规则再严没人执行也是摆设。

Harness Engineering的本质不是"给Agent加约束"，是"Agent和约束的统一体"：

Harness Engineering 的产出物 = Agent + Harness

Agent是马，Harness是缰绳。Harness Engineering不是造缰绳，是让马和缰绳成为一个可驾驭的系统。系统工程论讲"系统 = 要素 + 关系"------Agent是要素，Harness是关系（约束、反馈、协调），单独谈要素或单独谈关系都不完整，必须谈系统。

有了理论指导，咱来落地一下吧。

我搞了一段时间，把Harness Engineering落地成一套完整的工程体系：

AI原生Java架构 = 渐进式DDD + Harness工程化 + 多Agent协作

三者的关系：

• 渐进式DDD → 解决"AI能不能写出来"（结构可理解）
• Harness工程化 → 解决"写出来的对不对"（产出可治）
• 多Agent协作 → 解决"怎么高效写"（分工与编排）

缺少渐进式DDD的Harness，就像只有质检没有生产线------质检再严，生产不出东西也没用。 缺少Harness的渐进式DDD，就像只有生产线没有质检------产出再快，不敢上线也没用。

二、Harness的六大核心思想

1. 横纵双向分割

横向分割：每个服务/模块有自己的 spec、changes、wiki
  → 模块自治，不跨模块污染

纵向分割：元Agent（owner）和子Agent（coding/testing/doc-gardening）功能拆分
  → 各司其职，owner管治理，子Agent管执行

系统工程论讲"大系统分解-协调"：先分解为子系统，再由上层协调全局。横纵双向分割就是分解，owner就是协调者。但分解容易协调难------子系统各自最优不等于全局最优，owner的协调不是简单审批，还要裁决冲突（两个模块变更互相影响时谁优先）、维护接口契约（specs/层）、守住全局质量目标（五道门禁）。分解是手段，协调才是目的。

2. 多层索引 + AST行级索引

传统AI编程读整个文件，一个1000行的Service，AI要吃掉全部token。

Harness的做法：代码AST树行级索引。 AI只读它需要的方法、字段、调用链，不读整个文件。

传统：读 OrderService.java → 1000行全进上下文 → token爆炸
AST索引：读 OrderService.submit() → 只进30行 → token节省97%

这是Harness能处理小而多文件的关键基础设施。

3. 渐进式披露

不读未涉及的代码。 AI只加载当前任务相关的模块、实体、接口，不把整个项目塞进上下文。

任务：给Order加退款流程
加载：Order实体 + OrderService + OrderSubmitSpec + 退款相关的wiki
不加载：UserController、SysMenuService、定时任务模块......

4. Human in the Loop

AI不是全自动，关键决策点必须人确认：

• 需求分析的红绿灯门控 --- 红灯必须人处理
• 跨模块变更 --- owner审批
• testing-agent 3轮自愈失败 --- 人工介入
• 变更落地前 --- 人确认影响范围

不是"AI替代人"，是"AI执行 + 人决策"。

钱学森系统工程论有一个核心命题："人机结合，以人为主。" 人做定性判断（"这个需求逻辑断层"），机器做定量计算（"JaCoCo覆盖率80%"）。定性导向定量，定量验证定性------门控不是"人看一眼"这么简单，是定性判断和定量验证的双轨制。

5. Doc Gardening（文档防腐）

定时处理腐化文档------代码改了文档没改，漂移检测自动发现，doc-gardening-agent自动修复或标记。

6. 变更是一等公民

每个变更可追溯、可回滚、有影响分析。出了事知道改了什么、能改回来。

三、.harness/ 目录结构

Harness不是什么框架或工具，是项目根目录下的一个约定目录，承载整个AI工程化体系：

.harness/
├── agents/                          # 🤖 Agent定义层
│   ├── README.md                    #   Agent索引 + 协作流图
│   ├── owner.md                     #   元Agent: 协调者(红线+编排+门控)
│   ├── coding-agent.md              #   编码Agent: 6步脚手架+自检
│   ├── testing-agent.md             #   测试Agent: 自愈3轮+覆盖率
│   └── doc-gardening-agent.md       #   文档Agent: 新鲜度+一致性+漂移
│
├── rules/                           # 📏 规则约束层 (owner维护)
│   ├── 工程结构.md                   #   模块依赖+边界+命名约定
│   ├── 编码规范.md                   #   Java/Vue编码红线+审查清单
│   └── 开发流程规范.md               #   流水线+回滚路线+质量门禁
│
├── skills/                          # 🧩 可复用技能层
│   ├── code-discovery/SKILL.md      #   代码发现: 12场景路由表
│   ├── coding-skill/SKILL.md        #   编码脚手架: 6步+自检清单
│   ├── doc-analysis/SKILL.md        #   需求分析: 红黄绿门控+型态判定
│   ├── expert-reviewer/SKILL.md     #   专家评审: 8维度+热路径检测
│   ├── unit-test-write/SKILL.md     #   测试编写: 模板+覆盖目标
│   └── unit-test-ci/SKILL.md        #   CI门禁: JaCoCo+质量阈值
│
├── specs/                           # 📋 模块契约层
│   ├── README.md                    #   模块图谱+依赖关系
│   ├── system/README.md             #   系统管理模块: 边界+约束
│   ├── quartz/README.md             #   定时任务模块
│   └── generator/README.md          #   代码生成模块
│
├── wiki/                            # 📖 领域知识层 (doc-gardening-agent维护)
│   ├── 领域术语.md                   #   权限字符串+Redis Key+异常码
│   ├── 业务模型.md                   #   实体关系+RBAC模型
│   ├── 数据模型.md                   #   表结构+字段+索引
│   └── 接口协议.md                   #   认证+CRUD模式+公共接口
│
├── changes/                         # 📦 变更管理层
│   ├── active/README.md             #   进行中变更 (coding-agent写入)
│   │   └── {feature}/              #   每个功能一个子目录
│   │       ├── summary.md          #     变更概述+影响+回滚方案
│   │       ├── db-migrations.sql   #     DDL变更
│   │       └── rollback.sql        #     回滚脚本
│   └── shipped/README.md            #   已上线变更 (只读快照)
│
├── requests/                        # 📝 需求分析产出层
│   └── workorder/summary.md         #   需求分析报告
│
└── test-data/                       # 🧪 测试数据层
    └── README.md                    #   测试数据格式+基线说明

四、三层分离：Agent / Skill / Rule

Agent = 执行者（谁来做）
Skill = 能力包（怎么做）
Rule  = 红线约束（不能怎么做）

大部分AI编程只想到Agent，把Skill和Rule混在一起。分开才是质的区别：

• Rule由owner维护，coding-agent必须遵守 → AI不是自由的，是被约束的
• Skill是可复用的能力包 → 经验可以沉淀、传播、迭代
• Agent是角色分工 → 不是一个大Agent什么都干，是各司其职互相校验

五、owner元Agent：不是编排，是治理

role: coordinator
activates: always

owner的职责：

• 红线守护 --- 所有Agent必须在红线边界内工作
• 架构决策 --- 审批跨模块变更，裁决技术选型
• 任务编排 --- 拆分 + 分派给coding-agent / testing-agent
• 质量门控 --- 每阶段设检查点，偏差即阻断

有些小伙伴搞多Agent只做"编排"，owner加了红线+门控，这就是治理。

系统工程论讲综合集成：把多个局部的认知综合成全局判断。 单个coding-agent只能做局部编码决策，owner综合testing-agent的验证结果、doc-gardening-agent的一致性检查、人的领域判断，才能做出全局架构决策。这不是简单分工，是认知的综合------各Agent各自"看"到一部分真相，owner把它们拼成全貌。

六、门控原则：代码落地前软告警，代码落地后硬验证

这八个字解决了AI编程最纠结的矛盾：

|| 阶段 | 策略 | 为什么 | |------|------|--------| | 写代码时 | 软告警 | 创造期不能卡太死，否则AI动不了，效率归零 | | 代码落地后 | 硬验证 | 产出物进了仓库/流水线，必须过门禁，没商量 |

大部分人的做法要么全程软（等于没管），要么全程硬（AI写两行就被拦住写不下去）。分阶段策略才是工程现实------开发时给空间，交付时守底线。

七、需求分析的红黄绿门控

需求进来后，先做意图置信度评估：

• 🟢 绿灯：业务流程闭环，输入输出明确，无核心逻辑断层 → 直接继续
• 🟡 黄灯 ：存在局部歧义，可以推进，但盲区必须标记[🟡待澄清]，归入人类待办 → 继续但留痕
• 🔴 红灯 ：核心逻辑断层、前后矛盾、缺失关键数据源 → 立即终止，不生成任何文件

大部分AI做需求分析是"不管懂不懂都硬分析"，红灯阻断才是对下游负责。 硬分析出来的东西，coding-agent闭眼执行，就是灾难。

型态判定 + 工具路由

需求分析后，判定逻辑型态，动态路由生成工具：

|| 识别型态 | 匹配工具 | 触发门槛 | |----------|---------|---------| | State-Driven | 状态图 stateDiagram-v2 | 状态数 ≥ 4 | | Process-Driven | 时序图 sequenceDiagram | 跨系统调用 ≥ 3 | | Rule-Driven | 决策表 | 条件分支 ≥ 3 |

更关键的是降级修正： 命中2种型态但都低于门槛 → 降级为medium，不激活全套图表。简单CRUD绝不硬画状态机。

技术打标：人机共读的关键接口

stateDiagram-v2 direction LR DRAFT --> PENDING: 提交 (IF校验, DB_INSERT, REDIS_ZSET) PENDING --> PROCESSING: 认领 (REDIS_LOCK, DB_UPDATE)

状态图上不是写"提交"就完了，必须标注IF校验, DB_INSERT, REDIS_ZSET。人看业务语义，机器看技术动作，同一个图，两种信息密度。

下游coding-agent读这个图，它需要知道每一步的技术动作是什么，才能生成正确的代码。 纯业务中文对AI来说就是废话------"提交"两个字，AI怎么知道要写Redis ZSET？

红线阻断 → BLOCKER

红线检查发现冲突后，任务拆分的第一个任务强制固定 为[BLOCKER] 解决红线冲突。coding-agent读到任务列表，第一个就是BLOCKER，绕不过去。

八、coding-agent的6步脚手架

Step 1: 确认需求 → 读specs + MCP探索现有代码模式
Step 2: 数据库变更 → DDL + rollback.sql
Step 3: 后端实体层 → Domain + Mapper + Service
Step 4: 后端Controller → @PreAuthorize + @Log
Step 5: 前端API → request.js封装
Step 6: 前端页面 → 组件 + 路由 + 权限

每步完成后执行自检清单，生成后expert-reviewer做8维度审查。

九、testing-agent：自愈3轮

测试失败不是直接丢给人，先自动修3轮：

• 大部分简单问题1轮就能修
• 3轮覆盖了绝大多数可自愈场景
• 3轮修不好 → 人工介入，不硬撑

3轮上限不是拍脑袋------它是反馈增益的安全阈值。自动修一轮是一轮负反馈（纠偏），但每轮修正都有引入新问题的可能。不设上限，就可能振荡（改了又坏、坏了又改）。3轮是经验上"覆盖绝大多数可自愈场景"和"振荡风险可控"的平衡点。

十、变更是一等公民

changes/
├── active/    ← 进行中（可写）
│   └── {feature}/
│       ├── summary.md          ← 变更概述+影响+回滚方案
│       ├── db-migrations.sql   ← DDL变更
│       └── rollback.sql        ← 回滚脚本
└── shipped/   ← 已上线（只读快照，不可修改）

这解决了Vibe Coding最被诟病的问题：出了事不知道改了什么、改不回来。 变更可追溯、可回滚、有影响分析。

十一、Agent协作：持久化到md文件

Agent之间不直接通信，通过共享文件系统间接协作：

coding-agent 写 → changes/active/{feature}/summary.md
testing-agent 读 → 同一文件，写回测试结果
owner 读 → 所有产出，做门控判断
doc-gardening-agent 读 → 代码变更，更新wiki/

好处：

• 可追溯 --- md文件就是协作日志
• 可人工介入 --- 人随时能读md了解状态
• 无状态依赖 --- Agent崩溃重启无损失
• 可审计 --- 每一步产出都有物证

十二、doc-gardening-agent：最容易被忽视但最致命

代码改了文档没改，后面AI基于过期文档生成代码，就是灾难源头。专门设一个Agent管文档新鲜度、一致性、漂移检测。

从反馈回路的视角看，doc-gardening-agent跑的是一条正反馈回路 ：文档漂移检测 → 修复 → 文档更准确 → AI基于文档生成的代码更准 → 代码变更更少 → 文档漂移更少。系统越用越准，而不是越用越烂。

十三、MCP基础设施：AST代码树 + 趿会话记忆

Harness的coding-agent能高效处理小而多文件，靠的是两个MCP工具：

codegraph --- AST代码图

"codegraph": {
  "command": "npx",
  "args": ["-y", "@colbymchenry/codegraph", "serve", "--mcp"]
}

codegraph构建代码的AST（抽象语法树）图结构，提供：

• 符号级搜索 --- 按类名、方法名、字段名精准定位，不需要全文搜索
• 调用链追踪 --- trace_path 追踪方法调用链，检测跨模块越界
• 依赖图分析 --- query_graph 检测循环依赖、热路径（O(n²)隐患）
• 语义搜索 --- search_graph 按功能关键词搜索已有相似实现，避免重复代码
• 变更影响检测 --- detect_changes 检测最近变更的波及范围

有了AST索引，Claude Code处理小而多的文件毫无压力 --- 不需要读整个文件，精准定位到方法级别。

codebase-memory-mcp --- 趿会话代码记忆

"codebase-memory-mcp": {
  "command": "/path/to/codebase-memory-mcp",
  "args": []
}

codebase-memory-mcp提供跨会话持久化记忆：

• 架构决策记录（ADR） --- 上次会话做的架构决策，下次会话还能看到
• 代码模式记忆 --- 这个项目Controller/Service/Mapper的范式是什么，不用每次重新探索
• 踩坑记录 --- 上次在这个项目犯过的错，下次不再犯

两个MCP配合：codegraph解决"当前会话的代码理解"，codebase-memory-mcp解决"跨会话的知识积累"。

十四、硬验证工具链：代码落地后的五道门禁

代码落地后，硬验证自动执行，过不了就不让过：

1. maven-enforcer-plugin --- 环境锁定

锁定JDK版本和Maven版本，防止"我本地能跑你本地不能跑"：

<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <configuration>
    <rules>
      <requireJavaVersion><version>[1.8,1.9)</version></requireJavaVersion>
      <requireMavenVersion><version>[3.6.3,)</version></requireMavenVersion>
    </rules>
  </configuration>
</plugin>

2. ArchUnit --- 架构守卫

用单元测试守卫架构规则，防止依赖腐化：

@ArchTest
static final ArchRule no_cycle_dependencies = slices()
    .matching("com.ruoyi.(*)..")
    .should().beFreeOfCycles();

@ArchTest
static final ArchRule no_field_injection = noFields()
    .should().beAnnotatedWith(Autowired.class)
    .because("必须使用构造器注入");

@ArchTest
static final ArchRule no_raw_http_client = noClasses()
    .that().resideOutsideOfPackage("..infrastructure..")
    .should().dependOnClassesThat()
    .haveNameMatching("HttpClient|RestTemplate")
    .because("HTTP客户端只能在基础设施层使用");

ArchUnit是架构规则的可执行化------架构文档写"模块不可循环依赖"，ArchUnit让它真的不能。

3. Checkstyle --- 编码规范强制

<plugin>
  <artifactId>maven-checkstyle-plugin</artifactId>
  <configuration>
    <configLocation>checkstyle.xml</configLocation>
    <failOnViolation>true</failOnViolation>
  </configuration>
</plugin>

自定义规则：必须显式声明版本号、禁止魔法数字、命名约定等。failOnViolation=true --- 违规即构建失败。

4. SpotBugs --- 静态缺陷检测

SpotBugs（FindBugs继任者）检测常见缺陷模式：

• 空指针解引用
• 资源泄漏（未关闭的Stream/Connection）
• 并发问题（错误的double-checked locking）
• 不安全的反射调用

5. JaCoCo --- 覆盖率门禁

<plugin>
  <groupId>org.jacoco</groupId>
  <artifactId>jacoco-maven-plugin</artifactId>
  <configuration>
    <rules>
      <rule>
        <element>BUNDLE</element>
        <limits>
          <limit><counter>LINE</counter><value>COVEREDRATIO</value><minimum>0.80</minimum></limit>
        </limits>
      </rule>
    </rules>
  </configuration>
</plugin>

行覆盖率 ≥ 80%，不达标构建失败。 覆盖率不是装饰，是门禁。

五道门禁的协作

代码落地 → maven-enforcer（环境）→ ArchUnit（架构）→ Checkstyle（规范）→ SpotBugs（缺陷）→ JaCoCo（覆盖）
           ↓                        ↓                     ↓                    ↓                  ↓
           JDK/Maven版本不对         循环依赖/字段注入       命名违规              空指针/资源泄漏      覆盖率不足
           → 构建失败               → 测试失败             → 构建失败            → 构建失败          → 构建失败

任何一道门禁失败，代码就不可能进入仓库。

十五、AI工具Hook：写代码时的实时拦截

硬验证在CI里跑，但有些问题可以在AI写代码的瞬间就拦截------PreToolUse / PostToolUse Hook：

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "checkstyle_check" },
          { "type": "command", "command": "eslint_check" }
        ]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          { "type": "command", "command": "type_checking" }
        ]
      }
    ]
  }
}

工作原理：

|| Hook时机 | 触发条件 | 做什么 | |----------|---------|--------| | PreToolUse | AI执行Edit或Write之前 | 先跑checkstyle/eslint，格式不对就不让写 | | PostToolUse | AI执行Edit或Write之后 | 跑type_checking，类型错误立即发现 |

这就是"代码落地前软告警"的工程化实现------AI写代码的瞬间就校验，不用等到CI。

对比传统流程：

传统：写代码 → 提交 → CI跑 → 10分钟后发现checkstyle不过 → 修 → 再提交 → 再等CI
Hook：写代码 → 瞬间checkstyle → 不对就当场拦住 → AI立刻修正 → 提交时已经合规

反馈从10分钟缩短到0秒，这是AI编程效率的关键杠杆。

十六、3天 → 30分钟

|| 传统3天 | Harness 30分钟 | |---------|---------------| | 人读需求 | doc-analysis自动分析（红黄绿门控+型态判定） | | 人写代码 | coding-agent 6步脚手架生成 | | 人写测试 | testing-agent自动+自愈 | | 人做CR | expert-reviewer 8维度审查 | | 人写文档 | doc-gardening-agent自动维护 | | 人管变更 | changes/自动追踪 |

人做什么？做owner的事------定红线、审门禁结果、处理3轮自愈失败的case。

从"什么都干"变成"只做审查和决策"。

十七、Vibe Coding + Harness = 生产可用

没有Harness → Vibe Coding = 赌博，生产环境绝对不行
有Harness   → Vibe Coding = 有安全网的赌博，风险可控（如果你要这样搞，干脆直接写TODO告诉AI这里该干啥）
Harness + 渐进式DDD → Vibe Coding = 工程化可控，灰度验证（别问我为啥不直接发生产，问就是挨过打）

Vibe Coding是现象，Harness Engineering是解法，渐进式DDD是根基。三者合一，就是AI原生Java架构。

十八、系统工程论视角：Harness为什么能work

前面十七章把Harness的落地讲完了。但有一个问题一直悬着：这套体系为什么能work？是经验凑巧，还是有更底层的道理？

答案是后者。Harness的每一个核心设计，都能在钱学森系统工程论中找到对应原理。不是牵强附会------是工程直觉走到的地方，系统论已经给出了理论根基。

综合集成：多Agent协作的本质

钱老的核心方法论：综合集成 = 专家体系 × 机器体系 × 信息体系。

单个Agent的认知是局部的------coding-agent只看代码，testing-agent只看测试结果，doc-gardening-agent只看文档一致性。owner把它们综合起来，才能形成全局判断。这不是"分工"，是从局部认知到全局判断的涌现。

对应到Harness：Agent = 专家体系，MCP工具 = 机器体系，wiki/changes/ = 信息体系。三者综合，产出大于各自之和。

人机结合以人为主：门控的理论根基

钱老说："人机结合，以人为主。人要起主导作用，机器起辅助作用。"

为什么必须以人为主？因为开放复杂系统中，定性判断（人的经验直觉）和定量计算（机器的精确推理）缺一不可，但定性判断是导向，定量计算是支撑。

对应到Harness：红灯阻断、跨模块审批、3轮自愈失败介入------这些是人的定性判断。JaCoCo 80%、ArchUnit架构规则、SpotBugs缺陷数------这些是机器的定量验证。定性导向定量，定量验证定性，双轨闭环才是门控的完整逻辑。

分解-协调：横纵分割的数学基础

系统工程论：大系统 → 分解为子系统 → 上层协调 → 全局优化。

横纵双向分割是分解，owner是协调。但分解容易协调难------子系统各自最优 ≠ 全局最优。owner的协调不只是审批，还要裁决冲突（两个模块变更互相影响时谁优先）、维护接口契约（specs/层）、守住全局质量目标（五道门禁）。分解是手段，协调才是目的。

反馈控制：门控的回路化

系统工程论要求闭环反馈，不能只做单向检查。Harness里至少有三条反馈回路：

负反馈（纠偏稳定）：
  编码 → 门禁失败 → 修正 → 再验证 → 通过
  （testing-agent自愈3轮就是负反馈------每轮纠偏，趋向稳定）

正反馈（良性增强）：
  文档漂移检测 → 修复 → 文档更准 → AI生成更准 → 变更更少 → 漂移更少
  （doc-gardening-agent跑的是正反馈------系统越用越准）

增益上限（防止振荡）：
  自愈3轮上限 → 防止改了又坏、坏了又改的无限循环
  （3不是魔法数字，是"覆盖大多数可自愈场景"和"振荡风险可控"的平衡点）

大部分人的门控是开环的------检查完就完了，没有回路。Harness的门控是闭环的------检查完有反馈，反馈有增益控制，增益有上限。开环只能发现问题，闭环才能解决问题。

系统演化：渐进式的理论根基

第二篇讲的"渐进式DDD"------"不到需要的时候不拆"------是极好的工程直觉。系统演化理论给出了根基：系统从简单到复杂的结构化，是环境压力驱动的。 没有环境压力，过度结构化是浪费；环境压力增大，结构化是生存必需。

• 项目初期复杂度低 → 环境压力小 → 不需要spec/policy的结构化
• 项目中期上帝类苗头 → 环境压力增大 → 必须spec/policy分化，否则系统退化
• 项目后期跨聚合复用 → 环境压力更大 → policy独立、spec按场景拆

"拆的时机不是架构图好看，是不拆就看不懂了" ------本质是：系统结构化的时机 = 系统熵增到临界点的时刻。结构化有成本（认知负担、维护成本），只有当不结构化的成本超过结构化成本时，才结构化。这不是懒，是最小必要结构化原则。

系统边界：Harness的环境定义

系统工程论要求先定边界再分析系统。Harness的系统边界：

系统内：.harness/ 目录下的一切（agents、rules、skills、specs、wiki、changes）
环境：代码仓库、CI/CD流水线、运行时环境、团队组织
接口：changes/（变更进出）、门禁结果（信息输出到CI）、wiki/（知识输入给Agent）

边界内的事Harness管，边界外的事Harness不碰但通过接口感知。边界不清，优化无从谈起。

小结

Harness设计	系统工程论原理	一句话
多Agent协作	综合集成	局部认知→全局判断
Human in the Loop	人机结合以人为主	定性导向定量，定量验证定性
横纵分割+owner	分解-协调	分解是手段，协调是目的
门控+自愈+文档防腐	反馈控制	闭环才能解决问题
渐进式DDD	系统演化	最小必要结构化
.harness/目录边界	系统边界	先定边界再优化

没有理论根基的实践，叫"经验"；有理论根基的实践，叫"方法论"。 经验只能模仿，方法论可以迁移。Harness Engineering不是拍脑袋想出来的，是工程实践和系统工程论在AI编程这个新领域的交汇。

---

本文是"AI原生Java架构"系列第三篇。Harness Engineering不是概念，是落地的工程体系------.harness/目录、红黄绿门控、型态判定、技术打标、多Agent协作、变更管理、MCP基础设施、五道硬验证门禁、AI工具Hook。传统3天开发→30分钟。其核心设计可在钱学森系统工程论中找到理论根基------综合集成、人机结合、分解-协调、反馈控制、系统演化------工程直觉走到的地方，系统论已经给出了答案。