上下文工程（Context Engineering）

GitHub 一句话点破本质："问题不是给 AI 更多信息，而是让 AI 始终聚焦于正确的信息。" 这是 AI 编程从"偶尔有奇效"走向"稳定可复用"的分水岭。

一、为什么 Prompt Engineering 不够用了

很多人提到 AI 编程，第一反应还是 Prompt Engineering（提示词工程）——琢磨怎么把一句话写得更准。但到了实际项目，尤其长流程、多轮、多代理协作时，大家发现真正的瓶颈变了：

决定成败的不再是"提示词写得多妙"，而是"在正确的阶段，把正确的信息，用正确的结构喂给代理"。

这就是 Context Engineering（上下文工程）。注意名字重点在 Engineering——它不是小技巧，而是需要系统设计的工程：你要决定给代理什么信息、不给什么、在哪个阶段给、用什么结构给、如何持续维护这些上下文资产。

二、它在做什么

• 给代理正确而不是过量的上下文；
• 避免无关信息污染会话；
• 把经验沉淀成可复用的 context 资产；
• 让不同阶段只拿到该阶段真正需要的信息。

三、心智模型：注意力，而非信息量

❌ 失败链路：海量无关信息 → 上下文污染 → 代理偏航 → 沿错误理解持续扩写
✅ 成功链路：相关 spec / 约束 / 目标文件 → 聚焦上下文 → 稳定执行

一句话本质：

让代理把注意力放在对的地方，而不是让它看更多东西。

四、常见失败场景（其实多是上下文问题，不是模型问题）

很多团队以为"模型不够强"，真正的原因往往是：

症状	真实病因
AI 改错了文件	它拿错了上下文文件
AI 违反了某个约定	它没看到关键设计约束（约束没入库）
越聊越蠢、答非所问	无关信息挤满了上下文窗口
一本正经地沿着错误方向狂奔	一次错误理解没有被及时纠正，后续全在扩写

🕳️ 你可能会遇到的坑：把整个大仓库、所有历史对话一股脑塞进上下文，看似"信息更全"，实则稀释了关键约束的权重，代理更容易抓错重点。做不好上下文，反而比给得少更糟。

五、高质量团队怎么做上下文工程

今天做得好的 AI 编程团队，会特别重视：

• 仓库中的结构化规范（把约束写成文件，如 AGENTS.md / steering 规则）；
• 会话切分（一个任务一个干净会话，别让上文的噪音污染下文）；
• 精准文件选择（只带当前子任务相关的文件）；
• 上下文压缩（摘要历史，保留关键决策）；
• 任务分层（大任务拆小，每层只喂该层需要的信息）；
• 记忆与知识沉淀（把可复用经验固化为资产，跨会话复用）。

六、和其他理念的关系

• SDD 的规格（spec），本质就是最高质量的上下文资产——它把"最容易引起返工的决定"显式写了出来；
• 上下文工程做不好，执行工装工程 的闭环也会因为代理"看错东西"而失败；
• 它和 协作与工作流 里的 superpowers / Subagent 分工紧密配合：多代理并行时，"给每个子代理喂对上下文"是成败关键。
• 具体"把上下文写成什么文件"，见落地章：落地构件：AGENTS.md / Rules / Skills。

七、本章小结

• Context Engineering = 系统设计"喂给代理的信息"，追求相关而非海量。
• 核心口号：让 AI 聚焦于正确的信息。
• 大多数"模型变笨"的现象，本质是上下文污染，而非模型能力问题。

八、下一步

• 继续阅读：执行工装工程，范式地图里最难、也最前沿的一层。