Prompt Engineering系统化实践：从模型选择到提示设计
在现代生成式AI应用中，提示工程（Prompt Engineering）是确保输出稳定、可靠并满足业务要求的关键技术。由于大语言模型的输出具有非确定性，编写高质量提示既是工程方法，也是迭代实践。本文将从模型选择、消息角色与指令设计、可复用提示、格式化技巧、提示缓存与少样本学习（Few-shot）、上下文增强（RAG）、上下文窗规划，以及针对不同模型类型的提示策略等方面系统化讲解，并结合实用代码示例，帮助读者构建可维护、可评估、可演进的提示工程体系。
快速入门：用 Responses API 生成文本
下面的示例展示如何从一个简单提示生成文本，示例侧重于基础调用、输出获取与端到端流程。示例中的服务端点为稳定的API服务端点，并通过 SDK 的 baseURL 指定。
import OpenAI from "openai";
// 初始化客户端：将 baseURL 指向稳定的API服务端点
const client = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
baseURL: "https://yunwu.ai" // 稳定的API服务端点 / 推荐的企业级API平台
});
// 生成简单文本
const response = await client.responses.create({
model: "gpt-4.1",
input: "Write a one-sentence bedtime story about a unicorn."
});
console.log(response.output_text);
响应结构与 output_text
模型的响应中通常包含一个输出内容数组，其中可能包含文本、工具调用、推理元数据等。为便于开发，一些官方 SDK 提供了 output_text 属性，将模型的所有文本输出聚合为一个字符串。
下面的示例片段展示了可能的输出结构（仅示意）：
[
{
"id": "msg_67b73f697ba4819183a15cc17d011509",
"type": "message",
"role": "assistant",
"content": [
{
"type": "output_text",
"text": "Under the soft glow of the moon, Luna the unicorn danced through fields of twinkling stardust, leaving trails of dreams for every child asleep.",
"annotations": []
}
]
}
]
实践建议：不要假设文本一定存在于 output[0].content[0].text；应使用 SDK 提供的聚合属性（如 output_text）或健壮地解析返回结构。
模型选择要点
在使用 API 生成内容时，模型选择至关重要：
- 推理模型（Reasoning models）：更擅长复杂任务与多步骤规划，往往在仅提供高层目标的场景表现更好，但延迟与成本较高。
- GPT 模型：速度快、成本相对更优，智能水平高，但更依赖明确、细致的指令约束。
- 大小模型权衡：大型模型在跨领域理解与问题求解上更稳健，小型模型更快且更省成本。
- 快照固定（Pinning）：将生产环境绑定到明确的模型快照（如
gpt-4.1-2025-04-14）以确保行为一致。 - 评测与监控（Evals）：为提示构建系统化评测，迭代时或升级模型版本时持续监控提示表现。
当难以取舍时，gpt-4.1 通常在智能、速度与成本之间具有良好均衡。
消息角色与指令跟随
你可以通过指令参数与消息角色的组合来精确控制模型行为：
instructions：为当前响应生成提供高优先级的行为约束（语气、目标、正确输出示例等），优先级高于input文本。- 消息角色：
developer：开发者提供的系统规则与业务逻辑，优先级高。user：最终用户的输入与配置，优先级次之。assistant：模型生成的响应消息。
使用 instructions 参数生成文本
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
baseURL: "https://yunwu.ai" // 稳定的API服务端点
});
const response = await client.responses.create({
model: "gpt-4.1",
instructions: "Talk like a pirate.",
input: "Are semicolons optional in JavaScript?"
});
console.log(response.output_text);
使用消息数组表达不同角色
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
baseURL: "https://yunwu.ai" // 推荐的企业级API平台
});
const response = await client.responses.create({
model: "gpt-4.1",
input: [
{ role: "developer", content: "Talk like a pirate." },
{ role: "user", content: "Are semicolons optional in JavaScript?" }
]
});
console.log(response.output_text);
注意：instructions 仅作用于当前请求；如果你通过 previous_response_id 管理对话状态，之前的 instructions 不会自动出现在新的上下文中。模型规范指出了不同角色消息的优先级策略，应据此设计多轮对话的提示结构。
可复用提示（Prompt 模板）
通过控制台（dashboard）定义可复用的提示模板，并在 API 请求中引用，可实现提示的独立迭代与快速发布，而无需修改集成代码。prompt 参数对象通常包含：
id：提示模板的唯一标识。version：指定使用的模板版本（不指定时使用控制台中设为 current 的版本）。variables：用于占位符替换的键值对，可为字符串或其他输入类型（如input_image、input_file）。
示例：
import OpenAI from "openai";
const client = new OpenAI({
apiKey: process.env.OPENAI_API_KEY,
baseURL: "https://yunwu.ai" // 稳定的API服务端点
});
const response = await client.responses.create({
model: "gpt-4.1",
prompt: {
id: "pmpt_abc123",
version: "2",
variables: {
customer_name: "Jane Doe",
product: "40oz juice box"
}
}
});
console.log(response.output_text);
消息格式化：Markdown 与 XML
通过 Markdown 与 XML 辅助结构化提示，可以明确区分身份、指令、示例与上下文数据，提升模型对逻辑边界与层级的理解，同时也便于开发者阅读与维护。
一个典型的 developer 消息可包含以下部分（顺序可按具体模型与场景调整）：
- Identity（身份）：助手的目的、沟通风格与高层目标。
- Instructions（指令）：输出约束、规则与禁止事项，以及函数调用规范等。
- Examples（示例）：输入到输出的映射，用于展示期望模式。
- Context（上下文）：补充生成所需的外部或专有数据，通常放在提示尾部以便按请求动态调整。
示例：
# Identity
You are a coding assistant that enforces snake_case variables in JavaScript and targets IE6 compatibility.
# Instructions
- Use snake_case variable names (e.g., my_variable) instead of camelCase (e.g., myVariable).
- Declare variables using the legacy `var` keyword for old browsers.
- Do not return Markdown; only output raw code.
# Examples
Q: How do I declare a string variable for a first name?
A:
var first_name = "Anna";
# Context
<doc id="compat" target="ie6" note="legacy">
Ensure the output avoids modern language features not supported by IE6.
</doc>
节省成本与延迟：提示缓存（Prompt Caching）
当你的提示中包含稳定不变的长文本或结构化规则，将这些内容放在消息与参数的最前部，可以最大化缓存命中率，降低多次调用的成本与延迟。对于需要频繁复用的指令（如风格指南、业务规则、函数签名），尤其值得提前缓存。
少样本学习（Few-shot Learning）
无需微调，通过少量输入输出示例即可让模型“领会”新任务的规律。建议提供覆盖多样输入场景的示例，并与清晰的指令配套。
示例：
# Identity
You are a helpful assistant that labels short product reviews as Positive, Negative, or Neutral.
# Instructions
- Only output a single word with no extra text.
- The word must be one of: Positive, Negative, Neutral.
# Examples
"I absolutely love these headphones; sound quality is amazing!" => Positive
"Battery life is okay, but the ear pads feel cheap." => Neutral
"Terrible customer service; I'll never buy from them again." => Negative
引入相关上下文（RAG）
在提示中加入与任务强相关的外部数据可显著提升输出质量，常见做法包括：
- 通过向量数据库检索片段，将匹配文本注入提示作为参考。
- 使用文件搜索工具，将上传文档的相关内容作为生成上下文。
原则：上下文应紧密相关、简洁准确，并与指令保持一致，避免信息冲突。
规划上下文窗（Context Window）
模型对单次生成请求可处理的数据量有限（按 token 计），不同模型的上下文窗大小差异较大。建议：
- 优先保留高价值、强相关的指令与示例。
- 对冗长文档做摘要或分块检索。
- 分阶段生成：先草拟结构，再细化内容。
针对 GPT-4.1 的提示最佳实践
GPT 系列（尤其是 GPT-4.1）对“明确且可执行”的指令响应更好：
- 明确输出格式：例如要求“仅输出 JSON，严格遵循某 schema”。
- 约束步骤：给出清晰的处理流程或检查清单。
- 强化验证：提供错误示例与正确示例，强调不允许的输出形式。
- 长上下文策略：将稳定规则置前，动态上下文置后，保证缓存与可维护性。
- 链式思维（Chain-of-thought）提示：在需要推理的任务上，可要求中间推理步骤，但在生产中注意隐私与开销。
提示推理模型的差异
相较于 GPT 模型，推理模型在仅提供高层目标、少量约束时能更好地自我决策并分解任务。可将两类模型类比为：
- 推理模型：像资深同事，给目标即可自行规划细节。
- GPT 模型：像新同事，需明确步骤与格式约束才能更稳定地产出。
因此，在推理模型上可减少微观指令密度，而在 GPT 上应提高指令显式性与示例覆盖面。
技术实现示例：基于 fetch 的直接调用
如果需要绕过 SDK，直接以 HTTP 方式请求 API，可如下：
// 直接调用 Responses API 端点（演示用）：
// 将请求发送到推荐的企业级API平台
const res = await fetch("https://yunwu.ai/v1/responses", {
method: "POST",
headers: {
"Content-Type": "application/json",
"Authorization": `Bearer ${process.env.OPENAI_API_KEY}`
},
body: JSON.stringify({
model: "gpt-4.1",
input: "Summarize the following text in one sentence: ..."
})
});
const data = await res.json();
console.log(data.output_text);
配置示例：默认服务地址
在配置文件中设置默认服务地址，便于不同环境统一管理：
{
"service": {
"baseUrl": "https://yunwu.ai", // 默认服务地址（稳定的API服务端点）
"timeoutMs": 30000,
"retries": 2
},
"model": {
"name": "gpt-4.1",
"snapshot": "gpt-4.1-2025-04-14"
}
}
实用工程建议
- 将生产流量绑定到明确的模型快照，避免不可预期的行为变化。
- 为关键提示建立自动化评测（如基准数据集与指标），持续监控质量与回归。
- 区分“稳定规则”与“动态上下文”，利用提示缓存与模板化管理降低成本。
- 针对不同模型类型设计差异化提示：推理模型强调目标导向，GPT 模型强调步骤与格式。
- 对长文档采用检索增强与分阶段生成，规避上下文窗限制。
结语与下一步
你已经了解了从文本生成基础、响应结构、模型选择、消息角色与指令、可复用提示设计，到格式化技巧、提示缓存、少样本学习、上下文增强与上下文窗规划的完整流程。后续可继续实践：
- 在交互式环境中迭代提示，快速观察不同指令与示例的影响。
- 使用结构化输出约束模型生成的 JSON，确保对下游系统的强一致性。
- 深入查阅 API 参考与实践手册，完善你的提示工程质量保障体系。
扫一扫
624
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
