用途
EOL Checklist 用于在“决定退役产品”已经作出之后，把这一决定转化成一份按阶段放行的运营计划：需要做什么、在生命周期的哪个阶段做、由谁负责。它的产出是一份可执行的清单，而不是战略文档。
清单规模与退役规模相匹配。一个被弃用的内部工具可能只需三个阶段、十几条事项；一条受监管的硬件产品线则可能需要六个阶段的跨职能作战手册，并在阶段之间设置放行条件。两种做法都对，用错规模才是失败。
主要能力
按规模分级 技能先把退役规模分为三档，并默认推荐第 2 档：
- 第 1 档（轻量）：适用于功能、内部工具、无版本 API。典型使用 2-3 个阶段，覆盖 4 个职能领域，不设放行条件，产出为待办清单。
- 第 2 档（标准，默认）：适用于有付费客户和合同的商业产品。典型使用 4-5 个阶段，覆盖 11 个职能领域，在主要阶段之间设置放行条件。
- 第 3 档（重）：适用于收入关键、硬件、受监管的产品。使用全部 6 个阶段，覆盖 15 个职能领域，每个阶段之间都有放行条件和审批人。
技能会给出推荐并说明理由，用户可自行上下调整；若用户选择更轻的档位，技能会指出被舍弃的具体领域，让选择是知情的。技能明确避免默认第 3 档，因为把重清单套在轻退役上会让团队把 EOL 流程视为形式主义。
生命周期阶段划分 涉及的阶段包括：NSC（状态变更通知）、EOS（停止销售）、EOE（停止扩容）、EOR（停止续约）、EOM（停止维护）、EOL（生命周期结束）、EOSRV（服务结束）。其中 GA 是一种状态而非工作阶段，EOR 仅在续约仍有效时插入。技能会明确列出未使用的阶段并说明原因。
十五个职能领域 按档位过滤，括号内为该领域出现的最低档位：产品与战略（1）、工程与技术（1）、支持（1）、文档与培训（1）、法律与合同（2）、财务规划（2）、销售（2）、营销（2）、客户成功（2）、IT 系统（2）、数据管理（2）、库存与供应链（3）、渠道与合作伙伴管理（3）、监管与合规（3）、内部组织对齐（3）。
便利贴规则 每条事项 4 到 8 个词，以动词开头，并指定一个负责职能（是职能而非具体个人的日程）。“法律审查合同”是合格事项；冗长的整段描述不合格。负责人是强制项，因为无主事项只是一厢情愿，强制每行指定职能能提前暴露跨职能缺口。
阶段放行条件是承诺而非日期 放行条件是“进入下一阶段前必须为真的事项 + 审批人”，例如“EOS 到 EOE：末次采购订单已关闭——审批人：销售副总裁”。这能避免 EOL 变成一次公告之后某天悄悄拔掉电源。
使用方式
输入方面，最好提供被退役产品及已承诺的日期；此外客户与收入规模、是否存在替代方案及其就绪度、合同或监管义务、是否涉及硬件/库存/渠道伙伴也很有帮助。随调用提供的内容（技能名之后的文本、粘贴的上下文或附加的 ARGUMENTS: 行）视为已回答，会被跳过不重复询问。若空手而来也可用，技能最多追问三个问题：退役的是什么及其规模、是否有替代方案、有哪些硬性截止日期，然后选定档位并构建。未知项会标注为假设而非阻碍。
构建步骤：
- 设定档位（根据影响范围推荐，并呈现三档供选择）。
- 选择适用阶段，并检查两个覆盖项：合同跨过 EOS 则插入 EOR；完全没有服务义务则去掉 EOSRV 并说明。日期确实未知时写 TBD；尚不应设定日期时（如迁移路径不存在）写“未安排”并加一条说明前置条件的事项。不要编造 EOL 日期。
- 按阶段、按领域构建事项，每条以动词开头、4 到 8 个词、指定负责职能，且只归属一个阶段（发生工作的阶段，而非公告阶段）。至少覆盖日落最常遗漏的四件事：数据（导出格式、可用窗口、删除计划）、合同（续约条款、SLA、退款或抵扣）、访问（API 密钥、集成、SSO、下游系统）、资金（预测调整、收入确认、退役本身的成本）。
- 编写放行条件（第 2 档及以上）：每个阶段转换列出必须为真的事项及签字人，每道闸门 3 到 5 条即可，说不审批人则闸门不成立。
- 补充 EOL 后动作与假设：始终包含简短的 EOL 后区块——归档、最终报告、经验教训复盘（团队最常砍掉也最常后悔的一项），并以需验证的假设收尾。
示例调用：
- “为我们的遗留报表模块做 EOL 清单，12 月 31 日关停，约 400 个账户。”
- “为硬件退役构建重清单——服务合同、8 家经销商、UL 认证。”
适用场景
当退役决定已经作出，需要一份运营计划时使用。技能内置反模式说明：它不是项目计划（没有甘特图、依赖图、资源加载），默认不追求穷尽（覆盖与风险成正比），不是决策本身（若是否退役仍有疑问，则为时过早），也不能替代实际沟通（一条“与法律对齐”的事项并不等于已与法律对齐）。
限制与注意事项
技能列出了常见陷阱：形式主义膨胀（每次都用 15 领域六阶段）、无主事项、编造日期、阶段塌缩（所有事都塞进一个“EOL”阶段）、遗忘下游读取方（那些静默调用其 API 的内部系统）。关联技能包括 eol-readiness-advisor、eol-stakeholder-sequence、eol-internal-enablement、eol-message，均非必需前置，也无交接产物。参考资料包括行业 EOL 生命周期实践、用于分配负责人的 RACI。Provenance：改编自 github.com/deanpeters/product-manager-prompts 仓库中的 prompts/eol-checklist.md。