用AI写代码三个月，为什么我的代码越来越难维护？

我也有同感，AI写代码最大的问题就是它只保证“能跑”，不保证“好改”。我后来强制自己每个生成的组件都先过一遍，把状态逻辑抽成hooks，再让AI按这个结构去补，冗余能少很多。另外建议你定个规矩：AI生成的代码必须过人类review，重点看有没有重复造轮子，我们团队试了俩月，维护成本明显降下来了。

说实话你这个痛点太真实了，我最近也发现AI写React组件特别喜欢用useMemo和useCallback把逻辑绕成迷宫，局部看着挺规范，但改一个props能牵出七八个隐藏依赖。我现在强制自己把公共逻辑抽成自定义hooks，并且每次让AI生成代码后必须补上类型定义和关键注释，不然两周后自己都看不懂。至于review，我们团队现在要求任何AI生成的代码必须附带生成时的prompt，方便回溯当时的业务场景，至少能减少一半的“一次性”代码。

说实话我也有同感，Copilot写出来的东西像“外包代码”，能用但不敢深挖。我的办法是给AI限定“最小实现”+“禁止重复封装”，逼它写直白逻辑，复杂状态管理还是自己上手。另外我把AI当初级开发，必须过严格CR，重点查副作用和依赖关系，现在冗余少多了。

这个我太有同感了，AI写出来的东西就是“局部最优、全局灾难”，尤其是它特别喜欢把简单的状态逻辑拆成绕来绕去的闭包和副作用。我现在的做法是让AI只生成纯函数和UI片段，所有涉及数据流的部分必须自己手写，相当于给它划定“安全区”。另外code review的时候别只看功能对不对，专门盯着“这段逻辑如果换个人来改会不会想骂人”这个标准，不合格的直接打回重写。至于重构，建议先跑一遍依赖分析工具，把AI生成的重复组件标记出来，一次性清理反而比零敲碎打更安全。

这问题太真实了，我团队也踩过同样的坑。后来我们强制要求AI生成代码必须带上单元测试和类型定义，review时候重点看状态流和副作用，不允许它自己发明“巧”写法，宁可啰嗦一点。另外提示词里明确写“优先复用现有组件，不要新建相似结构”，能少不少冗余。但说实话，架构级的重构还是得人肉来，AI目前就是个高级补全工具，别指望它替你思考。

我也有同感，Copilot写出来的东西局部很聪明，但全局观基本为零。现在我的做法是让AI只负责纯函数和样式块，业务逻辑和状态管理必须自己手写，另外每周末固定抽两小时把AI生成的代码做一次“翻译”，改成我能一眼看懂的样子。其实最坑的是它生成的组件复用性差，我最近干脆在prompt里加了一句“优先复用现有工具函数”，情况好转不少，但依赖隐藏问题还是得靠code review的时候盯紧点。

说真的你这个问题我太有同感了。我团队用了半年AI辅助，现在代码review最怕看到那种“看起来能跑但没人敢碰”的模块。我后来总结了个笨办法：凡是AI生成的逻辑，必须让它在注释里写清楚“为什么这么写”，写不出来就说明它自己都不知道在干嘛。提示词方面，我现在会强制加上“请基于现有项目结构复用已有工具函数，不要新造轮子”，效果立竿见影，重复组件少了一半。但最关键的还是code review流程得改，我们规定AI生成的代码必须过两个人，一个看业务正确性，一个专门盯可维护性，哪怕慢点也得过。别指望提示词能根治，那玩意儿本质是概率模型，你指望它理解“长期维护”太难了，最终还是得靠人肉兜底，只是说AI帮你把脏活累活干了，你有精力去重构那些真正的坑。现在我的心态就是：AI是实习生，代码写出来必须当草稿用，得按自己的标准重新捋一遍。

把AI当结对编程的实习生，每次生成后必须自己重读逻辑，看不懂就当场改掉，别让技术债过夜。

建议把可复用的组件先抽出来再喂给AI，让它基于你的封装生成，不然它只会复制粘贴你的坏味道。

这问题太真实了，我周围好几个用AI写代码的同事都踩了同一个坑。我觉得核心矛盾在于，AI生成代码是“统计最优”而不是“架构最优”，它倾向于把能跑通的逻辑拼起来，压根不管模块边界和扩展性。你提到的那种“一次性”状态管理，我猜是它特别喜欢用闭包或者全局变量来绕过传参，局部测试没问题，一旦多个组件共享数据就全乱了。我自己摸索出的一个土办法是：让AI先写实现，但把架构决策（比如状态放哪、组件怎么拆分）强制留给自己，提示词里直接写“不许引入新依赖”或者“必须遵循现有目录结构”，能砍掉一半的乱代码。至于code review，光靠看diff根本抓不住隐藏依赖，我后来要求AI先输出一个“影响范围清单”再写代码，逼着它把牵涉的模块列出来，这样审查就有抓手了。不过说实话，冗余代码这个问题我也没完全解决，现在最大的心得是每周固定抽两小时专门做“AI代码整容”，把重复组件合并成一个带props变体的版本，虽然累但至少比最后爆雷强。你那边有没有试过让AI自己分析自己的代码复杂度？我试过一次，它还挺诚实，会标出哪些地方是“临时方案”。

说实话这个问题太真实了，我最近也有同感。AI生成代码最大的坑就是“局部最优但整体混乱”，尤其是状态管理那种隐式依赖，你根本不知道它哪一步就埋了个雷。我现在习惯让它先写单元测试再写实现，倒逼它理清逻辑，至少能暴露一部分隐藏假设。另外建议给Copilot定个规矩，比如“优先复用现有工具函数”写进系统提示里，能少造不少轮子。至于重构，我都是先跑一遍全量测试再动手，不然真不敢碰。

这问题太真实了，我团队也踩过同样的坑。后来我们定了个规矩：AI生成的代码必须过一遍“需求逆向评审”，就是让写的人对着代码讲清楚每一步为什么这么写，讲不清的直接重构。另外提示词里强制要求“优先复用现有工具函数和组件”，能压掉不少重复代码。

最关键的还是得把AI当实习生用，大方向自己把控，细枝末节让它填。现在我们对AI代码的容忍度是“能跑不算完，得能改得动”，但凡逻辑绕得看不懂，就让AI自己解释或者换种写法重来。

还有个小技巧，每周抽半天专门做“AI代码除冗余”，把相似组件人工合并，虽然累点，但比攒到后面一次性爆炸强多了。

说实话我也踩过这个坑，AI生成的代码就像外包写的，能跑但不敢碰。后来我强制自己每次让它生成前，先贴上项目的现有组件和状态管理规范，再明确要求“复用已有模块，不要新建相似组件”，效果会好很多。

另外code review可以加一条硬规则：AI提交的代码必须标出来，重点查冗余和隐藏依赖，宁可多花半小时拆解，也别攒到后面不敢重构。我甚至试过让它先画个逻辑草图再写代码，绕路情况少了不少。

但说到底，它只是加速器，方向盘还得自己握。你现在的恐惧感其实很真实，允许自己慢下来，把“小改”改成“看懂再改”，哪怕效率降三成，长远看是赚的。