Prompt 工程基础：与模型对话的核心范式

重新理解“对话框”这个产品界面

ChatGPT 的爆火让全世界习惯了一个新的交互范式：用户输入一段自然语言，模型返回一段自然语言。但对产品经理来说，这个看似简单的对话框背后，是一套与 traditional 软件完全不同的运行逻辑。

传统软件是确定性的：点同一个按钮，永远得到同一个结果。而大语言模型是概率性的：它每次都在预测“下一个最可能的 token”。这带来了产品设计的根本差异——你无法用“写好代码就稳定”的思路去设计 AI 功能，而必须学会用语言本身作为控制接口。

产品决策提示：AI 产品的“功能规格”很大程度上就是 Prompt。写清楚 Prompt，等于写清楚了一半的 PRD。

模型是如何“理解”你的输入的

你不需要懂得 Transformer 的数学细节，但要理解三个对产品设计有直接影响的事实：

1. 模型没有记忆，只有上下文。多轮对话中，模型每次都是重新读取整个对话历史。所谓“记忆”，是把历史拼进上下文窗口而已。这意味着：上下文越长，成本越高，且早期信息可能被“稀释”。
2. 模型的知识有截止日期。训练数据有时间边界，问它之后发生的事，它要么不知道，要么“编”。这就是 RAG（检索增强生成）存在的理由。
3. 模型对措辞极其敏感。同一意图换个说法，输出质量可能差异巨大。这不是 bug，是概率生成的本质。

Prompt 的四大要素

一个结构完整的 Prompt 通常包含四类信息：

要素	作用	示例
指令（Instruction）	告诉模型要做什么	“总结下面这篇客服工单的核心问题”
角色（Persona）	设定视角和专业度	“你是一位有 5 年经验的 SaaS 客服主管”
上下文（Context）	提供背景与约束	“我们的产品是面向中小企业的报销软件”
输出格式（Output Format）	规定返回的形态	“用不超过 100 字、分两点输出”

新手常犯的错误是只写指令，忽略其余三项。而经验丰富的做法是：先明确输出格式和验收标准，再倒推需要什么上下文。

一个对比实验

假设要做一个“商品评论情感分析”功能：

差的 Prompt：

分析这条评论的情感。

好的 Prompt：

你是一个电商评论分类器。请判断以下评论的情感倾向，
输出 JSON：{"sentiment": "正面|中性|负面", "reason": "不超过20字"}。
评论：「快递很快，但是包装破了，客服处理态度还行。」

第一条会返回一段不可控的自由文本，无法入库、无法统计；第二条返回结构化数据，可以直接进入下游流程。

产品决策提示：凡是 AI 输出要被程序消费的场景（打标签、分类、抽取），必须在 Prompt 中约定输出格式并做好解析失败的兜底。这不是工程细节，是产品可靠性的一部分。

站在产品经理的角度看 Prompt 的地位

Prompt 不是“调调措辞”的小技巧，而是 AI 产品的新一代“配置文件”：

• 可灰度：不同用户群可以下发不同版本的 Prompt，做 A/B 测试；
• 可迭代：不改代码就能改变产品行为，迭代周期以小时计；
• 有风险：措辞的微小改动可能在长尾场景引发连锁反应，需要像对待代码变更一样做回归测试。

Cursor 的代码补全、Perplexity 的搜索摘要，背后都是经过大量打磨的系统级 Prompt。产品的“手感”，很大程度是 Prompt 工程的手感。

本节要点

• 大模型是概率生成系统，Prompt 是控制它行为的语言接口，相当于 AI 产品的配置文件和半份 PRD。
• 模型没有记忆只有上下文，知识有截止日期——这两个限制分别催生了上下文管理和 RAG 两个完整的产品领域。
• 完整的 Prompt 包含指令、角色、上下文、输出格式四要素，输出格式对下游程序消费尤为关键。
• Prompt 是可灰度、可迭代、也需回归测试的产品资产，应纳入版本管理而非散落在个人对话里。
• 下一步：学习系统化的 Prompt 设计方法，从“凭感觉改措辞”走向“有框架地做设计”。