【欢乐分享】分享一些 Harness 工程经验

以下是我的一个回帖，我觉得这些经验也可以分享给更多的佬友，所以把它发成主帖。

介绍一下 Harness 工程

Harness 工程改造就是一种让项目可以被 harness 工具管理起来的一种改造。

harness 不友好的项目

你需要通过提示词描述现状，如果不描述，ai 就会随机读文档乱猜抽卡。

会话和会话之间你需要总结上下文传递，确保新开会话后 ai 对项目仍然理解。

缺少严格的门禁要求（定义项目的质量），质量不好的代码仍然会被提交进 repo，慢慢累积起技术债。

harness 友好的项目

项目现状和文档同步，ai 知道从哪里了解到必要信息。你只管说需求，跨会话，跨工具

所有 feature 的设计思路都会在文档中体现，ai（甚至人类）能通过文档知道为什么这样设计，逻辑细节如何进行

如果想了解更多，看这个社区文章即可，是中文的：

对现存的项目，可以直接用我的提示词跑一波改造:

参考 https://openai.com/zh-Hans-CN/index/harness-engineering 最佳实践，在新建 harnessing 分支对本项目做 harness 化改造。

前置要求：不要直接修改代码。先完成项目扫描，输出一份可评审的《Harness工程化改造计划文档》放到仓库内，文档里拆解下面5个阶段，每个阶段列出详细子任务、产出物与验收标准；计划文档确认之后，再按顺序从阶段1开始落地实施。

1. 全量扫描项目代码，识别架构、复杂度、重复代码、缺少文档/测试、以及安全、性能等潜在问题，输出结构化问题清单与分优先级解决计划。


2. 整理并补全项目文档，清理过时内容，确保文档与代码现状保持对齐。


3. 审计现有代码提交门禁，查漏补缺，完善自动化质量校验，保证每次提交保证项目可构建、质量可控。


4. 按计划落地问题修复与代码重构：拆分臃肿模块、落实单一职责、降低代码复杂度、抽离公共可复用逻辑；修改代码时同步更新文档。


5. 为重构代码与原有缺失场景编写完整测试，加入门禁自动化校验。

提交要求：

保持合理小粒度提交；commit message清晰描述本次变更内容；commit history可以完整追溯整个harness改造过程。

重构原则：保留原有业务行为，bug修复和业务变更在问题清单中显式标注。所有文档、清单、测试文件纳入仓库版本管理。

注意，上面 5 个步骤你可以根据情况删除不适合你的。步骤 3（改你的测试）、4（重构你的工程）、5（写更多测试） 会改动你的代码。特别是步骤 4，如果你满意现在的工程架构可以删除这项改造。