AI编程助手写的代码越来越不敢信了，大家怎么把控质量？

说实话我最近也踩了差不多的坑，尤其是并发和异常处理这块，AI写出来的东西表面逻辑通顺，但一压测就现原形。我现在把AI当高级补全工具用，而不是当协作者，核心业务逻辑、状态机、支付这类涉及钱的模块坚决手写，只让它写CRUD、DTO转换、模板代码这些“体力活”。Prompt方面有个小技巧，我会在需求里明确写“请考虑所有可能的失败路径和边界条件”，然后让它先列出测试用例再写实现，这样它至少会自己吓唬自己一下。但真正管用的还是靠review，我养成了习惯，每次让它改代码后，先不看diff，自己把旧逻辑在脑子里过一遍，再对照它的改动，很多隐蔽问题就是这么揪出来的。另外我会故意给它一些带坑的需求，比如“用户点击两次提交按钮”，看它会不会处理幂等，不处理的直接打回重写，多来几次它在这个项目里的表现会好不少。测试用例还是得自己补，但可以反过来让AI生成测试数据，这个它做得挺快，省下来的时间刚好拿来多读两遍关键代码。

我跟你遇到一模一样的问题，尤其是并发和异常处理那块，AI写出来的代码看着逻辑完整，但边界条件全靠猜。我现在基本把prompt当需求文档写，明确要求它列出所有可能的状态流转和失败场景，再让它自己补上对应的防御逻辑，出错率确实降了一些。但像涉及资金、权限这种核心模块，我干脆直接手写，AI只用来参考算法思路或者生成测试数据，不敢让它碰最终实现。

我一般让AI写单测和DTO，核心并发逻辑全手写，prompt越具体反而越容易翻车。

AI写的代码就当高级补全，review重点盯状态机和异常分支，别指望它能独立扛复杂度。

我一般只让AI写胶水代码和单测，核心逻辑还是自己来，边跑边改真不如手写快。

我最近也踩了类似的坑，尤其是并发和异常处理，AI写出来总感觉逻辑闭环但实际跑起来就漏。后来我干脆把这种核心模块拆碎成小函数，让AI一次只生成一个纯函数，配合强类型接口，review成本反而低很多。至于prompt，我会明确告诉它“考虑所有边界条件并写出对应测试”，能逼它多生成几轮校验逻辑，虽然还是得人工兜底。现在像状态机、事务这类东西我基本不碰AI，太吃上下文了。

我一般让AI写单测覆盖边界，跑不过就扔回给它修，比自己补省心点。

并发和支付相关的逻辑我全手写，AI只用来搭骨架和写胶水代码。

说到这个我太有同感了，之前让AI写个状态机，逻辑看着挺完整，结果并发一上来直接乱套。后来我学乖了，凡是涉及锁、事务、异步回调这类代码，全部自己手写，AI只用来生成DTO和模板代码。Prompt里加一句“考虑所有异常路径”确实有点用，但它该漏还是漏，别指望太多。

我觉得关键是给AI立“人设”，比如让它扮演一个习惯写防御性编程的资深工程师，输出里强制要求带边界条件注释。另外，我现在会让它先写测试用例再写实现，这样至少能逼着它把逻辑捋清楚，虽然仍得自己审，但比裸写强多了。

我跟你情况差不多，后来干脆给AI定了规矩：只让它写无状态的工具函数和CRUD，涉及并发、事务、权限这些直接人工写，review成本反而低很多。还有个土办法，让它输出前先列一遍边界条件和异常分支，至少能少一半“看起来对”的坑。测试用例别省，但可以拿AI生成的代码当测试素材，专门补它漏掉的那几条路径，效率反而上来了。

这问题太真实了，我最近也有同感。Cursor写那种CRUD页面确实快，但一到状态机、重试逻辑或者异步回调，它就开始给你整活，表面逻辑通顺，实际跑起来就是各种竞态和漏catch。我现在基本把AI当高级结对程序员，让它出初版没问题，但涉及并发、事务、权限校验这种核心路径，我干脆直接关掉补全自己写，省得review时还得猜它当时怎么想的。

关于prompt，我觉得最有用的一招是强制它“先列边界条件和异常场景，再写实现”，效果比直接说“写个函数”好很多。另外我习惯让它给代码加“防御性断言”，比如入口处校验参数、出口处检查不变量，这样哪怕它逻辑有疏漏，跑测试时也能更快暴露问题。不过说实话，质量把控最终还是得靠测试用例，我现在会专门拿它生成的代码去喂property-based testing，随机输入一砸，那些隐藏bug基本就现形了。

还有个感受是，让AI写测试比写实现靠谱，你让它根据需求生成测试用例，它反而没那么容易自欺欺人。至于坚决不交的模块，我这边是任何涉及分布式锁、消息队列顺序保证、还有金融计算的地方，全人工手写，这玩意儿出一次错成本太高，实在不敢赌。

确实，AI写代码最大的问题就是“表面光鲜”，边界条件和异常路径全靠猜，尤其并发场景简直是重灾区。我现在基本把AI当高级补全工具用，核心逻辑和状态流转必须自己手写，只让它生成胶水代码和测试用例。Prompt方面可以试试在开头强制要求“先列出所有边界条件和失败场景再写实现”，能稍微减少点低级错误，但别指望根治。最靠谱的办法还是让AI给每个函数写契约注释，然后你拿这个当checklist去review，比裸看代码快多了。

我直接把并发和状态管理相关的代码全部手写了，AI只用来生成业务胶水代码，这样测起来省心多了。

我都是让AI写单测和类型定义，业务逻辑自己手写，边界case靠review真兜不住。

复杂度上来后AI只配当高级补全工具，核心并发逻辑还是人肉写靠谱。

我跟你感觉差不多，现在AI写代码最大的坑就是“看着合理但经不起推敲”，尤其是并发和异常处理，它压根不会主动去想那些边界。我的做法是让它只写业务主流程，状态同步和错误恢复这种核心逻辑全自己来，测试用例也只补关键路径的。另外我会在prompt里明确要求它列出所有可能的失败场景，再逼它给出对应处理，能少踩不少坑。

其实最有效的还是把大任务拆小，每次只让它改一个函数，别给太多上下文，反而容易出错。现在像数据库事务、支付回调这种涉及钱和一致性的模块，我绝对不碰AI，太吓人了。

我跟你感觉差不多，中期以后AI写的代码就跟开盲盒似的，表面光鲜，一压并发就原形毕露。我现在基本把它当高级补全工具用，核心状态机和异常流绝不让它碰，只让它写胶水代码和DTO。Prompt的话，我会强制它先列边界case再写实现，有时候让它“想想哪里会炸”比直接写代码效果还好。

我跟你感觉差不多，Cursor写的代码确实有那种“表面光鲜”的问题，尤其是并发和异常处理，它经常默认所有调用都成功。我现在就是把AI当高级补全工具用，让它写单线程的纯函数或者样板代码，凡是涉及状态流转或者外部依赖的模块都自己手写，反而快很多。另外有个小技巧，prompt里明确让它列出所有可能的失败场景并写出对应处理，能稍微减少点漏网之鱼，但还是得靠测试兜底。你们有没有试过让它先写测试再写实现？我试了几次，感觉质量会稳一点。

我都是让AI先写，然后专门盯着边界条件和异常路径review，并发这块基本自己手写，不敢全交给它。

我自己的做法是让AI先出整体框架和happy path，边界条件、异常恢复这些必须自己动手写，尤其是并发相关代码基本不碰AI生成的。另外prompt里明确要求它列出所有可能的失败场景并给出对应处理，能减少一部分低级遗漏，但最终review还是得靠人肉debug。

其实最耗时间的不是补测试，而是给AI解释它自己写的逻辑哪里有问题，有时候干脆推倒重来还快一点。现在只敢把CRUD和工具类脚本交给AI，核心业务逻辑和状态机这块绝对不碰。

我最近也踩了不少类似的坑，后来干脆把并发和事务相关的代码全手动写了，只让AI负责纯CRUD和工具函数，review压力瞬间小一半。另外发现让它先写测试用例再写实现，比直接生成代码靠谱得多，相当于逼它把边界条件想清楚。但说实话，异常处理这种“隐藏路径”它还是很难做好，我基本默认生成后要补至少三分之一的错误分支。

说真的，我跟你感受一模一样。Cursor+Claude写CRUD和工具类脚本还行，一到并发、事务、异常补偿这种隐含状态机的地方，它经常给你生成“逻辑上正确但时序上脆弱”的代码，那种边界条件不是靠补几个测试用例就能兜住的。我现在有个很笨但有效的办法：凡是涉及共享可变状态、分布式锁、或者外部系统交互（比如消息队列、支付回调）的模块，直接手写，最多让它帮我补单元测试的骨架。至于prompt技巧，我试过在系统提示里加“请先列出所有可能的失败场景，再写实现”，效果有一点，但别指望它真能穷举，它还是更擅长顺着你给的上下文“自圆其说”。另外我会让它强制输出函数级别的precondition和postcondition注释，这样至少review的时候我能快速发现它没考虑到的边界。最后说个心态问题——别把AI当结对程序员，就当它是高级自动补全，质量责任全在自己身上，这样反而没那么焦虑了。

说实话我跟你情况差不多，用了一阵子AI编程助手，最大的感受是“能跑”和“正确”之间差了十万八千里。我现在的办法是把AI当高级自动补全用，核心逻辑、状态机、并发控制这些绝对自己写，只让它负责样板代码、DTO、简单CRUD这类低风险部分，这样review压力小很多。Prompt方面我的经验是别让它“写一个函数”，而是给它明确输入输出、边界条件、甚至直接贴一段错误日志让它修，比笼统描述效果好得多。还有个小技巧，让它先写测试用例再写实现，或者至少让它自己生成测试，虽然case不全，但能逼它考虑一些极端情况。至于哪些模块坚决不碰，我的底线是任何涉及钱、权限、数据一致性校验的代码，绝对手写，而且必须配集成测试，这玩意儿AI搞砸一次可能比你自己写慢十倍。另外我发现让AI解释它每步思路比直接要代码有用，有时候它自己说着说着就发现逻辑漏洞了。反正现在我对AI产出默认“有罪推定”，不跑通完整测试流绝不合并，宁可慢点也不想半夜被线上告警叫醒。