第一次用 Trae 做 AI 开发是在一个周末。当时我想做一个内部用的团队日志小工具把需求仔仔细细打进了对话框心想 AI 写代码不就是把话说清楚吗。结果一个下午过去项目倒是跑起来了登录逻辑却乱成一团数据库表里还多了三个我根本不认识的多余字段。后来我连续实测了一个多月翻了不少车才慢慢摸出一些门道最终把最容易踩的坑总结成了 7 条经验。我不敢说这些经验能让你直接变成高手但照着做少踩一半的坑是绰绰有余的。这篇内容适合正在用 Trae或者正准备让 AI 编程工具帮你做全栈小项目、写脚本、搭原型的人也特别适合被AI 生成的代码看着能用、改起来要命折磨过的朋友。先说明一个前提下面所有经验不是书上抄来的理论都是来自实际项目反复摔打之后的操作心得有几条甚至和大家的直觉相反。1. 用 Trae 的第一周我踩过的三个隐形坑1.1 Trae 做对了什么AI 原生 IDE 到底强在哪先客观地说Trae 确实改变了我写代码的节奏。它不是传统编辑器那种装个插件、旁边挂一个聊天窗口的用法而是把 AI 直接融进项目上下文里。它能读当前文件、能看整个仓库的文件结构、能拿到终端输出还能一次改多个文件。你选中一段代码它可以直接解释、重构、修 bug你把一张报错截图丢给它它也能看懂。用在搭原型、写胶水脚本、做内部小工具这些场景这种工作流是真的快。我以前写一个内部小工具从建项目到能跑怎么也得一晚上。现在用 Trae基本一顿饭的功夫就能出一个可用的版本。这也是我后来愿意花时间去研究它坑在哪里的原因——收益太明显了值得把工具用透。1.2 为什么一句话生成项目会翻车翻车场景我在开头已经说了一半。其实根本原因非常简单AI 写代码和人一样需要上下文。你说帮我做一个团队日志小工具它怎么知道你要不要登录要不要权限分级要不要多人协作要不要数据导出它不知道于是就会启动平均值模式把所有能想到的功能都猜出来放进去。每个字段它猜一点每个页面它猜一点最后出来的就是一坨你用不上、删起来又牵连甚广的代码。更麻烦的是它猜错的时候不会告诉你。比如它默认所有用户都是管理员、默认金额不涉及精度、默认没有并发写入。这些默认值被埋进代码之后问题要到很后面才会爆出来等爆出来的时候你又很难把线索追溯到源头。1.3 认知调整把 Trae 当结对程序员而不是自动代笔所以我在第一周结束的时候得到一个最重要的认知调整预期。用 Trae 的正确心态不是我出需求、它出代码而是我当负责人、它当执行者。它像一个精力旺盛但缺少全局判断的新人你给明确的任务它能执行得很热闹你完全放开它能在一小时里把代码写到让你看不懂。这听起来像是废话可到了实操里很多人还是忍不住把 AI 当成许愿池。接下来这 7 条经验本质上都在回答同一个问题怎么让这个执行力很强的人在正确的地方以正确的方式干活。2. 经验一、二选对模式拆对任务2.1 经验一Builder 模式和 Dialog 模式别用反了Trae 里有两个最容易混淆的入口Builder构建模式和 Dialog对话模式。Builder 适合从零搭建项目骨架你把需求说清楚它直接生成一个可运行的结构Dialog 适合对已有代码做局部修改。这两个模式的差异直接决定你用 Trae 是顺滑还是卡壳。这两种模式我见过太多人用反了。有人在 Builder 里反复纠缠加个字段去掉按钮换配色这就好比让一个擅长盖整栋楼的包工头去拧螺丝效率低不说还特别容易把别处弄坏。反过来也有人往 Dialog 里丢一句重构整个项目一次指令下去改了四十多个文件改完项目跑都跑不起来。拿我自己反复迭代的一个模拟项目X内部库存管理小工具举例我的标准流程是先开 Builder用一段话描述核心需求生成一个最小可用的库存管理页面包含商品列表、入库、出库三个核心功能先不做权限和报表。Builder 生成完骨架我立刻切到 Dialog。之后所有迭代都在 Dialog 中进行比如给入库表单增加备注字段出库流程增加确认二次弹窗。只有遇到特别大的结构调整时才重新开 Builder或者新建一个对话从头梳理。场景推荐模式理由从零生成项目骨架Builder一次性生成目录、依赖、基础代码效率最高修改单个函数/样式/文案Dialog改动面积小AI 容易保持克制整体重构、调整架构单独新对话避免旧上下文干扰也方便回滚多轮需求讨论Dialog边聊边改但注意及时收敛经验核心一句话Builder 只用来盖楼Dialog 只用来装修。别混着用你会在这一条上省下非常多的时间。2.2 经验二一个指令只做一件事拆任务是核心能力AI 编程工具最大的瓶颈很多时候不是模型本身而是指令太贪心。一句话塞三个需求把登录功能完善一下、样式调好看点、顺便把最近的 bug 修了这种话说给同事听同事都会皱眉AI 也一样。它的典型表现是挑其中最容易做的一部分先完成另外两个要么忘记要么做一半最后你根本不知道它到底做了哪些、没做哪些。我的做法是把每次任务拆成最小可验收单元并且尽量带上验收标准。所谓最小可验收单元就是这句话发出去它能独立完成、你也能独立验证结果的一个小任务。举个例子反例优化一下用户管理模块。正例在用户管理页新增一个禁用用户按钮点击后调用 PUT /users/{id}/disable 接口成功后刷新列表。只改 user-admin.js 这一个文件。你可能会觉得这样太碎、太啰嗦。但实测下来这恰恰是最省时间的做法因为 AI 的出错率和指令复杂度不是线性关系是指数关系。10 个小任务每个花 2 分钟一共 20 分钟就能全部搞定1 个复杂度拉满的任务可能折腾一两个小时还出不来正确结果。怎么算都划算。拆任务时我还用一条标准自检如果这个指令你自己动手可以在 10 分钟内完成那它就是一个合适大小的任务如果超过 10 分钟就接着拆。在 AI IDE 里任务粒度直接决定生成质量——这句话值得写在屏幕贴纸上。3. 经验三、四提示词的本质是控制 AI 的动作幅度3.1 经验三要修改而不是重写AI 生成代码有个天然倾向整文件重写。原因不难理解模型更擅长输出一个完整答案你让它改某个函数它也很可能把整个文件重新输出一遍。文件只有 50 行还好到了 500 行问题就出来了。重写过程中它可能顺手优化了其他函数、改了缩进风格甚至因为上下文过长丢掉部分老代码。你明明只让它动一行最后 diff 里却躺着二十处变化每一处你都得人肉确认一遍。我后来在指令里会明确加一句最小改动原则并且针对长文件专用一套措辞只修改 saveUser 函数内部逻辑其他函数保持原样不要调整 import 和格式。请先列出修改涉及的文件和行号我确认后再改。如果工具支持内联编辑优先用内联而不是整段重新生成。还有一个压箱底的小技巧如果 AI 实在无法避免整段输出我会让它先给改动清单我再决定要不要接受。这个清单就是天然的 review 入口它能逼着我把注意力放在它到底动了什么上而不是被新代码完整、好看的外表迷惑。3.2 经验四大改动之前先要方案再要代码AI 的默认行为是收到需求直接给代码但它经常不判断你的现有架构。举例来说有一次我在写一个内部工具时项目里已经封装好了一个请求工具函数统一带 token、统一处理错误码。AI 接到一个新页面需求后直接在页面里又写了一套新的网络请求逻辑。代码当然能跑但项目自此有了两套网络请求层后面所有维护成本直接翻倍。为什么模型会这样干因为它并不理解你项目里的约定它只见过太多风格不统一的代码于是倾向于现场造一套自己最熟悉的写法。对策也很简单——在大改动之前先给 Trae 下一条方案指令先不要写代码。列出你的改动方案影响哪些文件新建哪些文件复用哪些现有函数是否修改公共模块。我确认方案后你再动手。这一步相当于给 AI 装了一个强制评审环节成本不过一两分钟收益却极大。方案一出来你立刻能发现它是不是又要造新轮子、会不会碰到底层不该碰的东西。如果方案不对直接纠正方向而不是等它写完几百行再返工。我现在给自己定的规矩是凡是影响跨文件结构的改动必须走方案先行只有纯粹的单文件小修改才允许直接给代码。4. 经验五、六AI 写代码真正的门槛是审查和验证4.1 经验五关键路径必须人工看别信AI 说没问题这一条如果只能记一条请记这条。AI 生成的代码在列表页、CRUD、纯展示场景里出错概率不高但一旦涉及权限校验、支付金额、数据持久化、并发控制、正则校验这类敏感逻辑千万不要因为它说已通过测试就直接放过。我之前在一个模拟项目里排查过重置密码接口的问题那个接口就是用 Trae 生成的。接口能跑也会更新数据库但完全没有校验这个邮箱是不是当前登录用户本人的。换句话说任何一个登录用户都能通过改请求参数把别的账号密码重置掉。编译完全正常、运行完全正常但逻辑层面就是一个致命漏洞。这类问题最可怕的地方就在于它不在表面报错只会在真出事的时候爆发。我在项目里给自己立了一条规矩涉及认证、权限、金额、删除操作的文件生成后必须逐行人工 review。并且我还会在对话里额外要求 AI这段代码生成后标注你做了哪些安全假设。AI 的安全假设往往就是最大的坑。我假设调用方已经校验了权限这样一句话有时候就是事故现场。4.2 经验六编译通过不等于逻辑正确用测试用例把 AI 逼到死角AI 代码最迷惑人的地方就是看起来能跑。编译通过只是最低标准边界条件才是 AI 频繁翻车的地方。最常见的三类问题空值没判断、循环边界差 1、并发场景里没考虑锁或原子性。这些在正常路径上完全不会暴露等踩到的时候往往已经晚了。我现在的做法是把验证方式从跑一下看看升级为写测试用例来跑。在 Trae 里我会直接让它先写测试在 tests/user.test.js 中为 isVipUser 函数补充测试用例覆盖普通用户、过期会员、空对象、null 输入四种情况然后运行测试。这一步的精妙之处在于你不是事后再去审 AI 的代码而是先用测试用例把 AI 逼到死角。为了通过测试它必须处理那些本来想偷懒绕开的边界分支。实测下来同样一个功能如果我先要测试再要实现AI 生成代码的质量会明显高一个档次。另外一个配套习惯是每次 AI 完成一个功能我会手动跑一遍最小复现流程。比如新增了导入功能就真的拿三行脏数据导一次新增了搜索就真的试一次空搜索和特殊字符搜索。把这些固定成肌肉记忆之后你在项目里对 AI 的授权尺度会明显变大因为你知道它有兜底验证翻不出大浪。5. 经验七让 AI 大胆改但你负责踩刹车5.1 经验七改前先建还原点commit 比任何时候都重要AI 一次改多个文件的时候经常出现改完发现比原来还乱的窘境。真正的解药不是不让 AI 改而是保证一切都可以回滚。我把 Git 的使用逻辑简化成三条规则# 规则1重大改动前先给当前状态打一个快照 git add -A git commit -m chore: 改动前稳定快照 # 规则2AI 每完成一个边界清晰的小任务单独 commit git add -A git commit -m feat: 新增用户禁用按钮 # 规则3AI 改到一半失控时直接回滚 git checkout -- . git clean -fd别嫌这三条土。有了回滚机制你就敢让 AI 做大胆重构没有它你会在怕改坏和只敢让它改小地方之间反复摇摆最后两种状态都很难受。我个人的默认做法是动手之前先 commitAI 每完成一个自治性任务再 commit。这样无论它怎么折腾我都有退路。5.2 把 Trae 当队友而不是代笔一次复盘与一个小技巧最后分享一个完整例子。有个技术群里认识的某开发者用 Trae 做了个简易数据看板最初几乎每次改需求老功能就坏一次。原因就是他把 Trae 当成了许愿池需求一股脑丢进去。后来他按这套流程走先写清单、拆任务、最小改动、让 AI 写测试、每次改前都 commit。一周之后他和我说最明显的变化不是效率高了而是终于不用整天给 AI 擦屁股了。我自己的体会也差不多。用 Trae 到现在我形成了一份固定的 AI 协作清单开新项目先写最小功能清单每次只丢一个小任务长文件强制最小改动跨文件改动先要方案认证/权限/金额相关代码人工 review测试用例约束边界动手之前先 commit。这套循环走下来标题里说的少踩一半的坑真不是夸张说法。最后再补一个小技巧如果对话已经楼歪了不要试图在同一个会话里反复纠正 AI。新建一个会话把关键背景重讲一遍往往比在旧线程里翻来覆去有效得多。上下文窗口再大堆了一堆无效讨论后生成质量也会下降。重开会话等于给 AI 一次重新思考的机会。
第一次用 Trae 做 AI 开发是在一个周末。当时我想做一个内部用的团队日志小工具把需求仔仔细细打进了对话框心想 AI 写代码不就是把话说清楚吗。结果一个下午过去项目倒是跑起来了登录逻辑却乱成一团数据库表里还多了三个我根本不认识的多余字段。后来我连续实测了一个多月翻了不少车才慢慢摸出一些门道最终把最容易踩的坑总结成了 7 条经验。我不敢说这些经验能让你直接变成高手但照着做少踩一半的坑是绰绰有余的。这篇内容适合正在用 Trae或者正准备让 AI 编程工具帮你做全栈小项目、写脚本、搭原型的人也特别适合被AI 生成的代码看着能用、改起来要命折磨过的朋友。先说明一个前提下面所有经验不是书上抄来的理论都是来自实际项目反复摔打之后的操作心得有几条甚至和大家的直觉相反。1. 用 Trae 的第一周我踩过的三个隐形坑1.1 Trae 做对了什么AI 原生 IDE 到底强在哪先客观地说Trae 确实改变了我写代码的节奏。它不是传统编辑器那种装个插件、旁边挂一个聊天窗口的用法而是把 AI 直接融进项目上下文里。它能读当前文件、能看整个仓库的文件结构、能拿到终端输出还能一次改多个文件。你选中一段代码它可以直接解释、重构、修 bug你把一张报错截图丢给它它也能看懂。用在搭原型、写胶水脚本、做内部小工具这些场景这种工作流是真的快。我以前写一个内部小工具从建项目到能跑怎么也得一晚上。现在用 Trae基本一顿饭的功夫就能出一个可用的版本。这也是我后来愿意花时间去研究它坑在哪里的原因——收益太明显了值得把工具用透。1.2 为什么一句话生成项目会翻车翻车场景我在开头已经说了一半。其实根本原因非常简单AI 写代码和人一样需要上下文。你说帮我做一个团队日志小工具它怎么知道你要不要登录要不要权限分级要不要多人协作要不要数据导出它不知道于是就会启动平均值模式把所有能想到的功能都猜出来放进去。每个字段它猜一点每个页面它猜一点最后出来的就是一坨你用不上、删起来又牵连甚广的代码。更麻烦的是它猜错的时候不会告诉你。比如它默认所有用户都是管理员、默认金额不涉及精度、默认没有并发写入。这些默认值被埋进代码之后问题要到很后面才会爆出来等爆出来的时候你又很难把线索追溯到源头。1.3 认知调整把 Trae 当结对程序员而不是自动代笔所以我在第一周结束的时候得到一个最重要的认知调整预期。用 Trae 的正确心态不是我出需求、它出代码而是我当负责人、它当执行者。它像一个精力旺盛但缺少全局判断的新人你给明确的任务它能执行得很热闹你完全放开它能在一小时里把代码写到让你看不懂。这听起来像是废话可到了实操里很多人还是忍不住把 AI 当成许愿池。接下来这 7 条经验本质上都在回答同一个问题怎么让这个执行力很强的人在正确的地方以正确的方式干活。2. 经验一、二选对模式拆对任务2.1 经验一Builder 模式和 Dialog 模式别用反了Trae 里有两个最容易混淆的入口Builder构建模式和 Dialog对话模式。Builder 适合从零搭建项目骨架你把需求说清楚它直接生成一个可运行的结构Dialog 适合对已有代码做局部修改。这两个模式的差异直接决定你用 Trae 是顺滑还是卡壳。这两种模式我见过太多人用反了。有人在 Builder 里反复纠缠加个字段去掉按钮换配色这就好比让一个擅长盖整栋楼的包工头去拧螺丝效率低不说还特别容易把别处弄坏。反过来也有人往 Dialog 里丢一句重构整个项目一次指令下去改了四十多个文件改完项目跑都跑不起来。拿我自己反复迭代的一个模拟项目X内部库存管理小工具举例我的标准流程是先开 Builder用一段话描述核心需求生成一个最小可用的库存管理页面包含商品列表、入库、出库三个核心功能先不做权限和报表。Builder 生成完骨架我立刻切到 Dialog。之后所有迭代都在 Dialog 中进行比如给入库表单增加备注字段出库流程增加确认二次弹窗。只有遇到特别大的结构调整时才重新开 Builder或者新建一个对话从头梳理。场景推荐模式理由从零生成项目骨架Builder一次性生成目录、依赖、基础代码效率最高修改单个函数/样式/文案Dialog改动面积小AI 容易保持克制整体重构、调整架构单独新对话避免旧上下文干扰也方便回滚多轮需求讨论Dialog边聊边改但注意及时收敛经验核心一句话Builder 只用来盖楼Dialog 只用来装修。别混着用你会在这一条上省下非常多的时间。2.2 经验二一个指令只做一件事拆任务是核心能力AI 编程工具最大的瓶颈很多时候不是模型本身而是指令太贪心。一句话塞三个需求把登录功能完善一下、样式调好看点、顺便把最近的 bug 修了这种话说给同事听同事都会皱眉AI 也一样。它的典型表现是挑其中最容易做的一部分先完成另外两个要么忘记要么做一半最后你根本不知道它到底做了哪些、没做哪些。我的做法是把每次任务拆成最小可验收单元并且尽量带上验收标准。所谓最小可验收单元就是这句话发出去它能独立完成、你也能独立验证结果的一个小任务。举个例子反例优化一下用户管理模块。正例在用户管理页新增一个禁用用户按钮点击后调用 PUT /users/{id}/disable 接口成功后刷新列表。只改 user-admin.js 这一个文件。你可能会觉得这样太碎、太啰嗦。但实测下来这恰恰是最省时间的做法因为 AI 的出错率和指令复杂度不是线性关系是指数关系。10 个小任务每个花 2 分钟一共 20 分钟就能全部搞定1 个复杂度拉满的任务可能折腾一两个小时还出不来正确结果。怎么算都划算。拆任务时我还用一条标准自检如果这个指令你自己动手可以在 10 分钟内完成那它就是一个合适大小的任务如果超过 10 分钟就接着拆。在 AI IDE 里任务粒度直接决定生成质量——这句话值得写在屏幕贴纸上。3. 经验三、四提示词的本质是控制 AI 的动作幅度3.1 经验三要修改而不是重写AI 生成代码有个天然倾向整文件重写。原因不难理解模型更擅长输出一个完整答案你让它改某个函数它也很可能把整个文件重新输出一遍。文件只有 50 行还好到了 500 行问题就出来了。重写过程中它可能顺手优化了其他函数、改了缩进风格甚至因为上下文过长丢掉部分老代码。你明明只让它动一行最后 diff 里却躺着二十处变化每一处你都得人肉确认一遍。我后来在指令里会明确加一句最小改动原则并且针对长文件专用一套措辞只修改 saveUser 函数内部逻辑其他函数保持原样不要调整 import 和格式。请先列出修改涉及的文件和行号我确认后再改。如果工具支持内联编辑优先用内联而不是整段重新生成。还有一个压箱底的小技巧如果 AI 实在无法避免整段输出我会让它先给改动清单我再决定要不要接受。这个清单就是天然的 review 入口它能逼着我把注意力放在它到底动了什么上而不是被新代码完整、好看的外表迷惑。3.2 经验四大改动之前先要方案再要代码AI 的默认行为是收到需求直接给代码但它经常不判断你的现有架构。举例来说有一次我在写一个内部工具时项目里已经封装好了一个请求工具函数统一带 token、统一处理错误码。AI 接到一个新页面需求后直接在页面里又写了一套新的网络请求逻辑。代码当然能跑但项目自此有了两套网络请求层后面所有维护成本直接翻倍。为什么模型会这样干因为它并不理解你项目里的约定它只见过太多风格不统一的代码于是倾向于现场造一套自己最熟悉的写法。对策也很简单——在大改动之前先给 Trae 下一条方案指令先不要写代码。列出你的改动方案影响哪些文件新建哪些文件复用哪些现有函数是否修改公共模块。我确认方案后你再动手。这一步相当于给 AI 装了一个强制评审环节成本不过一两分钟收益却极大。方案一出来你立刻能发现它是不是又要造新轮子、会不会碰到底层不该碰的东西。如果方案不对直接纠正方向而不是等它写完几百行再返工。我现在给自己定的规矩是凡是影响跨文件结构的改动必须走方案先行只有纯粹的单文件小修改才允许直接给代码。4. 经验五、六AI 写代码真正的门槛是审查和验证4.1 经验五关键路径必须人工看别信AI 说没问题这一条如果只能记一条请记这条。AI 生成的代码在列表页、CRUD、纯展示场景里出错概率不高但一旦涉及权限校验、支付金额、数据持久化、并发控制、正则校验这类敏感逻辑千万不要因为它说已通过测试就直接放过。我之前在一个模拟项目里排查过重置密码接口的问题那个接口就是用 Trae 生成的。接口能跑也会更新数据库但完全没有校验这个邮箱是不是当前登录用户本人的。换句话说任何一个登录用户都能通过改请求参数把别的账号密码重置掉。编译完全正常、运行完全正常但逻辑层面就是一个致命漏洞。这类问题最可怕的地方就在于它不在表面报错只会在真出事的时候爆发。我在项目里给自己立了一条规矩涉及认证、权限、金额、删除操作的文件生成后必须逐行人工 review。并且我还会在对话里额外要求 AI这段代码生成后标注你做了哪些安全假设。AI 的安全假设往往就是最大的坑。我假设调用方已经校验了权限这样一句话有时候就是事故现场。4.2 经验六编译通过不等于逻辑正确用测试用例把 AI 逼到死角AI 代码最迷惑人的地方就是看起来能跑。编译通过只是最低标准边界条件才是 AI 频繁翻车的地方。最常见的三类问题空值没判断、循环边界差 1、并发场景里没考虑锁或原子性。这些在正常路径上完全不会暴露等踩到的时候往往已经晚了。我现在的做法是把验证方式从跑一下看看升级为写测试用例来跑。在 Trae 里我会直接让它先写测试在 tests/user.test.js 中为 isVipUser 函数补充测试用例覆盖普通用户、过期会员、空对象、null 输入四种情况然后运行测试。这一步的精妙之处在于你不是事后再去审 AI 的代码而是先用测试用例把 AI 逼到死角。为了通过测试它必须处理那些本来想偷懒绕开的边界分支。实测下来同样一个功能如果我先要测试再要实现AI 生成代码的质量会明显高一个档次。另外一个配套习惯是每次 AI 完成一个功能我会手动跑一遍最小复现流程。比如新增了导入功能就真的拿三行脏数据导一次新增了搜索就真的试一次空搜索和特殊字符搜索。把这些固定成肌肉记忆之后你在项目里对 AI 的授权尺度会明显变大因为你知道它有兜底验证翻不出大浪。5. 经验七让 AI 大胆改但你负责踩刹车5.1 经验七改前先建还原点commit 比任何时候都重要AI 一次改多个文件的时候经常出现改完发现比原来还乱的窘境。真正的解药不是不让 AI 改而是保证一切都可以回滚。我把 Git 的使用逻辑简化成三条规则# 规则1重大改动前先给当前状态打一个快照 git add -A git commit -m chore: 改动前稳定快照 # 规则2AI 每完成一个边界清晰的小任务单独 commit git add -A git commit -m feat: 新增用户禁用按钮 # 规则3AI 改到一半失控时直接回滚 git checkout -- . git clean -fd别嫌这三条土。有了回滚机制你就敢让 AI 做大胆重构没有它你会在怕改坏和只敢让它改小地方之间反复摇摆最后两种状态都很难受。我个人的默认做法是动手之前先 commitAI 每完成一个自治性任务再 commit。这样无论它怎么折腾我都有退路。5.2 把 Trae 当队友而不是代笔一次复盘与一个小技巧最后分享一个完整例子。有个技术群里认识的某开发者用 Trae 做了个简易数据看板最初几乎每次改需求老功能就坏一次。原因就是他把 Trae 当成了许愿池需求一股脑丢进去。后来他按这套流程走先写清单、拆任务、最小改动、让 AI 写测试、每次改前都 commit。一周之后他和我说最明显的变化不是效率高了而是终于不用整天给 AI 擦屁股了。我自己的体会也差不多。用 Trae 到现在我形成了一份固定的 AI 协作清单开新项目先写最小功能清单每次只丢一个小任务长文件强制最小改动跨文件改动先要方案认证/权限/金额相关代码人工 review测试用例约束边界动手之前先 commit。这套循环走下来标题里说的少踩一半的坑真不是夸张说法。最后再补一个小技巧如果对话已经楼歪了不要试图在同一个会话里反复纠正 AI。新建一个会话把关键背景重讲一遍往往比在旧线程里翻来覆去有效得多。上下文窗口再大堆了一堆无效讨论后生成质量也会下降。重开会话等于给 AI 一次重新思考的机会。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
