前言前几天我在做一道状态机模拟的编程题一只智能狗在一条直线上前后移动会发热、耗电遇到障碍物会停下温度太高会自动冷却电量太低会自动充电。听起来不复杂但我整整花了三天才把它跑通。这三天里我和一个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__为什么要这样写都说不清楚。三天后我能独立写出一个完整的状态机模拟程序。这三天里我最大的收获不是这段能跑的代码而是我知道了怎么去学一个我不会的东西拆解问题逐个击破组装测试推倒重来直到熟练这个过程很痛苦但很值得。这篇文章发布后我希望它能帮到那些和我一样正在从“照着写”迈向“自己写”的初学者。编程不是背答案而是学会解决问题的方法。