起因：一个被反复问到的问题

过去半年，我在各种场合被问过同一类问题："Prompt 到底怎么写才好？" 提问的人包括产品经理、创业者、写公众号的朋友，甚至我妈。每次我都试图认真回答，但总觉得哪里不对。后来想明白了：这个问题本身就问窄了。好比有人问"怎么跟服务员说话才能吃好"，你可以教他话术，但真正决定这顿饭质量的，是他走进了哪家餐厅。

这是一个系列的第一篇。我想把过去一年在 AI 工程实践中反复碰到的几个新概念拆开讲清楚。不是词典式的定义罗列，而是顺着实际使用的场景，说说这些概念为什么会被造出来，以及它们之间的关系。

今天先讲两个最基础的：Prompt 和 Context Engineering。

Prompt：一种很特殊的"说话"

Prompt 这个词翻译成中文是"提示词"，听起来平平无奇。但它背后藏着一个有意思的事实：这可能是软件工程史上第一次，一个 API 的输入和输出都是非确定性的。

什么意思？传统编程里，你写一条 SQL 查询，输入确定，输出就确定。你调一个函数，传同样的参数，返回同样的结果。但 Prompt 不是这样。你对 ChatGPT 说"帮我写一封邮件"，每次出来的东西都不一样。更微妙的是，你稍微换个说法，比如加一句"用正式语气"，结果可能完全不同。

所以 Prompt 的本质是什么？它是一个用自然语言写的 API 调用。从技术层面看，它就是 HTTP 请求体里的 messages 字段，跟你往数据库发一条 SQL 没有本质区别。但从使用层面看，它又像极了人与人之间的对话。

这种跨界性恰恰是它需要被单独命名的原因。

我之前一直把 Prompt 类比为"跟 AI 点菜"：你说得越清楚，上来的菜越对你胃口。这个比喻在入门阶段很好用，但用久了会发现它遮蔽了一些东西。点菜只需要说清楚你要什么，但写 Prompt 经常需要同时做四件事：给 AI 一个角色设定（"你是一个资深编辑"）、描述具体任务（"帮我改这段文章"）、设置约束条件（"保持原文风格，字数不超过 500"）、提供参考示例（"类似这种语气"）。

角色、任务、约束、示例。这四个要素组合在一起，已经构成了一套工程实践。这也是为什么"Prompt Engineering"会成为一个专门的学科，而不只是"学会跟 AI 说话"那么简单。

转折：写好 Prompt 还远远不够

讲到这里，好像只要把 Prompt 写好就万事大吉了。我也曾经这么以为。

转折发生在我开始用 Claude Code 做实际项目的时候。有一次我写了一个非常精心的 Prompt，详细描述了需求，给了示例，设了约束。但 AI 的输出还是差强人意。排查了半天才发现问题：它缺少项目的技术栈信息，不知道我们用的是什么框架，不了解现有代码的风格，对业务背景一无所知。

我的 Prompt 本身没问题。问题在于，AI 在回答之前"看到"的信息太少了。

这就像你走进一家高级法餐厅，对服务员说"来一份你们最好的牛排，七分熟，配红酒"。你的表达清晰、具体、有品位。但如果这个服务员刚上班第一天，不知道厨房今天有什么食材，不知道酒单上哪些酒跟牛排配，不知道你上次来的时候对某道菜过敏——那你说得再好，这顿饭大概率还是要出问题。

真正决定服务质量的，不只是你说的话，而是服务员在你开口之前已经知道多少。

Context Engineering：布置 AI 走进的那个房间

这就引出了第二个概念：Context Engineering，上下文工程。

如果说 Prompt 是"你跟 AI 说的话"，那 Context 就是"AI 走进的那个房间"。Context Engineering 做的事情，就是在 AI 开始工作之前，把这个房间布置好。

还是用餐厅的比喻。在你开口点菜之前，一个好餐厅的服务系统已经做了大量准备工作：餐厅类型决定了基础菜单（这相当于 System Prompt），你的会员档案记录了你的偏好和过敏史（这相当于 Memory），今天的食材库存和特价信息已经同步给服务员了（这相当于检索到的文档），你坐在哪个包间、是商务宴请还是家庭聚餐，这些场景信息服务员心里也有数（这相当于会话状态）。

把这个映射关系写得更明确一些，搞技术的朋友会觉得很亲切：

从 Prompt Engineering 到 Context Engineering，问题的核心发生了位移："怎么把话说清楚"变成了"让 AI 看到什么，以什么顺序看到"。

这个位移看起来只是范围扩大了，实际上是一个质变。因为语言模型的上下文窗口是有限的。即便现在最先进的模型能处理几十万 token，面对一个真实项目的全部代码和文档，塞不进去就是塞不进去。你必须做取舍：哪些信息放进去，哪些扔掉，放进去的信息以什么顺序排列。

这让我想到搜索引擎。Google 面对的问题是：互联网上有几十亿网页，用户搜一个关键词，你只能返回前十条结果，怎么决定哪十条？Context Engineering 面对的问题结构上是一样的：跟当前任务相关的信息可能有几百万 token，但窗口只有几十万，怎么选？

现在能做什么

说回实操层面。如果你今天就想改善跟 AI 协作的效果，两个层面都可以着手。

Prompt 层面，记住那四个要素：角色、任务、约束、示例。不需要每次都用全，但心里要有这个框架。很多时候 AI 表现不好，不是它笨，是你忘了告诉它你希望它扮演什么角色、有什么限制条件。

Context 层面，留意你正在使用的工具已经提供了哪些能力。Claude Code 的 CLAUDE.md 文件就是一个典型的 System Prompt 入口——你可以在里面写上项目的技术栈、代码风格、业务规则，AI 每次启动时都会读取。各种 AI 助手的 Memory 功能本质上是帮你维护长期上下文。RAG（检索增强生成）则是在每次对话时动态注入相关文档。

这些工具背后的逻辑是一致的：帮你把 AI 要走进的那个房间布置得更周全。

未完的困惑

写到这里，有一个问题我还没想清楚。

Context Engineering 的核心挑战是信息取舍。但做取舍需要判断力，而判断力本身能不能也交给 AI？也就是说，让 AI 自己决定它需要看什么——这条路走到底，Prompt 和 Context 的边界会不会完全消失？

这个问题留到系列的后面再聊。下一篇会讲 Agent 和 Agentic Workflow，到那个时候，"谁来决定 AI 看到什么"这个问题会变得更加紧迫。