用AI写代码半年了，感觉越来越依赖，但心里没底怎么办？

手写一阵子吧，重构这种活儿AI帮不了你补脑子的，状态机那部分真得自己啃明白才踏实。

跟你一样，后来强制自己先画时序图再碰键盘，依赖归依赖，基本功不能丢。

同款焦虑，我之前也这样，后来发现问题的关键不是AI写得对不对，而是你对那个模块的理解有没有跟上。重构老代码尤其危险，状态机这种用AI生成，出bug时你连排查方向都没有。建议这种核心逻辑先自己手写一版，哪怕是伪代码，让AI帮你补全细节，别让它从零生成，不然心里永远没底。另外，你跑通了但说不清，多半是没看它生成的测试用例，建议每次让AI解释下关键分支的意图，这比手写还练脑子。

这题我会，重构时先逼自己画状态图再让AI写，不然它给的并发方案你根本不敢上生产。

我也有同感，核心逻辑还是得自己先想透，AI当高级补全工具用就好，别让它带着你走。

得逼自己先画架构图再让AI动手，不然重构这种活迟早翻车。

手写一阵子吧，状态机这种核心逻辑AI只是拼概率，你心里没底就是它没兜住。

同款焦虑，我大概在重度用了四个月的时候也卡在这个坎上。你描述的状态机那块，太有共鸣了，我当时接手一个交易状态流转的遗留代码，第一反应也是先丢给AI生成个版本再说，结果它给了我一个看似正确但边界条件全错的实现，跑测试的时候才炸出来。后来我强迫自己改了流程：只让AI写那些我真的能逐行解释的模块，比如工具类、DTO转换这种，但凡涉及核心业务逻辑和并发控制，就关掉补全，自己从时序图开始画。这么做之后最大的变化是，重构时心里有底了，因为你知道哪些决策是你做的，哪些是AI瞎编的。说实话，完全回归手写不现实，效率落差太大，但我觉得得给自己设个“红线区域”，比如锁、状态机、事务边界这些地方，必须自己先想清楚再让AI辅助。另外你提到review心虚，这个特别危险，因为代码出问题往往是几个月后，到时候你连AI当时为什么这么写都忘了，查错成本全在自己身上。可以试试每次让AI生成完，逼自己写个三行注释说明核心思路，写不出来就说明没吃透，赶紧回去看文档。

重构这种硬骨头别让AI打头阵，先自己画完状态机再让它补代码，心里就踏实了。

你这状态我太懂了，AI写多了手生，建议啃硬骨头时纯手写，找回手感顺便逼自己想透。

重构这种硬骨头别让AI打头阵，自己先画状态机草图，它当副驾就行。

同感，重构状态机那块我也栽过。现在AI写出来的东西跑通跟理解是两码事，尤其并发控制，它给的方案有时候只是逻辑对，但性能或边界情况压根没考虑。我现在的做法是：CRUD随便让它写，但架构设计和核心模块一定自己先画清楚时序图，再拿给AI做参考。另外，它生成的关键代码我会故意改几个变量名或调整逻辑，逼自己逐行读一遍，至少能解释清楚每个分支。别慌，这不叫退步，是工具升级了但思维还没跟上，刻意练习一阵子就能找回掌控感。

跟你情况挺像的，我也是Java后端，用了大半年Copilot。状态机和并发这种确实不能先让AI铺代码，我现在的做法是逼自己先把核心接口和状态流转画出来，哪怕只是草稿，再让AI去填实现。你那种“跑通了但说不清为什么”的感觉我太熟了，后来发现是因为跳过了自己推演的那一步，脑子没参与进去。我试过刻意手写两周，说实话效率掉得厉害，但找回了一点对代码的掌控感，至少review的时候敢跟人掰扯了。现在的折中是：业务逻辑和复杂分支自己写，样板代码和测试全交给AI，但每段AI给的代码我都要能用自己的话讲一遍才提交。你那个重构模块，建议别一上来就生成，先花半天把状态迁移图和线程安全边界想清楚，后面AI能帮你省很多力气。依赖不是问题，问题是依赖之前你自己有没有底稿。

我也这样，后来强迫自己先画架构图再让AI填代码，不然真成AI的搬运工了。