过去与现在 过去有许多上下文工程最佳实践变成了神话，包括：. 过去：给 Claude 规则 现在：让 Claude 使用判断 当我们首次推出 Claude Code 时，我们需要确保 Claude 避免最坏的情况，例如删除文件。这意味着我们会提供特别强有力的指导，但这可能并不总是正确的。例如，在系统提示中，我们曾经说过：在代码中：默认情况下不写注释。绝不要写多段文档字符串或多行注释块——最多一行短小的行。除非用户要求，不要创建规划、决策或分析文档——从对话上下文出发，而不是中间文件。但是，对于某些特定的提示，这种指导可能是错误的。在文档的情况下，用户可能有自己的偏好，或者非常复杂的代码的特定部分可能需要多行注释块。尽管如此，对于旧模型来说，没有这些防护措施，Claude 写的注释在许多情况下是错误的，我们必须接受这个权衡。但是较新的模型具有更好的判断，可以在没有明确规则的情况下很好地处理这些决策。在新的系统提示中，我们说：编写与周围代码看起来很相似的代码：匹配其注释密度、命名和习语。 过去：给 Claude 示例 现在：设计接口 工具使用的第一条规则是给 Claude 示例，说明如何使用它们。随着我们最新模型的推出，我们发现给出示例实际上会将其限制在某个探索空间。与其使用示例，不如更多地考虑您的工具、脚本和文件的设计——Claude 拥有哪些参数，以及如何使它们更具表现力？例如，在 Todo 工具示例中，列出状态为待处理、进行中和已完成的枚举，提示 Claude 如何使用它。对保持一个项目为进行中的指示有助于定义我们请求的行为。 过去：把所有内容放在前面 现在：使用渐进式披露 由于 Claude Code 专注于编码，我们的系统提示中包含了有关如何进行代码审查和验证的详细信息。这些并不总是需要，但当需要时，这些信息至关重要。从那时起，Claude Code 在使用渐进式披露方面变得非常熟练——在合适的时机加载合适的上下文。例如，我们将验证和代码审查移入它们自己的技能，Claude Code 可以选择性地调用。但是渐进式披露不仅适用于技能，我们还有工具。我们的一些工具是“延迟加载”的，这意味着代理必须在使用它们之前使用 ToolSearch 搜索其完整定义。这使我们能够拥有更多的工具（例如我们的任务工具），这些工具在被需要之前不会占用上下文。同样的方式也适用于您的 CLAUDE.md 和 Skill.md 文件。一个常见的神话是，您希望将这些作为每个您可能遇到的已知实践的中央存储库，因为 Claude 否则将找不到它。相反，考虑拥有一个可以在合适时间加载的文件树。 过去：重复自己 现在：简单的工具描述 早期的 Claude 模型有时可能需要重复指令，或者在它们的上下文窗口的末尾更可能听取指令，而不是在开始时。这意味着我们的系统提示有时会在主系统提示中提到工具，以及工具描述中的指示。我们发现我们可以删除这些重复示例，将指示放在工具描述中，而不是系统提示中。 过去：CLAUDE.md 文件中的记忆 现在：自动记忆 我们曾鼓励用户利用 # 热键将内容自动保存到 Claude 的记忆中，以写入他们的 CLAUDE.md。相反，Claude 现在会自动保存与工作相关和与您相关的记忆。 过去：简单的规格 现在：丰富的引用 在计划模式下，Claude Code 很大程度上依赖于包含计划的 markdown 文件。将这些文件存储为计划有助于 Claude 在需要时参考它们。另一个类似的最佳实践是在代码库中存储规格，以便 Claude 在跨越较长项目时进行参考。但我们发现 Claude 可以处理越来越复杂的引用。与简单的 markdown 文件不同，Claude 可以引用我们新的 artifacts 功能创建的 HTML 产物。您还可以以代码形式向 Claude 提供引用。规格也可以是详细的测试套件，或者是 Claude 可能需要移植的不同代码库中的函数。评分标准是另一种引用形式。评分标准允许 Claude 尝试验证您在特定领域的品位（例如，好的 API 设计是什么样的），通过使用动态工作流并为这些评分标准启动验证代理。 将这应用到您的上下文 把这一切结合在一起，当您组装上下文时，这看起来是什么样子？ 系统提示 系统提示与产品上下文密切相关。它告诉 Claude 它正在操作的产品和它在做什么