AI提示工程革命：从Prompt到Context的协作进化

深夜三点，你仍在与人工智能激烈搏斗，频繁切换于ChatGPT、Claude、Gemini等多个平台之间，反复折腾难以入眠。

最终，仍然未能让AI生成一封令人满意的邮件——这并非笑话，而是许多人的真实体验。

一位开发人员尝试使用ChatGPT撰写一封不那么“机械式”的销售邮件，结果连续修改、询问、尝试了147次，每次生成的内容依旧呆板空洞，毫无人情味。

最终，在第147次尝试时，他崩溃地敲出一行字：“你就不能先问问我的需求吗？”

没想到这句抱怨意外点燃了灵感火花：如果AI能够主动提问、索取任务所需的详细信息，会怎样？随后，他在72小时内开发出一个名为“Lyra”的元提示（meta-prompt）。

简而言之，Lyra相当于为ChatGPT更换了一个人格，使其在回应请求前先反向采访用户，获取关键信息后再动笔。例如：以往你对ChatGPT下达指令“写一封销售邮件”，它只会生硬地吐出一个模板。

使用Lyra后，同样的请求会引发ChatGPT连续追问产品、目标客户、痛点等关键细节，然后根据你的回复撰写一封真正符合需求的邮件。

这篇帖子在Reddit上迅速走红，获得了近万点赞和上千条评论。许多网友称赞这是一个“绝妙的想法”，也有人吐槽：“折腾147次Prompt，还不如自己直接写邮件来得快”。

“都已经尝试了一百多次，有那时间早就写完了。”

荒唐之余，这场“147次失败召唤GPT”的喜剧反映了一个现实：让AI完成一件看似简单的任务，有时比想象中复杂得多，也滑稽得多——提示工程，确实需要变革了。

AI协作的全新路径：营造“氛围”与提供“上下文”

Lyra的诞生看似偶然，实则体现了提示词技术演进的一种方向。过去，人们热衷于在提示词上下功夫，竭尽全力确保输出效果。有时，提示词的长度甚至超过了AI生成的内容。

而Lyra所受到的质疑，也正是对这种传统方法的反思。其背后是AI社区近期兴起的新趋势，例如上下文工程（context engineering）。

上下文工程，本质上是一种编程与系统设计活动，被视为AI系统设计中的“下一代基础能力”。它是在AI应用场景中构建背景、工具、记忆、文档检索等全流程体系，使模型能够在可靠的上下文支持下执行任务。

这其中包括：

- 记忆结构：如聊天历史、用户偏好、工具使用记录；

- 向量数据库或知识库检索：在生成内容前检索相关文档；

- 工具调用指令模式：如数据库访问、代码执行、外部API格式说明；

- 系统提示：为AI设置的角色、边界、输出格式规则；

- 上下文压缩与摘要策略：管理长期对话内容压缩，确保模型高效访问。

好比你在编写提示时，是在一个已填充了历史记录、主题文件、用户偏好等信息的环境中操作——提示是“指令”，上下文是“指令背后的材料与背景”。

这部分工作是工程师的职责，虽然借鉴了提示工程的一些理念和技巧，但应用场景仍在于软件工程和架构系统设计。相比提示的微调，上下文更适用于实际生产环境，实现版本控制、错误追踪、模块复用等效果。

什么？工程师的工作，与普通用户有何关系？

简单来说，如果提示是点火开关，那么上下文工程就是设计整个打火机，确保一按即能冒出火焰。

复杂来看，上下文工程为构建、理解和优化面向未来的复杂AI系统，提供了所需的规范化系统框架。它将焦点从提示的技巧，转向信息流通与系统优化的艺术。

中科院的一篇论文指出了两者的关键差异：

目前，业界将上下文工程视为智能体构建的重要实践。尤其是上下文和工具调用等，能显著提升模型表现。

更轻松的提示，更清晰的结果

然而，仍需回到那个问题：工程师的工作，与我这样的普通用户有何关联？

当你作为普通用户编写提示时，上下文工程与提示工程虽不完全相同，但实质上存在深刻联系——理解它们的关系，有助于你撰写出更有效、上下文更贴切的提示。

传统提示方法为何常失败，且依赖运气？因为许多人使用AI仍像使用搜索引擎，几句指令就期望完美答案。但大模型生成内容依赖于理解上下文和模式匹配，如果提示模糊、信息不足，模型只能盲目猜测，往往产生千篇一律的套话或答非所问。

这可能是因为提示写得含糊、需求不够明确，但也可能是因为提示被置于不够结构化的上下文环境中。例如被冗长的聊天历史、图片、文档、混乱格式所掩盖，模型很可能“抓不住重点”或“回答偏离主题”。

以Lyra中写邮件的场景为例，一个结构完善的窗口，包含了用户之前的沟通历史、语气偏好，模型就能通过这些信息，组织出更符合用户口吻的邮件草稿——甚至无需用户编写复杂的提示。

不过，即使用户仅停留在提示层面，无法实施上下文工程，也可以借鉴其中的一些思路。

例如，来自Reddit社区ChatGPTPromptGenius的一种形式“协同提示”（Synergy Prompt），就是在提示层面结构化上下文。

它提出了三个核心组件：

- 元框架：每个元框架为对话添加特定视角或焦点，是对AI构建的“基础认知模块”（如角色设定、目标说明、数据来源说明等）；

- 具体信息框：每个上下文模块中的具体内容；

- 对话地图：记录整个对话的动态轨迹，捕捉每次互动和语境选择。

简言之，就是不断整合碎片化信息，形成模块，最终化为一个图谱。使用时，即可整体调用这些已有模块。

当AI掌握从主干到细节的完整语境结构时，它便能精准提取所需信息，提供精确的针对性回应。

这也正是上下文工程力求实现的目标，谁说这不是一种相辅相成呢？