系列第 3 篇。上篇讲业务、版本、架构中篇讲安全与隐式耦合本篇收官附完整速查表。开场写对一次不等于一直对前两篇讲的都是“单次产出对不对”这一篇讲两个更日常的问题AI 帮你做 code review为什么同事一眼看出“这不是你写的”同一个需求AI 两次生成两种写法混用就出事场景一Review 的边界把一段业务代码丢给 Trae 做 review它返回 8 条意见其中 6 条是建议提取常量建议添加注释建议拆分函数同事一看就知道“这不是你写的意见”。更糟的是它没看出真正的坑一个在事务内发 HTTP 请求的隐患。根因Trae 给的是“通用正确”拿不到你团队的上下文——历史包袱、约定、这段代码为什么这么写。正确用法用 Trae 做“扫描器”找空指针、重复代码、命名、明显逻辑错误结论自己写只有你懂这段代码的来龙去脉review 意见带具体行号和场景别发“通用建议”一句话Trae 可以做 review 助手不能做 review 结论。场景二长期一致性同一个“分页查询”需求周一让它写给的是offset/limit周三让它写给的是游标分页两种都对但混用就是灾难——接口不统一、前端对接踩坑。根因Trae 没有项目约定的持久记忆每次只回答“这一次怎么合理”。解法把约定写进项目规则文件在项目根目录建.trae/rules或统一的 Prompt 模板# 项目编码约定 - 分页统一用游标分页cursor禁用 offset - 错误统一抛 BizException禁止裸 return - 所有 DB 操作必须在事务模板内 - 新增公共函数必须同步写单测 - 禁止在事务内发起 HTTP 请求每次生成前让它先读约定再写。重要约定定期检查是否被“新生成的代码”破坏。速查表8 类场景全景场景Trae 能做Trae 不能做你必须补的业务逻辑起草保证业务正确约束写进 Prompt 业务方确认依赖/API起草保证版本对确认版本 跑通架构提供方案替你决策多方案对比 ADR跨文件改动改可见调用识别隐式耦合全仓 grep 字符串搜索安全写功能主动防攻击固定安全追问 人工审查Review扫描问题给最终结论结论自己写文档生成骨架写“为什么/坑”补设计与踩坑一致性单次合理项目长期一致规则文件 每次加载这张表建议存成图片贴工位或发群里系列结语Trae 做不了上面这些本质是同一个原因它没有业务上下文、不为结果负责、不承担组织后果。所以正确姿势只有一句让它起草你负责判断、验证和承担。把这条线划清楚它是效率工具划不清它只是帮你更快地写出错的代码。三篇看完你手里应该有一份能直接落地的“Trae 使用边界清单”。转发给团队里刚上 AI 编程的同事能少踩不少坑。