AI 功能从外部看起来常常像提示词设计。实际工程里，更重要的工作是上下文设计。 上下文是模型用来推理的材料。它可以包括用户请求、历史动作、检索文档、工具结果、系统规则、产品状态和临时任务记忆。 更多上下文不一定更好。真正有用的问题是：模型为了做出下一步正确决策，究竟需要知道什么？

区分意图和任务状态

长期意图是用户想完成什么。任务状态是目前已经发生了什么。 这两者不应该被混在一起。 比如，“准备部署清单”是长期意图；“Nginx 配置已经验证通过”是任务状态。系统应该保留两者，但使用方式不同。 长期意图帮助系统保持方向。任务状态帮助它避免重复工作或跳过必要步骤。

只检索真正有帮助的内容

检索应该具体。把大量文档直接塞进上下文，反而可能让模型更不可靠，因为重要信号被噪声淹没了。 好的检索层通常会考虑：

• 当前要回答的问题是什么？
• 哪个来源最权威？
• 信息需要多新？
• 当前任务是否有权限使用这份内容？
• 检索结果是否需要引用或可追溯性？

检索不只是搜索，它也是产品信任模型的一部分。

工具会产生新的上下文

当模型调用工具时，工具结果会成为新的上下文。这个上下文应该紧凑、结构化，并且易于检查。 如果工具返回巨大的非结构化文本，下一步模型就需要推断太多。如果工具返回清晰字段、状态和错误，工作流会更容易控制。 工具设计就是带 API 边界的上下文设计。

有意识地忽略

有些信息应该被排除：

• 密钥和凭证。
• 无关历史消息。
• 模型不需要的内部实现细节。
• 当前权限范围之外的用户数据。
• 低置信度的检索内容。

忽略信息不是弱点，而是系统保持聚焦和边界清晰的方式。

上下文是产品界面

用户可能看不到上下文窗口，但他们会感受到上下文质量。 当系统记住正确的事、忘掉无关的事、引用正确来源、选择正确工具、并能从失败步骤中恢复时，用户就会感受到它。 所以我把上下文设计看作产品工程的一部分，而不只是提示词写作。