如果你在用 AI 产品经理技能（PM Skills）生成 PRD、假设文档或实验结果报告，最让人放心的一件事就是：先看别人家的 AI 长什么样。PM-Skills 的样例输出库（skill-output-samples）正是为此而建——202 份可直接打开阅读的完整样例，由 3 家虚构公司（Storevine、Brainshelf、Workbench）贯穿 Triple Diamond 全生命周期，帮新手快速判断 AI 输出的"质量基准线"在哪里。

先搞清楚：这个样例输出库到底是什么？

它是 PM-Skills 项目自带的一套"标准答案库"，放在 library/skill-output-samples/ 目录下，核心用途有两个：

• 评估参考：第一次接触 PM-Skills？随便点开一个样例，就能看到某个技能（比如define-hypothesis）在真实产品语境下产出什么完整交付物，连同触发它的那条 Prompt 原文。
• 质量校准：要贡献新技能或修改现有技能？样例展示了"执行到位"应有的细节密度、结构和语气，是贡献者的标尺。

导航入口是 README_SAMPLES.md，它提供两张索引表：Browse by Skill（按技能查三份样例）和Browse by Company（按公司查完整故事线）。机器可读的线程档案则定义在 THREAD_PROFILES.md。

💡 这不是训练数据、不是 API 文档，而是一份份自包含、可直接阅读的产物示范。

3家虚构公司档案：覆盖 B2B / 消费 / 企业级

为什么是"虚构公司"？因为样例需要一个完整、连贯、不涉密的产品背景。于是项目设计了 3 家公司，每家代表一种产品类型、团队规模和Prompt 风格，刻意覆盖真实 PM 世界的不同工作方式：

三个关键设计值得新手记住：

1. 一条主线贯穿六阶段：每家公司的功能主线都走完 Triple Diamond 的 Discover → Define → Develop → Deliver → Measure → Iterate，还能看到实验结果和 pivot 决策（比如 Brainshelf 最终从定时摘要转向浏览器扩展触发的上下文召回）。
2. 竞品是真的，公司是假的：样例里出现的 Shopify、Klaviyo、Confluence 都是真实公司名，只有三家公司本身是虚构的。
3. 人物命名有约定：Storevine 用"Growth PM、Eng Lead"这类职位前缀；Brainshelf 用小写名字（marco、alex）体现创业团队氛围；Workbench 用正式"名 + 姓氏首字母"（Sandra C.、Karen L.）匹配企业文档规范。

每个样例的三段式结构：Scenario + Prompt + Output

打开任何一个样例文件，都会看到严格的三段式格式（规范定义在 SAMPLE_CREATION.md）：

• Scenario（2-4 句）：交代公司、团队和触发这份交付物的具体 PM 问题。虚构指标一律带[fictional]标记，真实行业数据则在 Source Notes 里引用公开来源。
• Prompt：PM 实际输入的斜杠命令原文，放在代码块中。Prompt 质量随线程风格变化——Brainshelf 的 prompt 就是几条粗糙的 bullet points，而 Workbench 的 prompt 是带干系人清单和量化基线的完整简报。
• Output：完整交付物，严格跟随对应技能references/TEMPLATE.md的章节顺序，不跳节、不留占位符。

以假设文档为例，sample_define-hypothesis_storevine_campaigns.md 展示了"有备而来"的 Prompt 长什么样：引用 1 月的商户访谈综述、2 月的竞品分析、已有问题陈述中的流失数据，然后要求带成功指标和 pass/fail 标准的完整假设文档。

🎯新手用法：想学习怎么写好 Prompt？同一个技能的三份样例（三个线程）并排读，你就看到了从"随便写写"到"企业级简报"的完整光谱。

[fictional] 标记机制：AI 样例如何做到"不编造"

这是整个样例库最有价值的"隐性课程"。规则的核心一句话：判断标准是溯源，不是形式——

• 输入（Scenario + Prompt）或 Source Notes 里有的数字/事实 → 不需要标记；
• 样例自己发明的观察（数字、研究方法、事件、用户引语、被引用为证据的来源）→ 必须紧跟[fictional]；
• 标记观察，不标记决策：目标值、阈值、灰度比例这类"产物自己做的决定"不标记。

为什么如此严格？因为未标记的虚构方法会让编造的综合看起来像被证实过的结论，而下游消费这份产物的团队会继承这种虚假的权重。配套还有校验脚本 check-sample-no-fabricated-metrics.mjs 做启发式扫描（它只标记百分比、且是咨询性的——通过不等于合规，发现也不等于违规）。

✍️ 对你的启示：要求你自己的 AI PM 技能也采用同样的"证据溯源"习惯，输出质量的可信度会显著提升。

文件怎么命名？看懂命名规律，索引一搜一个准

所有样例遵循统一命名模式：

sample_<skill>_<thread>_<additional-helpful-context>.md

• <thread>固定为storevine/brainshelf/workbench三选一（frontmatter 里也有对应的thread:字段，check-sample-counts.mjs 会按线程统计并校验分布）；
• 上下文段按样例类型变化：阶段技能用功能主线（_campaigns）、persona 变体编码模式+深度（_product-detailed-campaigns）、会议类编码主题（_resurface-algo-review）、OKR 周期编码季度（_campaigns-q3）。

全小写、连字符分隔、无空格——这条约定让文件名本身就成了可预测的索引系统。

202 份样例如何覆盖 63 个技能？

按发布批次拆分，202 份样例的构成为：

• 基础阶段技能 75 份：3 线程 × 25 个阶段技能；
• persona 样例 12 份：每线程 4 个变体（产品/营销 × 简版/详版）；
• Sprint 技能 45 份：Foundation Sprint 7 技能 + Design Sprint 7 技能各 3 线程 × 3 份，外加 note-and-vote 3 份，每条线程都是一条完整的 FS+DS 弧线；
• v2.18.0 新增 12 份：market-sizing、prioritization-framework、journey-map、survey-analysis 4 个新技能 × 3 线程；
• 后续批次 17 份：prioritized-action-plan、workflow-builder、stakeholder-briefings（18 份中的部分计入）、build-risk-review、project-memory 对等样例等。

其中两个"特例"值得点名：

• foundation-persona覆盖最广：每线程 4 份（12 份 persona 样例 展示故事驱动的角色档案）；
• discover-interview-synthesis 与 deliver-prd各多带一份 Storevine 的_sms-optin样例，演示 project-memory 交接——综合文档先记录 persona，后续 PRD 直接读取而不是重新粘贴。

新手上手路径：5 步用样例库校准你的 AI PM 输出

1. 选一个像你的线程：小团队快速迭代 → Brainshelf；有研究仓库习惯的 B2B PM → Storevine；企业级高文档环境 → Workbench。
2. 通读一条功能主线：比如 Workbench 的 Blueprints，从 competitive-analysis 一路读到 pivot-decision，感受"同一团队、同一功能、六个阶段"如何层层递进。
3. 对照 Prompt 与 Output 的差距：注意输出比 Prompt 多出了哪些结构——那就是技能本身的价值所在。
4. 把样例当模板验收 AI 输出：跑完自己的技能后，对照同技能的样例检查：章节是否完整？有没有该标[fictional]的裸数字？语气是否匹配？
5. 进阶阅读：THREAD_PROFILES.md 里每个线程都列出了"各阶段代表性场景"，是理解整个故事线的最短路径。

延伸阅读：样例库周边的契约与工具

样例库不是孤立存在的，它和仓库里的其他部件互为契约：

• 创作标准：SAMPLE_CREATION.md（命名、frontmatter 10 字段 schema、更新工作流）
• 线程档案：THREAD_PROFILES.md（机器可读元数据，含"新增线程"流程）
• 校验脚本：check-sample-counts.mjs、check-sample-no-fabricated-metrics.mjs、check-skill-sample-coverage.sh
• 子代理样例：library/sub-agent-samples/（6 个子代理的独立样例目录）
• 每个技能本体的模板与示例：skills/define-hypothesis/ 下的SKILL.md、references/TEMPLATE.md、references/EXAMPLE.md

📌 一句话总结：样例库的价值不在"看一遍"，而在把它当作 AI PM 输出的验收基线——先知道标准答案长什么样，你才能快速判断自己的输出差在哪。