用途
BP Polish 用于改进已有的商业计划书（BP），且不会在用户不知情的情况下改动其业务事实。它可在大纲阶段、幻灯片渲染之后，或作为修正循环的一部分使用。
模式
该技能提供四种模式，根据请求推断最小可用模式：
- content（内容）：输入为大纲或 Markdown，关注产品定义、故事、文案和页面节奏。
- evidence（证据）：输入为大纲加台账/来源，关注主张、指标、TAM/SAM/SOM 和假设。
- visual（视觉）：输入为 PPTX、PDF 或幻灯片图片，关注层级、图表、布局、品牌和二维码。
- full（完整）：输入为任意完整 BP 工作区，覆盖所有维度加修正循环。
当用户只想审阅大纲时，不要求提供 PDF。若多种模式都可行，会从用户措辞中预填；仅当选择会实质性改变工作时，才提出一个简短问题。例如“不专业”默认对应 full，“文字太技术”默认对应 content，“图表不好看”默认对应 visual。
输出契约
输出目录结构为：
business-plan/
├── reports/bp-review.md
├── outline.md # 仅在请求授权时修补
├── deck-manifest.md # 视觉修复时更新
└── revised slide/deck assets # 仅受影响的部分
工作流程（强制）
步骤 0：确定来源和模式 将 SKILL.md 所在目录解析为 SKILL_DIR。检查提供的来源和任何现有 BP 工作区，复用受众、阶段、风格和证据定义。按需阅读 references/review-rubric.md、references/charts-and-visuals.md 和 references/user-config.md。
步骤 1：运行确定性大纲审计 当存在大纲时，运行：
python3 "$SKILL_DIR/scripts/audit_bp.py" \
--input ./business-plan/outline.md \
--output ./business-plan/reports/bp-review.md
最终交付前使用 --strict。该脚本检查结构和证据卫生，但不替代投资者判断或视觉检查。
步骤 2：以四种对立视角审阅
- 非技术投资者——产品能否在十秒后被复述？
- 品类专家——哪些产品/竞争主张幼稚或不精确？
- 怀疑的合伙人——哪些核心主张缺乏证据或夸大牵引力？
- 设计总监——哪里布局降低了信任或扭曲了含义？
对每个问题记录幻灯片、严重程度、为何重要以及确切修订。
步骤 3：润色时保护事实
- 绝不让数字“看起来更好”。
- 绝不把假设变成事实。
- 绝不编造客户引语或证言。
- 绝不在没有买方和价格桥梁的情况下扩大 TAM。
- 绝不单纯为了改善故事而改变产品边界。
若修订需要新证据，标记证据阻塞并返回 lovstudio-bp-outline。
步骤 4：检查已渲染幻灯片 对于 visual/full 模式，创建或检查联系表以及正常演示尺寸下的每一页。检查：每页一个结论；正文至少 20 pt；光学对齐和留白；图表坐标轴、单位、图例、日期和来源；真实且清晰的产品截图；未拉伸的图片和徽标；无文字裁切或 CJK 损坏；从最终渲染页解码二维码；干净的封面和单一行动的末页；PPTX/PDF 页数匹配且文件名规范化。
步骤 5：应用针对性修复 将每个修复分类为：
- 文案修复——修补大纲并重新生成受影响幻灯片；
- 证据阻塞——在重写前更新台账/来源；
- 视觉缺陷——更改布局/样式或仅重新生成受影响幻灯片。
不要因单页问题重新生成整个幻灯片组。重复审计 → 修复 → 审计，最多三个循环。
步骤 6：交付报告 先给出结论和评分，然后是阻塞项、页面级发现、证据缺口、视觉 QA 和交付状态。使用 assets/templates/bp-review.md。
目标：85 分以上且无阻塞项。高数字评分绝不凌驾于捏造数据、缺失融资诉求、损坏来源、不可读幻灯片或无效二维码之上。
适用场景
适用于已有 BP 的审阅与改进，包括大纲阶段的内容打磨、证据核查、渲染后幻灯片的视觉检查，以及完整的修正循环。
限制
该技能不会改动业务事实，不会让数字“看起来更好”，不会把假设变成事实，不会编造客户引语，不会在没有买方和价格桥梁的情况下扩大 TAM，也不会单纯为改善故事而改变产品边界。需要新证据的修订会被标记为证据阻塞并返回 lovstudio-bp-outline。