Product-Manager-Skills 的 EOL 六阶段流程编排：如何有步骤地“失去产品而不失去客户”

• AI 技能
• AI 插件

导读

eol-process是 Product-Manager-Skills 仓库中 Lifecycle & EOL 套件的流程编排型（workflow）技能：它把一次完整的产品退市（product sunset / End-of-Life）拆成六个带决策点（Decision Point）的阶段，从 go/no-go 决策一直走到退市后复盘，并指明每一阶段应调用哪个独立子技能来产出对应产物。它的适用范围从"一周内完成的轻量功能下线"一直扩展到"跨季度执行的受监管硬件退市"——核心宗旨只有一句话：lose the product without losing the customer（失去产品，但不要失去客户）。读完本文，你将掌握六阶段结构、强度分级（Level 1-3）的缩放逻辑、中途介入的故障诊断方法，以及如何用一页模板追踪一次正在进行的退市。

技能定位：编排者，而非替代品

主文档 skills/eol-process/SKILL.md 的 frontmatter 定义了这个技能的性质：

• type: workflow—— 它属于流程编排类技能，而非产出单个文档的组件类技能；
• theme: eol-transition—— 属于退市过渡主题；
• argument-hint: "[product being retired, and where you are in the process]"—— 调用时只需说明"退市什么产品 + 目前进展到哪一步"；
• estimated_time: "30-60 min to plan; weeks to quarters to execute"—— 规划耗时约 30-60 分钟，执行期从数周到数季度不等。

在仓库的 docs/Lifecycle and EOL Suite Summary.md 中，整个套件被分为两条线：上游product-lifecycle（2 个技能，负责"extend / replace / retire"的玩法决策）与下游eol-transition（6 个技能，负责执行退市），eol-process正是后者的总编排。

技能自我声明了三条边界，值得在动手前记住：

1. 它不是项目计划—— 它编排的是决策与产物的顺序，不是任务与资源的甘特图；
2. 它不是强制的全套仪式—— 一个 Level 1 的下线非要跑满六个阶段，正是这套技能想防止的"仪式失败"；
3. 它不是对话的替代品—— 阶段 2 的本质是人与人的沟通，不是一份文档。

关键原则：它是"路线（route）"，不是"流水线（pipeline）"。每个子技能都独立可运行，本流程只是在它们之间推荐一条经过验证的走法。

核心概念一：六阶段与六个决策点

主文档给出了一张贯穿全文的阶段总表，这是整个技能的灵魂骨架：

配套套件总结文档给出了每个阶段对应的子技能映射：阶段 1 →eol-readiness-advisor，阶段 2 →eol-stakeholder-sequence，阶段 3 →eol-checklist，阶段 4 →eol-internal-enablement，阶段 5 →eol-message，阶段 6 → 由本技能自身承担。

主文档反复强调一个反直觉的事实：阶段 6 是所有人都会跳过的那一个，但它恰恰是让下一次退市更便宜的那一个。要在规划期就为它留预算，因为退市结束后没有人会自愿回来补做复盘。

每个阶段末尾都有一个"决策点"（DP1-DP6），它们共同构成了这套流程的刹车与转向机制——其中两个被认为承载了绝大部分价值（套件总结原文）：

• DP2（对齐之后）：有没有什么东西让决策失效？在这里回到阶段 1 是便宜的；在阶段 5 公告之后才发现同一件事，代价完全不同。
• DP4（准备之后）：赋能真的完成了吗？这是公告的闸门。检验方法是随便问一个销售代表：遇到流失威胁客户时你会打给谁？

核心概念二：路线而非管道 —— 可从任意阶段进入

主文档用"recommended route through independent stops"（经过独立站点的一条推荐路线）来描述这套流程，而非"conveyor belt"（传送带），由此推导出三条使用规则：

• 可在任意阶段进入：决策已做出且站得住脚？直接从阶段 2 开始。
• 可根据强度等级跳过阶段：Level 1 的退市通常可以把阶段 2-4 压缩进一个下午。
• 可以（而且有时必须）往回走：阶段 2 经常把流程送回阶段 1——一条法务发现或一项销售承诺就可能让决策失效。这是流程在起作用，而不是失败。

同时，阶段之间不传递任何格式化的交接物（"Nothing hands off a format"）。携带上下文的方式就是在调用下一个技能时说"Level 2"并把已有内容粘过去——不需要维护任何 schema。这正是套件总结文档中"独立性（Independence）"一节的立场：每个技能独立成章，eol-process只是推荐走法，不做机械排序。

核心概念三：把整个流程调成与退市规模相称（Right-Sizing）

并非所有 EOL 都一样。主文档给出了一张贯穿全局的强度分级表，它同时是"强度拨盘（right-sizing dial）"的原始出处，也是后续每个子技能各自复用的表：

两条纪律（主文档原话）：

• Level 2 是默认值：在阶段 1 定下等级，让它决定下游所有阶段的规模；
• 永远不要默认 Level 3：在小退市上搞流程表演，会教会所有人无视大退市上的流程。

值得交叉印证的是，这个"强度拨盘"贯穿了整个套件：在 skills/eol-readiness-advisor/SKILL.md 中它是"you set, not a verdict the framework hands you"（由你设定的拨盘，而非框架塞给你的结论），并允许用户中途下调——但必须附带一句话说明下调后哪件事会失去覆盖（通常是最需要留意的法务审查、渠道通知或迁移支持）；skills/eol-checklist/SKILL.md 则给出每个等级对应的功能领域数（4 / 11 / 15），并允许在构建中途因法务行暴露问题而加码（"Actually make this heavier" 是正常反馈）。

核心概念四：中途进入的故障诊断（Entering Mid-Stream）

大多数人是在一次已在进行中的退市里——而且往往是遇到麻烦的退市里——才找到这个技能的。症状与"被跳过的阶段"存在明确映射，主文档给出了这张诊断表：

这张表也是本技能在"救援已在进行中的退市"这一场景下的核心价值所在。

核心概念五：会话式执行的交互协议

主文档指明：当以对话方式运行任何一个阶段时，使用 skills/workshop-facilitation/SKILL.md 作为交互协议——先给预告（heads-up）、接收上下文倾泻（context dump）、提供编号选项、允许参与者直接跳到某个具体阶段。这一点在 skills/eol-readiness-advisor/SKILL.md 的 Application 一节同样被重复声明，说明它是整个套件的通用约定。

此外，主文档还列出了四条反模式（what this is NOT），用于校准预期：不是项目计划、不是必须全套执行、不是对话的替代品、不是单向的（回到阶段 1 是成功条件而非回滚）。

六阶段逐段详解

以下内容完整继承主文档的阶段骨架，并融入各子技能源码中的实现细节与调用链。

阶段 1：Decide —— 该不该退、规模多大

阶段问题：Should we retire this, and how big is this?

活动：

1. 诚实地命名触发点（trigger）——一个指标、一次战略转向、一笔成本投诉，或一句高管随口之言。触发点预测失败模式；
2. 把退市信号与保留信号（retire vs. hold signals）摆到一起比较。两个以上强退市信号才算真案例；而一个义务锁定（obligation lock）或一个缺失的落点（landing place）可以压过所有退市信号；
3. 设定强度等级：先从爆炸半径（blast radius）给出推荐，再刻意做出选择——它会决定后续每个阶段的规模；
4. 确认落点：替换（replacement）、迁移（migration）还是体面退出（graceful exit）——以及它是否已就绪。

调用：eol-readiness-advisor。

产出：

• 结论：Go（去）、Go-with-conditions（有条件地去）、Hold（暂缓）或 Harvest（收割）；
• 强度等级（1/2/3）；
• 一个有名称的落点及其就绪状态；
• 公告前需核查的义务清单。

决策点 1（DP1）：这是 Go 吗？落点是真实的吗？

• Go→ 进入阶段 2；
• Go-with-conditions→ 进入阶段 2，并把该条件作为阶段 5 的门禁携带下去；
• Hold→ 停下，设定复访触发点，考虑更便宜的替代动作（仅 End of Sale、价格调整、修 bug）是否已满足实际需求；
• Harvest→ 停止投资而非停止产品，设定复查日期。

硬性规则：落点未就绪时，可以推进阶段 2-4，但不得推进阶段 5——不要公告一个你尚无法支持的迁移。

从子技能源码补充：eol-readiness-advisor通过最多 4 个自适应问题完成评估（在什么、爆炸半径、设强度、客户落点），并明确"路径就绪度是 go/no-go 的输入，不是细节"——一个对这些特定客户尚未达到功能对等的替换品，还不算落点。其交付物结构包含 verdict、intensity、confidence、The Case to Retire、The Case Against、Assumptions I Made、Obligations to Check Before Announcing、Landing Place 与 What This Level Covers—and Doesn't，其中"我做的假设"一节专门收纳所有回答"我不知道"的项，带有三个标注假设的评估胜过一次从未发生的评估。此外它定义了四类退市信号（财务可行性、战略对齐、方案替换、市场无关性）与四类保留信号（义务锁定、战略人质、无落点、退出成本超过持有成本）。

阶段 2：Align —— 谁能叫停，他们知道什么

阶段问题：Who can stop this, and what do they know that we don't?

活动：

1. 给干系人站排序：Legal、Finance、Sales、Marketing、CS、难缠客户、Engineering、Support——按等级过滤，Level 3 再追加 Executives、Channel、Regulatory；
2. 对每个站，准备好你需要从他们那里获得什么、以及你欠他们什么；
3. 按顺序进行对话——每一场对话都滋养下一场；
4. 记录浮出水面的东西——尤其是现场承诺、合同条款和隐藏依赖。

调用：eol-stakeholder-sequence。

产出：

• 一张每站都有产出的完整顺序表；
• 一张发现的承诺/义务/依赖清单；
• 一份来自最难缠客户的修订版影响清单。

决策点 2（DP2）：有什么东西让决策失效了吗？

这是整个流程中最重要的一道闸门，也是最常被当成走形式的那一道。

• 无阻塞→ 进入阶段 3；
• 合同、法规或承诺阻塞了时间线→ 回到阶段 1，用新证据重新评估。日期后移、范围改变或结论翻转；
• 落点比想象中更弱→ 回到阶段 1。这是最常见的发现，通常来自难缠客户那一站。

在这里回到阶段 1 是便宜的；在阶段 5 之后才发现同一件事，就不是了。

子技能源码补充了排序背后的"排序原则"：先跟能杀掉计划的人谈，再跟需要执行计划的人谈（"Talk to the people who can kill the plan before you talk to the people who have to execute it"）。法务曝光优先（一个合同条款就能终结讨论）、财务影响其次（它给下游一切定规模）、然后是收入侧团队、客户侧团队，最后是执行的技术团队。顺序搞反——先通知 Support、最后才找法务——等于让四十个人知道一个被一条合同条款就能作废的计划。每站的五字段结构为：When / Why this stop matters / What you need FROM them / What you owe TO them / Red flags to watch for，且必须声明该站的输出——没有输出的站只是状态更新。另一个反直觉设计是把最难缠的客户放进顺序表：最会开工单、QBR 上最强势的客户，恰恰拥有最深、最怪的用法，他们会找出你忘记的集成、没人读过的合同条款、在替换品里没有对应物的工作流——你可以现在在预约电话里从他们那里学到，也可以日后在公开论坛上从他们那里学到。

阶段 3：Plan —— 做什么、何时、谁负责

阶段问题：What has to happen, when, and who owns it?

活动：

1. 圈定纳入范围的生命周期门禁——并点名刻意不用的那些；
2. 按阶段、按功能领域、按你设定的等级构建条目。每条目：一个动词、4-8 个词、一个具名的责任职能；
3. 为每个阶段转换（Level 2+）写出带审批人的门禁标准；
4. 覆盖退市最常搁浅的四样东西：数据、合同、访问、钱；
5. 把阶段 4 的"赋能完成"日期放到计划上，必须在阶段 5 公告日期之前。

调用：eol-checklist。

产出：

• 一张带负责人和日期的分阶段检查清单；
• 带具名审批人的门禁标准；
• 已落实归属的退市后动作，包括阶段 6 复盘；
• 待验证的假设。

决策点 3（DP3）：每个条目都有人负责吗？每个日期都真实吗？

• 存在无人负责的条目→ 这就是发现本身。升级处理，而不是糊弄过去；
• 无法辩护的日期→ 写TBD，或写Not scheduled并附上前置条件。编造的 EOL 日期是一个你会在公开场合打破的承诺；
• 赋能日期不在公告日期之前→ 现在就修；实践中两者常常坍缩成同一天。

子技能源码补充：eol-checklist在生命周期门禁上做了重要澄清——GA 是状态而非工作阶段，EOR 由合同驱动、仅当续约在局时出现，因此工作清单通常覆盖六个可行动阶段NSC, EOS, EOE, EOM, EOL, EOSRV（EOR 在订阅或服务合同跨过 EOS 时插入）。其十五个功能领域按等级过滤（Level 1 四项：产品与战略、工程与技术、支持、文档与培训；Level 2 追加法务、财务、销售、市场、客户成功、IT 系统、数据管理；Level 3 追加库存与供应链、渠道与伙伴、监管与合规、内部组织对齐）。"无主条目即愿望（an unowned item is a wish）"是该技能的核心纪律——当你无法给"通知渠道伙伴"命名负责人时，你刚刚发现的是：这件事没有人负责。门禁的定义是"进入下一阶段前必须为真的条件 + 审批人"，例如"EOS 到 EOE：last-time-buy 订单全部关闭 —— 审批人：销售 VP"，这让 EOL 不再是"一次公告 + 六个月后有人悄悄拔插头"。检查清单还必须覆盖四条"最常被搁浅"项：数据（导出格式、可用窗口、删除计划）、合同（续约措辞、SLA 条款、应退款项）、访问（API 密钥、集成、SSO、读取它的下游系统）、钱（预测调整、收入确认、退市本身的成本）。

阶段 4：Prepare —— 客户听到之前，自己人准备好了吗

阶段问题：Are our people ready before our customers hear?

活动：

1. 构建支持 FAQ，按客户真正会问的内容组织，呼叫量最高的排最前；
2. 构建销售话术，带一张诚实的对比表——包括差距；
3. 用 Acknowledge-Reframe-Offer（承认-重构-给方案）写异议处理，每个方案都预先审批过；
4. 命名升级梯——四级、真人；
5. Level 3 时追加渠道伙伴简报，并带角色扮演做现场培训。

调用：eol-internal-enablement。

产出：

• 一个按等级定规模的赋能包；
• 一条销售代表在周五下午 4 点也能用的升级梯；
• 公开通知前已被告知的伙伴（Level 3）。

决策点 4（DP4）：赋能真的完成了吗？

这道闸门卡着公告。EOL 沟通的原罪，是让 Support 和 Sales 在客户收到消息前五分钟才拿到公告。

检验方法：随便问一个销售代表遇到流失威胁会打给谁，并要求他出声回答最难的那个异议。任何一个答案是耸肩，你就还没准备好公告。

子技能源码补充：eol-internal-enablement给出 FAQ 的六个恒定问题顺序（发生了什么 / 对我意味着什么 / 我有哪些选项 / 我的数据怎么办 / 我的合同怎么办 / 支持何时结束），并明确"我们正在评估选项"不是答案，而是客户会听成推诿的拖延。异议处理的三拍结构顺序是有讲究的——压力下的团队会直接跳到 Offer（听起来像贿赂）或直接 Reframe（听起来像说教），先 Acknowledge 才能让后两者落地，而且它不花任何成本。五个可预测异议（"我们刚买了/上个季度刚续约""替换品没有功能 X""我们要整体离开""我们凭什么信任你的下一个产品""能给我们破例吗"）要先写好草稿再问还有哪些；其中第四个最难答，因为诚实的答案是关于你如何处理这次过渡——当前这次退市就是下一次承诺的证据。升级梯的四级是 Level 1 标准问题（Support）、Level 2 不满客户（Support 负责人或 CS）、Level 3 流失风险账户（CS 负责人或客户经理）、Executive（具名账户、媒体、法律威胁）——没有名字的升级路径只是一张示意图。

阶段 5：Announce —— 客户听到什么、何时听到

阶段问题：What do customers hear, and when?

活动：

1. 给消息定规模：Brief / Standard / Full；
2. 选择路径：替换 / 迁移 / 体面退出——每条路径产出不同的消息；
3. 按九段式框架起草，先承认影响，再谈收益；
4. 用客户能理解的后果语言表述门禁，而不是内部缩写；
5. 应用便利贴测试：读一遍之后，客户能否写下"要做什么、截止何时"？
6. 在必要处做分群——企业、SMB、高风险账户和伙伴需要不同的东西。

调用：eol-message。

产出：

• 定过规模、定过路径的客户公告；
• 必要时的分群变体；
• 一张跨越各门禁的沟通日历，而不是一次性群发。

决策点 5（DP5）：公告能在接触客户后活下来吗？发送前检查三件事：

• 法务读过它——尤其是涉及合同、退款或认证的内容；
• 它不与客户被销售时的承诺矛盾——对照阶段 2 的现场承诺；
• Support 先拿到它——留足提前量读完。

子技能源码补充：eol-message的九段式框架为：1) Company context、2) The announcement、3) The rationale（客户受益视角）、4) Current product context、5) Customer impact（承认干扰）、6) Transition solution、7) Support measures、8) Timeline（关键日期与门禁）、9) Call to action。三条迁移路径的侧重点完全不同：Replacement 依赖连续性叙事（什么延续、什么改进，定位最重要）；Migration 依赖机制细节（客户必须做什么、何时、工作量多大——低估工作量是通往不信任的最快路径）；Graceful exit 依赖尊严（诚实理由、数据导出、慷慨通知、真实替代品包括竞争对手——点名一个竞争对手的成本，低于让客户滞留造成的声誉损失）。消息规模表：Brief 1-3 段（功能/内部工具）、Standard 一页带阶段表（商用产品）、Full 跨月多段加合规（收入关键/硬件/受监管）。门禁必须以客户语言定义——"你可以继续用，但我们不再发修复包"胜过"EOM：3/2027"。eol-message还引用了 skills/positioning-statement/SKILL.md 来支撑 Transition Solution 一节。

阶段 6：Close —— 做完没有、学到什么

阶段问题：Did we finish, and what did we learn?

活动：

1. 门禁到达即走查。每个转换都需要标准满足 + 审批人签字——门禁是承诺，不是日历条目；
2. 对照阶段 3 的目标跟踪迁移/过渡进度。对零进展的账户要早升级，而不是在最后一道门禁前才动手；
3. 完成收尾条目：数据导出窗口兑现、删除已排期、合同关闭、收入确认结束、基础设施退役、文档归档；
4. 运行经验教训复盘：什么让你意外、你在哪个阶段投入不足、难缠客户发现了哪些你漏掉的东西、实际留存对照预测是多少；
5. 对未排期的 EOL 日期，把前置条件移交给一个具名负责人并带复查日期。

产出：

• 带签字的已关闭门禁；
• 对照预测的最终留存/迁移数字；
• 一份成文的经验教训复盘；
• 任何延后决策被显式负责。

决策点 6（DP6）：这真的算关闭了吗？

关闭不是关机那天。关闭是：数据已删除或已交付、合同已结清、钱已确认入账、有人把发生了什么写了下来。如果复盘没跑，退市就没完成——它只是安静了。

主文档在此补充了两条针对性的提醒：阶段 6 是"人人都会跳过的一个"，也是"让下一次退市更便宜的一个"；同时对照 skills/eol-checklist/SKILL.md 的 Step 5——复盘是团队第一个砍掉、最后悔的条目，因为"当有人写下这次退市让你意外的东西时，下一次总是更容易"。

完整工作流一览（End-to-End Summary）

主文档给出的端到端总图完整继承如下（括号内为该阶段的负责技能）：

PHASE 1: DECIDE -> eol-readiness-advisor Trigger -> signals -> intensity level -> landing place DP1: Go / Go-with-conditions / Hold / Harvest 落点未就绪？阶段 2-4 可走，阶段 5 被阻塞 | PHASE 2: ALIGN -> eol-stakeholder-sequence Legal -> Finance -> Sales -> Marketing -> CS -> difficult customers -> Engineering -> Support (+ Execs, Channel, Regulatory at L3) DP2: 有什么让决策失效了吗？ --[是]--> 回到阶段 1 | PHASE 3: PLAN -> eol-checklist 圈定门禁 -> 带负责人的条目 -> 门禁标准 -> 数据、合同、访问、钱 -> 赋能日期在公告日期之前 DP3: 每个条目有人负责？每个日期真实？ | PHASE 4: PREPARE -> eol-internal-enablement Support FAQ -> 带差距的销售要点 -> 异议处理（方案已预批） -> 升级梯 -> 渠道简报 + 培训 (L3) DP4: 赋能完成？ --[否]--> 不得公告 | PHASE 5: ANNOUNCE -> eol-message 定规模 -> 定路径 -> 起草 -> 便利贴测试 -> 分群 -> 沟通日历 DP5: 法务读过？与现场承诺一致？Support 先拿到？ | PHASE 6: CLOSE -> (本技能) 走查门禁 -> 跟踪进度 -> 关闭数据/合同/钱 -> 经验教训复盘 -> 承接任何延后决策 DP6: 数据结清、合同关闭、复盘成文？

Level 1 压缩规则：阶段 2、3、4 常常合并为一次会议——一份短干系人清单、一张待办清单、一份支持 FAQ。但阶段 1、5、6 仍然要发生。尤其是 6。

实战工具：一页追踪器（template.md）

主文档的 Application 一节明确："Usetemplate.mdas the one-page tracker for a sunset in flight."（用 skills/eol-process/template.md 作为进行中退市的一页追踪器。）

模板的核心结构（完整内容见原文件）包括：

• 先设定等级（Set the level first）：顶部重申三级表，并注明"大多数退市是 Level 2，永远不要默认 Level 3"；
• 每个阶段一个区块，带Status: [ ] Not started / [ ] In progress / [ ] Done勾选、对应的负责技能名（Phase 6 无独立技能）、该阶段的输入字段，以及决策点勾选清单（DP1-DP6）；
• 阶段 3 区块内嵌"Enablement complete by [date] <-- must precede announcement"的显式约束；
• 阶段 6 区块包含 closure items 勾选清单（数据导出兑现、删除排期、合同结清、收入确认关闭、基础设施退役、文档归档、经验教训复盘成文、延后决策带负责人与复查日期）；
• 底部 "Assumptions to Validate"（待验证假设）区块；
• 质量检查（Quality checks）部分，四个维度各带勾选：Sequence（阶段 5 不是第一个产物、DP2 被当作真门禁、DP4 在计划上卡着 DP5）、Proportion（等级在阶段 1 设定并用于定规模、Level 1 没上 Level 3 仪式、跳过的阶段是刻意跳过的并记录了理由）、Honesty（没有为填空而编造 EOL 日期、落点状态如实记录包括"未就绪"、阶段 2 的现场承诺反映在阶段 5 消息里）、Closure（阶段 6 在阶段 3 就有具名负责人、复盘已写成而非只排期、任何未排期的 EOL 都有前置条件与负责人）。最后的落点是那句终极判词："Retention is tracked as the success measure — not checklist completion"（用留存作为成功度量，而不是清单完成度）。

两个互锁的工作示例：看清正走与回退

每个 Component 和 Workflow 技能都带两个领域示例，它们互锁成连续的故事（套件总结文档称之为"interlock into continuous stories"）。

示例一：Fieldlight Classic Dispatch（SaaS，Level 2，正向走完全程）

skills/eol-process/examples/sample.md 展示了"干净案例"：约 800 个账户、$2.4M ARR、年度合同、直销，被 Fieldlight Next Scheduling 替换，约 30 个账户的自定义调度规则无法迁移。决策阶段以"Go-with-conditions"开局（条件：30 个自定义规则账户在公告前需有具名计划），对齐阶段 8 站跑完，DP2 明确记录"Decision unchanged. Date held."——即使没有阻塞，把话说出来才是让门禁真实而非装饰的关键。公告阶段分群：全体账户邮件 + 30 个自定义规则账户由 CSM 提前 48 小时单独通知。收尾阶段：781/800 迁移、94% ARR 留存（目标 90%）。示例的"要留意什么（What to notice）"部分点出三个教训：自定义规则这条差距线贯穿了所有阶段（阶段 1 是条件、阶段 2 是风险、阶段 4 是带预批方案的异议、阶段 5 是分群发送、阶段 6 是 19 个流失账户中的 11 个）——"最可能伤害你的东西，应该能追溯着穿过每一个阶段"；留存而非完成度才是被报告的成果；复盘敢于批评产生它的流程——"迟到的一对一重建方案导致 11 个账户流失"正是阶段 6 的全部价值，一篇结论为"进行得很顺利"的复盘等于没做。

示例二：NFA-200 控制器产线（工业，Level 3，DP2 回退改变结局）

skills/eol-process/examples/sample-industrial.md 展示了回环：约 120 套安装、8 个渠道伙伴、服务合同到 2028 年、UL 508A 与 CE 认证，NFA-500 是继任者但需要不同的安装支架——每次迁移都是一次现场勘察。第一次阶段 1 的结论是 Go，但"落点就绪"是被假设而非验证的——这个假设正是阶段 2 打破的东西。对齐阶段 11 站中，法务暴露"服务协议到 2028 年不可终止"（义务锁定），工程暴露"NFA-500 不是 drop-in，支架工作约 9 个月且未拨款"（无落点）——DP2 两项检查全部失败，流程回到阶段 1。第二次阶段 1 的结论变成"Hold on EOL. Go on End of Sale."：EOS 能还回制造产线（这才是真实的内部诉求），却不用承诺一个守不住的关机日期；EOL 被记录为Not scheduled并附前置条件（验证过的改造路径 + 安装基数低于 20 台）。阶段 6 合法地开放到 2028 年——关闭是义务到期日，不是公告日；其中"Reassess the EOL precondition — Owner: Product, review each Q4"这条延后决策，防止了"not scheduled"悄悄变成"forgotten"。示例的观察点包括：第一次阶段 1 被标记为 Superseded 而非删除（错误结论的记录——尤其是"落点就绪"旁边那个未勾选的框——是追踪器里最有教育意义的一行）；把高管排在 Stop 5 而不是第 1 站，让他们在听到 4 场对话的证据后才提出要求，才使得"要 EOL、接受 EOS"成为可能；提前 25 天给伙伴做简报，浮出了一个正在投标 NFA-200 项目的伙伴。

常见陷阱（Common Pitfalls）

主文档列出六条，全部继承如下：

1. 从阶段 5 开始（Starting at Phase 5）：第一个被产出的东西就是客户公告。后果：公告之后才在公开场合、带着已承诺的日期发现合同条款、现场承诺和缺失的迁移路径。修复：公告排在第五个阶段是有原因的——它之前的一切都是为了让它活下来。
2. 把决策点 2 当走形式（DP2 as a Formality）：对话发生了、发现被记下了、计划原样推进。后果：你开了会却无视了它们，比跳过更糟——你现在有了警告过你的目击者。修复：DP2 是一道真门禁；法务或难缠客户浮出实质性内容就回到阶段 1 重新评估，这个循环就是流程在起作用。
3. 赋能完成前就公告（Announcing Before Enablement）：阶段 4 和 5 落在同一周，或阶段 4 滑期而阶段 5 不滑。后果：Support 临场发挥三天，他们的即兴发挥成为你事实上且互相矛盾的政策。修复：DP4 在计划上用独立日期卡住 DP5——赋能滑期，公告就滑期。
4. 小退市上的流程表演（Process Theater）：一个被弃用的功能拿到十个干系人站和一套培训。后果：所有人学会"EOL 流程是官僚主义"然后下次跳过——而下一次正是有合同的那次。修复：阶段 1 诚实地设定等级。一个在一个下午跑完并妥善关闭的 Level 1 退市就是成功。
5. 跳过阶段 6（Skipping Phase 6）：产品关停、团队转场、没人写下任何东西。后果：下一次退市重复每一个错误，数据删除和合同关闭条目悄悄搁浅。修复：趁人们还在乎的时候，把复盘以具名负责人的形式放进阶段 3 检查清单。关闭不是关机那天。
6. 产品丢了、客户也丢了（Losing the Customer With the Product）：每个阶段都执行得无可挑剔，却全部用内部完成度来衡量。后果：一次干净利落的退市 + 一次流失激增。修复：把留存当作成果度量而非清单完成度。目标始终是"失去产品而不失去客户"——如果后半句没发生，流程就不算成功。

相关技能与套件上下文

六阶段技能映射（相对路径均已换算为仓库根起点）

• 阶段 1 → skills/eol-readiness-advisor/SKILL.md
• 阶段 2 → skills/eol-stakeholder-sequence/SKILL.md
• 阶段 3 → skills/eol-checklist/SKILL.md
• 阶段 4 → skills/eol-internal-enablement/SKILL.md
• 阶段 5 → skills/eol-message/SKILL.md
• 全程交互协议 → skills/workshop-facilitation/SKILL.md
• 阶段 5 过渡方案 → skills/positioning-statement/SKILL.md
• 通用干系人映射（阶段 2 需要广度时）→ skills/stakeholder-mapping/SKILL.md

上游的玩法决策（extend / replace / retire）与套件全景见 docs/Lifecycle and EOL Suite Summary.md，发布说明见 docs/announcements/2026-08-10-v0-84-lifecycle-and-eol-suite.md。主文档引用的外部框架包括 Product Life Cycle（PLC，EOL 位于衰退期）、行业 EOL 生命周期实践（GA/NSC/EOS/EOE/EOR/EOM/EOL/EOSRV）以及 Acknowledge-Reframe-Offer 异议处理模式——这些用于理解行业背景，不构成本仓库的代码事实。

使用前提与限制

• 本技能是编排技能，不替代任何子技能；它告诉你该拿哪个、何时拿、推进前什么必须为真；
• 所有技能均独立可运行，无前置依赖，也无交接格式——携带上下文就是一句"Level 2"加粘贴已有内容；
• 等级设定（Level 1/2/3）是全局缩放开关，应在阶段 1 决定并在后续所有阶段复用；
• 强度与历时按当前仓库文档为准：Level 1 数天到数周、Level 2 约 6-12 个月、Level 3 约 12-24 个月，受监管硬件退市可更长（工业示例为约 30 个月且仍在进行）。

最后回到那句话：把"失去产品而不失去客户"留在脑子里走完全程——它后面的大多数内容，都是为了保护这句话的后半段而存在的。

• AI 技能
• AI 插件