zayn-reply

根据客户原话、已确认事实、沟通目标和不可承诺边界，生成适合具体渠道和语言的客户回复。

REPLY()

1. 基本信息

• Skill ID：zayn-reply
• Display Name：REPLY()
• Project：WorkFn
• Author Prefix：zayn
• 中文名称：客户回复
• 所属分类：客户沟通
• 一句话用途：根据客户原话、事实和目标，检查风险并决定如何回复
• Version：0.2.0
• Status：Draft for testing

REPLY() 用于处理客户已经发送明确消息后的回复判断。它不是普通润色工具，也不是固定话术库。

它的任务是先检查事实、证据、沟通目标、责任边界和下一步动作，再决定：

1. 是否应该立即回复
2. 是否需要先内部确认
3. 是否需要向客户补充提问
4. 是否适合直接生成回复
5. 应该采用什么语气和结构

2. 解决的问题

在客户已经发送明确消息后，判断现在是否适合回复、应该采取什么动作，以及如何在不虚构事实、不过早承诺、不暴露内部问题和不承担不必要责任的前提下形成回复。

与相邻 Skill 的区别

1. REPLY() 只负责最终表达，不补做客户意图、价格、责任或订单判断。
2. 客户意图不清时，先转入 INTENT_DECODE() 或 CLARIFY()。
3. 价格策略未确认时，先转入 PRICE() 或 NEGOTIATE()。
4. 责任状态未确认时，先转入 RESPONSIBILITY()。
5. 订单条件未确认时，先转入 ORDER()。

3. 适用场景

1. 客户发送询价、反馈、质疑、催促或确认
2. 客户提出目标价、交期、库存、保修或付款要求
3. 客户对现有方案表示不同意见
4. 客户回复内容存在模糊、隐含条件或风险
5. 用户已经有初步想法，希望检查逻辑和表达
6. 需要生成 Email、WhatsApp、WeChat 或其他渠道回复
7. 需要判断是否存在过早承诺、证据不足或责任暴露

4. 不适用场景

1. 尚未收到客户消息，只是准备主动开发
2. 需要判断是否应该跟进客户，应使用 FOLLOWUP()
3. 需要分析一条询价是否值得投入，应使用 RFQ()
4. 需要做完整报价检查，应使用 QUOTE()
5. 需要处理客诉责任认定，应使用 COMPLAINT()
6. 需要进行内部汇报或向上沟通，应使用 REPORT()
7. 事实尚未确认，且用户要求直接承诺结果

5. 输入参数

输入包括必填参数和建议参数。所有输入必须区分已确认事实、待确认事项和用户期望，不得把缺失值或推测补成事实。

6. 必填参数

参数	说明
customer_message	客户原话或完整上下文
confirmed_facts	已确认事实
reply_goal	本次回复目标
commitment_boundaries	不可承诺边界
channel	Email、WhatsApp、WeChat 或其他渠道
output_language	输出语言

7. 可选参数

参数	说明
customer_relationship	客户关系和合作背景
project_stage	当前项目阶段
tone	正式、自然、简洁、坚定或缓和
length	期望长度
questions_needed	是否需要提问
next_step_needed	是否需要推进下一步
forbidden_expressions	禁止表达
available_solutions	可提供方案
prior_reply	用户原本准备发送的内容
urgency	是否紧急或存在截止时间

8. 证据优先级

判断时必须按以下顺序使用证据：

1. 客户原话
2. 已确认的订单、报价、付款、发货和售后记录
3. 采购、工程、财务或管理层的明确确认
4. 当前项目文件和正式文档
5. 用户明确说明的事实
6. 历史沟通记录
7. 市场信息
8. 官网或公开信息
9. AI 推测

不得用低等级证据覆盖高等级证据。AI 推测只能标记为可能性，不能写成确定事实。

9. 判断规则

第一步：识别客户真正关心的问题

不要只按客户字面逐句回复。识别客户主要关心的是价格、交期、库存、成色、配置、兼容性、保修、付款、风险，还是是否值得继续推进。

第二步：区分信息状态

将所有信息分为：

1. 已确认
2. 待确认
3. 推测
4. 不应对外表达

第三步：检查沟通风险

执行第 10 节的全部风险检查。

第四步：决定回复动作

只能从以下动作中选择：

1. 直接回复
2. 先补充信息后回复
3. 先内部确认
4. 先向客户澄清
5. 暂时不回复
6. 只做轻量确认
7. 明确拒绝并说明边界

第五步：生成表达

只有在事实足够、边界清晰时，才生成可直接发送的回复。

渠道规则

Email

1. 结构完整、语气正式、重点清楚
2. 可以适度补充背景
3. 结尾有明确下一步

WhatsApp 或 WeChat

1. 更口语化、更短
2. 一次只推进一个重点
3. 避免长段解释
4. 不机械复制 Email

LinkedIn

1. 更轻量
2. 不直接堆大量产品信息
3. 先建立沟通入口
4. 避免强推销

英文表达要求

1. 不使用任何破折号
2. 不使用过度正式或生硬的商务套话
3. 不使用绝对化表达，除非事实已确认
4. 不使用 we promise 一类高风险承诺
5. 不使用 the problem is caused by us 一类责任认定，除非已确认
6. 避免长句
7. 优先使用自然、直接、可信的美式商务英语
8. 不把内部角色冲突或采购困难直接告诉客户

10. 风险检查

必须检查：

1. 是否过早承诺
2. 是否把预计写成确定
3. 是否把供应商口头反馈写成有货
4. 是否暴露内部采购、工程或管理混乱
5. 是否替公司承担不必要责任
6. 是否替客户做了未经确认的判断
7. 是否显得焦虑、催促或防御
8. 是否承诺了无法控制的时间
9. 是否忽略客户核心问题
10. 是否缺少明确下一步

11. 输出结构

正式输出依次包含：

1. 参数完整度结论
2. 参数状态表
3. 回复策略
4. 风险提示
5. 正式回复版本
6. 更简洁版本
7. 需要人工确认项

初步分析模式不得输出看似可直接发送的最终版本。

12. 禁止事项

1. 无中生有
2. 自动补全未确认事实
3. 替用户承诺价格、库存、交期、保修或付款条件
4. 把客户猜测写成客户真实意图
5. 把市场推测写成事实
6. 暴露内部采购、工程、供应商争议
7. 强行生成 Email 和 WeChat 两个重复版本
8. 为了显得完整而写得冗长
9. 在信息不足时给出确定结论
10. 覆盖用户已经确认的人工判断

13. 信息不足时的处理

关键参数缺失时，先输出：

text

当前无法稳定生成回复

然后列出：

1. 缺失的事实
2. 为什么这些事实重要
3. 建议向谁确认
4. 是否可以先发送临时回复
5. 临时回复的安全边界

安全的临时回复可以只确认已经收到客户信息并说明正在核实，但不得承诺具体价格、库存、交期、保修或付款条件。

14. 人工判断边界

1. 不覆盖用户已经确认的事实和人工判断
2. 不替采购、工程、财务、管理层或客户作出未经确认的决定
3. 不进行未经确认的责任认定
4. 需要超出用户权限的承诺时，必须先内部确认
5. 证据冲突时，指出冲突并请求人工选择，不自行覆盖高等级证据
6. 市场信息、公开信息和 AI 推测不得替代订单、报价、付款、发货、售后或内部明确确认

15. 验收标准

一个合格的 REPLY() 输出必须：

1. 回应客户真正关心的问题
2. 不把推测写成事实
3. 不过早承诺
4. 不暴露内部问题
5. 不承担不必要责任
6. 有明确下一步
7. 符合沟通渠道
8. 语言自然
9. 可以解释为什么这样回复
10. 信息不足时敢于不生成完整话术

16. 当前状态

text

Version: 0.2.0
Status: Draft for testing

本版本需要通过真实客户沟通案例继续验证和修正。

参数解析流程

本 Skill 必须先解析用户输入并映射到参数表。

参数状态表

正式分析前，必须输出参数状态表。

参数状态只能使用：

text

已命中
部分命中
缺失
冲突
待验证

统一格式：

参数	必需程度	当前状态	已获取内容	缺失或冲突影响
待按本 Skill 参数填写	待确认	缺失	无	待判断

参数状态表必须基于用户输入，不得凭空补充。

最低运行条件

1. 客户原话或上下文明确
2. 本次回复目标明确
3. 事实与待确认事项已区分
4. 不可承诺边界明确

未达到以上条件时，先输出参数状态表，说明缺失或冲突内容、重要性、影响和可直接补充的字段，然后停止正式分析。

缺失参数处理

不得自动补全缺失参数，必须明确提示用户补充，并说明缺失参数、重要性、影响、补充方式及当前是否可以先做初步分析。

冲突参数处理

不得自行解决冲突，必须保留不同来源、标记冲突、说明影响并提示验证。在冲突解决前降低分析置信度。

待验证参数处理

待验证信息不得写成确定事实。供应商口头反馈、市场信息、预计库存、预计交期、公开资料、客户可能意图和 AI 推测等必须明确标记。

停止条件

出现以下任一情况时停止正式分析：

1. 客户原话或上下文无法识别
2. 回复目标不明确
3. 事实与推测无法区分
4. 不可承诺边界缺失
5. 关键价格、库存、交期、责任或订单状态存在冲突
6. 前置专业判断尚未完成

停止时必须说明原因、缺失或冲突字段、补充方式，以及应转入的相邻 Skill。

正式分析触发条件

只有达到最低运行条件，且关键缺失、冲突、证据来源、分析目标和风险边界已得到处理后，才进入正式分析。

初步分析模式

参数不完整时，只能提供明确标注的初步分析：

text

以下为初步分析，仍需补充关键参数。

不得把初步分析包装成确定结论。

正式分析模式

参数完整并满足触发条件时，才可输出正式分析。正式输出前必须再次检查参数缺失、冲突、待验证信息、推测、人工判断、职责边界和用户真实目标。