1. 为什么我劝你别把 Trae AI 当代码自动贩卖机刚上手 Trae AI 那阵子我跟大多数人一样觉得这玩意儿就是个你说人话、它吐代码的黑盒。结果第一个项目就翻车了——我让它帮我写一个带分页和筛选的表格组件它确实三秒钟吐出来两百行但跑起来之后筛选条件一改就报错分页器点第二页直接白屏。我盯着屏幕愣了十分钟才反应过来问题出在哪我压根没告诉它我的数据结构长什么样。这就是我想聊的第一条经验也是最重要的一条Trae AI 不是代码自动贩卖机它更像一个理解力很强但完全不了解你项目上下文的远程同事。你给它的信息越模糊它脑补出来的东西就越离谱。很多人抱怨AI 写的代码不能用其实十有八九是输入阶段就出了问题。我后来复盘了一下发现新手最容易犯的错集中在三个地方。第一是需求描述太抽象比如帮我写个登录功能它不知道你要的是 Session 还是 Token不知道你的用户表字段叫什么不知道你有没有验证码。第二是不给技术栈约束你不说清楚用的是 React 还是 Vue、是 Express 还是 Koa它默认给你生成的可能跟你的项目八竿子打不着。第三是一次性要太多恨不得一句话让它把整个后台管理系统全写完结果每个模块都是半成品。提示把 Trae AI 当成一个刚入职的实习生来对待。你会让实习生随便做个登录页吗不会。你会告诉他项目用什么框架、接口返回什么格式、设计稿长什么样。对 AI 也是同样的道理。我现在的习惯是每次开新对话之前先花两分钟写一段项目背景说明内容包括技术栈版本、目录结构约定、关键数据模型、代码风格偏好。这段说明我会存成一个模板每次新任务直接粘贴。别小看这两分钟它能让后续的返工时间减少一大半。还有一点值得说Trae AI 的上下文窗口是有限的。你聊得越久它记住的早期信息就越模糊。所以我的做法是一个功能模块聊完就开新对话把关键结论比如数据结构定义、接口约定重新贴一遍。虽然麻烦但比让它失忆之后胡写要靠谱得多。2. 提示词写得好返工少一半我的四段式描述法聊完心态问题咱们进入实操层面。我摸索出一套四段式描述法用下来效果比较稳定分享给你。2.1 第一段角色与场景锚定开头先给它一个身份和场景。比如你是一个有五年经验的前端工程师正在为一个电商后台管理系统开发商品列表页。 项目使用 React 18 TypeScript Ant Design 5状态管理用 Zustand。这段话的作用是缩小它的搜索空间。你不说它可能在 Vue 和 React 之间随机选一个你说了它就会调用对应的知识库。实测下来加了角色锚定之后代码的技术栈匹配度能从大概六成提升到九成以上。2.2 第二段数据结构与接口约定这是最容易被忽略、但最关键的一段。你得把涉及的数据长什么样告诉它。比如商品数据结构 { id: number, name: string, price: number, // 单位分 stock: number, categoryId: number, status: on_sale | off_shelf, createdAt: string // ISO 8601 格式 } 列表接口GET /api/products?page1pageSize20keywordcategoryId 返回{ list: Product[], total: number, page: number, pageSize: number }我踩过的坑就是没给这个结果它自己编了一套字段名跟我后端接口完全对不上改字段名改到怀疑人生。把数据结构写清楚等于帮它把地基打好了。2.3 第三段具体功能点拆解不要写做个商品列表要拆成条目表格展示商品列包括名称、价格分转元显示、库存、分类、状态、创建时间支持按名称关键词搜索输入框防抖 300ms支持按分类筛选分类数据从/api/categories获取分页器每页 20 条切换页码时重新请求状态列用 Tag 组件on_sale 显示绿色在售off_shelf 显示灰色下架这样它就知道边界在哪不会给你加一堆你不需要的功能也不会漏掉你要的细节。2.4 第四段约束与偏好最后补一句你的特殊要求注意所有请求用项目里封装好的 request 工具不要直接用 fetch。 价格显示保留两位小数。代码里加中文注释。这四段下来基本上一次就能生成可用的代码。我统计过用这套方法之后我平均每个功能的返工次数从三四次降到了一到两次。2.5 一个反直觉的技巧先让它提问有时候需求比较复杂我自己都没想清楚。这时候我会在描述末尾加一句在开始写代码之前如果你对需求有任何不清楚的地方先问我。这招特别好用。它经常会问出一些我忽略的点比如分页切换时是否需要保留搜索条件、删除操作是否需要二次确认。这些问题逼着我把需求想完整比它闷头写完再返工高效多了。3. 代码生成之后才是重头戏审查与调试的完整链路很多人拿到 AI 生成的代码看一眼觉得差不多直接复制粘贴就跑。这是第二个大坑。我现在的流程是生成只是开始审查和调试才是真正花时间的地方。3.1 第一遍逻辑走查别急着运行我习惯先不运行而是从头到尾读一遍代码重点看三个地方。边界条件。AI 特别喜欢写理想情况的代码。比如数组操作它经常直接list[0].name不判断list是否为空。分页计算它可能写Math.ceil(total / pageSize)但如果total是 0 呢这些地方我都会手动补上防御。异步处理。AI 生成的异步代码有时候会漏掉await或者错误处理只写个console.log。我会检查每个请求有没有try-catchloading 状态有没有正确切换请求失败时用户能不能得到反馈。状态依赖。React 里最常见的问题是useEffect依赖数组写错导致无限循环或者该更新的时候不更新。AI 生成的useEffect我基本都会重新审视一遍依赖项。3.2 第二遍小步运行逐块验证读完没问题了我不会一次性把整个功能跑起来而是分块验证。比如先只渲染表格静态数据确认列显示正常再加上搜索功能确认防抖生效最后接分页确认切换正常。这样出问题的时候我能立刻定位到是哪一块的锅。我遇到过一个典型情况AI 生成的表格组件数据渲染没问题但一搜索就报错。我分块排查后发现是搜索时它把keyword参数拼到了 URL 里但没做encodeURIComponent关键词里有特殊字符就崩了。这种问题如果一次性跑整个功能排查起来会麻烦很多。3.3 第三遍让它自己解释代码这一步很多人不知道。我会把生成的代码贴回去问它请逐行解释这段代码的逻辑特别是第 15 到 30 行。它解释的过程中我经常能发现它自己都没意识到的 bug。有一次它解释到某一行时说这里假设用户一定已登录但我这个页面其实是允许游客访问的。它自己就把问题暴露出来了。3.4 常见问题速查表我把踩过的坑整理成了一张表你可以对照着检查问题类型典型表现排查方向字段不匹配接口报 400 或数据渲染为空对照后端接口文档检查字段名空值崩溃页面白屏控制台报 undefined检查数组/对象访问前是否判空无限循环页面卡死CPU 飙升检查 useEffect 依赖数组请求重复网络面板看到同一请求发多次检查防抖/节流是否生效样式错乱布局跟设计稿对不上检查是否漏了关键 CSS 或组件属性注意AI 生成的代码里console.log和注释经常是假的——它可能注释写着处理错误但实际代码根本没处理。别信注释信代码。4. 把 Trae AI 接进真实工作流我的日常协作方式前面聊的都是单次对话的技巧但真正提升效率的是把它嵌入到你整个开发流程里。我现在的用法大概分这么几类。4.1 写新功能从骨架到填充新功能我一般分两步走。第一步让它生成骨架就是组件结构、函数签名、类型定义这些不要求具体实现。第二步再逐个函数让它填充实现。这样做的好处是骨架阶段我能快速调整整体设计不用等它把细节都写完才发现方向错了。比如做一个表单我先让它生成interface FormValues { name: string; email: string; role: string; } const handleSubmit async (values: FormValues) { // TODO: 提交逻辑 }; const validateEmail (email: string): boolean { // TODO: 校验逻辑 };确认结构没问题后再让它填handleSubmit和validateEmail。这样每一步都可控。4.2 改老代码先让它读懂再动手改别人的代码或者自己半年前写的代码最怕改出连锁反应。我的做法是先把相关代码贴给它让它先总结这段代码在干什么确认它理解对了再提修改需求。这是现有的用户权限判断逻辑请先总结它的判断流程不要改代码。 [贴代码]等它总结完我再问现在需求变了管理员和超级管理员都能删除用户但只有超级管理员能删除其他管理员。请修改上面的逻辑。这样它改出来的代码通常不会破坏原有的其他逻辑。4.3 写测试让它当假想敌写单元测试是个苦活但交给 AI 很合适。我会把函数贴给它说请为这个函数写单元测试覆盖正常情况、边界情况和异常情况。它生成的测试用例经常能覆盖到我没想到的场景。有一次它给一个日期格式化函数写了传入非法日期字符串的测试我才发现我的函数遇到这种情况会返回NaN之前一直没注意。4.4 代码审查换个视角看自己的代码写完一个模块我会把代码贴给它问请以代码审查者的角度指出这段代码可能存在的问题性能、可读性、潜在 bug、安全隐患。它提的意见不一定都对但经常能给我一些新视角。比如它提醒我某个循环里做了重复的 DOM 查询可以提到循环外面。这种优化我自己写的时候往往注意不到。4.5 学习新技术让它当陪练学新框架的时候我会让它用新框架写一个我熟悉的功能然后对比它和我熟悉的框架的写法差异。比如学 Svelte 的时候我让它写一个计数器然后问它这个功能在 React 里怎么写两者有什么区别。这种对比学习比看文档快多了。5. 那些没人告诉你、但一定会遇到的坑这部分是我踩过的血泪教训网上教程基本不会提但实际用起来一定会碰到。5.1 它会自信地胡说八道AI 最危险的地方不是它不会而是它不会的时候也装得很会。有一次我让它用一个比较新的库的 API它生成了一段看起来特别合理的代码参数名、返回值都对得上。结果我一跑那个 API 根本不存在——它是根据命名规律编出来的。所以我的原则是凡是它生成的、我不熟悉的 API一律先查官方文档确认存在再使用。尤其是版本比较新的库或者小众的库它编造的概率很高。5.2 长对话会失忆前面提过这里再强调一次。对话超过一定轮次后它对你早期说的约束会逐渐淡忘。我遇到过聊到后面它突然不用我指定的request工具了改回fetch。解决办法就是关键约束反复提或者干脆开新对话重新贴背景。5.3 它倾向于过度设计你让它写个简单函数它可能给你整出个类、几个辅助方法、一堆配置项。我一开始觉得哇好专业后来发现维护成本太高。现在我经常要补一句保持简单不要过度抽象能用三行解决就别写三十行。5.4 中文注释有时是翻译腔它生成的中文注释有时候读起来怪怪的像是英文直译过来的。比如这个函数被用于处理当用户点击按钮时。我会顺手改成正常的中文表达。虽然是小问题但代码是给人看的注释质量直接影响后续维护。5.5 别让它碰敏感逻辑涉及金额计算、权限判断、加密解密这类逻辑我只让它生成框架核心算法自己写。原因很简单这些地方出错代价太大而且 AI 生成的代码你很难一眼看出问题。比如浮点数计算金额它可能直接a * b但正确做法是先转成整数分再算。这种坑它不一定知道。6. 效率翻倍的进阶玩法几个我常用的组合技基础用法聊完了说几个进阶的能让你的效率再上一个台阶。6.1 用角色扮演做代码审查普通的帮我看看代码效果一般但如果你说你现在是一个严格的代码审查者你的任务是找出这段代码所有可能的问题不要客气越严格越好。它给出的意见会尖锐很多。我试过同一个模块用两种问法严格模式下它多找出了三个潜在问题。6.2 让它生成决策文档技术选型的时候我会让它列一个对比表我要在项目里加一个图表库候选有 ECharts、Chart.js、Recharts。 请从包体积、学习成本、定制能力、社区活跃度四个维度对比用表格呈现。它生成的对比表虽然不能全信数据可能过时但作为思考框架很有用能帮我把评估维度想全。6.3 用反向提问逼它想清楚有时候它生成的方案我觉得不对劲但说不上哪里不对。这时候我会问你这个方案有什么潜在问题在什么情况下会失效它自己就能把问题说出来。这招特别适合在方案定稿前做最后检查。6.4 把重复性工作模板化如果你发现自己反复让 AI 做类似的事比如把这段代码转成 TypeScript、给这个函数加错误处理可以把它固化成一段固定的提示词模板。我建了一个文档存了十几条常用模板用的时候直接复制省去了每次重新组织语言的时间。7. 关于AI 会不会取代程序员这件事我的真实看法聊了这么多技巧最后说点掏心窝子的。用了大半年 Trae AI我的结论是它取代不了程序员但它会取代只会写代码的程序员。什么意思就是那些工作内容纯粹是把需求翻译成代码的人确实危险了因为这件事 AI 做得又快又好。但程序员真正的价值从来不只是写代码而是理解需求、设计方案、权衡取舍、排查疑难问题——这些 AI 目前还差得远。我现在的状态是AI 帮我处理了大概六成的体力活写样板代码、补测试、查文档、做格式转换。我省下来的时间用来做那些更需要判断力的事跟产品对齐需求、设计系统架构、优化性能瓶颈、处理线上故障。这么一算我的产出反而比以前高了。但我也见过反面例子。有个朋友完全依赖 AI自己不看代码结果线上出了个 bug他排查了一整天都没找到原因因为代码他根本没读懂过。AI 生成的代码你必须有能力审查和修改否则就是在给自己埋雷。所以我的建议是把 AI 当成一个能力很强但需要监督的助手。它帮你提速但方向盘得握在你自己手里。你得知道它在干什么、为什么这么干、哪里可能出问题。这种驾驭能力才是这个时代程序员真正的核心竞争力。提示每次用 AI 生成代码后问自己一句如果这段代码出 bug我能独立排查吗如果答案是不能那就先别用去把相关知识点补上。说到底工具就是工具它放大的是你本身的能力。你基础扎实它让你如虎添翼你基础薄弱它只会让你更快地写出自己看不懂的代码。这七条经验本质上都是在帮你建立驾驭 AI的能力而不是依赖 AI的习惯。希望这些踩坑经验能帮你少走点弯路把省下来的时间用在真正重要的地方。