team-concept-whitepaper

name	team-concept-whitepaper
description	在产品规划阶段澄清产品定位、价值与能力边界，并编写可评审的产品概念白皮书。Create a reviewable product concept white paper by clarifying its positioning, value, and capability boundaries.
license	MIT
metadata	{"author":"coolbeevip","version":"1.0"}
triggers	["编写产品概念白皮书","写产品白皮书","梳理产品概念","定义产品定位和边界","产品规划阶段需要白皮书","write a product concept white paper","create a product white paper","clarify a product concept","define product positioning and boundaries","document a product vision"]

产品概念白皮书

这个技能用于把早期产品构想组织成一份有证据边界、可评审、可继续细化的概念白皮书。先建立问题、价值与产品边界，再写架构、能力和路线；不要把概念白皮书写成 PRD、技术方案或营销宣传稿。

触发边界

• 适合触发：产品规划早期需要定义为什么做、为谁做、产品是什么、提供什么价值、负责与不负责什么，以及如何演进。
• 不适合触发：需要细化具体功能、业务规则与验收口径时，转交 team-spec-refine；需要固化版本交付范围时，转交 team-spec-to-prd；需要描述组件、接口和实现选型时，应使用架构或技术设计流程。

概念白皮书描述目标产品，不自动构成当前功能、性能、兼容性、发布日期或客户交付承诺。

工作边界

本技能只做产品调研、概念澄清与白皮书写作，不修改业务代码、测试、配置、依赖、数据库或构建文件。代码和现有系统只能作为产品事实的只读证据。

允许写入的运行时产物仅限：

• team-spec/config.yml：缺失时按配置规则创建最小配置。
• team-spec/active/{slug}/concept/whitepaper.md：白皮书正文。
• team-spec/active/{slug}/STATUS.md：可选，记录 concept-drafting、concept-review、concept-ready、paused 或 blocked。
• 已有全局或当前需求上下文文件：只有在用户确认信息适用范围后，才按既有规范更新。

运行时配置与 slug

开始前读取 team-spec/config.yml。语言优先级固定为：用户本轮明确指定 > 配置中的 language > 询问一次并创建最小配置。存在 access_policy 时，先遵守其读写边界。

在读取或写入需求工作区前，必须确定唯一 {slug}，格式为 {yyyy-mm-dd}-{short-english-slug}。如果无法从用户请求、当前对话或明确路径唯一判断，要求用户指定继续哪个 slug 或创建哪个新 slug，不得猜测。team-spec/archive/ 默认只读。

输入物

• 用户提供的产品想法、战略背景、目标用户、市场机会、用户问题、竞品观察和商业假设。
• 访谈、研究、现有产品文档、设计材料、数据或用户明确提供的优秀白皮书样例。
• team-spec/CONTEXT.md、team-spec/decisions/。
• 同一 slug 下已有的 concept/whitepaper.md、spec/CONTEXT.md、spec/decisions/，如果存在。
• 代码、测试和系统行为；仅作为当前产品事实的只读证据。

读取外部白皮书样例时，提炼其叙事结构、章节职责、证据表达、图表类型和评审方法。不要复制专有产品内容、品牌措辞、未授权数据或大段原文。

输出物

• 对话中的概念澄清结论、关键假设和待确认问题。
• team-spec/active/{slug}/concept/whitepaper.md：主输出物，供 team-spec-refine、产品评审、架构设计和后续 PRD 使用。
• team-spec/active/{slug}/STATUS.md：可选状态更新。

白皮书是上游产品概念基线，不替代 spec/refine.md、spec/reviews.md 或 prd/prd.md。

工作流程

1. 定义文档任务

先确认并记录：

1. 白皮书对象：单个产品、产品体系，还是平台/架构概念。
2. 目标读者：客户决策者、产品与架构人员、研发、合作伙伴、市场，或内部管理者。
3. 阅读后应形成的关键认识与期望决策。
4. 发布范围：内部对齐、受限交流或公开发布。
5. 文档版本、事实截止日期和负责人。

缺失信息会显著改变叙事或披露边界时才追问；每次优先问影响最大的一个问题，并给出推荐答案。

2. 建立事实与主张台账

写作前把材料分为四类：

类型	含义	写作要求
已验证事实	有产品、代码、数据或负责人确认	可以陈述，并保留来源
产品决策	已确认的定位、边界或原则	明确决策范围和影响
待验证假设	尚无充分证据的判断	标注为假设，不写成事实
演进方向	未来可能建设的能力	标注阶段或“方向性规划”

性能数字、支持清单、客户案例、市场数据和兼容性主张必须有证据与披露权限；缺失时删除具体断言或明确标注待确认。

3. 选择叙事类型

• 产品体系或架构概念：强调行业变化、现有方案之间的空隙、分层理由、关键决策、职责契约与整体演进。
• 单个产品概念：强调用户问题、产品定位、产品价值、设计原则、核心能力、端到端过程、产品边界、协作关系与演进。

两类文档都遵循同一条主线：

变化或问题 → 现有解法的缺口 → 产品判断 → 产品定位
→ 设计原则 → 能力与架构 → 边界与协作 → 场景验证 → 演进方向

每一章只承担一个叙事任务，并能用一句话说出读者读完后应得到的结论。

4. 先产出大纲

先给出章节级或逐页大纲，再展开正文。每个章节至少说明：

• 核心结论。
• 支撑证据或产品判断。
• 建议图表。
• 尚待确认的信息。

获得用户确认后再写完整白皮书；如果用户明确要求直接起草，可在文首声明未确认假设并继续。

5. 编写正文

默认使用下面的自适应模板，按产品复杂度删减，不为凑齐目录重复内容：

# {产品名称}概念白皮书

## {一句话副标题}

**文档版本：** {Concept Vx.y}
**发布日期：** {日期}
**文档属性：** 产品规划阶段概念白皮书

> 本文描述目标产品概念、设计原则与能力边界，不代表所有能力已经实现。具体版本范围、验收标准、技术实现和交付承诺由后续文档定义。

## 执行摘要

## 1. 问题与背景

## 2. 现有解法与关键缺口

## 3. 产品定位与价值

## 4. 目标用户与使用场景

## 5. 设计目标与原则

## 6. 产品能力与概念架构

## 7. 端到端使用或任务过程

## 8. 产品边界与协作关系

### 8.1 本产品负责

### 8.2 本产品不负责及相应责任方

## 9. 部署、运营或交付形态

## 10. 产品演进路线

## 11. 风险、假设与开放问题

## 12. 结语

## 附录 A：核心术语

## 附录 B：事实与发布审校清单

产品体系型白皮书可以把“产品能力”替换为“分层架构与关键架构决策”，并增加职责矩阵、关键流和版本兼容章节。

6. 设计图表

只有图表能明显降低理解成本时才加入。优先考虑：

• 产品定位图：说明产品位于什么上下文、连接谁。
• 概念架构图：表达稳定职责，不展开易变实现组件。
• 职责边界表：同时写清主责方、协作方和非责任方。
• 端到端过程图：区分业务流、任务流、数据流和控制流，不混画。
• 部署图：说明部署变化是否改变产品职责。
• 演进路线图：区分当前能力、下一阶段和方向性规划。

图表必须与正文使用同一术语，并在正文中解释图表要证明的结论。

7. 评审与修订

至少从四个视角审校：

评审视角	核心问题
产品	定位、用户价值、能力范围和路线是否成立
架构	分层、依赖、接口和职责边界是否自洽
研发	产品事实、当前能力和约束是否准确
市场/解决方案	对外表达、场景和披露内容是否清晰可信

出现以下情况时不得标记为 concept-ready：核心定位仍有多个互斥版本；目标读者或发布范围未知；产品边界冲突；把规划能力写成已交付能力；关键数字或案例没有来源；术语和架构图互相矛盾。

修订同一概念时沿用 slug，并在正文末尾维护 ## Change Log，记录日期、版本和变化原因。

写作原则

• 先讲客户问题和产品价值，再讲架构与能力。
• 从用户可感知结果组织能力，不以内部模块、进程或代码目录充当产品能力。
• 清晰区分“为什么/是什么”与“怎么实现”；实现细节留给技术方案。
• 产品边界不仅写“不负责”，还要说明相邻责任由谁承担。
• 对同一概念只使用一个规范术语；首次出现技术名词时解释它在产品中的角色。
• 用具体场景验证抽象定位，但不要把单一客户定制误写成通用产品能力。
• 执行摘要应能独立回答问题、缺口、定位、核心价值和边界。
• 结语收束产品判断，不重复全文目录。
• 避免“领先、颠覆、全面、无缝、赋能”等无证据宣传词。

完成标准

• 目标读者不依赖原始对话也能理解产品为什么存在、是什么和不是什么。
• 问题、产品定位、能力、边界、场景与路线形成一条一致的因果链。
• 当前事实、产品决策、待验证假设和演进方向可明确区分。
• 一页或一个短章节即可说明定位、目标用户、核心价值和产品边界。
• 所有关键术语、图表和职责描述一致。
• 没有把概念白皮书写成 PRD、技术方案、操作手册或销售承诺。

最终回复

完成时说明：

• 白皮书路径与 slug。
• 文档类型、目标读者和发布范围。
• 已确认事实、仍保留的假设或披露风险。
• 当前状态是否达到 concept-ready。
• 下一步可选必须使用有序号列表：通常包括继续概念评审，或进入 team-spec-refine。