提示词工程：给模型一份角色说明书

系列：ToyAgent 智能体知识库 02/26

一句话核心：同一个模型，换一份系统提示词就换了一种人格——这是成本最低的"能力开发"。

为什么需要

Step01 的 MVP 没有任何预处理，模型输出风格完全随机：有时啰嗦有时简短，有时编造有时拒答。问题不在模型能力，而在它不知道自己该以什么身份、按什么标准回答。系统提示词（system message）就是补上这份说明书的机制——不改模型、不训练、不加代码，只换一段文本就能系统性改变输出质量。相比微调，这是零成本、分钟级生效的"能力开发"手段。

核心机制

与对话 MVP 相比，唯一改动是调用前塞入一条 system 消息：

private static final String SYSTEM_PROMPT = """
        # 角色
        你是技术助理，专注讲清楚 AI Agent 的原理与工程实践。

        # 背景
        读者是正在学习智能体开发的 Java 工程师。

        # 任务与约束
        1. 回答使用简体中文，先给结论再展开。
        2. 若用户要求"用一句话"，必须严格只回答一句话。
        3. 不确定的内容如实说明，禁止编造。
        """;

@Override
public String chat(String input) {
    return model.chat(List.of(
            Message.system(SYSTEM_PROMPT),   // 唯一新增
            Message.user(input)));
}

三层结构：角色 / 背景 / 任务

层	回答的问题	示例
角色	你是谁	某领域的技术助理
背景	在什么语境下工作	读者是 Java 工程师、AI 新手
任务与约束	怎么干、什么不能干	先结论后展开、可拒答

这三层各自解决一类不稳定：角色锚定语气和专业度，背景校准详略与用词，任务约束控制格式与边界行为。缺任何一层，对应的维度就会漂移。

graph TD
    A["用户输入"] --> B["组装消息列表"]
    B --> C["system 三层提示词"]
    C --> C1["角色：锚定语气与专业度"]
    C --> C2["背景：校准详略与用词"]
    C --> C3["任务约束：控制格式与边界"]
    C1 --> D["发给大模型"]
    C2 --> D
    C3 --> D
    B --> D
    D --> E["受约束的输出"]

图示：system 消息在请求发出前拼进上下文，三层各自约束一个漂移维度，同一次模型调用因说明书不同而输出不同。

C.L.E.A.R 原则

Concise 简洁——删掉一切不影响行为的词；
Logical 逻辑——约束之间不能互相矛盾（比如既要求"详尽"又要求"一句话"）；
Explicit 明确——"简短"不如"50 字以内"，可执行性是关键；
Adaptive 适配——提供示例（Few-shot）校准格式；
Robust 鲁棒——声明边界行为（不知道就拒答，而不是硬答）。

举例：约束条款的"执行力"

同一句输入，有无系统提示词的输出对比：

【无系统提示词】
用户：用一句话解释什么是 Agent。
模型：Agent（智能体）是指能够感知环境、做出决策并采取行动以实现特定目标的
智能实体，在人工智能领域，它通常指基于大语言模型构建的、能够自主规划任务、
调用工具并与环境交互的软件系统，广泛应用于……（40 秒内停不下来，还超了一句话）

【有三层系统提示词，约束第 2 条生效】
用户：用一句话解释什么是 Agent。
模型：Agent 是在大模型基础上叠加工具、记忆与循环，能够自主完成目标的程序。

对照场景：给客服系统写提示词时，"任务与约束"层往往最重要——"若用户询问退款，必须先引导提供订单号，禁止直接承诺到账时间"这类条款，比任何角色包装都更能改变系统行为。

// 生产提示词骨架示例（Spring Boot 项目中放在配置/常量里，支持热更新）
String CS_PROMPT = """
        # 角色：电商售后客服
        # 背景：用户可能在生气，语气要稳
        # 任务与约束：
        1. 涉及退款一律先要订单号
        2. 不承诺具体到账时间
        3. 遇到辱骂不回应情绪，只解决诉求
        """;

常见误区

把提示词写成一句"你是个 AI 助手"。缺少角色锚点与约束条件时，输出风格完全随机。提示词工程的本质是用自然语言写一份可执行的规格说明——它要经得起"逐条执行"的检验，而不是一段氛围描述。

面试考点

"提示词工程和上下文工程的区别？"——提示词工程决定模型怎么答（风格、格式、边界）；上下文工程决定模型看见什么（历史、检索结果、工具结果）。看见什么决定它知道什么（见 Step05）。
"为什么系统提示词要放 system 角色而不是拼在 user 消息里？"——语义上它是"对整个会话生效的指令"，多数模型对 system 消息有独立的注意力权重，拼进 user 会被当作普通输入对待，约束力下降。

生产化路径

提示词即配置：三层提示词放配置中心或数据库（参考本项目已有的"系统提示词后台可配、热更新"机制），改提示词不需要发版。
版本化与回归评测：提示词改动要像代码一样有版本，配一组固定问题集做回归对比，防止"改好了 A 场景、弄坏了 B 场景"。
约束条款化：把模糊形容词全部翻译成可验证的条款（"简短"→"50 字以内"、"专业"→"引用具体 API 名"），这是提示词质量跃升最快的一步。