产品终止消息撰写技能（eol-message）：把“产品要下线了”写成一次值得信任的沟通
- 它解决的问题很具体：产品、功能或 API 停用时的对外通知。多数团队写不好这类消息，结果导致客户流失、口碑受损。
- 它不是普通的公告模板：技能内置了一套九段式 EOL（End of Life，生命周期终止）消息框架，从公司背景、公告、原因、当前产品背景、客户影响、过渡方案、支持措施、时间线到行动号召，逐段约束写作质量。
- 它把“同理心”写进了结构里：要求在证明决策合理之前，先承认客户受到的中断，并明确列出迁移支持，避免“通知一发、客户自生自灭”。
- 它同时是一份避坑清单：技能明确列出“以业务为中心”“时间线模糊”“无支持计划”“忽视客户影响”“语气简洁防御”等反模式，并给出修复方式。
- 上手成本低：只要你能说清楚“停用什么、为什么、替代方案、影响、时间线、支持计划”，剩下的结构组织和措辞由技能完成。
一、该技能叫什么？如何下载安装 AI 技能提升开发效率？
1.1 基本信息
| 项目 | 内容 |
|---|---|
| 技能中文名 | 产品终止消息撰写技能 |
| 技能英文名 | eol-message |
| 技能 ID | 11375 |
| 技能类型 | 组件型（Component）技能 |
| 建议文件名 | eol-message.md |
| 建议放置位置 | /skills/components/ |
1.2 它到底解决什么问题？
产品下线、功能停用、旧平台迁移、被收购产品淘汰、API 弃用——这些时刻企业必须对外发一封通知。现实中的通知往往走向两个极端：
- 过于冷冰冰：“我们将在某月某日停用产品 X，感谢您的使用。”客户读到的是被抛弃。
- 过于自我中心：“为降低成本并整合产品组合，我们决定关停产品 X。”客户读到的是“你们的成本比我重要”。
这两类消息直接对应两个后果：流失率上升和品牌信任下降。而 eol-message 技能的定位非常明确——它不是“通用的日落公告生成器”，而是以客户为中心的沟通工具：承认损失，同时把变革框定为进步，并给出清晰的前进路径。
1.3 如何“一键安装”这个技能
AI 技能的安装方式因平台而异，具体命令、入口地址与目录规范请以你所使用平台的官方说明为准。通用的安装思路如下：
第一步：确认安装前提
- 你已拥有一个支持“技能（Skill）”机制或自定义指令的 AI 助手环境；
- 环境支持加载 Markdown 格式的技能定义文件（本技能建议文件名
eol-message.md）； - 若平台支持目录结构，建议放置到
/skills/components/下，便于被主流程调用。
第二步：执行安装
- 若平台提供技能市场或技能库入口：在搜索框中检索技能名
eol-message或技能 ID11375，点击安装/启用即可，具体检索与安装入口以官方说明为准； - 若平台支持导入技能文件：将技能定义内容保存为
eol-message.md，上传或放入指定技能目录，随后在配置中启用； - 若平台通过提示词注入：把技能正文作为系统级指令或常驻上下文载入，并在会话中显式声明“使用 eol-message 技能”。
第三步：验证是否生效
- 输入一句测试请求，例如：“用 eol-message 技能，为我们将于年底停用的旧版工作流产品写一封客户通知”；
- 观察输出是否呈现“公司背景 → 公告 → 原因 → 当前产品背景 → 客户影响 → 过渡解决方案 → 支持措施 → 时间线 → 行动号召”的完整结构；
- 若输出缺少“客户影响”或“支持措施”段落，说明技能未被正确加载，请回到第二步检查。
第四步：补齐依赖（可选但推荐）
技能说明中提到它与三个相关技能协同工作：positioning-statement（定位声明，用于过渡方案段）、problem-statement（问题陈述，用于客户影响段）、proto-persona（原型用户画像，用于定义受影响客户）。如果你的平台支持多技能组合，建议一并启用，输出会更完整。
二、该技能的主要功能和特点
2.1 核心能力
- 九要素 EOL 消息框架：技能把一封合格的终止通知拆成九个必须回答的问题——公司背景、公告、原因、当前产品背景、客户影响、过渡解决方案、支持措施、时间线、行动号召。写作者只需逐段填内容，不必从零构思结构。
- 同理心优先的叙事顺序：技能明确要求“在证明决定之前承认客户中断”。也就是说，先讲“我们知道这会给你带来什么麻烦”，再讲“为什么这个变化对你有好处”，避免变成单向通知。
- “以客户利益为中心”的原因改写：把“我们降低成本”翻译成“我们把 100% 的工程资源投入到你要求的功能上”。技能给出正反两种写法，防止写成内部汇报口吻。
- 当前产品背景段落：要求承认“正在失去的东西”——产品是什么、服务了谁、服务了多久、提供了什么价值。这一段是很多企业公告完全缺失的，也是让客户感到被尊重的地方。
- 定位声明格式的过渡方案：技采用结构化表达：“对于【受影响的客户】/ 目前使用【旧产品】/ 【新产品】/ 是一个【类别定义】/ 它【对用户的益处】”，并额外要求“差异化与连续性”段落，说明新方案保留了旧产品的哪些关键好处，同时新增了什么。
- 时间线与支持措施的双重保障：强制要求给出具体日期（公告日、迁移工具可用日、功能冻结日、完全关闭日、数据导出截止日）与具体支持动作（一对一迁移协助、自动迁移、折扣、培训资源）。
- 反模式与陷阱清单：技能列出五类典型错误及其“症状—后果—修复”三段式说明，包括以业务为中心、时间线模糊、无支持计划、忽视客户影响、简洁或防御性语气。这相当于给写作过程加了一层自动质检。
- 清晰的适用边界：技能明确说明什么时候不该用——小功能调整不必过度沟通、过渡计划尚未成型前不要发通知、不要抱着“希望客户没注意到”的心态。这种“反场景”说明在同类工具中并不常见。
- 配套文件指引：技能提供
template.md作为完整填充结构、examples/sample.md作为完整范例，降低首次使用的门槛。
2.2 和普通工具比，强在哪
普通的公告模板工具只提供“格式骨架”，不约束内容质量；通用大模型能写通顺文字，但很容易写出“以业务为中心”的段落，也不会主动提醒你“数据导出截止日期还没定”。eol-message 的差异在于：它把产品生命周期沟通的最佳实践固化成了结构、顺序和检查项，输出的不仅是文字，而是一份可直接进入评审的沟通方案。
三、如何使用该技能？
步骤 1：收集上下文（这是最关键的一步）
在动笔之前，先把六类信息准备好：停用对象、替代方案、关键时间线、客户影响面、支持计划、真实原因。技能里有一句非常硬的话：如果你还没有完整的过渡计划，就不要发消息——因为客户一定会问“那我现在该怎么办”。
示例输入（可参考此格式提交给 AI）：
我们是一家服务 5 万家小企业的工作流自动化平台。将在 2026 年 12 月 31 日停用“经典版”，迁移到“专业版”。 原因：经典版运行在过时基础设施上，限制性能与扩展性；专业版基于现代技术，自动化执行快 3 倍，新增 50+ 集成与实时协作。 影响：约 2 万家客户需要迁移工作流、学习新界面、更新自定义集成与 API 连接。 支持：一对一迁移协助、经客户批准的自动迁移、现有客户 3 个月折扣、培训资源。 时间线：2026 年 3 月 1 日迁移工具上线；9 月 1 日经典版转为只读；12 月 31 日完全停用并截止数据导出。
步骤 2：触发技能并生成叙述骨架
在对话中显式指明使用 eol-message 技能，要求先输出“公司背景 + 公告 + 原因 + 这意味着对你”四段。这一段的产出决定了整封信的基调。
步骤 3：生成“当前产品背景”与“客户影响”
要求技能补上“我们的产品是什么、服务了谁、服务了多久”，以及“我们理解这可能会影响你通过……”三条具体影响。注意：影响必须具体到工作流层面，不能写成“可能带来不便”这种空话。
步骤 4：生成过渡解决方案（定位声明 + 差异化与连续性）
使用技能内置的定位声明格式输出。参考产出效果（示例）：
对于 小企业主 / 目前使用 Acme 工作流经典版 / Acme 工作流专业版 / 是一个 下一代工作流自动化平台 / 它 保持了你喜爱的所有简单性和可靠性，同时增加了 3 倍更快的性能、50+ 个新集成和实时协作。
差异化与连续性：像经典版一样，专业版提供无需编码的易建自动化、可靠执行和直接定价；同时提供 3 倍更快的工作流、移动端访问、实时团队协作与 Slack、Asana、Notion 等工具集成。
步骤 5：补齐支持措施、时间线与行动号召
要求输出具体日期清单和具体支持动作，并给出“下一步做什么 + 找谁”的联系方式。技能还附带质量检查项：前置期是否足够（通常 6–12 个月）、里程碑是否清晰、是否写明数据导出截止日期。
步骤 6：按反模式清单自查
把生成结果对照技能里的五类陷阱逐条核对：原因是否变成了内部成本视角？时间线是否出现“很快”？是否缺少支持段落？是否跳过了客户影响直接推销新产品？语气是否防御？发现问题就要求 AI 定向重写对应段落。
步骤 7：定稿与分发
确认无误后，把同一份内容拆成邮件、站内公告、帮助中心文章、销售话术四个版本，保持事实一致。
四、同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| eol-message（本技能） | 以客户为中心的产品终止消息撰写组件 | 九要素框架、同理心优先叙事、定位声明式过渡方案、反模式清单、质量检查项 | 低：加载技能定义文件即可，需准备完整的过渡上下文 | 产品/功能/API 停用、平台迁移、收购整合淘汰 | 优势：结构完整、内置避坑清单、直接可用；不足：强依赖前置信息，信息不全时无法代劳决策 |
| 通用大模型直接对话 | 通用写作助手 | 任意文本生成，可临时给指令 | 极低：打开对话框即可 | 临时应付、内部草稿 | 优势：灵活；不足：默认容易写出“以业务为中心”的口吻，缺少时间线与支持段落，质量不稳定 |
| 传统公告/邮件模板库 | 静态文案模板 | 提供固定格式与占位符 | 低：复制粘贴填空 | 结构简单的常规通知 | 优势：上手快；不足：无同理心设计、无过渡方案结构、无法根据场景调整语气 |
| 客户成功/危机沟通剧本（人工咨询） | 方法论 + 顾问服务 | 定制化沟通策略、留存方案 | 高：需要排期、预算与内部评审 | 高风险的重大产品停用 | 优势：深度定制、可结合业务数据；不足：周期长、成本高，不适合中小团队高频使用 |
选择建议：日常或中等规模的产品停用，用 eol-message 技能即可独立完成；涉及大量营收与核心客户的重大停用，可先用技能产出标准初稿，再交由客户成功团队或外部顾问做二次加工。
五、该技能的典型应用场景与实际体验情况
场景一：SaaS 产品经理停用旧版产品线
角色与痛点：产品经理要发一封停用通知，但内部只关心“什么时候关”，没人关心“客户读到什么感受”。写出来的初稿往往是一段冷冰冰的时间表。
使用方式：按步骤 1 提交上下文，让技能生成九段式初稿，再补齐支持措施与时间线。
实际体验：上手难度低，第一次用也能拿到结构完整的初稿。效果最明显的部分在“客户影响”段落——技能会强制你写出三条具体中断，这往往是团队此前完全忽略的内容。注意事项：如果时间线还没定，技能会反过来提示你先定计划，这时不要强行让它编日期。
场景二：技术团队弃用旧 API 或技术栈
角色与痛点：开发者关系或技术负责人要给外部集成方发弃用通知。开发者最怕“说关就关”，没有迁移窗口和兼容说明。
使用方式：把 API 名称、替代接口、版本冻结日、下线日、迁移文档链接作为上下文输入，用技能生成“差异化与连续性”段落，说明新接口保留了哪些调用方式。
实际体验：技能的结构天然适配这类沟通，尤其是“数据导出截止日期”这一强制项，能有效避免开发者在最后一天才发现取不到数据。注意事项：技术细节（如接口签名变化）仍需人工补充，技能负责的是沟通框架而非技术文档。
场景三：收购整合中淘汰被收购方产品
角色与痛点：两套产品合并，被收购方客户天然敏感，任何措辞都可能被解读为“我们被抛弃了”。
使用方式：重点使用技能中的“公司背景”与“当前产品背景”两段，先承认原产品的价值与服务历史，再谈整合带来的资源集中。
实际体验：这两段的设计明显借鉴了危机沟通的“承认—解释—行动”原则，能有效降低对立情绪。注意事项：涉及品牌归属的表述要经法务与市场确认，不要直接采用生成稿。
场景四：客户成功团队降低过渡期流失
角色与痛点：客户成功经理需要在通知发出后跟进，但手头没有统一的沟通口径。
使用方式：把技能产出的通知进一步拆解为“常见问题回答”与“销售/客服话术”，保证所有触点口径一致。
实际体验：这一步的收益很直接——技能内建的“支持措施”段落本身就是一份可执行的留存清单（一对一协助、自动迁移、折扣、培训），客户成功可以直接照着排期。注意事项：折扣与补偿属于商务决策，需内部审批后再写入正式通知。
六、该技能能为用户带来的价值
- 效率提升：一封完整的产品终止通知，过去需要产品经理起草、市场润色、法务审核、客户成功补充支持计划，来回数轮；使用技能后，结构与措辞在几分钟内成型，团队只需聚焦在事实确认与商务决策上。
- 门槛降低：不需要读过危机沟通方法论，也不需要临摹优秀范例。技能把“同理心优先”“客户利益导向”“支持导向”这些抽象原则，直接变成了九个必须填写的段落和一份反模式清单。
- 风险可控：五类典型陷阱（业务中心、时间线模糊、无支持计划、忽视影响、防御性语气）每一项都对应真实的流失诱因。提前规避，就等于减少了一次大规模客户投诉或集中退订的可能。
- 长期价值：产品生命周期管理是持续动作——今天的旧版下线，明天就是另一个功能的日落。技能沉淀出的模板与话术，可以成为团队的标准资产，让每一次“说再见”都保持同样的专业度与温度。
- 品牌信任的复利：客户会忘记你上线了什么功能，但会记得你在关停产品时是否尊重过他们。一封写得好的终止消息，往往比十篇产品发布稿更能建立长期信任。
七、常见问题 FAQ
Q1：这个技能怎么安装？我没有技术背景能搞定吗？
安装的核心是把技能定义文件（建议文件名 eol-message.md）加载到支持技能机制的 AI 环境中，或直接在对话中声明使用该技能。如果你的平台提供技能库，按技能名 eol-message 或技能 ID 11375 检索并启用即可。具体入口与命令请以你所使用平台的官方说明为准。整个流程不需要写代码。
Q2：使用这个技能收费吗？
技能本身是一份结构化的写作方法与提示定义，不涉及独立的订阅或计费。你实际产生的费用取决于所使用 AI 平台的计费方式，请以该平台的官方说明为准。
Q3：它适合谁用？只有产品经理需要吗？
主要使用者包括产品经理（产品/功能停用）、开发者关系与技术负责人（API 弃用）、客户成功经理（过渡期留存）、市场与品牌（对外口径统一），以及并购整合项目负责人（被收购产品淘汰）。只要你的工作需要向客户传达“某个东西要停了”，它都适用。
Q4：和直接在通用大模型里说“帮我写一封产品停用通知”有什么区别？
通用大模型能写出通顺的文字，但默认口吻往往偏内部视角，也容易漏掉关键要件——尤其是“客户影响”和“数据导出截止日期”。eol-message 的差异在于用结构强制覆盖这些要件，并附带一份反模式清单用于自查。你可以把通用大模型理解为“会写字”，把这个技能理解为“知道这类信该怎么写才不会伤人”。
Q5：如果我们的产品停用后没有替代方案，还能用吗？
可以使用，但要注意技能里的一条重要前提：在你拥有完整的过渡计划之前不要发送消息。没有替代产品时，“过渡解决方案”段落应改为“数据导出与迁移协助”方案，并明确说明客户如何取回自己的数据、可以获得多长时间的支持。如果这两件事都还没想清楚，先别写通知，先做计划。
Q6：小功能调整也要用它吗？会不会过度沟通？
不需要。技能本身明确写了“何时不使用”：小功能调整不要过度沟通，也不要在还没有支持方案时提前通知。它面向的是真正影响客户工作流的产品级、功能级或接口级停用。