撰写一份可交付的提示词文档，关键在于让接手的人无需反复提问就能直接使用、轻松修改、快速查证。这并非简单的文字堆砌，而是构建一套可执行、可复用的知识结构。

明确交付对象和使用场景

第一步：这份文档究竟面向谁？是给开发同事对接API，给运营同事每天复制粘贴，还是给客户自行填空调用？不同角色的信息粒度截然不同——写给开发看的，必须附带参数说明和错误码；写给运营看的，需要有示例截图和替换标记；写给客户看的，则必须提供清晰的填空指引。

第二步：先写下三个真实会发生的使用瞬间。例如这样的场景：客服小王在下午3点收到新客咨询，打开文档复制第2节模板，把“{客户姓名}”替换成张伟，发送前检查是否遗漏了“优惠截止时间”字段。这种具体的画面，能立刻帮你筛掉那些冗余的描述性内容。

结构按“动线”而非“逻辑”组织

方法一：从触发动作开始排布（推荐给一线使用者）。动线应为：打开文档 → 找到对应业务类型（如“生成商品详情页”） → 核对输入要求（需提供SKU、卖点列表、目标人群） → 复制基础模板 → 粘贴到编辑器 → 替换花括号内占位符 → 检查输出长度是否超限 → 点击发送。每一步都清晰可见，使用者无需自行揣摩下一步。

方法二：按调试流程分层（适合技术对接场景）。① 原始提示词（未优化版，附带注释说明每行作用）；② 约束条件清单（如“禁用emoji”“必须含且仅含1个问句”“数字统一用阿拉伯数字”）；③ 典型失败案例与修复对比（左栏是AI跑偏的输出，右栏标红修改点）。这种结构，技术同事看完就能直接上手修改。

占位符和变量必须带类型与示例

所有花括号里的{xxx}都必须标注类型。例如{产品名称}【字符串，≤15字，不可含促销符号】；{折扣率}【数字，0.7–0.95之间，保留两位小数】。这一步如果漏写类型，下游使用者一定会填错——有人把“{截止日期}”理解成“2024-06-30”，有人写成“6月30号”，还有人填“下周三”。文档里没有定义格式，就是在埋下隐患。

附上可验证的测试用例

方法一：最小闭环测试集。输入“{品牌}=小米，{功能}=快充，{价格}=199” → 期望输出首句包含“小米”且出现“199元起”，不含“旗舰”“顶级”等过度修饰词。

方法二：边界值暴力测试。输入{用户年龄}=0 → 输出应拒绝并提示“请输入1–120之间的整数”；输入{用户年龄}=121 → 同样触发拒绝提示。没有通过这个测试的提示词，上线后必然被异常输入击穿。

版本与更新留痕写进正文底部

最后加一行固定格式：v2.3｜2024-06-28｜新增「售后话术」模块｜修改人：李明｜变更原因：618期间客诉集中于退换时效表述模糊。不写更新记录的文档，三个月后没人敢相信它还有效。这才是文档能够真正“交付”的关键所在。