一文读懂Harness

Lantuzi

10.3 三大空白区

以下是目前文献中被反复提及但缺乏解决方案的领域，也是最值得投入探索的方向。

空白 1：棕地项目的 Harness 改造。所有公开成功案例——OpenAI、Carlini、Anthropic、Stripe、Hashimoto——全部是绿地项目或可控环境。对于十年历史的遗留代码库如何引入 Harness Engineering，目前零成功案例、零方法论。Martin Fowler 将其比作"在从未用过静态分析工具的代码库上运行静态分析——你会被警报淹没"。如何在不重写的前提下渐进式引入 Harness？从哪些约束开始投入产出比最高？是否需要先用 AI 做一轮"代码考古"再建 Harness？全部待解。

空白 2：功能和行为验证的系统化方案。Böckeler 对 OpenAI 报告最尖锐的批评：大量讨论了架构约束和熵管理，但功能正确性验证几乎缺席。Anthropic 承认 Agent 倾向于不做端到端测试就标记功能完成。即使提供了 Puppeteer MCP，也有局限——Agent 看不到浏览器原生 alert 弹窗。Carlini 的编译器项目用 GCC torture test 做功能验证（99% 通过率），但那是有明确正确性标准的特殊领域。目前大家擅长的是"约束 Agent 不做错事"（架构约束、Linter、类型检查），但"验证 Agent 做对了事"这个问题远未解决。

空白 3：AI 生成代码的长期可维护性。Brockman 抛出的问题至今无人回答：怎么防止"功能没问题但维护性很差"的代码渗透进代码库？Agent 写的代码和人写的代码，积累技术债的方式不一样——LLM 生成的代码经常重新实现已有功能（Carlini 专门分配了"去重 Agent"来解决这个问题）。"垃圾回收" Agent 是一种新兴做法，但长期效果还缺乏数据。代码审查标准是否需要针对 AI 生成代码做根本性调整？这个问题完全开放。

10.4 共识与分歧速查表

领域	共识程度	核心结论
基础设施 > 模型智能	★★★★★	全面共识。6+ 来源支持，无反对。
思考与执行分离	★★★★★	全面共识。所有团队独立发现。
文档作为活反馈循环	★★★★☆	强共识。做法细节有差异，原则一致。
上下文不是越多越好	★★★★☆	强共识。有量化数据（~40% 甜蜜区间）。
约束必须机械化执行	★★★★☆	强共识。Linter、CI、结构测试是标配。
工程师角色转变	★★★★☆	强共识。方向一致，具体分工在演化中。
人类介入程度	★★★☆☆	部分共识。方向是减少介入，取决于 Harness 成熟度。
Harness 简化 vs 精细化	★★☆☆☆	存在分歧。取决于通用产品 vs 定制项目。
单 Agent vs 多 Agent	★★☆☆☆	存在分歧。规模决定选择，缺乏通用指导。
术语边界定义	★★☆☆☆	存在分歧。嵌套 vs 互补，术语能否存活存疑。
功能验证方法	★☆☆☆☆	严重缺失。被指出但无解决方案。
棕地项目改造	★☆☆☆☆	完全空白。零成功案例，最大实践缺口。
AI 代码长期可维护性	★☆☆☆☆	完全空白。问题已提出，无人回答。

---