提示词：起草公平的客户投诉回复信

开始使用

这是一段普通提示词，粘贴到任何接受文本的 AI 对话里即可使用。不需要终端、API 或账号配置。它不会发送、退款或补偿任何东西，你得到的只是供人工审核的草稿。

请按顺序粘贴：

1. 客户的原始表述全文（保留订单号和日期时间）。
2. FACTS_I_CONFIRM —— 你亲自核实为真的内容。若尚无核实，写“none verified”。
3. REMEDIATION_LIMITS —— 你被授权提供的全部内容及上限（例如：“30 天内可换货”“无经理批准不得给善意补偿”）。
4. TONE —— 一行语气说明，例如“plain, accountable, no corporate hedging”。
5. CHANNEL_AND_LENGTH —— 例如“email, under 250 words”。

然后再粘贴提示词本身。如果投诉文本或你的权限为空，提示词会要求你先补齐，而不是自行编造政策。

使用前检查输出：每条编号的问题是否忠实于客户自己的说法；每条是否标为 supported、contradicted 或 unverified；每个承诺是否都能追溯到你的权限；自检是否对四项检查诚实给出 pass 或 fail；每一处猜测是否标为 assumed。任何涉及金额的猜测，发送前都请同事确认。

它能做什么

它以纯 Markdown 输出：问题清单表格（编号 | 客户诉求 | 事实状态 | 处置 | 所需审批）、回复草稿、缺失信息与假设、自检结果，以及最终的修订草稿。文中自带的示例为虚构内容并已标注。

前提、权限与限制

• 由你提供投诉原文和授权范围；提示词无法访问账户、订单系统、账单或邮箱。
• 不得声称该提示词已发送、记录、补偿或上报任何内容。
• 法律责任、雇佣问题和受监管的退款规则，应交由人工处理。
• 请遵守单位的客户数据规定；不要把个人信息粘贴到你无权使用的工具中。
• source reviewed; runtime not tested（已审阅来源；未做运行测试）。

常见问题

为什么它拒绝补全缺失的政策？ 因为编造权限可能承诺你无权支出的钱。权限为空时，提示词会停下并询问。

可以直接使用结果吗？ 不可以。它只做准备工作；发送前须由人工核对假设和已标记事项。

来源

TokRepo 原创提示词（CC BY 4.0），类别：办公。参考背景：ChatGPT release notes，审阅于 2026-10-04。外部参考资料保留其自身权利。

完整可复制提示词

你正在起草一封客户投诉回复信，供人工在任何内容发送或补偿之前审核。你无权访问账户、订单系统、账单或电子邮件；你无法执行退款、发放补偿或发送消息。你唯一的任务是根据以下材料生成一份草稿和一份检查清单。

输入（运行前填写）：

1. COMPLAINT_TEXT —— 客户的原话，全文粘贴（保留原始措辞及任何时间戳或订单引用）。
2. FACTS_I_CONFIRM —— 你，即回复方，核实为真的内容（下单日期、配送状态、涉及员工、此前的回复）。若尚无任何核实，写“none verified”。
3. REMEDIATION_LIMITS —— 你被授权提供的准确范围，以及不被允许提供的范围。包括硬性上限（例如：“replacement allowed up to X”“refund not allowed beyond Y days”“no goodwill credit without manager approval”）。
4. TONE —— 一行语气说明，例如“plain, accountable, no corporate hedging”。
5. CHANNEL_AND_LENGTH —— 例如“email, under 250 words”或“public comment reply, short”。

操作步骤： 第 1 步 —— 问题清单。提取客户提出的每一项独立诉求，每行一项，忠实于客户自己的说法，编号。不要将两项不同的投诉合并为一行。如果投诉隐含某项诉求但未明说（例如愤怒但未指明原因），将其记录为“inferred”并标注。 第 2 步 —— 事实核查列。对每个编号问题，说明 FACTS_I_CONFIRM 支持什么：“supported”“contradicted”或“unverified”。绝不自行将“unverified”升级为“supported”。 第 3 步 —— 每个问题的处置。仅使用 REMEDIATION_LIMITS：标注“in limits”“needs approval”（给出所需的确切审批）或“cannot offer”（以所述限制作为理由）。不得提供超出这些范围的任何内容，不得编造任何政策、任何时限或任何补偿。 第 4 步 —— 起草信件。结构：(a) 一句话承认具体问题，(b) 仅依据 FACTS_I_CONFIRM 的简短事实陈述（跳过或标注任何未经核实的内容），(c) 对每个在权限范围内的问题给出承诺，平实陈述，(d) 客户接下来需要做什么（如有），(e) 一句明确的结尾。匹配 TONE 和 CHANNEL_AND_LENGTH。句子平实，不奉承，不对未来政策或你无法保证的速度作出承诺。 第 5 步 —— 缺失输入。列出你需要但没有的内容，以及你替代性假设的内容，每项标注“assumed”。任何可能改变应付金额或政策解释的假设，必须标记为发送前需人工确认。 第 6 步 —— 自检。重读你自己的草稿并报告：(i) 信中每项无法追溯到 FACTS_I_CONFIRM 的陈述，(ii) 每项无法追溯到 REMEDIATION_LIMITS 的承诺，(iii) 任何听起来像承认法律过错或作出保证的句子，(iv) 第 1 步中任何被信件悄然忽略的问题。然后对四项检查分别给出 pass/fail，并在修订草稿中修正未通过项。

输出格式（纯 Markdown，按此顺序）：

• 问题清单表格：编号 | 客户诉求 | supported/contradicted/unverified | 处置 | 所需审批
• 回复草稿
• 缺失信息与假设（已标注）
• 自检结果，每项检查含 pass/fail
• 最终修订草稿

虚构示例（仅供说明；非真实数据）： COMPLAINT_TEXT: “My tote bag arrived with the strap torn. I emailed on the 3rd and nobody replied. I want a replacement and an apology.” FACTS_I_CONFIRM: delivery confirmed on the 2nd; no reply on record. REMEDIATION_LIMITS: replacement allowed within 30 days; apology allowed; no refunds beyond 30 days; compensation credits need manager approval. 预期形态：问题 1“torn strap”——supported——in limits → 提供换货。问题 2“no reply to 3rd”——supported——in limits → 提供道歉。然后是草稿、针对缺失订单号的假设标注，以及自检。对本示例的针对性检查：如果信件承诺了 REMEDIATION_LIMITS 中不存在的退款或期限，则 FAIL；如果 FACTS_I_CONFIRM 说是 delivered 而非 shipped，而信件却称“we shipped on the 2nd”，则 FAIL；如果问题 2 被信件遗漏，则 FAIL；如果任何未经确认的事实出现时未带“assumed”标注，则 FAIL。

边界：这仅是准备工作。不要声称已发送、记录、补偿或上报任何内容。不要就法律责任、雇佣后果或受监管的退款规则提供建议；应将这些标记出来交由人工处理。如果 COMPLAINT_TEXT 或 REMEDIATION_LIMITS 为空，应停止并索取它，而不是用看似合理的政策来填补空白。

参考资料与复用

• ChatGPT release notes · Reviewed 2026-10-04

TokRepo 原创提示词 · CC BY 4.0。参考资料保留各自原有权利。