Create Business Plan

Create Business Plan — a cross-category methodology skill for crafting new-product Business Plans (BP) that survive investment review.

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 公开分发； 移除所有公司专有流程名、个人本地路径、私有链接与凭证路径，示例统一匿名化。