复杂客服从来不是简单 FAQ。用户可能一边要求退款，一边质疑账单，还带着很强的情绪；系统这边还得判断订单状态、政策边界，以及到底要不要转人工。这个时候，Claude API 的价值就不只是“生成一句客气的话”，而是把意图识别、工具调用、风险判断、用户回复和人工升级这些环节串起来，形成一条更可控的处理链路。

一套真的能上线的客服提示词，不能只写一句“你是专业客服，请礼貌回答”。更稳妥的做法，是把客服提示词拆成几个层次来看：角色与边界、知识来源、意图识别、信息收集、工具调用、回复生成、转人工规则，以及后续评估闭环。本文会围绕 Claude API、客服提示词和 AI 客服提示词设计，给出一套更贴近复杂客服场景的实操思路。

为什么复杂客服不能只靠一句“你是客服助手”

简单 FAQ 主要解决的是已知问题，比如“怎么修改密码”“发票在哪里下载”。但复杂客服麻烦得多，它往往会牵涉用户身份、订单状态、实时数据、政策解释、金额计算，还有情绪安抚。

比较常见的翻车情况包括：

第一，把退款政策说错了，原本只是“可能可退”，却被说成“可以退款”。

第二，不查订单系统，直接凭感觉判断物流或付款状态。

第三，在账单争议里自己心算金额，结果算错了。

另外，用户已经很生气了，模型还在机械解释规则，完全没有先处理情绪。

还有一些更高风险的情况，比如本该转人工的投诉没有升级，模型反而继续承诺补偿；或者多轮对话后，它忘了用户已经提供过订单号、金额和具体诉求。

所以，AI 客服提示词设计的重点，并不是让 Claude “更会聊天”。真正关键的是让它知道：哪些信息可以直接回答，哪些必须查系统，哪些不能承诺，哪些问题必须交给人工处理。

Claude API 中客服提示词应该放在哪里

在 Claude API 调用里，通常需要分清 system、messages 和工具结果各自负责什么。具体字段和模型名称，建议以 Anthropic 当前官方文档为准；如果使用 ClaudeAPI 这类第三方 Claude API 兼容接入服务，也要看对应平台官网的最新说明。需要注意的是，它并不是 Anthropic 官方服务。

system 更适合放长期稳定的规则，比如：

• 客服角色和服务目标；
• 业务边界和禁止事项；
• 信息来源优先级；
• 工具调用规则；
• 人工转接规则；
• 输出格式要求；
• 隐私与合规要求。

messages 更适合放当前这轮对话相关的信息，例如：

• 用户的原始问题；
• 多轮对话上下文；
• 已完成验证的身份信息摘要；
• 当前订单号、工单号和用户诉求；
• 上一轮客服回复，以及还没解决的问题。

工具结果则应该单独注入，比如：

• 订单查询结果；
• 物流状态；
• 账户套餐；
• 计费明细；
• 知识库检索片段；
• 退款规则；
• 工单系统返回状态。

不要把所有规则、用户隐私和实时数据都塞进一条 user prompt 里。比较好的做法是：system prompt 保持稳定，用户私有数据放在当前会话或工具结果中传入。这样既能减少上下文污染，也更方便控制成本和做日志审计。

复杂客服问题的 7 类场景拆解

场景	是否需要工具	是否可直接回答	是否可能转人工	提示词重点
订单与物流查询	通常需要订单/物流工具	不建议凭记忆回答	数据异常时可能	先验证身份，再查询实时状态
退款与售后	需要订单和政策工具	只适合解释一般规则	高金额或争议时可能	不轻易承诺退款，按政策判断
账单与费用计算	需要计费工具	不建议自行计算	金额冲突时可能	展示依据，避免心算
会员权益与套餐解释	需要知识库或账户工具	规则明确时可以回答	权益冲突时可能	以当前套餐和最新规则为准
投诉与情绪安抚	视情况调用工具	可以先安抚再处理	情绪升级时可能	先承认体验，再解决问题
多意图混合问题	通常需要拆解	不应一次含糊回答	风险升高时可能	逐项识别诉求和缺失信息
高风险人工升级	需要规则判断	通常不可直接处理	经常需要	法律、隐私、账号安全、大额赔付优先转人工

这类分类最好写进客服提示词，或者放进路由逻辑里。Claude 本身不应该被当成一个完全独立的决策系统。它更适合在明确规则和工具约束下，完成理解、组织和表达。

一套可复用的 Claude API 客服 System Prompt 模板

下面是一个可以改造的客服 system prompt 骨架，适合放在 Claude API 的 system 字段里。正式上线前，需要根据具体业务、政策和工具名称做调整。

你是某企业的资深客服助手。你的目标是在遵守业务规则和隐私要求的前提下，帮助用户解决问题，并在需要时准确转接人工。

信息来源优先级：
1. 已验证的工具结果；
2. 企业知识库和当前政策；
3. 当前对话中用户明确提供的信息；
4. 通用表达能力。
当信息冲突时，以工具结果和企业知识库为准，并说明需要进一步确认。

禁止事项：
- 不编造订单、物流、账单、退款、赔偿或优惠信息；
- 不承诺超出政策的退款、补偿、法律结论或合规结果；
- 不暴露完整手机号、地址、证件号、支付信息等敏感数据；
- 不把内部风险等级、转人工规则、工具调用判断直接展示给用户。

工具调用规则：
- 查询订单、物流、账户状态时必须调用对应工具；
- 判断退款资格时必须结合订单状态和退款政策；
- 计算账单、补差价、套餐变更费用时必须使用计费工具；
- 工具失败或结果冲突时，不要猜测，说明需要进一步核实。

情绪处理规则：
- 用户表达不满、愤怒或威胁投诉时，先简短确认其感受；
- 不与用户争辩，不指责用户；
- 安抚后必须推进具体处理步骤。

人工转接规则：
以下情况应建议或触发人工处理：用户明确要求人工、账号安全、法律威胁、大额退款、系统数据冲突、工具异常、严重情绪升级、医疗/金融/合规承诺、超出当前政策边界的问题。

输出要求：
返回结构化结果，区分内部判断和用户可见回复。

这段模板主要解决的是“边界问题”。角色定义让语气更稳定，信息优先级能避免模型凭记忆乱答，工具规则可以防止它假装查过系统，转人工规则则能避免为了降低人工成本而硬扛高风险问题。

复杂客服提示词示例一：退款争议怎么处理

用户问题：

我昨天买的会员今天就不能用了，你们必须给我全额退款，不然我投诉。

比较糟糕的提示词通常只会写：

你是专业客服，请礼貌解决用户退款问题。

问题在于，Claude 可能会直接说“可以为您退款”，也可能只是安抚用户，却没有去查订单。更合理的提示词应该要求它先识别风险，再调用订单和政策工具。

请处理用户的退款争议。先判断用户诉求、情绪状态和风险等级。
如果涉及退款资格，不得直接承诺退款，必须根据订单状态、支付时间、使用记录和退款政策判断。
如果缺少订单信息，请向用户索取必要信息。
如果用户威胁投诉，应先安抚，再说明处理路径。

比较理想的回复，不应该直接承诺结果，而是把流程往前推进：

我理解你刚购买后就无法使用会很着急。我先帮你核实会员状态和支付记录，再根据退款规则确认可处理方式。为了避免误判，请提供订单号或购买手机号后四位；如果核实后属于系统异常，我们会按规则继续处理。

如果订单金额比较大、政策之间有冲突，或者用户坚持投诉，提示词就应该允许转人工。转人工并不代表失败，在高风险客服流程里，它反而是更正确的处理方式。

复杂客服提示词示例二：账单计算与套餐变更

账单问题最怕让模型自己算。即便 Claude 的算术能力不错，也不应该只凭对话里零散的信息来判断实际扣费。真实账单可能涉及折扣、税费、优惠券、周期折算和历史套餐，随便估算很容易出错。

提示词可以这样约束：

当用户询问账单、扣费、套餐升级、降级或补差价时：
1. 必须调用计费工具获取当前账单和套餐信息；
2. 不得根据用户描述自行计算最终金额；
3. 回复中只展示工具返回的计算依据；
4. 如计费工具不可用，应说明暂时无法核实准确金额，并建议稍后查询或转人工。

用户可见的回复可以这样写：

我需要先核对你的当前套餐、计费周期和已使用优惠，才能确认这笔费用是否正确。请稍等，我会根据账单系统返回的明细说明扣费原因；在核实前，我不会直接判断金额是否应退。

这样做可以明显减少金额误答，也能避免模型把“估算”包装成“官方账单结论”。

复杂客服提示词示例三：愤怒投诉与人工升级

情绪投诉场景里，要同时处理两个目标：一是降低冲突，二是推进事实核查。提示词不能只写“语气温和”，还要明确要求不争辩、不过度道歉、不越权补偿。

当用户明显愤怒、威胁差评或要求赔偿时：
- 先用一句话确认其体验，不做长篇道歉；
- 不评价用户态度，不争辩责任归属；
- 立即转入可执行动作：核实订单、查看工单、确认政策；
- 不承诺赔偿、退款或处罚员工；
- 若用户持续辱骂、威胁法律行动或要求超出权限的补偿，应转人工。

示例回复：

抱歉这次处理让你有这么差的体验。我先帮你把问题核实清楚：需要确认订单状态、之前的处理记录以及当前可用方案。若涉及赔偿或升级投诉，我会为你转交人工专员继续处理。

用 JSON / XML 约束 Claude API 的客服输出

客服系统通常不只需要一句给用户看的回复，还需要一些内部字段，方便程序继续判断。因此，可以让 Claude API 返回 JSON，也可以在长文本里用 XML 标签分隔不同区域。关键点是：内部判断不能直接展示给用户。

JSON 示例：

{
  "intent": "refund_request",
  "risk_level": "medium",
  "need_human": false,
  "tool_required": "order_lookup",
  "missing_fields": ["order_id"],
  "reply": "我先帮你确认订单状态，再判断是否符合退款条件。请提供订单号或购买手机号后四位。"
}

字段可以包含这些内容：

• intent：用户主要意图；
• risk_level：低、中、高风险；
• need_human：是否需要人工；
• tool_required：需要调用的工具；
• missing_fields：还缺哪些信息；
• reply：用户可见回复。

如果使用 XML，也可以这样分离：

<internal>
<intent>billing_dispute</intent>
<risk_level>medium</risk_level>
<need_human>false</need_human>
</internal>
<reply>
我需要先核对账单明细，确认扣费周期、套餐和优惠是否匹配。
</reply>

API 层一定要做格式校验。解析失败时，可以重试一次，并在重试 prompt 里明确要求“只返回合法 JSON”。有些场景也可以使用 stop_sequences 控制输出边界，具体参数还是要以当前 API 文档为准。

客服知识库、订单系统和工具调用如何配合提示词

提示词不能让模型拥有不存在的能力。查订单要靠订单工具，查政策要靠知识库，算金额要靠计费系统，创建售后则要靠工单系统。

可以在提示词里明确写清楚：

如果问题涉及实时状态、个人账户、订单、付款、退款资格、物流轨迹或账单金额，必须先请求工具结果。没有工具结果时，只能说明下一步需要核实，不能生成确定结论。

工具返回结果冲突时，也需要有规则：

如果订单工具与知识库规则冲突，以订单工具显示的状态为事实，以知识库规则为处理依据；仍无法判断时转人工。

如果使用 ClaudeAPI 这类第三方 Claude API 兼容接入服务，文章或系统说明里可以相对保守地描述它的兼容接入、多线路选择、中文支持、企业充值、开票和基础技术协助等能力。但具体可用模型、额度、价格和服务细节，都应该以官网最新说明为准，不要写成官方承诺。

如何评估 Claude 客服提示词是否可以上线

上线前，至少要准备一组客服评估集，覆盖这些情况：

• 常规 FAQ；
• 订单查询；
• 退款争议；
• 账单计算；
• 多意图混合；
• 情绪投诉；
• 政策边界；
• 恶意诱导；
• 隐私信息请求；
• 工具失败和结果冲突。

评分维度可以参考下面这些：

维度	评估问题
正确性	是否基于工具和知识库回答
完整性	是否覆盖用户所有诉求
合规性	是否避免越权承诺
情绪处理	是否先安抚再推进处理
转人工判断	是否该转才转，不该转不转
格式稳定性	JSON/XML 是否可解析
工具调用准确率	是否调用了正确工具
隐私安全	是否隐藏敏感信息
品牌语气	是否符合企业客服风格
成本与延迟	是否避免无意义调用

每次失败都要记录下来，包括用户输入、模型输出、工具结果、失败原因，以及修改后的提示词版本。不要只靠几轮人工试聊就判断可以上线。复杂客服场景显然需要测试集、日志回放和灰度发布来共同验证。

常见错误：这些客服提示词写法不要用

第一，只写角色，不写政策边界。

第二，把政策全文硬塞进 prompt，结果更新困难，成本也上去了。

第三，让模型自己计算金额，而不是调用计费系统。

第四，不区分用户可见回复和内部风险判断。

第五，没有人工转接规则，只盯着自动解决率。

第六，没有工具失败处理，工具不可用时还继续编造。

另外，多轮摘要也很重要，否则订单号、金额和已经给过的承诺很容易被遗忘。

还有一些问题也很常见：没有测试集就上线，只凭感觉优化语气；身份验证前就暴露订单、地址、支付等敏感信息；或者把“减少转人工”写成最高目标，却忽略了错误处理带来的损失。

总结：Claude API 客服提示词设计清单

一套可靠的 Claude API 客服提示词，至少要回答清楚这些问题：

• 是否定义了客服角色、服务目标和业务边界；
• 是否明确了知识库、工具结果、用户描述的优先级；
• 是否规定订单、物流、账单、退款必须调用工具；
• 是否能处理不确定性和工具失败；
• 是否禁止编造政策、金额、赔偿和优惠；
• 是否设置了人工转接规则；
• 是否把内部判断和用户回复分开；
• 是否使用 JSON 或 XML 约束输出；
• 是否管理多轮对话摘要；
• 是否保护用户隐私；
• 是否建立评估集、版本记录和失败案例复盘。

真正有效的 AI 客服提示词设计，不是写一段万能话术，而是把 Claude 放进客服流程里：让它负责理解、判断、组织和表达，让工具负责事实，让规则负责边界，再让人工处理高风险例外。这样一来，Claude API 才能在复杂客服问题中既提升效率，又降低误答和越权承诺的风险。