QQ音乐Harness-Engineering实践

一句话概括

本文介绍了QQ音乐团队在大仓多服务场景下自研Harness Engineering框架的实践，通过五阶段四门禁流程、三层知识体系和三仓联动机制实现AI协作的工程化治理。

摘录

当 AI 开始快速生成大量代码，真正的瓶颈就不再是”写不出来”，而是”看不完、想不清、管不住”。Harness Engineering 的核心理念是：AI 参与问题分析、方案设计、编码实现、审查和验证，但最终判断权始终留在工程师手中。Engineering 的本质是约束下的优化——在质量、安全、可维护性等约束下寻找最优可行解。

代码产出 = AI 能力 × 上下文质量——这个乘号至关重要。如果公式是加法，那么模型足够强的时候，上下文差一点也无妨。但乘法的含义截然不同：当上下文质量趋近于零时，模型再强，产出也是零。提升上下文质量，是比提升模型能力更高效的杠杆。因为模型能力的提升依赖外部厂商，而上下文质量的提升，完全掌握在团队自己手中。

自研 Harness Engineering 并不意味着我们要重造 Cursor、CodeBuddy 或 Claude Code。我们只补齐一层：L5 工程治理层。Harness Engineering 的边界非常清晰：不替代执行工具，只定义执行工具必须遵守的工程上下文和协作协议。工程规范与 AI 工具解耦。今天用 Claude Code，明天换 Superpower 类新工具，流程和知识都不丢。

Self-Refinement 闭环：当用户纠正 AI 某个错误后，AI 识别这是”模式性教训”还是”一次性 diff”，主动提议沉淀层级（团队级/框架工程级/服务级），生成经验文档、更新 Skill 或修订规范，下次同类场景 AI 主动引用。错误不再”走一次算一次”，而是成为团队资产。

涉及实体

• Harness-Engineering —— 作为L5工程治理层在QQ音乐落地

涉及主题

• Harness-Engineering-主题 —— 五阶段四门禁、三层知识体系、Self-Refinement