如何建立生产级提示词工程流程

提示词工程在生产环境里不是“写一句更聪明的话”。对正在构建 LLM 应用、Agent 或 AI 工作流的团队来说，它更像一套工程流程：定义输入输出、拆分上下文、建立评测集、记录版本、分析失败案例，并在上线后持续监控。

如果你的提示词只在聊天窗口里测试过，很可能会在真实用户输入、脏数据、模型升级、工具超时、JSON 格式错误和边界问题面前失效。生产级提示词工程的目标是让输出可测试、可追踪、可回滚、可协作。

生产级提示词工程的核心目标

在开始写提示词之前，团队需要先定义什么叫“好”。不要只说“回答准确”或“体验自然”。这些标准太宽泛，无法指导迭代。

更可执行的成功标准包括：

• 输出准确率：例如分类任务准确率达到 92% 以上，摘要任务关键事实覆盖率达到 95% 以上。
• 格式合规率：例如 JSON Schema 校验通过率达到 99.5% 以上。
• 延迟：例如 P95 响应时间小于 3 秒。
• 成本：例如单次请求平均成本低于 0.02 美元。
• 人工审核通过率：例如客服回复初稿的一审通过率达到 85% 以上。
• 回归测试稳定性：例如每次提示词修改后，核心评测集通过率不能下降超过 1%。

这些指标会决定你应该改提示词、换模型、增加工具调用，还是把单个 prompt 拆成多步 workflow。

步骤 1：定义任务、用户输入和成功标准

先把任务写成工程规格，而不是自然语言愿望。

明确任务边界

用下面的问题约束范围：

• 模型要完成什么动作？分类、抽取、生成、改写、审核、路由，还是工具调用？
• 输入来自哪里？用户自由文本、数据库字段、PDF、客服记录、代码 diff，还是多轮对话？
• 输出给谁用？终端用户、内部审核员、下游服务、另一个 Agent，还是数据库？
• 失败时应该怎么处理？拒答、返回错误码、请求补充信息，还是交给人工队列？

例如，你要构建一个“合同风险摘要”功能，不要把任务写成：

不够好：“请分析合同风险。”

更好的任务定义是：

更可执行：“从用户上传的合同文本中识别付款、违约、续约、数据使用和责任限制相关风险。输出 JSON，包含 risk_type、severity、evidence、recommended_action。如果证据不足，返回 insufficient_evidence。”

定义输入字段

把输入字段列清楚，减少提示词里的隐含假设：

• contract_text：合同全文，最多 40,000 tokens。
• company_policy：内部法务规则，可为空。
• jurisdiction：司法辖区，例如 US-CA、UK、EU。
• user_role：销售、法务、采购或管理员。

字段定义越清楚，后面写 JSON Schema、评测集和日志分析越容易。

步骤 2：写基础提示词，并拆分 system、developer 和 user 上下文

生产环境不要把所有内容塞进一个 user message。你应该把稳定规则、产品逻辑和动态输入分开。

推荐拆分方式

• System message：放身份、最高优先级规则、安全边界和输出原则。
• Developer message：放产品规则、字段说明、分类标准、格式要求和错误处理逻辑。
• User message：只放本次请求的动态输入，例如用户问题、文档内容、上下文数据。

示例结构：

System:
You are a contract risk analysis assistant. Follow the output schema exactly.
Do not invent risks that are not supported by the provided contract text.

Developer:
Task: Identify contract risks related to payment, termination, renewal, data usage, and liability.
Severity scale:
- low: minor wording issue
- medium: commercial impact possible
- high: likely legal or financial exposure

If evidence is missing, return insufficient_evidence instead of guessing.

User:
contract_text: {{contract_text}}
jurisdiction: {{jurisdiction}}
company_policy: {{company_policy}}

这种拆分能帮助你在版本管理、代码审查和线上排查时快速定位问题。团队也可以用 PromptLayer 的提示词管理记录每个版本的 message 结构、变量、模型参数和变更说明。

步骤 3：补充 few-shot 示例和约束

Few-shot 示例适合用来解决“规则说得清楚，但模型仍然不稳定”的问题。它尤其适合分类、抽取、风格改写、结构化输出和边界案例处理。

什么时候应该加 few-shot

• 模型经常混淆相近标签，例如 billing_issue 和 refund_request。
• 输出格式经常偏离要求。
• 业务判断有公司内部标准，模型单靠通用知识无法掌握。
• 你需要稳定处理边界案例，例如“用户在抱怨，但没有明确要求退款”。

什么时候不应该先加 few-shot

• 提示词本身还没有定义清楚任务和输出字段。
• 错误主要来自缺少外部数据，例如库存、订单状态、账户权限。
• 模型能力明显不足，例如小模型处理长文档推理时持续失败。
• 示例会显著增加 token 成本和延迟，但收益很小。

few-shot 示例要覆盖真实失败场景，而不是只放理想样本。一个实用做法是从线上日志里抽取 20 到 50 条失败请求，按错误类型分组，每组挑 1 到 3 个代表案例写进提示词或评测集。

步骤 4：设计结构化输出与错误处理

如果 LLM 输出要进入下游系统，你应该优先使用结构化输出。自然语言适合展示给用户，JSON 适合系统处理。

使用 JSON Schema 约束输出

例如合同风险分析可以定义为：

{
  "type": "object",
  "required": ["status", "risks"],
  "properties": {
    "status": {
      "type": "string",
      "enum": ["success", "insufficient_evidence", "error"]
    },
    "risks": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["risk_type", "severity", "evidence", "recommended_action"],
        "properties": {
          "risk_type": {
            "type": "string",
            "enum": ["payment", "termination", "renewal", "data_usage", "liability"]
          },
          "severity": {
            "type": "string",
            "enum": ["low", "medium", "high"]
          },
          "evidence": {
            "type": "string"
          },
          "recommended_action": {
            "type": "string"
          }
        }
      }
    }
  }
}

在 OpenAI、Anthropic 或 Gemini API 中，你可以结合结构化输出、工具调用或服务端 JSON 校验。即使模型声称会返回 JSON，你仍然应该在服务端做校验。

设计错误处理路径

生产系统要明确处理下面几类错误：

• 格式错误：JSON 解析失败、字段缺失、枚举值不合法。
• 业务错误：模型给出没有证据支持的结论。
• 安全错误：用户输入包含 prompt injection 或要求泄露内部规则。
• 工具错误：外部 API 超时、返回空数据、权限不足。
• 低置信度：模型无法判断，需要返回 insufficient_evidence 或进入人工审核。

一个常见策略是设置最多 1 次自动修复重试。第一次模型输出不符合 schema 时，把校验错误传回模型，请它只修复格式。不要无限重试，否则成本和延迟会失控。

步骤 5：用真实样本建立评测集

没有评测集，提示词迭代就是凭感觉。生产级流程需要把真实样本变成可重复运行的测试集。

评测集应该包含什么

• 正常样本：最常见的用户输入，覆盖主要业务路径。
• 边界样本：信息不完整、表达含糊、多意图、超长文本。
• 失败样本：线上出过错的请求。
• 对抗样本：prompt injection、越权请求、诱导泄露规则。
• 回归样本：核心功能不能被后续修改破坏的固定样本。

开始阶段不用追求几千条数据。对很多团队来说，先建立 100 到 300 条高质量样本就能发现大部分明显问题。每条样本至少包含输入、期望输出、评分标准和标签。

选择评测方式

• 精确匹配：适合分类、路由、枚举字段。
• Schema 校验：适合结构化输出。
• 规则评分：适合检查是否包含证据、是否引用原文、是否超过字数。
• LLM-as-judge：适合摘要质量、语气、完整性，但要用固定 rubric。
• 人工标注：适合法务、医疗、金融等高风险场景。

你可以用电子表格、Git 中的 JSONL 文件、标注工具或 PromptLayer 的评测功能管理这些样本。关键是让每次提示词修改都能跑同一批测试，而不是临时挑几个例子手测。

步骤 6：记录版本、运行日志和人工反馈

上线后最常见的问题不是“模型完全不可用”，而是“某个版本在某类输入上悄悄变差”。因此你需要完整记录每次运行。

每次请求建议记录的字段

• prompt 版本号和模板变量。
• 模型名称、温度、max tokens、工具配置。
• 原始输入和最终输出，敏感数据需要脱敏或按权限存储。
• JSON 校验结果和错误信息。
• 延迟、token 用量和成本。
• 用户反馈、审核结果或下游业务结果。

这些日志让你能回答具体问题：某次错误是模型变了、提示词变了、输入变了，还是工具返回了异常数据？如果没有日志，团队只能猜。

PromptLayer 的可观测性功能可以帮助团队追踪请求、查看提示词版本、分析模型输出和收集反馈。你也可以把日志同步到自己的数据仓库，用于离线分析和报表。

步骤 7：根据失败案例迭代，并上线监控

提示词迭代应该从失败分类开始，而不是直接改文字。

常见失败类型

• 指令不清：模型不知道优先级，或者多个规则互相冲突。
• 缺少上下文：模型没有订单状态、产品规则或用户权限。
• 输出约束不足：字段不稳定，格式经常变化。
• 示例不足：边界案例没有覆盖。
• 模型能力不足：任务需要更强推理、更长上下文或更好的工具调用能力。
• 工作流设计不合适：单个 prompt 承担了检索、推理、生成、校验等太多职责。

每次迭代只改一个主要变量，例如提示词版本、模型、温度或工具策略。修改后跑完整回归评测，再和线上指标对比。这样团队才能知道是哪一项改变带来了提升或退化。

关键决策：改提示词、加工具、换模型，还是做 Agent workflow

很多团队会把所有问题都归因于 prompt。实际生产中，提示词只是控制面之一。你需要根据失败原因选择方案。

什么时候继续改提示词

• 模型已经有足够信息，但输出风格、格式或标签选择不稳定。
• 错误来自规则优先级不清。
• 任务可以通过更明确的约束、few-shot 示例或 schema 改善。

什么时候加工具调用

• 模型需要实时数据，例如订单状态、库存、账户余额或权限。
• 模型需要执行动作，例如创建工单、查询数据库、发送邮件。
• 输出必须基于权威系统，而不是模型记忆。

例如客服 Agent 不应该凭空判断用户是否可以退款。它应该调用订单 API 获取付款时间、商品状态和退款政策，再生成回复。

什么时候换模型

• 长上下文任务持续丢失关键信息。
• 复杂推理任务在高质量提示词和评测集下仍然失败。
• 小模型的格式合规率、准确率或安全表现达不到最低要求。
• 你已经优化提示词，但人工审核通过率仍低于业务目标。

换模型前要用同一套评测集比较准确率、延迟和成本。不要只看单条 demo 输出。

什么时候需要 Agent workflow

• 任务需要多步决策，例如检索、计划、工具调用、反思、生成和校验。
• 不同步骤需要不同模型或不同提示词。
• 系统需要根据中间结果选择下一步动作。
• 你需要可观察的执行轨迹，而不是一个黑盒输出。

例如“自动处理企业采购邮件”通常不适合一个 prompt 完成。更稳的流程是：先分类邮件类型，再抽取关键信息，然后查询供应商和订单系统，最后生成回复草稿并进入审核队列。

推荐的生产级工作流模板

下面是一套适合多数 LLM 应用团队的流程：

1. 写任务规格：定义输入、输出、成功标准和失败路径。
2. 创建初版提示词：拆分 system、developer、user message。
3. 设计输出 schema：用 JSON Schema 或工具参数约束下游接口。
4. 准备 100 条真实样本：覆盖正常、边界、失败和对抗输入。
5. 建立 baseline：记录准确率、格式合规率、延迟、成本。
6. 添加 few-shot 或规则：只针对明确失败类型修改。
7. 跑回归评测：比较新旧版本，不让核心样本退化。
8. 灰度上线：先给 5% 到 10% 流量，观察错误率和审核通过率。
9. 监控线上表现：追踪成本、延迟、用户反馈和失败样本。
10. 定期复盘：每周把高频失败案例加入评测集。

团队协作建议

提示词一旦进入生产环境，就不应该只存在某个开发者的本地文件或聊天记录里。你需要像管理代码一样管理提示词。

• 给每个提示词版本写变更说明。
• 用 Git 或提示词平台记录 diff。
• 把评测结果作为合并或发布条件。
• 让产品、工程、运营或审核人员能提交反馈。
• 为高风险任务设置审批流程。

PromptLayer适合把提示词版本、运行日志、评测和团队协作放在同一个工作流中。对 AI 工程团队来说，这比在代码、表格、聊天记录和日志平台之间来回查找更容易维护。

上线前检查清单

• 是否定义了可量化成功标准？
• 是否拆分了 system、developer 和 user 上下文？
• 是否有结构化输出 schema？
• 是否处理了格式错误、工具失败和证据不足？
• 是否建立了至少 100 条真实样本的评测集？
• 是否记录 prompt 版本、模型参数、输入输出、延迟和成本？
• 是否能快速回滚到上一个稳定版本？
• 是否有灰度发布和线上监控？
• 是否把线上失败案例持续加入回归测试？

结语

生产级提示词工程的重点不是写出一次表现很好的 prompt，而是建立一套能持续改进的系统。你需要清晰的任务定义、结构化输出、真实评测集、版本管理、运行日志和上线监控。这样团队才能在模型、需求和用户输入不断变化时保持稳定。

当你的 LLM 应用开始影响真实用户、真实成本或真实业务流程时，提示词就应该进入工程化管理流程。

如果你正在构建生产级 LLM 应用，可以用 PromptLayer 管理提示词版本、追踪运行日志、运行评测并和团队协作。现在可以在 https://dashboard.promptlayer.com/create-account 创建账户，开始把你的提示词工程流程接入生产环境。