文章目录
-
- [核心理念：从"Prompt Engineering"到"Environment Engineering"](#核心理念：从"Prompt Engineering"到"Environment Engineering")
- Harness的结构：4层闭环系统
- 关键问题1：架构约束从哪里来？
- 关键问题2：AI反复犯同样错误怎么办？
- 关键问题3：复杂业务逻辑谁来实现？
- 关键问题4：团队如何跨越"学徒缺口"？
- 为什么这套设计必然胜出？
- 立即上手的1周MVP
- 终局图景
在2026年，AI Agent已经能写出90%的代码，但为什么大多数团队仍然深陷"AI效率陷阱"？答案是：你还在教AI怎么写代码，而不是教环境怎么约束AI。
Harness Engineering（驾驭工程）不是新技术，而是一种系统设计哲学：工程师不再是"写代码的人"，而是"设计能让AI可靠干活的环境设计师"。
核心理念：从"Prompt Engineering"到"Environment Engineering"
传统Prompt工程的问题：
用户：写一个用户管理系统
AI：给你一个单文件5000行monolith
用户：不够分层啊
AI：给你一个6层嵌套的过分抽象
用户：架构不对
AI：给你一个用10种设计模式过度工程化的版本Harness Engineering的洞察：
AI就像3岁的学徒：给你任务，它会拼尽全力按自己的理解去做，但通常会犯低级错误。与其教它"这次别犯错"，不如设计一个让它"没法犯错"的工作间。
工作间(Harness) = 工具箱 + 安全围栏 + 操作手册 + 质量检查站
学徒(AI Agent)只负责在你设计的车间里"按流程干活"Harness的结构：4层闭环系统
┌─────────────────────────────────────┐
│ 第4层：人类监督（兜底5%复杂判断） │
├─────────────────────────────────────┤
│ 第3层：质量关卡（CI/Linter/测试） │ ← 自动拦截90%错误
├─────────────────────────────────────┤
│ 第2层：约束环境（仓库结构+工具） │ ← 让正确行为成为唯一选择
├─────────────────────────────────────┤
│ 第1层：上下文系统（知识库+动态数据）│ ← Agent真正能"看到"的信息
└─────────────────────────────────────┘每一层都有明确职责，缺一不可。
关键问题1：架构约束从哪里来？
问题本质：没有大牛架构师，如何保证AI不产生"屎山代码"？
错误思维 ：指望AI理解"Clean Architecture"
正确思维 ：把架构变成AI没法违反的物理约束
❌ AI自由发挥 → 随机架构
✅ 仓库结构+规则 → 强制分层架构具体解法：
# 仓库物理结构（第2层约束）
src/
├── ui/ # 只能依赖 service/
├── service/ # 只能依赖 domain/
├── domain/ # 只能依赖 infra/
└── infra/ # 叶子节点
# Linter规则（第3层关卡）
ESLint: ui/*禁止import infra/*
ArchUnit: Controller不依赖Repository
CI Gate: 违反=PR不能合并背后的原因 ：人类大脑能记住抽象原则，AI只能记住具体禁令。与其教AI"分层架构的好处"，不如让它连违反分层的代码都写不出来。
关键问题2：AI反复犯同样错误怎么办？
问题本质：AI有"健忘症"，今天教会的明天忘。
错误思维 ：写更详细的prompt
正确思维 ：把经验固化进环境，让错误结构上无法重现
案例：AI在组件里直接写API调用
第1次：人工Review发现
第2次：加ESLint规则禁止 → 自动报错+给出正确写法
第3次：永远不会再犯，因为语法上不允许具体流程（第3层质量关卡进化）：
发现错误 → 分类（架构/安全/性能） → 工程化固化 → 自动检查
↓
Linter规则 / 测试用例 / CI Gate / 文档反例背后的原因 ：AI的"记忆"在对话窗口里，Harness把记忆永久刻在文件系统和CI管道里。
关键问题3：复杂业务逻辑谁来实现？
问题本质：简单CRUD交给AI没问题，但复杂风控/定价逻辑呢？
错误思维 ：让AI直接写复杂逻辑，你全量Review
正确思维 ：人定边界+验收标准，AI负责实现+自验证
人类介入的3个固定点（第4层）：
1. 规格评审：输入输出+10个正反例
2. 测试评审：AI先生成测试用例，覆盖关键场景
3. 行为抽检：上线后抽样验证（而非看代码）具体解法：
需求：复杂定价规则
↓
规格文件：输入→规则表→输出 + 边界case
↓
AI：先生成测试用例（人审）→ 实现逻辑 → 自测通过
↓
CI：Lint+测试+安全检查通过 → 自动部署
↓
人：抽10%真实流量验证行为（而非代码）背后的原因 ：代码是实现的一种，行为才是真理。与其审5000行你看不懂的实现，不如直接验证最终行为。
关键问题4：团队如何跨越"学徒缺口"？
问题本质：新人只会操作AI，老人忙不过来，如何培养Harness设计师？
错误思维 ：让所有人直接用AI，省时省力
正确思维 ：保留"手动踩坑→抽象规则"的训练路径
成长三阶段：
阶段1：手动实现完整业务链路 → 形成系统直觉
阶段2：把踩坑经验转Linter/CI规则 → 学会"从错误到约束"
阶段3：设计Harness → 成为环境设计师团队资产化：
经验库：
├── ADR.md（为什么这么设计）
├── anti-patterns.md（经典错误+防护规则）
└── harness-rules/（Linter/测试模板）背后的原因 ：系统直觉不是天生的，需要从具体案例中抽象。AI可以加速实现，但判断力需要真实踩坑积累。
为什么这套设计必然胜出？
数学原因：错误率呈几何递减
传统：错误率10%，100次任务→10次人工
Harness：第1次10%，第2次1%，第N次→0%
→ 100次任务→1次人工经济原因：把"重复认知税"自动化
原成本：每个新人重复犯老错误
新模式：错误只犯一次，永久固化工程原因：符合"约束优于自由"的普适规律
操作系统：用户态进程无法直接操作硬件
浏览器：JS沙箱无法随便发网络请求
Harness：AI无法违反仓库规则和CI约束立即上手的1周MVP
Day1：仓库重构 → docs/AGENTS.md + 分层目录
Day2：3条Linter规则 → 依赖方向+命名规范+安全底线
Day3：CI模板 → lint+test双保险
Day4：工具脚本 → make test/run/logs
Day5：写1个复杂需求的规格 → AI全自动实现
Day6：收集错误 → 转2条新规则
Day7：80%CRUD需求零人工介入终局图景
2026年：工程师=AI操作员
2027年：工程师=Harness设计师
2028年：Harness=团队核心竞争力Harness Engineering不是技术变革，是组织变革。它把"写代码的重复劳动"交给AI，把"设计可靠系统的创造性工作"还给人类。