Context Engineering：比 Prompt Engineering 重要十倍的事
不卖课、不贩卖焦虑、不搞成功学。Prompt Engineering 火了两年了，但我觉得大部分人关注错了重点。真正决定 AI 输出质量的不是你怎么写 prompt，而是你给它什么上下文。
一个反直觉的事实
我做过一个实验。同一个问题，两个 prompt：
A："帮我写一个用户认证模块。"
B："帮我写一个用户认证模块。项目是 Next.js + TypeScript，用 Prisma 做 ORM，数据库是 PostgreSQL。认证方案用 NextAuth，支持 GitHub OAuth 和邮箱登录。需要中间件保护 /dashboard 下的所有路由。参考项目里已有的 /api/auth/[...nextauth].ts 的模式。"
你猜哪个得到的代码更好？
答案不用猜——B 远好于 A。但有意思的地方在于，B 的 prompt 部分其实也很简单（"帮我写一个用户认证模块"），真正起作用的是后面那一堆上下文信息。技术栈、已有代码、期望方案、约束条件——这些东西才是让 AI 输出从"凑合能用"变成"可以直接合"的关键。
这就是 context engineering 的核心：你给 AI 的信息质量，决定了 AI 输出的质量。
我后来又做了几组对比实验。让三个不同的人用 AI 写同一个功能：一个只给一句话需求，一个给需求加技术背景，一个给需求加技术背景再加已有代码和约束条件。结果差异巨大——第一个人拿到的代码有一半需要重写，第二个人拿到的代码大约三成需要调整，第三个人拿到的代码几乎可以直接用。三个人用的是同一个 AI，区别只在于 context。
这件事让我意识到：大部分人对 AI 能力的评估其实是不准确的。他们觉得"AI 写代码不行"，但实际上是"我给 AI 的信息不够"。AI 的能力比你感受到的要强，你感受到的差距大部分来自 context 的差距。
Prompt 是入口，Context 是基建
大部分人对 AI 的使用停留在"写好 prompt"的层面。"扮演一个资深工程师""用简洁的风格""给出三种方案"——这些 prompt 技巧确实有用，但作用有限。
打个比方：prompt 是你对一个厨师说的那句话，context 是你摆在厨师面前的食材、调料、菜谱和厨房设备。你说得再好，如果食材不对、调料没有、菜谱缺页，厨师也做不出好菜。
我见过太多这样的场景：开发者吐槽"AI 写的代码不行"，然后我一看他的对话，发现他只给了 AI 一句话的需求描述，没有任何项目背景、技术约束、已有代码。AI 能给出什么？一个通用的、没有上下文的、大概率跟你的项目不匹配的方案。
反过来，我也见过高手用 AI 的方式——他们花在准备 context 上的时间，比花在写 prompt 上的时间多得多。把相关文件贴上去、把报错信息粘上去、把需求文档的关键段落摘出来、把项目的目录结构列一下。看起来很麻烦，但 AI 返回的结果直接能用的概率高了好几倍。
怎么组织 Context
说几个我自己在用的方法。
按层次给信息。 我一般会把 context 分三层。第一层是项目级的——技术栈、架构风格、约定规范。这一层你可以在项目根目录放一个 AI.md 或者 .cursorrules，让 AI 自动读取。第二层是模块级的——当前在做什么功能、相关的文件有哪些、数据流怎么走。这一层在对话开头给出。第三层是任务级的——具体要做什么、有什么约束、期望什么输出。这一层才是你的 prompt。
大部分人的做法是只给第三层，然后期待 AI 猜出前两层。这就像你走进一家陌生餐厅，对厨师说"给我做道好吃的"，然后抱怨他做的菜不合口味。
给"反例"比给"正例"更有效。 告诉 AI"不要用 any"比告诉它"用严格的类型"更有效。告诉它"不要用 class 组件"比告诉它"用函数组件"更有效。因为"不要做什么"比"要做什么"更精确地约束了输出空间。
我经常在 context 里加一段"之前的方案为什么不行"——"我之前试过用 Redis 做缓存，但部署环境不支持。""上一个版本用了 JWT，但 refresh token 的逻辑太复杂，换一种方案。"这些"反例"信息帮 AI 避开了已知的坑，效率提升非常明显。
控制 Context 的粒度。 不是所有文件都需要给 AI 看。如果你在改一个组件，把整个项目的代码都贴上去只会淹没真正有用的信息。我的经验是：给 AI 看直接相关的文件（3-5 个），再加上一两个有代表性的参考文件，就够了。太多反而降低质量——跟人类读代码的规律一样。
用结构化格式。 纯文本的 context 效率很低。用 markdown 列表、JSON、代码块这些结构化格式组织信息，AI 理解得更快更准。比如你给它项目结构的时候，用树形图比用一段描述文字好得多。
常见的 Context 误区
误区一：把所有东西都塞进去。 我见过有人把整个代码库的上下文都堆给 AI，想着"信息越多越好"。实际上 context window 是有限的，而且 AI 对信息的利用效率也是有限的。当上下文太长的时候，AI 会"稀释"注意力——开头和结尾的信息权重高，中间的信息容易被忽略。这跟人类阅读长文档的规律一样。
误区二：不更新 context。 你在一个对话里改了三四个文件，AI 的上下文里还保留着旧版本的代码。结果就是 AI 给出的建议基于过时的代码结构。每次有重大改动，要么开新对话，要么主动更新 AI 的上下文。
误区三：忽略错误信息。 报错信息是 AI 能拿到的最有价值的 context 之一。但很多人只把错误信息的第一行贴给 AI——"Module not found"。实际上完整的 stack trace、相关文件的内容、你试过的修复方案，这些信息才是 AI 定位问题的关键。
误区四：以为 .cursorrules 就够了。 .cursorrules 是一个好东西，但它只是 project-level context 的一部分。你还需要在具体的对话中补充 task-level 的信息。指望一个配置文件搞定所有上下文，就像指望一份员工手册搞定所有培训——它能解决一部分问题，但不能替代具体的沟通。
Context Engineering 不是新概念
说实话，Context Engineering 这个词听起来很新，但做的事情一点都不新。
好的技术文档就是一种 context engineering——把项目背景、架构决策、接口约定、常见问题整理成结构化的信息，让新人能快速上手。好的代码注释也是一种 context engineering——在关键位置补充上下文，让维护者能理解代码意图。好的 commit message 也是——在提交记录里保留足够的上下文，让未来的人能追溯变更原因。
AI 只是把这个需求变得更显性了。以前你需要给新来的同事做 onboarding，现在你需要给 AI 做 onboarding。本质上都是同一件事：把隐性的知识变成显性的、结构化的上下文。
从这个角度看，那些写得一手好文档的程序员，用 AI 也会更得心应手。因为他们本来就擅长组织和传递信息。而那些代码能跑就行、文档从来不写的程序员，用 AI 就会碰到很多"我明明说清楚了但 AI 就是不理解"的情况——因为他们的"说清楚了"只是自己觉得清楚，信息的组织方式对 AI 并不友好。
我有一个朋友，他写代码不怎么写注释，但他在每次用 AI 之前都会花几分钟整理"我要告诉 AI 什么"。他的做法是先在记事本上列一个清单：项目用了什么技术、当前碰到什么问题、期望的输出是什么、有什么不能做的约束。列完之后再复制给 AI。效果比直接开口问好了不止一倍。
他说了一句我觉得很精辟的话："我不是在写 prompt，我是在给 AI 做 briefing。" 你想想，你会怎么给一个新来的同事做 briefing？你会告诉他项目背景、他的任务、有什么坑要注意、有问题找谁。对 AI 也一样。
所以与其说 Context Engineering 是一个新技术，不如说它是程序员一直应该做但经常偷懒没做的事。AI 的出现只是逼着你不能再偷懒了——因为你的偷懒会直接反映在 AI 的输出质量上。
还有一个趋势值得注意：随着 AI 工具越来越智能，它们对 context 的理解能力也在提升。Cursor 的 @file、@codebase 功能，Claude 的 project knowledge，这些本质上都是在帮你管理 context。但工具再智能，也替代不了你"想清楚要给什么信息"的判断。工具帮你搬运信息，你负责决定搬运什么。
说个可能得罪人的话：如果你一直觉得 AI 写的代码不行，先别急着骂 AI。回去看看你给它的 context 足够吗？准确吗？结构化吗？大部分人的问题不在 AI，在自己的使用方式。就像你不能给厨师一堆过期食材然后抱怨菜不好吃——先把食材准备好，再说厨师行不行。
行了，说几句收尾的话。
Context Engineering 不是什么高深的技术，它就是"怎么把信息组织好"这件事。但这件事的重要性被严重低估了。在 AI 时代，你的 prompt 写得多花哨不重要，重要的是你给 AI 的上下文质量有多高。
就像你跟一个聪明人合作——他的能力很强，但如果你给他的信息是混乱的、过时的、不完整的，他也发挥不出来。反之，如果你给的信息准确、完整、有结构，他能给你惊喜。
AI 就是那个聪明人。Context Engineering 就是你跟他合作的方式。
最后推荐一个实践：从今天开始，在你的项目根目录放一个 AI.md 或 .cursorrules 文件。里面写上：项目的技术栈和版本、目录结构和命名约定、代码风格要求、常用的设计模式和反模式、常见的坑和注意事项。花 30 分钟写好，以后每次用 AI 都能自动读取。这个投入产出比，可能是你做的所有"提升 AI 使用效率"的事情里最高的。
#ContextEngineering #PromptEngineering #AI编程 #Cursor #Claude #开发者效率 #AI工具 #代码质量 #工程实践 #技术选型 #LLM #上下文管理 #AI辅助开发 #软件工程 #提示词工程
Q.E.D.
