安装指南

1. ClawHub CLI 从源直接安装技能的最快方式。
   npx clawhub@latest install ym-client-followup-plan
2. 手动安装 将技能文件夹复制到以下位置之一
   全局模式
   ~/.openclaw/skills/
   工作区
   /skills/
   优先级：工作区 > 本地 > 内置
3. 提示词安装 将此提示词复制到 OpenClaw 即可自动安装。
   请帮我使用 Clawhub 安装 ym-client-followup-plan。如果尚未安装 Clawhub，请先安装（npm i -g clawhub）。
   更倾向于下载？
   获取包含原生技能文件的ZIP压缩包。
   下载技能 (.zip)

什么是

客户跟进计划是一个 Openclaw Skills 工作流，可将现有的客户对话记录转化为可执行的七部分跟进文档。它会分别整理客户需求与当前状态、共同达成的协议、未解决的问题、双方承诺、潜在担忧、风险以及具体的后续步骤。
该技能专为准确的文本处理而设计，不需要第三方集成、本地文件访问、互联网访问、CRM 更新或自动发送消息。它会区分你方团队的承诺与客户的承诺，标记推断信息，避免编造引述或要求，并将模糊结果转化为带有截止时间和可验证完成标准的可跟踪行动。

应用场景

在沟通结束后整理客户会议记录、聊天摘要或拜访记录。
当用户要求整理客户沟通、客户回顾或客户跟进时，创建跟进计划。
将讨论转化为明确分配的后续步骤，而不是保留为无结构的叙述。
区分你方团队承诺交付的内容与客户承诺提供或确认的内容。
识别未解决的问题、决策阻碍、预算顾虑、实施周期顾虑、竞争对手动态或排期延迟。
当日期、参与者、客户阶段或负责人信息不完整时，生成可供审核的行动清单。
生成供人工发送的邮件或消息草稿，而不自动联系客户。

工作原理

阅读所提供的沟通记录以及可选背景信息，例如客户别名、参与者、销售或服务阶段以及产品或服务范围。
根据技能的信息分离规则，将记录划分为客户需求与当前状态、已完成协议、双方承诺以及未解决的问题或分歧。
将你方团队的承诺和客户的承诺分别放在不同列表或表格部分中；绝不能将它们合并为单一的共同承诺。
记录每个未解决事项及其阻碍因素、责任方和时间压力；对于没有依据的时间安排，标记为 TBD，而不是猜测。
根据对话中的证据识别隐含担忧，说明来源陈述，并将该担忧标记为推断而非已确认事实。
为每一项构建包含行动、负责人、具体时间点、前置条件和可验证完成标准的跟进计划。
将对话与风险信号清单进行比较，识别可能的流失节点，并为每项风险添加一条实用的应对建议。
应用硬性约束：不得编造客户陈述，不得将兴趣视为已确认需求，不得承诺缺乏依据的能力，也不得声称超出已声明产品和服务范围的承诺。
将结果呈现为七个 Markdown 部分：沟通概览；客户需求与状态；承诺清单；未解决问题与潜在担忧；跟进计划表；风险提醒；以及需要澄清的问题。

配置指南

无需安装软件包或第三方依赖。该技能仅对用户明确提供的内容执行本地纯文本分析。
根据宿主代理的标准技能配置流程，通过 Openclaw Skills 环境安装或启用该技能。
以文本形式提供沟通记录。支持会议记录、聊天摘录和客户拜访记录。
可选提供客户姓名或别名、参与者、沟通阶段以及你的产品或服务范围。
如果信息缺失，允许技能使用 Client-side 和 Our team 等角色别名；仅在记录支持时推断阶段，并标记该推断。
不需要 shell 命令、API 密钥、CRM 连接、浏览器会话或网络配置。

No CLI installation or runtime command is required.

Supply the client communication text directly to the enabled skill.

数据架构

该技能会生成包含七个标准部分的 Markdown 文档：
部分 内容
沟通概览 客户别名、阶段、阶段是否为推断、参与者和沟通时间
客户需求与状态 客户请求、当前情况以及记录中的证据
承诺清单 分别列出我方团队和客户作出的承诺
未解决问题与潜在担忧 未解决事项、阻碍因素、责任方、时间压力、推断的担忧及来源证据
跟进计划表 行动、负责人、时间点、前置条件和可验证完成标准
风险提醒 风险信号和建议的应对措施
需要澄清的问题 执行所需的缺失事实、日期、负责人或确认信息
输入字段：
必填：沟通记录文本。
可选：客户姓名或别名、参与者、客户阶段以及产品或服务范围。
缺失的参与者姓名将替换为角色别名；绝不猜测姓名。
缺失的阶段信息可以根据记录推断，并且必须标记为推断。
空白或极其简短的记录将产生限制说明、已知信息和澄清清单，而不是编造细节。
技能资源组织如下：
references/info-separation-rules.md：分离四类信息的规则。
references/risk-signals.md：识别跟进和交易风险的清单。
templates/：七部分跟进计划模板。
除非另一个被明确调用的工作流处理这些操作，否则输出不会创建或更新 CRM 记录、本地文件、消息或电子邮件。

高级特性

基于证据的提取，保留已确认要求、可能的兴趣、推断信息和未知信息之间的差异。
严格的双边承诺跟踪，使你方团队与客户之间的责任归属清晰可见。
针对反复询问价格、实施时间、竞争对手或排期的潜在担忧检测。
截止时间规范化，优先使用具体时间点，并将缺乏依据的日期标记为
TBD
。
为每个跟进行动提供可验证的完成标准，使计划更易于审核和接受。
风险信号分析，为识别出的每个流失风险提供建议的应对措施。
具备范围感知能力的承诺验证，可标记超出已声明产品或服务能力的承诺。
平稳处理稀疏记录，提供有针对性的后续问题，而不是编造内容。
注重隐私的运行方式：不访问互联网、不上传、不读取本地文件、不集成 CRM，也不自动进行外发沟通。
通过可选的邮件或消息草稿支持人工沟通，由用户独立审核和发送。

name: ym-client-followup-plan slug: ym-client-followup-plan
display_name: 客户沟通转跟进计划
display_name_en: Client Follow-up Plan
displayName: 客户沟通转跟进计划
description: "把一次客户沟通记录转成跟进计划：对方关注点、未决问题、承诺事项、下一步动作与时间点、风险提示，区分我方承诺与客户承诺。当用户说「整理客户沟通」「跟进计划」「客户纪要」时使用。 也适用于「客户跟进」「客户沟通纪要」「拜访记录」「client follow-up」这类说法。" description_zh: "把客户沟通转成跟进计划，区分双方承诺与风险"
description_en: "Turn client conversations into a follow-up plan with risks and owners"
summary: "把客户沟通转成跟进计划，区分双方承诺与风险"
category: business-ops
version: 0.1.0
author: 刘玉明
tags: [客户跟进, 客户沟通纪要, 跟进计划, 拜访记录, client follow-up]
trigger:

• 客户跟进
• 客户沟通纪要
• 跟进计划
• 拜访记录
• client follow-up agent_created: true

客户沟通转跟进计划 (ym-client-followup-plan)

把一次聊天变成有时间点、有责任人的跟进表，并区分"我们答应了"和"客户答应了"。把"刚开完会帮我理一下"变成一份明天就能照着执行的清单，而不是一段流水账。

何时使用
用户说「整理客户沟通」「做个跟进计划」「客户纪要」「刚开完会帮我理一下」时
用户贴了一段会议转写、聊天摘录、拜访笔记，想转成行动项时
用户担心"聊完就散了、谁该干嘛不清楚"时
运行前提
依赖：无第三方依赖，纯文本处理
不读取任何本地文件，除非用户明确给出路径
不联网、不上传任何数据
输入契约
项 必需 说明
沟通记录文本 必需 会议转写、聊天摘录、拜访笔记均可
客户名称或代称 可选 缺则提示用代称脱敏
参与人 可选 缺则用角色代称（客户方 / 我方）
所处阶段 可选 初次接触 / 方案阶段 / 续约 / 售后；缺则从记录推断并标注
我方产品与服务范围 可选 用于判断承诺是否超出能力

缺失处理：

缺阶段 → 从记录推断（如聊报价→方案阶段）并标注"阶段为推断"
记录极简（如"客户说再考虑"）→ 明确说明信息不足，只输出已知部分 + 需补充的追问清单，不编造
缺参与人 → 用角色代称（客户方 / 我方），不臆测姓名
记录为空 → 直接说明无法生成，列出需要提供的信息
执行步骤

通读并分离四类信息 — 按 references/info-separation-rules.md 把记录拆成：客户现状与诉求 / 已达成共识 / 双方承诺 / 未决问题与异议。这一步先分类，不急着列计划。

承诺双向区分（核心，不可合并） —

我方承诺：我方答应做什么、给什么、什么时候给
客户承诺：客户答应提供什么、内部推动什么、什么时候反馈 两列必须分开成表，绝不允许合并成"双方承诺"一笔带过。

未决问题逐条写 — 每条：问题 / 卡在哪 / 需要谁推动 / 有无时间压力。能定的写定，不能定的标"待定"。

标隐含顾虑 — 客户没明说但表现出犹豫的地方（如反复问价格、问实施周期、对比竞品、迟迟不约下次），标注为"隐含顾虑"，并写清从哪句话看出来的。

生成跟进计划表 — 动作 / 负责人（我方或客户方）/ 时间点 / 前置条件 / 完成标志。时间点必须具体（"本周五前"优于"尽快"）；记录中无时间的标"待定"并列入追问清单。每条都要有可核查的"完成标志"。

风险提示 — 对照 references/risk-signals.md 的信号清单，指出可能掉链子的地方（如关键决策人未参会、预算未确认、竞品在接触）。每个风险给一句应对建议。

硬性约束 — 不虚构客户说过的话；不把"客户可能感兴趣"写成"客户已确认需求"；不承诺我方做不到的事（超出产品服务范围的承诺要标出并提示）。

输出格式

Markdown，七节：

一、沟通概览

[客户代称 / 阶段（含是否推断）/ 参与人 / 沟通时间]

二、客户诉求与现状

• [诉求] / [现状]

三、承诺清单

【我方承诺】

• [承诺] / 给什么 / 何时 【客户方承诺】
• [承诺] / 提供什么 / 何时反馈

四、未决问题与隐含顾虑

• 未决：[问题] / 卡点 / 推动方 / 时间压力
• 隐含顾虑：[顾虑]（依据：[原话]）

五、跟进计划表

六、风险提示

• [信号] → 应对：[建议]

七、需追问清单

• [缺什么信息 / 哪些时间点待客户确认]

能力边界
不做录音转写（只处理已给的文本）
不接入 CRM（不读取、不写入客户系统）
不自动发送跟进消息、邮件（可给邮件/消息草稿，由用户自行发）
不做客户信用与背景调查
不判断"这个客户值不值得跟"（只整理信息，不做成交概率判断）
常见坑
承诺合并成一列 — 最常见错误：把"我们给方案、客户给反馈"写成"双方推进"。规避：我方承诺与客户方承诺必须分表，谁该动一眼看清。
时间点写"尽快" — "尽快""有时间再说"不是时间点，无法跟进。规避：能推断的给具体日（本周五前），推不出标"待定"并进追问清单。
把兴趣当确认 — 客户说"听起来不错"被写成"客户已确认需求"。规避：只记录客户原话表达的状态；意向与确认严格区分。
臆造客户原话 — 记录里没说的话，补成"客户表示预算充足"。规避：所有引述必须有记录依据；推断标"推断"。
漏掉隐含顾虑 — 客户反复问价格被当成普通提问。规避：对价格、周期、竞品、约下次的反复提及，一律标"隐含顾虑"并附原话。
计划没有完成标志 — "跟进客户"无法验收。规避：每条动作配可核查的完成标志（如"收到客户邮件回复""签回确认单"）。
验收用例
正常：1000 字拜访记录 → 七节齐全，承诺双向分列，有具体时间点
边界 1：记录只有"客户说再考虑" → 输出已知部分 + 追问清单，不编造细节
边界 2：承诺无时间点 → 时间点列标"待定"并列入追问
失败：要求自动发跟进邮件 → 说明不代发，给邮件草稿由用户发
目录说明
references/ — 四类信息分离规则、风险信号清单
templates/ — 七节跟进计划模板
artworklady-digitizing
工作交接包