在前几天，Hacker News 的头条发表了一篇文章，核心观点是：决定 AI 代理效果的关键，已经从“写好提示词”转向了“上下文工程”。作者将上下文工程描述为一整套把信息在恰当时机、以恰当格式送入模型的技术手段，包括 RAG 检索、工具调用、状态管理、分层摘要等。评论区里，支持者列举了 VS Code Copilot Chat、AnyTool 等产品如何动态拼装上下文，也有人质疑这不过是旧瓶装新酒，甚至将其比作“现代炼金术”。对企业而言，这套方法有望让单一代理掌握成千上万工具；对个人开发者来说，成本、工程复杂度和安全隐患同样值得关注。

首先还是看下文章的原文，我们采用Claude来提取下文章里面的核心观点，即：

上下文工程是AI领域的新兴概念，它将"上下文"从单一提示扩展为包含七个维度的完整信息体系：系统指令**、用户提示****、对话历史、长期记忆****、外部检索信息****、可用工具****和输出格式定义**。这种方法的核心在于为大语言模型提供完成任务所需的全部信息和能力。

上下文工程具有四个显著特点。首先是系统性，它不依赖静态模板，而是通过动态系统生成上下文。其次是动态性，根据具体任务实时定制信息内容，一个请求可能需要日历数据，另一个可能需要邮件历史。第三是精准性，确保在正确时机提供正确信息和工具，避免信息过载或缺失。最后是格式敏感性，重视信息呈现方式，简洁摘要优于原始数据堆砌。

文章通过会议安排案例说明，"廉价演示"和"神奇产品"的区别不在代码复杂度，而在上下文质量。神奇的AI代理能够整合用户日历、邮件历史、联系人信息等多维度上下文，生成自然、有用的回复。这揭示了一个重要趋势：AI代理的失败主要源于上下文失败而非模型缺陷，因此构建有效AI系统的关键是工程化上下文管理。

那么对于上下文工程和传统提示词工程的对比如下表：

接着我们再看下对于复杂问题上下文工程完整的处理流程如下图：

从上面的逻辑图，我们也可以看到上下文工程的核心组件包括了：

• *七个上下文维度 -* 按照文章中提到的分类，用不同颜色区分
• *上下文聚合器 -* 负责动态组装和优先级排序
• *智能处理流程 -* 5个核心处理步骤
• *LLM核心 -* 大语言模型的推理引擎
• *智能输出 -* 最终的结构化结果
• *反馈循环 -* 持续优化机制

所以看了前面的内容后，我的第一感觉就是上下文工程就是一种通用性的Agent，具备了复杂任务感知理解和拆分，任务规划和执行，长上下文记忆和存储，多轮反思和迭代，高度工程化和自主性等关键特点。

那你可能会问，这些东西不是定制开发的Agent都有吗？

而真正的问题就在这里，我们希望和AI的对话问答具备Agent感知行动和反思的能力，但是我们又不希望去定制化开发一个个的Agent，那么是否能够在当前模式下，通过提示词模板规约，RAG增强检索，问题内容的结构化等多种方式，再配合类似Cursor，MCP工具来实现一个完整的灵活的类似Agent工程的AI能力。

所以结合我个人的实践，我们来看下个人如何进行上下文工程的一些实践。

1. AI智能知识库

对于AI智能知识库很多，你完全可以将你的文章，资料，个人经验积累上传存储到AI智能知识库，那么这个知识库就是你个人的一个关键Agent代理或知识外挂。通过这种RAG增强检索，我们可以实现公网知识和私域经验的完美融合，在这种情况下我们进行问答，那么问答的内容就不会脱离我们历史实践，我们RAG知识库就实现了一个个人长上下文记忆的能力。

类似知识直达库，我前面也专门做过分享。比如准备提示词如下：

基于我知识库的内容帮我回答如下问题。有哪些让你受益匪浅的思维方式？ 具体回答的要求如下： 1. 所有的回答素材和内容必须来源于我个人历史文章的内容，不要自己杜撰和创新，你做的更多的是内容整合加工，让整个回答更加符合逻辑。 2. 回答的内容要体现完整的逻辑性，而且通俗易懂，容易理解，如果需要例子也需要知识库里面存在的例子或案例。 3. 整个回答在2000到3000字之间。中间可以有小标题，每个小标题的内容在400字到800字。 4. 回答问题的风格要以我第一人称进行，文章内容风格和我历史文章风格完全一致，不要让人感觉是AI输出内容。 5. 简单来说，你要做的事情就是将我大量历史知识库已有的知识基于问题进行重新归纳和整理，形成一篇完整的条理清楚，逻辑性强的回答。 6. 注意列出4到5点最关键的点进行说明。7. 注意回答的不要太官方，太理论化，尽量通俗易懂，语言直白，可以增加些我文章经常用到的一些惯用词，类似简单来说，也就是，实际上，可以讲等。8. 再次说明不要创新或杜撰任何新名词，新说法，完全引用我知识库已有文章内容进行归纳整合。

对于一些规约我们可以固化到提示词里面，最终知识库输出内容如下：

这个结果来看，相当不错。基本抓住我知识库核心内容特点。如果大家对这个知识库感兴趣也可以订阅加入做验证测试。具体链接如下：

2.AI编程中的需求工程结构化

这个也是我最近做的一个关键实践，就是AI编程中的需求结构化。核心就是尽量减少提示词的内容，而是将我们的需求，我们的开发规范框架模板要求的，拆解为一个个独立的Markdown结构化文件纳入到工程项目整体管理。这些Markdown文件就是AI需要管理和识别的关键上下文。

基于我前面的分析，为了让AI尽量跟我们的需求和实现思路一致，我们还是需要严格的定义需求文档和规约，数据库设计，功能需求说明书，UI/UE界面设计原型。

当然这些内容你也可以借助AI帮你辅助编写，但是完成这些内容编写后需要你自己进行修订和审核。审核完成后才能够进入下一步。

注意，实际AI编程的第一步往往就是通过Markdown结构化的写文档，但是程序员天生不愿意写文档，总是想到哪里写到哪里，这个思路实际是不适合快速转换到AI编程上面来的。

来看下面的截图：

我们做一个简单的学生选课系统，一开始不要去生成代码。先构建一个DesignDoc的子目录来编写文档，至少包括如下几类：

• 总体系统介绍，技术架构和选型说明
• 数据库和对象设计
• UI/UE界面规范约束
• 各个功能点设计（拆分为多个md文件）

对于数据库设计提前进行文档化，你可以借助AI先生成数据库设计，但是需要单独存储为一个独立的文件。

对于UI界面设计规范单独一个md文件，提前规约。其中包括了具体的布局，控件字体大小，颜色选择，边距设计等。实际这个文件编写最好是有UI和前端开发经验的人根据项目实际情况来精确化完成。原因就是我们后续界面UI原型生成需要用到这个markdown文件。

接着是我们每个功能点的详细需求设计文件。在这个文件里面重点是精确的描述和定期需求，包括功能说明，业务流程，业务规则，具体的界面设计要求和原型参考，使用角色等关键内容。

注意这个文件不需要体现任何的技术实现内容，包括技术架构内容，通用的技术架构应该体现在统一md文件中，细节的技术实现逻辑也没必要单独生成文件进行管理，这个毫无意义。

以选课功能为例，参考需求设计md文件如下：

这些文档能否AI辅助生成？

答案当然是可以，注意AI辅助编程首先就应该是AI辅助编写结构化和拆分后，条目化的各个Markdown需求文档和设计文档。生成完成后的文档你需要进行审核和修订，看是否完全满足你的原始需求。在需求完全明确后才能够进入到下一步。

包括需求文档写完后也可以反问AI，如果拿着这个需求说明去编码，是否还有不清晰的，需要进一步完善的地方，并对AI提出的问题和待完善点进行一般补充和完善。

为什么要按上面思路进行管理？

大家可以看下我前面AI辅助编程的文章，所有的内容其实都放在提示词里面，包括和AI工具的多次沟通迭代来完成。而提示词本身就是需求，但是提示词实际没有结构化，工程化的进行管理。这个是不利用后面进行进行多轮迭代变更和优化的。

注意这个工程化问题拆解的思路不仅仅适合AI编程，同样适合其他复杂问题的解决。

3. 模拟和细化思维链步骤

再前面已经谈到上下文工程还有一个关键能力就是问题拆解，多步骤化，知识归纳聚合。对于这块实际是可以通过工程化规约来详细定义AI思维链和思考的步骤的。

比如在通过AI辅助进行方案或文章写作的时候，我们可以先列出我们回答问题的关键点，然后让A基于我们个人知识库内容进行补充和完善。但是实际我们核心思路是希望AI先回答补充每个关键点的内容，然后再对内容进行整合。

当我用TRAE工具进行尝试的时候，我进一步梳理关键提示词如下：

注意这个问题我整理了如下关键点的回答，在对认知的概念做了基础解释后，我希望你完全参考我给出的abcd四个关键点进行展开回答。在回答的时候我需要你基于每个关键点搜索markdown文件夹中相关的素材进行归纳整合，然后再将四个点整合为一篇文章文章，注意在最终输出的文章我还需要你进行审核检查确保逻辑完整，条理清晰，观点明确。

注意实际这个提示词包括了详细的步骤要求，整合要求和审查要求。我们需要AI严格按照我们的要求分步骤进行处理。最终再输出完整的结果。

这个方式个人简单做了验证，基本可行。

当然你还可以进一步使用类似SequenceThinking这些MCP工具来完成整个分析处理问题的分步骤处理。（具体Trae结合MCP工具后续我会再专门发文分享）。

而且对于细分领域复杂问题的处理，我们往往可以将我们历史经验单独定义为一个独立的markdown文件规约来进行约束。要求AI按照我们的规约进行分阶段，分步骤处理。这个处理和我们开发独立Agent类似，但是现在完全可以通过Markdown文件定义+Cursor工具共同来完成。

所以最后再总结下我理解的上下文工程。

我们来代码生成来做一个简单类别。Agent就类似于有一个独立的代码生成APP应用，但是当我们应用生成需求规则变化都需要修改应用源代码并重新发布。而上下文工程核心就是实现一个同样的APP应用，然后是一堆的yaml配置定义文件。我们要做的就是基于问题需求不同，灵活的定义和配置这些yaml文件来满足我们的需求。

这种方式显然比我们大量去开发Agent信息孤岛好很多。当然是否完全可行，仍然需要进一步结合项目实践做验证，才能够分析评估是否可以完成达到工程级实践的要求。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】