Create Business Plan

SKILL.md

# Create Business Plan · 新品类商业计划书通用方法论
# Create Business Plan · A Cross-Category Business Plan Methodology

> 本 Skill 是给智能体自己用的内部工作流。**适用于任意新品类**，不绑定任何具体公司或产品。
> This skill is an internal workflow for AI agents. **Works for any product category** — not tied to any company or product.
> 示例（如电动床）仅作为「§5 参考案例」帮助理解原则，换品类时必须按 §1 原则重新推导，
> Example (e.g. smart bed) in §5 is illustrative only; re-derive from §1 principles per category.
> 不要照搬具体数值 / 品牌 / 功能名。
> Do not copy specific numbers / brands / feature names.

---

## 0. 何时触发（默认自动加载）
## 0. When to Trigger (auto-load by default)

- 用户要新建 / 改写 / 评估某品类或产品的商业计划书（BP），或说"按之前的共识做 BP"。
- 只要识别到是 BP 类任务，**主动加载本 Skill 再开工**，无需用户每次 @ 指定。
- 同类任务也包括：补竞品图、修封面配色、调功能版本归属、做 Gate Review 材料等。

---

## 1. 与用户达成的工作共识（跨品类通用，强制遵循）
## 1. Working Consensus (cross-category, mandatory)

以下原则从真实项目抽象而来，适用于任何新品立项。每条附「为什么」与「示例」帮助理解。

### P1 · 数据诚信三态标签（最高优先级）
### P1 · Data Integrity: 3-state Tags (highest priority)
- **规则**：全篇用 **已确认 / 待确认 / 假设** 标注；不虚构任何数字。竞品价若来自快照，
  标"非实时、以立项复核为准"；财务模型未获批前用"建模假设"措辞；生成图统一标
  "AI 生成示意、非特定品牌实拍"。
- **为什么**：数据诚信是 BP 的生命线，宁可留白也不造假。
- **示例**：BP 把 Persona 标为"假设"、竞品价标"对话快照非实时"。

### P2 · 改用户的 BP 文件前，必须先请求批准
### P2 · Request Approval Before Editing BP
- **规则**：列出变更清单 → 用 AskUserQuestion 让用户确认范围 → 再动手编辑。不静默改文件。
- **为什么**：BP 是用户的重要资产，变更前应先与用户确认范围。
- **例外**：用户当次明确说"直接改 / 不用确认"时可免。

### P3 · 行为 / 市场假设必须验证，不靠拍脑袋
### P3 · Validate Behavior & Market Assumptions
- **规则**：若 BP 的差异化依赖某个使用行为假设（如"用户会在 X 场景下用产品"），
  必须做市场调研验证其真实性（市场规模、现有已付费品类、调研统计），再据此定策略；
  若暂时无法验证，明确标为"假设"并附验证计划（如定量问卷 / 类目销量证据）。
- **为什么**：未验证的行为假设是 BP 最大风险点，会被评审委员会 / 决策层质疑。
- **示例**：电动床"床上办公"假设 → 调研证实北美 ~22% 居家办公、~8% 直接在床上工作、
  Lap Desk 类目已稳定付费，从而把"假设"转为"已验证"。

### P4 · 定位避开专业 / 监管 / 安全反弹，翻转到可防守角度
### P4 · Reframe Positioning to a Defensible Angle
- **规则**：当差异化叙事会招致权威方（医学 / 安全 / 监管）可信反驳时，
  翻转到"让已有行为更安全 / 更正确"的角度，并用核心 / 统领式定位（umbrella positioning）包住。
- **为什么**：头条叙事一旦被专家证伪，整份 BP 可信度受损。
- **示例**：不说"床=第二办公室"（触发 ergonomics/sleep 反弹、被迫对标 $1,500 椅），
  改说"为已在床上工作的人把姿势做对" + 核心定位（umbrella positioning）Small-Space Smart Bed Platform。

### P5 · 竞品矩阵要全面，不只盯正面 DTC 品牌
### P5 · Full Competitive Matrix
- **规则**：至少覆盖五类——① 已锁客的头部龙头；② **承接该需求的低质现有品类**
  （产品升级的机会所在）；③ 该品类 Amazon #1 爆款；④ 高端 / 智能标杆；⑤ **相邻替代品类**。
- **为什么**：只放正面竞品会漏掉真正的 incumbent 与替代威胁，也漏掉升级机会。
- **示例**：电动床补 Lap Desk（$20–40 爆款）、Overbed Table（$179）、
  一房两用家具品牌、Marsail（Amazon #1）等。

### P6 · 必须建 TAM / SAM / SOM + 增量 vs 替代分析
### P6 · TAM/SAM/SOM + Increment vs Substitution
- **规则**：三层市场估算框架必做；并显式检验产品是**取得增量**还是**仅替代**现有方案。
- **为什么**：评审委员会必问"市场够不够大、是不是真增量"。
- **示例**：用 Lap Desk 类目销量 / 评论作为"床上办公付费意愿已验证"的硬证据。

### P7 · 分层首发（先上一款，再叠加差异）
### P7 · Phased Launch
- **规则**：v1 = 最小但完整、基于成熟供应链（ODM / 共用底盘）的版本，优先保住上市时限；
  v1.5 / v2 再叠加差异化（智能功能、配件）。契合"先上市一款"的偏好。
- **为什么**：复杂结构 + 认证常击穿激进排期；分期可先验证大盘再上差异。
- **示例**：电动床 v1 Lite（床架-only 冲 3 个月）→ v1.5 Work（叠 WorkDock/Tech Hub）。

### P8 · 单位经济必须补数字
### P8 · Unit Economics Modeling
- **规则**：财务模型里"待计算"必须填成带具体数字的模型（即便标建模假设）：
  MSRP、BOM、EXW、Landed Cost、渠道费、品类特有成本杀手、CAC、贡献毛利。
  **单列该品类的成本杀手**（大件→退货/破损/末端配送；其它→CAC/质保/损耗），附敏感度。
- **为什么**：这是评审委员会关键批准门槛，留空不可接受。
- **示例**：电动床填了 Lite 上广告前贡献毛利 ~$128/20%、含广告后 ~$53/8.4%。

### P9 · 合规 / 认证进关键路径
### P9 · Compliance & Certification on Critical Path
- **规则**：按品类识别强制认证（电子→UL/ETL/FCC；儿童→CPSC；食品接触→FDA…），
  写实周期（常 8–12 周），列入关键路径；展示它如何挤压排期 → **支撑 P7 分层首发**。
- **为什么**：认证常被忽略，却是最容易击穿上市时限的隐性关键路径。
- **示例**：电动床 UL/ETL/FCC 8–12 周，击穿 12 周 EVT+DVT+PVT，证明必须分期。

### P10 · 功能 → SKU 归属显式且全文一致
### P10 · Explicit, Consistent Feature to SKU Mapping
- **规则**：明确哪些功能属 entry / core / pro 哪一档，并在产品组合、价格走廊、功能证明、
  功能矩阵所有章节保持一致，不出现"项目级 P0 写了但某 SKU 没有"的矛盾。
- **为什么**：归属混乱会让读者误判标配范围、打乱定价逻辑。
- **示例**：电动床腿部舒缓功能（示例）→Pro 专属；增强腰托/支撑→Work；Lite 去该差异功能。

### P11 · 设双硬 Gate（进入下一阶段前必过）
### P11 · Two Hard Gates (go/no-go)
- **规则**：定义 2 个具体、可判定的通过/不通过门槛（如支付意愿测试达标、
  单位经济上广告前为正），写进 BP 作为阶段放行条件。
- **为什么**：把"批准"从主观判断变成可验证的里程碑。
- **示例**：Gate1 床上办公支付意愿测试；Gate2 Lite 单位经济上广告前为正。

### P12 · 交付格式优先选「可直接编辑」的文档（强偏好，区分离线/上云）
### P12 · Editable Delivery Formats (offline/cloud)
- **规则**：BP 终稿交付物，优先用「用户能直接改文字/表格/图片」的格式，但**区分离线 vs 在线协作两种场景**：
  - **离线可编辑档**：用 **PPTX / DOCX**（用户可在 PowerPoint / WPS 直接改）。源文件若是 HTML，用本地 `python-pptx` / `python-docx` 解析 DOM 树转换。
  - **在线协作（如腾讯文档智能页面）可编辑档**：把 HTML 源文件用 `aipage_pack.js` 打包成 `.aipage` **直接导入在线协作文档智能页面（/page/）**——按原 HTML 排版渲染、可在线编辑、**不走 PPT 中转**。
- **为什么（实践验证后修正）**：
  - 早期反馈"HTML 不便改、MD 排版乱 → 要 PPT"成立；但把 PPTX 导入腾讯文档「演示（slide）」后，python-pptx 生成的复杂形状 / 绝对定位被演示编辑器重新流排，**排版乱七八糟**。
  - 改为 **HTML 直接打包 aipage 上云** 后，实践确认保真度远高于 PPT 中转。
  - 结论：**要上在线协作文档可编辑，就走 aipage；不要经 PPT 中转。**
- **怎么做（aipage 链路，已验证可用）**：
  1. `node aipage_pack.js --html <html_path> --title <title>` → 产出 `.aipage`（脚本在 tencent-docs skill 目录，零 npm 依赖，Node>=14）。
  2. `python import_file.py <aipage>`（同 skill 目录）完成 `pre_import` + 上传 COS。
  3. `manage.async_import` + 轮询 `manage.import_progress` 至 `progress=100`，拿 `file_url` + `file_id`（链接附 `?_fid=`）。
  - 解析坑（仅 HTML→PPTX 离线档相关）：① 跳过 void 元素；② base64 WEBP 转 PNG；③ section 递归查找。
  - 导入 API 坑位：`async_import` 的 `file_size` 必须传**整数**（schema 要求 integer）。
  - 连接器未连时，先交付本地 PPTX/DOCX，不要硬上云。

### P13 · 云端协同编辑：用户改云端，智能体负责同步回源（协作约定）
### P13 · Cloud Co-editing Sync
- **规则**：当用户选择把 BP 放在在线协作文档智能页面协同编辑时，**用户是单一编辑源**（直接在文档上改）；智能体负责"同步"——把云端改动反映回本地源文件（及必要的下游产物，如重新导出/重排版）。
- **触发与动作**：用户说"同步"时，拉取文档最新内容 → 对齐并更新本地 HTML 源文件；如需其它格式再据此重生成。
- **技术待验证（诚实标注）**：在线协作文档 MCP 能否**读回 aipage（/page/ 类型）的正文内容**尚未核实；若接口不支持读取 page 正文，退化为：用户改完后把改动点 / 导出文本贴给智能体，智能体据此更新本地源文件。**不要在未核实前承诺"自动无损同步"。**
- **为什么**：确立单一事实源与智能体的对齐职责，避免双份版本漂移。

---

## 2. 标准工作流程（7 步）
## 2. Standard Workflow (7 steps)

### P14 · 营销 / 定位 / 战略概念须事实核查，不得臆造术语
### P14 · Fact-check Marketing Terms
- **规则**：BP 中出现的所有定位 / 营销 / 战略概念（如 Umbrella Positioning、各类 Positioning 类型、斑马 / 漏斗等框架名），必须使用**标准译名并核查定义**，不得脑补听起来专业但不存在的中文词。拿不准时，要么 WebSearch 核实标准中文译法（营销学界 / 百科 / 教材），要么改用直白表述（如"核心定位"）而非生造。
- **为什么（真实教训）**：BP 中曾出现"伞盖定位"一词——公开资料查无此词（"伞盖"是佛教 / 器物用语），正确概念是 **Umbrella Positioning（伞形定位 / 伞型品牌策略）**。AI 生成营销文案极易臆造术语，一旦被评审识破，整份 BP 可信度受损，且违背 P1 数据诚信。
- **示例**：想表达"一个母定位罩多个场景"时，写"核心定位（umbrella positioning）"或"伞形定位"，绝不写"伞盖定位"。

### P15 · BP 必须内置「指标 Glossary / 术语表」统一口径
### P15 · Built-in Metrics Glossary
- **规则**：凡 BP 出现 CAC / CVR / TACOS / AOV / 贡献毛利 / LTV / ACoS 等单位经济与 GTM 缩写，必须附「指标 Glossary」小节，给**全称 + 公式 + 本品类口径**；尤其要显式区分易混对：
  - **ACoS vs TACOS**：ACoS = 广告费 / 广告带来的销售额（只看广告桶）；TACOS = 广告费 / 全部销售额（含自然单），更能反映盈利与自然流量健康度。
  - **贡献毛利 vs 毛利**：贡献毛利扣所有可变成本（含退货 / 物流 / 广告分摊），未扣固定 overhead。
  - **Session CVR vs 订单 CVR**：Amazon 常用 Session 转化率（订单 / 会话）。
  - **CAC 与售前咨询成本**：售前咨询成本只是 CAC 的一项明细，不应与 CAC 平行列导致重复计算。
- **为什么（实践信号）**：评审方对 CAC / CVR / TACOS / AOV / 贡献毛利 / LTV 等缩写常有理解障碍，统一口径可避免评审混淆与误读。
- **怎么做**：Glossary 按三组组织（获客 / 转化 / 盈利）；可同时生成为**独立 md 文件**作知识沉淀（见 P7 / §3）。每换品类，按本品类口径重写，不要照搬示例数字。

### P0 · 立项对齐（Intake）
### P0 · Intake & Alignment
- 明确：目标市场（默认北美）、渠道（默认 Amazon + 独立站）、公司 / 品牌（用户项目字段）、品类、
  上市时限、是否"先上市一款"。读用户已有 BP（大文件用 Python 抽正文到 txt 再分段精读）。

### P1 · 品类调研（Research）
### P1 · Category Research
- 复用选品方法论 6 步：**需求 → 竞争 → 利润 → 差异化 → 供应 → 收口**。
- 必采：品类规模 / CAGR、主力规格占比、旺季、头部竞品价 / 评论 / BSR、
  用户差评痛点、关键词搜索量。

### P2 · 评估现有 BP（若用户提供）
### P2 · Evaluate Existing BP
- 出 10 维评分卡（市场假设 / 竞争 / 差异化 / 单位经济 / 排期 / 风险 / 认证 / GTM /
  数据诚信 / 闭环）并给综合分；重点找三类缺口：① 市场假设未验证；② 单位经济为零数字；
  ③ 上市时限 ≠ 含认证 / 结构创新的可行周期。

### P3 · 验证关键假设（Validation）
### P3 · Validate Key Assumptions
- 对依赖行为假设的差异化做专项调研：行为是否真实、现有低质品类、权威反弹点、
  相邻替代机会。结论反哺定位（P4）与竞品矩阵（P5）。

### P4 · 修订 BP（带批准门）
### P4 · Revise BP (with approval gate)
- 按 §1 共识列变更清单 → **AskUserQuestion 请求批准** → 确认后编辑。
- 同文件多处编辑**串行**（避免 Edit 快照冲突）；大段 base64 / 批量替换用 Python 脚本更稳。
- 改完 Grep 校验所有点落位，确认无残留"待计算"等遗漏。

### P5 · 视觉资产（Visuals）
### P5 · Visual Assets
- 竞品 / 产品图用 ImageGen 生成（见 §3，必须串行）；隔离 venv 的 Pillow 压 JPEG q82
  后 **base64 内联** HTML（离线可看、不依赖外链）；图注标"AI 生成示意、价格以立项复核为准"。

### P6 · 反馈与迭代（强制，见 §4）
### P6 · Feedback & Iteration

### P7 · 知识沉淀（资产化，可选但推荐）
### P7 · Knowledge Assetization
- 把可复用资产导出为独立文件，便于跨会话 / 跨项目复用：
  - **指标 Glossary**：按 P15 生成「指标Glossary_跨境电商单位经济.md」（获客 / 转化 / 盈利三组 13 指标，含全称 + 公式 + 口径）。
  - **品类调研框架 / 评分卡模板**：可复用的方法论骨架。
- 存放优先级：① 用户指定的知识库（如 IMA，见 §3 凭证要求）；② 本地工作区 md 文件；③ 合并进在线协作文档 BP 作参考小节（P12/P13 协同源）。

---

## 3. 已知坑位 / 技术细节（通用）
## 3. Known Pitfalls (general)

- **封面标题看不见（高频）**：根因是全局 CSS `h1,h2,h3,h4{color:var(--navy)}` 覆盖了
  `.cover h1`，使封面标题与深蓝背景同色而"隐形"。修复：显式写 `.cover h1{color:#fff}` +
  `text-shadow`，eyebrow 改亮青。仅加实色深底不够，必须改标题色。
- **ImageGen 并发上限**：平台单账户约 150 任务上限，并行生成会失败 → **严格串行**生成。
- **Python 环境（隔离）**：用隔离的 Python venv（WorkBuddy managed python）。首次需建 venv
  并安装 Pillow（target 到 venv 的 site-packages），脚本用该 venv python 运行。
- **大 base64 块不要直接 Edit**：用 Python 脚本读文件、字符串替换、写回，避免工具失败。
- **Edit 同文件并发写**：会报快照过期；一律串行，或用脚本批量替换。
- **IMA 知识库需凭证（沉淀资产时注意）**：调用 IMA OpenAPI 需 `IMA_CLIENT_ID` / `IMA_API_KEY`
  （通过环境变量或本地配置文件提供），**未配置时返回 -100 未找到凭证**，无法直接上传。
  降级方案：先存本地 md 文件 + 项目记忆，或合并进在线协作文档（P12/P13）；要上 IMA 必须请用户提供凭证，且**绝不把凭证写入记忆 / 文件**。

---

## 4. 使用后的反馈与自我迭代（强制步骤）
## 4. Feedback & Self-iteration

**当用户主动要求"复盘 / 沉淀能力 / 更新 Skill"时（跨会话系统性抽取）：**
- 读取本项目 `.workbuddy/memory/`（含 MEMORY.md 与每日日志）+ 本次会话，通盘抽取：新共识 / 新坑位 / 新术语核查需求 / 新品类特例；
- 批量更新 §1 共识、§2 流程、§3 坑位，升版本号，追加 §6 变更记录；
- 不重复已固化内容，重点补"之前对话暴露但 Skill 还没覆盖"的能力缺口。

**每次用本 Skill 完成一次实际工作任务（不是创建 / 修改 Skill 本身）后，必须：**

1. 用 **AskUserQuestion** 向用户收集反馈（3 题左右）：
   - 本次交付哪些符合预期、哪些不符合？
   - 是否形成了一条可固化的**新共识 / 新坑位 / 新品类特例**？
   - 是否有流程步骤想增删、或调整顺序 / 措辞？
2. 依据反馈，用 **Edit** 直接更新本 `SKILL.md`：
   - 新增 / 修正「§1 共识」「§3 坑位」「§2 流程」；
   - 若为某品类积累了可复用经验，补进「§5 参考案例」或新增品类小节；
   - 文末「§6 变更记录」追加一条（日期 + 反馈摘要 + 改动点）。
3. 若反馈与已有共识冲突，先向用户确认再改，不要静默覆盖旧共识。
4. 目标：让本 Skill **越来越贴合用户真实偏好**，下一次同类任务更少提问、更准。

---

## 5. 参考案例：某消费电子品牌智能电动床（仅作示例，非规则）
## 5. Reference Case: Smart Bed (example only)

> 以下全部是电动床的**实例化**，用于演示 §1 原则如何落地。**换品类时按 P1–P11 重新推导，
> 不要照搬具体品牌 / 数值 / 功能名。**

- **背景**：某消费电子品牌在北美 Amazon + 独立站从 0 到 1 立"智能电动床"品类，目标 3 个月上市一款。
- **P3 验证**：调研证实"床上办公"真实（北美 ~22% 居家办公、~8% 在床上；Lap Desk 类目已付费）。
- **P4 定位**：从"Your Bed Is Your Second Office"翻转为"为已在床上工作的人把姿势做对"
  + 核心定位（umbrella positioning）Small-Space Smart Bed Platform。
- **P5 竞品补**：Lap Desk（$20–40）、Overbed Table（如 Muwuele $179）、
  一房两用家具品牌（Ori/Resource Furniture/IKEA）、Marsail（Amazon #1）、Tempur-Pedic/Sleep Number（高端）。
- **P6 市场**：TAM/SAM/SOM + 增量 vs 替代；以 Lap Desk 销量作付费意愿硬证据。
- **P7 分层**：v1 Lite（床架-only，成熟 ODM 底盘，冲 3 个月）→ v1.5 Work（叠 WorkDock/Tech Hub）。
- **P8 财务**：填单位经济模型（Lite 上广告前贡献毛利 ~$128/20%；Work ~$123/13.7%），标号建模假设；
  单列大件成本杀手（退货/破损/末端配送）。
- **P9 认证**：UL/ETL/FCC 显式进关键路径（8–12 周，击穿 12 周 EVT+DVT+PVT）→ 支撑分层。
- **P10 功能归属**：腿部舒缓功能（示例）→Pro 专属；增强腰托/支撑→Work；Lite 去该差异功能
  （注：项目级 P0 清单应将该功能标为"Pro 阶段交付"，不列全系标配）。
- **P11 双 Gate**：Gate1 床上办公支付意愿测试；Gate2 Lite 单位经济上广告前为正。
- **视觉**：竞品卡补 Overbed Table / 一房两用家具等 AI 图（base64 内联）；实践中按需增删图鉴章节。
- **坑位实战**：封面 h1 深蓝同色已修；ImageGen 串行；Pillow base64 内联。

---

## 6. 变更记录（自我迭代日志）
## 6. Changelog

- **v1.0.0**：从某消费电子品牌电动床项目固化初版，含 10 条共识 + 7 步流程 + 坑位 + 反馈机制。偏具体品类。
- **v1.1.0**（实践反馈"用于其它品类"→ 重做）：
  - 重做为**跨品类通用方法论**，具体品类降为「§5 参考案例」，原则化 P1–P11；
  - 触发方式改为**默认自动加载**；
  - 功能归属原则化（示例中功能在案例中体现，不写死为全局规则）；
  - 新增 P3/P4/P5/P6/P9/P11 的"为什么 + 示例"说明，便于迁移。
- **v1.2.0**（实践反馈"HTML 不便改、MD 排版乱，要 PPT"→ 迭代）：
  - 新增 **P12 交付格式优先选 PPT/DOCX**（强偏好，附 HTML→PPTX 解析坑：void 元素、
    WEBP 转 PNG、section 递归查找）；
  - 源文件若是 HTML，固化用 `python-pptx` 本地转换、不依赖连接器的路径。
- **v1.3.0**（实践验证"PPT 导入在线协作文档演示排版乱"，改用 aipage 路线后确认保真度更高→ 迭代）：
  - **修正 P12**：区分「离线 PPTX/DOCX」与「上云 aipage」两场景；明确**上在线协作文档可编辑必须走 aipage（HTML 直接打包上云），绝不经 PPT 中转**；附 aipage 已验证链路与导入 API 坑位（file_size 整数）。
  - **新增 P13 云端协同同步约定**：用户是单一编辑源（在在线协作文档智能页面直接改），智能体负责"同步"回本地源；诚实标注 aipage 正文读回接口待验证，不支持时退化为用户贴改动点、智能体更新本地源。
- **v1.4.0**（系统性复盘迭代）：
  - **修正 P4 / §5 残留讹误**：原"伞盖式品类定位"改为"核心定位（umbrella positioning）"，统一为正确概念。
  - **新增 P14 营销 / 定位术语事实核查**：禁臆造中文营销词（伞盖定位教训），拿不准就 WebSearch 核实或直白表述。
  - **新增 P15 BP 内置指标 Glossary**：统一 CAC / CVR / TACOS / AOV / 贡献毛利 / LTV 等缩写口径，区分 ACoS vs TACOS、贡献毛利 vs 毛利、CAC 与售前咨询成本关系。
  - **§2 流程增 P7 知识沉淀**：指标 Glossary / 框架模板资产化，存知识库（需凭证）/ 本地 md / 在线协作文档。
  - **§3 坑位补 IMA 凭证要求**：未配置返回 -100，降级本地 / 在线协作文档，凭证绝不入记忆。
  - **§4 增"用户主动复盘"指令**：跨会话读 memory 批量抽取能力缺口并升版。
- **v2.0.0（公共化发行版）**：去品牌化与去个人信息，更名 `create-business-plan`，面向 ClawHub 公开分发；
  移除所有公司专有流程名、个人本地路径、私有链接与凭证路径，示例统一匿名化。