你有没有遇到过这种情况：同一个大模型，别人用它写出了惊艳的 Agent 应用，你用它却只会得到「正确的废话」？问题往往不在模型，而在上下文（Context）——你塞给模型的那一坨信息怎么组织、按什么顺序、保留什么、砍掉什么。2026年，Anthropic 用 Claude 5 掀起了上下文工程的新范式：规则让位给判断力，例子让位给接口设计，全量塞入让位给渐进披露。这篇文章把这套新范式翻译成能直接上手的方法。
提示词工程（Prompt Engineering）关心的是「怎么跟模型说一句话」，上下文工程（Context Engineering）关心的是「模型在决策那一刻，手里握着哪些信息、以什么形态呈现」。后者是前者的超集：
| 维度 | 提示词工程 | 上下文工程 |
|---|---|---|
| 关注单元 | 单次对话 / 单条指令 | 整个 Agent 的生命周期信息流 |
| 核心问题 | 怎么说模型才听话 | 什么信息该给、什么不该给、何时给 |
| 手段 | 措辞、格式、少样本示例 | 系统提示词、记忆、工具 schema、技能按需加载、外部验证 |
| 失败代价 | 答非所问 | Agent 静默跑偏，看起来成功实则零产出 |
一句话：提示词工程是让模型「说对」，上下文工程是让 Agent「做对」。 2026年的主流共识是——Agent 能力的上限由上下文设计决定，而不是由模型参数决定。
Anthropic 在 Claude 5 一代做了个标志性动作：砍掉了 Claude Code 约80%的系统提示词。这不是偷懒，而是把过去几年积累的上下文工程经验总结成了六条新规则。理解这六条，你就掌握了 2026 年的上下文设计哲学。
旧做法：在系统提示词里写满「你必须…」「禁止…」「如果…那么…」的硬约束，指望用规则穷举所有情况。
新做法：只给原则，不给细则。 让模型用自己的判断力处理具体情境。规则写得越细，模型越容易在规则没覆盖的边界上犯蠢；而原则性的引导（比如「优先保证数据准确，拿不准就明说」）能让模型在未知场景下做出合理决策。
实战含义：检查你的系统提示词，如果超过一半是「禁止」和「必须」，说明你在用规则对抗不确定性——该换成判断力了。
旧做法：给模型大量输入输出示例（few-shot），指望它模仿。
新做法：把工具（函数）的参数结构设计好，比给一万个例子都管用。 当模型面对一个参数命名清晰、类型明确、描述简洁的工具接口时，它自然知道怎么调用。示例是「教它猜」，接口是「让它查」。
实战含义：花时间打磨工具 schema 的 description 字段——每个参数写清楚「是什么、什么时候用、格式要求」，比在提示词里塞 20 条示例的效果更好。
旧做法：把所有知识、技能、规范一次性塞进系统提示词，模型一睁眼就要消化整个知识库。
新做法：先给目录，按需展开。 系统提示词里只放「索引」——告诉模型有哪些技能可用、什么时候该加载哪个；真正的内容放在独立的技能文件里，模型需要时才读取。这就是 2026 年「Skills 机制」大行其道的根本原因：上下文窗口再大也是稀缺资源，没必要让模型为用不到的知识买单。
实战含义：把你的提示词拆成「常驻核心（几百字）+ 按需加载的技能库（每个几百字）」，而不是一份动辄上万字的巨型提示词。
旧做法：同样的要求在不同地方反复强调（「记住你是…」「一定要…」），指望重复加深印象。
新做法：同一信息只出现一次，放在最该出现的位置。 重复不仅浪费 token，还会稀释模型对「关键信息」的注意力权重。工具描述要短——一句话说清用途，让模型扫一眼就知道该不该用。
实战含义：把「每轮都要遵守」的规则合并到一条原则里；工具描述超过 50 字的，先删一半再说。
旧做法：把用户的偏好、项目背景写死在 CLAUDE.md / AGENTS.md 里，永久加载。
新做法：固定文件只放「不会变的事实」（项目结构、技术栈），会变的观察（用户偏好、最近决定）交给自动记忆机制——模型在对话中自行判断什么值得记、什么该忘。固定记忆的毛病是会过期：三个月前的用户偏好可能已经变了，但文件还写着。
实战含义：固定上下文文件要精简到「客观事实」；把「用户上个月说喜欢 X」这类动态信息交给记忆系统管理。
旧做法：在提示词里用文字描述期望的代码风格、输出格式。
新做法：直接用代码本身、测试套件、HTML 页面当规范。 与其写「输出符合 Airbnb 风格的 JavaScript」，不如直接引用一份 lint 配置 + 一个示例文件。模型读代码比读规范理解得更准——规范是翻译过的，代码是原汁原味的。
实战含义：写代码任务时，把仓库里的现有文件路径直接给模型，让它「照着这个风格写」，而不是描述风格。
记住一句话总结：判断力优于规则，接口优于例子，按需优于全量，简洁优于重复，自动优于固定，代码优于描述。
一个健康的系统提示词应该满足：
把 Agent 的信息分成四层，各管各的：
| 层级 | 内容 | 更新频率 |
|---|---|---|
| L1 固定上下文 | 项目结构、技术栈、不可变事实 | 几乎不更新 |
| L2 技能库 | 按需加载的方法论、模板、参考文件 | 低频 |
| L3 会话记忆 | 本次任务的中间状态、决策理由 | 高频 |
| L4 长期记忆 | 用户偏好、跨会话经验、教训 | 中频，需主动写入 |
最常见的错误是把 L4 的内容写进 L1（用户偏好写死进固定文件），或者把 L3 当 L4（把一次性的任务进度当成长期经验存下来）。
模型通过工具定义来理解「我能做什么」。打磨 schema 的三个要点：
send_message、search_articles 比 fn1、param2 好十倍。把 Agent 可能用到的方法论拆成独立文件（SKILL.md / 参考文档），系统提示词里只放一行索引：
可用技能：
- 写作类：标题公式、去AI味、爆文结构（写作任务时加载）
- 数据类：A股分析、行情采集（金融任务时加载）
- 自动化类：n8n工作流、MCP调用（搭建自动化时加载）
模型需要时才读取对应技能全文。这样即使你有 100 个技能，单次任务的上下文开销也只有几百 token。
上下文工程最容易忽视的一环：Agent 自报成功 ≠ 真的成功。 模型对自己的输出有「自信偏差」，它说「任务完成」可能只是它觉得该这么说。正确做法是引入外部可观测的验证信号：
把验证写进上下文：「完成任务后，调用 check 工具确认结果真实生效，再报告完成。」这一步能把 Agent 的「假成功率」从 30% 降到接近 0。
2026年，很多内容自动化系统遭遇了同一个诡异现象：cron 定时任务显示「执行成功」，但产出为零。 系统提示词写得无懈可击、模型没报错、日志全是 green——可发布出去的内容一篇都没有阅读。
用上下文工程的视角解剖，问题出在三处：
修复方案：系统提示词砍到 300 字只留原则；技能改为按需加载；加一条铁律——「发布后必须抓取线上页面验证内容真实存在，否则视为失败」。修复后产出质量显著回升。这个案例说明：大多数「AI 不行」的抱怨，实际是上下文设计不行。
七项全过，你的 Agent 已经超过 80% 的同行了。
上下文工程不是玄学，它是「把稀缺的上下文窗口花在刀刃上」的工程学科。2026年的趋势很明确：模型越来越强，上下文设计越来越成为区分高手和普通用户的分水岭。从今天起，别再往提示词里堆规则了——先砍一半，再按需加载，最后加上外部验证，你会看到立竿见影的变化。
如果你在做 AI 内容创作、Agent 自动化或数字产品变现，欢迎关注本站的持续更新，也欢迎在爱发电商店获取更多实战模板与教程。