不打无准备之仗，不做无模型之功能。
写代码之前，应该先在心智里把代码跑一遍。这不是空话。
回顾前两篇文章——道具协同设计、地牢射击游戏骨架——里面所有的架构决策，在写第一行代码之前就已经定好了。这不是巧合。好的游戏功能是想出来的，不是调出来的。
心智模型到底是什么
心智模型是你对系统运转方式的内在理解。它不是架构图，不是 UML，不是文档。是你闭上眼睛时，能在脑子里看到那行数据流走的样子。
拿武器系统举例。在打开 Godot 之前，先问自己：
当玩家按下滑鼠左键，从输入到子弹命中敌人，中间经过哪些节点？
如果你只能回答「播放动画，生成子弹」，那你的心智模型还不够细。一个合格的模型应该能预测到：
1
2
3
4
5
6
| 输入 → WeaponController 判断能否开火 → 查询射速/弹匣/后坐力
→ Weapon 提供子弹模板 → 生成子弹 → 子弹飞行
→ 命中检测 → StatModifierManager 查询命中时的修改器
→ 应用效果（伤害 / 元素 / 分裂 / 连锁）
→ 触发事件（ON_BULLET_HIT）
→ 其他道具响应这个事件
|
能走到这一步，代码还没写，但你已经知道需要什么模块、它们怎么通话、边界在哪。写代码只是把脑子里的东西翻译成 GDScript。
反面教材：边写边想
这是最常见的陷阱：
- 想到一个「很酷的道具」→ 开始写
- 写到一半发现需要一个新的修改器类型 → 回去改基类
- 改基类发现影响了其他四个道具 → 把它们也改了
- 测试时发现子弹和碰撞体打架 → 加
body_entered 判断
- 加了判断发现性能崩了 → 重构事件系统
- 重构到一半发现思路和初版完全不同 → 删掉重来
你认不认得这个循环？我写过太多这种代码了。
症状：
- 一个函数的参数列表越加越长，因为当初没想好数据从哪来
- 信号连接越连越乱，因为节点之间的通话关系没设计过
- 一修 Bug 就修出两个新 Bug，因为系统内部的依赖是运行时随机长出来的，不是设计出来的
根因：代码的组织结构由「灵感的当下状态」决定，不受任何全局理解约束。
正确流程：心智模型先行
第一步：问自己五个问题
在写任何代码之前，先回答这五个问题：
| 问题 |
意义 |
| 这个功能的核心行为是什么？ |
一句话说清楚，说不清楚就别写 |
| 它需要知道哪些东西？ |
数据依赖 |
| 它会产生什么输出？ |
对系统其他部分的影响 |
| 它和其他已有系统怎么通话？ |
接口定义 |
| 边界情况是什么？ |
空状态、失败路径、极限值 |
用最近那篇道具协同设计文章里的 TRIGGER 系统举例：
1
2
3
4
5
| 核心行为：某个事件发生时，执行道具上挂载的效果
需要知道：事件类型、上下文（谁、在哪、伤害多少）
产生输出：可能修改上下文，可能生成新对象
通话方式：StatModifierManager.process_trigger(event, context)
边界情况：递归深度限制（depth > 2 就停）、触发冷却（0.5s）
|
这五个问题答完，代码结构就已经定了。 process_trigger 用什么签名、加什么防护、搁在哪个类里——全都清楚。
第二步：在心智里跑一遍
把前五个问题的答案串起来，在脑子里跑一次完整的流程：
1
2
3
4
5
6
7
| 玩家开枪 → 子弹命中敌人 → on_hit 信号发出
→ StatModifierManager.process_trigger(ON_BULLET_HIT, context)
→ 遍历 modifiers，筛选 TRIGGER 类型且匹配 ON_BULLET_HIT
→ 对每个匹配的 modifier，检查 depth、cooldown
→ 执行效果（生成分裂弹、触发爆炸、回复血量）
→ 把修改后的 context 传回给事件源
→ 事件源用修改后的 context 继续后续逻辑（伤害结算、死亡判定）
|
跑得通吗？哪一步会卡住？如果 depth > 2 了但是爆炸还在链式触发——走哪条路？这些问题在写代码之前想清楚，比在调试器里断一个小时有效率得多。
第三步：识别「不知道」的地方
心智模型一定会有盲区。关键在于提前识别它们：
- 「我不知道子弹生成后怎么拿到 modified_context」→ 意味着需要设计一个数据回传机制
- 「我不知道多个
TRIGGER 的执行顺序」→ 意味着需要优先级排序
- 「我不知道
depth 参数由谁维护」→ 意味着 context 需要包含递归元信息
每个「不知道」就是一个设计决策点。 卡出所有决策点之后，才开始写代码。写的时候只做翻译工作，不再做设计决策。
什么时候你的心智模型足够好了
一个简单的检验标准：
你能在一行代码没写的情况下，完整回答另一个开发者对这个功能的任何架构问题。
他问：
- 「分裂出的子弹算不算一次新的 ON_BULLET_HIT？」——你能立刻回答「算，但 depth + 1，超过 2 不再触发」
- 「换弹时触发的技能会不会打断换弹动作？」——你能立刻回答「不会，技能和换弹是并行流程，技能只是挂了一个额外的回调」
- 「如果玩家同时持有分裂和爆炸，执行顺序是什么？」——你能立刻回答「按道具获取顺序，但爆炸的触发结果不会再次触发分裂（depth 保护）」
答得出来，模型够了。答不出来，继续想。
心智模型不仅仅用于功能设计
同样的原则可以用在：
- 重构：动手之前，先在心智里画出重构后的依赖图。如果图和现状差别太大，说明步子太大了，拆成几步
- 排查 Bug：不要盲打
print。先在心智里复现你认为的完整路径，推理出「应该走到 A 但走到了 B」，再用 print 验证
- 性能优化：先想数据流瓶颈可能在哪个节点，再 profiler。不然你就是在数据里捞针
从经验中提炼模型
做一阵子游戏开发后，你会积累一批可复用的心智模型：
| 模式 |
适用场景 |
| 数据栈 |
属性修改器、Buff/Debuff 系统 |
| 事件总线 |
道具协同、成就系统、UI 更新 |
| 对象池 |
子弹、粒子、敌人（高频创建销毁） |
| 组件树 |
Entity-Component 架构 |
| 状态机 |
玩家状态、AI 行为、动画控制 |
| 资源注册表 |
导出后资源加载路径管理 |
建立心智模型的最佳练习就是：在下一篇博客里写「我为什么这样设计」而不是「我做了什么」。 前者训练模型，后者只是记录。你之前那两篇文章——道具协同和地牢骨架——恰好是前者，这也是它们读起来有说服力的原因。
一句话总结
你的代码不会比你的心智模型更好。你想不清楚，就写不清楚。
写代码只是把脑子里的结构翻译成行号。如果你打开编辑器的时候还不知道 process_trigger 该接收几个参数、该返回什么、由谁调用——那就是还没准备好。先合上电脑，想清楚再打开。
不打无准备之仗。