opencode-skills-collection 3.1.23 → 4.0.1

package/bundled-skills/product-decision-agent/references/reasoning-engine.md

@@ -0,0 +1,289 @@
+# 产品决策推理引擎
+
+当用户的问题复杂、信息不足、症状很多、内部意见冲突或涉及资源取舍时，读取本文件。这里是后台工作手册，最终回答仍要转成中文产品语言，不要暴露方法来源。
+
+## 目录
+
+1. 决策闭环
+2. 事实与假设
+3. 核心阻塞
+4. 主导机制与变化条件
+5. 阶段判断
+6. 证据质量与充分性
+7. 用户、相关方与冲突形式
+8. 行动模式
+9. 实验与验证
+10. 资源集中与停止清单
+11. 输出组装
+12. 常见误判
+
+## 1. 决策闭环
+
+后台按这个顺序想：
+
+1. **目标**：用户到底想改变哪个结果。
+2. **现象**：表面症状是什么，是否只是用户的说法。
+3. **机制**：是什么用户行为、产品机制、市场变化、数据口径或组织机制导致了现象。
+4. **核心阻塞**：当前最决定结果的瓶颈是什么。
+5. **主导机制**：核心阻塞内部，哪项力量、行为或规则当前主导结果。
+6. **阶段**：产品、业务、项目或团队处在哪个阶段。
+7. **约束**：资源、时间、权限、供给、流量、信任、数据、激励中哪个最硬。
+8. **相关方**：谁背结果、谁执行、谁否决、谁承担成本、谁受益。
+9. **证据**：来源是否可靠，哪些事实够用，哪些只是推断，哪些必须验证。
+10. **变化条件**：什么信号出现时加码、停止、回滚或换打法。
+11. **行动**：现在该决策、诊断、验证、排序、谈判、停止还是升级。
+12. **复盘信号**：用什么指标或事实判断下一步有效。
+
+不要把这 12 步原样输出给用户，除非用户明确要求方法框架。
+
+## 2. 事实与假设
+
+先把信息分成四类：
+
+- **硬事实**：已发生的行为、数据、上线记录、合同、资源、截止时间。
+- **一线材料**：用户原话、客服/销售反馈、运营观察、研发阻塞、真实使用路径。
+- **判断假设**：用户或团队对原因的解释。
+- **解决方案诉求**：别人已经提出的功能、活动、投放、流程或组织动作。
+
+处理原则：
+
+- 不把“用户说想要功能”直接当成需求，要追到场景、行为和结果。
+- 不把“老板说要做”直接当成优先级，要追到业务压力和代价。
+- 不把“数据涨跌”直接当成业务结论，要先查口径、分层和贡献段。
+- 信息不足时，不要追问一堆问题；先给基于当前信息的判断，再给最小取证动作。
+- 不照搬行业案例或所谓最佳实践；先检查案例前提是否和当前人群、阶段、渠道、资源一致。
+- 不用少量高声量反馈代替行为证据，也不因只有数据就忽略真实操作路径。
+
+## 3. 核心阻塞
+
+一个问题可以被判定为核心阻塞，通常满足至少两条：
+
+- 解决它，多个其他问题会随之缓解。
+- 不解决它，其他优化效果都很弱。
+- 它解释了为什么之前的办法没用。
+- 它离用户行为或业务结果足够近，而不是内部偏好。
+- 它在用户当前权限或可升级范围内能被改变。
+
+好的表述：
+
+- “新用户没有在 10 分钟内到达第一次价值体验。”
+- “内容供给不稳定，导致留存动作没有承载物。”
+- “团队还没确认真正愿意付费的目标人群，就在优化付费按钮。”
+- “Roadmap 争论本质是资源分配冲突，不是功能排序冲突。”
+
+差的表述：
+
+- “体验不好。”
+- “数据要完善。”
+- “团队要协同。”
+- “需要做增长。”
+
+## 4. 主导机制与变化条件
+
+找到核心阻塞后，再判断是什么在阻塞内部主导结果。这一步防止把两个相关现象直接拼成因果。
+
+常见的主导机制：
+
+- **供需关系**：是有效需求不足，还是供给数量、质量或稳定性不足。
+- **价值与摩擦**：是用户没有感知价值，还是路径、价格、信任、性能阻止用户到达价值。
+- **增量与承接**：是流量不足，还是激活、留存、履约能力接不住流量。
+- **目标与激励**：是团队不知道做什么，还是知道但考核、权责、成本结构让其不愿做。
+- **规则与行为**：是个别执行问题，还是流程、分配、准入或决策规则持续制造同类问题。
+
+然后写出变化条件：
+
+- 哪个指标或事实改变，说明主导机制已切换。
+- 哪个阈值出现，应该加码、停止、回滚或升级。
+- 哪个依赖解除后，下一优先级才有意义。
+- 当前只是随机波动、持续积累，还是已经跨过会改变产品阶段或用户行为的阈值。
+- 哪个领先指标能在结果指标明显恶化前发出信号。
+
+例：社区 DAU 下滑的核心阻塞可能是内容供给，但真正主导结果的是核心创作者连续流失。只有创作者周留存和有效内容量恢复后，拉新活动才值得重启。
+
+## 5. 阶段判断
+
+同一个动作在不同阶段价值完全不同。先判断阶段，再给方案。
+
+| 阶段 | 关键问题 | 优先动作 | 常见坑 |
+|---|---|---|---|
+| 探索期 | 问题是否真实存在 | 访谈、观察、人工服务、问题验证 | 太早做完整产品 |
+| 验证期 | 用户是否愿意用或付费 | MVP、原型、烟囱测试、灰度 | 没证明价值就优化体验 |
+| PMF 寻找期 | 哪个细分人群和场景会重复使用 | 收窄人群、打深核心链路 | 过早扩品类扩人群 |
+| 增长期 | 哪个渠道或循环可放大 | 聚焦增长实验、建立节奏 | 多渠道平均用力 |
+| 规模化期 | 系统和组织能否承载规模 | 标准化、自动化、稳定性 | 继续靠人工救火 |
+| 成熟优化期 | 边际 ROI 最高在哪里 | 漏斗、留存、定价、效率优化 | 追新概念 |
+| 危机期 | 先止住哪类损失 | 止血、保护核心用户、重排优先级 | 照常执行 Roadmap |
+| 组织对齐期 | 谁需要改变行为 | 权责、激励、依赖、决策机制 | 把人和激励问题当成功能问题 |
+
+阶段不明确时，先说明阶段假设，再问一个会改变判断的问题。
+
+## 6. 证据质量与充分性
+
+先判断证据来源，再判断数量是否足够：
+
+1. **直接行为与结果**：交易、留存、日志、录屏、真实任务完成情况。
+2. **一线材料**：用户访谈、客服工单、销售记录、运营观察、研发阻塞记录。
+3. **可追溯汇总**：口径明确、能回到原始事件的数据和研究结论。
+4. **二手判断**：会议转述、老板印象、竞品故事、行业文章。
+5. **孤立个案**：单个强烈反馈或未经核验的异常样本。
+
+关键决策尽量让不同来源互相印证。证据冲突时，先查定义、人群、时间窗口和采集链路，不做平均折中。
+
+### 足够行动
+
+适用：动作低风险、可回滚，或证据已经明显指向一个方向。
+
+输出：明确建议、取舍、时间窗口、复盘指标。
+
+### 需要快速验证
+
+适用：方向可能对，但不确定性会影响投入。
+
+输出：1 天到 1 个迭代内能产生决策证据的小实验。
+
+### 需要先诊断
+
+适用：同一个现象可能由多个机制导致，贸然行动成本高。
+
+输出：窄口径诊断，不做泛调研。
+
+只问会改变决策的问题：
+
+- 目标用户或目标客户是谁。
+- 当前基线指标和趋势是什么。
+- 漏斗最大掉点在哪一步。
+- 可用资源和硬截止时间是什么。
+- 决策人、执行人、否决人是谁。
+- 过去试过什么，为什么没成。
+
+## 7. 用户、相关方与冲突形式
+
+### 用户分层
+
+按对结果的影响排序，不按声音大小排序：
+
+- 高价值付费用户。
+- 高频核心用户。
+- 高潜转化用户。
+- 供给侧关键用户，如创作者、商家、达人、服务商。
+- 新用户和流失用户。
+- 边缘低频用户。
+
+反馈冲突时，按目标人群、行为证据、商业价值、战略阶段加权。
+
+### 相关方地图
+
+组织协作类问题要先看人和目标：
+
+- **结果负责人**：最终背指标或业务结果的人。
+- **执行负责人**：真正要做事的人。
+- **否决人**：能卡住推进的人。
+- **受益人**：成功后获得收益的人。
+- **成本承担者**：承担时间、预算、信誉、运维成本的人。
+- **中间人群**：没有强反对，但需要证据争取的人。
+
+对齐动作不是“加强沟通”，而是：
+
+- 把方案连接到对方指标。
+- 降低对方成本或风险。
+- 做可回滚的小试点。
+- 让取舍和后果可见。
+- 区分原则问题和执行细节。
+
+不同冲突要用不同处理方式：
+
+- 数据冲突：统一口径并回到原始记录。
+- 资源冲突：公开取舍、挤出项和决策人。
+- 目标冲突：先确认共同结果，再谈方案。
+- 权责冲突：明确谁拍板、谁承担后果，必要时升级。
+- 假设冲突：用最小实验取证，不靠会议投票。
+- 硬约束冲突：先满足合规、安全、现金流或交付底线，再优化体验。
+
+## 8. 行动模式
+
+每次优先选择一个主模式，不要什么都说一点。
+
+| 模式 | 适用情况 | 输出重点 |
+|---|---|---|
+| 立即决策 | 事实足够，风险可控 | 明确建议、取舍和代价 |
+| 快速验证 | 主要不确定性是用户反应或 ROI | MVP、A/B、灰度、人工验证 |
+| 先诊断 | 根因不明 | 指标拆解、用户样本、日志或口径检查 |
+| 排序 | 多件事都重要但资源不够 | 顺序、依赖、停止清单 |
+| 谈判对齐 | 相关方冲突阻塞推进 | 相关方地图、共同目标、底线和替代方案 |
+| 停止投入 | 继续做只会消耗资源 | 停止标准、沉没成本处理、对外说法 |
+| 升级决策 | 权限和责任不匹配 | 决策备忘录、升级路径、需拍板事项 |
+
+## 9. 实验与验证
+
+好的验证要“小、快、能改决策”。
+
+必须说清：
+
+- 假设是什么。
+- 目标人群是谁。
+- 在哪里验证。
+- 最小实现方式是什么。
+- 成功指标是什么。
+- 失败指标是什么。
+- 持续多久或需要多少样本。
+- 结果出来后怎么决策。
+
+优先选择：
+
+- 人工服务先于平台化建设。
+- 落地页或烟囱测试先于完整功能。
+- 分 cohort 留存先于总量活跃。
+- 手工运营先于自动化。
+- 灰度先于全量。
+- 小范围真实客户试点先于全公司流程改造。
+
+不要做无法改变决策的实验。
+
+## 10. 资源集中与停止清单
+
+资源不足时，优先一个决定性动作加一个取证动作。
+
+判断维度：
+
+1. **结果杠杆**：是否直接影响目标指标。
+2. **阶段匹配**：是否符合当前阶段。
+3. **约束解除**：是否解决核心阻塞。
+4. **证据强度**：是否有数据、用户行为、失败经验支撑。
+5. **执行成本**：人力、时间、复杂度、依赖。
+6. **可逆性**：能否低成本回滚或学习。
+
+停止清单常见对象：
+
+- 当前阶段无法证明价值的完整平台建设。
+- 没有承接能力的投放和补贴。
+- 只为单个低复用客户做的产品主线改造。
+- 没有成功/失败标准的 A/B Test。
+- 没有负责人和代价说明的临时插入需求。
+- 只制造短期数据噪音的全站活动。
+
+## 11. 输出组装
+
+默认输出：
+
+1. **问题判断**：一句话指出真正问题。
+2. **原因分析**：2-4 条，解释为什么是这个问题。
+3. **行动建议**：1-3 个动作，包含时间、对象、指标或决策口径。
+4. **风险提醒**：现在不要做什么。
+5. **需要确认**：最多 3 个，只问会改变判断的事实。
+
+短答也要保留“判断 + 下一步”。不要把内部框架完整讲出来。
+
+## 12. 常见误判
+
+- 把症状当原因。
+- 找到核心阻塞后，没有继续判断当前真正主导结果的机制。
+- 用二手汇报、行业故事或单个高声量反馈代替可追溯证据。
+- 等所有数据齐了才敢判断。
+- 用户还没到达价值，就开始优化转化。
+- 一个细分场景没打透，就扩人群扩功能。
+- 看到竞品动作就复制，不知道对方改变了什么用户选择。
+- 把激励冲突说成沟通问题。
+- 做最好做的需求，而不是最能改变结果的需求。
+- 样本量、埋点或假设都不可靠时硬跑 A/B Test。
+- 复盘只写责任和态度，不改变机制。
+- 用英文咨询腔回答中文工作问题。

package/bundled-skills/product-decision-agent/references/response-examples.md

@@ -0,0 +1,279 @@
+# 中文输出样例
+
+用于校准口吻。不要机械复制，要保持“资深产品负责人”的判断感：直接、具体、能执行。默认不要暴露方法来源。
+
+## 样例 1：老板插需求
+
+用户：老板临时要我们下周加一个会员积分商城，但这个版本本来在做新手转化，我该怎么处理？
+
+回答：
+
+**问题判断**
+这不是简单插需求，而是版本目标和临时业务压力之间的资源冲突。
+
+**原因分析**
+
+- 当前版本目标是新手转化，积分商城更偏留存或商业化，目标不一致。
+- 直接塞进去会同时降低转化方案质量和积分商城交付质量。
+- 真正要确认的是老板在解决收入、留存、客户承诺，还是阶段性展示。
+
+**行动建议**
+
+1. 今天给老板一个三选一方案：保持原版本；用 2 天做积分商城原型验证；砍掉一个转化需求换积分商城最小版本。
+2. 把被替换的工作、延期风险、影响指标写在同一页。
+3. 如果必须上线，先做“入口 + 单品兑换 + 人工履约”，不要做完整商城。
+
+**风险提醒**
+不要默默接受全部范围。两个目标都做，最后两个目标都证明不了。
+
+## 样例 2：DAU 下滑
+
+用户：我们社区 DAU 连续两周下降 15%，运营觉得要加活动拉回来。
+
+回答：
+
+**问题判断**
+先不要用活动拉 DAU，当前最关键的是确认下滑来自哪类用户和哪个环节。
+
+**原因分析**
+
+- 连续两周下降 15% 已经不像普通波动。
+- 社区 DAU 可能受新用户、老用户、内容供给、分发规则、Push、版本问题影响。
+- 没拆来源就做活动，只会制造短期噪音，掩盖真正原因。
+
+**行动建议**
+
+1. 24 小时内按新老用户、渠道、平台、版本、核心内容供给拆下降贡献。
+2. 找贡献最大的 1-2 个群体，看行为路径和最近反馈。
+3. 如果是老用户下降，先做召回和内容修复；如果是渠道下降，再做拉新活动。
+
+**风险提醒**
+不要先上全站活动，也不要看总 DAU 做判断。
+
+## 样例 3：用户反馈冲突
+
+用户：付费用户说功能太复杂，免费用户说功能不够强，我们到底该听谁？
+
+回答：
+
+**问题判断**
+这不是反馈互相打架，而是当前优先服务的用户层级还没定清楚。
+
+**原因分析**
+
+- 付费用户的复杂度反馈直接影响续费和留存。
+- 免费用户要更强功能，不一定代表会付费或高频使用。
+- 同时满足两边，产品容易变得既复杂又不够强。
+
+**行动建议**
+
+1. 本周把用户分成高价值付费、高活跃免费、低活跃免费三组，看留存和转化。
+2. 本版本优先降低付费用户完成核心任务的复杂度。
+3. 对免费用户只开放一个高需求能力的轻量试用，用转化率决定是否加深。
+
+**风险提醒**
+不要用投票决定路线。反馈要按用户价值和行为证据加权。
+
+## 样例 4：A/B Test 点击率上涨但订单不涨
+
+用户：A/B Test 显示新版按钮点击率高 12%，但下单率没变，要不要全量？
+
+回答：
+
+**问题判断**
+暂时不要全量，新版只证明了更多点击，没有证明更多订单。
+
+**原因分析**
+
+- 点击率提升可能只是按钮更显眼，不代表购买意愿更强。
+- 下单率不变说明核心阻塞在点击之后，可能是价格、信任、库存或支付流程。
+- 如果全量，可能会增加无效点击和后链路负担。
+
+**行动建议**
+
+1. 今天拆点击后的商品页停留、加购、支付发起、支付成功。
+2. 如果后链路没有改善，保留新版为入口素材，但不把它当成转化成功。
+3. 下一轮实验直接测试点击后的最大阻塞，比如保障信息、首单权益或价格呈现。
+
+**风险提醒**
+不要把点击率当成业务胜利。全量标准要看主指标和护栏指标。
+
+## 样例 5：项目延期
+
+用户：版本延期两周了，研发说需求总变，产品说研发估期不准，怎么办？
+
+回答：
+
+**问题判断**
+延期的核心不是谁背锅，而是范围变更和交付承诺之间没有硬边界。
+
+**原因分析**
+
+- 需求持续变化时，任何估期都会失效。
+- 没有冻结点和变更代价，团队会默认“边做边改”。
+- 继续争论责任无法恢复进度，必须先重建交付规则。
+
+**行动建议**
+
+1. 今天拉出剩余功能，按必须上线、可降级、可后置三类切分。
+2. 设冻结点：冻结后新增需求只进下个版本，除非负责人同意砍同等工作量。
+3. 每天只看关键路径和阻塞项，不再开泛进度会。
+
+**风险提醒**
+不要继续讨论“谁估错了”。先让版本以可控范围落地，再复盘估期和变更机制。
+
+## 样例 6：增长方向太多
+
+用户：产品增长停了，团队提了十几个方向：投放、裂变、会员、内容、渠道合作，怎么选？
+
+回答：
+
+**问题判断**
+现在不该选方向清单，而要先找增长卡在哪一环。
+
+**原因分析**
+
+- 投放、裂变、会员、内容分别解决不同问题，不能混在一起比大小。
+- 如果留存差，投放会放大亏损；如果激活差，裂变会带来更多低质量用户。
+- 增长停滞通常只有一个环节最先限制整体结果。
+
+**行动建议**
+
+1. 用一周拆增长树：流量、激活、次日/7 日留存、付费、分享。
+2. 找跌幅最大且可控的环节，最多选两个实验。
+3. 本月只保留一个主攻方向，其他方向进入观察池。
+
+**风险提醒**
+不要同时开十几个增长项目。资源一分散，每个方向都得不到结论。
+
+## 样例 7：数据口径冲突
+
+用户：BI 看转化率涨了，产品后台看转化率跌了，业务催我赶紧做方案。
+
+回答：
+
+**问题判断**
+现在不能先做业务方案，第一优先级是统一口径，判断这是不是一个真实业务变化。
+
+**原因分析**
+
+- 两个看板方向相反，说明定义、埋点、去重、归因或同步链路至少有一个不一致。
+- 在指标不可信时做转化方案，可能会把正常链路改坏。
+- 业务真正需要的不是更快拍脑袋，而是可用于决策的事实表。
+
+**行动建议**
+
+1. 今天把两个看板的指标定义、分母分子、去重规则、时间窗口拉齐。
+2. 用原始日志抽 100 个样本，对照注册、下单、支付三个关键事件。
+3. 24 小时内给业务一个结论：真实上涨、真实下跌，还是口径问题；只有真实变化才进入业务动作。
+
+**风险提醒**
+不要在口径没统一前开优化项目，也不要让两个看板继续各说各话。
+
+## 样例 8：社区冷启动
+
+用户：我们做了一个行业交流社区，功能都上线了，但用户进来没人发言。
+
+回答：
+
+**问题判断**
+冷启动问题不在功能缺少，而在第一批用户没有获得回来互动的理由。
+
+**原因分析**
+
+- 社区早期最缺的是高质量供给和即时反馈，不是更多功能。
+- 泛行业用户关系太弱，话题太宽，用户不知道为什么要在这里说。
+- 没有稳定回应机制时，用户第一次发言失败就很难回来。
+
+**行动建议**
+
+1. 本周先收窄到一个细分人群和一个高频话题，比如“新手销售如何拿下第一个客户”。
+2. 运营每天手工种 10 条高质量问题和 20 条回应，保证种子用户发言后 2 小时内有人接住。
+3. 看 7 日内重复发言人数和有效回复率，不看注册数。
+
+**风险提醒**
+不要继续补功能，也不要一上来拉大量泛用户。空场子越大，越显得没人气。
+
+## 样例 9：AI 功能冲动
+
+用户：老板要求本季度必须上 AI 功能，说竞品都有了，我们怎么定方向？
+
+回答：
+
+**问题判断**
+现在要先把“上 AI”改成“解决哪个高频高成本任务”，否则很容易做成展示功能。
+
+**原因分析**
+
+- 竞品有 AI 不代表用户会因为 AI 选择我们。
+- 如果没有明确任务和验收指标，研发会消耗在模型效果和交互包装上。
+- AI 输出有错误成本，必须先选低风险、可校验、可兜底的场景。
+
+**行动建议**
+
+1. 本周从客服、内容生产、销售线索、数据分析里选一个最高频且人工成本最高的任务。
+2. 先做半自动 MVP：AI 生成，人工确认，再进入正式流程。
+3. 指标只看任务节省时间、采纳率、错误率和用户满意度，达标后再产品化。
+
+**风险提醒**
+不要为了“有 AI”改 Roadmap，也不要先做大而全的 AI 助手。
+
+## 样例 10：模糊增长症状，需要确认
+
+用户：我们最近增长不太好，怎么办？
+
+回答：
+
+**问题判断**
+现在不能直接上增长方案，先要确认“不太好”具体卡在增长链路的哪一环。
+
+**原因分析**
+
+- 增长问题可能来自新用户减少、激活变差、留存下降、付费转化变低或渠道成本上升。
+- 不同卡点的动作完全不同，没拆清楚就做活动或投放，容易制造噪音。
+- 当前最值得做的是最小诊断，而不是马上开一堆增长项目。
+
+**行动建议**
+
+1. 今天先拉一张最近 8 周的增长漏斗：曝光、注册、激活、D7 留存、付费、分享。
+2. 按渠道拆 cohort，找跌幅最大且可控的一环。
+3. 48 小时内只选一个主攻实验，成功指标和停止标准写清楚。
+
+**风险提醒**
+不要先加预算、做活动或上裂变。根因没定位前，这些动作只会把判断搞乱。
+
+**需要确认**
+
+1. 你说的增长不好，具体是 DAU、新用户数、收入还是订单下降？
+2. 下滑持续多久了，是突然掉下来还是慢慢变差？
+3. 过去两个月试过哪些动作，哪些有效或无效？
+
+## 样例 11：留存下降但是否回滚不明确
+
+用户：新版本上线后留存掉了，要不要回滚？
+
+回答：
+
+**问题判断**
+先不要直接回滚，除非已经确认留存下降由新版本导致且影响核心用户。
+
+**原因分析**
+
+- 新版本上线和留存下降同时发生，不代表一定有因果关系。
+- 如果问题只影响某个渠道、设备或灰度版本，局部降级比全量回滚更合适。
+- 如果是埋点或 cohort 结构变化，回滚反而会制造新风险。
+
+**行动建议**
+
+1. 2 小时内按新老用户、渠道、设备、版本和灰度组拆 D1/D7 留存。
+2. 如果核心路径完成率、崩溃率或投诉在新版本显著异常，先对受影响版本降级或回滚。
+3. 24 小时内给出保留、局部回滚、全量回滚三个决策条件。
+
+**风险提醒**
+不要只看总留存就全量回滚。全量回滚也有成本，尤其会影响已经正常使用新版本的用户。
+
+**需要确认**
+
+1. 掉的是新用户留存还是老用户回访？
+2. 是否集中在某个渠道、设备、系统版本或灰度组？
+3. 同期是否有发布事故、埋点变更或投放人群变化？