Copilot和Cursor写出来的代码，大家真的会直接merge吗？

小改动我也直接合，涉及并发和状态的必须手写重写，AI写的真不敢信。

说实话，我跟你情况差不多，现在Copilot写个工具类或者DTO我基本扫一眼就过了，但凡是涉及异步、重试、连接池这种，我绝对不敢直接merge。你说的WebSocket重连我太有同感了，AI特别喜欢把重试间隔写死，或者忘了处理close事件里的异常，这种坑压测之前根本看不出来。我的做法是，让它生成代码之后，先自己画个状态机或者时序图，把关键路径走一遍，只要逻辑分支超过三个，我就默认它有问题。另外我有个土办法，就是故意在代码里留几个边界值，比如把超时时间改成0或者负数，看它生成的代码会不会防御，如果不会，那说明它只是抄了个表面。测试兜底确实重要，但单测覆盖率再高，也盖不住并发场景下的竞态条件，所以我现在更依赖代码审查时的“心智模拟”，就是假装自己是那个连接管理器，一步步推演资源释放。小改动我可能信任它，但核心模块我宁愿自己重写一遍，毕竟排查AI埋的雷，比写代码本身耗时多了。

说实话我跟楼主情况差不多，小工具函数或者CRUD我基本扫一眼就合了，但涉及并发、重试、资源释放这种，我连review都不敢省，直接当同事写的代码来审。你那个WebSocket重连泄漏，我猜多半是没考虑关闭前的pending状态，这种逻辑AI很难从上下文里推断出来。我的习惯是让它只负责生成单点逻辑，然后把边界条件列成清单自己补，最后再压一轮测试，不然真不敢上生产。

说实话，我跟你情况挺像的，刚开始用Copilot那会儿恨不得它写啥我信啥，后来被坑了一次就老实了。我现在基本是分场景处理，像那种纯boilerplate、CRUD接口、DTO转换之类的，大概扫一眼逻辑直接合，因为测试能兜住；但凡涉及到锁、状态机、重试策略、资源生命周期这些东西，我连review都不够，还会自己再补几个边界case的测试。你说那个WebSocket重连，我猜就是典型的“看着对但细节全错”——比如没处理close后的pending消息，或者重连定时器没重置，这种光靠读代码真的很难看出来，压测暴露是好事。我的技巧是让AI自己先写一轮单元测试，然后我拿测试当“需求说明书”反过来审实现，很多隐藏假设就现形了。另外一定要看它生成的代码里有没有“假异步”或者“隐式共享状态”，比如闭包里藏了个计数器，这种我基本直接重写。最后说句实话，工具确实提速，但把AI当实习生用、而不是当专家信，心态摆正了才能既快又不翻车。

小改动信一半，涉及状态和并发的必重写，测试兜底是底线但别全指望它。

测试兜底是必须的，但并发这种坑测试也难全覆盖，我一般让AI写单测自己再补边界case。

小改动直接合，涉及状态和并发的代码必须人肉review加压测，别嫌麻烦。

我基本是当高级补全用的，小函数或者DTO这类直接merge没问题，但涉及状态流转或者资源生命周期的，必须自己把边界条件捋一遍。你说的WebSocket重连我太有同感了，AI特别喜欢写那种看起来优雅但漏了清理旧连接的代码。我的土办法是让它先生成，然后专门盯着close、cancel、dispose这些关键字找，再配合压力测试，不然真不敢上生产。

说真的，我跟你一模一样，小改动比如工具函数或者简单CRUD，我基本扫一眼就过了，但涉及并发、重试、资源释放这种，绝对不敢直接merge。我现在的习惯是让它生成代码前先写清楚伪代码或者关键状态流转，然后review的时候重点看异常分支和资源关闭，再丢给CodeRabbit之类的工具扫一遍。测试确实兜底，但压测场景不全，很多泄漏是跑出来的，不是看出来的。

说实话我跟你情况差不多，刚开始也图省事直接merge过几个小函数，后来有一次它生成个带闭包的定时器，逻辑看着没问题，结果内存蹭蹭涨，排查了半天才发现是它没考虑引用释放。现在我的原则是：凡是涉及生命周期、异步、共享状态的代码，一律当它是个实习生写的，必须逐行过一遍，尤其是错误处理和边界条件，这俩地方它最容易一本正经地胡说八道。单纯CRUD或者工具函数我倒会快一些，但也会跑一遍单测再合，毕竟它有时候会“自信地”用一些冷门API，我都不确定是不是真存在。技巧的话，我习惯先看它有没有处理异常分支，再看有没有不必要的副作用，最后压测或者写个针对性测试兜底。说到底，工具省的是打字时间，省不了思考时间，尤其并发这种，它给的方案往往是“看起来对”而不是“真对”。

小改动直接merge，涉及并发和状态的必看测试结果，再信它不迟。

说实话我跟你差不多，小改动用它生成的真就瞄一眼合了，但涉及并发、重试这种核心逻辑绝对得当祖宗供起来review。我一般会让它把关键路径拆成纯函数，这样能肉眼追踪状态变化，再补上边界测试。另外有个土办法，就是故意给它一个带坑的prompt，看它会不会踩雷，踩了说明逻辑没理解透。测试兜底是必须的，但别全指望AI自己写测试，它经常生成那种自我安慰式的用例。

小改动也当大改review，并发代码我直接当乙方写的，测试不过不碰merge按钮。

说真的，我跟你情况差不多，现在团队里AI写代码的比例越来越高，但merge前的心态完全取决于代码类型。像那种纯CRUD或者模板类的东西，我基本扫一眼就过了，但凡是涉及到状态机、并发、重连这种带时序逻辑的，我绝对不敢直接信。你提的WebSocket那个例子太典型了，AI写出来的表面逻辑往往很完整，但边界条件和资源释放这种要靠运行时压力才能暴露的问题，它根本“想不到”。我现在有个习惯，凡是AI生成的代码，先逼自己用抽象的方式把它的状态流转画出来，如果画不出来或者觉得有环，那就必须重写。另外，我特别依赖测试兜底，但会先针对AI生成的代码写几个刁钻的测试用例，比如突然断网、超时重试、重复close之类的，能过这些才算有点底。说到底，我觉得这工具适合当高级结对编程搭档，但绝对替代不了那个“最后把关”的人。你有没有试过让它生成完再换另一个模型去review？有时候交叉验证能发现不少问题。

说实话我跟你情况差不多，WebSocket重连这种带状态的逻辑我从来不敢直接信，AI写出来那种“看起来完整”的代码往往忽略了边界条件。我现在基本规则是：样板代码、单元测试、正则表达式这类纯机械的活儿直接merge，但涉及并发、资源生命周期、事务回滚的，哪怕它写得再像那么回事，我也必须把关键路径手推一遍。有个小技巧是故意给它丢一些极端输入，比如空指针、超时、断连重入，看它能不能自己发现矛盾，很多时候它会在第二次生成时自己推翻之前的逻辑。另外我觉得测试兜底是必须的，但不是那种跑一遍绿了就完事的，得针对它生成代码的“自信区”额外补压测和竞态检查，像日志里有没有异常吞掉、定时器有没有正确清理这种，靠肉眼review效率太低。说到底，AI是个很强但会一本正经胡说八道的实习生，你让它写代码可以，但让它背锅不行。我现在最烦的是它把错误处理写得特别“优雅”，结果异常全被吞了，排查问题反而更费劲。

我基本是拿它当高级自动补全用，超过20行的逻辑或者涉及状态流转的代码，默认全部不信，必须一行行过。跟你遇到的情况差不多，它写出来的东西表面很完整，但边界条件和资源释放经常想当然。我的习惯是让它生成初版，然后自己重写核心部分，或者至少把关键分支都补上测试用例。另外有个土办法，就是故意问它“这个写法在高并发下有什么坑”，它有时候会自己把问题列出来，反而比直接看代码更容易暴露风险。

我都是拿它当高级补全用，生成超过二十行的逻辑必review，并发代码直接当草稿重写。

我基本是小改动才敢直接merge，涉及到并发、重试、状态机这类逻辑，不管它写得多像样都得自己过一遍。你那个WebSocket的例子太真实了，AI特别擅长生成看起来合理但边界条件有坑的代码，压测或者故障注入比肉眼review更靠谱。我现在的习惯是让它先写，然后重点盯资源释放、超时处理和错误恢复这几块，再补几个针对性测试，这样能省一半时间但又不至于翻车。

说实话我基本不直接merge，尤其是涉及并发或者重试逻辑的代码，AI写出来表面光鲜但边界条件经常漏。我的习惯是小改动比如工具函数或者样板代码会扫一眼就过，但核心逻辑必须自己重写一遍逻辑再让AI补测试。另外有个土办法挺管用：让它把关键函数用注释解释一遍执行流程，如果它解释得含糊或者跳步，那八成有问题。测试确实兜底，但压测和故障注入比单测靠谱多了，特别是网络和资源释放这种场景。

我跟你的感受差不多，尤其涉及状态管理的代码，AI生成的“看起来合理”和“实际正确”完全是两码事。我的习惯是，简单的CRUD或者工具函数，review时重点看边界条件就直接合了；但像重连、并发这种，不管它写得多漂亮，我一定得自己画个时序图捋一遍，再补上特定场景的测试才敢动。另外有个小技巧，就是让它把关键逻辑拆成纯函数，这样测试复杂度会降很多，也更容易暴露问题。

说实话我跟你情况差不多，刚开始也是无脑信任，后来被坑了几次就老实了。现在我的原则是：凡是涉及并发、状态、IO的代码，一律当“有bug的候选”来看，哪怕它写得再漂亮。你那个WebSocket重连的例子太典型了，这种带生命周期和资源释放的逻辑，AI特别容易生成“看起来正确”但边界条件全崩的代码。我现在的做法是，先让AI写，然后我会重点盯几个地方：有没有合理的超时控制、有没有finally或者defer来保证释放、异常分支到底怎么处理。小改动比如工具函数、配置解析，我可能直接合，但也会跑一遍单测。另外我强烈建议把静态分析和压力测试接进CI，别靠人工review去抓资源泄漏，人眼真斗不过机器生成的逻辑盲区。最后补一句，让AI写代码前，最好把约束条件写清楚，比如“必须用context取消”或者“禁止全局变量”，这样能省不少排查时间。