Prompt 工程

Prompt 工程不是玄学：我的结构化提示词方法

从角色、目标、上下文、约束、输出格式和评估标准六个部分整理 Prompt 设计方法。

发布：2026/06/29更新：2026/06/30

背景

Prompt 很容易被写成一句临时指令，但在真实应用里，它更像接口协议：需要稳定、可读、可测试，并且能随着业务反馈持续迭代。

临时 Prompt 最大的问题是不可复用。今天换一个输入、明天换一个模型、后天加一个字段，输出就可能发生明显漂移。对于产品功能来说，这种不稳定会直接影响前端展示、后端解析和用户信任。

所以我会把 Prompt 当成一份轻量规格说明：它不仅告诉模型要做什么，也告诉开发者这个能力的输入、输出、边界和评估方式。

方法

我通常把 Prompt 拆成六个部分：

  1. 角色：模型需要以什么身份处理任务。
  2. 目标：最终要完成什么。
  3. 上下文：输入材料、业务背景和已知事实。
  4. 约束：不能做什么，必须遵守什么。
  5. 输出格式：字段、结构、长度和语言。
  6. 评估标准：什么样的结果算好。

示例

一个用于技术文章摘要的 Prompt，不应该只写“帮我总结”。更稳定的版本会说明读者是谁、摘要用途是什么、需要保留哪些技术关键词、输出几条要点，以及不要添加原文没有的信息。

例如摘要任务可以这样拆：

  1. 读者是技术面试官，目标是快速判断文章价值。
  2. 输入是一篇 Markdown 技术笔记，可能包含代码、列表和未完成想法。
  3. 输出必须是 3 条要点，每条不超过 40 字。
  4. 不能编造原文没有的结果、数据和公司信息。
  5. 如果原文信息不足，输出“信息不足”并说明缺什么。

这样的 Prompt 更容易接入程序。后端可以检查输出条数，前端可以稳定渲染，人工审校也更容易判断是否合格。

迭代方式

Prompt 迭代不要只改一句话。每次改动前，我会准备 5 到 10 个代表性输入，包括正常输入、信息不足、格式混乱、超长文本和边界案例。改动后逐条比较输出，记录改善点和退化点。

如果输出需要被程序消费，就必须加结构化约束。简单场景可以要求 Markdown 列表，复杂场景可以要求 JSON，并在后处理阶段做 schema 校验。校验失败时，不应该直接展示给用户，而是进入修复流程或返回明确错误。

风险控制

Prompt 里要明确禁止模型补事实。尤其是求职材料、项目复盘、技术文章这类内容，如果模型为了让文章更完整而编造指标，风险会很高。

另一个风险是过度依赖角色设定。角色可以帮助稳定语气，但真正决定质量的是上下文、约束、样本和评估标准。只写“你是资深专家”并不能替代任务定义。

复盘

Prompt 的改进不应该只凭感觉。每次修改都应配套输入样本和期望输出，至少能回答：这次改动提升了什么，又牺牲了什么。

当 Prompt 被用于真实功能时，它就应该像代码一样被管理：有版本、有说明、有测试样本、有回滚方案。这样才能把 Prompt 从灵感变成工程资产。

Reusable projects

关联可复用项目

本文已经进入以下工程项目；项目页提供固定版本、运行命令和结果工件。

讨论

正在加载评论...