你跟 AI 说的话，其实只是冰山一角

一个你可能碰到过的情况

你打开 ChatGPT 或 Claude，输入"帮我写一封请假邮件"，它回了一封。语气不对，太正式了。你说"随意一点"，它改了，但又太随意了。你再调，来回几轮，最后凑合用了。

大多数人在这个阶段会觉得：我得学会怎么跟 AI "说话"。于是去搜"Prompt 技巧"、"提示词大全"，研究怎么措辞才能让 AI 给出更好的回答。

这个方向不能说错，但它只是冰山一角。

过去一年我在实际项目中用 AI 写代码、做文档、搭工作流，最大的一个认知转变是：AI 表现好不好，"你说了什么"只占一小半，"AI 开口之前已经看到了什么"才是大头。 你以为在跟 AI 说话，其实在给它布置房间。

这篇文章把两个最基础的概念拆开讲清楚：Prompt 和 Context Engineering。如果你写过代码但还没深入接触过 AI 工程实践，这篇就是为你写的。

什么是 Prompt

先退一步，看看你每天在做的事情。

你在终端里敲一条命令，比如 ls -la，系统返回文件列表。你写一条 SQL 查询 SELECT * FROM users WHERE age > 18，数据库返回符合条件的记录。这两个场景有一个共同点：输入确定，输出确定。同样的命令、同样的数据，跑一百次结果一模一样。

现在你打开 ChatGPT，输入"帮我写一封请假邮件"。跑三次，三次结果都不一样——措辞不同、结构不同、甚至长短都不同。

这就是 Prompt 最根本的特殊性。

Prompt 是什么？

一句话： 你发给 AI 模型的那段文字输入。

技术层面： 它就是你通过 API 发送的 HTTP 请求体里 messages 字段中的内容，跟你往数据库发一条 SQL 查询在形式上没有本质区别。

使用层面： 它像极了人与人之间的对话——用自然语言表达意图，但接收方不是人，而是一个统计模型。

跟 SQL 的关键区别： SQL 是确定性的，同样的输入永远返回同样的输出。Prompt 是非确定性的，同样的输入每次可能返回不同的输出。这是软件工程史上第一次，一个系统的输入和输出都用自然语言表达，而且结果不可完全预测。

"Prompt"翻译成中文是"提示词"，这个翻译不太好，容易让人觉得它只是一个"提示"，一个触发词。实际上它是一条完整的指令，只不过用自然语言写成。

Prompt 的四个要素

既然 Prompt 是一条指令，那它跟传统编程里的函数调用有什么相似和不同？

一个函数调用通常需要：函数名、参数、有时还有配置项。Prompt 的结构没有这么死板，但经过大量实践，大家总结出了四个常见的组成要素：

1. 角色（Role）： 你希望 AI 扮演什么身份。"你是一个资深的前端工程师"、"你是一个耐心的小学老师"。这决定了 AI 用什么视角和语气来回应。
2. 任务（Task）： 你具体要它做什么。"帮我把这段代码从 JavaScript 重构成 TypeScript"、"解释一下什么是递归"。
3. 约束（Constraints）： 限制条件。"不超过 200 字"、"用中文回答"、"不要用专业术语"。
4. 示例（Examples）： 给 AI 看一个你期望的输出样例。这在 AI 领域有个专门的名字叫 few-shot learning——通过几个例子让模型"学会"你要的模式。

不是每次都要用全四个。你说"帮我写个请假邮件"只有任务，也能得到结果。但当 AI 的输出不符合预期时，通常是因为你漏了其中一两个要素。回头加上，效果往往立竿见影。

一个完整的例子：

你是一个技术博客编辑（角色）。
请帮我把下面这段技术笔记改写成一篇博客文章（任务）。
要求：保持原文的技术准确性，语气轻松但不轻浮，长度控制在 800-1200 字（约束）。
参考风格类似这样：[附上一段示例文章]（示例）。

这四个要素组合在一起，就构成了 Prompt Engineering 这个学科的基础。"Engineering"这个词不是随便用的——它意味着写 Prompt 不是一种直觉或天赋，而是一套有章法的工程实践。

Token 和上下文窗口：一个物理限制

在继续往前走之前，需要先讲一个底层概念，否则后面的内容会悬在空中。

当你输入一段文字给 AI，模型不是按"字"来处理的，而是按 Token 来处理的。

Token 是什么？

一句话： AI 模型处理文本的最小单位。

具体来说： 一个 Token 大约等于一个英文单词，或者半个到一个中文字。"Hello world" 是 2 个 Token，"你好世界" 大概是 3-4 个 Token。具体怎么切分取决于模型使用的分词器（tokenizer），但你不需要关心细节，知道数量级就够了。

为什么它重要？ 因为每个 AI 模型都有一个 上下文窗口（Context Window），也就是它一次能处理的 Token 数量上限。这个上限是硬性的，超过了就塞不进去。

2023 年初，GPT-3.5 的上下文窗口是 4096 个 Token，大概相当于 3000 个英文单词——一篇短文章的长度。到了 2026 年，主流模型的上下文窗口已经到了 128K 甚至 1M Token，相当于一本书甚至几本书。

但即便窗口越来越大，它仍然是有限的。一个真实项目的全部代码可能有几百万行，文档、历史记录、业务规则加起来可能有几千万 Token。你不可能把所有东西都塞进去。

这意味着你必须做选择：哪些信息放进去，哪些不放，放进去的以什么顺序排列。

这个选择，就是从 Prompt 走向 Context 的关键转折点。

System Prompt、User Prompt 和 Assistant：三种角色

在理解 Context 之前，还需要理解一个技术细节：AI 对话 API 里的三种消息角色。

当你用 ChatGPT 或 Claude 的网页界面聊天时，你看到的是一个简单的对话框。但在底层，发送给模型的不是一条消息，而是一个消息列表，列表里每条消息都带有一个角色标签：

[
  {"role": "system", "content": "你是一个资深前端工程师，擅长 React 和 TypeScript。"},
  {"role": "user", "content": "帮我写一个 Todo 组件"},
  {"role": "assistant", "content": "好的，这是一个基础的 Todo 组件..."},
  {"role": "user", "content": "加上删除功能"}
]

三种角色是什么？

• System（系统消息）： 在对话开始之前就设定好的背景信息和行为规则。用户通常看不到它。它相当于你在新员工入职第一天给他的工作手册——不是针对某个具体任务的指令，而是"你在这家公司应该怎么工作"的总纲。

• User（用户消息）： 就是你说的话。你的提问、指令、反馈。

• Assistant（助手消息）： AI 之前的回复。对话历史里的 AI 回答会作为后续对话的参考——模型通过看自己之前说过什么来保持对话的连贯性。

System Prompt 是一个非常重要的概念。当你在 ChatGPT 里选择"GPT-4"还是"GPT-4o"，或者选择一个定制的 GPT，背后的区别很大程度上就是 System Prompt 不同。同一个基础模型，给它不同的 System Prompt，表现可以天差地别。

在实际工程中，System Prompt 通常由应用开发者设置，用户不直接接触。但有些工具把这个能力暴露了出来。比如 Claude Code 的 CLAUDE.md 文件，本质上就是一个你可以自己编辑的 System Prompt 入口——你在里面写上项目的技术栈、代码风格、命名规范，AI 每次启动时都会读取。

转折：写好 Prompt 还远远不够

到这里，好像只要把 Prompt 写好——角色、任务、约束、示例都配齐——就能得到好的结果。

我也曾经这么以为。转折发生在我开始用 AI 做实际项目的时候。

有一次我写了一个非常精心的 Prompt，详细描述了需求，给了示例，设了约束。但 AI 的输出还是差强人意。排查了半天才发现问题：它不知道我们项目用的是什么框架，不了解现有代码的风格约定，对业务背景一无所知。

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

这就像你去医院看病。你对医生描述症状描述得非常清楚："左膝盖内侧疼，上下楼梯加重，持续两周了。"你的表达精确、具体。但如果这个医生看不到你的病历、不知道你的手术史、没有 X 光片——他的诊断质量不取决于你说得多好，而取决于他在你开口之前已经掌握了多少背景信息。

这个发现让我理解了一件事：Prompt 决定了你"说"什么，但 AI 的表现更多取决于它"看到"什么。

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

这就引出了第二个核心概念。

Context Engineering 是什么？

一句话： 在 AI 处理你的请求之前，把它需要的信息准备好、组织好、送到它面前。

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

跟传统应用的对比： 如果你做过后端开发，这个概念其实很亲切。传统应用里也有类似的分层：全局配置（环境变量、config 文件）决定了应用的基本行为，会话状态（Session）记录了用户的交互历史，请求数据（HTTP body）是用户本次发来的具体内容，依赖注入把应用需要的服务和数据源接上。AI 应用里的结构几乎是一一对应的。

把这个对应关系展开：

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

为什么顺序也很重要？因为上下文窗口是有限的（前面讲过），你塞进去的信息有主次之分。研究表明，语言模型对上下文中靠前和靠后的信息记忆更深，中间的部分容易被"遗忘"——这个现象被称为 Lost in the Middle。所以不光要选对信息，还要把最重要的放在对的位置。

一个类比：Context 像搜索引擎的排序

这让我想到一个结构上很像的问题。

Google 面对的挑战是：互联网上有几十亿网页，用户搜一个关键词，你只能返回第一页的十条结果。怎么决定返回哪十条？这是一个信息检索和排序问题。

Context Engineering 面对的挑战结构上是一样的：跟当前任务相关的信息可能有几百万 Token（整个代码库、所有文档、历史对话记录），但上下文窗口只有几十万 Token。怎么选？选完怎么排？

这不是一个"写好一句话"就能解决的问题。这是一个系统设计问题。这也是为什么"Context Engineering"这个概念会被独立提出来——它解决的问题层次跟 Prompt Engineering 不一样。

Context 的四个来源

实操层面，AI 能"看到"的 Context 通常来自四个地方：

1. System Prompt / 系统配置

应用启动时就加载好的规则和背景。比如你在项目根目录放一个配置文件，写上"这是一个 TypeScript + React 项目，使用 Next.js 14，CSS 方案用 Tailwind"——AI 每次启动时读取，就知道了项目的基本技术栈。

2. 对话历史 / Memory

你跟 AI 之前说过什么，它之前回答过什么，都会作为 Context 带入下一轮对话。有些工具还提供了跨会话的 Memory 功能——AI 能"记住"你上周告诉它的事情。

3. 动态检索的信息（RAG）

RAG 是 Retrieval-Augmented Generation 的缩写，意思是"检索增强生成"。它的原理是：在你提问之后、AI 回答之前，系统先去知识库里搜索跟你问题相关的内容，把搜到的内容塞进 Context 里，然后 AI 基于这些信息来回答。

这解决了 AI 知识截止日期的问题。模型的训练数据可能截止到半年前，但通过 RAG 你可以让它基于今天的文档来回答。

4. 工具调用的返回结果

AI 调用了一个外部工具（比如查询数据库、读取文件），工具返回的结果也会成为 Context 的一部分。这个话题在下一篇讲 MCP 时会展开。

现在你能做什么

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

Prompt 层面，记住四个要素：角色、任务、约束、示例。不需要每次都用全，但当 AI 表现不好的时候，检查一下是不是漏了某个要素。大部分情况下，加一个角色设定或者一个示例，效果就会有明显提升。

Context 层面，留意你正在使用的工具提供了哪些配置入口。很多 AI 工具都有类似"自定义指令"或"系统设定"的地方，本质上就是让你编辑 System Prompt。如果你的工具支持 Memory，花几分钟告诉它你的基本情况和偏好。如果你在做开发，看看项目里有没有类似 CLAUDE.md 或 .cursorrules 这样的配置文件——它们就是 Context Engineering 的最直接入口。

一条判断标准： 如果你发现自己在每次对话开头都要重复同样的背景信息，那说明你需要的不是更好的 Prompt，而是更好的 Context 配置。

还没讲完

这篇讲了两个概念：Prompt 是你说的话，Context 是 AI 走进的房间。Prompt Engineering 关心怎么把话说清楚，Context Engineering 关心让 AI 在开口之前就掌握足够的信息。

但有一个问题留着没答：AI 能"看到"信息了，但它能"做"事情吗？你让它查你的日历、发一封邮件、执行一段代码——它做不到。它就像一个被关在隔音玻璃房里的顾问：看得见、想得清楚，但没有手。

下一篇讲 MCP 和 Skill——怎么给 AI 接上手脚，再给它一本操作手册。

这是 AI 工程入门系列的第一篇。如果你已经理解了 Prompt 和 Context 的区别，推荐继续阅读进阶篇《Prompt 与 Context Engineering：你说的话，和 AI 走进的房间》，那篇从实践角度深入讨论了信息取舍的策略和 Context 设计的哲学。