企业官网建设流程全解析

• AI 技能
• AI 插件

导读

本篇文章以仓库根目录的10AUG26.md（v0.84 发布会话交接简报）为主线，剖析 Product-Manager-Skills 项目在 2026 年 8 月 10 日发布的Lifecycle & End-of-Life Suite（生命周期与停服套件）：7 个新技能 + 1 个技能升级、两处关键设计决策（"强度是用户拨盘"与"路线而非管线"）、门禁词汇体系的协调，以及一次 CI 覆盖盲区的彻底修补。读完本文，你将掌握该套件 8 个技能的分工与调用顺序、三个 Level 的右尺寸化（right-sizing）拨盘如何工作、8 个生命周期门禁与 6 个工作阶段的对应关系，以及仓库如何用check-dist-freshness.py这类工程手段防止"文档与产物漂移"。

一、v0.84 发布全景：70 → 77 技能的扩展路径

10AUG26.md是 v0.84 的会话交接简报，取代了09AUG26.md与docs/maintenance/2026-08-09-eol-suite-plan.md（在四点上有意偏离了原计划，见下文第三节）。它回答的不是"我们要做什么"，而是"实际上交付了什么"。

本次发布把技能库从70 扩展到 77，类型分布为28 Component（组件）、29 Interactive（交互）、20 Workflow（工作流），新增内容分为两个主题：

eol-transition主题（6 个技能）

product-lifecycle主题（2 个技能，计划外追加）

套件的统摄思想一句话概括（见 docs/Lifecycle and EOL Suite Summary.md）：

Lose the product without losing the customer.（可以失去产品，不能失去客户。）

在 eol-process 技能 的 Purpose 段落中，这句话被明确为"整个流程值得牢记的一句话"，并指出"以下内容大多是为了保护这句话的后半句而存在的"——一个在内部里程碑全部达成后仍然引发客户流失的停服，不能算成功。

配套的工程改动还包括：

• 新发布包07-lifecycle-eol-pack.zip，同时在两处登记：build-claude-desktop-packs.sh的包清单与build-dist.sh的拷贝循环及其生成的 README 表格；
• README 更新（badges、ASCII 横幅、文字计数、导航块、包表、文档表、What's New）；
• 发布说明 docs/announcements/2026-08-10-v0-84-lifecycle-and-eol-suite.md；
• 套件总结 docs/Lifecycle and EOL Suite Summary.md；
• catalog/重新生成（77 项）、dist/重新生成（77 个技能 ZIP、9 个包）；
• marketplace.json更新至 77 条并 bump 到 0.84.0，plugin.json更新至 0.84。

二、套件地图：八技能如何分工

上游：剧本决策（product-lifecycle 主题）

在"该不该杀"之前，有一个更大的问题——延长（Extend）、替换（Replace）、退役（Retire）三种玩法选哪个。按 docs/Lifecycle and EOL Suite Summary.md 的说明：

• lifecycle-play-advisor（Interactive）：通过一组"七个过渡问题"诊断产品所处阶段，再依据压力来源（需求侧 / 供应成本侧 / 能力侧）区分玩法。它默认偏向"解决真实压力所需的最便宜玩法"，并且愿意回答"nothing yet"——一个还在稳定产生利润的成熟产品不需要一个项目；
• product-lifecycle-plays（Component）：决策背后的框架本体——按阶段的 PLC 战略网格、三种玩法及其理由、七个替换风险（replacement hazards），以及最后一列必问"Plan B 是什么"的风险登记表，并附带跨整个产品线做决策的组合工作表（portfolio worksheet）。

三种玩法（同样来自套件总结）：Extend（最便宜、风险最低，却常因"不够刺激"被跳过）；Replace（上线继任者并逐步停掉旧产品，此时GTM 与 EOL 必须并行——两个互相竞争的产品；这是昂贵的玩法）；Retire（没有自家继任者，客户流向他处，可能包括竞争对手）。另外还有不是玩法的一个答案：harvest（收割）——停止投入、继续运行、设定复查日期。

执行链：退役落地（eol-transition 主题）

六阶段与两个"价值承载"门禁

eol-process 将整个停服组织为六个阶段，每阶段对应一个独立技能作为其工件产出者：

其中两个门禁承载了大部分价值（docs/Lifecycle and EOL Suite Summary.md）：

• DP2（Align 之后）——有没有任何东西使决策失效？在这里回到 Phase 1 代价很低；在 Phase 5 之后发现同样的问题代价高昂；
• DP4（Prepare 之后）——赋能是否真正完成？它门禁着公告（announcement）。检验方法：问一位客服代表"遇到流失威胁时你会给谁打电话"。

三、与原计划的四点偏离：本会话最重要的设计决策

原计划（09AUG26）被批准后又经 Dean 在场调整，10AUG26.md明确记录了四处偏离。这些偏离定义了套件的设计哲学，值得逐一展开。

1. 强度等级是"用户拨盘"，不是上游传参

原计划设想每个技能自行判定等级："（a）上游传入，或（b）自分类"。Dean 否定了这种耦合。**每个技能现在都推荐一个等级、呈现全部三个等级，并接受任意方向的覆盖——包括运行中途改档。**当用户选择比推荐更轻的档位时，技能会明确指出"更轻的选择会遗漏哪件具体的事"，从而让轻量化成为一个知情选择，而不是意外。

所有技能都声明Level 2 是默认值，且"永远不要默认 Level 3"。理由是从教学法出发（在 eol-process 与 eol-readiness-advisor 中均有原文）：

在一个小停服上搞"流程表演"，会教会团队在大停服上忽略流程。

eol-readiness-advisor的"Question 3 of 4 — Set the intensity"就是这一设计在交互层的最小实现：Agent 先给出Recommended: Level [N]与两三句理由，再逐条呈现三个等级，然后说"Take the recommendation, or pick a different level — you know your organization"，并允许中途再改。若用户拨低，Agent 必须补一句"Going lighter than recommended means [the specific thing that goes uncovered]"，让选择透明；若用户拨高，则直接接受、不作争辩（"Over-preparing an EOL is a cheap mistake"）。

三个等级的右尺寸化对照表（来自 docs/Lifecycle and EOL Suite Summary.md）：

2. 技能之间零紧耦合：路线（route），不是管线（pipeline）

Dean 的原话：

"let's not build this so there are tightly coupled dependencies between the skills, that breaks the mandate of this repo in general."

因此：每个技能都内联定义等级与门禁（重复文本，而非共享依赖），且每个 References 小节开头都声明"任一方向都不是前置条件"。eol-process是路线而非管线——它内置了"Entering Mid-Stream"诊断，把症状映射回被跳过的阶段，并明确写出"向后走（回退到更早阶段）是成功条件"。

eol-process中"Entering Mid-Stream"症状映射表（对正在崩坏的停服现场尤其有用）：

简报特别告诫：不要"修复"这一点而去引入交接 schema（handoff schema）。跨阶段携带上下文的方式就是"说 Level 2 + 粘贴你已有的内容"——这就是设计本身。

3. 词汇统一："Tier" → "Level"

已发布技能全篇使用Level 1/2/3（Light/Standard/Heavy），而原计划写的是 "Tier"。同一概念、同一词汇，保持下去。

4. 门禁词汇协调：8 个门禁 vs 6 个工作阶段

源提示词使用 6 个阶段，而第一阶段交付了 8 门禁词汇。协调结果在eol-checklist中显式落地：

• GA 是状态，不是工作阶段——GA 下没有可勾选的条目；
• EOR 是合同驱动的——仅当续约跑过 EOS 时才插入；
• 工作清单跨越NSC、EOS、EOE、EOM、EOL、EOSRV这 6 个阶段。

8 个门禁的完整词汇（来自 docs/Lifecycle and EOL Suite Summary.md）：

• GA— General Availability，活跃销售且完全支持（状态而非工作阶段）
• NSC— Notice of Status Change，决策已传达
• EOS— End of Sale，新客户无法再购买
• EOE— End of Expansion，无法再增加容量或席位
• EOR— End of Renewal，合同不再续约（合同驱动，按需纳入）
• EOM— End of Maintenance，修复停止
• EOL— End of Life，产品退役
• EOSRV— End of Service，所有支持与服务义务结束

eol-checklist的工业示例演练了 EOR（合同跑过 EOS 的硬件产品），所以这条规则是"被演示"而非"被声明"。此外该技能还给出了15 个功能领域的分层（括号内是该领域出现的最低等级）：Product/Engineering/Support/Documentation（L1）、Legal/Financial/Sales/Marketing/CS/IT/Data（L2）、Inventory/Channel/Regulatory/Org（L3）。

附加：套件临时扩展为 8 个技能

原计划只有 6 个。Phase 1-3 交付后，Dean 批准了自初次差距分析起就被标记的extend-vs-replace-vs-retire 分叉，以 Component + Interactive 配对形式落在新主题product-lifecycle下——即product-lifecycle-plays+lifecycle-play-advisor，另加两处对eol-readiness-advisor的小修改（在 Q1 加上游指引；Extend作为第五个判定加入，并明确与 Hold 区分——"Hold 说'现在不行'，Extend 说'这个产品还有牌可打'，不要合并它们"）。

四、对计划文档的日期勘误

09AUG26.md将 NFA-200 工业叙事世界标为"EOL announcement Q4 2026 with EOSRV in Q2 2027"——这与实际构建的世界不一致：服务合同一直运行到 2028 年，EOSRV 不可能早于合同结束。实际发布的日期：

• Northfield / NFA-200（工业）：NSC 2026-03-31 · EOS 2027-03-31 · EOE 2027-03-31 · EOR 2027-12-31 · EOM 2028-12-31 ·EOL 未排期· EOSRV 2028-12-31
• Fieldlight Classic Dispatch（SaaS），在 10 个文件中保持一致：NSC 2026-01-15 · EOS 3-01 · EOE 6-01 · EOM 10-01 · EOL 2026-12-31 · 800 账户 · $2.4M ARR · 约 30 个自定义规则账户 · 对 90% 目标达成 94% 留存。

eol-process的工业示例examples/sample-industrial.md正是"NFA-200 计划退役却发现无法退役"的失败叙事，与这套日期完全咬合。

五、本会话的核心学习（写进套件 DNA 的部分）

1. 叙事世界应跨技能互锁，且"让它失败"

最强的教学法来自让一个故事贯穿所有技能并且让它失败：Northfield/NFA-200 线索中——一个正确的玩法决策、一份命名了正确风险却因假设误评为"Low"的风险登记表、一个打破计划的 Phase 2、一次回到 Phase 1、最终以"End of Sale 且无 EOL 日期"收场。product-lifecycle-plays的工业示例甚至标注了当时这个失误在哪里可见。结论被提炼成一句话：

一个干净的示例教格式；一个失败往前推的示例教判断。

2. "Not scheduled" 是一等输出

反复出现的诚实物件是一个缺席：一个被刻意留空的 EOL 日期，配以记录的触发前提和一名具名负责人定期复查。模板现在显式支持这种写法，因为替代方案——"编一个日期填上空白"——是一个你会在公开场合打破的承诺。这正是 eol-process Phase 3 决策点 DP3 的规则："A date you can't defend → writeTBD, orNot scheduledwith the precondition."

3. 最重要的门禁是干系人对齐之后的那一个（DP2）

SaaS 与工业两个示例都围绕 DP2 展开（一个显式通过、一个失败并循环回去）。团队把它当走过场，但它却是整个流程中最便宜的一处"发现自己错了"的地方。

4. Validator 陷阱：H2 阶段标题会让## Application读作空

eol-process最初 smoke 失败，报错"section 'Application' is empty"——因为## Phase 1:紧跟## Application出现。discovery-process用一个引导段落解决这个问题。任何未来的 Workflow 技能都应照做。（这也解释了 eol-process 中## Application下现在有一句引导语的原因。）

六、仓库工程细节与会话确认的坑

10AUG26.md记录的仓库级注意事项，是维护本仓库最实际的"生存手册"：

1. README 横幅每行是 70 个字符（不是字节——║和•是多字节字符）。任何编辑后都要用 Python 的len(line)验证。把 "July 17, 2026" 改为 "August 10, 2026" 需要恰好移除 2 个空格的内边距。可对照 README.md 第 7-22 行的横幅。
2. build-dist.sh在两处硬编码了包清单——拷贝循环（约第 39 行）与生成的 README 表格（约第 125 行）。本次会话再次确认。对照源码可见 scripts/build-dist.sh 第 39-44 行的for p in pm-skills-starter-pack 02-discovery-pack ...与第 120-130 行 README 中的包表。
3. marketplace.json是手工维护的；check-library-drift.py负责捕捉缺失条目。
4. check-library-drift.py不检查catalog/、dist/或文字计数——CI 可以全绿而三处全部过期。必须用generate-catalog.py与build-dist.sh重新生成，并手工更新 README 计数。
5. 发布包是ZIP 套 ZIP（每个技能一个内层 ZIP）——这是既有约定，不是 bug。
6. 唯一持续的 trigger 警告来自incoming-request-advisor（description 缺少字面 "Use when"）。历史遗留、无关本次发布、至今仍在。

验证运行记录（提交前）

scripts/validate-skills.sh -> 77 skills, 0 failures, no drift scripts/test-a-skill.sh --smoke skills/eol-*/SKILL.md -> 6/6 PASS, 0 warn scripts/check-skill-triggers.py -> 0 errors, 1 warning (pre-existing) scripts/generate-catalog.py -> 77 skills, 6 commands scripts/build-dist.sh -> 77 skill ZIPs, 9 packages

这套验证链条在 scripts/test-library.sh 中有完整编排：7 步依次为技能元数据检查 → trigger 审计 → 命令元数据检查 → 库漂移检查（marketplace + 文档链接）→ 可选 smoke → 目录重新生成 →dist 货架新鲜度检查。

七、Part 2：套件发布之后，同一会话继续交付的内容

1. 全库元数据回填

全部77/77技能现在都带有theme、best_for、scenarios与estimated_time元数据。此前覆盖率是 theme 42/77、estimated_time 43/77；35 个技能因为没有主题而掉进了 "All other skills" 桶。本次：

• 新增主题validation-experiments（pol-probe、pol-probe-advisor、derisk-measurement-advisor、lean-ux-canvas、recommendation-canvas）——这组技能原本没有归宿，也不适合 discovery 或 artifacts 主题；
• company-intel与tam-sam-som-calculator属于 v0.83 market-intel 套件却从未被打标；pestel-analysis现在与姊妹技能pestel-delta-monitor归位；
• 为 15 个两样都缺的技能补写了best_for和scenarios。

你可以在 catalog/skills-index.yaml 与 catalog/skills-by-type.md 中直接验证新主题与新元数据的落库效果。

2. CI 盲区被关闭：check-dist-freshness.py

这正是第三节第 4 点提到的坑：check-library-drift.py只验证 marketplace 与文档链接，不验证catalog/、dist/与文字计数——于是 CI 可以全绿，而可浏览的下载货架仍广告着上一个版本。v0.83 与 v0.84 之间就真实发生了这件事。

新脚本 scripts/check-dist-freshness.py 现在验证：catalog 成员与数量、每个技能一个dist/ZIP 且无孤儿、dist/packages/中存在每个声明的包、dist/CATALOG.md提到所有内容。其 docstring 直接点明设计约束：

• 内容级而非字节级（content-level, never byte-level）——重建的 ZIP 因内嵌时间戳每次运行都不同，比较归档字节会持续误报并训练所有人无视该检查；
• 作为独立 CI 步骤，绝不放进validate-skills.sh——因为build-dist.sh→build-release.sh→validate-skills.sh的调用链意味着，检查若住在那里，会中止"恰好用来修复它所检测的过期问题"的那条命令。因此它被接线为 scripts/test-library.sh 的第 7 步，位于目录重新生成之后。

验证方式是加了一个一次性技能：得到 4 项具体发现加修复命令，移除后恢复干净。

3. Provenance 规则与两个匿名化陷阱

Dean 指出，即使抹掉客户，具名交付物（如 "Dean's GTM/EOL Strategy Workshop"）依然可被识别。新规则已写入 CONTRIBUTING.md 与 CLAUDE.md：公开可链接的工作按名引用；未公开的内部或客户交付材料，引用框架或实践，而不是引用成果本身。本次在 v0.83 与 v0.84 的 13 处做了重写，涵盖organic-growth-advisor、CLAUDE.md 及 09AUG/10AUG/17JUL 简报——包括携带客户名的本地文件路径。

两个值得带走的陷阱：

1. 具名交付物 + 日期 + 作者 = 即使抹掉客户也可被搜索到；
2. 已提交的拒绝清单本身就是泄露——Plan 4 护栏的早期版本枚举了要避免的主题，这反而把敏感材料指给了读者。排除项只留在会话记忆里；已提交文档以正面方式陈述约束（"应该待在哪个领域内"）。

保持不变（因为公开且可链接）：product-manager-prompts 的 URL、Product Porch 播客的 URL、第三方框架、productside.com 的公司链接。

4. 发布资产重建

v0.84 的发布资产携带旧的 provenance（tag 早于清理动作）。通过下载活 ZIP 而非假设来验证后，tag 移至7f92c40，工作流重建了每个资产并复核干净。提交历史被刻意保留——重写成本更高、既覆盖不到 fork 也覆盖不到 clone，且被暴露的只是产品类别与培训交付物名称，从未涉及客户。

5. Adornment Plan 4 —— 完成

四个 wave 全部交付（详见 docs/maintenance/2026-08-10-adornment-plan-4.md）：

单域缺口 21 → 0（排除三个有文档记录的 carve-out）。每个 Component 与 Workflow 技能现在都附带template.md加两个领域的完整示例。

第三个叙事世界获批并投入使用：Brightwater Biologics——生命科学、临床试验运营、平台Trialpath。它有意识地范围收窄、不是通用回退：只在"受监管 / 证据驱动 / 长周期工作本身就是教学点"的地方使用。核心工件保留一个即时可读的第二领域，因为"需要词汇铺垫的领域会与教学点竞争读者的注意力"（护栏见memory/fictional-universes.md）。

6. 更多学习

• 失败往前推比干净示例教得更多。本会话最强的工件都是失败的：一个把正确风险按假设误评为 "Low" 的风险登记表、一个三周后正确毙掉的 epic、一个标记为 Superseded 而非删除的 Phase 1 判定。复用这个模式。
• 两个stakeholder-mapping示例独立地把"受影响最大、权力最小"的群体在第一个网格中放进Monitor，并在第二个网格中纠正——同一模式、无关领域，看起来是结构性的错配，两份文件都如此写道。
• Trigger 审计全库首次干净。incoming-request-advisor曾写 "Use before replying"（而check-skill-triggers.py要求字面 "Use when"）。

八、下一步与后续候选

近期（near-term）

1. 主题回填——仍是最老的未结事项。约 36 个技能缺theme/best_for/scenarios/estimated_time；两个新主题（eol-transition、product-lifecycle）已完整打标。
2. Adornment Plan 4——为约 30 个旧技能回溯补齐template.md与双域示例（范围见 docs/maintenance/2026-07-17-adornment-and-docs-plan.md）。EOL 套件已完整"装扮"，可作参考实现。
3. build-dist.sh仍未接入 CI/发布自动化——自 v0.82 起一直挂着。
4. 修复incoming-request-advisor的 description，清掉最后一个 trigger 警告（一行改动）。

套件后续候选

• Portfolio EOL screening——7 步玩法（Organize → Assess → Identify → Validate → Plan → Execute → Review），带跨目录挑选候选的标准；product-lifecycle-plays的组合工作表部分覆盖，未完全覆盖。
• EOL 决策权（DACI）——谁决定哪些细分先测试、谁批准提前的白手套消息、谁拥有针对"没坏就别修"的应对消息权。干系人序列覆盖对话顺序，不覆盖权力。
• 合同/SLA/监管义务审查作为独立工件——目前只是序列中的一站和清单的一个区域，但它正是每个知名 EOL 灾难背后的失败模式。
• 迁移与留存战役——内部赋能的客户侧对应物。"失去产品但不失去客户"是套件的主论题，但留存战役本身仍是隐性的。

旧队列（未变）

• Phase 6 AI PM Orchestrator：ai-product-evals、ai-observability-framework、ai-maintenance-planning、ai-product-orchestrator
• Pricing & Monetization Suite（7 个技能）
• 决定 v0.80 AI Product Builder Track 简报（15MAY26.md）的去留
• docs/Using PM Skills with Claude.md中的 "Invoking skills with arguments" 小节

九、源材料与匿名化边界

匿名化被严格保持：已发布技能的任何地方都不出现来自源客户工件的客户名与细节，只有虚构世界。product-lifecycle-plays中使用的真实公司失败案例（Kodak、Zune、New Coke、Vista、Nest Revolv、AT&T POTS、Amgen）来自 Dean 自己的 deck，属于公开商业史，而非客户合作项目——这也是"引用公开可链接材料、不引用客户交付物"这一 Provenance 规则（现载于 CONTRIBUTING.md 与 CLAUDE.md）的直接应用。

结语：一份交接简报的工程价值

10AUG26.md表面上是"本会话交付了什么"的记录，实际是三层信息的合体：产品层（EOL 套件的设计哲学——拨盘式右尺寸化、零耦合路线、门禁词汇协调）、工程层（CI 盲区的识别与check-dist-freshness.py的内容级校验设计、构建脚本的硬编码维护点、横幅的字符级陷阱）、流程层（Provenance 规则与匿名化、失败叙事的教学法、Not scheduled 作为一等输出）。对于任何要复刻该套件设计或维护该仓库的工程师与 PM，这份简报都是比正式文档更真实的第一手资料；而套件本身的可运行依据，始终沉淀在 skills/eol-transition 与 skills/product-lifecycle 各技能目录 下的 SKILL.md、template.md 与双域示例中。

• AI 技能
• AI 插件