我喜欢把代码写得顺眼但一个项目能不能交给后来的自己最终看的是另一件事隔几个月重新打开它还能不能判断一次修改为什么成立。程序员节适合谈创造也适合把夸张的形容词收一收。一个小关卡、一个会说话的NPC不必立刻叫作数字生命它只要能清楚回答“状态从哪里来、操作造成什么变化、失败时留下什么”就已经值得继续做下去。把演示拆成三份证据第一份是规则。钥匙开门、受伤中断、任务完成条件应该能从代码和数据中找到而不是只存在于演示视频的讲解里。第二份是输入。录像中的操作顺序、随机种子和初始存档应当可以保存。第三份是输出。别只留一张漂亮截图还要留下门的状态、物品归属和错误信息。它们不华丽却能告诉我画面变化是规则造成的还是碰巧看上去像成功。新工具降低开工门槛也增加解释责任Unity在10月1日公布Grok Build官方插件时强调不同编码agent共享Unity工程指导10月7日与Google的合作公告则把Spark放在后续推出安排中。这些变化让我更关心生成后的工程由谁读懂。工具能建立场景不等于已经定义清楚游戏。最值得保留的不是“用了多少agent”而是一个别人能重走的操作路径。对于AI生成资产也应能追踪输入、授权范围和实际使用版本。一个小例子也可以成为交接点我愿意为一个门锁规则写几行断言因为它省下的不是某次演示的时间而是下一位维护者猜测规则的时间。下面没有模拟复杂引擎只写出一个关键约定已经打开的门不会反复消耗钥匙缺钥匙也不会改变世界。这比一段“我们彻底消灭了所有Bug”的宣言更诚实。错误仍会出现只是出现时有地方开始查。想法需要落到规则、输入和可检查输出漂亮的演示只是其中一份材料。把关键规则缩成一个可运行例子下面使用 Python 3 标准库表达算法规则保存为example.py后运行python3 example.py。它便于观察输入和输出不替代引擎中的 C、Shader 或模型实现。def open_door(state): if state[open]: return already_open if state[keys] 0: return locked state[keys] - 1 state[open] True return opened s {keys: 1, open: False} assert open_door(s) opened assert open_door(s) already_open assert s {keys: 0, open: True} print(one key consumed; repeated action is harmless)本例输出one key consumed; repeated action is harmless写给未来的代码可以不浪漫但别让别人只能依赖你的记忆。把一个假设写出来把一个失败保留下来把尚未试过的部分说清楚。未来的自己未必会记得今天的兴奋通常会感谢今天少留下了一处猜谜。适用范围这是一则工程写作与验证方法的手账门锁例子不是Unity项目实测也不代表任何已完成的商业发行。相关资料Unity官方Grok Build插件公告Unity与Google合作公告