先说结论，Trae 能用的场景比宣传的窄，但窄不等于没用，它恰好卡在我最烦的那几类活儿上，所以我还留着
真正省时间的三个场景
读陌生仓库，接手一个没写文档的老项目，以前得花半天翻目录、找入口、猜模块关系，现在直接问它「这个请求从哪进来、经过哪些层、数据最终写到哪」，它给出的链路七成是对的，我要做的是核对剩下三成
写样板代码，CRUD、表单校验、接口封装、单测骨架，这些东西写起来不难，但烦，而且要一遍遍重复同样的结构，交给它，我改改就行
写一次性的脚本，批量改文件名、清洗一份 CSV、把日志按规则切分，这种活儿以前我要么用 Python 现写，要么手动搞半天，现在描述清楚输入输出，它给的脚本大概率能直接跑
看起来很强、实际不行的场景
复杂业务逻辑改动，只要涉及「这个状态什么时候能流转」「这笔钱该记在哪个账上」，它就开始编，不是它笨，是这类知识不在代码里，在业务的约定俗成里，它拿不到
我试过让它改一段对账逻辑，它给出的实现语法全对、逻辑全错，而且错得很自信；这种错误比编译不过更危险，因为编译不过你立刻知道，逻辑错了可能上线后才发现
老系统的兼容性修改，项目里有一堆历史包袱的时候，它倾向于「按最佳实践重写」，而最佳实践往往会把老系统弄挂
需要跨文件判断的重构，改一个函数名它能搞定，改一套抽象的边界它就开始乱动了
我现在的用法
基本是「它先写，我来审」，但审的力度看场景
样板代码我扫一眼就过，涉及业务规则的，我会逐行读，而且要求它把改动理由写出来——写不出理由的地方，通常就是它瞎猜的地方
另外我给它立了几条规矩，写在项目根目录的说明文件里，不许改哪些目录、不许引入新依赖、提交前要跑什么检查；有这份东西之后，它犯的错少了一半
团队里怎么用才不翻车
我的建议很朴素，先别指望它提高产出，先指望它减少重复劳动
团队落地时最容易出问题的不是工具本身，是评审环节被省掉，有人觉得「AI 写的应该没问题」，直接合并，出事之后又怪工具，工具不背这个锅
我现在的要求是，AI 参与写的代码照样走评审，评审时额外看两件事，这段逻辑能不能一句话说清楚、边界条件有没有覆盖；如果作者自己都说不清楚，那就打回去重写
值不值得用
如果团队做的是常规业务系统，每天有大量相似的增删改查和接口对接，那它值得，省下来的时间是真的
如果团队做的是强业务耦合的核心系统，那它更适合当「读代码的助手」，而不是「写代码的助手」，位置摆对了，它很有用，摆错了，净添乱
企业内训和团队落地的内容在 rayda-tech.com，这里只记我自己用工具的感受