复杂客服从来不是简单 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 intentbilling_dispute/intent risk_levelmedium/risk_level need_humanfalse/need_human /internal reply 我需要先核对账单明细确认扣费周期、套餐和优惠是否匹配。 /replyAPI 层一定要做格式校验。解析失败时可以重试一次并在重试 prompt 里明确要求“只返回合法 JSON”。有些场景也可以使用stop_sequences控制输出边界具体参数还是要以当前 API 文档为准。客服知识库、订单系统和工具调用如何配合提示词提示词不能让模型拥有不存在的能力。查订单要靠订单工具查政策要靠知识库算金额要靠计费系统创建售后则要靠工单系统。可以在提示词里明确写清楚如果问题涉及实时状态、个人账户、订单、付款、退款资格、物流轨迹或账单金额必须先请求工具结果。没有工具结果时只能说明下一步需要核实不能生成确定结论。工具返回结果冲突时也需要有规则如果订单工具与知识库规则冲突以订单工具显示的状态为事实以知识库规则为处理依据仍无法判断时转人工。如果使用 ClaudeAPI 这类第三方 Claude API 兼容接入服务文章或系统说明里可以相对保守地描述它的兼容接入、多线路选择、中文支持、企业充值、开票和基础技术协助等能力。但具体可用模型、额度、价格和服务细节都应该以官网最新说明为准不要写成官方承诺。如何评估 Claude 客服提示词是否可以上线上线前至少要准备一组客服评估集覆盖这些情况常规 FAQ订单查询退款争议账单计算多意图混合情绪投诉政策边界恶意诱导隐私信息请求工具失败和结果冲突。评分维度可以参考下面这些维度评估问题正确性是否基于工具和知识库回答完整性是否覆盖用户所有诉求合规性是否避免越权承诺情绪处理是否先安抚再推进处理转人工判断是否该转才转不该转不转格式稳定性JSON/XML 是否可解析工具调用准确率是否调用了正确工具隐私安全是否隐藏敏感信息品牌语气是否符合企业客服风格成本与延迟是否避免无意义调用每次失败都要记录下来包括用户输入、模型输出、工具结果、失败原因以及修改后的提示词版本。不要只靠几轮人工试聊就判断可以上线。复杂客服场景显然需要测试集、日志回放和灰度发布来共同验证。常见错误这些客服提示词写法不要用第一只写角色不写政策边界。第二把政策全文硬塞进 prompt结果更新困难成本也上去了。第三让模型自己计算金额而不是调用计费系统。第四不区分用户可见回复和内部风险判断。第五没有人工转接规则只盯着自动解决率。第六没有工具失败处理工具不可用时还继续编造。另外多轮摘要也很重要否则订单号、金额和已经给过的承诺很容易被遗忘。还有一些问题也很常见没有测试集就上线只凭感觉优化语气身份验证前就暴露订单、地址、支付等敏感信息或者把“减少转人工”写成最高目标却忽略了错误处理带来的损失。总结Claude API 客服提示词设计清单一套可靠的 Claude API 客服提示词至少要回答清楚这些问题是否定义了客服角色、服务目标和业务边界是否明确了知识库、工具结果、用户描述的优先级是否规定订单、物流、账单、退款必须调用工具是否能处理不确定性和工具失败是否禁止编造政策、金额、赔偿和优惠是否设置了人工转接规则是否把内部判断和用户回复分开是否使用 JSON 或 XML 约束输出是否管理多轮对话摘要是否保护用户隐私是否建立评估集、版本记录和失败案例复盘。真正有效的 AI 客服提示词设计不是写一段万能话术而是把 Claude 放进客服流程里让它负责理解、判断、组织和表达让工具负责事实让规则负责边界再让人工处理高风险例外。这样一来Claude API 才能在复杂客服问题中既提升效率又降低误答和越权承诺的风险。