★ FEATURED ARTICLE 我用了快两个月的 Trae从最开始只是拿它当“带界面的 GPT”用到后来把整套项目需求、原型图、前后端代码、联调测试全扔给它感受最深的一点是这工具不是来帮你写几行代码的它是来帮你把一个“活”从头到尾接过去的。Trae 是字节跳动推出的 AI IDE本质上是 VS Code 的分支所以如果你用过 VS Code上手几乎没有成本。但它和普通 IDE 加插件最大的区别是它内置了一套完整的 AI Agent 能力不是你在侧边栏问一句它答一句而是你给它一个目标它自己规划、改代码、跑命令、修 bug干完了还跟你汇报。这篇文章不聊安装和基础操作那些官方文档比我写得好。我只讲我真实项目里反复验证过的 4 个关键功能以及它们是怎么组合起来把“整个活”交给 AI 的。无论你是前端、后端、全栈还是只会写点脚本的业余爱好者只要你手上有一个具体的小项目想快速落地这篇文章应该能帮你省下大量时间。顺便把我在积分、模型选择、MCP 配置上踩过的坑也一并说了。1. 核心思路为什么敢把“整个活”交给 AI1.1 Trae 的本质是填平“AI 问答”和“AI 干活”之间的沟很多人用 AI 编程工具的姿势是这样的在 ChatGPT 里问“帮我写一个登录页面”拿到代码粘贴到项目里运行报错再把报错贴回去来回折腾十几次。这不是 AI 干活这是 AI 当字典查。Trae 的逻辑完全不一样。它直接住在你的项目里能看到你的文件结构、代码上下文、终端输出甚至能自己去跑命令、装依赖、起服务。你给它的是一个“目标”而不是一个“问题”。它拿到目标之后自己拆解任务列表然后逐个执行。我举个例子。我之前要做一个内部用的数据看板需求是从后端接口拉数据前端做图表展示支持时间范围筛选。如果按传统方式我需要先写前端页面再写接口联调再处理 loading 和错误状态最后还要调样式。但在 Trae 里我只需要在 Builder 模式下发一句话“创建一个数据看板页面接口路径是 /api/dashboard/data返回结构是 {dates: [], values: []}用 ECharts 展示折线图加上时间筛选器”。它自己会去读项目里已有的代码风格、装 ECharts、创建组件、写接口调用然后我在预览窗口里看到效果不满意直接跟它说“把折线图改成柱状图”它继续改。这个体验的核心差异在于传统 AI 给的是“代码片段”Trae 给的是“完成状态”。1.2 4 项功能的组合逻辑我挑了 4 个最核心的功能来拆解它们是支撑“把活整个交给 AI”这个目标的最小闭环Builder 模式把自然语言需求变成本地代码的自动驾驶仪。AI 上下文管理与项目规则确保 AI 在改代码时不乱来、不跑偏。Trae CLI不打开 IDE也能在终端里指挥 AI 干活。MCP 集成让 AI 能读取 Figma/MasterGo 设计稿等外部工具数据打通从设计到代码的链路。这 4 个功能不是孤立的。Builder 负责“动手”上下文和规则负责“守规矩”CLI 负责“远程遥控”MCP 负责“开眼看外部世界”。它们组合在一起才真正意义上把“项目经理 程序员 测试 运维”这四个角色压缩成了一句话。1.3 适合什么项目不适合什么项目先说结论适合中型以下、需求边界清晰、技术栈不太冷门的项目。不适合探索性极强、架构决策风险极高的大型系统。我自己用它做过几个完整的全栈小项目比如带用户登录的后台管理系统、自动生成周报的小工具、对接第三方 API 的数据同步服务。这些项目的特点是需求明确技术栈主流React/Vue/Node/Python对代码质量要求是“能跑、好改、不太烂”。这类活交给 Trae效率提升是倍数级的。但如果是那种需要深度架构设计、大量历史代码兼容、或者业务规则极其复杂的系统AI 目前的水平还达不到“独立负责”的标准。这种情况下把它当高级助手用让它写单元测试、处理模板代码、做代码审查反而更合适。2. Builder 模式从自然语言到可用代码2.1 Builder 的工作方式和技术原理Builder 模式是 Trae 最核心的亮点理解它的工作方式你就理解了这个工具的设计哲学。它本质上是一个Agent Loop代理循环大模型先生成一个执行计划然后调用工具执行计划中的步骤每执行一步都观察结果再决定下一步做什么。这个循环会一直持续直到你给的目标被完成或者它自己判断需要向你提问。我观察到的典型执行路径是理解需求读取你当前打开的文件、项目结构和你在对话里发出的指令。制定计划在侧边栏显示一个任务列表比如“创建 api.ts 文件”“修改 Dashboard.vue”“安装 echarts 依赖”。执行代码修改自动创建、修改、删除文件。你可以实时看到 diff代码差异随时中断。运行命令它会自动执行npm install、npm run dev这类命令检查有没有报错。自检迭代如果发现运行错误它会读报错信息自己修复继续跑直到跑通或者尝试次数耗尽。这里有个很关键的细节Trae 的 Builder 模式和普通对话模式是两个不同的入口。对话模式是你一问、它一答适合问问题、查资料Builder 模式才是真正让它动手改代码的模式。很多人觉得 Trae 不智能其实是用错了入口。2.2 实操案例用 Builder 做一个小型登录功能我拿一个实际做过的功能来走一遍完整流程。假设项目是 Vue 3 Vite已有基本框架现在要做登录页。第一步在 Builder 模式下输入提示词在现有 Vue 3 项目中实现一个登录页面包含用户名和密码输入框、登录按钮。调用 /api/login 接口成功后将 token 存入 localStorage并跳转到 /dashboard 页面。接口返回结构是 {code: 200, data: {token: xxx}}。第二步观察 Trae 的行为。它会先扫描项目里已有的目录结构和路由配置然后创建views/Login.vue修改router/index.js添加路由创建api/auth.js封装接口调用甚至会在package.json里检查是否安装了 axios没装的话自动装。第三步自动启动开发服务器验证。它会在终端里跑npm run dev然后用无头浏览器模拟操作如果你配置了浏览器插件或者通过代码静态检查来验证功能。如果它发现自己写错了接口地址它会主动修正。我的建议是过程中你不要干等而是盯住它的 diff 面板看到不合理的地方立刻中断纠正。比如它如果要把整个main.js重写你就要阻止它因为那说明它没有理解你的项目结构最好先把相关文件引用关系告诉它。2.3 给 Builder 写“能执行”的提示词模板这可能是全文最值钱的部分。我总结了一套给 Builder 模式的提示词模板实测下来成功率远高于随意描述。模板一新功能开发在 [项目名] 中实现 [功能名]。 需求描述[尽量具体包括页面元素、交互逻辑、接口字段] 技术约束[使用已有的 XX 组件库、遵循项目的 XX 代码规范] 验收标准[运行 npm run dev 后能正常访问点击按钮能调通接口报错时弹出提示]模板二修改已有功能在 [文件名] 中修改 [某个具体行为]。 当前问题[描述现象最好附上报错信息] 期望结果[描述期望行为] 注意[不能影响现有的 XX 功能保持和 XX 文件的一致性]模板三跨文件重构把 [旧方案] 重构为 [新方案]。 涉及范围[列出会影响的文件让 AI 不要乱动其他文件] 接口要保持兼容[说明哪些外部依赖不能破坏] 重构完成后运行 [具体命令] 验证。我在实际操作中发现Builder 模式最怕两件事太抽象的指令比如“优化一下代码”和太开放的目标比如“做一个博客系统”。前者它不知道改哪里后者它会发挥过头最后搞出一堆你不需要的东西。所以给它的指令要有限制条件就像你给一个很能干的新同事布置任务边界画得越清楚干活越顺畅。2.4 积分消耗和模型选择的取舍Trae 的免费版是限量的普通对话模式下每天有固定的免费次数Builder 模式消耗相对更快。这就涉及到一个非常现实的问题怎么在有限积分下干最多的活我的策略是三层分配普通语法、概念提问、找 API 用法用免费对话即可没必要进 Builder。小范围的单文件修改用对话模式中的“编辑”功能让 AI 直接改文件消耗较低。跨多文件、需要跑命令验证的功能开发才用 Builder 模式。另外Trae 支持选择不同的模型比如 Claude 系列和自研模型。从我的实测看复杂逻辑理解和前端页面生成Claude 系模型的成功率更高简单的机械性修改、代码补全自研模型也够用且响应更快。我的习惯是Builder 模式里选最强模型日常对话用默认模型这样积分消耗能优化不少。关于积分Trae 有一个兑换机制有时候活动会发放积分兑换码。我的建议是别囤因为免费额度每天有限你积攒的兑换积分如果超过有效期会清零。我自己吃过这个亏兑换了一堆结果出差两周没用回来一看清零了。日常该用就用把额度当资源而不是资产。3. AI 上下文管理与项目规则教会 AI 守规矩3.1 上下文管理机制AI 怎么“看懂”你的项目Builder 模式强大归强大但它有个明显的短板如果不加约束它对项目的理解会“浅”。它默认会在当前打开的文件和对话上下文里寻找信息一个大型项目有成百上千个文件它不可能全部塞进模型上下文里这时候它就会“猜”。猜的结果就是它可能生成了和现有代码风格完全不搭的文件或者用了项目里根本没有的依赖甚至把你已经写好的代码覆盖掉。这种问题如果频繁出现你会觉得 AI 还不如自己写。要解决这个问题得主动管理 AI 的上下文。Trae 在这方面提供了几个工具比如# 符号引用你在对话里输入#或会自动弹出当前项目的文件列表你可以手动指定 AI 应该重点阅读哪些文件。这比我前几年用其他工具时需要在提示词里贴一堆代码片段要优雅得多。我的习惯是在下达 Builder 任务前在提示词里用把相关的文件都带上然后再写需求。比如请阅读 src/api/user.js 和 src/store/user.js然后修改登录页 src/views/Login.vue让登录成功后调用 store 里的 setToken 方法而不是直接操作 localStorage。这样 AI 对现有代码的理解就从“猜”变成了“读”。这一个小动作能大幅提高修改成功率。3.2 项目规则文件让 AI 从一开始就懂规矩Trae 支持在项目根目录创建规则文件告诉 AI 这个项目的约定和偏好。这个功能太重要了因为它解决了“每次都要重复交代”的痛点。项目根目录下有一个.trae/rules目录你可以在里面建不同的规则文件比如project_rules.md、frontend_rules.md。规则文件里的内容会被自动注入到每次对话上下文中相当于给 AI 上了一堂“项目文化课”。我建议最好把这几类内容写进去技术栈说明项目用的是 Vue 3 组合式 API 还是 Vue 2 选项式 API用了哪个组件库Node 版本是多少代码风格约定缩进用两个空格还是四个分号加不加组件命名是 PascalCase 还是 kebab-case目录结构约定API 请求放哪个目录页面组件放哪个目录公共组件怎么归类禁区哪些文件不能动哪些构建配置不能改比如我的一个项目规则文件长这样- 本项目使用 Vue 3 TypeScript Vite。 - 状态管理使用 Pinia禁止引入 Vuex。 - API 请求统一放在 src/api 目录下禁止在组件中直接使用 axios。 - 组件命名统一使用 PascalCase文件命名统一使用 kebab-case。 - 样式使用 TailwindCSS非特殊情况禁止写原生 CSS。 - src/shims-vue.d.ts 文件为自动生成文件禁止修改。有了这个文件之后你会发现 Builder 模式的行为规范了很多。以前它可能随手创建一个utils/http.js现在它会知道你项目里已经有一个src/api/request.ts会主动去复用。3.3 多文件协同编辑与重构Trae 有一个让我很惊喜的能力跨多文件协同编辑。它不只是一个文件一个文件地改而是能同时理解多个文件的依赖关系进行联动修改。举个例子有一次我改一个接口的返回结构原来是{success: true, data: {...}}后端改成{code: 200, data: {...}}。按传统方式我得找到所有调用这个接口的地方挨个改判断条件。在 Trae 里我只需要告诉它后端接口返回结构从 {success: boolean, data: any} 改成了 {code: number, data: any}请更新所有涉及该接口判断逻辑的文件并在接口层做统一封装避免每个页面都改一遍。它会自己搜索所有引用了这个接口的文件评估影响范围然后统一在 API 封装层做适配同时修改各个页面的判断逻辑。整个过程它会列出一个修改清单给我预览我确认后它才动手。这个功能对“重构”场景特别有价值。重构是那种又费时间、又容易出错、又不想自己干的活现在可以放心地让 AI 去做只需要在完成后做一轮测试验证。3.4 模型选型一个项目里不同的模型各干各的Trae 里能切换不同模型这一点很多人没充分利用。我的建议是别从头到尾只用同一个模型而是根据任务难度动态切换。简单总结我的经验任务类型推荐模型原因代码补全、格式化、简单语法问题默认自研模型快、省积分、日常够用复杂业务逻辑实现、跨文件修改Claude 系列上下文理解强代码生成质量高解释报错、排查诡异 bugClaude 系列推理能力更强能分析多层嵌套原因文案生成、正则表达式等无项目上下文任务任一模型均可对上下文要求低我踩过的一个坑是在项目里用默认模型让 AI 重构一个状态管理模块结果它反复改写不下十次每次都有新错误最后我切换到更强的模型一次就改对了。所以遇到反复不成功的情况先别急着换提示词试试换一个模型往往很快就能解决。4. 命令行 Agent不打开 IDE 也能指挥 AI 干活4.1 Trae CLI 能做什么Trae CLI 是一个让人惊艳的功能。它在终端里运行一个交互式命令行工具通过它和 AI 进行多轮对话。它和 IDE 里最常见的使用场景区别在哪里我理解有两种。一种是在 IDE 里打开工程文件AI 从界面读取你的代码、运行、调试适合要写代码的工作。另一种是在终端命令行里直接让它做事它看不到 IDE 界面但可以通过文件系统、git 命令、终端执行等方式和项目交互适合快速执行一些小的、不需要打开编辑器的任务。我在实际使用中比较常用的场景写完代码后在终端运行trae 帮我检查一下当前分支的代码找出潜在的 bug 和安全隐患让 AI 做一轮代码审查。提交代码前运行trae 根据 git diff 生成一份规范的 commit message解决每次写提交信息都头疼的问题。项目部署时用trae 检查 package.json 里的依赖版本看有没有需要更新的快速做依赖审计。4.2 把 CLI 接入自动化流程CLI 最实用的地方是可以嵌入脚本。比如我写过一个自动化部署脚本里面加了一步#!/bin/bash # 代码检查通过后才允许部署 trae 请审查当前代码库重点关注安全性问题如果发现高危漏洞输出 FAIL否则输出 PASS当然脚本没法直接拿到 Trae 的终端输出做判断这个我最后还是处理成人工确认的流程。更实际的用法是把 CLI 当成“AI 助手通道”在需要 AI 协助的命令行场景里直接调用不用特意打开 IDE。比如在 CI 环境里可以让它生成发布说明在本地开发时可以用它快速生成 API 文档草稿在交接工作时让它根据仓库代码生成项目结构说明。4.3 Builder 模式和 CLI 的分工这里理清一下Builder 模式和 CLI 都能让 AI 改代码但工作场景不同。Builder 模式更适合需要视觉反馈的场景比如写一个页面要看效果需要持续观察运行结果的场景比如跑测试、跑开发服务器需要多文件协同重构的场景。CLI 更适合纯代码层面的操作不涉及运行/调试的场景快速问答、代码搜索、文档生成的场景自动化脚本里需要 AI 赋能的场景远程服务器上不方便打开 IDE 的场景。我个人比较常用的一个组合是先用 CLI 快速探索代码库了解某个功能是在哪个文件实现的然后用 Builder 模式做实际修改改了之后再用 CLI 复盘检查。4.4 Maven 配置和构建环境中的 CLI 实践还有一个很多人忽略的场景CLI 在 Java 项目里也很有用。特别是我看到有人问 “trae cn maven配置”这其实是指 Trae 在 Java/Maven 工程下的使用。Maven 项目的特点是构建链路长、报错信息藏在海量日志里。用 Trae CLI 处理这个场景方式是trae 项目的 maven 构建失败了请查看最近的日志文件分析是什么依赖问题并给出修复建议需要注意一个前提CLI 如果要在终端直接跑mvn命令它需要继承你当前终端的环境变量比如 JAVA_HOME。我踩过的一个坑是在 IDEA 里配置的 JDK 和终端里的 JAVA_HOME 不一致导致 AI 在终端里推荐命令时没有考虑到这个问题按照 IDEA 里的配置去理解项目给出的命令在终端里跑不通。所以在 Java 项目里使用 Trae一定先确认终端环境的 JDK 版本和项目要求一致。5. 打通外部工具MCP 集成实战5.1 MCP 是什么为什么它这么重要MCPModel Context Protocol是 Anthropic 推出的一种开放协议它规范了 AI 模型如何连接外部数据源和工具。简单说它像一个“USB 接口”让 AI 模型可以插上各种“外设”——比如读取本地数据库、访问设计稿、操作浏览器等。Trae 较早支持了 MCP。之前我用其他 AI 编程工具最大的一个问题是AI 只能看到代码看不到设计稿、产品文档、数据库结构等“人类开发者经常参考的东西”。这导致 AI 写出来的前端页面经常和设计稿差得很远AI 理解的接口字段和数据库里真实的表结构不一致。有了 MCP 之后这些信息可以变成 AI 的“上下文”喂给它。比如我可以给 Trae 配置一个连接 MySQL 的 MCP让它直接查看表结构看一张表有哪些字段、类型是什么再去生成代码就不用我再一篇篇地复制了。5.2 接入 MasterGo/Figma从设计稿到代码的直通车最近很多人在问 “figma mcp 怎么运用在 trae”还有一个高频词是 “trae 读取 mastergo”。这说明设计稿到代码的流程很多人都想打通。以 Figma 为例Figma 官方发布了 MCP Server允许 AI 读取 Figma 设计稿的节点结构、图层名、样式属性等。在 Trae 中配置好的话你可以直接对 Builder 模式说读取 设计稿中的“登录页”节点按照设计稿的布局、配色、字号在项目里实现这个页面注意这里有一个实际的难点Figma MCP 需要访问 Figma API这通常需要一个 Personal Access Token并且要在 Trae 设置的 MCP 配置里填进去。具体操作流程是在 Figma 中生成 Personal Access Token登录 Figma 后到设置里创建。在 Trae 的 MCP 配置中心里添加一个 MCP Serveraddress 填 Figma 官方提供的 URLToken 填你创建的 Token。用 Figma 的分享链接或者文件 key让 AI 去读取。这个功能对前端开发非常有价值。以前设计师出完稿前端要手动量尺寸、看颜色、切图现在可以直接让 AI 读取设计稿信息生成页面基础代码。但要提醒一点它目前对简单的页面效果很好对复杂的交互、动效、特殊组件库的自定义样式还是会有偏差所以更实际的定位是“基础代码生成器”而不是“完全自动的 UI 实现”。5.3 自定义 MCP 服务的配置方案除了官方提供的 MCP ServerTrae 还支持自定义 MCP 服务。这意味着你可以把内部系统接入 AI。具体的实现方式通常是在 Trae 设置界面找到 MCP 配置项填上 MCP Server 的地址。有些 MCP 服务需要你本地安装运行那就要在本地先启动一个 MCP Server 进程再把本地地址填进去。我在一个项目里做过这样的尝试公司内部有一个聚合搜索系统提供 HTTP 接口。我用 Python 写了一个简单的 MCP Server把搜索接口包装成 MCP 工具然后在 Trae 里配置好。这样我在写代码时直接让 AI 调用内部搜索服务获取数据格式再生成调用代码。虽然配置过程有点折腾但对团队内部开发效率的提升是很大的。5.4 MCP 的局限和避坑建议MCP 虽然强但不是万能的。我踩过几个坑分享出来帮大家避开第一MCP 读取到的数据可能过时。MCP 通过 API 读取数据API 返回的是“某个时间点的快照”。比如设计稿改了一版MCP 读取到的可能还是旧数据取决于缓存策略。所以在关键交付前我有一次对着旧版设计稿写代码返工了一次。现在我会在让 Builder 读设计稿之前先跟它确认它读到的节点名称对不对。第二Token 泄漏风险。配置 MCP 时填写的 Token会以明文或近似明文的形式存在配置里。如果你的项目是团队共享的多人都在用一个工作区要注意不要把自己的个人 Token 留在项目共享配置里尽量用专用账号。第三MCP 不是越多越好。每多接一个 MCPAI 的决策空间就多一层有时候会莫名其妙调用了一个不该调用的 MCP 工具导致结果怪异。我的原则是只配置当前项目真正用到的 MCP用不到的暂时禁用。6. 常见问题与排查技巧实录6.1 积分不够用、限额触发了怎么办免费额度用完后Trae 会提示限额。我的处理办法是先优化用法。把消耗积分的 Builder 模式当成“重型武器”只在大任务时用。日常的问询、代码片段生成用免费对话额度即可。修改小文件时优先用“编辑”功能它比 Builder 省得多。再考虑兑换。关注 Trae 官方活动有时会发积分兑换码。兑换码一般在特定的活动页面输入兑换兑换后积分会加到账户里。但我前面说了小心有效期别兑换太多用不完。最后才是付费。如果你每天必须要用 Builder 模式大量干活积分确实不够那就要评估下是否值得付费订阅。我的看法是如果你能把 Trae 用成“一个人干三个人的活”这个投入完全值得。6.2 Builder 模式改来改去就是不对这是最高频的问题之一Builder 输出结果不稳定反复改都达不到预期还不如自己写。排查思路是这样的先确认它有没有“看懂”你的项目。看它生成的代码用没用项目里根本不存在的依赖有没有随意创建你不认识的文件。如果有说明上下文不足。解决办法是用引用关键文件或者把项目规则文件完善一下。再看你的需求描述是不是太模糊。“做一个好看一点的按钮”是没法自动化的但“把按钮背景色改成 #1677ff圆角改成 8px文字加粗悬停时变暗”就非常明确。Builder 不是读心术机器它需要你像写工作流一样把需求说明白。最后分步执行。不要一次让它做一个 2000 行的完整系统而是让它做一个模块验证通过后再做下一个。分步执行时每一步都有清晰的验证点出问题时也好定位。6.3 AI 改了某个文件导致了其他模块报错这是一个非常让人崩溃的场景。AI 改 A 文件结果破坏了依赖 B 文件的 C、D、E 文件。应对办法有几个强烈建议用 Git 做保护。每次让 Builder 动手之前确保当前分支是干净的。它改完后用git diff查看它到底改了哪些文件。如果它动了不该动的文件git checkout瞬间还原损失为零。给它画“禁区”。在项目规则文件里明确写“哪些文件禁止修改”比如配置文件、自动生成文件、CI 脚本等。这样能大幅减少误伤。开启 Diff 审阅模式。Builder 模式执行时我建议不要让它“自动应用所有改动”而是让它在关键节点停下来等你确认。虽然这样效率会低一些但安全感高很多。6.4 和 Qoder 等其他 AI IDE 怎么选最近很多人讨论 Qoder 和 Trae 的对比。我没有必要拉踩只说我的个人体感如果你需要的是一个能频繁使用 Builder 类 Agent 的 IDETrae 的免费策略和功能完整度就比较合适如果你对另一些工具的某些集成能力有特殊需求可以并排试用。我自己的选择逻辑很简单对比了 CodBuddy、Qoder 和 Trae 的 Builder 模式后Trae 的 Builder 从任务拆解到执行到自检的完整度更高。而且它能读取项目规则文件对项目“规矩”的理解更好这对实际工程的帮助比其他工具更明显。6.5 一些很少被提及但很重要的细节联网搜索功能Trae 支持联网搜索。当 Builder 遇到 API 文档不了解时它可以自己上网查。这个功能默认是关闭还是开启我记不太清了建议在设置里确认一下。比如你想让它用某个刚出的新 API就得允许它联网查询不然它只能根据训练数据猜测。代理设置如果你在公司网络环境下使用且网络有特殊配置Trae 可能需要相应的代理设置否则一些搜索、MCP 连接能力可能无法正常工作。这个在不同网络环境里差异很大遇到连不上外部服务的问题优先排查网络配置。快捷键Builder 模式里的“中断”快捷键我建议一定要记住。当发现它改错了越快中断越省积分。长对话的上下文污染Builder 跑完一个任务后如果你马上开始下一个任务建议先开一个新的对话会话把之前的上下文清掉。否则 AI 会把上一个项目的上下文带入新任务导致一些莫名奇妙的“发挥”。我自己现在写项目的流程已经固化成这样打开 Trae加载项目写好规则文件在 Builder 模式下分模块下需求每个模块验证完再继续下一个。碰上复杂的设计稿就用 MCP 读取需要快速看代码就开 CLI提交前让 AI 做一轮 code review。两个月用下来单人维护两三个中小型项目已经不是什么有压力的事了。如果你之前只是把 AI 编程工具当“高级搜索”用我建议你认真试一下 Builder 模式加项目规则的组合让它真正接手一个完整的功能模块试一试。第一次看到它自己拆任务、自己改代码、自己修 bug 的时候那种“整个活终于可以交代出去了”的感觉还是挺奇妙的。
阅读完成 · 觉得有帮助？
)
