AI新纪元：从“提示”到“上下文”的进化

夜深人静，你在 ChatGPT、Claude、Gemini 之间徘徊，为了一封理想的邮件奋战至凌晨三点。这并非笑话，而是许多人的日常。

一名程序员试图让 ChatGPT 撰写一封不「机械」的销售邮件，然而，他进行了147次修改和询问，结果依旧空洞而刻板，完全不像人工所写。

在第147次尝试后，他崩溃地喊出：「你就不能问问我需要什么吗？」这句吐槽却成了转折点：如果 AI 能主动提问，获取完成任务所需的信息，会怎样？于是，他花费72小时开发出了「Lyra」——一个元提示工具。

简而言之，Lyra 改变了 ChatGPT 的角色，让它先反向采访用户，收集关键信息再创作。例如：你要求写销售邮件，它以前只会生硬地给出一个模板。

而使用 Lyra 后，ChatGPT 会主动询问产品、目标客户、痛点等细节，根据你的回答定制一封真正符合需求的邮件。

此帖子在 Reddit 上迅速走红，收获近万赞和上千评论。有人称赞这是「绝妙的主意」，也有人吐槽：「折腾147次提示词，还不如自己写封邮件快。」

「都试了一百多次了，有这功夫早就写完了。」

这一荒诞的喜剧背后，折射出 AI 执行的简单任务往往比想象中复杂得多——提示词技术，是时候做出改变了。

AI 合作新方向：注重「氛围」与「上下文」

Lyra 的诞生看似偶然，实则代表了提示词技术发展的新趋势。过去，人们热衷于优化提示词以确保输出效果，有时提示词长度甚至超过 AI 产出。

Lyra 引发的质疑，是对传统方法的反思。它反映了 AI 社区的新趋势，如 context engineering。

Context engineering 是编程与系统设计的活动，被视为 AI 系统设计中的「下一代基础能力」。它构建背景、工具、记忆、文档检索等全流程体系，让模型在可靠上下文中执行任务。

包括：

- 记忆结构：如 chat history、用户偏好、工具使用历史；

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

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

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

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

写提示词时，你处于充满历史、主题文件、用户偏好的环境中——提示词是「指令」，而上下文是「指令背后的材料与背景」。

这是工程师的工作，虽然借鉴了 prompt engineering 的理念与技巧，但应用场景在软件工程与架构系统设计上。相较于提示词的微调，context 更适用于实际生产。

更简单的提示词，更清晰的结果

回到问题核心：工程师的工作与你有何关系？

当你是普通用户写提示词时，Context Engineering 与 Prompt Engineering 有深刻联系——理解它们的关系有助于写出更有效、更贴合上下文的提示。

传统提示词方法常失败的原因在于，许多人用 AI 如同用搜索引擎，几句指令就想得到满分答案。但大模型生成内容需理解上下文和模式匹配。如果提示模糊、信息匮乏，模型只能硬猜，结果往往千篇一律或答非所问。

这可能是因为提示词模糊、需求不清晰，也可能是因为提示词放在缺乏结构化的上下文中。例如被冗长的历史聊天、图片、文档掩盖，模型可能「抓不到重点」或「回答跑题」。

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

它提出了三个核心构件：

- 元框架 Metaframe：为对话添加特定视角或焦点；

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

- 对话地图 Chatmap：记录整个对话的动态轨迹。

整合碎片化的信息为模块，最后化为图谱。使用时整体性地调用这些模块。

当 AI 掌握从主干到细枝末节的完整语境结构时，就能精准调取所需信息，给出精确回应。

这正是 context engineering 的目标——谁说这不是一种互相成就呢？