从零读代码：变量、条件、函数与类型

准备一个独立练习场景，只有一个 Node 根节点，挂上本课脚本即可；不依赖角色、美术、输入映射或其他脚本。你要学的不是把代码背下来，而是看见一段程序时，能说出它在运行前后改变了什么。我们只练三个事实：手里有没有钥匙、门开没开、调查过几次。

把变量想成有名字的小记录栏，比“装任何东西的盒子”更准确。has_key: bool 记录真假，examine_count: int 记录整数，message: String 记录文字。类型不是额外的数学题，而是提前说明这一栏允许什么内容，让明显不合适的赋值更早暴露。

清空练习根节点的模板脚本，输入下面这段完整示例。先不要运行，在纸上写出你认为会出现的四行输出，再用运行结果核对。本课代码根据 Godot 4.7 语法核实，未完成实际场景交互验证，请在你的练习场景做实际验证。

extends Node

var has_key: bool = false
var door_open: bool = false
var examine_count: int = 0

func try_open() -> String:
    examine_count += 1
    if door_open:
        return "门已经开着"
    if not has_key:
        return "门锁着，需要钥匙"
    door_open = true
    return "门打开了"

func _ready() -> void:
    print(try_open())
    has_key = true
    print(try_open())
    print(try_open())
    print(examine_count)

预期顺序是“门锁着，需要钥匙”“门打开了”“门已经开着”和数字 3。得到不同结果时，先对照自己改过的行，不要添加新功能掩盖问题。

var 声明变量，冒号后的部分说明类型，等号右侧是初始值。examine_count += 1 的意思是“把当前值加一再记回原位置”。if 后面的问题必须能回答真假，缩进决定满足条件时执行哪几行。not has_key 是“没有钥匙”，不等于“钥匙数量为零”这种尚未设计的数据模型。

func try_open() -> String 声明一个返回文字的动作。return 把结果交给调用者，也立即结束这一次函数执行，因此前面已经返回时，后面的开门语句不会执行。函数名后的括号代表调用；只写名字并不会自动把门打开。

现在把 examine_count += 1 移到 door_open = true 前一行，再预测计数。它会从“尝试了几次”变成“真正打开了几次”。这不是语法错误，却改变了变量含义，所以名字也应该改成 open_count。代码能运行不代表意思正确。

脚本顶层变量会在这个节点实例里保留；如果把 var examine_count: int = 0 写进函数内部，每次调用都重新开始，这样就无法累计。最后把门的反馈文字改掉而不改判断条件，体验“规则决定结果，文字负责表达”的分工。当前例子不消耗钥匙；是否消耗是游戏规则，不能由代码习惯擅自决定。

先暂时把 has_key = true 改为赋一段文字，观察类型相关错误，然后恢复。再把 door_open = true 移到“没有钥匙”的判断之前：程序可能仍能解析，却在规则上出错。第一种属于语法或类型层面的问题，第二种要靠输入与结果对照才能发现。

遇到错误时保留第一条报错、行号、当前代码和重现步骤。不要把所有警告都当成崩溃，也不要为了消除提示删掉类型。另一个常见问题是把比较 == 与赋值 = 混淆：前者问是否相等，后者写入新值。先用一句中文复述那一行想做什么，再选运算符。

增加一个 power_on: bool，规则改为“有钥匙并且通电才能首次开门”。先列测试表：无钥匙无电、有钥匙无电、无钥匙有电、两者都有、门已经打开。每行写预期反馈，再修改函数实现；不要一次加入背包、任务、音效和动画。

验收时让自己解释：哪些行只判断，哪些行修改状态，哪几条路径会提前返回；随后从空脚本重新写出一个等价版本。允许查函数语法，不允许仅复制成品后说“我懂了”。当你能找出一条“能运行但规则不对”的代码并修好，就已经具备检查 AI 小段脚本的第一项能力。