后端用 AI 的真实边界：能交给它什么，不能

后端用 AI 最大的风险不是它写得差，而是它写得很像对的——逻辑通顺、能编译、测试也过，但漏掉了并发、事务或者幂等。这类 bug 上线后才炸。

可以放手的（低风险高频）

这些任务规则明确、影响局部，交给它几乎不需要返工：

• DTO / VO / 实体类转换、参数校验注解。
• 单元测试与边界用例（给它方法签名和业务规则即可）。
• 简单 CRUD 接口的骨架与文档注释。
• 日志、异常包装、工具方法这类样板代码。
• SQL 的格式化、索引建议（结论要自己核）。

必须人审的（中风险）

它能写，但你要逐行看，因为错在细节：

• 涉及金额计算的逻辑——四舍五入、精度、货币单位，它经常用错。
• 事务边界与传播行为，多数据源场景尤其容易出问题。
• 并发相关：锁粒度、幂等设计、重复提交。
• 缓存与失效策略，它倾向于给一个「看起来合理」的过期时间。

绝对不能交给它的

不是它写不出来，是出错的代价不可接受：

• 权限与鉴权逻辑——漏一个分支就是越权漏洞。
• 密钥、证书、加密实现——它可能生成不安全的默认实现。
• 数据迁移脚本——跑错一次可能无法回滚。
• 线上配置变更、生产环境操作。

一个降低风险的习惯

让它写完先「自我审查」一遍：要求它列出这段代码在并发、异常、超时、重复调用四种情况下分别会怎样。

这个动作能逼出它自己漏掉的场景，比你事后逐行读代码更快发现问题。