打开 Trae AI 写了三个月代码我最大的感受不是“生成速度真快”而是“坑真多”。周围几个朋友也在用类似的 AI 编程工具几乎都是同一个套路刚开始惊为天人觉得一天的活半小时能干完用了一周之后开始修 AI 生成的 bug越修越暴躁最后干脆退回手写。项目进度不仅没快反而慢了。我自己在某模拟项目 X 的开发中也经历了这个阶段从“让 AI 写登录模块翻车”到“用 AI 把一整套后台管理系统搭起来”中间踩过的坑基本能写一本小册子。现在沉淀下来的这 7 条经验不敢说让你彻底绕开所有问题但至少能帮你省掉一半折腾时间。如果你正在用 Trae AI或者准备用类似工具接手真实项目这文章应该是为你写的。1. 先搞清楚 Trae AI 的定位不是搜索引擎是能对话的结对工程师很多人第一次用 Trae AI 的习惯是把它当成搜索引擎用输入一句“帮我写个导出 Excel 的功能”然后等着它吐出一大段代码复制粘贴收工。这样用不是不行但它生成的代码大概率只有“能跑”的水平离“能用”还很远。关键在于你没有把它当成一个需要协作的人而是当成了一个万能答案机器。1.1 搜索引擎思维 vs 结对工程师思维搜索引擎的用法是“提问—得到答案—结束”缺点是不管上下文。如果你问“ES6 数组去重怎么写”搜出来的代码可以直接用因为这个问题本来就独立。但如果你让 AI 写“用户模块的注册接口”它就必须要知道你的项目用了什么框架、数据库字段怎么设计的、登录态怎么存的、异常怎么抛的。这些背景信息你不说模型只能靠猜猜的后果就是它自己设计了一套你认为很奇葩的方案。我吃过一次大亏。当时在项目里新增一个第三方扫码登录我直接对 Trae AI 说“帮我加一个扫码登录功能”。它很热情一口气生成了微信扫码、支付宝扫码、通用 OAuth 三个实现方案还附带了十几张表的设计。但项目只需要对接一个内部账号系统的扫码接口那些代码 90% 用不上删都删了半天。结对工程师思维是反过来的你描述清楚背景、约束、验收标准先让它给你思路再让它动手写。Trae AI 在“理解项目结构”上做得不错但前提是你得像对待刚入职的同事一样把前因后果说清楚。它会记住当前会话里的上下文所以第一次描述越完整后面的返工越少。1.2 开场白决定输出质量直接背这份模板我现在写任何任务开场白基本固定成下面这个结构宁可多花十秒钟也不让 AI 去猜项目背景这个模块属于什么系统给谁用大概什么量级技术栈约束语言、框架、UI 库、数据库、ORM版本号有坑的也要写当前文件作用让 AI 先看哪个文件这段代码加在哪个位置本次任务要做的一件事精确到函数/接口/组件级别验收标准什么样的输出算完成包括性能、异常处理、代码风格举个例子同样是“加一个导出功能”两种写法输出质量完全不一样写法一帮我写一个导出 Excel 的功能。写法二这是一个 Vue 3 Element Plus 的管理后台订单列表页在 src/views/order/index.vue现在要新增一个“导出当前筛选结果”按钮。后端接口 GET /api/orders/export 已经存在接收查询参数和分页参数返回二进制流。请在这个文件中新增导出逻辑用 Blob 方式下载文件导出期间按钮要 loading接口失败时用 ElMessage 报错并且文件名要从响应头里取。不要改动其他文件。第二种写法 AI 基本能一次给到可用的代码第一种写法它只能给你一个“通用模板”你还得自己拆、自己拼接费的时间比手写还多。这就是定位问题你把它当搜索引擎它就给你碎片你把它当结对工程师它就给你方案。2. 把需求讲清楚比会写提示词更重要任务描述模板与细化技巧提示词技巧听起来很玄但落到 AI 编程这个场景核心其实就一点把“做什么”说透把“怎么做”的约束说够。我见过有人沉迷于研究各种提示词魔法什么“请你扮演十年经验的架构师”实际效果有限。真正影响输出质量的是任务描述里的信息密度不是人设。2.1 需求描述缺三样东西AI 几乎肯定跑偏这三样是输入输出的数据格式、边界和异常场景、不允许碰的东西。拿接口开发举例我要求 AI 写一个创建订单的接口最初我写的描述是“创建订单校验库存返回订单号”。结果 AI 生成的接口里参数校验只做了非空判断库存扣减没有加乐观锁返回的订单号类型也不对前端对接的时候发现它返回了一个对象而我们约定返回字符串。后来我总结了一份接口类任务的描述检查清单每次让 AI 写接口之前先过一遍检查项说明入参协议字段名、类型、是否必填、最大长度、嵌套结构出参协议返回结构的字段名、类型、成功和失败的样子业务规则关键流程的顺序、状态流转、唯一性约束异常场景参数非法、资源不存在、重复提交、并发冲突、超时权限与边界谁能调、不能改哪些模块、不能引入哪些新依赖这五列缺一列AI 生成的代码就多一分“看起来不错但用不了”的风险。不是说它一定错而是它会在你没指定的地方自由发挥而你恰恰最不想让它发挥的地方往往是系统最脆弱的地方。2.2 小步描述优于大段描述善用多轮对话还有一种常见错误是把整个需求一股脑贴上去几千字AI 完全抓不住重点。Trae AI 是支持多轮对话的我现在的习惯是拆成三步走先讲业务背景和目标让它给一个方案方案确认后让它按方案列出改动文件清单最后才让它逐个文件动手。这个过程很像真实开发里的“先设计再编码”但因为 AI 反馈速度极快整体并不会花太多时间。多轮对话还有一个好处AI 会自动引用前面几轮的内容。比如第一轮我说“不要修改工具函数”后面几轮提需求时即使忘记重复它也大概率会遵守。这比把全部约束堆在一条消息里要可靠得多。我经常在对话中间插入一句“你刚才的方案里第 3 步有没有考虑缓存失效的问题”它会顺着前面的上下文重新检查比重新开一个对话效率高很多。3. 上下文管理别把整个项目扔给它圈定战场再开火Trae AI 这类工具普遍具备项目代码库索引能力能够跨文件理解和生成代码。但索引能力强大不等于你应该把整个项目作为上下文交给它。我实测下来的感受是上下文范围越大回答越“平均”越难聚焦到具体问题。这句话听起来反直觉但你想想如果一个人同时翻开你项目里 200 个文件来回答一个函数的问题他大概率只能给一个谁也不得罪的通用方案。3.1 明确指定文件和代码区域效果立竿见影在 Trae AI 里我几乎每条任务都会用 或手动指定文件路径告诉它“先看 src/api/order.js再看 src/views/order/list.vue其他文件不用管”。如果问题只涉及某个函数我会把函数代码直接贴进对话里再加上一句“只改这个函数不要动外部依赖关系”。这样 AI 的输出通常非常收敛改动范围完全在预期内。反之如果我不指定文件只问“订单列表接口分页有问题帮我看看”它就会去全局搜索可能搜索到三个相关接口、两个工具函数、五个页面引用。等它把所有文件都分析一遍生成的修改方案往往覆盖过多文件。有一次我遇到的问题只是时间格式化逻辑写错了它却把三个页面的时间展示都改了事后回滚花费的时间远比我自己改长。3.2 一次对话只处理一个任务跨模块先做影响面分析这是我很吃亏之后才立的规矩一次对话一个任务。AI 的上下文窗口虽然越来越大但连续聊上几十轮之后它会慢慢“忘记”最开始设下的约束尤其是当任务切换时。如果我在同一次对话里一会儿让它改订单接口一会儿让它改库存表结构一会儿又问它报表统计怎么优化后面生成的代码经常会串味——改报表的代码里莫名其妙带上订单模块的逻辑。正确做法是遇到跨模块的改动先让 AI 做一次影响面分析而不是直接改。比如我让它调整数据库表里的一个枚举字段我会问它“这个字段被哪些文件引用改动可能影响哪些接口和页面先列出清单不要动手。”等清单出来后再逐个模块单独开新对话处理。这确实多了一点沟通成本但相比“AI 一改改三处三处坏两处”的返工成本这笔买卖相当划算。4. 小步提交一次只让 AI 干一件事干完立即验证让 AI 一次性生成一个完整的模块听起来很爽但风险极高。上下文窗口有限任务越长后面的生成质量就越差而且一旦生成结果整体有误排查范围是你根本不想面对的一整片代码。我现在的节奏是把一个大功能拆成多个内聚的小任务每个任务跑通验证后再继续下一个。4.1 任务粒度怎么拆按数据流拆不按页面拆我拆任务的原则是“按数据流走”而不是“按页面走”。做一个订单管理页面我不会让 AI 一次性把列表、筛选、详情、导出全写出来而是拆成先写接口请求函数再写列表渲染再写筛选联动再写详情弹窗最后写导出。每一个小单元都是可以独立运行和验证的闭环。每个单元完成后我立即做两件事编译运行一次确认没有报错再人工看一眼关键逻辑确认它没自作聪明加东西。确认没问题后才提交一次 git并且提交信息写得清清楚楚比如“feat: 新增订单列表查询接口”。这样做最大的好处是如果后面某一步出了问题我可以精确回退到上一步而不是面对一整个失控的commit。4.2 子任务之间要传递约束别让 AI 丢失前文设计有人觉得拆任务会导致“AI 忘记了前面说好的设计”其实这个问题有解每个新任务描述里先用一两句话“同步”前情。比如前一个任务是“新增订单查询接口”后一个任务我开头会写“基于刚才已完成的 order/list.vue 中的列表数据和筛选条件现在继续做重置筛选功能”。这句话不是废话它是在帮 AI 重建语境避免它把一个新任务当成从零开始。这个思路和人类协作完全一样。你不可能让同一个同事只靠一次口头沟通就把前后两个版本的需求记得一字不差AI 也一样。我踩过的坑是上一个任务让 AI 把分页参数命名为 page 和 pageSize下一个任务只让它写“重置筛选”逻辑它擅自把分页参数改成了 current 和 limit。虽然是小问题但排查了半天才发现是命名不一致导致的请求异常。5. AI 代码也要过审三类最常踩的陷阱与自查清单很多人的误区是“AI 写的代码不用评审反正它比人细心”。实测下来完全相反AI 生成代码的平均水平确实不低但它的错误风格和人类不一样。人类容易犯的是手误AI 容易犯的是“看起来合理但底层认知错误”。所以 AI 生成的代码必须过你的眼睛而且要带着清单去过。5.1 陷阱一幻觉 API 与过度设计AI 偶尔会生成不存在的库函数、不存在的配置项、不存在的 CSS 变量。这类错误通常在运行时报错就能发现但让人难受的是那些“库函数确实存在但参数含义你根本没查过”的情况。比如它生成了一段调用某个日期库的代码参数顺序写反了语法完全合法运行也不会崩溃结果输出日期全都偏移了一天。过度设计则是更隐蔽的问题。AI 天生爱“考虑周全”你让它写一个简单的下拉选择框它会顺便给你抽象出一个通用组件基类、一个 props 校验工具、一个选项缓存机制。如果你不带约束它甚至会乖乖把这些代码全部生成出来。我现在的做法是在任务描述里明确写一句“禁止引入新的抽象层保持简单直接”可以砍掉大量多余代码。5.2 陷阱二边界条件缺失和错误延续边界条件可能是 AI 最弱的地方。它生成的循环往往不考虑空数组生成的函数往往不考虑 null 入参生成的并发代码往往不考虑竞态条件。我要求 AI 每生成一个函数都附上“你考虑到了哪些异常场景”的说明。它列得出来的我会抽查几个它列不出来的我会自己补。这个过程其实相当于一份免费的代码评审意见。另一种更难察觉的问题是错误延续。如果项目里有一段老代码写得不好AI 在修改它时大概率会“恭敬”地延续同样的坏风格而不是纠正。比如老代码里所有接口都用 any 类型AI 生成的新接口也会默认 any老代码里到处是 console.logAI 也会在新代码里顺手加一堆日志。所以我在让 AI 改代码前会专门提醒它“不要模仿旧代码的不良习惯按项目规范来”。这也是我总结出来最容易被忽略的一条。5.3 过审方法不要只看 diff让 AI 解释给你听带着清单检查代码还不够我还会做一步让 AI 解释关键段落。不是简单地问“这代码什么意思”而是问“这一段的逻辑如果在某某条件下执行会发生什么”。AI 会顺着问题重新审视代码很多时候能发现自己生成逻辑里的漏洞。这种“AI 自查 人工复核”的搭配比我一个人闷头看代码效率高很多因为 AI 找问题快而人负责判断这些问题是不是真问题。6. 用测试当验收标准让 AI 先写单测再写实现软件开发里最朴素的道理是没有测试的改动都是裸奔。在 AI 辅助开发这个场景里这道理不仅成立而且重要性翻倍因为 AI 改代码的能力远超它验证自己代码的能力。如果不靠测试兜底AI 生成代码看起来一切正常但一个小改动可能把边缘逻辑全部推翻。最让我省心的做法是先让 AI 写测试再让它写实现。6.1 先写测试等同于把需求变成可执行的描述很多开发者的习惯是让 AI 先写功能代码测不测试后面再说我现在的习惯是先让 AI 根据我描述的业务规则生成一组单测。这些单测覆盖返回值、异常分支、边界条件、关键业务规则本质上就是把需求“翻译”成语义明确的断言。测试写好后我再基于这些测试让 AI 补实现代码直到测试全部通过。这个流程至少有三个好处测试就是一份可执行的需求文档AI 拿到测试之后对“正确代码长什么样”更清楚实现代码是否有问题跑一遍就知道不用肉眼一点点检查后续再让 AI 优化或重构时测试能立刻拦住它破坏已有行为。我甚至会在 AI 生成实现之后问它一句“刚才那组测试能不能再补两个边界情况”它通常会给出很有价值的补充。6.2 当心“自适应断言”测试通过不代表代码正确不过这里有一个我必须提醒的坑AI 生成的测试可能会“自适应”。它有时候会根据代码实现反向调整断言让测试恰好通过而不是根据业务规则做独立验证。典型的例子是代码里写了if (status 1) return 成功AI 生成的测试断言也是expect(result).toBe(成功)。这种测试没有任何保护价值因为它只是复述了实现而不是验证业务规则。怎么防我给 AI 写测试的时候会刻意在描述里注明“测试断言必须基于业务需求描述生成不要参考具体实现代码”。写完测试后我还会做一次反向验证故意在实现代码里改错一个逻辑跑一下测试如果测试没挂说明它根本没测到点子上。这个动作五分钟内能完成却能省下后面无数个“相信了错误测试”的夜晚。6.3 没有测试的 AI 重构 定时炸弹我在这里把话放重一点如果你打算让 AI 重构任何一段非玩具代码但没有测试兜底我建议你直接放弃这个冲动。不是 AI 能力不行而是重构的本质是保持行为不变地调整结构验证“行为不变”的手段只有测试。没有测试AI 重构后逻辑出错的概率不会低而且错误往往藏在隐蔽的边界里。先让 AI 花半小时把测试补齐再用测试约束着重构一前一后走的弯路完全不是同一个量级。7. 克制重构冲动什么时候不该让 AI 动代码工具用了顺手之后人会产生一种膨胀感看哪段代码都不顺眼想喊 AI“帮我优化一下”。这个冲动一定要克制。AI 适合做增量和明确定义的修改但它对“历史包袱”“隐式依赖”“潜在外部调用方”完全没有概念。你让它重构一个模块它看到的只是代码而你看不到的那些线上依赖它更看不到。7.1 重构前必须回答的三个问题我给自己定的规矩是在让 AI 重构任何代码前先回答三个问题这段代码当前的测试覆盖率够不够重构的目的到底是“更优雅”还是“更正确”改动是否涉及公共接口、数据库结构、外部系统协议如果三个问题里有一个答不上来我宁可不重构或者只做最保守的改动。举一个真实的翻车案例。当时我看一个老模块的金额计算函数实现特别冗长就让 AI“提取公共逻辑简化重复代码”。它确实简化了但把函数里一个隐藏在中间步骤后的进位逻辑也“统一”掉了。单看代码新版本更漂亮一跑测试金额多了两分钱。幸好那部分代码有单测兜底否则这个问题大概率会直接漏到生产环境靠用户投诉才能发现。7.2 从“一步重构”降级为“小步重构”如果确定要重构我会请 AI 换一种执行方式每次只做一类小改动改完立刻跑测试确认再继续下一个。比如第一步只提炼魔法数字为常量第二步只抽取纯函数第三步再调整调用关系。每一步改动范围小即使出了问题也能快速定位。绝不让 AI 在一次对话里同时完成“重命名变量拆分函数抽公共类调整调用方”这种四级连跳。还有一类改动我强烈建议不要交给 AI涉及公共接口签名变更且调用方分布在多个模块甚至多个服务里的情况。AI 通常能列出所有调用方但它不知道每个调用方背后的业务约束。我让 AI 做过一次这种操作结果它把 A 模块的调用改错了方式而 A 模块的报错只有在特定权限场景下才会触发排查成本极高。从那以后公共接口的变更流程顺序变成先人工评估影响面再让 AI 列出改动点最后人工逐个确认。7.3 稳定永远优先于优雅最后说一句可能不太“极客”的结论但这是我在项目 X 里反复验证过的道理在 AI 辅助开发这个模式下代码的“可维护性”首先来自行为稳定性其次才来自结构优雅性。AI 可以帮助你把代码写得更工整但它更擅长的是把你从重复劳动里解放出来。与其频繁喊着 AI 重构老代码不如把它用在写新功能、补测试、查文档这些收益更直接的环节上。老代码能在测试保护下逐步演进就好没必要追求一次性的“完美”。用 Trae AI 开发到现在我的体会是工具本身只会越来越多、越来越强但人和工具配合的节奏才是真正决定效率的东西。这 7 条经验听起来都不复杂难的是每次开会话时都记得把约束说全每次拿到代码时都愿意花几分钟过一遍逻辑每次手痒想重构时都有勇气忍住。如果你能把这几条变成习惯AI 就不再是那个“有时靠谱有时翻车”的玩具而是一个真正能把你从无休止的重复编码里拉出来的帮手。