提示词工程实践指南（Prompt Engineering）

提示词工程是为大语言模型设计输入接口的工程方法。它把人的目标、业务上下文和输出要求转换成模型可以稳定执行的指令，并通过测试持续验证效果。

一条能工作的提示词通常包含任务、上下文、约束、示例和输出格式。生产环境还会加入版本管理、评估数据集、失败处理与安全边界。这些部分共同决定模型能否在不同输入上持续交付合格结果。

什么是提示词工程

大语言模型接收一段上下文，并预测接下来最合适的内容。提示词工程负责组织这段上下文，让模型获得完成任务所需的信息。

从软件工程角度看，提示词很像一个函数接口：

prompt-as-interface.ts

type InstructionInput = {
  instruction: string;
  context: string;
  constraints: string[];
  examples?: Array<{ input: string; output: string }>;
  outputSchema: object;
};

type ModelOutput = {
  result: unknown;
  evidence?: string[];
  confidence?: number;
};

instruction 定义任务，context 提供知识，constraints 约束行为，examples 展示模式，outputSchema 固定模型与下游程序之间的数据契约。

提示词工程的工作范围通常包括四部分：

设计：把模糊需求转换成明确指令。
编排：拆分复杂任务，安排模型、检索和工具之间的调用顺序。
评估：用代表性样本测量准确率、格式合规率和稳定性。
维护：记录提示词、模型和参数版本，持续执行回归测试。

为什么需要提示词工程

自然语言经常省略前提。人类可以依赖共同经验补齐含义，模型只能依据当前上下文推断。相同的“帮我分析一下”可能表示寻找根因、提取摘要、比较方案，也可能表示生成行动计划。

大语言模型还具有概率性。模型、采样参数或输入内容发生变化时，结果也会变化。提示词工程通过明确目标、收紧搜索空间和定义验收标准，让这种变化保持在可接受范围内。

它主要处理三个工程矛盾：

工程问题	提示词中的处理方式
人的目标含有隐含条件	写清任务、读者、用途和成功标准
模型掌握的信息存在边界	提供上下文、检索结果、时间范围和来源
生成结果存在随机性	固定格式、增加示例、执行评估和回归测试

因此，提示词的质量体现为可执行性和可验证性。语言可以很朴素，关键字段需要完整。

提示词工程解决什么问题

对齐任务目标

“总结这份事故报告”缺少结果用途。值班工程师需要时间线和缓解措施，管理层需要影响范围和风险，开发团队需要根因和修复计划。明确读者与用途后，模型才能选择信息密度和表达结构。

注入模型需要的上下文

企业内部文档、实时数据库和当前页面需要通过上下文或工具显式提供给模型。提示词可以直接携带这些材料，也可以接收检索系统返回的内容。模型获得事实边界后，回答可以引用输入中的证据。

固定输出契约

当结果需要进入程序，输出格式属于接口协议。JSON Schema、枚举值和必填字段可以减少解析失败，并让字段级验证成为可能。

incident-output.schema.json

{
  "type": "object",
  "required": ["severity", "summary", "evidence", "actions"],
  "properties": {
    "severity": { "enum": ["SEV-1", "SEV-2", "SEV-3"] },
    "summary": { "type": "string" },
    "evidence": {
      "type": "array",
      "items": { "type": "string" }
    },
    "actions": {
      "type": "array",
      "items": { "type": "string" }
    }
  }
}

拆分复杂任务

复杂任务适合分成多个可检查阶段。例如技术选型可以拆成需求提取、候选筛选、证据核对、风险分析和结论生成。每个阶段都有清晰输入与输出，失败时也能定位具体环节。

建立可重复的质量标准

提示词、模型版本、参数和评估集一起构成可复现实验。上线应用最好钉住具体的模型快照。团队可以比较两个版本的准确率、延迟、成本和格式合规率，再决定采用哪个版本。

谁会在什么场景使用它

个人用户可以用提示词提高一次对话的质量。开发团队面对重复任务、程序化调用和多人协作时，会进一步采用模板、版本控制和自动评估。

使用者	常见场景	关注重点
开发者	代码生成、测试、日志分析、Agent 工具调用	输出格式、权限边界、回归测试
数据团队	信息抽取、分类、实体识别、报告生成	准确率、Schema 合规率、批处理成本
研究与运营团队	资料综合、市场分析、内部知识问答	来源、时效、事实一致性
内容与产品团队	技术文章、产品说明、客服回复	读者、语气、品牌规则

当任务会重复执行、结果需要进入下游程序、错误具有业务成本，提示词就需要按工程接口管理。一次性探索可以从简短指令开始，再根据失败结果逐步增加上下文和约束。

怎样设计提示词

先定义结果

先写交付物和成功标准，再补充角色与背景。一个有效的任务描述应该回答：模型需要产出什么，这份结果交给谁，结果将支持什么决定。

task.md

分析订单接口延迟升高的最可能原因。

结果交给值班开发，用于决定是否回滚最近一次服务部署。
输出事件时间线、三个按证据强度排序的根因假设，以及每个假设的验证方法。

提供必要上下文

上下文包括事实、术语、环境、时间范围和来源。长材料适合放在明确的分隔符中，使指令与数据保持清晰边界。材料几乎不变、查询在变时，可以把长文放在指令前面；每次检索结果都不同时，可变上下文靠近末尾更省事。

context.md

## 环境
- 服务：orders-api v3.18.0
- 区域：ap-southeast-1
- 数据库：MySQL 8.0
- 时间范围：2023-12-14 09:00 至 11:00

## 观测数据
<metrics>
{{METRICS}}
</metrics>

## 部署记录
<deployments>
{{DEPLOYMENT_LOG}}
</deployments>

写清约束

约束用于限定证据来源、时间范围、工具权限和回答边界。约束应当可以检查。

constraints.md

- 每个根因假设至少引用一条输入证据。
- 将推测标记为“待验证”。
- 仅使用 <metrics> 与 <deployments> 中的信息。
- 缺失数据放入 missing_information 数组。

“准确分析”属于主观要求；“每个结论引用证据”可以执行自动检查或人工审核。与其写「不要臆测」，不如写「材料不够就写入 missing_information」。

用示例展示模式

当任务包含特殊分类、固定文风或边界案例时，示例可以直接展示期望映射。示例需要覆盖正常输入和容易混淆的输入，彼此也要有差异，避免模型只学会复读同一种格式。

few-shot.md

输入：CPU 稳定，数据库连接池使用率在部署后从 42% 升至 97%。
输出：
{
  "hypothesis": "数据库连接池耗尽",
  "evidence": ["部署后连接池使用率从 42% 升至 97%"],
  "status": "needs_verification"
}

定义输出格式与自检

结构化输出适合机器消费，Markdown 适合人工阅读。自检步骤用于检查字段、证据和约束是否完整。

output-contract.md

返回 JSON，字段遵循给定 Schema。

提交前检查：
1. required 字段全部存在。
2. 每个 hypothesis 都有 evidence。
3. 输入未提供的信息进入 missing_information。
4. severity 只使用 Schema 中的枚举值。

一个完整示例

incident-analysis.prompt.md

## Role
你是负责 Java 微服务和 MySQL 性能分析的 SRE。

## Objective
判断 orders-api 延迟升高是否与 09:42 的服务部署有关，并给出回滚建议。

## Context
<metrics>
{{METRICS}}
</metrics>

<deployments>
{{DEPLOYMENT_LOG}}
</deployments>

## Rules
- 建立按分钟排列的事件时间线。
- 每个结论引用对应证据。
- 将推测标记为 needs_verification。
- 将缺失数据写入 missing_information。

## Output
返回符合 incident-output.schema.json 的 JSON。

## Sense Check
提交前检查字段完整性、时间顺序和证据引用。

这个模板已经包含角色、目标、上下文、规则、输出契约与质量检查。多数技术任务都可以从这六个字段开始。

常用提示词框架与结构

提示词框架是帮助记忆字段的模板。本章保留四种覆盖面较广的结构：RTF 用于简单任务，STAR 用于组织分析过程，CO-STAR 用于内容沟通，RODES 用于复杂技术任务和质量检查。

RTF：处理简单任务

RTF 由 Role、Task、Format 组成，适合摘要、改写、分类和格式转换等短任务。

rtf.prompt.md

Role：你是 TypeScript 测试工程师。
Task：为下面的 parseDuration 函数生成单元测试，覆盖正常值、边界值和非法输入。
Format：输出 Vitest 代码，并为每组测试添加一句测试意图说明。

RTF 结构短，维护成本低。涉及私有知识、复杂步骤或严格质量要求时，可以增加 Context、Examples 和 Check 字段。

STAR：组织分析过程

STAR 由 Situation、Task、Action、Result 组成。它源于结构化案例表达，也常用于事故复盘、问题分析和方案推演类提示词。

star.prompt.md

Situation：服务变更后，订单接口 P95 延迟从 180ms 升至 1.4s。
Task：判断这次变更与延迟变化之间的关系。
Action：对齐部署、流量、GC、连接池和慢查询的时间线，按证据强度验证假设。
Result：输出根因、证据、即时缓解措施和长期修复计划。

STAR 可以保留从背景到行动再到结果的因果链，适合需要解释分析依据的技术任务。

CO-STAR：控制沟通效果

CO-STAR 由 Context、Objective、Style、Tone、Audience、Response 组成。该框架在新加坡 2023 年 GPT-4 提示词工程竞赛中得到系统展示，适合技术文章、产品说明和面向特定读者的沟通任务。

co-star.prompt.md

Context：读者了解 REST API，正在第一次接触事件驱动架构。
Objective：解释订单系统从同步调用迁移到事件驱动架构的收益与风险。
Style：技术博客，使用架构示例和故障场景。
Tone：克制、清晰、基于证据。
Audience：具有两年经验的后端工程师。
Response：1200 字，包含架构流程、迁移步骤、风险表和检查清单。

Style、Tone 与 Audience 让同一份技术内容适配不同沟通对象。

RODES：增加示例与质量检查

RODES 由 Role、Objective、Details、Examples、Sense Check 组成，适合代码审查、技术研究和需要提交前检查的任务。

rodes.prompt.md

Role：你是 Node.js 平台架构师。
Objective：评估三个任务队列库并推荐一个生产方案。
Details：比较吞吐量、重试、幂等、可观测性、维护状态和迁移成本。
Examples：结论采用“选择 / 证据 / 风险 / 验证方式”的结构。
Sense Check：检查每个结论是否有来源，版本和基准环境是否明确。

RODES 将示例和最终检查直接放进结构，适合对输出一致性要求较高的技术任务。

怎样选择框架

先明确任务目标、输入材料、主要风险和输出用途，再选择能够覆盖这些信息的最小结构。

场景	推荐框架或结构	选择理由
一次性短任务	RTF	字段少，编写和维护成本低
事故复盘、案例分析	STAR	建立背景、行动和结果之间的因果关系
面向特定读者写作	CO-STAR	控制风格、语气、读者和响应结构
研究、审查、技术选型	RODES	包含示例和提交前质量检查

这些结构也可以组合使用。例如用 STAR 整理事故因果链，再用 RODES 补充详细约束、参考示例和最终检查。

框架选定后，建议继续检查三个问题：

主要失败风险来自知识缺口、执行步骤还是输出格式？
哪些字段可以通过程序验证？
哪些输入能够加入评估集进行回归测试？

怎样评估提示词

提示词评估需要固定模型、参数、提示词版本和测试数据。改提示或换模型快照之前，先固定评估集。一次成功输出只能说明该样本通过，评估集才能反映整体质量。

建立评估集

评估集应覆盖真实流量中的主要类型：

正常输入，验证核心任务完成度。
边界输入，验证空值、长文本和极端数值。
模糊输入，验证模型能否标记待确认信息。
对抗输入，验证外部材料中的指令是否会干扰系统规则。
历史失败样本，防止已经修复的问题再次出现。

每个样本至少包含输入、期望特征和评分规则。分类任务可以保存标准答案，开放式任务可以保存评分量表。

选择指标

维度	指标示例
任务质量	准确率、召回率、事实一致性、人工评分
格式质量	Schema 通过率、必填字段完整率、解析成功率
稳定性	多次运行一致率、版本回归通过率
性能	P50/P95 延迟、输入与输出 Token 数
成本	单次调用成本、完成一个合格结果的平均成本
安全	越权率、提示注入成功率、敏感信息泄漏率

结构化任务优先使用确定性检查，开放式任务可以结合规则、模型评分和人工抽检。模型评分器需要单独验证，并保留部分人工标注作为校准集。

做版本对比

每次实验只改变一个主要变量，例如提示词文案、示例集合、模型版本或采样参数。

prompt-experiment.yaml

experiment: incident-analysis-v4
baseline_prompt: v3.2.0
candidate_prompt: v4.0.0
model: model-version-id
temperature: 0
dataset: incident-eval-2023-12
metrics:
  - schema_pass_rate
  - evidence_coverage
  - root_cause_accuracy
  - p95_latency_ms
  - average_cost

候选版本需要在质量、安全、延迟和成本上达到预设的通过标准。遇到新的失败样本时，应把它加入评估集。

设置通过标准

一个技术分析提示词可以采用下面的通过标准：

Schema 通过率       >= 99.5%
证据引用完整率      >= 95%
根因分类准确率      >= 90%
提示注入拦截率      >= 99%
P95 延迟            <= 4s
单次平均成本        <= $0.02

具体数值应根据业务风险和基线结果设定。高风险场景还需要权限控制、人工审批、审计日志和确定性校验。

实践检查清单

提示词工程的核心成果是一套可维护的模型接口：需求明确，输入有边界，输出有契约，质量有数据。

参考资料

Brown et al., Language Models are Few-Shot Learners, 2020.
Ouyang et al., Training language models to follow instructions with human feedback, 2022.
Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, 2022.
Kojima et al., Large Language Models are Zero-Shot Reasoners, 2022.
Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022.
White et al., A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT, 2023.
Schulhoff et al., The Prompt Report: A Systematic Survey of Prompt Engineering Techniques, 2024.
Sheila Teo, How I Won Singapore’s GPT-4 Prompt Engineering Competition, 2023.
Twisted Brackets, Riding the Wave of Effective AI Prompt Crafting, 2023.
OpenAI, Prompt engineering.
Anthropic, Prompt engineering overview.
Anthropic, Prompting best practices.