上下文优先设计 Context-Aware Design Method CADM

01当智能体输出不达预期，第一反应总是错的

在许多企业的 AI 项目评审中，有一个固定的讨论模式：当智能体的输出质量不达预期，第一个被提出的解决方案几乎总是"换一个更好的模型"，或者"调整一下提示词"。

这两个动作都会被执行，有时候也有效果，但一段时间之后，问题往往以不同的形式再度出现。

问题的根源很少被触及，因为它不在模型能力上，也不在提示词技巧上。它在一个更基础的地方：智能体处理的上下文（Context），决定了它能看到什么信息，而它能看到什么，决定了它能产生什么输出。

上下文设计的质量，是限制智能体输出质量的首要因素，而不是模型能力。在同等模型条件下，上下文设计的差距可以让输出质量相差数倍。但奇怪的是，在大多数产品团队的工作流里，上下文设计所获得的关注，远少于功能开发和提示词工程。

02三种人群对"上下文"的认知错位

"上下文"这个词，在技术人员、产品经理和业务人员那里，有三种完全不同的理解，而这种理解的分歧，是上下文设计经常出问题的根源。

技术人员通常把上下文理解为"传入模型的输入文本"——一个纯粹的工程参数，越长越好，信息越全越好。这种理解导致的常见问题是：把所有可能相关的信息都塞入上下文，然后发现输出质量反而下降了，因为模型在噪声里失去了焦点。

产品经理通常把上下文理解为"用户提供的背景信息"——是用户侧的输入，产品设计者的工作是设计一个好的界面让用户输入这些信息。这种理解的常见问题是：过度依赖用户的自觉性和表达能力。

业务人员通常根本不把上下文当作一个需要设计的东西——他们认为"AI 应该能理解我说的话"，上下文问题是技术团队的责任。

三种理解都不完整，它们共同导致了一个结果：没有人把上下文当作产品设计的核心工作来做。

03把感知系统当作产品来设计

重新认识上下文，需要一个视角的根本转换：不要把上下文当作参数，而要把它当作智能体的感知系统。

这个转换有实质性的含义。感知系统决定了一个智能体能理解的世界的边界——它看不到的，不存在；它看到的，是它判断和行动的全部依据。一个感知系统设计糟糕的智能体，即使拥有强大的"处理能力"（模型能力），也无法产生高质量的输出。

上下文优先设计的核心主张是：先设计智能体需要看到什么，再设计它应该做什么。这个顺序的改变看起来不大，但它意味着产品设计的起点从"功能规格"变成了"信息需求"。

系统上下文（System Context）

最稳定的一层：角色定义、工作原则、行为边界、价值观设定。回答的是"这个智能体是谁"。系统上下文一旦设计好，在相当长的时间里不应该频繁变动。

任务上下文（Task Context）

每次任务特定的信息：任务的目标、相关的背景数据、已知的约束条件。设计挑战是：既要包含完成这个任务真正需要的信息，又要避免引入不相关的噪声。

历史上下文（Historical Context）

记忆和学习的载体：过去的交互记录、用户的偏好模式、之前任务的结果和反馈。设计挑战不是记住多少，而是记住什么——决定什么历史信息值得被保留。

动态上下文（Dynamic Context）

实时变化的环境信息：当前时间、用户的当前状态、外部系统的实时数据、任务执行过程中产生的中间信息。最难设计，因为它要求在运行时进行信息的实时获取、过滤和注入。

四层之间有优先级规则：动态 > 任务 > 历史 > 系统——越具体、越即时的信息，优先级越高。但系统上下文有一类特殊的"不可覆盖规则"（边界和安全约束），这类规则不被任何其他层次的信息覆盖。

04精准胜过丰富

上下文优先设计揭示的，是一个关于"AI 能力上限"的重新定位。

大量企业把提升 AI 输出质量的期望放在"模型能力"上——等待更强的模型发布，或者负担更贵的模型费用。这种期望有其道理，但它忽略了一个关键事实：在任何给定的模型能力水平下，上下文质量对输出质量的影响，往往大于模型能力的提升。

模型是上限，上下文是实际表现。换句话说，花在上下文设计上的工程和产品资源，其单位回报往往高于花在模型升级上的资源。

精准胜过丰富。上下文中的噪声——与当前任务无关的信息——是智能体性能下降的主要原因之一。不是因为模型"读不懂"这些信息，而是因为不相关的信息会分散模型的注意力，模糊真正重要的信号。

在大量实践中，删减上下文带来的性能提升，往往比增加上下文更显著。确定什么不该放入，有时比确定什么该放入更重要。

05调试方式和迭代优先级的改变

这个框架最直接改变的，是智能体系统的调试方式和迭代优先级。

没有这个框架时，当智能体输出质量不达预期，团队通常优先考虑：优化提示词、升级模型版本、增加训练数据。这三个方向都可能有效，但都是在假设"感知系统是合理的，处理能力需要提升"。

有了这个框架，第一步变成了：审查上下文设计。检查系统上下文是否准确定义了角色和边界，任务上下文是否包含了真正需要的信息而没有引入噪声，历史上下文是否调用了正确的历史记录，动态上下文是否成功注入了关键的实时信息。

这个审查往往会发现，质量问题的根源不在模型能力，而在"给了模型错误的信息"或"没有给模型它需要的信息"。这类问题的修复成本，远低于模型升级，效果却可以非常显著。

先审上下文，再优化能力——这个顺序的改变，可以为一个团队节省大量被浪费在错误方向上的工程资源。