企业官网建设流程全解析

我们外贸业务员最累的不是回消息，是记消息。
一天两百条对话划过去，到晚上复盘的时候，想不起哪个客户提了什么要求、哪个客户说了下周给回复。
这几年我用 AI 做摘要，把这件事从「靠脑子」变成了「有清单」。这篇讲具体怎么做。

一、重点不是「看完」，是「抓到」

先说个现实。

一个业务员手里有八十个活跃客户，WhatsApp 上一天两百条消息是常态。这里面真正需要动作的可能只有五到八条。

问题是我们没法从两百条里精准捞出那八条。人看消息是线性的，一条一条往下划，划到最后，前面的已经模糊了。

我以前的解决办法是记便签。聊到重要的就写一张贴屏幕上。结果便签越贴越多，最后连便签都不敢看了。

后来我想明白一件事：摘要不是浓缩，是筛选。

一段对话摘要成三句话，如果只是把长话变短，价值不大。真正有用的是把「需要你做事的部分」挑出来，其余丢掉。

这个区别很关键。判断标准不是「总结得全不全」，是「看完之后知不知道下一步干什么」。

有了这个标准，摘要的维度就清楚了。

还有一层现实要承认：摘要永远会漏东西。

再好的摘要也是筛选，筛选就有取舍。我们能做到的是把「大概率的重点」捞出来，把漏掉的概率压到能忍受的范围。

所以摘要不能替代翻记录。它的定位是「让你不必每条都细看，但需要的时候能快速定位到原文」。

这也是为什么我要求每一条摘要都要带原文位置。摘要说「客户担心交期」，你得能一键跳到那句话。没有这个回溯能力，摘要就是个不可信的东西。

二、摘要要抓的四个维度

我把一条对话里值得留下的信息分成四类。

1. 需求

客户明确提出的、需要我们提供的东西。

比如「要一份 CE 认证的复印件」「想知道能不能做定制包装」「需要一个 20 尺柜的报价」。

需求的特点是：它是可以被执行的动作。看到就有一件事要做。

2. 异议

客户表达的顾虑、不满、疑问。

比如「你们的上一次交期慢了」「这款比另一家贵了 8%」「担心这个材质的耐用性」。

异议这类信息最容易被漏掉，因为它通常藏在一长段寒暄里，语气也不重。但它是成交的最大障碍，漏一条可能就丢一单。

我特别在意这类。以前有个客户在聊天里随口提了一句「我们的仓库只有两个卸货位，卸货时间有限」，这句话我们当时没当回事，后来货到了对方拒收，说卸不了。这一句如果被挑出来当异议处理，就不会有后面的麻烦。

3. 承诺

双方说过的、有约束力的话。

包括我们承诺的（下周发样品、周五前给方案），和客户承诺的（月底确认数量、下周一给答复）。

承诺是最需要摘要的一类，因为它直接对应「该不该催」。客户说了周一给答复，周二你就可以跟进，理直气壮。

4. 下一步动作

这条是前三条的落点。

摘要最后一定要有一句「接下来做什么」，是给谁做的、什么时候做。没有这一句，摘要就是一堆信息，看完还是不知道该干什么。

这四类我一般叫「需、异、诺、动」。跑熟了之后，一条对话扫一眼就能分出来。

四个维度里，异议是最容易漏的，我踩过的坑也最多。

原因是异议通常不直接说。客户不会写「我有一个异议」，他会绕。比如：

• 「你们的上一批货我们那边清关花了挺久」——其实是在试探下次能不能快点
• 「我老板最近在压成本」——其实是在为后面讲价做铺垫
• 「你们这款和某某牌的差多少」——其实是在做比较，心里已经有另一个选项了

这些话从字面上看只是陈述，从业务上看全是信号。机器很难判断，人一看就懂。

所以摘要这套东西的价值，不在于它能替人判断，在于它能把这类话从两百条消息里捞到眼前，让人有机会判断。

三、结构化输出怎么做

四个维度是内容层面的，落到工程上，得有个固定的格式。

我的做法是输出成 JSON。原因是它可以直接进表格、进 CRM，也能被脚本继续处理。

字段设计大概是这样：

• customer：客户名
• date：对话日期
• demand：需求列表，每条是一句话
• objection：异议列表
• commitment：承诺列表，每条带「谁承诺的」和「时间」
• next_action：下一步动作，一句话
• urgency：紧急程度，高、中、低

写 Prompt 的时候有三个要点。

第一，要求它只提取，不要推理。

明确告诉模型：只提取对话里明确出现的信息，不要根据上下文推测。因为它一推测就会开始编。

第二，要求它找不到就留空。

客户没提出异议，就返回空列表。不要让模型为了「完成格式」硬凑一条出来。这一条我踩过坑：早期不限制的话，模型会给每个客户都编出一条异议，看着挺丰富，实际全是错的。

第三，要求它保留原文关键短语。

涉及到具体数字、型号、时间的时候，让它引用客户的原话。这样后面核对的时候能对得上。

四、脚本怎么写

考虑到不是每个团队都有模型接口，我写了两层：一层是规则版，靠关键词先兜住底；一层是模型版，规则抓不到的地方再交给它。

先用规则版的原因是——规则版不花钱、不联网、不会编。虽然笨，但结果可信。

importreimportjson# 对话摘要脚本：规则版。# 为什么先写规则版？因为它有两个模型替代不了的优点：# 1. 结果可解释，命中了哪句话一查就知道，不会出现「AI 说是这样」的情况# 2. 不依赖外部接口，断网也能跑，日常稳定性更可控# 规则版覆盖不了的部分，再交给模型补，这样出错概率最低。# 高频表达模式。这些是从我们团队两年的聊天记录里捞出来的，# 不是为了穷举所有表达，是为了覆盖最常见的八成。PATTERNS={"demand":[r"(?:能|能否|可以)不?能?(?:提供|发|做|给)([^，。？！]{2,30})",r"(?:需要|要一份|需要一份|想要)([^，。？！]{2,30})",r"(?:send|provide|need)\s+(?:me\s+)?([a-z0-9 ,\-]{3,40})",],"objection":[r"(?:担心|害怕|concer|worri|afraid)([^，。？！]{2,40})",r"(?:太贵|贵了|偏高|高了|expensive|too high)([^，。？！]{0,20})",r"(?:上次|之前)(?:的)?(?:问题|慢了|延迟|delay)([^，。？！]{0,30})",],"commitment":[r"(?:我们|我)(?:会|会尽快|将在)([^，。？！]{2,30})",r"(?:下周一|下周二|下周|本周五|月底|月底前)([^，。？！]{0,30})",r"(?:we will|will send|will confirm)([^\.]{2,40})",],"urgency_high":[r"紧急|马上|尽快|asap|urgent|immediately"],"urgency_low":[r"不急|慢慢来|no\s+rush|whenever"],}defextract_by_rule(text):"""按模式抽取。返回的每条都带上原文片段，方便人工核对是否抽对了"""result={"demand":[],"objection":[],"commitment":[]}forfield,patternsinPATTERNS.items():iffieldnotinresult:continueforpinpatterns:forminre.finditer(p,text,flags=re.IGNORECASE):snippet=m.group(0).strip()# 去重：同一个意思被两个模式命中时只留一条，避免摘要看着很乱ifsnippetnotinresult[field]:result[field].append(snippet)returnresultdefjudge_urgency(text,commitments):"""紧急程度判断。有明确时间点的承诺最优先，其次是语气词。 为什么把承诺放在语气前面？因为「客户说月底给答复」比「客户说尽快」更可执行。"""ifany(re.search(p,text,re.IGNORECASE)forpinPATTERNS["urgency_high"]):return"高"ifcommitments:return"中"return"低"defbuild_summary(customer,text,model_summary=None):"""拼装最终摘要。model_summary 是模型版的输出，可为空。 两边都跑的好处是能对照：规则抽到的和模型抽到的差在哪里，一眼就能看出来。"""rule_result=extract_by_rule(text)urgency=judge_urgency(text,rule_result["commitment"])summary={"customer":customer,"demand":rule_result["demand"],"objection":rule_result["objection"],"commitment":rule_result["commitment"],"urgency":urgency,# 下一步动作必须由人生成，脚本只提示「这里需要人补」。# 为什么不让模型直接写动作？因为动作涉及资源和优先级，只有人知道。"next_action":"待人工确认",}ifmodel_summary:summary["model_supplement"]=model_summaryreturnsummaryif__name__=="__main__":chat=("Hi, thanks for the samples last week. ""We need a copy of the CE certificate for our customs clearance. ""We are a bit concerned about the delivery time since the last shipment was delayed. ""We will confirm the quantity by the end of this month. ""Please send the packing list ASAP.")summary=build_summary("Nordic Trading",chat)print(json.dumps(summary,ensure_ascii=False,indent=2))

跑了一遍，上面这段对话会被抽出一条需求（CE 证书）、一条异议（担心交期）、一条承诺（月底确认数量），紧急度判成高，因为出现了 ASAP 和明确的月底时间点。

准确率说实话不是百分之百，一些委婉的说法会漏。所以我现在的用法是：规则版先跑一遍，把命中的部分当清单，剩下不确定的整段丢给模型再过一次。

两层结合之后，八十个客户的对话，我大概十五分钟能过完，以前得一个小时。

用久了还有两个附带的好处。

一是**团队交接变容易了。**业务员请假或者离职，接手的人不用翻全部记录，看摘要清单就知道每个客户走到哪一步了。以前交接一个客户要花半天，现在十几分钟。

二是**复盘有依据了。**月底回看这个月的摘要，能看出哪类异议出现最多、哪类需求我们响应最慢。这些问题凭印象判断不出来，因为印象总被最近发生的事影响。

第一个月跑的时候，规则版的准确率估计只有六成。后来靠两件事提上来的：一是把漏掉的表达补进模式里，二是让业务员每天花两分钟纠错。

纠错这一步不能省。脚本不会自己变聪明，是人喂给它的。

五、三种做法对比

第三种效率最高，但有个前提：必须有人核对。

我们团队的规定是，模型摘要不能直接进 CRM，必须有人看过点过确认。原因很简单，客户需求错一条，后面的动作全是错的。

至于对话本身怎么收集，我们多个号的消息是聚在 WADesk 这类工具里看的，摘要脚本直接处理导出的对话文本。这样至少不用在几个手机之间来回翻。

写在最后

今天就能做的一件事：挑一个对话最多的客户，把最近一个月的聊天记录导出来。

然后拿张纸，按「需求、异议、承诺、下一步动作」四栏，自己手工摘一遍。感受一下这四个维度是不是够用。

摘上三五个客户，你就知道该固定哪几栏了。等手摘觉得烦了，再把脚本接上。