当奖励或游戏化失效、团队不投入时，用 AMP（自主、精通…

用 Daniel Pink 的自主、精通、目的（AMP）框架设计产品、团队与激励中的内在动机系统，替代胡萝卜大棒。

适用场景

解决思路

1. 采用 Motivation 3.0 视角：假设人寻求自主、精通、目的，而不是只受生存驱动或奖励/惩罚驱动。
2. 对任何需要基本认知努力的任务，不要依赖外部奖励，改用内在动机 AMP 驱动持久参与。
3. 对产品功能、团队激励、游戏化、参与循环等任何动机系统，使用快速诊断评分：从 5 分开始；前五问每回答“是”加 1 分；若第六问也回答“是”，再减 2 分；目标为 10/10。
4. 按得分区间解读：9-10 表示自主、精通、目的都具备且无如果-那么奖励挤出；5-6 表示一个支柱支撑系统，另外两个薄弱或外在；≤3 表示依赖奖励、命令或控制行为，内在动机缺失。
5. 评分后始终说明当前得分、未通过的诊断项，以及达到 10/10 的具体修复措施。
6. 先判断任务类型：外部奖励只用于常规、算法型、无内在兴趣的任务；对创造性工作、复杂问题解决或长期参与，不要用如果-那么奖励，否则会反噬。
7. 识别并避免如果-那么奖励的七类危害：挤出内在动机、降低表现、摧毁创造力、挤走善行、鼓励作弊、变得上瘾、助长短期思维。
8. 设计自主性时覆盖四个 T：任务（Task）、时间（Time）、技术（Technique）、团队（Team）。
9. 记住自主性不等于独立性：允许有选择的同时保持团队相互依赖。
10. 在任务维度给选择：允许用户或员工选择工作内容，例如 Google 20% time、Atlassian ShipIt days。
11. 在时间维度给选择：使用弹性工时、取消强制会议。
12. 在技术维度给选择：允许选择工具、方法和实现路径。
13. 在团队维度给选择：支持自组织团队或选择合作对象。
14. 在新手引导中提供自主性：允许选择路径、跳过步骤，不要强制线性教程。
15. 在内容消费中提供自主性：提供用户可控的信息流、过滤器，而不是仅算法推荐。
16. 在工作流中提供自主性：提供自定义自动化、显示/隐藏、渐进披露，避免僵化流程和功能膨胀。
17. 消除自主性违规：不要强制“完成 X 才能做 Y”、不可跳过教程、强制通知、单一路径。
18. 设计精通时遵循三条法则：精通是心态（能力可发展，用成长型思维）；精通是痛苦的（需要努力和刻意练习）；精通是渐近的（永远没有终点）。
19. 用心流条件校准精通：清晰目标、即时反馈、挑战与技能平衡、控制感。
20. 把挑战难度校准到用户技能水平：太易会无聊，太难会焦虑；使用自适应难度。
21. 把失败框定为学习而非评判，不要惩罚失败。
22. 提供可见的技能发展：进度指示、技能等级、贡献图等，例如 GitHub contribution graph、Duolingo levels。
23. 提供即时、清晰的反馈：对行动实时响应，例如 Grammarly 实时写作分析。
24. 始终提供下一等级或下一挑战，因为掌握永远没有完全到达。
25. 设计目的时使用三种表达：目标（Goals）、语言（Words）、政策（Policies）。
26. 用目标表达目的：设置目的驱动的目标。
27. 用语言表达目的：使用目的语言而非利润语言，例如用 associates 而不是 employees，用 community 而不是 users。
28. 用政策表达目的：用行动证明目的，例如 Patagonia “Don't Buy This Jacket”。
29. 在产品中展示影响：显示用户贡献，例如 Wikipedia 编辑计数器、Kiva 借贷影响。
30. 在产品中连接社区：让用户参与更大事物，例如开源贡献、社区目标。
31. 在产品中对齐价值观：把产品与信念绑定，例如 Ecosia “Search the web to plant trees”。
32. 执行目的处方：展示聚合影响，例如“Together, our users have saved 1M hours”，把个人行动连接到集体结果，并庆祝有意义里程碑而非虚荣指标。
33. 做游戏化时按 AMP 设计：自主性用自愿加入和自选挑战；精通用基于技能的进展和有意义里程碑；目的用社区贡献和个人成长。
34. 避免坏游戏化：强制挑战、强制参与、事事积分、琐碎徽章、无意义竞争、令人泄气排行榜。
35. 参考 Duolingo：自主（选择语言、节奏、主题）、精通（自适应难度、技能等级）、目的（学习语言以与人连接）。
36. 注意连续打卡可能从内在精通转为外在损失厌恶，需谨慎设计。
37. 团队管理中交出手中的任务、时间、技术、团队，并说“这是目标，如何达成由你决定”。
38. 团队管理中提供挑战、反馈和成长：拉伸任务、导师制、学习预算。
39. 团队管理中把工作连接到使命：解释“为什么这对客户重要”。
40. 薪酬上先付足够且在理想情况下高于市场，把钱从桌面上拿走，然后聚焦 AMP；超过“足够”后更多钱不增加动机。
41. 用事后奖励替代如果-那么奖励：事后意外认可，如“你达成目标！这是奖金。”；不要用“如果达成目标，就得到奖金。”
42. 培养 I 型行为：用自主、精通、目的驱动，追求内在满足、长期焦点和成长型思维；避免 X 型行为的外部奖励、外部认可、短期焦点和固定型思维。
43. 记住 I 型行为是后天培养的，不排斥金钱或认可，可更新，并促进幸福感。
44. 把团队或用户从 X 型转向 I 型时，使用完整行为对比和转化策略，见 references/type-i.md。
45. 修复常见错误：不要事事积分，奖励只留给有意义里程碑。
46. 修复常见错误：不要强制参与，改为自愿加入。
47. 修复常见错误：不要所有人同一挑战，改为难度匹配的自适应挑战。
48. 修复常见错误：不要没有可见进度，添加进度指示和技能跟踪。
49. 修复常见错误：不要缺失“为什么”，把每个功能连接到目的。
50. 修复常见错误：不要如果-那么奖金，公平付薪，使用事后奖励并聚焦 AMP。
51. 按快速诊断行动：若用户不能选择做什么、何时做、如何做，添加选择、灵活性、定制化。
52. 按快速诊断行动：若用户看不到进度，添加进度跟踪、技能等级。
53. 按快速诊断行动：若挑战未匹配技能，实现自适应难度。
54. 按快速诊断行动：若无即时反馈，添加对行动的实时响应。
55. 按快速诊断行动：若用户不知道为何重要，连接使命并展示影响。
56. 按快速诊断行动：若正在使用如果-那么奖励，切换到事后奖励或内在设计。
57. 当奖励或激励方案反噬时，查阅 references/extrinsic-rewards.md，使用每个危害背后的研究和奖励安全使用决策规则。
58. 设计新手引导、信息流或工作流控件时，查阅 references/autonomy.md，使用完整四个 T 模式和自主性审计清单。
59. 设计进度、难度或反馈系统时，查阅 references/mastery.md，使用心流校准、刻意练习和掌握审计清单。
60. 设计影响、社区或价值观功能时，查阅 references/purpose.md，使用目标/语言/政策模式和目的审计清单。
61. 把 AMP 应用到具体游戏化、团队管理或薪酬设计时，查阅 references/applications.md，使用工作示例和升级表。
62. 查看真实世界 AMP 项目（Atlassian ShipIt、3M、ROWE、Duolingo、Wikipedia）时，查阅 references/case-studies.md。

适用边界 · 注意事项

• 不要用于只需常规、算法型、无内在兴趣任务的外部奖励设计；此时外部奖励安全且本框架并非必要。
• 不要对创造性工作、复杂问题解决或长期参与引入如果-那么奖励，否则会挤出内在动机、降低表现并助长短期思维。
• 若目标是形成习惯产品循环或留存行为设计，应看 hooked-ux 或 improve-retention，而不是本技能。