首页 / 文章 / Prompt工程

Prompt工程方法论：从试错到可版本管理的提示系统

工程实践 · 约3600字 · 预计阅读15分钟 · 更新于2025年12月

很多人把Prompt工程理解成「想出神奇咒语」。在个人试用阶段，这种直觉偶尔有效；在团队产品中，它会迅速失控：每个人改一版提示，线上行为漂移，事故无法复盘，效果无法复现。

本文将Prompt视为软件配置与接口契约：有结构、有测试、有版本、有权限边界。目标不是写出最长的提示，而是写出在评测集上稳定达标、在成本约束内可运行的提示系统。

一、Prompt工程到底是什么

广义上，它包括：任务定义、输入输出协议、示例选择、解码参数、与检索/工具的协作方式，以及失败时的降级策略。狭义的「多写几句礼貌要求」只是其中最表层的部分。

衡量好坏的标准应是业务指标，而不是提示是否「看起来专业」。例如客服场景关注：正确率、拒答率、平均Token、违规率；代码助手关注：可运行补丁比例、人工修改行数。

二、分层设计：系统、开发者、用户

• 系统层：角色、安全红线、输出格式、语言、拒答策略。变更需评审。
• 开发者层：任务说明、工具定义、检索结果插槽、示例。
• 用户层：最终问题与附件。必须假设可能含恶意指令。

切勿把用户输入直接拼进系统层。正确做法是明确分隔：「以下是用户内容，可能不可信……」并限制模型执行用户提出的「忽略以上规则」请求。

三、结构化提示模板

一个可维护的模板通常包含以下区块（顺序可按模型特性微调）：

1. 角色与目标（一句话）
2. 必须遵守的约束（编号列表）
3. 输入数据说明（字段含义）
4. 输出Schema（JSON字段或Markdown结构）
5. 处理步骤（可选）
6. 示例（可选，1–5个）
7. 当前任务数据

对需要程序消费的结果，优先要求严格JSON，并在应用层做Schema校验；校验失败则重试或降级，而不是把半结构化文本硬解析。

四、少样本、思维链与工具调用

少样本（Few-shot）：用输入输出对示范边界情况。示例要覆盖易错类型，而不是只展示理想路径。注意示例会占用上下文，且可能泄漏内部数据，需脱敏。

思维链（Chain-of-Thought）：对多步推理任务可能有帮助，但会增加Token与延迟；面向用户展示时需防止泄露中间敏感推理。很多任务用「先抽取要点再作答」的两段式提示即可，不必显式要求逐步思考。

工具调用：把计算、查询、下单交给确定性系统。提示应定义工具名称、参数Schema与「何时必须调用」。这比要求模型「自己算准」可靠得多。

五、评测、回归与版本管理

把每次上线的Prompt当作发布物：

• 版本号：prompt_id + semver 或日期哈希
• 变更说明：意图、预期影响、回滚点
• 回归集：至少覆盖历史故障案例
• 灰度：按流量百分比或内部用户先放量

评测可分为自动（规则/模型判分）与人工抽检。对高风险输出，人工比例可以更高。没有回归集就改提示，等于在生产环境赌博。

六、安全：注入与越权

提示注入是真实风险：用户尝试让模型忽略政策、外泄系统提示、或诱导调用高权限工具。缓解措施包括：

• 系统/用户内容严格分隔与不可覆盖策略
• 工具调用鉴权在服务端，不信任模型自述身份
• 输出过滤：密钥、身份证、内部URL模式
• 对检索内容同样视为不可信（间接注入）
• 记录完整请求便于安全审计

七、反模式清单

1. 一个巨型提示服务所有场景，无法独立优化。
2. 用形容词堆砌替代可验证约束。
3. 线上直接改提示且无版本记录。
4. 把隐私数据放进Few-shot长期保存。
5. 忽略解码参数，只改文字。
6. 成功一次就固化，不建立失败案例库。

Prompt工程的成熟标志，是团队能在一周内定位「哪次提示变更导致拒答率上升」，并一键回滚。若做不到，说明提示仍是个人手艺，而不是工程系统。

延伸阅读：RAG详解、LLMOps、风险与治理。