从Prompt到Harness：让用户反馈分类真正可控

在产品运营的日常工作中，用户反馈是一座巨大的信息金矿。产品评价、使用吐槽、求助建议……这些声音本应成为推动产品迭代的核心驱动力。然而，理解和消化这些海量信息本身就需要投入大量人力：运营团队需要持续整理分类，产品经理需要从零散建议中寻找线索，开发人员则要在模糊描述中定位问题。

Prompt工程的三大困境

随着大模型能力的不断提升，反馈分类看起来像一道非常适合交给AI完成的任务：输入一条用户反馈和一棵分类树，让模型选出最匹配的分类。通过补充业务背景、判断规则和典型案例，Prompt工程帮助我们快速跨过了"模型能否分类"的门槛。但当分类进入真实、复杂且持续变化的业务场景后，问题逐渐显现：分类节点不断增加，判断条件日益复杂，Prompt持续膨胀，维护成本越来越高。更关键的是，模型的行为变得难以控制，系统的稳定性也无法保证。

Harness：重新定义控制框架

在实际应用中，基于Prompt的分类方案面临三个核心挑战。首先，分类并非一道纯粹的语义题。当一条反馈在语义上可以同时匹配多个分类时，决定分类结果的已不再是相似度，而是业务的分类目的和当前关注方向。其次，Prompt与定制链路不断膨胀。越来越多的业务规则、判断条件和例外场景被写入Prompt，同时无法通过通用流程解决的特殊情况又形成了独立的定制链路，规则分散、分支增多，系统越来越难以理解和维护。第三，历史经验会过期。当业务分类标准调整后，模型可能继续参考过去的Few-shot案例，导致正确的反馈被错误归类。模型可以学习过去，但分类系统必须服从业务调整后的方向。

业务的职责：掌握方向盘

Harness的核心理念是在模型外建立一层控制框架，重新划分业务、系统与模型的职责。业务负责定义当前的分类方向，包括每个节点的归入条件（什么应该进入）、排除条件（什么不应该进入）、关键词（用户通常如何表达）以及分类优先级规则。Harness负责将业务定义组织成稳定的分类过程，确保规则被严格执行。模型则专注于理解用户问题，在明确的范围内完成语义判断。

具体实现上，Harness提供了四种不同强度的业务规则控制方式：定向归类（规则命中后直接确定结果，不再进行后续匹配）、范围限定（排除无关分类，模型只在指定范围内判断）、优先推荐（模型在完整分类树中判断，但会优先考虑指定候选）和语义归类（默认方式，由模型完成全量语义匹配）。这种分层控制让业务能够根据判断的确定程度灵活选择介入方式。

如有侵权，请联系删除。