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

我跟你情况差不多，后来干脆定了个规矩：AI只写无状态、边界清晰的纯函数，但凡涉及并发、事务或者外部依赖的模块全部自己手写。测试用例别指望它补，用quickcheck之类的属性测试反而能逼出不少边界问题。prompt的话我试过让它先列case再写码，但效果不稳定，感觉还是得靠review时重点盯异常分支。

同感，边界情况和异常路径AI是真的容易翻车，我现在基本只让它写胶水代码和单测模板，核心逻辑全手动。Prompt技巧的话，我会把需求拆成极小的步骤，每一步都明确输入输出和错误处理，比一次性给个大任务靠谱得多。另外有个笨办法，让它生成完代码后自己先跑一遍静态检查或写个最小复现脚本，能筛掉不少低级错误。像并发、状态机这类模块我绝对不碰AI，自己写反而更快。

说实话你这个阶段我太理解了，项目一到中期，AI生成代码的“幻觉”就开始集中爆发，尤其是那种跨模块的状态流转，它根本意识不到自己漏了哪个分支。我的做法是把它当成一个高级的自动补全，而不是协作者，凡是涉及锁、事务、异步回调或者数据一致性的核心逻辑，我直接手写，这部分省不了时间。至于测试，我现在反过来了，先让AI根据我描述的边界条件生成测试用例，再拿这些用例去跑它自己写的代码，反而能逼出不少问题。Prompt上有个小技巧，就是明确告诉它“不要假设任何全局状态，所有依赖必须显式传入”，并且要求它先输出一段伪代码逻辑再写实现，这样能砍掉一半低级错误。另外我坚决不碰的是支付、权限校验和任何跟外部系统对接的序列化层，这些地方出错了不是改代码的事，是背锅的事。你那个“改它代码比自己写还费时间”的体验，我现在基本是如果一次review发现三个以上逻辑漏洞，就直接整段丢掉重写，别心疼那点token。

我一般让AI写单文件工具类还行，涉及状态机和并发就直接手写了，省得给它擦屁股。

说实话我跟你感受差不多，现在基本把AI当高级补全用，核心逻辑和状态机这块都是自己手写，只让它生成胶水代码和单测模板。后来学乖了，每次生成完先逼它自己列边界条件和异常路径，再对着清单补测试，比自己盲改快不少。像并发、事务这种有隐式状态的模块我干脆不碰AI，review成本比写代码还高。

我一般让AI只写单测和工具函数，核心业务逻辑还是自己来，省得debug到怀疑人生。

把需求拆到足够细再喂给AI，复杂模块全部人肉写，反而比改它的烂代码快。

我跟你情况差不多，用AI写代码最怕的就是那种“逻辑自洽但边界全崩”的体验。后来我给自己定了条死规矩：凡是涉及状态机、并发、重试补偿这类带时序逻辑的模块，一律手写核心部分，AI只用来生成胶水代码或者样板CRUD。至于prompt技巧，我会在任务描述里强制它“先列出所有异常分支再写实现”，并且要求它给每个函数标注前置条件和副作用，这样review的时候至少有个检查清单。测试这块别省，但我发现让AI自己生成测试用例反而更高效——前提是你得在prompt里给它几个具体的边界值例子，比如“考虑list为空、元素重复、并发写同一key”这些场景，它生成的测试比直接让它“写单测”靠谱得多。另外我还有个习惯，每周抽半小时把AI最近写的代码里被我改过的地方复盘一下，总结它高频犯错的模式，下次在prompt里提前打预防针，比如“不要假设map遍历顺序稳定”这种，真的能少踩很多坑。反正现在我的态度是：AI当高级补全工具用，别当同事用，关键路径上的人工review永远不能省。

我现在的做法是让AI写单测先行，逼着它自己先跑一遍边界条件再给我代码，能过滤掉不少低级错误。但并发和状态同步这种我是真不敢放权，基本手写，AI最多帮我起个框架。prompt里加一句“考虑所有异常路径和竞态条件”确实有用，但别指望它一次到位。另外我给自己定了个规矩：凡是改了三遍还不过的模块，直接重写，不跟它死磕。

写得挺好，建议补充一些性能数据。

说实话这问题我太有同感了，上个月用类似组合重构了个调度模块，AI生成的并发控制代码看着逻辑挺顺，结果压测一上直接暴露竞态条件，排查半天才发现是它把锁的粒度搞错了。我现在基本把AI当高级补全来用，核心状态机、事务边界、幂等控制这些绝对手写，只让它处理CRUD、DTO转换、简单工具函数这类低风险片段。另外我发现给它限定“必须显式处理异常分支”加上“列出所有边界条件”这类约束词，比笼统说“写好点”管用得多，但前提是你自己得先想清楚边界在哪，否则它只会一本正经地编造。还有个小技巧是让它先写测试用例再写实现，这样至少能逼它把异常场景过一遍，不过涉及资金、权限、分布式一致性的模块，我劝你还是彻底别碰AI，省下的时间不够填坑的。

说真的，我最近也踩了不少这种坑。后来定了个规矩，凡是涉及状态机或者资金相关的逻辑，AI只负责写单测和注释，主逻辑必须自己手写。Prompt里加一句“请先列出所有异常分支和边界条件再写代码”会稍微好点，但别指望它一次到位。现在我的流程是让AI出第一版，然后拿它的代码当code review的靶子，反而比自己从零写更能逼着去思考边界。

说实话我也有同感，AI写业务逻辑还行，一到并发和异常处理就原形毕露。我的做法是让它只产出单测覆盖不到的骨架代码，状态机和事务边界必须自己手写。另外尽量把需求拆得足够细，每次只让它改一个函数，别让它一口气生成整个模块，错误率会低很多。

我一般只让AI写纯函数和样板代码，涉及状态流转的模块还是自己写靠谱。

边界条件你得在prompt里直接列给它，不然它真就给你写个理想态。

同感，越到后期AI写的代码越像“语法正确但逻辑脆弱”的纸老虎。我的做法是给Cursor限定严格约束，比如在prompt里写明“必须处理所有异常分支”和“禁止使用全局可变状态”，能少踩一半坑。另外并发和事务相关的代码我基本不碰AI，这块它犯错的成本太高，自己写反而更快。测试的话，我现在让它先补边界case的测试，再让它写实现，顺序反过来正确率会高不少。