$ man context-wiki/context-engineering

Andrej Karpathy 将其称为"用恰到好处的信息为下一步填充上下文窗口的艺术"。这是我见过最好的一句话定义。上下文工程不是写更好的提示词。它是在 AI 看到你的提示词之前，架构好 AI 能访问的信息。同一个 AI 模型加上差劲的上下文等于千篇一律的垃圾。同一个 AI 模型加上丰富、结构化的上下文等于听起来像你、了解你的业务、无需手把手指导就能执行你的工作流的输出。大多数人完全跳过了这一步。他们打开 Claude，从头开始重新解释整个业务，然后纳闷为什么输出感觉很肤浅。这不是 AI 的问题。这是上下文的问题。

模式

提示词工程是精心设计问题。上下文工程是在你提问之前架构好 AI 所知道的一切。可以这样理解。提示词工程："帮我写一封给 SaaS 公司销售副总裁的冷邮件。" 上下文工程：加载你的 ICP 定义、角色画像层级、语音指南、消息框架，以及三封获得回复的邮件范例。然后说"写那封冷邮件"。提示词只有一句话。上下文是其他所有东西。大多数人专注于提示词而忽略了上下文。这就像给新员工完美的指令却没有任何入职培训。如果他们不了解你的业务，再好的指令也没用。

专业技巧

我的整个 GTM OS 仓库就是一个上下文工程系统。CLAUDE.md 加载环境默认值。Skills 加载工作流指令。Rules 加载文件特定的模式。合作伙伴文件夹为每个客户加载 ICP、角色画像和消息框架。当我输入 /deploy 时，Claude 已经知道 Git 工作流、Vercel 设置、三个域名和构建验证步骤。我没有在提示词中解释这些。它们已经在上下文窗口中了。这就是使用 AI 和工程化 AI 的区别。如果你每次会话都在向 Claude 解释同样的东西，那你做的恰恰是上下文工程的反面。

模式

上下文工程会产生复利效应。你写的每一份语音文件都让未来的内容变得更好。你构建的每一个技能都让未来的工作流更快。你组织的每一个合作伙伴文件夹都让未来的入职流程更清晰。你不只是在为今天的会话而构建。你在构建一个每次使用都变得更智能的系统。我的仓库从一个 CLAUDE.md 和三个技能开始。现在它有 40 多个技能、完整的语音系统、合作伙伴工作流、RPG 进度系统和自动化仪表板。每一个部分都让其他每个部分运转得更好。这就是上下文工程的复利效应。第一个月很慢。第六个月就不可思议了。