Day03-Prompt工程与Prompt-Contract

Day 3：Prompt 工程与 Prompt Contract

学习目标

今天的目标是建立对 Prompt 工程的系统理解，从”随便写写”进化到”结构化设计”。

很多人以为 Prompt 工程就是写好一句话，然后反复调试直到模型给出满意的结果。这确实是一种方式，但它是不可复制的、不可维护的、不可扩展的。今天要学的是一种更工程化的方式——用结构化的方法设计 Prompt，让 Prompt 变成可管理、可测试、可迭代的资产。

更重要的是，今天要引入”Prompt Contract”这个概念。它是一种思维方式，把 Prompt 看作你与大模型之间的一份契约——你承诺提供什么信息，模型承诺输出什么格式。这种契约思维是从”用 AI”走向”开发 AI 应用”的关键转变。

完成今天的学习后，你应该能写出结构化的企业级 Prompt，能说明 Prompt 的能力边界，能区分普通 Prompt 和企业级 Prompt 的本质差异。

核心概念

一、Prompt 的作用

Prompt 是你与大模型沟通的桥梁。它的作用是把你的意图翻译成模型能理解的形式，同时引导模型产生符合你期望的输出。

从信息论的角度看，Prompt 是一个信号，它的质量决定了模型输出的质量上限。给模型一个模糊的 Prompt，你得到的可能是模糊的回答。给模型一个精确的 Prompt，你得到的可能是一个精确的回答。当然，这只是上限——模型的能力水平决定了实际输出能否达到这个上限。

Prompt 的作用可以拆解为几个层面：

意图传达——告诉模型你想做什么。是分析、总结、翻译、生成、还是比较？模型需要首先理解你的意图，才能选择合适的策略。

上下文提供——给模型补充必要的背景信息。模型不知道你是谁、你的业务是什么、你的受众是谁。这些信息需要通过 Prompt 提供。

格式约束——告诉模型你想要什么格式的输出。是段落、列表、表格、还是 JSON？格式约束让输出能被后续流程使用。

质量标准——告诉模型什么样的输出算”好”。准确、简洁、专业、还是通俗易懂？不同的质量标准会影响输出的风格和深度。

边界划定——告诉模型什么不要做。不要编造数据、不要使用口语、不要超过 500 字。边界划定能减少模型的不可控行为。

二、Prompt 的局限

在深入了解 Prompt 的能力之前，先搞清楚它做不到什么。

Prompt 不能改变模型的能力边界。如果一个模型没有学过半导体物理，你写再好的 Prompt 也无法让它做出专业的半导体分析。Prompt 是放大器，不是创造器。它能把模型已有的能力更好地发挥出来，但不能凭空创造新能力。

Prompt 不能保证 100% 的输出稳定性。即使你把 Temperature 设为 0，由于并行计算中浮点数精度的微小差异，不同调用之间仍然可能有细微差别。在大多数场景下这无所谓，但在需要完全确定性输出的场景下，Prompt 本身是不够的。

Prompt 不能替代外部知识。模型只能基于训练数据中的知识来回答问题。如果你的 Prompt 要求模型回答它不知道的信息，它要么老老实实说不知道，要么编造一个答案。对于后者，写更好的 Prompt 并不能解决问题——你需要 RAG。

Prompt 不能替代工程系统。Prompt 是文本，它不能查数据库、不能调 API、不能发邮件。这些能力需要通过 Tool Calling 等机制来实现，Prompt 只能告诉模型”什么时候该用什么工具”。

Prompt 不能自我验证。模型无法判断自己输出的内容是否正确。即使你在 Prompt 里写了”确保所有信息准确无误”，模型仍然可能输出错误信息——因为它不知道自己不知道什么。

理解这些局限不是要贬低 Prompt 的价值，而是要在正确的范围内使用它。Prompt 是 AI 应用开发中的重要工具，但不是唯一的工具。

三、System Prompt 与 User Prompt

在大模型的 API 调用中，消息通常分为两种角色：System 和 User。

System Prompt 是系统级别的指令，它定义了模型的角色、行为规范和输出要求。System Prompt 在整个对话过程中保持不变（除非你主动修改），它像是给模型的一份”工作手册”。所有在这个对话中的交互都会受到 System Prompt 的约束。

System Prompt 的典型内容包括：角色定义（你是一个专业的行业分析师）、能力范围（你擅长行业分析、岗位拆解、流程优化）、行为规范（基于事实分析，不编造数据）、输出格式（使用 Markdown 格式，包含摘要和详细分析）。

User Prompt 是用户级别的输入，它包含了具体的任务或问题。User Prompt 在每次对话中可以不同，它像是给模型的一个”具体任务单”。

User Prompt 的典型内容包括：具体任务（分析半导体行业的 AI 提效机会）、输入数据（以下是某半导体企业的业务数据…）、补充要求（重点关注良率分析和工艺优化）。

System Prompt 和 User Prompt 的配合关系可以这样理解：System Prompt 定义了”你是谁、你怎么工作”，User Prompt 定义了”你现在要做什么”。一个好的设计是让 System Prompt 处理通用规则，User Prompt 处理具体任务，两者配合产生高质量输出。

在实际的企业应用中，System Prompt 通常由开发者维护，用户看不到也不需要关心。User Prompt 则可能来自用户的直接输入，也可能由系统根据用户输入和模板自动生成。

四、Role / Task / Context / Constraint 框架

这是设计高质量 Prompt 的四个核心要素。

Role（角色）：告诉模型它应该以什么身份来回答问题。

角色定义会影响输出的风格、深度和视角。同样是分析半导体行业，“你是一个半导体行业资深工程师”和”你是一个投资分析师”会产生完全不同风格的输出。前者更关注技术细节和工艺参数，后者更关注市场规模和投资回报。

好的角色定义应该具体且专业。不要写”你是一个 AI 助手”——这太泛了，等于没定义。要写”你是一个有 10 年经验的半导体行业咨询顾问，擅长为企业设计 AI 提效方案”。

Task（任务）：明确告诉模型要做什么。

任务描述要清晰、具体、可执行。不要写”帮我分析一下”——分析什么？从哪些维度？输出什么格式？要写”分析半导体行业中 AI 可以提效的 5 个核心场景，每个场景包括：场景描述、当前痛点、AI 解决方案、预期效果、实施难度”。

好的任务描述像一份需求文档——它详细到不需要追问就能开始工作。

Context（上下文）：提供模型完成任务所需的背景信息。

上下文信息的多少和质量直接影响输出的质量。常见的上下文包括：业务背景（这家半导体企业主要做功率器件，月产能 10 万片）、目标受众（报告给老板看，需要简洁有力）、已有数据（以下是最近三个月的良率数据）、约束条件（只分析生产环节，不涉及销售）。

一个常见错误是提供的上下文太多或太少。太多会让模型抓不住重点（上下文窗口也是有限的），太少会让模型缺乏足够信息来做出好的输出。合适的上下文应该是”刚好够用”——包含所有必要信息，但排除所有冗余信息。

Constraint（约束）：告诉模型不能做什么或者必须遵守什么规则。

约束是 Prompt 的安全带。没有约束的 Prompt 就像没有护栏的高速公路——模型可能跑得很快，但也可能跑偏。常见的约束包括：格式约束（输出必须是 JSON 格式，包含以下字段）、内容约束（不要编造任何数据，如果信息不足就说”信息不足”）、长度约束（分析不超过 1000 字）、风格约束（使用专业但通俗的语言，避免学术化表达）。

这四个要素不是必须全部包含，但一个完整的企业级 Prompt 通常四者兼备。缺少任何一个都可能导致输出质量下降。

五、Few-shot Prompting（少样本提示）

Few-shot Prompting 是在 Prompt 中提供几个示例，让模型学习你期望的输入-输出模式。

人是通过例子学习的，模型也是。当你给模型展示几个”问题-答案”的例子时，它能从这些例子中推断出你期望的输出模式——格式、风格、深度、逻辑结构。

举个例子，你想让模型分析行业的 AI 机会。与其用大量文字描述你想要什么样的分析，不如直接给它一两个示例：

示例输入：分析制造业质检岗位的 AI 机会 示例输出：岗位名称：质检工程师。核心任务：对产品进行外观和性能检测。高频痛点：人工检测速度慢、漏检率高、疲劳后准确率下降。AI 机会：基于视觉模型的自动缺陷检测系统，预计可将检测速度提升 3 倍，漏检率降低 80%。实施难度：中等，需要采集缺陷样本并训练视觉模型。优先级：高。

模型看到这个示例后，会模仿这种结构和风格来分析其他岗位。这比纯文字描述有效得多。

Few-shot 的几个使用技巧：

示例质量比数量重要。三个高质量的示例比十个低质量的示例效果好。

示例应该覆盖不同的情况。如果只给一种类型的示例，模型可能无法处理其他类型的输入。

示例的格式要和你期望的输出格式完全一致。模型会严格模仿示例的格式。

在复杂任务中，Few-shot 的效果通常优于 Zero-shot（不给示例）。但 Few-shot 会占用更多的 Token 空间，需要权衡。

六、输出格式控制

控制模型的输出格式是 Prompt 工程中非常重要的一部分，尤其当输出需要被程序处理时。

常见的格式控制方式：

指定文本格式——要求模型用列表、表格、分级标题等结构化文本格式输出。适用于需要人阅读的场景。

指定数据格式——要求模型输出 JSON、XML 等机器可解析的格式。适用于需要程序处理的场景。

指定模板——给模型一个输出模板，要求它按照模板填充内容。这是最精确的格式控制方式。

格式控制的难点在于：模型不总是能严格遵守格式要求。有时候它会多加一些解释性文字，有时候会遗漏某些字段，有时候会生成格式不正确的 JSON。这就是为什么需要结构化输出机制（明天会深入讲）和格式校验。

七、Prompt Contract 思维

Prompt Contract 是今天最重要的概念。

什么是 Prompt Contract？它是一种思维方式，把 Prompt 看作你与大模型之间的一份契约。这份契约包含：

输入约定（你承诺提供什么）：你会给模型提供哪些信息？格式是什么？范围是什么？输入的信息质量如何保证？

输出约定（模型承诺返回什么）：模型应该返回什么格式的内容？包含哪些字段？每个字段的含义和约束是什么？输出的质量标准是什么？

边界约定（什么情况怎么处理）：当输入不完整时怎么做？当信息不足无法回答时怎么做？当任务超出能力范围时怎么做？当遇到安全风险时怎么做？

为什么需要 Prompt Contract 思维？

因为它把 Prompt 从一段”随意的文字”变成了一份”可管理的规范”。在企业应用中，一个 Prompt 不是写完就结束的——它需要被测试、被评估、被迭代、被版本管理。如果你没有一个清晰的 Contract，你根本不知道怎么评估 Prompt 的好坏，更不知道该往哪个方向优化。

举个例子。你写了一个行业分析 Prompt，模型输出了分析结果。你怎么判断这个结果好不好？如果你有 Contract，你可以对照 Contract 来检查：输出包含了约定的所有字段吗？格式符合约定吗？当信息不足时有按照约定标注吗？没有 Contract，你只能凭感觉说”看起来不错”或”好像不太行”。

Prompt Contract 思维的另一个价值是它让 Prompt 变成了团队协作的基础。如果多个开发者都在维护同一套 Prompt，没有 Contract 就会出现不一致。有了 Contract，每个人都知道这个 Prompt 的输入是什么、输出是什么、边界是什么，协作效率会高得多。

八、企业级 Prompt 的结构

一个企业级 Prompt 不是一段文字，而是一个有结构的文档。它通常包含以下几个部分：

元数据——Prompt 的 ID、名称、版本号、创建者、最后更新日期、用途描述。这些信息用于管理和追踪 Prompt。

输入定义——这个 Prompt 接受哪些输入参数？每个参数的类型、格式、取值范围是什么？哪些是必填的，哪些是选填的？

System Prompt 模板——包含角色定义、行为规范、输出格式要求等固定内容，其中可以嵌入变量（比如行业名称、公司名称等），在运行时动态替换。

Few-shot 示例——提供 2-3 个高质量的输入输出示例，帮助模型理解期望的模式。

质量标准——怎么判断这个 Prompt 的输出质量？有哪些评估维度？每个维度的合格标准是什么？

边界处理——遇到异常输入怎么处理？信息不足时怎么输出？任务超出范围时怎么回复？

测试用例——一组用于验证 Prompt 效果的输入输出对，每次修改 Prompt 后都要跑一遍测试用例，确保没有退化。

变更记录——每次修改了什么、为什么修改、修改前后的效果对比。

这种结构化的 Prompt 管理方式，把 Prompt 从”一段文字”升级成了”一个可管理的组件”。在企业应用中，你可能需要维护几十个甚至上百个 Prompt，没有这种结构化管理，Prompt 就会变成一团乱麻。

九、Prompt 版本管理意识

Prompt 是需要迭代的。你写了第一版，测试后发现效果不理想，修改出第二版，再测试，再修改，直到满意。这个过程和软件开发的迭代过程一模一样。

但很多团队不重视 Prompt 的版本管理，随意修改 Prompt 而不记录变更历史。这就导致几个问题：

无法回滚。新版本 Prompt 效果更差了，你想回到旧版本，但旧版本的内容已经找不到了。

无法评估。你不知道这次修改到底改了什么，无法评估修改的效果。

无法协作。其他团队成员不知道 Prompt 被修改了，可能会基于旧版本做开发。

无法复现。用户报告了一个问题，但你无法复现当时的 Prompt 版本，无法诊断问题。

版本管理的基本实践：

给每个 Prompt 一个唯一 ID 和版本号。每次修改都更新版本号。

记录每次修改的内容、原因、修改人。

保留旧版本的完整内容。

每次修改后跑一遍测试用例，记录结果。

建立一个 Prompt 库，集中管理所有 Prompt 的版本。

概念关系图

Prompt 工程体系

+------------------------------------------------------------+
|                    Prompt Contract                          |
|                                                            |
|  输入约定              输出约定              边界约定        |
|  +-----------+        +-----------+        +-----------+   |
|  | 提供什么   |        | 返回什么   |        | 异常怎么  |   |
|  | 参数格式   |  <--->  | 输出格式   |  <--->  | 处理      |   |
|  | 质量保证   |        | 质量标准   |        | 安全边界  |   |
|  +-----------+        +-----------+        +-----------+   |
|                                                            |
+------------------------------------------------------------+

Prompt 四要素
+-------+  +-------+  +---------+  +------------+
| Role  |  | Task  |  | Context |  | Constraint |
| 角色  |  | 任务  |  | 上下文  |  | 约束       |
+-------+  +-------+  +---------+  +------------+
    |          |          |              |
    v          v          v              v
+----------------------------------------------+
|              完整的 Prompt                    |
|                                              |
|  [System Prompt] + [User Prompt]             |
|  + [Few-shot 示例] + [格式控制]              |
+----------------------------------------------+

企业级 Prompt 结构
+------------------+
| 元数据           |  <- ID, 版本, 用途
+------------------+
| 输入定义         |  <- 参数, 类型, 范围
+------------------+
| Prompt 模板      |  <- System + User + Few-shot
+------------------+
| 质量标准         |  <- 评估维度, 合格线
+------------------+
| 测试用例         |  <- 输入输出对
+------------------+
| 变更记录         |  <- 修改历史, 效果对比
+------------------+

实战分析

设计 Prompt Contract 模板

模板应该是一个标准化的文档结构，包含以下部分：Contract 名称和版本、输入约定（参数名、类型、是否必填、格式要求、示例值）、输出约定（输出格式、字段定义、字段约束、示例输出）、边界约定（信息不足时的处理方式、超出范围时的回复方式、安全风险的处理策略）、质量标准（准确率要求、完整性要求、格式合规率要求）。

这个模板不是写一次就固定的，它应该随着你的实践不断迭代。每次使用后发现新的边界情况，就补充到 Contract 里。

写 10 个企业级 Prompt

这 10 个 Prompt 覆盖了 AI 咨询的核心工作流：行业分析、岗位拆解、流程拆解、机会评分、方案生成、ROI 粗算、风险审查、客户访谈、报告生成、销售话术。

每个 Prompt 的设计思路：

行业分析 Prompt：角色是行业咨询顾问，任务是分析指定行业的结构、价值链、关键痛点，输出是结构化的行业分析报告。关键在于提供足够的上下文（行业名称、关注维度、目标受众），同时约束模型不要编造具体数据。

岗位拆解 Prompt：角色是岗位分析专家，任务是拆解指定岗位的日常任务、高频痛点、AI 机会，输出是岗位分析表。关键在于引导模型从”岗位目标-日常任务-痛点-AI机会”这条线来分析，而不是泛泛地描述岗位。

流程拆解 Prompt：角色是流程优化顾问，任务是拆解指定业务流程的步骤、参与角色、系统依赖、AI 优化点，输出是流程分析表。关键在于要求模型识别每个步骤的输入输出和人工判断点。

AI 机会评分 Prompt：角色是 AI 投资分析师，任务是对给定的 AI 场景做多维度评分，输出是评分表。关键在于定义清晰的评分维度和评分标准，让评分结果可量化、可比较。

解决方案生成 Prompt：角色是 AI 解决方案架构师，任务是根据给定的场景和痛点设计 AI 解决方案，输出是方案文档。关键在于要求方案包含技术架构、实施路径、成本估算、风险评估。

ROI 粗算 Prompt：角色是商业分析师，任务是粗略计算给定 AI 方案的投资回报率，输出是 ROI 分析表。关键在于要求模型明确列出所有假设条件，因为估算结果的可信度取决于假设的合理性。

风险审查 Prompt：角色是风险评估专家，任务是对给定 AI 方案进行全面的风险审查，输出是风险评估报告。关键在于覆盖多个风险维度：技术风险、数据风险、安全风险、合规风险、运营风险。

客户访谈 Prompt：角色是客户成功经理，任务是根据给定的客户信息生成访谈问题清单，输出是结构化的访谈大纲。关键在于问题要有层次：从宏观（业务现状）到微观（具体痛点），从现状到期望。

报告生成 Prompt：角色是商业报告撰写专家，任务是根据给定的分析数据生成可读性强的报告，输出是 Markdown 格式的报告。关键在于指定报告结构、风格（专业但通俗）、受众（老板能看懂）。

销售话术 Prompt：角色是资深销售顾问，任务是根据给定的客户画像和产品信息生成销售沟通话术，输出是分场景的话术脚本。关键在于要求话术关注客户价值而不是技术细节。

每个 Prompt 的设计过程都应该遵循 Role-Task-Context-Constraint 框架，写完后用至少 3 个不同的输入测试，根据测试结果迭代优化。

当日产物说明

《Prompt Contract 模板》

一个标准化的 Prompt Contract 文档模板，包含输入约定、输出约定、边界约定、质量标准四个部分。每个部分有清晰的字段定义和填写说明。质量标准：模板本身结构清晰、字段完整，可以作为团队标准使用。

《企业级 Prompt 模板 10 个》

10 个按照 Role-Task-Context-Constraint 框架设计的企业级 Prompt。每个 Prompt 包含：Prompt ID、用途描述、System Prompt 内容、User Prompt 模板、输入参数定义、输出格式要求、至少一个 Few-shot 示例。质量标准：每个 Prompt 都经过实际测试，输出质量基本满足要求。

《Prompt 评分表》

一份用于评估 Prompt 质量的评分标准，包含以下维度：意图清晰度（Prompt 是否清晰传达了意图？）、格式合规率（模型输出是否遵守了格式要求？）、内容准确性（输出内容是否准确？）、完整性（输出是否包含了所有要求的要素？）、边界处理（Prompt 是否覆盖了异常情况？）。每个维度 1-5 分，附带评分说明。

《Prompt 使用边界说明》

一份说明 Prompt 能做什么和不能做什么的文档。核心内容包括：Prompt 的能力范围、Prompt 的局限、什么情况下需要从 Prompt 升级到 RAG/Agent 等更复杂的架构、如何判断一个任务是否超出了 Prompt 的能力边界。

常见误区与避坑

误区一：Prompt 越长越好

有些人觉得 Prompt 写得越长、越详细，模型输出就越好。实际上，过长的 Prompt 可能导致模型困惑，抓不住重点。好的 Prompt 应该精确而不是冗长。每一句话都应该有明确的目的，没有一句话是多余的。

误区二：一个 Prompt 解决所有问题

有些人想写一个万能 Prompt 来处理所有任务。这在实践中行不通。不同的任务需要不同的 Prompt。行业分析和报告生成的 Prompt 应该分开设计，因为它们的角色、任务、输出格式都不同。正确的做法是为每种任务设计专门的 Prompt，然后通过系统来管理这些 Prompt。

误区三：忽视 Prompt 的测试和维护

写完 Prompt 就不管了，这是一个常见错误。Prompt 需要持续测试和维护。模型的更新可能导致 Prompt 效果变化，新的边界情况需要补充处理逻辑，业务需求的变化可能要求调整 Prompt。Prompt 是活文档，不是写完就结束的。

误区四：把 Prompt 当成系统设计的替代品

有些人觉得只要写好了 Prompt，其他都不重要了。实际上，Prompt 只是系统的一部分。一个好的 Prompt 搭配一个好的系统（RAG、评估、安全），效果远好于一个精心打磨的 Prompt 搭配一个简陋的系统。系统设计应该和 Prompt 设计同步进行。

误区五：在 Prompt 里堆砌约束

有些人喜欢在 Prompt 里写大量的”不要做这个、不要做那个”。过多的否定约束可能让模型过度保守，什么都不敢输出。更好的做法是用正向的方式描述你想要什么，而不是不断强调不想要什么。比如”基于提供的数据进行分析”比”不要编造数据”效果更好。

延伸思考

今天的 Prompt 工程学习为后续内容打下了直接基础。

明天的结构化输出，是在 Prompt 格式控制的基础上，进一步学习如何通过 JSON Schema 等机制来强制控制输出格式。Prompt 里写的”请输出 JSON 格式”是软约束，模型可能不遵守；而 JSON Schema 是硬约束，通过机制来保证输出格式。

后续学习 RAG 时，你会看到 RAG 系统中大量使用 Prompt 来引导模型基于检索到的文档回答问题。RAG 的 Prompt 设计需要特别注意：如何把检索到的文档片段自然地嵌入 Prompt，如何引导模型基于文档内容回答而不是凭记忆回答，如何处理检索结果为空的情况。

学习 Agent 时，Prompt 会变成更复杂的系统指令——Agent 的目标、可用的工具、决策逻辑都通过 Prompt 来定义。Agent 的 Prompt 设计比普通应用 Prompt 难得多，因为你需要在一个 Prompt 里定义 Agent 的完整行为规范。

从个人发展角度看，Prompt 工程是 AI 应用开发的基本功。但不要把它看得太高——它只是众多技能中的一个。一个优秀的 AI 应用开发者需要同时掌握 Prompt 工程、系统架构、数据处理、评估优化、安全管理等多方面能力。Prompt 工程是起点，不是终点。

自测问题

1. Prompt 的作用是什么？它能解决哪些问题？不能解决哪些问题？

2. System Prompt 和 User Prompt 的区别是什么？各自适合放什么内容？

3. Role-Task-Context-Constraint 框架中，每个要素的作用是什么？缺少任何一个会导致什么问题？

4. 什么是 Few-shot Prompting？它和 Zero-shot 的区别是什么？在什么场景下应该用 Few-shot？

5. 什么是 Prompt Contract？它和普通 Prompt 的本质区别是什么？为什么企业应用需要 Contract 思维？

6. 企业级 Prompt 和个人使用的 Prompt 有什么区别？至少说出三个差异。

7. 为什么需要 Prompt 版本管理？不做版本管理会出现什么问题？

8. 如果一个 Prompt 的输出格式经常不符合要求，你会从哪些方面排查问题？

9. 在设计行业分析 Prompt 时，如何避免模型编造具体数据？

10. Prompt 工程在 AI 应用开发中扮演什么角色？它的重要性被高估了还是低估了？为什么？

关键词

• Prompt：用户输入给大模型的指令文本，是与模型沟通的核心方式
• System Prompt：系统级别的固定指令，定义模型的角色和行为规范
• User Prompt：用户级别的具体任务输入
• Role（角色）：Prompt 中定义模型身份的要素，影响输出风格和视角
• Task（任务）：Prompt 中明确告知模型要做什么的要素
• Context（上下文）：Prompt 中提供的背景信息，帮助模型做出更好的输出
• Constraint（约束）：Prompt 中定义的规则和限制，控制输出的边界
• Few-shot Prompting：通过提供示例来引导模型学习输入输出模式的技术
• Prompt Contract：把 Prompt 当作契约来设计管理的思维方式
• 格式控制：通过 Prompt 约束模型输出格式的方法
• 版本管理：对 Prompt 的修改历史进行追踪和管理的实践
• Zero-shot：不提供示例，仅通过指令让模型完成任务的方式