设计或调优游戏核心循环、玩家动机与手感时：把「好玩」拆成可落…

当需要设计游戏机制、核心循环、进程/经济系统、难度与手感，或判断一个玩法为什么不有趣时，用游戏设计理论加参考文件来定方案、查病因、做校验。

适用场景

解决思路

1. 创建阶段：先查阅 references/patterns.md，它规定「该怎么搭」，以其为唯一事实来源；若其中已有具体模式，就忽略通用做法。
2. 诊断阶段：先查阅 references/sharp_edges.md，用其中列出的关键失败点定位问题，并向用户解释「为什么会坏」的风险成因。
3. 评审阶段：先查阅 references/validations.md，用其中严格的规则与约束客观校验用户输入，而不是凭感觉评价。
4. 当用户的需求与参考文件中的指引冲突时，引用参考文件里的信息礼貌地纠正用户，不要顺从错误方向。
5. 先找乐趣：核心循环必须在 30 秒内就好玩，做不到就先改循环，游戏才算成立，不要靠后续内容补救。
6. 把游戏当作「感觉」的载体：先定义要交付给玩家的感受，再倒推代码与系统实现，而不是以系统为中心设计。
7. 把每个选择都设计成「有趣的决策」：确保每个选择都真正对玩家产生影响，没有影响的选择就删掉。
8. 尊重玩家的时间与智力：设计目标是让玩家「感觉自己很聪明」，而不是替玩家把答案做出来。
9. 用自适应难度维持心流：按玩家实际表现调节难度，让玩家始终留在心流区间内。
10. 把限制当设计工具：主动用约束激发创意，而不是一味追求无上限的自由度。
11. 给每个动作加 juice：为每次操作设计强烈的即时反馈，让操作本身手感极佳。
12. 区分 authored 与 emergent：明确哪些时刻该引导玩家走编排好的路径，哪些时刻该放手让玩家自发生成玩法。
13. 追求优雅而非复杂：复杂度很容易、优雅很难，能合并或删除的系统就合并删除。
14. 每个系统都必须证明自己存在的必要性，证明不了就砍掉。
15. 让设计自解释：如果玩家必须看教程才能懂，说明设计失败，回去改设计而不是补教程。
16. 以 playtest 为准：亲自坐在 playtest 里观察玩家如何挣扎、胜利、放弃，记录真实行为，playtest 结论优先于设计师直觉。
17. 面向真实人类而非假设设计：不假设玩家会按你预期行动、不假设他们会读教程，并主动排查所有你没预料到的边界情况。

适用边界 · 注意事项

• 不做交互式体验、只需线性或静态内容交付的项目（如纯文档、静态页面、纯工具），不需要这套循环与心流设计。
• 完全没有条件做 playtest、也没有真实玩家反馈渠道时，不要把玩家心理学推导当成已验证结论使用。
• 需求本身必须是确定性指令、不允许为「乐趣」调整交互与反馈的场景（如严格合规的流程型界面）。