business-evaluation

[BLOCKING] 按声明顺序执行技能步骤。未经用户明确批准，绝不跳过、重排或合并步骤。 [BLOCKING] 每个步骤或子技能调用开始前，更新任务跟踪：步骤开始时设为 in_progress，结束时设为 completed。 [BLOCKING] 每个已完成或跳过的步骤都必须附上简要证据或明确的跳过原因。 [BLOCKING] 如果无法使用 Task 工具，则创建并维护等效的逐步计划跟踪器，执行相同的状态转换。

快速摘要

目标： 评估商业创意的可行性，并给出有证据支撑的可行性结论——评分、置信度，以及“推进／转型／暂停／放弃”的建议。评估应以完整的 9 模块 BMC、注明假设的 3 年财务数据、5 项以上风险及缓解措施，以及分阶段执行与 GTM 计划为依据，确保是否继续的决策基于可追溯证据，而非盲目乐观。

摘要：

• 全部 7 个主要步骤，按顺序执行：（1）记录创意（问题／解决方案／目标群体），（2）加载市场分析数据作为证据，（3）商业模式画布——全部 9 个模块，（4）3 年财务预测 + 假设表，（5）风险评估——至少 5 项风险，（6）分阶段执行计划，（7）市场进入计划——然后给出（第 7 步）结论。绝不跳过、重排或合并步骤——原因：AI 会忘记技能自身的步骤，交付不完整的评估。
• 在完成 market-analysis 后运行：将其市场数据作为证据引入，而不是在此重新推导市场规模——本技能评估的是可行性，不负责市场研究。
• 每项产出都必须通过证据门槛——所有 9 个 BMC 模块都要引用证据，每个财务数字都要注明假设和来源，每项风险（至少 5 项）都需要缓解措施和剩余风险条目；缺乏依据的数字或模块无法通过门槛。
• 结论是核心产出：给出 1–10 分的可行性评分，明确的置信度等级（95/80/60/<60%）及其证据依据，“推进／转型／暂停／放弃”的决策，以及成功所必须满足的唯一关键条件——倾向审慎，绝不盲目乐观。
• 使用强制模板 .claude/templates/business-evaluation-template.md，将结果写入 docs/knowledge/strategy/business/{slug}.md，然后使用 AskUserQuestion 确定下一步（建议进行 domain-analysis）——绝不自动做决定。

工作流：

1. 记录创意 — 问题、解决方案、目标客户
2. 加载市场分析 — 来自 market-analysis 的市场数据
3. 商业模式画布 — 全部 9 个模块，附证据
4. 财务预测 — 3 年收入、成本、盈亏平衡点
5. 风险评估 — 至少 5 项风险及其缓解措施
6. 执行计划 — 3 个阶段及里程碑
7. 结论 — 可行性评分、置信度、建议

关键规则：

• 必须包含全部 9 个 BMC 模块，每个模块都要有证据
• 财务预测：提供明确的假设表
• 至少 5 项风险，并列出缓解措施和剩余风险
• 结论必须有证据支撑，并声明置信度

保持审慎，运用批判性思维和顺序思维。每项主张都需要可追溯的证据和置信度百分比（创意应高于 80%）。

商业评估

第 1 步：记录创意

根据用户输入，提取：

• 一句话介绍 — 用 1 句话概述创意
• 问题 — 它解决了什么痛点？
• 解决方案 — 它如何解决问题？
• 目标客户 — 具体哪些人会从中受益？

步骤 2：商业模式画布

必须包含全部 9 个模块：

模块	关键问题	所需证据
客户细分	我们服务哪些客户？	市场调研
价值主张	我们提供什么价值？	客户痛点
渠道	我们如何触达客户？	渠道分析
客户关系	我们如何维护客户关系？	留存策略
收入来源	我们如何盈利？	定价调研
核心资源	我们需要什么？	资源评估
关键活动	我们必须做什么？	运营分析
重要合作	谁能帮助我们？	合作伙伴格局
成本结构	成本是多少？	成本分析

步骤 3：财务预测（3 年）

收入模型

年份	用户/客户	ARPU	收入	增长

成本结构

类别	Y1	Y2	Y3

盈亏平衡

• 月度现金消耗： ${X}
• 盈亏平衡点： 月份/年份
• 所需资金： ${X}

假设表

每个数字都必须列出其假设和来源。

步骤 4：风险评估

至少列出 5 项风险：

风险	可能性	影响	缓解措施	剩余风险

需考虑的类别：市场、执行、财务、竞争、监管、技术。

步骤 5：执行计划

阶段	时间线	重点	关键里程碑
验证	0-3 个月	客户探索、MVP	N 次访谈、原型
构建	3-6 个月	核心产品、早期用户	Beta 发布、首笔收入
增长	6-12 个月	扩大规模、优化	收入目标、团队规模

步骤 6：市场进入策略

• 发布策略 — 如何进入市场
• 初始渠道 — 排名前 3 的获客渠道
• 定价策略 — 模式 + 理由 + 竞争对比

步骤 7：结论

• 可行性评分： 1-10，并说明理由
• 置信度： 95%/80%/60%/<60%，并提供证据依据
• 建议： 推进 | 转型 | 暂停 | 放弃
• 关键条件： 要取得成功，必须满足什么条件？

输出

使用 .claude/templates/business-evaluation-template.md 中强制要求的模板，写入 docs/knowledge/strategy/business/{descriptive-slug}.md。

---

后续步骤

强制重要必须注意——无一例外 完成本技能后，必须注意使用 AskUserQuestion 呈现这些选项。不要因为任务看起来“简单”或“显而易见”就跳过——由用户决定：

• "/domain-analysis（推荐）" — 根据业务评估分析领域模型
• "/plan" — 如果已准备好规划实现
• "跳过，继续手动处理" — 由用户决定

[IMPORTANT] 开始前，使用 TaskCreate 将所有工作拆分为小任务。

外部记忆： 对于复杂或耗时较长的工作（研究、分析、扫描、审查），将中间发现和最终结果写入 plans/reports/ 中的报告文件——避免上下文丢失，并作为交付物。

证据门槛： 强制重要必须注意——每项声明、发现和建议都必须有 file:line 证明或可追溯的证据，并附上置信度百分比（>80% 才可采取行动，<80% 必须先核实）。

防止 AI 出错 — 每项任务都应避免以下失败模式：

上下文变化后重新读取文件。 上下文压缩、恢复或长时间运行的工作可能导致记忆过时；采取行动前，请核实当前文件。 根据源证据核实生成的内容。 AI 可能会幻觉 API、名称、声明和文档事实。记录或引用内容前，请检查相关源。 删除或重命名前检查下游引用。 移除某个产物可能导致文档、生成的镜像、配置和调用方过时；请先梳理引用关系。 编辑后追踪完整影响链。 更改定义可能会遗漏派生输出和使用方。宣布完成前，请追踪所有受影响的环节。 核实所有受影响的输出，而不只是第一个。 一个检查通过不代表所有检查都通过；请验证此更改可能影响的每个输出界面。 假定现有值是有意设置的——更改或标记缺陷前先问为什么。 更改或报告常量、限制、标志、阈值、措辞或模式前，请阅读相邻上下文和历史记录、调用方的顺序，以及 2 个或更多遵循相同约定的同类调用点。文档只说明“是什么”却未说明“为什么”，意味着缺少理由，并不能证明缺少保护条件。 行动前指出歧义——不要悄悄自行选择。 存在多种合理解释时，必须明确提问，或说明假设及其风险。 断言系统自身负责的结果，而不是基础设施负责的中间状态。 验证异步工作时，应断言最终业务状态——切勿断言由共享基础设施维护的投递／重试记录，因为任何并行运行的进程都可能写入这些记录。这类检查单独运行时会通过，但只要有其他进程共享该基础设施，就可能变得不稳定。 确保共享指南与角色相关。 通用指南必须对每个接收它的技能或 Agent 都有帮助；代码专属要求只应放在代码专属协议中。

批判性思维模式 — 运用批判性思维和顺序思维。每项声明都需要可追溯的证明；置信度 >80% 才可采取行动。 反幻觉： 绝不要将猜测当作事实陈述——每项声明都要引用来源，坦诚承认不确定性，自行检查输出错误，独立交叉核对，并对自己的信心保持怀疑——毫无证据的确信是所有幻觉的根源。

必须注意 运用批判性思维和顺序思维——每项声明都需要适当的可追溯证据（仓库／代码声明需提供 file:line；研究、产品、内容和文档声明需提供来源 URL 或产物章节）；置信度 >80% 才可采取行动，<60% 时切勿提出建议。反幻觉：绝不要将猜测当作事实陈述，坦诚承认不确定性，独立交叉核对，并对自己的信心保持怀疑。

必须注意 执行 AI 防错措施——根据证据核实生成的内容，删除或重命名前追踪下游引用，核实所有受影响的输出，上下文丢失后重新读取文件，并在行动前指出歧义。

提示词增强收尾锚点

重要，务必注意：严格遵循此技能声明的步骤顺序；未经用户明确批准，绝不跳过、重排或合并步骤。 重要，务必注意：每次执行步骤／子技能调用时，执行前将状态设为 in_progress，执行后设为 completed。 重要，务必注意：每个跳过的步骤都必须注明明确原因；每个已完成的步骤都必须提供简洁的证据。 重要，务必注意：如果 Task 工具不可用，请维护等效的逐步计划跟踪器，并同步状态。

项目协议覆盖规则 — 执行此技能之前，先解析应用于此技能的任何 PROJECT 覆盖规则：根据项目技能协议索引的 Target 列，将此技能名称与之匹配（默认位于 docs/project-reference/skill-protocols-reference.md；若 docs/project-config.json 中存在 referenceDocs 条目，则以该条目覆盖默认路径），仅采用最具体的匹配层级——精确名称 > glob > *。此优先级只用于排列覆盖规则彼此之间的顺序，绝不用于对抗此技能本身。只读取匹配条目对应的正文，路径解析为 <protocols-dir>/<Name>.md；行中的 Body 链接只是显示文本，绝不是读取路径。若匹配到的正文缺失或格式错误，应报告并跳过，绝不能根据索引中的 Description 重建。没有索引或没有匹配项 -> 不应用覆盖规则，静默继续。完整约定见 .claude/skills/project-skill-protocol/references/registry.md。

覆盖规则仅可增加内容：它们只能在此技能自身协议的基础上增加规则，绝不能替换、覆盖、禁用或重新解释已有规则——移除所有覆盖规则后，此技能必须恢复为其文档所述的确切行为。覆盖规则是简报，不是权限升级：绝不能免除工作流关卡、git 规范、审查关卡或用户确认关卡。若覆盖规则与技能本身确实冲突，或两个同等具体的覆盖规则直接矛盾 -> 将两者都告知用户；绝不静默裁决。

务必注意：执行前必须为此技能解析项目协议覆盖规则——仅采用最具体的匹配层级（精确名称 > glob > *；该顺序只用于排列覆盖规则彼此之间的优先级，绝不用于对抗此技能本身）；只读取 <protocols-dir>/<Name>.md 中匹配的正文；正文缺失或格式错误时应报告，绝不重建。覆盖规则仅可增加内容（绝不替换此技能自身的规则），且只是简报，绝不能提升权限；同等具体的规则发生矛盾时，应交由用户处理。

收尾提醒

重要，务必注意目标：给出有证据支撑的可行性结论——包括评分、置信度及 Pursue/Pivot/Pause/Pass 建议——并以完整的 9 块 BMC、注明假设的 3 年财务数据、5 项以上风险及其缓解措施，以及分阶段执行和 GTM 计划为依据，让继续／停止决策建立在可追溯的证据上，而非乐观情绪之上。

务必注意——当前生效协议（此技能所携带 SYNC／共享区块的简明摘要）：

• **防止 AI 犯错：**根据证据核实生成内容，追溯下游引用，核实所有受影响的输出，在上下文丢失后重新阅读，并明确指出歧义。
• **批判性思维：**提供可追溯的 file:line 证明，置信度 >80% 时才采取行动，绝不把猜测当作事实。

重要，务必注意：每项声明、财务数字、BMC 区块和结论都必须附带证据与置信度百分比（95/80/60/<60）——绝不把猜测当作事实——原因：没有依据的数字会让继续／停止决策变成披着分析外衣的乐观判断。 重要，务必注意：结论应偏向审慎——绝不把乐观情绪向上取整；指出必须成立的单一关键条件，以及该条件不成立时的剩余风险——原因：过度乐观的 Pursue 会耗费资金，而诚实的 Pause 本可以保住这些资金。 重要，务必注意：通过 AskUserQuestion 与用户确认下一步路线——绝不自动决定领域分析／计划——原因：此技能负责评估可行性，人类负责做出继续／停止决策。 必须高度重视 开始前，使用 TaskCreate 将工作拆分为多个小型待办任务；确保只有一个任务处于 in_progress 状态，并提供证据后将其标记为 completed；添加一个最终审核待办任务——原因：未跟踪的多步骤工作在上下文压缩时会丢失状态。 必须高度重视 将 market-analysis 中的市场数据作为证据——绝不在此处重新推导市场规模——原因：此技能用于判断可行性，而非研究市场；重复测算会导致数据偏离源头。 必须高度重视 商业模式画布（BMC）的 9 个模块必须全部呈现，且每个模块都要引用证据；每个财务数字都必须在假设表中列出其假设和来源——原因：缺少模块或没有依据的数字会形成隐性缺口，而结论会建立在这些缺口之上。 必须高度重视 至少列出 5 项风险，涵盖市场、执行、财务、竞争、监管和技术领域；每项风险都必须包含缓解措施和剩余风险条目——原因：未说明剩余风险，会让人误以为缓解措施能消除全部风险。 必须高度重视 按顺序完成全部 7 个步骤——创意 → 加载市场数据 → 9 模块 BMC → 3 年财务预测 → 至少 5 项风险 → 3 阶段执行计划（验证／构建／增长里程碑）→ 上市策略（发布 + 头部 3 个渠道 + 定价依据）→ 结论；绝不能因为觉得创意的可行性「已经有定论」而省略财务、执行或上市策略——原因：结论的可靠性取决于其所依据步骤中最薄弱的一环。 必须高度重视 在写下任何数字或结论前，先搜索 market-analysis 输出和过往评估，查找至少 3 个可比案例并引用——原因：没有可比依据的数字就是捏造。 必须高度重视 使用强制模板 .claude/templates/business-evaluation-template.md，将结果写入 docs/knowledge/strategy/business/{slug}.md——绝不能自行编写结构——原因：该模板是下游技能（domain-analysis/plan）读取的约定。 必须高度重视 对耗时较长的评估，将中间发现保存到 plans/reports/——原因：外部记忆可在上下文丢失后保留信息，并作为交付物。

反合理化：

逃避说法	驳斥
「创意显然可行，跳过严谨评估吧」	乐观不是证据。仍要完成全部 9 个模块、财务预测和风险分析。
「跳过一个 BMC 模块吧——它不相关」	每个模块都必须引用证据，或明确说明为何不适用；悄然省略会导致评估不合格。
「先估个数字，之后再找来源」	没有假设和来源，就不能列出数字。必须先填好假设表，再给出结论。
「5 项风险太多了，2 项就够」	至少 5 项，每项都要说明剩余风险。过于单薄的风险清单会掩盖真正的下行风险。
「建议已经很明确了，跳过提问吧」	仍须使用 AskUserQuestion 询问下一步路线——是否继续由人来决定。

必须高度重视 每个数字都必须附有证据和置信度百分比——绝不能把猜测当作事实。必须高度重视 保持怀疑态度——绝不能把乐观估计向上取整。必须高度重视 使用 AskUserQuestion 询问下一步路线——绝不能自动做出决定。