上下文工程

核心观点

Shopify 的 CEO Tobi Lutke 提出了一个观点：提示词工程只是开始，上下文工程才是真正的突破。

什么意思？提示词工程关注"怎么问"，上下文工程关注"给什么信息"。两者不是二选一，而是递进关系——先解决"给什么"，再解决"怎么问"。

我越来越认同这个判断。在实际使用中，80% 的 AI 输出质量问题，根源不是提示词写得不好，而是上下文提供的不到位。

上下文窗口（Context Window）是模型一次能"看到"的最大 Token 数量。你可以把它理解为模型的"工作台"——所有信息都要放在这个台面上，模型才能处理。

不同模型的窗口差异很大：

窗口大是好事，但不是越大越好。我的经验：

给模型一个模糊的提示词，但配上高质量、高相关性的上下文，结果往往不差。反过来，提示词写得再精致，上下文里塞了一堆无关信息，模型照样跑偏。

举个例子：你要让 AI 帮你写一段 SQL 查询。

如果只给提示词"帮我写个 SQL"，结果很泛。但如果你把数据库表结构、字段注释、一个已存在的查询示例都放进上下文，AI 几乎能一次写出可用的代码。

这就是上下文工程的核心：让任务所需的信息全部在上下文中可及。

模型对最近输入的内容关注度最高。如果你的提示词很长，把核心指令放在末尾。

对话太长时，不要简单截断。让模型自己总结之前的对话，把总结作为新的上下文起点。我常用这个 prompt：

请用 3-5 句话总结我们之前的对话，保留所有技术决策和具体数字。

不要把整个文档库塞进上下文。先检索最相关的 3-5 个片段，只放这些进去。质量 > 数量。

系统提示词放不变的规则和角色设定，用户提示词放每次变化的具体需求。这样缓存机制能大幅降低成本。