夜雨聆风“上一篇我们讲解了和AI协作写代码要做的心态模式转型。这一篇我们来讲一下AICoding最被低估的工程能力：Context Engineering（上下文编程）。全篇3千余字，大概需要10分钟（若来不及看可先收藏，已把全文总结置顶！）。”
全文速览
很多人用AI效果不稳定，其实问题不在Prompt而在上下文不一致。Context Engineering就是系统性地管理AI能获取的背景信息，包括项目目标、技术栈、历史决策等，远比单次Prompt更重要。
好的上下文分三层：仓库级（如AGENTS.md）、会话级和任务级，需保证正确、完整、精简、有轨迹。常见反模式包括信息太少、太多、太旧或太模糊。维护好上下文，能让AI输出更稳定、减少返工。维护AGENTS.md是最有效的单一手段。
一、为什么大多数人用AI的效果不稳定？
Prompt 是战术，Context 是战略。
一个常见的现象：同一个问题，同一个AI工具，今天得到一个很好的结果，明天换一个会话，得到一个差很多的结果。
很多人把这归结为"AI不稳定"或者"Prompt没写好"。但更根本的原因往往是：上下文不一致。
AI模型的输出质量，在很大程度上取决于它在生成回答时所拥有的上下文信息——关于项目的信息、关于任务的信息、关于约束的信息、关于历史决策的信息。
这就是 Context Engineering（上下文工程）——系统性地设计、管理和维护AI所能获取的上下文信息，以稳定地获得高质量输出。
二、为什么说"Context > Prompt"
Prompt 是战术Prompt 是你在某个具体时刻对AI说的话。它决定了AI在这一次对话中的行为。好的Prompt可以提升单次输出质量，但它是一次性的、会话级的。
Context 是战略Context 是 AI 在整个任务过程中所能获取的所有信息的总和——不仅是你当前说的话，还包括：
项目的背景和目标
技术栈和架构约束
过去做出的决策和原因
当前任务的范围和边界
验收标准和质量要求
好的 Context 设计，可以让 AI 在整个项目过程中保持一致的行为和输出质量，不依赖于每次都写出完美的 Prompt。
类比：Prompt 像是每次开会前的议题，Context 像是团队共同拥有的背景知识库。一个新成员每次开会都需要反复解释背景，是因为他没有这个背景知识库。AI 的情况类似——如果没有良好的 Context 设计，每次对话都需要从头建立背景。
三、四维上下文质量模型
评估一份 Context 的质量，可以从四个维度：
维度一：正确性（Correctness）
上下文中的信息是否准确？过时的 API 文档、错误的架构描述、不再适用的约束条件，都会主动误导 AI。检查问题：我提供的信息，是否反映了系统当前的真实状态？
维度二：完整性（Completeness）
AI 完成任务所需的关键信息，是否都已经提供？缺失的关键信息会导致 AI 做出错误假设。检查问题：如果一个不了解项目的新工程师只看我提供的 Context，他能做出正确决策吗？
维度三：精简性（Conciseness）
上下文并不是越多越好。AI 的上下文窗口有限，无关信息会稀释关键信息的权重，甚至让 AI 在大量信息中"迷失"。检查问题：我提供的每条信息，是否对当前任务有实际价值？有没有可以去掉的噪音？
维度四：轨迹性（Trajectory）
AI 不仅需要知道"现在是什么"，还需要知道"我们是怎么到达这里的"——关键决策的背景和原因，比决策本身更有价值。检查问题：对于重要的约束和设计选择，我有没有说明"为什么这样做"而不仅仅是"这样做"？
四、三层上下文架构
实践中，上下文可以按照"持久性"分为三个层次：
第一层：仓库级上下文（持久性最高）
这是关于整个项目的信息，通常以固定文件的形式存在于代码仓库中，对所有任务都适用。
常见文件：
AGENTS.md/CLAUDE.md：告诉 AI 关于这个项目的一切——技术栈、架构模式、代码风格、禁止操作、关键约束.cursorrules：Cursor 专用的规则文件，定义 AI 在编辑代码时的行为约束README.md：项目基本信息，通常 AI 会自动读取
一份好的 AGENTS.md 应该包含：
## 项目概述这是什么项目，服务什么用户，解决什么问题## 技术栈语言、框架、主要依赖及版本## 架构约束模块边界、数据流、禁止的模式## 代码风格命名约定、文件组织、注释要求## 关键决策记录"我们为什么选择 X 而不是 Y" 类型的历史决策## 禁止操作绝对不能做的事（删除数据、修改配置文件、调用外部服务等）
第二层：会话级上下文（中等持久性）
这是针对某个工作阶段或某类任务的上下文，通常在开始一个新的工作会话时提供。
常见形式：
SOUL.md：定义 AI 的角色和工作风格任务背景文档：当前正在做的事情的背景信息
相关代码片段：AI 在本次会话中可能需要参考的现有代码
最佳实践：在开始一个新的工作会话时，明确告诉AI："今天我们要做的是X，背景是Y，请先读取这些文件"。
第三层：任务级上下文（一次性）
这是针对单个具体任务的上下文，通常在任务开始时提供，完成后就不再需要。
常见形式：
spec.md：具体功能的需求规格plan.md：实现方案和设计决策tasks.md：当前任务列表和进度
设计原则：任务级上下文应该是自包含的——仅凭这份文档，AI应该能够完成任务，不需要反复追问。
五、常见的上下文反模式
反模式一：太少（Under-Context）
症状：AI经常需要猜测，输出质量不稳定，经常出现"AI把简单的问题理解错了"的情况。
修复：在
AGENTS.md中补充关键背景信息；在 Prompt 中使用 CACA 框架提供完整上下文。
反模式二：太多（Over-Context）
症状：把整个代码库都塞给AI，AI的回答开始变得"通用"而不是针对你的具体情况。
修复：每次任务只提供相关的上下文；将大型文档拆分，按需提供。
反模式三：太旧（Stale-Context）
症状：
AGENTS.md上次更新是 3 个月前，描述的是旧架构；AI 按照旧架构给出了错误的建议。修复：在每次重要架构决策后更新
AGENTS.md；将上下文维护纳入 Definition of Done。
反模式四：太模糊（Vague-Context）
症状：
AGENTS.md里写的是"遵守最佳实践"、"代码要整洁"，这些对 AI 毫无约束力。修复：用具体、可操作的语言描述约束——不是"代码要整洁"，而是"函数不超过 50 行，每个公共函数必须有 JSDoc 注释，变量名使用驼峰命名法"。
六、如何写一个好的 AGENTS.md
一份有效的 AGENTS.md，应该能回答 AI 的这五个问题：
我在哪？→ 项目背景、目标用户、主要功能
我能用什么？→ 技术栈、可用的库和工具
我不能做什么？→ 禁止操作、需要人工确认的决策
我应该怎么做？→ 代码风格、文件组织、测试要求
为什么是这样？→ 关键架构决策的背景和原因
# AGENTS.md - 项目名称## 项目概述[一段话描述：这是什么系统，服务谁，解决什么核心问题]## 技术栈- 语言: TypeScript 5.x- 框架: Next.js 14 (App Router)- 样式: ****- 数据库: PostgreSQL- 测试: Vitest + Testing Library## 架构原则- Server Components 优先，只在必要时使用 Client Components- 错误处理: 不要 throw，除非是无法恢复的错误## 禁止操作- 修改数据库 schema- 删除任何现有的接口## 代码风格- 函数不超过 50 行- 每个公共函数必须有 JSDoc 注释- 文件命名: 组件用 PascalCase，工具函数用 camelCase- 测试文件与源文件同目录，命名 xxx.test.ts## 关键决策记录- ****
七、写在最后
Context Engineering 是 AI 时代工程师最需要投资的能力之一。它不是一次性的工作，而是随着项目演进持续维护的工程实践。
投资在上下文质量上的时间，会以"AI 输出更稳定、迭代更少、方向偏差更小"的方式得到几倍的回报。
下一次当你觉得"AI 表现不稳定"时，先检查一下：你给它的上下文，是不是这篇文章里描述的某种反模式？
本文是「AI Coding 研发新范式」系列的第4篇。本系列计划10余篇文章，系统的介绍VibeCoding、SpecCoding、OpenClaw多Agent协作的AICoding研发新范式！
AiCoding研发新范式02 | Vibe Coding感觉驱动编程
AICoding研发新范式03 | 从「写代码」到「指挥AI写代码」你需要做的转变
下一篇预告：Spec Coding！
关于我:
我是老乔伊，互联网大厂十年技术管理，专注技术人职场跃迁，也在持续探索AI时代IT人职场转型之路！
关注我：
每周持续分享AI时代的技术转型（AICoding）、职场跃迁、绩效管理、后端|数据开发|数据科学专业技能进阶、面试指南等等适合IT人的实操干货！欢迎关注交流~
