用户注册后流失、激活/留存漏斗泄漏时…

当应用有人注册但静默流失、日活平坦、激活漏斗持续泄漏时，按阶段设计习惯循环、首跑激活、证据驱动实验、唯一指标与伦理化参与机制，提升激活和留存。

适用场景

解决思路

1. 核心原则：先修漏桶，再投入获客；习惯、激活和留存优先于任何增长预算。
2. 按八阶段编排旅程，在每个决策点向用户提问，并把结果记录到 docs/；具体方法由各阶段技能承载，调用技能而不是自行即兴发挥其框架。
3. 恢复优先：先读取 docs/GROW-APP-PLAN.md 和 Journey Map 中所有 artifact；如果 tracker 存在，用 3-5 行总结旅程状态并询问进入哪个阶段；确认入口点后才继续；有 tracker 的旅程只恢复，不重启。
4. 仅首次运行做 Intake：无 tracker 时先跑 Intake，然后创建 docs/GROW-APP-PLAN.md，为每个阶段标注 pending | in-progress | awaiting-evidence | done | deferred: reason | skipped: reason；tracker 存在且用户确认阶段计划后完成。
5. Intake 问题 1：问应用做什么，以及留存用户重复的核心动作是什么，用来定义 Hook loop 和 OMTM。
6. Intake 问题 2：问当前留存数字是什么，例如 day-1/7/30 或 week-4 cohorts，用来设定 Rule 8 获客门槛并输入 lean-analytics。
7. Intake 问题 3：问激活漏斗在哪里泄漏，以及 first-run flow 是什么，用来门控 improve-retention。
8. Intake 问题 4：问是单人/小团队还是完整 product trio（PM、designer、engineer），用来衡量 continuous-discovery 和 inspired-product。
9. Intake 问题 5：问应用是否是 network/marketplace 产品，以及 engaged users 是否未能转化为 revenue，用来标记可选 cold-start-problem / monetizing-innovation。
10. Intake 问题 6：问今天有哪些 analytics 和 instrumentation，用来门控 lean-analytics 和每个实验。
11. Intake 问题 7：问留存是否因 UX 或 performance 而不是缺少 engagement 而受损；如果是，先路由到 improve-app。
12. Intake 跳过启发式：单人创始人无团队可对齐时跳过 Phase 5；在 loop 和 activation 达标前 defer Phase 7；没有用户访问时以降级节奏运行 Phase 3。然后从 references/artifact-templates.md 创建 tracker 并标注每个阶段状态，确认计划。
13. 阶段进入：宣布该阶段做什么、强制什么决策、产出什么 artifact、大致工作量；提供 proceed / skip / defer；标记为 GATE 的阶段可以 defer，不能 skip；用户选择 proceed 后把阶段标记为 in-progress。
14. 技能调用与后备：加载该阶段技能并使用；每个阶段的 Invoke 行按 slug 命名技能，用该技能运行阶段；如果不可用，提供 npx skills add wondelai/skills/<slug> --global；如果用户拒绝，则按该阶段 Brief 运行最低可行方法；说明当前处于哪种模式。
15. 阶段内决策：对 Decide with the user 中每个问题都要询问，给出具体选项和你的推荐；把选择记录到 tracker 的 Key Decisions；静默做出的决策是缺陷。
16. 阶段退出：写入前展示 artifact 草稿内容供签字；批准后写入或扩展 docs/ 文件，更新 tracker（status、Key Decisions、Next Actions）；文件写入且阶段行显示 done 后完成。
17. Artifact 纪律：写前先读；文件缺失才创建，否则扩展；添加或更新自己的章节，保留其他人的章节；docs/ 中文件名使用 UPPERCASE；每条建议落地为带 owner 和 priority 的 checkbox 或表格行；首次创建 docs/ 文件时查看 references/artifact-templates.md，用完整骨架（所有 section headings）创建，再填写本阶段指定的章节。
18. Retention before acquisition：当激活和留存低于 intake 设定的门槛时，获客导向阶段——可选 cold-start-problem、contagious、crossing-the-chasm，以及任何 paid-growth 工作——保持锁定；只有 cohort curve 越过门槛才解锁。每个 habit loop 和 reward 必须通过 Manipulation Matrix：只构建制作者自己会用且真心相信能实质性改善用户的东西；当策略需要制造焦虑或 loss aversion 时，替换为基于真实价值的策略。
19. Phase 1 目的：构建回归引擎——强到用户因内部触发而非付费通知回来的 Hook loop。
20. Phase 1 Brief 后备：Hook Model 跑 Trigger → Action → Variable Reward → Investment；把 external triggers（push、email）迁移为 internal ones（一种情绪——boredom、FOMO、anxiety）；让 action 极其简单；让 reward 在 tribe/hunt/self 上可变；把 investment 排在 reward 之后，以提高 switching cost 并加载下一次 trigger；只有一个弱阶段的 loop 会停滞，不会半工作。
21. Phase 1 调用：使用 hooked-ux 技能，输入核心 loop 和当前 daily-active users 如何回来；要求它 (a) 映射四阶段 loop，按 0-10 评分并指出最弱项，(b) 用已有数据设计诚实的 variable-reward concepts，每个都对照 Manipulation Matrix。
22. Phase 1 与用户决策：确认哪个 internal trigger（情绪）应拉用户回来；确认哪个单一阶段最弱并现在就做最高杠杆修复——若 loop 已在形成（5%+ unprompted return）则 defer；选择强化哪种 reward 类型——tribe（social）、hunt（resources）、self（mastery）——拒绝任何未通过 Manipulation Matrix 的概念。
23. Phase 1 Artifact：扩展 docs/PRODUCT.md ## Hook Model（trigger → action → variable reward → investment；命名最弱阶段）；更新 tracker。
24. Phase 1 完成条件：PRODUCT.md 写明 internal trigger 和全部四个阶段，记录最弱阶段及其修复，重新设计 onboarding 让新用户在首个 session 完成一个完整 Hook cycle，用户选择要上线的修复。
25. Phase 2 目的：让新用户到达 loop，把第一个有意义动作变得几乎不费力。
26. Phase 2 Brief 后备：B=MAP——行为只在 Motivation、Ability、Prompt 汇聚时发生；Motivation 不可靠，提升 Ability；简单性受六种资源中最稀缺者限制：time、money、physical effort、mental effort、social deviance、non-routineness；把目标缩小为 Starter Step，在 30s 内交付价值，锚定到现有 routine，并立即庆祝胜利。
27. Phase 2 调用：使用 improve-retention 技能，输入真实 activation flow 逐步流程和 day-1/7/30 drop-offs；要求 B=MAP friction audit，给所有六个 Ability-Chain 因素评分，命名最稀缺资源，重新设计 Starter Step，并制定 event-based prompt rules。
28. Phase 2 与用户决策：对第一个动作最稀缺的 Ability 资源是什么——先修那一环，不是最明显的一环；Starter Step（最微小有价值动作）及其 celebration moment；哪些 time-based prompts 转为 event-based，丢弃任何不符合 will I appreciate this now? 的。
29. Phase 2 Artifact：扩展 docs/PRODUCT.md ## Activation & Retention Plan（friction/moment | fix | owner | status）；更新 tracker。
30. Phase 2 完成条件：命名最稀缺资源，Starter Step、celebration、prompt changes 成为带 owner 的行，每个 day-1/7/30 drop-off 映射到可能的 B=MAP failure，用户批准修复列表。
31. Phase 3 目的：用关于自己用户的每周证据流替代通用最佳实践。
32. Phase 3 Brief 后备：目标至少每周一次 customer touchpoint；构建 Opportunity Solution Tree：outcome 在顶部 → customer opportunities（用客户原话表述 needs/pains）→ candidate solutions/experiments；绝不从 outcome 直接跳到 solution；访谈基于故事（tell me about the last time you…），记录为一页 snapshots；先便宜地测试最冒险的 leap-of-faith assumption。
33. Phase 3 调用：使用 continuous-discovery 技能，输入 retention outcome 和已知 churn patterns；要求 Opportunity Solution Tree、当前 churned users 今天如何尝试成功的 current-state experience map、每周 story-based interview snapshot template、下一个计划功能的 assumption map。
34. Phase 3 与用户决策：tree 顶部的单一 outcome；先 pursue 哪两三个 opportunities；团队能实际维持的每周 cadence 和 recruitment mechanism——现在就设置，否则降级运行；下一个功能里最冒险的 leap-of-faith assumption（desirability、viability、feasibility、usability）和最便宜的测试。
35. Phase 3 Artifact：扩展 docs/PRODUCT.md ## Opportunity Solution Tree Notes、## Outcome Roadmap（outcome/problem | job served | priority | status）、## Discovery Cadence；扩展 docs/CUSTOMER.md ## Interview Evidence（date | who | facts | commitment）；更新 tracker。
36. Phase 3 完成条件：记录 tree 的 outcome 和 top opportunities，排定 cadence，存在第一个 interview snapshot template，最冒险 assumption 有便宜测试设计。
37. Phase 4 目的：把机会变成由行为裁决的可证伪押注，而不是会议裁决。
38. Phase 4 Brief 后备：Outcomes over outputs——价值是行为改变，不是交付物；写 hypothesis：We believe [outcome] will happen if [persona] achieves [action] with [feature]，并在测试前承诺 metric 和 threshold；让 fidelity 匹配风险（paper prototype 加五个用户可发现约 85% usability issues）；A/B tests 留给调优已验证概念；被 invalidated 时从 backlog 移除——不要 defer。
39. Phase 4 调用：使用 lean-ux 技能，输入当前最大设计争论或 top discovery opportunity；要求三个标准格式 hypothesis statements、能验证 top one 的最低 fidelity experiment、及其预先承诺的 metric、threshold、timebox。
40. Phase 4 与用户决策：先测试哪个 hypothesis；experiment fidelity——能回答实际问题的最低 fidelity；pass/fail line，以及失败后什么离开 backlog。
41. Phase 4 Artifact：扩展 docs/EXPERIMENTS.md ## Experiment Cards（hypothesis, type, primary metric + threshold, guardrail, decision rule）和 ## Experiment Backlog（idea | ICE | status）；更新 tracker。
42. Phase 4 完成条件：至少一个 experiment card 有预先承诺的 threshold 和 decision rule，backlog 已 triage，用户选择第一个测试。
43. Phase 5 目的：把团队从 feature factory 移到 outcome ownership——解决的是问题，不是交付功能。
44. Phase 5 Brief 后备：Empowered teams 得到 problems 而不是 backlogs，并对 outcomes 负责；Dual-track：discovery（什么值得构建——处理 value、usability、feasibility、viability）与 delivery 持续并行；每个已发布功能预期 10-20 次 discovery iterations；给团队 product vision 和 outcome-based roadmap，使其能自主决策。
45. Phase 5 调用：使用 inspired-product 技能，输入 top three backlog requests 和当前 roadmap；要求对每个做 opportunity assessment（objective、target user、problem、success measure、alternatives），以及一段式 vision 加一个季度的 outcome-based roadmap items。
46. Phase 5 与用户决策：哪个 backlog request 证据最强——以及哪个在进入 sprint 前 kill 掉；一段式 product vision；roadmap 是否重述为 problems + key results 而不是带日期的 features。
47. Phase 5 Artifact：扩展 docs/PRODUCT.md ## Vision 和 ## Outcome Roadmap（outcome/problem | job served | priority | status）；更新 tracker。
48. Phase 5 完成条件：存在 vision paragraph，三个 requests 每个有 build/kill verdict，roadmap rows 是 outcomes 而不是 features。
49. Phase 6 目的：让整个团队盯住 One Metric That Matters，并暴露掩盖衰减的 vanity metrics。
50. Phase 6 Brief 后备：好 metric 是可比较的、ratio/rate（不是累计总数）、能改变行为的；business model 决定哪些 metrics 重要，stage 决定排序（Empathy → Stickiness → Virality → Revenue → Scale）；弱留存 = Stickiness 阶段，所以 retention 就是 OMTM——先做更晚阶段是典型错误；画一条 line in the sand（target、date、miss response），把 OMTM 与 counter-metric 配对，并对数据做 cohort。
51. Phase 6 调用：使用 lean-analytics 技能，输入当前 dashboard/metrics 和 business model；让它标记 vanity metrics，选 Stickiness-stage OMTM 加 counter-metric，设计一屏 dashboard（OMTM 大，≤6 supporting），以及 cohorted retention view。
52. Phase 6 与用户决策：OMTM 及其 counter-metric；line in the sand——target、date、预先承诺的 miss response；哪些当前 metrics 作为 vanity 退役。
53. Phase 6 Artifact：创建 docs/METRICS.md，含 ## Stage & One Metric That Matters、## KPI Definitions、## Baselines & Targets、## Funnel、## Cohort Notes；更新 tracker。
54. Phase 6 完成条件：METRICS.md 写明 OMTM + counter-metric，记录带日期的 line in the sand，列出 cohorted baselines，标记 vanity metrics 退役，指定一屏 dashboard，并设置 Rule 8 acquisition gate 的 retention bar。
55. Phase 7 目的：在用户每天触碰的微时刻，缩小能忍受的应用和喜爱的应用之间的差距。
56. Phase 7 Brief 后备：每个 microinteraction 有 Trigger → Rules → Feedback → Loops & Modes；Feedback 立即（直接操控 <100ms）且成比例；动画作用于用户触碰的元素，而不是单独 toast；映射每个状态：empty、loading、partial、error、disabled、double-tap；投资一两个通过 removal test 的 signature moments；用 long loops 为 power users 退役 hints。
57. Phase 7 调用：使用 microinteractions 技能，输入五个最常用 interactions；要求对每个做 Trigger/Rules/Feedback/Loops audit，找出 sub-100ms feedback 和缺失 edge-case states，并用真实代码实现一个 signature moment。
58. Phase 7 与用户决策：审计哪五个 interactions；哪一个成为 signature moment（应用 removal test）；先实现哪些 edge-case states。
59. Phase 7 Artifact：扩展 docs/DESIGN.md ## Microinteraction Inventory（interaction | trigger/rules/feedback/loops | fix | status）；更新 tracker。
60. Phase 7 完成条件：五个 interactions 进入 inventory，含缺失 states 和 fixes，signature moment 已选，每个 fix 有 status。
61. Phase 8 目的：防止 loops 变质——让 engagement 靠 Autonomy、Mastery、Purpose，而不是 exploitation。
62. Phase 8 Brief 后备：对任何需要 cognitive effort 的任务，if-then rewards 会摧毁 intrinsic motivation；持久 engagement 是 Autonomy（对 what/when/how/with whom 的选择）、Mastery（可见进步、flow-calibrated challenge）、Purpose（为什么重要）；Autonomy killers：forced tutorials、unskippable steps、mandatory notifications；把 rewards 留给有意义 milestones；偏好 now-that recognition 而非 if-then bargains。
63. Phase 8 调用：使用 drive-motivation 技能，输入应用的 gamification、streaks、points、notification patterns；要求 AMP audit 按 0-10 评分，标记每个 autonomy violation，指出 streaks 转入 loss aversion 的点，并围绕真实 mastery 和 purpose 重新设计 progression。
64. Phase 8 与用户决策：移除哪些 autonomy violations（forced/unskippable steps）；哪些 if-then rewards 转为 now-that recognition；任何 streak/points mechanic 是否利用 loss aversion 且必须改变。
65. Phase 8 Artifact：扩展 docs/PRODUCT.md ## Activation & Retention Plan，加入 AMP-audit rows（violation/finding | fix | owner | status）；更新 tracker。
66. Phase 8 完成条件：记录 AMP score 和每个 autonomy violation，reward/streak fixes 成为带 owner 的行，loops 通过 Rule 8 的 Manipulation Matrix。
67. 可选阶段 cold-start-problem：当应用是 network 或 marketplace 产品时添加；扩展 docs/PRODUCT.md。
68. 可选阶段 monetizing-innovation：当 engaged users 没有转化为 revenue 时添加；扩展 docs/OFFER.md。
69. 可选阶段 contagious：当用户喜爱应用但从不提及它时添加；扩展 docs/MARKETING.md。
70. 可选阶段 crossing-the-chasm：当增长在 early-adopter 边界停滞时添加；扩展 docs/STRATEGY.md。
71. 可选阶段 jobs-to-be-done：当使用模式表明应用被雇来做另一份工作时添加；扩展 docs/CUSTOMER.md。
72. 可选阶段遵循相同 operating rules——像核心阶段一样加载并使用每个列出的技能；在 Add-when 条件首次为真处插入。获客倾向的 cold-start-problem、contagious、crossing-the-chasm 保持锁在 Rule 8 之后，直到留存越过门槛。
73. 常见错误修复：购买增长前先修留存——在任何获客支出前通过 Stickiness gate（cohort curve 趋平）；按 Rule 8 保持获客阶段锁定。
74. 常见错误修复：不要永远依赖 external triggers——通过 hooked-ux 迁移到 internal trigger；把 notifications 当脚手架，不是承重墙。
75. 常见错误修复：不要优化错误的 Ability-Chain link——在 improve-retention 中给所有六个因素评分，修最稀缺资源，而不是最明显的。
76. 常见错误修复：不要从 outcome 直接跳到 solution——先构建 continuous-discovery 的 Opportunity Solution Tree；明显功能常是五个里最差的。
77. 常见错误修复：不要测量 outputs 而不是 outcomes——为每个发布加 instrumentation；在 lean-ux 和 inspired-product 中，成功是用户行为改变，不是 shipped stories。
78. 常见错误修复：不要给一切都 gamify 点数——把 rewards 留给有意义 milestones，并跑 drive-motivation AMP audit；if-then rewards 会挤出 power users。
79. 完成旅程检查：PRODUCT.md 包含一个 Hook loop（最弱阶段已修）、一个 activation Starter Step、一棵活的 Opportunity Solution Tree、以及 AMP-clean engagement design。
80. 完成旅程检查：METRICS.md 写明 Stickiness-stage OMTM 加 counter-metric，并有 line in the sand（target、date、miss response）。
81. 完成旅程检查：至少一个 lean-ux experiment 已解决并有记录 verdict，invalidated ideas 已离开 backlog。
82. 完成旅程检查：在任何 acquisition phase 运行前，满足 intake 设定的 retention bar，或量化剩余 gap。
83. 关闭 tracker：每个阶段 done 或 skipped，并把 Next Actions 带入 PRODUCT.md、METRICS.md、EXPERIMENTS.md。
84. 路由前进：当 engagement mechanics 无法修复由 broken UX 或 performance 拖累的产品时，继续用 improve-app skill。
85. 路由前进：当应用粘住且周围业务必须跟上——revenue、channels、operations——继续用 grow-business skill。

适用边界 · 注意事项

• 不要用于修复没有任何 engagement mechanic 能掩盖的 broken UX 或 performance；先运行 improve-app。
• 如果还没有 app，使用 create-app。
• 如果只想单独使用某一个框架，直接调用对应技能，而不是走完整 grow-app 旅程。