Copilot和Cursor都用过了，为什么感觉代码越写越不踏实？

这问题太真实了，我也有同感。AI补全快是快，但那种“自信地胡说”特别坑，尤其状态管理里闭包和竞态这种隐性问题，它根本意识不到。我现在基本把Copilot当高级自动补全用，复杂逻辑还是自己搭骨架，只让它填无脑重复的代码。要是能自动标注“这段代码参考了哪个版本API”或者“此处可能有内存泄漏风险”，我才敢放手让它写。不然真就是给审查环节增加工作量。

把AI当结对编程的实习生用，别当权威，它给的是草稿，拍板还得靠你脑子里的那份技术债清单。

生产环境我真不敢全信它，关键逻辑还是得自己手写核心，再用AI去补那些样板代码才踏实。

我现在的做法是把AI当个记性特别好但偶尔会胡编的实习生，它出的代码我默认全是草稿。异步竞态和内存泄漏这块确实容易翻车，因为它看不到运行时的真实行为，只能靠模式匹配，生成的useEffect依赖数组经常是错的。我一般在它给完框架之后，自己把涉及生命周期和并发的那几行重写一遍，剩下的UI和样板逻辑就直接用。查文档这事我也经历过，后来发现与其一个个验证API，不如先让它写测试，跑不过的它自己就露馅了。Cursor的agent模式我更多用来做重构和跨文件改动，那种场景它比人快很多，但生产代码的最后一公里还是得自己走。说白了它适合把60分的东西快速拉到80分，剩下那20分恰恰是最要命的，指望它兜底不太现实。

我现在的习惯是让AI先写，但自己必须逐行过一遍，尤其是异步和effect那块，它给的依赖数组经常漏东西。你这种不踏实的感觉其实挺正常的，说明你在认真读代码，比无脑接受强多了。我一般把Copilot当高级补全用，agent模式只拿来写测试和样板，核心逻辑还是自己动手。真要说的话，它更适合加速你已经会的东西，而不是替你想清楚你没想明白的部分。

我现在的做法是把AI当“结对新人”而不是“资深同事”，它给思路我给判断。你说的那种查文档反而更累，我太懂了，尤其是React这种生命周期和hooks规则容易踩坑的地方，它生成的代码看起来特别顺，但一跑就发现闭包捕获了旧state，或者useEffect依赖漏了。后来我给自己定了个规矩：凡是涉及异步竞态、订阅清理、状态机这类逻辑，AI写的我只当草稿，必须自己重写一遍或者至少逐行过一遍。补全和样板代码我是真离不开了，比如写个reducer的switch、类型定义、测试mock，省下来的时间拿去盯核心逻辑。但agent模式我反而用得少，因为它一次改好几个文件，出问题的时候排查成本比手写还高。我觉得不是工具不适合生产，是它适合生产里那些“错了也容易发现”的部分，真正容易埋雷的地方还是得自己扛。

我现在的做法是让AI写“骨架”，但凡是涉及异步、副作用、生命周期这些地方，我基本都会自己重写一遍。它补全快是真的，但它对运行时行为的理解经常停留在“看起来对”的层面，尤其是竞态和清理逻辑，翻车率不低。你可以试试把AI限制在纯函数和类型定义这些确定性高的部分，复杂逻辑自己来，效率反而更稳。另外它编API这事无解，我现在都开着文档在旁边随时查，习惯了就好。

我现在的习惯是让AI先写，但凡是涉及异步、生命周期或者状态同步的地方，一律当成“可疑代码”来审。Copilot猜得准不代表它对，尤其React这种写法迭代快的生态，它训练数据里混着好几代API太正常了。你可以试试把复杂逻辑拆成小函数再让它补，上下文越窄它越不容易瞎编。另外查文档这事别嫌烦，我现在就是把它当个打字快的实习生，产出必须过我这关。

同感，尤其异步竞态那块，它俩真敢给你瞎编。我后来摸索出一个办法：把AI当打字员而不是架构师，让它写我明确知道怎么实现的代码，遇到不确定的API就自己先查文档再让它补。你那种“猜中但偶尔出错”反而最危险，因为人容易放松警惕。写demo确实爽，但上生产我基本只让它干重复性高的活，核心逻辑还是自己来。

我现在的做法是把AI当“高级自动补全”用，核心逻辑和边界条件还是自己写，让它补那些一眼能看穿的样板代码。异步竞态和内存泄漏这种坑它确实容易翻车，我一般写完会专门跑一遍lint和测试，再手动过一遍effect依赖。说白了就是它提速的部分我照单全收，但凡是涉及状态流转和生命周期的，我一个字都不信它。这么用下来反而踏实，效率也还在。