从提示工程到上下文工程：AI编程的进化之路
从提示工程到上下文工程：AI编程的进化之路
一年前，技术圈最火的词是"提示工程"（Prompt Engineering）。各类教程满天飞："学会这10个提示词技巧，让AI效率翻倍"、"高阶Prompt模板，价值万元"。大家都在卷谁的提示词写得更花哨。
一年后的今天，风向变了。圈子里的讨论重点从"怎么写好提示词"悄悄转向了"上下文工程"（Context Engineering）。
发生了什么？
第一阶段：提示工程时代（2023-2024）
核心思路：把话说清楚
提示工程时代的逻辑很简单粗暴——你说得越清楚，AI回答得越准确。
这个阶段，我们做的事情本质上就是：把需求从脑子里翻译成AI能理解的文字。像教一个刚入职的新人，你告诉他用什么技术栈、要实现什么功能、有什么约束条件、按照什么规范输出，他就照着做。
在上一篇文章里，我总结过一个提示词公式：
[场景定位] + [技术栈约束] + [功能需求] + [输出规范] + [示例参考]
这五要素在当时确实好用。以"监控预警模块"为例，当你把技术栈（Java8 + SpringBoot + MyBatis-Plus）、功能需求（指标上报、预警判定、多渠道通知）、输出规范（分层输出、驼峰命名）一股脑写清楚之后，AI的输出质量确实会有质的飞跃。
那个时期的几个关键技巧
- 约束前置：技术栈、性能要求等"不可协商"的条件放最前面，避免AI走偏
- 任务拆解：把复杂需求拆成编号明确的子任务，AI逐个落地
- 示例锚定：用项目中已有代码结构（如BaseEntity、Result封装）作为参考，让生成代码无缝融入
- 迭代开发：不要指望一次到位，分步骤推进，每步及时反馈纠偏
- 项目约定：在
.github/copilot-instructions.md里写好规则，AI每次对话自动加载
这套路用了一年多，说实话，效果确实比"帮我写个监控模块"这种模糊提示好太多了。
但问题也来了
提示工程有个致命的局限——所有的上下文都是静态的，都得你手动提供。
打个比方，提示工程像是你每次跟AI聊天都得先自我介绍："你好，我是做Java后端的，项目用的是SpringBoot，数据库是MySQL，前端用Vue..." 每次开新对话都要重复一遍，遗漏了什么AI就给你整出幺蛾子。
更崩溃的是续接开发。隔两天想接着干活，AI完全不记得之前写了什么，你又得把之前的代码贴一遍、逻辑说一遍。上下文窗口一满，它还能把前面的内容忘了，直接给你来个"从零开始"。
你花在"给AI提供上下文"上的时间，有时候比写代码还多。
这就像你带了个实习生，能力是有的，但没有记忆。每天上班你都得把项目背景、代码规范、已完成的模块重新交代一遍，你说累不累？
第二阶段：上下文工程时代（2025）
核心思路：让系统自动管理上下文
2025年，随着AI编程工具的进化（Cursor、Windsurf、Copilot Workspace等），一个新概念浮出水面——上下文工程。
如果说提示工程是"教你怎么跟AI说话"，那上下文工程就是"构建一套系统，让AI在正确的时间看到正确的信息"。
不是"我该怎么说"，而是"我该怎么组织"。
这就像从"手工作坊"进化到了"流水线"。以前你手动把每一份材料递给AI，现在你搭好流水线，材料自动传到AI面前。
三种上下文类型
上下文工程把AI需要的信息分成了三类：
1. Instructions（指令）——告诉AI怎么干活
这就是之前的copilot-instructions.md思路的升级版。不只是写规则，而是构建一套完整的指令体系：
- 代码规范和项目约定
- 工作流程和思考链路
- 禁止事项和安全红线
- 分层架构和数据流向
2. Knowledge（知识）——告诉AI知道什么
这一层是提示工程时代最缺失的。以前你得手动把项目文档、技术规范、业务逻辑一股脑贴给AI。现在：
- RAG检索：AI自动从知识库中检索相关文档
- 代码库索引：AI能理解整个项目的代码结构
- 结构化数据：数据库Schema、API文档自动纳入上下文
3. Tools（工具）——让AI能干什么
AI不再只是"嘴上说"，它能动手了：
- 读取文件系统，自动获取项目代码
- 执行命令，运行测试、检查编译
- 调用API，查询数据库、操作云服务
- 联网搜索，获取最新文档和解决方案
读写上下文的双向管理
上下文工程不只是"给AI看什么"，还包括"AI记住什么"。
读上下文（Reading Context）——AI获取信息的方式：
- 工具调用结果：通过MCP等协议自动获取项目信息
- RAG检索：从知识库中自动检索相关文档片段
- 代码分析：自动扫描和理解项目代码结构
- 结构化数据：数据库Schema、配置文件等自动加载
写上下文（Writing Context）——AI保存信息的方式：
- Notepad机制：在对话窗口之外保存信息，不受上下文长度限制
- Memory机制：跨会话持久化，上次聊的内容下次还记得
copilot-context.md模式：自动记录开发进度和关键逻辑
实战对比：以监控模块为例
还是拿监控预警模块来举例，对比两种方式的差异。
提示工程的做法：
第一步：写一个超长的提示词，把所有需求、约束、规范全塞进去
第二步：AI生成代码，你检查发现一堆问题
第三步：反复修改提示词，重新生成
第四步：终于差不多了，但是隔两天要续接开发
第五步：把之前的代码再贴一遍，重新描述需求
第六步：又回到第二步...
这个过程中，你像个"提示词打字员"，主要工作就是不断地给AI喂信息。
上下文工程的做法：
第一步：在项目里建好 instructions 文件（一次性）
第二步：创建 copilot-context.md 记录进度锚点
第三步：把参考代码和样板文件放在AI能自动读取的位置
第四步：启动开发，AI自动加载指令、自动检索知识库
第五步：每完成一个阶段，自动记录进度到context文件
第六步：下次续接时，AI自动读取context，无缝继续
结果就是：返工少了，连续性强了，AI对你的项目理解越来越深。
效率对比
用一组数据说话。同样是开发一个中等复杂度的功能模块：
| 维度 | 传统团队 | AI辅助（提示工程） | AI Agent全栈（上下文工程） |
|---|---|---|---|
| 人员 | 3人（Android + 后端 + 前端） | 1人 | 1人 |
| 周期 | 4-6周 | 2-3周 | 1-2周 |
| 沟通成本 | 高（跨角色协调） | 中（与AI反复沟通） | 低（系统自动管理） |
| 返工率 | 中 | 高 | 低 |
| 开发者角色 | 实现者 | 提示词工程师 | 设计者+审核者 |
注意看最后一行——开发者的角色发生了根本性转变。
在上下文工程时代，你的核心工作不再是"一行一行写代码"，而是：
- 理解问题：搞清楚到底要做什么
- 设计架构：决定技术方案和数据流向
- 编排AI：搭建上下文系统，让AI高效工作
- 审核代码：AI写完了，你把关质量
从"搬砖工"变成了"包工头"，这感觉其实还不错。
我的实战心得
用了一段时间的上下文工程后，几个比较深的感触：
1. 前期投入是值得的
刚接触上下文工程时，建instructions文件、整理知识库、配置工具链——这些前期工作确实要花时间。但这就跟搭建CI/CD流水线一样，一次性投入，后面每次开发都在受益。
我现在每接手一个新项目，第一件事就是搭好这套上下文体系。磨刀不误砍柴工，古人诚不欺我。
2. 信任AI，但必须审核
AI在上下文工程时代确实变强了，但"变强"不等于"可靠"。
它能自动检索你的项目代码，但可能理解错了某个工具类的用途。它能自动获取数据库Schema，但生成的SQL可能漏了索引。它能跨会话记住开发进度，但可能在续接时悄悄改了之前的设计。
AI是效率工具，不是信任对象。 它写的每一行代码，你都得过一遍。不过审代码总比写代码轻松，这个账算下来还是赚的。
3. 记录AI协作过程
我现在养成了一个习惯：每次跟AI协作完成一个模块，就把关键信息记录下来——用了什么提示词策略、踩了什么坑、怎么解决的。
这些记录慢慢积累成了一套可复用的方法论库。下次遇到类似的模块开发，直接套用，不用从零摸索。
4. 在团队中分享经验
上下文工程不是一个人的事。在团队里推广最佳实践，统一instructions文件模板，共建知识库和样板代码——这些做好了，整个团队的AI编程效率都能上一个台阶。
一个人用AI是加分项，一个团队用好AI是乘号。
未来核心竞争力在哪
说了这么多，一个很现实的问题：在AI编程越来越强的时代，开发者的核心竞争力到底是什么？
我的答案是四个能力：
1. 问题理解力——搞清楚用户到底要什么，这永远是第一步。AI再强，它也只能理解你表达出来的需求。而你连需求都没理解透，给AI的输入就是垃圾，出来的自然是垃圾。
2. 架构设计力——AI擅长实现细节，但不擅长做系统级的设计决策。选什么技术栈、怎么划分模块、数据怎么流转——这些是架构师的大脑该干的事。
3. AI协作力——就是这篇文章说的上下文工程能力。怎么搭建上下文体系、怎么编排AI的工作流、怎么让AI和项目深度融合。
4. 代码审核力——AI写代码越来越快，但质量把控还得靠人。能快速理解AI生成的代码、发现潜在问题、做出改进决策，这个能力会越来越值钱。
写在最后
从提示工程到上下文工程，本质是从"手工作坊"到"工业化生产"的转变。
提示工程教你"怎么跟AI说话"，上下文工程教你"怎么让AI系统性地帮你干活"。前者是沟通技巧，后者是工程能力。
想起一句话："AI不会取代开发者，但不会用AI的开发者，会被会用AI的开发者取代。"
这话虽然有点老套，但确实是这么个理。
工具在进化，用工具的方式也得进化。提示工程已经够用了？不，上下文工程才刚刚开始。