AI编程专栏(三)- 实战无手写代码，Monorepo结构框架开发
在学习上下文工程时，我们先对比提示词工程。一是回顾一下之前讲过的提示词工程，二是系统性的弄清楚二者的关系。知道自己应该什么时候，什么场景使用什么工程技巧。
一、什么是上下文工程？
英文： Context Engineering
定义： 构建一个动态系统，以正确的格式提供正确的信息和工具，从而使大语言模型（LLM）能够可靠地完成指定任务。
这是提示工程的演变，是更广泛、更系统级的方法。
二、什么是提示工程
英文： Prompt Engineering
定义： 一门设计、优化和构建有效指令（提示词）以引导人工智能模型生成所需输出的技术和实践。
三、从定义看二者差异
"上下文工程" 的重点在于系统性，为了得到预期的输出，提供必要的信息和工具。
更多的是关注设计一个架构，用于动态地收集、筛选和整合来自多源的数据，构建出完整的上下文。
提示工程的重点在于构建有效提示词，为了得到预期的输出，使用更加准确高效的提示词。
更多的是关注如何进行最终的格式化和指令设计，以最优的方式与LLM沟通。
四、二者关系
二者并不存在谁替代谁的关系，本质上是从两个不同的方向优化AI的输出结果，从而达到获得稳定高质量的输出结果的目标。
或可以将"提示工程"看作"上下文工程"的子集，"上下文工程"为AI提供完成任务所需的所有信息和工具，而 "提示工程"（措辞技巧）只是其中的一部分。
即使拥有了所有的上下文信息，仍需要组织、编排提示词来优化最终呈现，因此提示词工程仍然至关重要。
五、业界呼声转变
为什么现在业界呼声开始从"提示工程"转向"上下文工程"，表现出一种后者替代前者的趋势？
一部分原因是有些人并不是真正理解其意，只是在网上看到了一些说法介绍，未曾深入，便开始高谈阔论。
另一部分是一个新的认知逐渐形成：向AI提供完整高质量的上下文，远比措辞技巧更能/更容易带来优质的结果。
早期LLM应用，开发者更多是通过提示工程（措辞技巧）来诱导输出更优质的结果。但随着大模型功能越来越复杂，需要更多的上下文信息，才能完成最终符合预期的输出。
六、提示词工程有哪些重点？
重点内容主要在一些提示词技巧上面，可以直接看下面的思维导图，罗列了重点技术实现。
详细参考我的另一篇文章，提示词工程。下图是一个总结性内容。
七、上下文工程有哪些重点？
如果说提示工程是一个神奇的句子，那么上下文工程就是为 AI 编写完整的剧本。或者你也可以理解为，提示工程是一个个巧妙的函数，组件，上下文工程是完整的工程项目。
一旦你制作了一个好的提示，提示工程即可结束，是一种稳定态 。上下文工程是以有组织的方式引入内存、知识、工具和数据，会随着功能动态变化，是一种动态 。很可能会随着功能迭代产生裂化，需要持续维护更新。
目前上下文工程不同于提示工程，有非常多论文相关支持。而且提示工程有明显性的技巧理论，比如说少量样本提示，角色设定，链式思考，自我反思等。上下文工程更多体现在系统性的工具，知识和数据的组织能力。
7.1 上下文是一个系统
它是一个系统，而不是一次性的提示。上下文工程，动态地为AI提供所需的一切------指令、数据、示例、工具和历史记录。所有这些都在运行时打包到模型的输入上下文中。
在上下文工程设计中，LLM 最终得到的提示可能包含几个部分：开发人员编写的角色指令、最新的用户查询、动态获取的相关数据，以及一些所需输出格式的示例。
7.2 系统是动态的
上下文可以动态地出现（外部数据，工具，交互，多模态），因此，构建最终提示的逻辑也必须是动态的，而不仅是一个静态提示。
7.3 提供正确的信息
系统不能很好的执行，一个常见原因是没有正确的上下文。LLM不会读心术，你需要给他们正确的信息。否则 "垃圾进，垃圾出"。
7.4 提供正确的工具
LLM 并不总是能够根据输入来解决任务，在某些情况下，想授权 LLM 执行操作，需要确保它具有正确的工具（比如Excel转JSON，需要有Python相关工具），为 LLM 提供正确的工具与为其提供正确的信息一样重要。
7.5 正确格式输入/输出
简短但描述性强的信息，比庞大的 JSON 数据更有用。为了确保 LLM 能够使用你的工具，工具的输入参数至关重要。
八、常规上下文工程技巧
为了获得优质结果，需要提供清晰的上下文和必要的信息，输出质量直接取决于输入质量。
是不是上下文提供的越详细越好？很明显不是，上下文太少（或类型错误）会导致模型缺乏所需的关键信息；无关上下文太多则会浪费 token 甚至降低性能，找到最佳平衡点并非易事。
8.1 提供高质量的上下文技巧
-
精准：模糊需求会导致模糊的答案，因此越具体清晰结果越好。
-
提供相关代码：提供请求相关的特定文件、文件夹或代码片段。
-
添加设计文档：粘贴或附加相关设计文档的部分内容，提供更全面的信息。
-
添加示例：展示您希望最终输出的内容示例结构。
-
外部知识：提供领域知识（公司特定信息、API 规范），检索信息并与上下文联系起来。
-
巧妙维护对话历史记录（和下面的短期记忆类似）：总结历史对话，为后面对话提供上下文，通常不需要完整的历史记录。
-
说明限制：清楚地列出要求，例如要使用的库、要遵循的模式或要避免的事情。
-
工具使用：确保访问外部信息时，拥有相应的工具（context7或MCP）。工具返回的信息应以 LLM 能解读的方式进行格式化。
-
短期记忆：如果对话持续了一段时间，则创建对话摘要并在将来使用（比如Cursor的自动摘要，它用小模型进行摘要总结）。
-
长期记忆：如果用户在之前的对话中表达了偏好，则能够获取该信息并存储为长期记忆（MCP工具或Cursor近期推出的generate Memories）
-
提示工程：在提示中清楚地使用提示工程技巧，保证合理的提示词使用。
8.2 上下文污染劣化
随着我们构建丰富的上下文，一个新问题诞生：上下文实际上会随着时间的推移而自我毒化。
这种现象被 Workaccount2 在 Hacker News 上称为"上下文腐烂"，描述了随着对话时间的延长，干扰、死胡同和低质量信息的积累，上下文质量会下降。
-
上下文修剪和刷新：通过定期汇总，启动新上下文，然后将前一个汇总输入进来。丢弃噪音的同时保留了基本状态。对上下文进行垃圾回收。
-
结构化上下文边界：使用清晰的标记来区分不同的工作阶段。（"先前尝试" 和 "当前工作上下文")
-
渐进式上下文细化：取得重大进展后，从头开始重建上下文。提取关键决策、成功方法和当前状态，然后重新开始。
-
检查和摘要：定期让模型总结已完成的任务和当前状态。在开始新的会话时，可以使用这些摘要作为新上下文的种子。
-
上下文窗口：对于非常长的任务，将其分解成几个阶段，每个阶段都可以从头开始，只保留前一阶段必要的内容。
优秀的上下文工程需要有意识的信息管理------不仅要决定包含哪些内容，还要决定何时排除、汇总或刷新。
九、生产级别的上下文工程
生产级系统通常会从更大的方向结构来做系统性决策。此类更适合Agent的开发系统，而非单纯的编程coding阶段。
-
问题分解和控制流：健壮的系统通常会有结构性的问题分解流程和任务控制流程，提供将问题分解为多个子任务或多步骤工作流。
-
模型选择和路由：针对不同的任务使用不同的 AI 模型。轻量级模型用于简单任务或初步答案，而重量级模型用于最终解决方案。针对编码任务使用代码专用模型，而针对对话任务使用通用模型。
-
工具集成和外部操作：可以执行操作（调用 API、数据库查询、打开网页、运行代码），您的软件需要管理这些功能。这包括为 AI 提供可用工具列表和使用说明，以及实际执行这些工具调用并捕获结果。
-
用户交互和用户体验流程：LLM 应用程序可能让用户参与其中。编码助手可能会建议更改，然后要求用户确认应用。这些用户体验决策也会影响上下文。
-
防护栏和安全：在生产中必须考虑误用和错误。这可能包括内容过滤器（用于防止有害或敏感的输出）、工具的身份验证和权限检查（例如，防止 AI 删除数据库，因为它包含在指令中）以及输出验证。某些设置会使用第二个模型或规则来仔细检查第一个模型的输出。
-
评估和监控：需要持续监控 AI 的运行情况。记录每个请求和响应，可以帮助分析故障和异常值。
十、最能体现上下文工程的产品
- RAG 检索增强生产
- Agent 各类Agent工具系统
- 工作流（n8n、扣子、Dify）
- AI编程IDE的Chat能力，Agent能力
十一、参考资料
addyo.substack.com/p/context-e...