呱呱聚合
← 返回基因库
图像与设计

在框定新产品论点、压力测试现有战略或对齐团队商业模型假设时…

用一页九宫格精益画布把问题、客户、方案与可行性假设显式化、可测试化，适用于新产品构思、战略压力测试或方案对比。

被复用0 次
复用有效—
置信度85%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 noah.sun 的小呱沉淀
GDI C 49/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 85/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 60/100 ×0.15

适用场景

在框定新产品论点、压力测试现有战略或对齐通用

解决思路

  1. 先确定模式与意图：判断请求是 content 还是 visual；若未指定模式，默认 content 并明确说明该回退。澄清目标是新产品论点、现有业务压力测试，还是多方案并排对比；若不清楚，先询问一次再继续。
  2. 收集上下文与证据：优先使用用户提供的上下文，包括产品名称、市场、目标客户、已做研究、用户当前使用的现有替代方案、已知约束。若证据薄弱，继续生成但在 Evidence & Confidence 部分标注缺口，并相应校准每个模块的置信度。对现有业务，明确区分当前假设与已验证数据。
  3. 按推荐顺序填写九个模块（每个模块的答案会约束下一个，不要跳步）：a. Problem——按痛苦强度和频率排序的前 3 大问题，并包含 Existing Alternatives（客户今天实际在做什么，包括变通方案和不消费，而不仅是直接竞品）。b. Customer Segments——谁最强烈地拥有这些问题？把 Early Adopters 命名为你将首先触达的独立子集；他们比更广泛人群更痛苦、更易触达、更愿意尝试新方案。c. Unique Value Proposition (UVP)——用一句话做出清晰、可测试的承诺，并包含一个 High-Level Concept（“X for Y”类比）以帮助忙碌读者快速理解。d. Solution——针对前 3 大问题的前 3 大功能，与 Problem 模块一一对应；保持具体但不要过度设计，这是假设而非规格。e. Channels——触达早期采用者的免费与付费路径，区分复利型渠道（内容、SEO、社区）与展示牵引力的渠道（外呼、付费广告）。f. Revenue Streams——模式（订阅、交易、freemium、服务）、价格点、预期销量和 LTV；展示计算过程，使收入论点可被检查。g. Cost Structure——CAC、固定成本与可变成本，以及塑造增长曲线的成本驱动因素。h. Key Metrics——3 到 5 个表明模型是否有效的领先指标；AARRR（Acquisition、Activation、Retention、Revenue、Referral）是常用默认框架。i. Unfair Advantage——无法被轻易复制或购买的东西；若作为开放问题来框定，留空是可以接受的，但绝不要捏造护城河。
  4. 应用证据与置信度政策：为每个模块标注 High、Medium 或 Low 置信度，并附一行理由。填写 Evidence & Confidence 部分：Validated（有具名来源的假设）、Assumed（尚无数据）、Open Questions（需要了解什么才能提高置信度）、Governance（谁拥有画布以及何时重新审视）。标记为 High 的模块必须给出具体证据来源，而不是泛泛声明。
  5. 仅在 visual 模式下渲染并写出可视化文件：读取 references/html-template.html，它是一个完整、自包含的 HTML5 文档，使用 CSS Grid 表达经典 Maurya 九宫格布局，带每列颜色点缀、置信度徽章和 A3 横向打印样式。用 markdown 画布中的内容填充模板中的每个 {{PLACEHOLDER}} 标记：{{PRODUCT_NAME}}、{{CREATED_DATE}}、{{PURPOSE}}、{{OVERALL_CONFIDENCE}} 来自画布头部；{{PROBLEM_CONTENT}}、{{EXISTING_ALTERNATIVES}}、{{SOLUTION_CONTENT}}、{{UVP_CONTENT}}、{{HIGH_LEVEL_CONCEPT}}、{{ADVANTAGE_CONTENT}}、{{CUSTOMER_CONTENT}}、{{EARLY_ADOPTERS}}、{{METRICS_CONTENT}}、{{CHANNELS_CONTENT}}、{{COST_CONTENT}}、{{REVENUE_CONTENT}} 来自各自模块，多条目模块使用 <ul><li> 列表，单元格内容保持简洁（一行摘要，而非完整 markdown 细节）以保持可视化可扫读；{{CONF_PROBLEM}}、{{CONF_SOLUTION}}、{{CONF_UVP}}、{{CONF_ADVANTAGE}}、{{CONF_CUSTOMER}}、{{CONF_METRICS}}、{{CONF_CHANNELS}}、{{CONF_COST}}、{{CONF_REVENUE}} 用单字母 H、M 或 L 匹配各模块置信度标签，每个在模板中出现两次（一次在 class 属性用于样式，一次作为可见文本）；{{VALIDATED_COUNT}}、{{ASSUMED_COUNT}}、{{OPEN_QUESTIONS_COUNT}}、{{OWNER}}、{{NEXT_REVIEW}} 在页脚证据条中。将填充后的文档写到用户指定路径，或默认写到当前工作目录下的 ./lean-canvas-{slug}.html（其中 {slug} 为产品名小写并将非字母数字字符替换为连字符）。不要引入外部字体或 CSS 链接；模板刻意保持自包含。在 content 模式下完全跳过此步骤。
  6. 最终化为可直接使用的产物：从最终产物中移除所有模板指导性引用块（> 注释）。验证 UVP 是能改变决策且可测试的，而不是营销空话。确认 Early Adopters 是独立子集（不是 Customer Segments 的复述）。确认 Solution 模块条目与 Problem 模块条目一一对应。
  7. 满足输出契约：九个模块全部按经典顺序出现（Problem、Customer Segments、UVP、Solution、Channels、Revenue Streams、Cost Structure、Key Metrics、Unfair Advantage）；每个模块包含内容、置信度标签（High|Medium|Low）和一行理由；Evidence & Confidence 部分存在且 Validated、Assumed、Open Questions、Governance 四个子节均已填写（即使某子节有意为空，也标记为 “None” 而不是删除）；content 模式下 markdown 画布是唯一输出；visual 模式下除 markdown 画布外，还要将自包含 HTML 文件写到 ./lean-canvas-{slug}.html（或用户指定路径），HTML 由 references/html-template.html 派生、所有占位符已填充且无外部依赖，写完后向用户报告文件路径；foundation 分类：frontmatter 中无 phase: 字段，使用 classification: foundation。
  8. 按质量清单逐项核验：九个模块齐全且顺序正确；Problem 列出前 3 大问题并包含 Existing Alternatives 子节；Customer Segments 将 Early Adopters 命名为独立子集而非复述；UVP 为一句话并包含 High-Level Concept 类比（“X for Y”）；Solution 与 Problem 模块一一对应（前 3 大功能对应前 3 大问题）；Channels 区分复利型与展示牵引力型路径；Revenue Streams 展示计算过程（模式、价格、销量、LTV）；Cost Structure 命名 CAC 并识别成本驱动因素；Key Metrics 列出 3 到 5 个领先指标；Unfair Advantage 要么具体，要么明确标记为开放问题；每个模块有置信度标签（High|Medium|Low）和一行理由；Evidence & Confidence 部分四个子节均已填写；最终产物中模板指导性引用块已移除；visual 模式下生成的 .html 文件在无网络访问时能在浏览器中成功打开，每个 {{PLACEHOLDER}} 都已替换，置信度徽章颜色正确，经典 Maurya 九宫格排列可见，A3 横向打印预览能在一页内容纳画布，存在 role="img" 和 aria-label，文件路径已回报给用户；content 模式下不写 .html 文件且 markdown 中不出现可视化部分。

适用边界 · 注意事项