当我说 Claude 搭配 GLM-5.3-Flash 太好用了，同事却提醒我：你可能正在失去对代码的掌控
昨天下午，我和同事聊起了 AI 编程。
同事目前主要使用对话框形式的 AI 工具，比如豆包 PC 端，还没有开始使用 Claude Code、Codex、Cursor 这类能够深入参与项目开发的工具。
聊到这里，我主动帮他搭建了 CC Switch 环境，配置 Claude 的使用环境。他使用的是火山方舟 Agent Plan Medium 套餐提供的 API 服务。
配置完成后，我向他分享了自己的使用感受。
说实话，Claude 搭配 GLM-5.3-Flash，在我的实际开发过程中确实非常好用。无论是新增需求、修改代码，还是排查 Bug，AI 都能帮我承担大量工作。
有些功能，我不需要再像过去那样，从头到尾自己编写每一行代码；遇到 Bug，也可以先让 AI 分析问题、定位原因，再提出修复方案。
开发效率确实提高了。
所以当时，我的评价很直接：
Claude 搭配 GLM-5.3-Flash，太完美了。很多时候，我甚至不需要自己写代码和调试 Bug。
但同事的回答，让我重新思考了这件事。
一、同事的一句话，让我开始反思
同事认为，这样开发下去，可能会逐渐失去对项目代码的掌控。
他的理由很简单。
AI 生成了一大段代码，我们在 Review 的时候，可能只是快速浏览一遍，确认整体逻辑看起来没有问题，就继续推进开发。
但快速浏览不等于真正理解，更不等于记住。
代码今天由 AI 生成，明天又由 AI 修改。随着需求不断增加，代码量持续增长，我们可能越来越依赖 AI 去解释自己项目里的代码。
到最后，代码明明是自己负责的项目，自己却未必能清楚地说出某个功能为什么这样实现、某个状态为什么这样流转、某个异常为什么会出现。
我当时并没有完全认同他的观点。
因为在我的开发习惯中，我并不是让 AI 不加限制地直接修改代码。
新增需求时，我会先整理需求文档；修复 Bug 时，我会先分析问题。等文档经过 Review、确认没有明显问题后，再让 AI 按照文档实施开发。
代码完成后，还要进行单元测试，最后再对照需求文档检查代码。
从流程上看，这套方法似乎没有什么问题。
既有需求分析，也有文档评审、测试和代码 Review。既然每一步都有约束，为什么还会失去对代码的掌控？
当时，我认为这已经是比较合理的 AI 开发方式。
但后来，我换了一个角度审视自己的工作。
二、真正让我警惕的，不是 AI 写代码，而是我开始记不住代码
我认真回想了一下自己最近的开发状态。
过去，开发一个功能时，我需要自己分析需求、梳理调用链、设计实现方案，然后一步步编写代码。
这个过程很慢，但有一个好处：为了让功能正常运行，我必须深入代码细节。
某个方法为什么这样写，某个状态在哪里发生变化，某个异常为什么会出现，这些东西会随着实际开发过程进入自己的理解体系。
现在，AI 可以替我完成大量工作。
它能够分析调用链，找到相关文件，修改代码，甚至给出测试方案。我需要做的事情，逐渐变成描述问题、确认方案、检查结果。
这确实减少了重复劳动。
但我也发现，自己对项目代码中一些具体细节的记忆，正在变得模糊。
有些代码，我以前可能亲自写过，但现在再看到时，已经不能立刻说清楚它的实现过程。
遇到某些问题，我的第一反应也越来越容易变成：让 AI 帮我看看。
这里必须区分两件事。
第一件事是，我不再记得每一行代码。第二件事是，我不再具备独立理解、分析和修改这些代码的能力。
这两件事并不完全相同。
一个有经验的程序员，本来就不需要记住整个项目的所有实现细节。忘记某个方法的具体写法，也不意味着编程能力消失了。
真正值得警惕的是：当我离开 AI 的帮助时，是否还能独立定位问题、理解核心逻辑、判断修改的影响，并在必要时完成修复？
如果这些能力也在下降，那么问题就不是记忆力变差，而是自己的开发能力可能正在发生变化。
这才是我开始担心的地方。
三、我原来的开发流程，真的能解决这个问题吗？
回到最初的争论。
我认为，只要先写需求或问题分析文档，再让 AI 编码，最后进行测试和 Review，就能够控制开发质量。
现在看来，这个判断只说对了一部分。
这套流程确实能够降低需求理解错误、修改范围失控和遗漏测试的风险。
但它不能自动保证我真正理解了代码。
举个例子。
假设 AI 根据需求修改了一个 Android 功能，涉及 Activity 生命周期、异步任务、状态更新和异常处理。
我先让 AI 分析需求，再让它输出实施方案。方案没有问题，于是 AI 开始修改代码。
最后，单元测试通过，代码 Review 也没有发现明显问题。
从流程上看，任务已经完成。
但如果我说不清楚以下问题，这次开发就还存在一个缺口：
- 为什么选择这种实现方式，而不是另一种方式？
- 这个状态在什么条件下发生变化？
- 如果请求失败、页面销毁或任务重复触发，会发生什么？
- 修改的代码会影响哪些其他调用方？
- 如果线上出现异常，我能否不依赖 AI，独立找到关键问题？
这些问题并不是要求程序员记住每一行代码，而是要求程序员掌握代码背后的关键逻辑。
文档评审解决的是方案是否合理，测试解决的是特定条件下行为是否符合预期，代码 Review 解决的是实现是否存在问题。它们都很重要，但不能替代开发者本人的理解。
这也是我对原有工作方式需要修正的地方。
我不能因为 AI 输出了完整的分析文档，就认为自己已经理解了问题；不能因为测试通过，就认为自己掌握了实现；更不能因为代码看起来没有问题，就默认自己仍然拥有修改和维护它的能力。
四、接下来，我需要改变的不是 AI 工具，而是使用 AI 的方式
我不认为应该因此放弃 Claude Code、Codex 或其他 AI 编程工具。
效率提升是真实存在的。让程序员重新手写所有重复代码，也不是解决问题的合理方式。
真正需要调整的是：把 AI 生成代码的效率，与自己理解和掌控代码的能力分开衡量。
以后开发需求或修复 Bug 时，我仍然会先分析问题、整理文档、评审方案，再让 AI 实施开发。
但我还需要增加几个明确的检查点。
第一，要求 AI 解释关键实现，而不是只检查它给出的结论。我需要弄清楚核心调用链、状态变化、关键判断和异常处理。
第二，Review 时不只看代码有没有明显错误，还要主动追问修改原因。对于重要的实现，我必须能够用自己的话解释清楚。
第三，测试不能只看一个通过或失败的结果。我需要关注测试覆盖了什么、没有覆盖什么，以及异常场景是否得到验证。
第四，定期进行不依赖 AI 的独立分析。遇到熟悉的问题时，先自己定位、画出调用链或提出解决思路，再让 AI 进行对照。这样才能判断自己究竟是不会，还是只是习惯了让 AI 代劳。
第五，明确自己的责任边界。代码可以由 AI 编写，但需求是否正确、方案是否合理、修改是否安全，以及最终代码能否交付，仍然需要由我负责。
我不必记住项目中的所有代码，但必须知道关键逻辑在哪里、为什么这样设计，以及出现问题时应该从哪里开始排查。
五、AI 提高了我的开发效率，但我不能把判断能力也交出去
这次和同事的交流，并没有让我否定 AI 编程。
相反，它让我意识到，使用 AI 这件事并不是简单地分成两派：一派拥抱 AI，一派坚持手写代码。
真正需要考虑的是，如何在提高效率的同时，保留自己的技术判断能力。
如果 AI 帮我完成重复的代码编写，让我把更多精力放在架构、问题分析和系统设计上，那么这是一种有价值的提升。
但如果我只是不断向 AI 提出需求，接收代码，再快速 Review，最后把所有不确定的问题继续交给 AI，那么即使我的开发速度提高了，也不能证明我的能力同步提高了。
甚至可能出现一种情况：我交付的代码越来越多，开发速度越来越快，但面对项目中的复杂问题时，我却越来越依赖 AI。
我不希望自己变成这样。
我希望 AI 能够放大我的能力，而不是逐渐替代我思考问题的过程。
当然，我现在还不能确定自己的编程能力是否真的下降了。记不住一些代码细节，也可能只是工作方式发生了变化。
但这个信号值得认真对待。
接下来，我更应该做的不是纠结于自己是否还记得每一行代码，而是通过实际开发检验自己：离开 AI 的即时帮助后，我是否仍然能够理解问题、分析原因、判断方案，并独立完成关键部分的工作。
这才是我需要持续关注的事情。
AI 可以替我写代码，但我不能因此放弃理解代码的能力；AI 可以帮我解决问题，但我不能把判断问题的责任也交给它。
这是我昨天和同事交流后，真正留下来的思考。