求教：AI编程工具写出的代码，大家真的敢直接上生产吗？

这感受太真实了，我拿Copilot搞过一阵子内部工具，跟你一模一样，跑通没问题，但一看事务边界和异常处理就想骂人。后来我学乖了，AI生成的代码就当个初稿，重点逻辑和边界条件全自己重写一遍，反而比纯手写还费劲。不过话说回来，效率提升是真的明显，尤其是写那种CRUD样板代码，省下来的时间刚好用来补它埋的坑。

我现在的习惯是让它写骨架和工具函数，核心业务逻辑自己来。像事务和异常这块，我一般会明确在prompt里要求它按项目规范来，或者干脆生成完自己过一遍。空catch这种确实是重灾区，我后来直接在rules里写死禁止吞异常，效果好了不少。效率提升是真的，但完全放手还是不太敢，尤其涉及钱和数据的接口。

我一般只让它写脚手架和单测，核心逻辑还是自己来，不然review比写还累。

跑通和能上线是两码事，AI写的代码我基本都当草稿用，核心逻辑还得自己盯。

空catch和事务边界随意这两点太真实了，我前两天也踩过，线上直接丢了个异常排查了半天。我的做法是让它生成完再单独跑一遍review prompt，专门盯错误处理和事务这块，基本能兜住。风格问题其实还好，加个项目级的rules或者示例代码喂给它，多轮下来会越来越像人写的。但核心业务逻辑我目前还是自己手写，AI负责CRUD和胶水代码，分工明确省心不少。

我现在的做法是把它当“高级代码补全”用，不让它直接产出完整逻辑。核心部分自己写，重复的CRUD或者工具函数交给它，这样效率和质量能平衡。空catch确实很坑，我一般会加个lint规则强制报错。你们团队有没有统一的prompt规范？感觉这个挺关键的。

这玩意儿写业务逻辑确实快，但生产环境我是不敢直接用的。我现在都是让它先出个初稿，然后自己把异常处理和事务那块全过一遍，空catch这种坑太常见了。不过说真的，用它来写单元测试和工具类代码倒是挺省心的，那部分我基本不怎么改就直接用了。

我现在的用法是让它先写，但心里默认这就是个草稿。空catch和事务乱放确实很常见，所以我一般会在prompt里直接要求它按项目规范来，比如异常必须打日志、事务写在service层。不过就算这样，review还是省不了，尤其是涉及并发和边界条件的地方，基本得自己重捋一遍。感觉目前最靠谱的姿势是把它当打字快的实习生，而不是能直接甩锅的同事。

敢用但不敢全信，我现在就当它是个手速飞快的实习生，产出必须过一遍我的code review才行。

说实话这问题我也纠结过一阵子，现在算是想明白了点。AI生成的代码当草稿用是真香，但直接扔生产环境我是不敢的，尤其涉及钱和用户数据那块。你提到的空catch和事务边界还算好抓的，我更怕的是它有时候会悄悄改掉一些边界条件，比如分页查询少个排序、并发场景下锁的粒度不对，这种跑起来不报错但埋雷最要命。我的做法是把它当个手速超快的初级开发，产出必须过我的review清单，重点盯异常处理、事务、幂等和日志这几块。另外单元测试我也会让它自己写，但测试用例我得先定好，不然它经常写出“验证自己实现”的假测试。效率提升是真的，但省下来的时间基本都花在review和补测试上了，总体还是赚的，就是别指望它替你把关。

同感，我现在基本把AI当“高级自动补全”用，不是当“外包”用。它写业务逻辑和样板代码确实快，但事务、异常、边界条件这些地方经常糊弄，空catch我也见过好几次，直接上生产肯定不敢。我的做法是让它先出草稿，然后自己重点盯并发、事务和错误处理这几块，其他细节可以放一放。说白了省的是打字时间，不是省脑子，review这关还是得自己扛。

当草稿用挺香的，但直接上生产真不敢，空catch和事务边界这种坑不炸则已，一炸就是线上事故。

空catch和事务边界确实是重灾区，我一般只让它写纯逻辑，涉及DB和并发的地方手动来。