我花了三天才搞定的“智能狗”编程题，AI也翻车了
前言
前几天我在做一道状态机模拟的编程题：一只智能狗在一条直线上前后移动，会发热、耗电，遇到障碍物会停下，温度太高会自动冷却，电量太低会自动充电。听起来不复杂，但我整整花了三天才把它跑通。
这三天里，我和一个AI助教反复拉扯了几十个回合，期间推倒重来了三次，写了十几个测试文件。最后代码跑通的那一刻，我最大的感受不是“我终于会了”，而是“原来编程是这样学的”。
这篇文章不贴完整代码，只分享我在这个过程中学到的东西。
第一阶段：我以为我会了
一开始我很自信。类？我会。方法？我会。循环？我会。于是我刷刷刷写完了moving_forward、cool_down、charge三个方法，觉得差不多了。
然后AI助教问我：“移动过程中温度超标怎么办？”
我说：“那就调用cool_down啊。”
AI又问：“那cool_down是谁来调用的？是移动方法自己调，还是主循环调？”
我愣住了。这个问题我从来没想过。
第二阶段：单一职责原则
AI给我讲了单一职责原则：一个方法只做一件事。
移动方法只负责移动，不负责冷却
冷却方法只负责冷却，不负责充电
主循环负责协调所有事情
我一开始不理解：“可是移动过程中温度超标了，难道不是应该立刻冷却吗？如果移动方法不调用冷却，那谁调？”
AI说：“移动方法应该做的是：检测到温度超标 → 停止移动 → 返回一个中断信号给主循环 → 主循环根据中断原因调用冷却方法。”
我问：“这不绕了一圈吗？直接调用不是更快？”
AI说：“直接调用是更快，但耦合度更高。如果以后你想改变冷却的逻辑（比如先记录日志再冷却），你得改移动方法的代码。而通过主循环协调，你只需要改主循环，移动方法完全不用动。”
这个道理我听懂了，但说实话，直到我自己动手写主循环的时候，才真正体会到这样设计的好处。
第三阶段：主循环——最难的部分
独立方法都写好了，测试也都通过了。但当我开始写run_simulation主循环时，我发现自己根本不知道从哪里下手。
我有这些零件：
一个可以移动的狗
一个可以冷却的狗
一个可以充电的狗
一堆按时间排序的指令
一堆按时间采集的传感器数据
但我不知道怎么把它们串起来。
AI给我画了一个流程图：
按时间排序指令
遍历每条指令
如果当前时间还没到指令时间，把时间跳到指令时间
根据指令类型执行对应的动作
动作结束后，更新时间戳
查询最近的传感器记录，更新环境参数
检查是否触发报警
记录位置和状态变化
处理下一条指令
我对着这个流程图写了一遍，跑不通。再写一遍，还是跑不通。第三遍，终于跑通了。
那一刻我突然明白：流程图和代码之间的距离，就是经验和练习的距离。
第四阶段：AI也翻车了
写到后面，我发现自己的代码总是有重复的报警记录。我让AI帮我查，AI说：“你这里缺一个continue。”
我加上continue，还是有重复。AI又说：“你check_alarm里用extend加字典，应该用append。”
我改成append，还是有重复。AI沉默了一会儿，说：“你把冷却方法里的check_alarm调用去掉试试。”
我去掉了，果然好了。
这时候我才意识到：AI不是万能的。它可以帮你找到问题的方向，但最终定位问题、解决问题的，还是你自己。
更让我惊讶的是，后来我又找了另一个AI来审查代码，两个AI给出的修改建议居然不一样。一个说“碰撞检测要实时监测”，另一个说“碰撞检测只在动作结束时更新”。我不得不自己去看题目描述，自己判断哪个更合理。
AI可以帮你生成代码，但不能替你理解需求。
第五阶段：支撑轮理论
整个过程中，我最喜欢AI讲的一个比喻——支撑轮理论。
学骑车的时候，支撑轮的作用不是让你永远依赖它，而是让你在摔倒之前有时间感受平衡。我的代码也是这样：
第一次写：扶着支撑轮，每一步都问AI“这样对不对”
第二次写：支撑轮松了，能自己骑一段，但拐弯时还要扶一下
第三次写：支撑轮拆了，虽然骑得摇摇晃晃，但终究是自己骑下来的
我现在还处在“支撑轮刚拆”的阶段。骑得不稳，但我知道自己会越来越稳。
几个具体的教训
先画流程图，再写代码。 我第三次重写时，先在纸上画了主循环的流程图，写代码的速度比前两次快了一倍。
每个方法只做一件事。 移动方法不要调用冷却方法，冷却方法不要记录报警。让主循环来做协调。
先测零件，再总装。 我写了一个
test.py，专门用来单独测试moving_forward方法。零件没问题了，再组装整车。AI是好工具，但不是万能钥匙。 它可以帮助你拓宽思路，但最终的决定权在你手上。你才是最了解题目需求的人。
重复是最好的老师。 我推倒重来了三次，每一次都比上一次理解得更深。不要怕重写，重写是学习的捷径。
结语
三天前，我连if __name__ == '__main__'为什么要这样写都说不清楚。三天后，我能独立写出一个完整的状态机模拟程序。
这三天里，我最大的收获不是这段能跑的代码，而是我知道了怎么去学一个我不会的东西：
拆解问题
逐个击破
组装测试
推倒重来
直到熟练
这个过程很痛苦，但很值得。
这篇文章发布后，我希望它能帮到那些和我一样，正在从“照着写”迈向“自己写”的初学者。编程不是背答案，而是学会解决问题的方法。