项目中的提示词模板如何构建？

核心回答

提示词模板应从任务目标和验收标准倒推，把稳定规则与每次变化的输入分开。稳定部分写清角色、要完成的任务、依据使用规则、工具边界和输出要求；变量部分注入用户问题、必要的历史、检索证据及业务状态，不能把所有资料都堆进同一段系统指令。

例如旅行 Agent 的模板要知道目的地、日期、预算和出行偏好；缺关键条件先澄清，实时票价通过工具获取，最终给出行程与费用依据。模板、模型和工具描述一起记录版本，用正常、缺输入和失败样例回放，验证改动是否改善任务完成情况。

展开解析

1. 先确定模板要解决什么问题

同样是“旅行助手”，推荐景点、规划路线和实际订票的边界不同。先定义输入、目标输出和成功条件，再决定提示词包含哪些内容。角色描述服务于任务，不需要虚构“二十年经验”来代替具体规则。

可以按职责拆成这些部分，实际项目不必固定成同一套段落：

部分	需要说清楚什么
任务与范围	生成行程建议，还是执行预订；什么时候完成
动态输入	日期、人数、预算、偏好和缺失字段
证据规则	哪些事实必须查工具，哪些资料有时效，冲突如何处理
工具边界	各工具适用条件、参数含义、失败后的处理路径
输出契约	行程、费用估算、依据与待确认事项的字段要求
异常与停止	无票、缺参数、预算冲突、无充分依据时如何结束或澄清

2. 让模板能复用，也能检查

固定指令存成可版本管理的模板，动态数据通过显式变量绑定；模板渲染前检查必填变量、长度和类型，避免占位符遗漏或把空值当真实事实。历史消息保持原角色，检索内容保留来源和时间，不提升为系统规则。

PromptTemplate 适合生成普通文本；需要区分多角色消息时可以用 ChatPromptTemplate。框架只是组织输入，角色名称和优先级仍应遵循所接模型的接口契约。输出接程序时，用可用的结构化输出能力配合 JSON Schema 或业务校验，不能仅凭“请严格输出 JSON”就提交结果。

3. 给一个可以落地的任务骨架

下面是旅行规划模板的示意内容，不是唯一标准，也不包含真实订票授权：

任务：根据用户条件生成可执行的旅行建议。
输入：目的地、日期、人数、预算、兴趣；缺关键条件时先澄清。
事实：票价、开放时间等实时信息需通过可用工具核对；保留来源与时间。
工具：只使用当前提供的工具及其参数契约；失败时说明未确认部分。
约束：不要编造余票或预订成功；行程时间与交通耗时应能衔接。
输出：每日安排、交通建议、费用估算、依据、待确认事项。

工具名称、参数和适用范围由工具定义维护，模板只补任务层面的选择规则，避免两处配置漂移。外部网页或工具结果中的“忽略原要求”等文字是待处理数据；执行预订还要由可信服务校验身份、库存、价格与具体授权。

4. 用回归样例维护，而不是无限追加规则

准备有代表性的正常输入、缺日期、预算冲突、工具超时、证据冲突及注入内容。比较行程是否满足约束、事实是否有依据、缺口是否正确澄清、格式是否可用，同时观察延迟和成本。

一次尽量只改变可辨认的因素，记录模板、模型、工具与数据版本。失败以后先定位是模板含糊、上下文缺失、工具结果错误，还是模型能力不足；只有前两类等确实属于输入组织的问题，才通过模板修改解决。

追问

为什么不是把所有规则写进一个超长 System Prompt？

长提示增加成本，也容易产生冲突和无关上下文。高优先级只保留稳定任务规则，资料和历史按需装配；复杂任务可以分步骤，并在步骤之间保留清晰的状态和验收。

Few-shot 示例怎么选？

示例应展示容易误解的输入、期待输出和边界行为，例如预算不足时如何澄清，而不是放很多同类成功答案。示例不能来自保留测试集，否则评测结果会被调参污染。

对应教程

参考资料