opencode-skills-collection 4.0.0 → 4.0.1

package/bundled-skills/product-decision-agent/references/product-playbooks.md

@@ -0,0 +1,813 @@
+# 产品工作场景手册
+
+按具体场景读取对应小节。输出时不要讲框架名，要给判断、动作和风险。
+
+## 目录
+
+1. 需求分析与优先级
+2. Roadmap 与版本规划
+3. 老板或关键相关方临时插需求
+4. 用户研究与产品探索
+5. 增长停滞
+6. 拉新、投放与 CAC 上升
+7. 激活与首次价值
+8. DAU 或流量下滑
+9. 留存下降
+10. 转化问题
+11. 商业化、会员与定价
+12. 活动效果差
+13. 社区冷启动
+14. 内容供给不足
+15. 用户运营与私域
+16. 指标异常与数据冲突
+17. A/B Test 结果异常
+18. 用户反馈互相冲突
+19. 竞品冲击
+20. 资源不足
+21. 项目延期
+22. 需求反复修改与范围失控
+23. 跨部门协作
+24. 团队冲突
+25. OKR/KPI 与目标拆解
+26. 复盘
+27. 大客户定制需求
+28. 发布事故、评分下滑与质量问题
+29. Push、消息与用户打扰
+30. 平台供给质量与信任
+31. 风控、作弊与滥用
+32. 内部工具 adoption 低
+33. AI 功能或技术热点
+34. 合规、法务与硬截止
+35. 出海、本地化与新市场
+36. 战略转向与业务模式选择
+
+## 1. 需求分析与优先级
+
+**核心判断**：哪个用户或业务结果被卡住，哪个需求能解除这个阻塞。
+
+先判断：
+
+- 这是用户问题、业务目标、内部效率、合规要求，还是相关方偏好。
+- 这个需求希望改变哪个用户行为或业务指标。
+- 如果本周期不做，真实损失是什么。
+- 它是新能力、Bug、合规、增长、留存、转化，还是运营效率。
+
+建议：
+
+- 按结果归类需求，不按提出人归类。
+- 把模糊需求改写成：“为某类用户，在某个场景，改变某个行为或指标。”
+- 资源紧时只保留一个主攻需求，加一个取证需求。
+- 两个需求冲突时，比机会成本、风险和可逆性，不比谁声音更大。
+
+不要：
+
+- 按老板、销售、运营谁更急来排序。
+- 在硬约束存在时，还套平均评分模型。
+- 接受“解决方案式需求”而不追问背后的问题。
+
+## 2. Roadmap 与版本规划
+
+**核心判断**：这个版本结束后，产品必须比今天多证明什么。
+
+先判断：
+
+- 当前阶段：探索、验证、PMF、增长、规模化、成熟优化、危机。
+- 版本目标：证明价值、提升激活、提高留存、降低成本、支持销售、稳定系统。
+- 资源边界：人力、时间、依赖、硬截止日期。
+
+建议：
+
+- 一个版本只设一个主主题和 2-4 个可衡量结果。
+- 区分承诺交付、实验验证和调研探索。
+- 明确停止清单：本版本不做什么。
+- 把平台建设、增长实验和业务承诺拆到不同节奏管理。
+
+不要：
+
+- 做一张每个团队都照顾到、但没有重心的 Roadmap。
+- 把探索、增长、平台重构同时塞进一个小版本。
+
+## 3. 老板或关键相关方临时插需求
+
+**核心判断**：这是战略信号、业务承诺、权力覆盖，还是临时焦虑。
+
+先判断：
+
+- 对方真正关心收入、留存、客户承诺、合规、声量，还是展示。
+- 为什么现在急。
+- 插入后要挤掉什么。
+- 这个需求是否可逆，是否能用小版本验证。
+
+建议：
+
+- 先承接目标，不直接承诺方案。
+- 给三个选择：现在做但砍掉某项；先做 1-2 天验证；进入下个版本。
+- 用一页纸写清代价：延期、砍需求、风险、影响指标。
+- 如果必须做，压到最小可上线闭环。
+
+不要：
+
+- 只说“不行”。
+- 默默吞下范围，最后毁掉版本。
+- 把优先级冲突伪装成体验讨论。
+
+## 4. 用户研究与产品探索
+
+**核心判断**：现在要验证的是问题是否真实，不是方案是否漂亮。
+
+先判断：
+
+- 目标用户是谁，真实场景是什么。
+- 用户现在如何解决，成本在哪里。
+- 用户是否愿意付出时间、钱、关系或数据。
+
+建议：
+
+- 用 5-10 个目标用户做深访，必须看真实操作或真实记录。
+- 访谈后输出用户任务、当前替代方案、痛点强度、付费或使用信号。
+- 能人工服务就先人工服务，不急着做系统。
+
+不要：
+
+- 用泛问卷代替一线观察。
+- 只问“你会不会用”，不看用户现在怎么做。
+
+## 5. 增长停滞
+
+**核心判断**：增长被拉新、激活、留存、转化、复购/分享、渠道饱和中的哪一环卡住。
+
+先判断：
+
+- 拆增长树：流量、激活、留存、转化、复购、分享。
+- 按 cohort 和渠道看变化。
+- 示例拆法：按渠道 cohort 看“新用户注册 -> 激活 -> D7 留存 -> 付费 -> 分享”，找最先掉下来的环节。
+- 判断是新用户质量变差，还是产品循环变弱。
+
+建议：
+
+- 先修最弱的一环。
+- 激活弱，先修第一次价值体验，再买量。
+- 留存弱，先停掉无效放量。
+- 渠道饱和，再测相邻渠道，但要明确人群和卖点。
+
+不要：
+
+- 把增长等同于多做活动。
+- 留存或激活没修好就加大投放。
+
+## 6. 拉新、投放与 CAC 上升
+
+**核心判断**：CAC 上升通常不是单纯投放问题，而是渠道、人群、承诺和承接效率共同变化。
+
+先判断：
+
+- 哪些渠道 CAC 上升，哪些 cohort 后续留存或付费变差。
+- 创意承诺和产品实际价值是否不匹配。
+- 是否已经触达原有渠道的高质量人群上限。
+
+建议：
+
+- 暂停 ROI 最差且留存最差的人群包。
+- 对高意向人群重测卖点，不先扩大预算。
+- 用 7 日或 14 日 cohort 判断渠道质量，而不只看注册成本。
+
+不要：
+
+- 用更大补贴掩盖承接差。
+- 只优化素材点击率，不看后链路质量。
+
+## 7. 激活与首次价值
+
+**核心判断**：用户注册后没有快速到达第一次价值体验。
+
+先判断：
+
+- 新用户第一次成功行为是什么。
+- 从注册到该行为有几步、最大掉点在哪里。
+- 不同渠道和设备的新用户是否掉在同一步。
+
+建议：
+
+- 把首次价值路径压到最短，优先砍非必要字段和选择。
+- 对关键人群做引导、默认样例、人工辅助或新手任务。
+- 用激活率、首次价值用时、D1/D7 留存联动判断。
+
+不要：
+
+- 新用户还没感到价值，就做复杂会员、积分或社交体系。
+
+## 8. DAU 或流量下滑
+
+**核心判断**：下滑来自新用户、老用户、使用频次、内容供给、渠道、版本、季节性，还是埋点。
+
+先判断：
+
+- 拆新老用户、渠道、平台、地域、版本、cohort。
+- 查发布记录、埋点变更、Push 策略、内容供给、分发规则、外部渠道变化。
+- 区分一次性冲击和持续趋势。
+
+建议：
+
+- 先排除数据口径和技术问题。
+- 找贡献下滑最大的用户群或渠道。
+- 对最大贡献段做恢复动作，不做全站泛活动。
+- 急性下滑设置 24-72 小时监控窗口。
+
+不要：
+
+- 只看总 DAU。
+- 没确认来源就上线新功能或全站活动。
+
+## 9. 留存下降
+
+**核心判断**：用户没有到达价值、价值不再重复，还是引入了更差的新 cohort。
+
+先判断：
+
+- 按渠道、人群、版本、首个关键行为拆 cohort 留存。
+- 看掉点发生在首次价值前、首次价值后，还是长期使用中。
+- 找目标 cohort 的行为路径和反馈。
+
+建议：
+
+- 早期留存掉，修 onboarding 和第一次价值。
+- 中后期留存掉，修内容/供给新鲜度、核心任务深度或习惯触发。
+- 渠道 cohort 变差，调整投放人群和承诺。
+
+不要：
+
+- 用 Push 硬拉留存。
+- 把短期活跃技巧当长期价值。
+
+## 10. 转化问题
+
+**核心判断**：阻塞来自流量质量、价值表达、信任、价格、流程摩擦，还是时机不对。
+
+先判断：
+
+- 找漏斗最大异常掉点。
+- 比高意向和低意向用户。
+- 看客服、销售、退款、用户访谈里的真实反对理由。
+
+建议：
+
+- 价值没讲清，先修表达。
+- 信任不足，先补证明和保障。
+- 价格犹豫，先修套餐和锚点，不先乱打折。
+- 每次只测一个关键摩擦。
+
+不要：
+
+- 不知道掉点就重做全漏斗。
+- 用优惠掩盖价值不清。
+
+## 11. 商业化、会员与定价
+
+**核心判断**：用户愿意付费的价值点、付费时机和套餐边界没有被验证清楚。
+
+先判断：
+
+- 付费对象是个人、团队、商家还是企业。
+- 用户买的是效率、确定性、身份、权益、资源，还是风险降低。
+- 价格阻力来自价值不清、预算不足、信任不足，还是套餐设计不合理。
+
+建议：
+
+- 先找最有支付意愿的细分人群做小范围验证。
+- 套餐只围绕 1-2 个核心价值分层，不堆权益。
+- 设置退款、续费、使用深度作为护栏。
+
+不要：
+
+- 在价值没验证前做复杂会员体系。
+- 为了短期收入透支核心体验或信任。
+
+## 12. 活动效果差
+
+**核心判断**：活动失败在目标人群、利益点、时机、渠道，还是参与路径。
+
+先判断：
+
+- 拆曝光、点击、参与、转化、复访。
+- 找用户第一次没有按预期行动的节点。
+- 判断奖励是否匹配用户动机。
+
+建议：
+
+- 修正一个关键假设后小范围重跑。
+- 按人群保留学习，不要只看总结果。
+- 如果只带来低质量用户，停止放大。
+
+不要：
+
+- 用一次活动失败证明“用户不喜欢活动”。
+- 没修相关性就提高奖品成本。
+
+## 13. 社区冷启动
+
+**核心判断**：第一批用户为什么回来互动，这个循环是否成立。
+
+先判断：
+
+- 种子用户是谁。
+- 用户获得身份、关系、实用价值、交易机会，还是情绪陪伴。
+- 网络效应没起来前，谁来提供内容和回应。
+
+建议：
+
+- 从一个窄人群或窄话题开始。
+- 手工种高质量内容和互动。
+- 给早期用户可见反馈、身份感或即时收益。
+- 看重复参与，不看注册数。
+
+不要：
+
+- 功能做很全但场子是空的。
+- 邀很多泛用户进来。
+
+## 14. 内容供给不足
+
+**核心判断**：供给不足是创作者动力、选题方向、生产成本、分发反馈还是质量标准的问题。
+
+先判断：
+
+- 按创作者层级、题材、频率、质量、分发效果拆。
+- 问清创作者为什么停更：没流量、没收益、标准不清、太费劲、工具差。
+
+建议：
+
+- 先定义对留存最关键的内容坑位。
+- 只招募或补贴能填这个坑位的创作者。
+- 降低生产成本，快速给反馈。
+- 先建质量底线，再扩数量。
+
+不要：
+
+- 没定义有效供给就疯狂拉创作者。
+- 用数量激励破坏质量。
+
+## 15. 用户运营与私域
+
+**核心判断**：运营动作是否改变了关键用户行为，而不是只增加触达次数。
+
+先判断：
+
+- 运营目标是激活、复购、续费、召回、转介绍，还是服务。
+- 用户是否有回来的理由和承接内容。
+- 群、企微、短信、Push 是否对同一用户过度触达。
+
+建议：
+
+- 先围绕一个关键行为设计运营链路。
+- 把用户按价值、生命周期、意图分层，不群发同一话术。
+- 用转化、复访、退订、投诉作为共同指标。
+
+不要：
+
+- 把私域当免费流量池。
+- 用频繁触达替代价值供给。
+
+## 16. 指标异常与数据冲突
+
+**核心判断**：这是用户行为变化，还是口径、埋点、同步、归因问题。
+
+排查顺序：
+
+1. 指标定义或埋点是否改过。
+2. 数据延迟、去重、归因、ETL 是否异常。
+3. 产品发布或实验是否影响。
+4. 渠道或用户结构是否变化。
+5. 是否真有行为变化。
+
+建议：
+
+- 先统一口径和事实表。
+- 用原始日志、不可变指标或第三方数据校验。
+- 给出置信度和对决策的影响。
+
+不要：
+
+- 还没统一定义就争论仪表盘。
+- 基于可能坏掉的指标直接行动。
+
+## 17. A/B Test 结果异常
+
+**核心判断**：结果是否有效、可解释、值得决策。
+
+先判断：
+
+- 样本量、随机分流、曝光、护栏指标、季节性、重叠实验、埋点一致性。
+- 分人群是否方向一致。
+
+建议：
+
+- 实验设计有问题，修正后重跑。
+- 主指标赢但护栏伤害大，不直接全量。
+- 只有特定人群赢，就只对该人群灰度。
+
+不要：
+
+- 看完数据再选自己喜欢的解释。
+- 用点击率替代业务结果。
+
+## 18. 用户反馈互相冲突
+
+**核心判断**：哪个反馈来自当前最重要的用户群和行为场景。
+
+先判断：
+
+- 用户分层：付费、高频、高潜、低频、流失。
+- 反馈代表痛点、偏好、边缘场景，还是战略信号。
+- 反馈是否有行为证据支撑。
+
+建议：
+
+- 按用户价值、目标人群和行为证据加权。
+- 示例：高价值付费用户的反馈权重应高于声音大的边缘用户；高频行为证据高于一次性吐槽。
+- 把冲突反馈转成不同人群的产品选择。
+- 如果冲突来自定位不清，先收窄产品承诺。
+
+不要：
+
+- 平均所有反馈。
+- 被声音最大的边缘用户带偏。
+
+## 19. 竞品冲击
+
+**核心判断**：竞品打的是核心价值、渠道、价格、信任，还是用户心智。
+
+先判断：
+
+- 哪些用户在转移，为什么转移。
+- 竞品优势是否可持续。
+- 竞品在哪些场景看起来强但其实不适配。
+
+建议：
+
+- 先防守自己的核心场景。
+- 不复制功能清单，只学习改变用户选择的机制。
+- 找自己优势更尖锐的人群加深。
+
+不要：
+
+- 在对手最强的战场硬拼。
+- 把 Roadmap 变成竞品反应清单。
+
+## 20. 资源不足
+
+**核心判断**：最稀缺资源应该投到哪个结果杠杆上。
+
+先判断：
+
+- 稀缺的是研发、设计、运营、预算、数据、法务，还是管理层注意力。
+- 哪些工作要停止、延期、降级或人工处理。
+
+建议：
+
+- 先砍范围，再谈加班。
+- 保护一个决定性结果。
+- 能用人工或低代码验证的，不先消耗研发。
+
+不要：
+
+- 用更少的人继续承诺同样 Roadmap。
+- 把关键岗位拆散到一堆低价值任务。
+
+## 21. 项目延期
+
+**核心判断**：延期来自范围、依赖、质量风险、决策延迟，还是隐藏工作。
+
+先判断：
+
+- 关键路径、阻塞人、范围变化、未决事项、验收标准。
+- 截止时间、范围、质量、资源哪个可以调整。
+
+建议：
+
+- 围绕关键路径重排计划。
+- 冻结范围或拆版本。
+- 提前给四种选择：小版本上线、延期、加资源、接受风险。
+
+不要：
+
+- 加会议但不改变权限和范围。
+- 到 deadline 才暴露延期。
+
+## 22. 需求反复修改与范围失控
+
+**核心判断**：问题不是大家想法多，而是问题定义、验收标准和变更代价没有锁住。
+
+先判断：
+
+- 每次修改是在改目标、改方案、改验收，还是补遗漏。
+- 谁有权改变范围，改变后挤掉什么。
+- 变更是否来自真实用户证据或只是会议偏好。
+
+建议：
+
+- 先锁问题定义和成功指标，再讨论方案。
+- 建立变更规则：新增必须替换同等工作量或进入下个版本。
+- 把已决事项、未决事项、变更代价写在同一页。
+
+不要：
+
+- 每次评审都重新打开方向讨论。
+- 用“敏捷”包装无边界变更。
+
+## 23. 跨部门协作
+
+**核心判断**：团队之间没对齐的是目标、优先级、激励、权限，还是信息。
+
+先判断：
+
+- 谁背结果。
+- 谁承担成本。
+- 各团队分别优化什么指标。
+- 哪个决策没有明确负责人。
+
+建议：
+
+- 先对齐共同结果和决策人。
+- 把抽象冲突变成取舍选项。
+- 用小试点降低对方风险。
+
+不要：
+
+- 把激励冲突说成沟通问题。
+- 只要求配合，却不降低对方真实成本。
+
+## 24. 团队冲突
+
+**核心判断**：冲突来自目标、方法、资源、边界、信任，还是能力表现。
+
+先判断：
+
+- 区分事情冲突和人际冲突。
+- 权责是否匹配。
+- 大家一直绕开的真实决策是什么。
+
+建议：
+
+- 把真实决策摆出来。
+- 先约定决策规则，再讨论方案。
+- 信任受损时，用短周期承诺和可观察结果修复。
+
+不要：
+
+- 强行制造表面和谐。
+- 只批评个人，不改协作机制。
+
+## 25. OKR/KPI 与目标拆解
+
+**核心判断**：目标是否是团队能影响的结果。
+
+先判断：
+
+- 滞后指标和前置指标。
+- 可控部分和不可控部分。
+- 每个团队对目标的贡献路径。
+
+建议：
+
+- 只选一个主业务结果或北极星指标。
+- 用驱动树拆目标。
+- 给前置指标配负责人和复盘节奏。
+- 设置停止标准和预警线。
+
+不要：
+
+- 把 OKR 写成任务清单。
+- 给所有团队同一个高层 KPI，但不拆贡献逻辑。
+
+## 26. 复盘
+
+**核心判断**：哪条关键假设错了，下次机制怎么变。
+
+先判断：
+
+- 预期和实际差在哪里。
+- 错的是用户、渠道、产品、执行、数据、相关方，还是时机。
+- 有没有早期信号，为什么没被看到或没被处理。
+
+建议：
+
+- 只抓 1-3 个根因。
+- 每个根因对应一个机制改变和负责人。
+- 保留有效做法，不要把复盘写成全盘否定。
+
+不要：
+
+- 停在“沟通不够”。
+- 没有机制变化的复盘等于没复盘。
+
+## 27. 大客户定制需求
+
+**核心判断**：大客户需求首先是收入机会、交付承诺和产品复用性的取舍。
+
+先判断：
+
+- 合同金额、上线期限、违约风险和销售承诺。
+- 同类客户数量、复用概率、维护成本。
+- 需求是通用能力、配置项、一次性交付，还是专属服务。
+
+建议：
+
+- 把需求拆成产品化、配置化、交付服务三类。
+- 只把高复用能力进 Roadmap。
+- 专属部分要收费、限期、限维护范围。
+
+不要：
+
+- 让单个客户直接改写产品主线。
+- 简单拒绝收入机会而不给替代交付方案。
+
+## 28. 发布事故、评分下滑与质量问题
+
+**核心判断**：先判断问题影响范围和是否需要回滚，再谈体验优化。
+
+先判断：
+
+- 影响哪些版本、设备、渠道、关键路径和核心用户。
+- 是功能 bug、性能问题、预期落差、客服响应，还是灰度策略问题。
+- 是否正在造成收入、留存、口碑或合规损失。
+
+建议：
+
+- 先止血：回滚、降级、热修、公告或客服脚本。
+- 24 小时内建立版本、设备、路径、反馈的对应表。
+- 修复后看负评率、崩溃率、关键路径完成率。
+
+不要：
+
+- 先争论责任。
+- 影响核心链路时还等下个大版本。
+
+## 29. Push、消息与用户打扰
+
+**核心判断**：消息触达正在透支用户信任，还是核心提醒没有被正确分层。
+
+先判断：
+
+- 哪些消息带来留存或转化，哪些只带来退订、卸载和投诉。
+- 用户意图、生命周期和频控是否区分。
+- 推送内容是否有真实价值承接。
+
+建议：
+
+- 先停掉低价值高退订消息。
+- 把消息分成交易/服务提醒、内容召回、营销转化三类管理。
+- 用 opt-out、卸载、打开后行为作为护栏。
+
+不要：
+
+- 用更高频次弥补内容或价值不足。
+
+## 30. 平台供给质量与信任
+
+**核心判断**：供给质量低于用户信任底线，会先破坏核心循环，再影响增长。
+
+先判断：
+
+- 哪类供给造成最多退款、投诉、差评或流失。
+- 质量问题来自准入、审核、履约、评价、分发还是激励。
+- 哪些品类或场景必须先守住底线。
+
+建议：
+
+- 先定义质量底线和红线场景。
+- 对最影响信任的品类先准入、抽检、降权或清退。
+- 把优质供给的曝光和收益绑定到质量指标。
+
+不要：
+
+- 在质量底线没守住时继续拉供给数量。
+
+## 31. 风控、作弊与滥用
+
+**核心判断**：作弊上升会改变用户、商家或平台激励，必须先稳住信任和成本。
+
+先判断：
+
+- 作弊影响收入、补贴、内容质量、交易安全还是账号生态。
+- 黑产路径、受益对象、成本承担者是谁。
+- 当前规则是否误伤正常用户。
+
+建议：
+
+- 先保护核心链路和高风险人群。
+- 用规则、模型、人工审核和限额分层处理。
+- 设置误伤率、拦截率、申诉率作为护栏。
+
+不要：
+
+- 只追求拦截率，伤害正常用户。
+- 风险没稳住就继续加补贴。
+
+## 32. 内部工具 adoption 低
+
+**核心判断**：工具没有进入真实工作流，或没有解决使用者的激励和成本问题。
+
+先判断：
+
+- 使用者原来怎么完成任务，新工具增加还是减少步骤。
+- 经理想要的价值和一线员工想要的价值是否一致。
+- 是否缺培训、数据、权限、集成或强制场景。
+
+建议：
+
+- 跟 3-5 个真实用户 shadow 一次完整流程。
+- 先打通一个高频任务，不做全功能平台。
+- 找一个团队做试点，用节省时间、错误率、完成率判断。
+
+不要：
+
+- 把低使用归因于“不愿学习”。
+
+## 33. AI 功能或技术热点
+
+**核心判断**：先确认用户问题和业务结果，不要从技术能力反推需求。
+
+先判断：
+
+- AI 解决的是效率、质量、成本、转化、风控，还是只是展示。
+- 目标用户是否愿意把关键任务交给 AI。
+- 输出错误的成本和人工兜底方式是什么。
+
+建议：
+
+- 先用人工或半自动方式验证任务价值。
+- 选低风险、高频、可校验的场景做 MVP。
+- 指标看任务完成率、节省时间、采纳率、错误成本。
+
+不要：
+
+- 为了“有 AI”改 Roadmap。
+- 不要先有 AI 能力再去找场景；先找高频、高成本、可校验的用户任务。
+- 在高风险任务上没有兜底就全量。
+
+## 34. 合规、法务与硬截止
+
+**核心判断**：硬约束会覆盖普通优先级，但仍要控制范围。
+
+先判断：
+
+- 截止时间、处罚风险、最低合规要求和可延期部分。
+- 哪些能力必须上线，哪些只是锦上添花。
+- 是否影响核心用户路径或收入。
+
+建议：
+
+- 先做最低可合规版本。
+- 明确被挤掉的需求和业务影响。
+- 合规上线后再补体验和自动化。
+
+不要：
+
+- 把合规需求和普通需求放同一评分表。
+- 借合规名义扩成大重构。
+
+## 35. 出海、本地化与新市场
+
+**核心判断**：新市场失败通常不是翻译问题，而是渠道、信任、支付、供给和使用场景不匹配。
+
+先判断：
+
+- 哪个国家/地区、哪类人群、哪个场景先打。
+- 本地获客渠道、支付习惯、信任背书、合规要求。
+- 原有核心价值是否仍然成立。
+
+建议：
+
+- 只选一个市场和一个场景做验证。
+- 找本地渠道和用户样本，不用国内经验硬套。
+- 先验证渠道-卖点-产品承接，再规模投入。
+
+不要：
+
+- 同时铺多个国家。
+- 把本地化等同于语言翻译。
+
+## 36. 战略转向与业务模式选择
+
+**核心判断**：是否转向，不看新方向多诱人，而看旧方向的核心假设是否被证伪、新方向是否有更强证据。
+
+先判断：
+
+- 旧方向失败的是用户需求、商业模式、渠道、供给、组织能力，还是时机。
+- 新方向有没有真实用户、付费信号、可复用能力和资源匹配。
+- 转向会丢掉哪些资产和用户。
+
+建议：
+
+- 先写一页决策备忘录：旧假设、证据、新假设、验证计划、停止标准。
+- 用 2-4 周验证新方向的一个核心假设，不直接全团队切换。
+- 明确转向代价：放弃的用户、沉没资产、团队能力缺口和短期收入影响。
+- 保留旧方向中可迁移的用户、数据、技术和渠道资产。
+- 给旧方向设一个清晰的停止标准，避免两边同时消耗资源。
+
+不要：
+
+- 因为短期焦虑频繁换方向。
+- 因为新方向热闹就全面转向。
+- 在没有真实用户信号前，把原 Roadmap 全部砍掉。
+- 没有停止标准就同时做两条主线。