AI 写完代码以后，需要理解到什么程度？

用 AI 写代码已经很顺手了。把需求说清楚，拆出计划，再让它生成实现，很多过去需要慢慢补齐的代码，很快就能摆在面前。真正让我有些在意的，是代码生成以后那种熟悉又陌生的感觉。

需求是自己提的，模块也是按自己的思路划分的，但点进具体实现时，阅读体验经常接近接手别人写的代码。大概知道这一块负责什么，也看过几处关键逻辑，至于某个函数究竟在哪个阶段调用，某个对象在退出时是否仍被回调引用，就未必能立刻回答。

亲手写代码时，也会遗漏这些问题。但逐步实现的过程通常会顺带积累一些细节记忆：为什么先初始化这个对象，为什么需要在这里取消任务，某个分支曾经考虑过什么。生成代码省去了大量敲代码的时间，这些认识却需要另外补回来。

于是开始想，AI 写完以后，究竟应该把代码理解到什么程度，才算能对这份实现负责？

知道功能，离知道运行过程还有一段距离

模块名和函数名很容易给人一种理解了的感觉。看到加载、更新、销毁几个入口，大体就能讲出系统做什么。可程序实际出问题时，往往发生在这些入口之间。

比如，一个异步加载函数单独看没有明显问题，完成回调也写得很清楚。如果等待期间用户已经切换场景，回调还能不能继续访问原来的对象？如果重新发起了一次请求，前一次请求的结果会不会覆盖新的状态？退出时取消了任务，又是否能保证已经排队的回调不会执行？

沿着这样的场景想下去，就会发现，读过几个关键函数，仍然可能错过函数之间的时间关系。每一段局部逻辑都说得通，组合起来却需要额外的前提。

渲染和引擎代码里也有类似情况。初始化、提交和释放都实现了，不代表它们的先后关系就正确。CPU 侧已经走完清理流程时，GPU 可能还在使用资源。若只看某个释放函数有没有调用，很难判断释放时机是否成立。

所以，对一段代码的理解还需要包括它怎样进入运行状态，过程中有哪些状态变化，以及怎样安全地结束。功能说明能帮助快速定位，调用链和生命周期才让这些说明落到实际执行上。

全部精读，确实有成本

最直接的办法当然是把生成的代码从头读到尾。但当一次生成涉及许多文件时，逐行研究所有细节会花不少时间。花完这些时间，也可能因为缺少系统视角，依然没发现关键的顺序问题。

说实话，也确实有懒得看的时候。功能已经跑起来，AI 给出的解释似乎也合理，就容易想先把事情往前推。这个念头很真实，但功能跑通一次，只能证明当时的输入和执行顺序没有暴露问题。

目前更倾向于按风险分配阅读精力。范围清楚、容易撤回的展示代码，可以结合完整的改动浏览和效果检查来确认；涉及共享状态、并发任务、资源释放、持久化数据或核心运行流程时，就需要沿调用链细读。遇到不熟悉的 API，还要核对它在当前版本里的真实语义。

这里的前提是先知道这次到底改了什么。文件数量、接口变化、新增依赖和对既有流程的影响，都需要有一个整体判断。若连改动范围都无法说清，也就很难决定哪些部分可以少花时间，哪些部分必须仔细看。

精力有限，阅读应当有轻重；关键路径里的未知，需要被明确找出来。

给理解程度设一个具体门槛

如果要给自己设一条交付前的门槛，想用几个实际问题来判断。

首先，能不能从入口讲出这次功能的执行过程？输入从哪里来，经过哪些状态，在哪一步产生副作用，最后如何结束。无需背下全部函数名，但应该能找到对应代码，并确认实现和自己的解释一致。

其次，能不能说清核心对象和资源由谁持有？创建、借用、转交和释放分别发生在哪里，异步任务结束前谁保证对象仍然有效。这里如果只能回答大概会自动释放，就需要继续看。事件订阅、缓存、原生资源和 GPU 资源，都可能有各自的清理条件。

还要知道正常流程之外会怎样。初始化只成功了一半，已经分配的资源如何处理？用户中途退出，哪些工作需要取消？同一个入口连续调用两次，会重复注册还是被正确处理？这些情况通常比正常调用更能暴露实现依赖的假设。

最后，出现异常时，能不能提出一个可验证的排查方向？例如先检查输入是否准备好，再看状态是否推进，最后确认结果是否被消费。至少要能找到观察点，知道补什么日志、断点或测试有助于缩小范围。

这些问题答不出来时，即使代码已经通过编译，也还没有达到想要的掌控程度。反过来，如果能沿着实际代码把这些关系解释清楚，再用运行结果验证关键假设，就比只记住模块功能踏实得多。

验证要从需求和约束出发

让 AI 检查代码很有帮助。它能快速找出一些遗漏，也能提出值得追问的地方。不过，生成和检查可能沿用相同的假设。实现默认一个对象不会提前销毁，检查时若继续接受这个前提，两次回答都合理，隐患仍然会留着。

因此，验收条件最好在看实现之前，就根据需求和项目约束想一遍。比如一个异步资源接入功能，除了加载成功后能使用，还应该考虑等待期间退出、重复发起请求、加载失败以及旧请求晚于新请求完成。每个场景下允许发生什么，都需要先有明确预期。

AI 可以帮忙补充场景、生成测试，也可以协助分析失败结果。预期是否符合业务，测试有没有覆盖重要约束，仍然需要自己判断。如果测试只是照着实现的分支再写一遍，它很可能只能证明代码按现有写法运行。

同样，模拟测试覆盖不了所有运行环境。线程调度、设备差异和 GPU 执行时序等问题，需要对应的运行检查。有些行为还依赖引擎或库的具体版本，说明写得再流畅，也要回到实际接口和运行结果上确认。

验证的目标应该是减少某个具体的不确定性。编译帮助确认类型和引用关系，测试帮助确认约定行为，运行观察帮助确认真实环境下的执行。知道每项检查证明了什么，也就能看见还有哪些地方没有证据。

把生成速度控制在能理解的范围里

还有一个很实际的办法：让每次改动保持在自己能审查的范围内。

一次让 AI 生成完整系统，代码量会增长得很快。等到需要解释运行关系时，往往已经包含多层封装和许多相互依赖的状态。此时再回头建立理解，成本会集中到最后。

更适合自己的做法，可能是先确认输入输出和状态关系，再补一条可运行的主流程，随后处理失败、取消和清理。每一步都检查实际改动，确认它接到了预期位置，也确认既有行为仍然成立。拆分的尺度可以随任务调整，核心是每轮都有清楚的验收对象。

在这个过程中，也可以让 AI 帮忙画调用关系、列出资源的持有者，或指出需要结合引擎约定核查的地方。这些材料能降低阅读门槛，但遇到关键结论，仍然应该点回代码确认。解释和实现有出入时，以实际执行关系为准。

如果一批代码已经大到无法判断它会影响哪里，就该先缩小范围，或者花时间补齐系统认识。继续生成更多实现，只会让待理解的部分越积越多。

希望保留的是怎样的工程能力

用 AI 久了，确实容易把工作组织成提出需求、生成代码、再让 AI 检查的一套流程。这套流程能承担很多劳动，但程序员仍然需要知道项目有哪些约束，哪些改动值得做，以及什么结果足以支持交付。

在引擎开发里，这些判断常常涉及已有资源系统的约定、平台能力、帧预算和调试成本。一个实现局部上很合理，却可能不适合当前项目。把这些上下文讲清楚，也需要先理解它们为什么存在。

希望自己保留并继续积累的，是这种贴着项目做判断的能力：能发现需求中含糊的地方，能把风险变成具体场景，能解释关键路径，也能根据真实结果调整方案。AI 可以参与其中很多步骤，判断依据仍然需要自己核实。

至于不可替代性，暂时很难给出一个确定答案。工具还会继续变化，单靠某一种使用技巧，也未必能形成长期优势。至少对现在的工作而言，把代码写出来以后还能接着定位、修改和维护，是可以持续练习的能力。

接下来想试着在每次较重要的 AI 改动后，留下一份简短记录：这次影响了什么，关键路径怎样运行，验证过哪些异常场景，还有哪些假设需要进一步确认。记录不用长，但要能帮助过一段时间后的自己重新接上这份代码。AI 节省下来的实现时间，也值得分一部分给这些工作。