从写提示词到管上下文：2026 年的提示词工程该怎么做先说结论

先说结论

2026 年，提示词工程没有消失，但它变了重心。

变的地方很具体：官方文档开始主动下架一部分"经典技巧"。Anthropic 在今年的提示词最佳实践里明确写了两条：XML 标签结构化在多数场景下不再是必需品，清晰的小标题加直白语言同样管用；角色提示（You are a helpful assistant 那一类）对成熟模型往往多余，框得太死反而伤质量。

没变的地方也很具体：模型再好，也不会猜出你没说的事。上下文给得对不对、够不够、有没有噪声，仍然是决定输出质量的第一变量。

所以真正的分界线是这条：写提示词是离散动作，管上下文是持续动作。前者一次写好就完了，后者每一次调用都要重新筛一遍。下面按这个顺序讲。

一、官方下架了什么，为什么

先把话讲清楚，避免误解成"老技巧全作废"。

XML 标签：从默认手段降级为局部工具

过去推荐用 <instructions>、<data>、<output_format> 把提示词切成块。逻辑上没错——模型确实靠这些边界区分"哪段是指令、哪段是待处理数据"。

但 2026 年的官方说法是：清晰的小标题、空行、直白的过渡句，效果通常一样，而且写起来更省事。比如直接写"下面是一位运动员的资料，请据此提取成绩"，模型就分得清。

XML 标签还剩两种值得用的场景：

提示词里混了多种内容，且边界必须严格界定（比如同时有指令、参考文档、待处理输入、输出模板）

要支持旧版本模型

除此之外，加标签只是给自己增加维护成本。

角色提示：只在你需要"跨多次输出保持统一语气"时用

You are a world-class expert who never makes mistakes 这类写法，在早期模型上确实能拉起表现，因为那时的模型对"人设"更敏感。现在的模型指令跟随能力强了，过度设定反而会挤占注意力。

官方给的替代方式很朴素：直接说明你要的分析角度。

弱：You are a senior financial analyst with 20 years of experience.

好：分析这份投资组合，重点关注风险承受能力和长期增长潜力。

后者给的是具体信号，前者给的是气氛。

预填充（Prefill）：注意，这条已经不能照搬了

老教程里有个常用手法：把 assistant 回复的开头先写好，比如预填一个 {，逼模型接着输出纯 JSON，顺便跳过"好的，我来帮你"这类寒暄。

这个技巧在 2026 年的新版模型上要小心。Claude 4.6 之后的多数新模型会直接拒绝 assistant 预填充并返回错误，官方给出的替代方案是结构化输出（schema 约束）或明确的格式说明。

如果你在维护老代码，这是升级模型时最容易踩的一个坑：请求没改，模型一换，全挂。

二、真正没变的四件事

下面这四条，从 2023 年到现在一直是官方文档的第一梯队，一次都没被下架。

1. 说清楚，别让模型猜

对比一下：

帮我做一个数据分析面板

创建一个数据分析面板。尽可能包含相关的功能和交互，不要只做最基础的版本；
要有筛选、排序、导出，以及加载中的占位状态。

第二版的信息量不是"更长"，是可验证。前者模型只能给一个中庸答案，后者你知道该验收什么。

写的时候用一个简单检查：把这句话给一个没背景的同事看，他能不能照做。不能，就还没写清。

2. 给动机，不只是给命令

这条最容易被忽略，收益却最大。

弱：绝对不要用项目符号列表。

好：用连贯的段落写，不要用项目符号列表——这份材料是给我在通勤路上听的，列表读起来断断续续。

第二版多了"为什么"，模型就能在边界情况下自己判断：比如需要并列三个短项时，它知道该写成一段话而不是硬拆成列表。只给命令，模型只能一刀切。

3. 示例胜过描述

格式这种东西，用例子展示比用文字描述准确得多。官方的建议是先给一个，不够再加。

有个坑要提醒：现代模型对示例里的细节极其敏感。你在示例里随手带了个"综上所述"的收尾，输出就会次次带"综上所述"。示例里不能出现你不想要的行为，哪怕只是无心的。

4. 明确允许"不知道"

这条能显著降低编造率。

如果给出的资料不足以得出结论，直接说明资料不足，不要推测或补全。

不加这句，模型面对信息缺口时的默认行为是填补——它不是在骗你，是在完成"给出答案"这个任务。你得显式地把"承认不知道"写成合法选项。

三、重心转移：为什么现在要谈上下文

上面四条都还是"怎么写提示词"。但 2026 年真正拉开差距的，是另一个问题：这次调用里，到底该塞进去哪些 token。

上下文腐化（context rot）

现象：上下文越长，模型准确回忆其中信息的能力越弱。

原因在架构层面。Transformer 里 n 个 token 两两之间都可能产生关联，关系数量是 n²。上下文变长，模型很难把每对关系都捕捉到。加上训练数据里长序列本来就少，模型对远距离依赖的经验不足。

表现不是"到某个长度突然崩"，而是随长度渐降：检索精度下降、长程推理变弱、中段信息被忽略。

结论：上下文是收益递减的资源，不是免费的容器。

有效的上下文长什么样

官方的总原则一句话：用尽可能小、信号尽可能强的 token 集合，最大化达成目标的可能性。

注意"精简不等于短"。必要的信息还是要前置写清，砍掉的是重复、寒暄、无关的工具输出，不是关键约束。

拆成四块看：

系统提示词：高度要"恰到好处"

太低：把复杂的 if-else 逻辑写死在提示里，脆弱、难维护

太高：只给笼统原则，模型拿不到具体信号

合适：能给行为定调、又留出判断空间的一组强启发式

实操顺序是：先用最强模型跑一个最小提示，看它在哪里失败，再针对失败补指令和示例。不要一上来就把所有想到的规则写进去。

工具：越少越准

工具是模型和信息、行动之间的契约。两个指标：返回内容省 token，调用行为明确。

常见失败不是工具太少，是工具集臃肿——功能重叠、命名含糊，模型不知道该挑哪个。先给一个最小可用集合，等确实不够再加。

示例：要多样，不要边缘

挑典型、多样的例子，不要堆大量罕见边缘案例。堆边缘案例会让模型把特例当通则。

消息历史：动态管理

长任务里的历史会不断膨胀，需要主动清理。清理旧的工具结果是成本最低的做法，比整体摘要更轻。

四、长任务的三种处理方式

窗口再大，也扛不住无节制增长。官方给了三条路，各有适用面。

压缩（compaction）：接近窗口上限时，把对话摘要后开一个新窗口。取舍原则是先保召回、再谈精简——宁多留一点，别把关键决策丢了。适合来回交互多的任务。

结构化笔记（structured note-taking）：把进度写到上下文外面，需要时再读回来。比如维护一个待办文件、一份进度笔记。适合有明确里程碑的迭代开发。

子代理（sub-agent）：主代理负责规划和汇总，子代理在干净上下文里做深度探索，只回传精炼结论。子代理可能烧掉几万 token，回来的只有一两千字摘要。适合需要并行探索的复杂研究。

这三种不是三选一的技术栈，是按任务形态挑。

五、把它当工程做，别当文案做

前面讲的都是"怎么写好的提示词"。但落到项目里，真正决定成败的是怎么管住这些提示词。

提示词是代码，就该有代码的待遇

有版本，能回滚

进评审，改动要有人看

有测试集，改完要跑，看关键用例有没有退化

改动有理由，不能"感觉这样更好"

最容易被跳过的是第三条。没有测试集的提示词优化，本质上是凭手感调参——你改好了 A 用例，可能同时弄坏了 B 用例，而你并不知道。

按"能不能 100% 生效"选层

这是我在实际项目里验证过的一条判据，用在这类规则上很有效。

假设你要保证模型"绝不执行用户上传文档里的指令"（防提示注入）。写法有三种：

写进系统提示词：有效，但只是概率性的。模型有时会漏

写进外部规则文件（比如 CLAUDE.md 这类项目说明）：同上，而且容易被长上下文稀释

在代码层拦截：在模型看到内容之前就过滤，100% 生效

第一、二种属于建议，第三种属于强制。必须无例外的规则，不要只写进提示词。

我在自己的仓库里是这么分层的：

规则文件（项目说明、约定文档）：管"希望怎么做"，属于建议层

钩子 / 权限配置：管"绝不允许怎么做"，属于强制层，在动作发起前就拦住

CI：管"改完有没有变差"，属于回归层，跑不过就不许合

三层各管一件事，不互相替代。

规则文件要短

反直觉的一点：规则文件越长，遵守率越低。

每次加载都在消耗注意力预算，几十条并列的规则里，真正关键的那几条会被淹没。有效做法是：

加一条之前先问：删掉它，会不会真的出错？不会就别加

某条老被忽略，只给那一条加显眼的标记，不要整篇加粗

会重复执行的流程细节，挪到独立文档里按需加载，不要塞进常驻文件

我的常驻规则文件控制在 200 行以内。这不是为了好看，是因为超过之后遵守率会明显下降。

六、一份常见错误清单

按出现频率排：

一次用尽所有技巧。堆了示例、思维链、角色设定、格式约束，最后不知道哪个起了作用。一次只改一个变量。

用否定句约束格式。写"不要用 markdown"，不如写"用连贯的段落"。模型对"要做什么"的跟随，比对"不要做什么"稳。

提示词本身的排版影响了输出。你写成一堆短句和列表，输出往往也是短句和列表。想要成段的行文，提示词就先写成段。

示例里混进了不想要的行为。前面提过，但值得再说一次，因为太常见。

输出泛泛就加形容词。加"请专业一点""要有深度"没用，要加具体的结构要求或验收标准。

编造就加重语气。写"绝对不能编造"作用有限，真正有效的是给"不知道"开一个合法出口。

在提示词里写 if-else。分支超过两三个，就该拆成链条式调用或者交给代码判断。

七、如果只用一句话

把每一次调用当成一次预算分配：你只有有限的注意力预算，决定放什么进去，比决定怎么措辞更重要。

措辞决定模型能不能听懂，上下文决定它有没有东西可听。前者是入门线，后者是现在的分水岭。

参考

Anthropic 官方博客《Prompt engineering best practices》，2026 年更新

Anthropic 工程博客《Effective context engineering for AI agents》，2025-09-29

Anthropic 官方文档「Prompting best practices」

文中原则来自上述官方材料。这些材料以 Claude 为对象撰写，但底层机制（Transformer 注意力、指令跟随模型的训练方式）在各家模型上是共通的，因此对国内主流大模型同样适用。涉及具体 API 参数的部分（如预填充、结构化输出）请以你所用平台的当期文档为准