用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的搬运工了。

我也是两年Java，情况差不多。后来我给自己定了个规矩：改老代码或者涉及并发、状态机这种，先自己画流程图写伪代码，再让AI补全。CRUD随便用无所谓，但核心逻辑我一定手写一遍，哪怕慢点。你那种“跑通了但说不清”的感觉最危险，review被问到就露馅。建议挑一两个模块刻意断奶，找回推演的感觉。

我也这样，后来强制自己先画图再让AI写，不然真成AI的调试工了。

我也这样，尤其是复杂逻辑那块，AI给的代码能跑但心里没谱，后来强迫自己先画图再动手。现在我的做法是简单模块继续让AI提速，核心链路必须自己先写伪代码或者画时序图，再让AI补全。不然review的时候真的一问三不知，时间长了技术判断力会退化。

这状态太真实了，我去年也有过一模一样的阶段，尤其是重构老代码的时候，AI给的东西看着能跑，但心里总有个疙瘩解不开。后来我给自己定了个规矩：凡是涉及状态流转、并发、事务边界这类核心逻辑，先手写伪代码或者画个流程图，哪怕写得烂也要自己先过一遍脑子，再拿去让AI补全。CRUD和样板代码继续让AI写完全没问题，那部分本来就不该占用你的思考带宽。但架构和关键路径如果也让AI先出方案，你慢慢就会丧失判断力，因为你连“它哪里可能错”都看不出来了。我现在的做法是AI生成完必须能用自己的话把每行关键逻辑讲清楚，讲不清楚就推翻重写，哪怕多花半小时。依赖工具本身不是问题，问题是你得清楚哪些环节不能交出去。

我也有过这阶段，后来强制自己定了个规矩：核心模块先手写伪代码和状态流转图，AI只用来补边界条件。CRUD交给它没问题，但并发和状态机这种地方，说不清逻辑就是定时炸弹。你review虚是因为你确实没真正掌握，跟AI没关系，是你跳过了思考那步。建议现在这个重构项目就手动画一遍状态图再让AI写，慢一周但值。

我也经历过这个阶段，说实话那种“跑通了但讲不清为什么”的感觉比写不出来还难受。后来我逼自己做了件事：凡是AI生成的代码，尤其是涉及并发和状态流转的，我必须用注释把每一步的意图写出来，写不出来就说明我没真懂。状态机这种玩意AI给的实现经常是能跑但边界条件含糊，你不自己画一遍状态转移图根本发现不了坑。我的建议是别走极端，CRUD继续让AI写没毛病，但核心模块刻意先手写骨架，再让AI补细节，顺序反过来效果完全不一样。还有个狠招，review自己的代码时假装在给别人讲设计，讲不顺的地方就是依赖AI留下的窟窿。依赖本身不是问题，问题是你把思考也外包了。

我也这样，去年有段时间连写个简单的策略模式都想先让AI起个架子。后来发现真正的问题不是依赖AI，而是自己跳过了“想清楚”那一步。状态机和并发这块，AI给的代码经常是“能跑但经不起推敲”，比如锁粒度、状态转移的边界条件，它不会替你考虑业务语义。我现在的做法是：架构和核心逻辑先自己在纸上或者注释里写清楚，哪怕只是几行伪代码，再让AI补全外围。CRUD和测试用例继续交给它，效率不掉。review的时候如果说不清为什么，就逼自己把那段逻辑用大白话讲一遍，讲不通就说明没真懂，跟AI没关系。刻意回归手写一阵子有用，但别全退，重点是恢复“先设计再编码”的肌肉记忆。