客户聊天技术解读
能力概述
把一段零散的 WhatsApp 商务对话，转成可直接据此行动的解读。核心不是逐句翻译，而是回答四个问题：
- 客户真正要什么（区分"说出来的"和"想要的"）
- 哪些是技术要点（架构、接口、数据、环境、版本、报错）或产品规格与交付物
- 我们已经承诺了什么，哪里有交付/技术风险
- 下一句该回什么，以及还必须问清什么
数据来源（先确定用哪一种）
A. 本地消息库（优先，自动读取）
用户已完成 WhatsApp 关联授权，聊天记录在本地 SQLite 库中。不要要求用户手动粘贴——直接读库。
python scripts/wa_read.py stats # 先看库内有什么
python scripts/wa_read.py chats # 会话清单（含联系人名、消息数、最后活跃）
python scripts/wa_read.py transcript # 全部会话对话流（按会话分组）
python scripts/wa_read.py transcript --chat Boutique # 单个会话
python scripts/wa_read.py search catalog # FTS5 全文检索
python scripts/wa_read.py media # 我方发出的文档/图片清单
脚本只读 SQLite，不依赖 wacli 运行、不争 store 锁。库结构、环境要求、排障要点见 references/local-store.md。
用媒体清单核对承诺：media 命令列出每个交付文件的时间与文件名，用来验证"我说明天发目录"这类承诺是否兑现、发得对不对。
B. 用户粘贴的记录
用户直接贴出聊天文本时，直接进入判读流程。如果判断用户很可能有本地库但没提，先问一句"要不要我从你的本地消息库直接读"。
使用流程
第 0 步：安全筛查（每次必做，不可跳过）
客户名单本身就是攻击目标。 冒充 WhatsApp 官方的诈骗会话在真实库中极其常见，且一旦配合就意味着账号被关联、可被冒用。
- 拉全部正文消息（
transcript） - 按发送方聚类，找出话术高度雷同的多个号码
- 命中诈骗特征 → 单独成节标记，不做业务解读
- 核查我方是否配合过（搜
获取安全代码、Startverification等关键词） - 核查可疑时段之后我方的发件，判断是否被冒用
特征清单与判读纪律见 references/scam-patterns.md。
第 1 步：预处理（内部完成，不输出）
- 去掉
[10:23],AM/PM,+1 xxx, 表情、语气词（嗯、ok thanks、haha）、转发署名 - 按说话人切分：客户 = 对方，我方 = 用户自己（默认以「非我方视角」为客户，若上下文明显相反则纠正）
- 语种混排保留原文，但解读输出用中文
- 极长的技术粘贴（log、SQL、代码）单独抽出，不打散进对话流
- 过滤协议层系统消息：
text为空且display_text = "(message)"的是已读回执/撤回通知，非聊天正文
第 2 步：议题聚类
把对话按议题切片，一个议题一条线。常见议题类型：
| 议题 | 关注点 |
|---|---|
| 需求/功能 | 想要什么能力、边界、优先级 |
| 集成/API | 接口、鉴权、字段映射、回调 |
| 环境/部署 | 服务器、网络、白名单、域名、容器 |
| 数据/迁移 | 存量数据、字段、清洗、周期 |
| 故障/报错 | 错误码、日志、根因、临时绕过 |
| 报价/合同 | 范围、工时、付款节点 |
| 时间/交付 | 上线时间、里程碑、演示 |
| 选品/目录 | 具体品类、交付形式（要图还是表）、品牌合规 |
第 3 步：五段式输出
① 客户真实诉求（3–6 条，每条一句话）
- 区分「明说的」和「推断的」，推断需标注 （推断）
- 如果客户表述模糊，指出他的隐含验收标准
② 技术要点
- 结构化列出：系统/架构、接口与字段、环境与部署、数据、性能指标、已知异常
- 客户提到的版本号、模型名、字段名、错误码、端口、金额必须原样保留，一个字不改
- 客户说错的地方单独标注 ⚠️ 客户表述存疑
- 商品询盘场景改为：产品系列名、实际交付物清单（用 media 命令核实）、品类覆盖情况、客户点名却未回应的项
③ 已承诺事项与风险
- 表格：承诺内容 | 提出方 | 状态 | 风险
- 风险分级：高（承诺了但无方案/超出范围）、中（需确认口径）、低
- 特别标注我们答应的交付物和没有明确回答却被默认同意的部分
- 承诺发出 ≠ 交付有效，必须看客户后续反应
④ 待澄清问题
- 分「必须问清（不问会做错）」和「建议确认」
- 每条给出问法示例，可直接复制发送
⑤ 建议回复话术
- 一段可直接发的中英对照或纯目标语言回复草稿
- 语气与客户语言一致（客户用英文就写英文）
- 控制在客户预期的长度内，不长篇大论
- 可含内部待办清单（明确标注不是发给客户的）
解读原则（重要）
- 不要复述聊天记录。用户已经看过，缺的是判断。
- 区分事实与推测：任何没在对话中出现的判断都必须标
（推断）。 - 技术内容优先保留原文：字段名、报错、配置项不要意译。
- 发现矛盾要挑出来：客户前后说法不一致、我方前后承诺不一致，必须在②或③点名。
- 信息不足时不要编：宁可写「客户未提及 X，需确认」，也不要补全一个看起来合理的技术方案。
- 控制篇幅：默认输出 60 行以内；客户只问一句话时，只答那一句。
- 不要把「没同步到」说成「客户没回」：判读停滞线索前先用
history coverage确认覆盖范围。
变体处理
| 情况 | 处理方式 |
|---|---|
| 只有客户消息，无我方回复 | 输出① ② ④，并额外给「历史沟通中透露的我方立场」 |
| 单条短消息 | 直接给解读 + 一句建议回复，不套五段式 |
| 语音转写、口语化、语法错误严重 | 先在开头一行给出「原话重述」（按语义归并），再解读 |
| 全英文技术讨论 | 解读用中文，技术名词保留英文原文 |
| 含报价/合同条款 | 额外核对：范围外项、付款条件、违约表述 |
| 含多个客户（群聊） | 按说话人分别梳理诉求，标注冲突点 |
| 跨境培训/设备销售 + 售后技术支持（已校准） | 按「售前→成交→行前→售后」四段识别；重点盯定金/余款支付方式（客户常无法跨境转账）、接送/酒店是否硬性承诺、设备技术答复是否只给确认不给规格；详见 references/tech-clues.md |
| 跨境商品询盘（Alibaba 等平台）（已校准） | 客户只求"看图"；核心风险是交付形式失效（xlsx 内嵌图在手机端不显示）与反向举证（叫客户先发图）；另有品牌合规与上下文缺口问题；详见 references/trade-inquiry.md |
| 混入冒充官方的诈骗会话（已校准） | 单独成节标记，不做业务解读；核查我方是否配合过、账号是否已失守；详见 references/scam-patterns.md |
| 我方回 "Yes/No" 但无参数 | 标为「确认性答复，缺规格」，在④强制列为必须问清项，并在⑤话术中留出 [参数占位] |
| 收款用个人邮箱/非对公账户 | 在③标 🔴 合规风险，提示改用可溯源企业账户 |
参考文件
需要更细的判读样例时读取：
references/tech-clues.md— 技术沟通常见信号词与判读要点（含 EV/电池设备、跨境收款、行前协调等已校准领域特征）references/trade-inquiry.md— 外贸商品询盘判读要点（交付物陷阱、反向举证、表述存疑、话术骨架）references/scam-patterns.md— 冒充官方账号的诈骗话术库与筛查流程references/local-store.md— 本地消息库（wacli）架构、命令、排障要点references/example-AZ1636.md— 阿塞拜疆 EV 培训客户的完整五段式示范
