提示工程文档规范全指南：从0到1构建可落地的提示工程体系

摘要

你是否遇到过这样的场景？

• 团队里的提示“各自为战”：客服用的提示是运营写的，销售用的提示是产品经理编的，结果同一问题出现10种不同回复；
• 迭代时“找不到北”：上个月的提示为什么这么写？没人记得，只能重新推导；
• 测试时“漏洞百出”：上线的提示突然答错边缘问题，回头看测试用例只覆盖了常见场景；
• 协作时“鸡同鸭讲”：技术说“提示要结构化”，业务说“要口语化”，争论半天没结果。

这些问题的根源，不是“提示写得不好”，而是没有一套可落地的提示工程文档规范。

提示工程不是“写几个Prompt”的玄学，而是需要全流程管理的工程化能力——文档就是这套能力的“载体”。它能帮你把零散的提示知识变成可复用的“AI资产”，让团队协作从“拍脑袋”变成“按规则出牌”，让迭代从“盲目试错”变成“有迹可循”。

本文将为你揭开提示工程文档规范的全貌：

• 为什么提示工程文档是团队的“AI大脑”？
• 一份合格的提示文档要包含哪些核心模块？
• 如何从零开始写第一个可落地的提示文档？
• 90%的团队都会踩的文档误区有哪些？
• 用规范文档提升效率的真实案例是什么样的？

1. 认知：为什么提示工程文档是“AI时代的需求文档”？

在软件时代，需求文档是开发的“指南针”；在AI时代，提示工程文档就是AI应用的“需求文档”——它定义了“AI应该做什么、怎么做、不能做什么”。

1.1 什么是提示工程文档？

提示工程文档是记录提示全生命周期（设计→测试→迭代→协作）的结构化文档，核心目标是：

• 沉淀知识：把“个人经验”变成“团队资产”；
• 统一认知：让技术、业务、运营对“AI能力”达成共识；
• 可追溯性：迭代时能快速定位“为什么变”“变了什么”；
• 降低风险：避免因“口口相传”导致的错误。

1.2 没有文档的团队，会踩哪些坑？

我见过很多团队的“提示管理”现状：

• 知识流失：核心提示工程师离职，带走了“为什么这么写”的逻辑，新人只能重新试错；
• 协作内耗：业务团队说“提示要更灵活”，技术团队说“要更结构化”，争论半天没结果——因为没有文档定义“边界”；
• 迭代混乱：上线后发现提示答错了，想回滚到之前的版本，却找不到“旧版本”在哪里；
• 复用率低：同样的“退货问题”，客服、售后、APP都写了不同的提示，重复劳动不说，还容易出错。

1.3 提示工程文档的“价值公式”

一份好的提示文档，能帮你实现：
协作效率×2 + 迭代周期÷2 + 错误率×0.5

比如某电商团队之前修改一个提示需要3天（找旧版本→争论变更点→测试），推行文档规范后，1天就能完成——因为文档里写清楚了“变更原因”“影响范围”“测试用例”。

2. 核心：提示工程文档的5大模块规范

一份合格的提示工程文档，必须覆盖全流程、全角色、全场景。我总结了5大核心模块，覆盖从“设计”到“协作”的所有环节：

模块1：基础元数据——给提示“打标签”

元数据是提示的“身份证”，能帮你快速定位“这个提示是什么、适用于什么场景”。

必填字段：

字段	说明	示例
提示ID	唯一标识（比如“prompt-ec-cs-return-001”，ec=电商，cs=客服，return=退货）	prompt-ec-cs-return-001
版本号	用“主版本.次版本”（比如v1.0→v1.1→v2.0）	v1.0
作者/负责人	文档的创建者和维护者	张三（提示工程师）、李四（电商售后经理）
创建/更新时间	记录文档的生命周期	2024-05-01 创建；2024-05-10 更新
适用场景	明确提示的应用范围（避免“通用提示”）	电商售后客服→用户咨询“退货流程”的场景
关联模型	适用的AI模型（比如GPT-4、Claude 3、通义千问）	通义千问-Plus
状态	草稿/待审批/已发布/已废弃	已发布

注意：ID要“语义化”，比如“prompt-ec-cs-return-001”比“prompt-001”更容易理解——看到ID就知道是“电商客服退货场景的第1个提示”。

模块2：提示设计文档——定义“AI该怎么做”

这是文档的“核心”，要写清楚“提示的目标、输入输出、规则、示例”，让所有人都能看懂“这个提示是做什么的”。

2.1 核心内容：

（1）目标说明：“要解决什么问题？”

用SMART原则写目标，避免模糊表述：

• 错误示例：“帮客服回答退货问题”；
• 正确示例：“帮电商售后客服准确回答用户的‘退货流程’问题，要求回复包含‘退货条件’‘操作步骤’‘预计到账时间’3个要素，语气亲切。”

（2）输入输出定义：“AI需要什么？要产出什么？”

• 输入：明确AI需要的“信息项”（必填/可选），避免“信息缺失导致的错误”；
  示例（电商客服）：

  输入项	类型	说明	是否必填
  用户问题	文本	用户的原始问题	是
  订单状态	枚举	已发货/未发货/已签收	是
  商品类型	枚举	普通商品/预售商品/定制商品	是
  历史对话记录	文本	过去3轮的对话内容	可选

• 输出：明确AI的“输出格式”（结构化/非结构化）、“约束条件”（长度、语气）；
  示例（电商客服）：

  • 输出格式：“回复内容+操作建议”（JSON结构）；
  • 约束条件：
    ① 回复内容不超过200字，用“亲”“您”等敬语；
    ② 操作建议要具体（比如“点击‘我的订单’→‘申请退货’→上传凭证”）；
    ③ 不能提到“客服电话”（避免用户转人工）。

（3）提示模板：“AI的‘指令’是什么？”

提示模板要**“明确、具体、无歧义”**，避免“玄学表述”。

• 错误示例：“请友好回答用户的退货问题”；
• 正确示例：

  你现在是电商售后客服，需要回答用户的退货问题。请遵循以下规则：
  1. 回复必须包含3个要素：退货条件（如“商品未拆吊牌”）、操作步骤（如“点击‘我的订单’→‘申请退货’”）、预计到账时间（如“7个工作日内”）；
  2. 语气要亲切，用“亲”“您”等敬语；
  3. 不超过200字，不要提到客服电话；
  4. 如果用户的问题涉及“非退货场景”（比如换货、退款），请引导用户“请您描述具体需求，我会帮您解答”。
  
  输入信息：
  - 用户问题：{{用户问题}}
  - 订单状态：{{订单状态}}
  - 商品类型：{{商品类型}}
  
  请输出JSON格式的结果：
  {
    "reply": "亲，您的商品已签收，符合7天无理由退货条件~请点击“我的订单”→“申请退货”→上传商品照片，审核通过后预计7个工作日到账哦~",
    "action": "引导用户申请退货"
  }
  

（4）约束条件：“AI不能做什么？”

明确“禁忌”，避免AI“越界”：
示例（电商客服）：

• 不能回答“商品质量问题”（需转人工）；
• 不能承诺“超过公司规定的到账时间”（比如“24小时到账”）；
• 不能使用“不确定”的表述（比如“可能”“大概”）。

（5）示例：“正确的回答是什么样的？”

正例+反例是最有效的“认知统一工具”——业务团队看了示例，立刻明白“AI该怎么说”；技术团队看了示例，能更准确地调整提示。
示例（电商客服）：

• 正例（符合要求）：
  用户问题：“我昨天买的衣服，今天能退吗？”
  订单状态：已签收；商品类型：普通商品；
  AI回复：“亲，您的商品已签收且未超过7天，符合无理由退货条件_{请点击“我的订单”→“申请退货”→上传商品照片，审核通过后预计7个工作日到账哦}”
  操作建议：“引导用户申请退货”。

• 反例（不符合要求）：
  用户问题：“我昨天买的衣服，今天能退吗？”
  AI回复：“可以退，你去申请吧。”（问题：缺少“退货条件”“操作步骤”“预计到账时间”）；
  AI回复：“亲，您的商品可以退，但需要等3天才能到账~”（问题：承诺了“3天到账”，超过公司规定的“7天”）。

模块3：测试与验证文档——确保“AI能做好”

提示不是“写出来就完了”，需要用测试用例验证“是否符合预期”。测试文档要记录“怎么测、测了什么、结果怎么样”。

3.1 核心内容：

（1）测试用例设计：“要测哪些场景？”

测试用例要覆盖3类场景：

• 正向场景：常见的、符合预期的问题；
• 反向场景：不符合规则的问题（比如“超过7天的退货请求”）；
• 边缘场景：少见但可能发生的问题（比如“吊牌拆了能不能退”“预售商品能不能退”）。

示例（电商客服）：

测试用例ID	场景类型	用户问题	预期输出	实际输出	结果（通过/失败）
TC-001	正向	我昨天买的衣服，今天能退吗？	包含“7天无理由”“操作步骤”“7天到账”	符合预期	通过
TC-002	反向	我去年买的衣服，能退吗？	引导“超过7天无法退货”	回复“亲，超过7天无法无理由退货哦~”	通过
TC-003	边缘	我买的预售衣服，能退吗？	说明“预售商品需等待发货后才能退”	回复“亲，预售商品需发货后才能申请退货哦~”	通过
TC-004	边缘	我把吊牌拆了，能退吗？	说明“吊牌拆了无法退货”	回复“亲，吊牌拆了无法无理由退货哦~”	通过

（2）评估指标：“怎么衡量AI做得好不好？”

用可量化的指标评估提示效果，避免“主观判断”：

• 准确性：回答符合“目标说明”的比例（比如“是否包含3个要素”）；
• 一致性：不同次调用的回复是否一致（比如“同一问题，AI会不会给出不同答案”）；
• 合规性：回复是否符合“约束条件”（比如“有没有提到客服电话”）；
• 用户满意度：业务团队/用户对回复的评分（1-5分）。

示例（电商客服）：

• 测试结果：准确性95%、一致性100%、合规性100%、用户满意度4.8分（满分5分）；
• 结论：符合上线标准。

模块4：迭代与优化文档——让提示“越用越好”

AI不是“一成不变”的，提示需要根据“用户反馈、业务变化”迭代。迭代文档要记录“为什么变、变了什么、影响范围”，避免“改乱了”。

4.1 核心内容：

迭代版本	变更时间	变更原因	变更内容	影响范围	审批人
v1.1	2024-05-15	业务反馈“预售商品退货问题增多”	提示中增加“预售商品需发货后才能退货”的规则	电商售后客服→退货场景提示	李四
v1.2	2024-05-20	用户反馈“回复太长”	将回复长度从“200字”缩短到“150字”	所有电商客服提示	王五

注意：迭代时要“小步快跑”——每次只改1个点，避免“改了A影响B”。比如想优化“回复长度”，就只改“约束条件”，不要同时改“输入项”。

模块5：协作与权限文档——让团队“按规则出牌”

提示工程不是“提示工程师一个人的事”，需要业务、技术、运营共同参与。协作文档要明确“谁负责什么、流程是什么”。

5.1 核心内容：

（1）责任分工：“谁做什么？”

角色	职责
提示工程师	编写提示设计文档、测试用例、迭代记录
业务负责人	审核提示的“业务准确性”（比如“退货规则是否符合公司政策”）
测试工程师	执行测试用例、记录测试结果
运营团队	收集用户反馈、提出优化建议

（2）审批流程：“提示要怎么走流程才能上线？”

示例：
草稿→提示工程师自检→业务负责人审核→测试工程师测试→发布→运营团队监控。

（3）版本管理：“怎么管理不同版本的提示？”

• 用语义化版本号（v1.0→v1.1→v2.0），不要用“提示-001-改1”“提示-001-改2”；
• 每个版本都要“归档”，比如用Confluence的“版本历史”功能，或者专门的提示管理工具（如PromptLayer、LangChain）；
• 废弃的版本要“标记”，避免被误用。

3. 实操：从零开始写第一个提示文档（电商客服案例）

说了这么多理论，我们用电商客服退货提示的例子，一步步写一份可落地的文档。

步骤1：填写基础元数据

字段	内容
提示ID	prompt-ec-cs-return-001
版本号	v1.0
作者/负责人	张三（提示工程师）、李四（电商售后经理）
创建时间	2024-05-01
适用场景	电商售后客服→用户咨询“退货流程”的场景
关联模型	通义千问-Plus
状态	已发布

步骤2：写提示设计文档

（1）目标说明：帮电商售后客服准确回答用户的“退货流程”问题，要求回复包含“退货条件”“操作步骤”“预计到账时间”3个要素，语气亲切，不超过200字。
（2）输入输出：

• 输入：用户问题（必填）、订单状态（必填）、商品类型（必填）、历史对话（可选）；
• 输出：JSON格式（reply+action），约束条件如前所述。
  （3）提示模板：如前所述的“电商客服提示模板”。
  （4）约束条件：不能提客服电话、不能承诺超过7天的到账时间、不能回答非退货问题。
  （5）示例：正例（TC-001）、反例（TC-002）。

步骤3：写测试与验证文档

（1）测试用例：覆盖正向（TC-001）、反向（TC-002）、边缘（TC-003、TC-004）；
（2）评估指标：准确性95%、一致性100%、合规性100%、用户满意度4.8分；
（3）结论：符合上线标准。

步骤4：写迭代与优化文档

（暂时无迭代，留空，等后续优化时补充）

步骤5：写协作与权限文档

（1）责任分工：张三（写文档）、李四（审核业务规则）、王五（测试）、赵六（运营监控）；
（2）审批流程：张三→李四→王五→发布；
（3）版本管理：用Confluence的版本历史，每个版本都归档。

4. 避坑：90%的团队都会踩的文档误区

我见过很多团队“写了文档但没用”，问题出在忽略了“落地性”——文档不是“摆样子”，而是要“能用、好用、常用”。

误区1：“文档写得太复杂，没人看”

错误做法：把文档写成“学术论文”，用大量技术术语（比如“链式提示”“思维链”）；
正确做法：用“业务语言”写文档，比如不说“链式提示”，说“一步步引导AI思考”；不说“思维链”，说“让AI给出推理过程”。

误区2：“忽略反例，只写正例”

错误做法：只写“正确的回答”，不写“错误的回答”；
后果：业务团队以为“AI什么都能答”，结果上线后发现AI答错了“边缘问题”；
正确做法：每写1个正例，至少写1个反例——比如“正确的回复是包含3个要素，错误的回复是缺少要素”。

误区3：“测试用例只覆盖常见场景”

错误做法：只测“用户问‘我昨天买的衣服能退吗？’”，没测“用户问‘我把吊牌拆了能退吗？’”；
后果：上线后遇到边缘问题，AI答错，用户投诉；
正确做法：测试用例要覆盖“正向+反向+边缘”，比如电商客服的提示要测“预售商品”“吊牌拆了”“超过7天”等场景。

误区4：“版本管理混乱，改完找不到旧版本”

错误做法：直接在原文档上修改，不保留旧版本；
后果：上线后发现问题，想回滚到旧版本，却找不到；
正确做法：用“语义化版本号”+“归档”，比如v1.0→v1.1→v2.0，每个版本都保存。

误区5：“文档写完就不管了，没有迭代”

错误做法：文档写完上线后，再也不更新；
后果：业务规则变了（比如“预售商品的退货规则改了”），提示还是旧的，导致错误；
正确做法：定期（比如每周）Review文档，根据用户反馈、业务变化迭代，迭代记录要写清楚“为什么变”“变了什么”。

5. 案例：某电商团队用规范文档提升效率40%

去年，我帮某电商团队做提示工程落地，他们的问题是：

• 客服提示由运营团队写，没有文档，经常出现“回复不一致”；
• 迭代时要找运营、技术、客服开会，耗时3天；
• 提示错误率高达15%，用户投诉多。

我给他们做了3件事：

1. 推行提示工程文档规范，要求所有提示都要写文档；
2. 用正例+反例统一业务团队的认知；
3. 用版本管理和审批流程避免“随意修改”。

结果：

• 客服回复准确率从85%提升到95%；
• 迭代周期从3天缩短到1天（因为文档里写清楚了“变更原因”“影响范围”）；
• 协作效率提升40%（不用再开会争论“提示该怎么写”）；
• 用户投诉率下降了60%。

6. 未来：AI如何辅助提示工程文档？

随着AI技术的发展，提示工程文档将从“人工写”变成“AI辅助写”——比如：

• AI生成初始文档：用GPT-4或Claude 3生成提示设计文档的草稿，人工优化；
• AI自动关联知识：写提示时，AI自动关联“公司的退货规则”“历史的提示案例”；
• AI监控文档效果：运营团队收集用户反馈后，AI自动分析“哪些提示需要优化”，并给出建议；
• AI可视化编辑：用低代码平台（比如LangChain的Prompt Builder）可视化编辑提示文档，减少手动输入。

7. 结论：提示工程文档是“AI资产的地基”

提示工程不是“写几个Prompt”的玄学，而是需要工程化管理的能力——文档就是这套能力的“地基”。

一份好的提示文档，能帮你：

• 把“个人经验”变成“团队资产”；
• 让协作从“争论”变成“按规则出牌”；
• 让迭代从“盲目试错”变成“有迹可循”；
• 让AI应用从“不稳定”变成“可依赖”。

行动号召：立刻开始整理你的提示文档！

现在，打开你的笔记本，做3件事：

1. 列出你团队里的“核心提示”（比如客服、销售、运营用的提示）；
2. 给每个提示补全“基础元数据”“提示设计文档”“测试用例”；
3. 找业务团队一起Review文档，确认“业务规则是否正确”。

如果有问题，欢迎在评论区留言——我会帮你解答！

附加部分

参考文献

1. OpenAI《Prompt Engineering Guide》：https://platform.openai.com/docs/guides/prompt-engineering
2. 微软《Azure OpenAI Prompt Best Practices》：https://learn.microsoft.com/en-us/azure/ai-services/openai/prompt-best-practices
3. 亚马逊《Bedrock Prompt Design Guidelines》：https://docs.aws.amazon.com/bedrock/latest/userguide/prompt-design.html

致谢

感谢我的团队成员（张三、李四、王五），他们在提示工程落地过程中提供了大量反馈；感谢某电商团队的合作，让我有机会验证规范的效果。

作者简介

我是陈默，资深提示工程架构师，有5年AI产品经验，专注于提示工程落地。曾帮多个电商、金融团队搭建提示工程体系，提升AI应用效率40%以上。欢迎关注我的公众号“AI工程化”，获取更多提示工程干货。

结语：AI时代，“提示工程文档”不是“可选项”，而是“必选项”——它能帮你把“AI的能力”变成“可管理、可复用、可优化”的资产。从今天开始，写一份属于你团队的提示文档吧！