夜雨聆风我为什么用 Trae + HBuilderX + IDEA 三开
「AI 编程时代，选 IDE 不再看补全准不准，而是看能不能把项目上下文喂给 AI。」
这是折腾一周后，我对编辑器选择这件事最大的认知转变。
写在前面
写完前三篇需求文档，我终于要开始写代码了。
但第一个拦路虎不是代码本身，而是——用什么编辑器写。
听起来很无聊对吧？编辑器能写代码就行，有什么好纠结的。但放在「AI 编程 + 跨端 App」这个组合下，这个问题意外地复杂：
想用 AI 辅助编程，就得用 AI 友好的 IDE
App 是 UniApp 写的，真机调试离不开 HBuilderX
后端是 Java + pig 框架，IDEA 才是 Java 的主场
一个项目横跨前端 / 后端 / 移动端三套技术栈，单靠一个 IDE 搞不定
折腾了一周，我最终稳定在 Trae + HBuilderX + IDEA 三开 的组合。这篇就把选型过程和踩过的坑记录下来，给同样在纠结的同学一个参考。
一、AI 编程时代，IDE 的角色正在变化
1.1 传统 IDE 的核心价值
过去我们选 IDE，看重的是这几样：
代码补全（基于语言服务）
跳转 / 引用查找
重构工具
调试器集成
插件生态
VS Code 凭借插件生态一统江湖，WebStorm 凭借重构能力守住 Java / 前端专业用户，IDEA 则是 Java 开发的事实标准。
1.2 AI 时代的新核心：上下文
但 AI 编程改变了权重分布。现在写代码，最关键的不是「这个 IDE 补全准不准」，而是——这个 IDE 能不能把项目上下文喂给 AI。
AI 写代码的能力取决于三件事：
模型能力：模型本身有多强
Prompt 工程：你怎么问
上下文投喂：你把哪些代码 / 文档 / 规则喂给它
前两件事跟 IDE 关系不大，第三件事完全取决于 IDE。一个不能把项目代码喂给 AI 的 IDE，在 AI 编程时代就是残废。
1.3 IDE 的新角色：AI 的「投喂员」
所以新一代 AI IDE 都在这件事上卷：
Cursor 把整个仓库索引进向量库，让 AI 能搜到相关代码
Trae 内置 Builder 模式，能读取整个项目并自主修改多文件
VS Code + Copilot 走的是「当前文件 + 主动选择」的轻量路线
我用过的体验排序：Trae ≈ Cursor > Copilot。但具体选哪个，还要看你的项目类型。
二、候选对比：5 个主流编辑器
2.1 VS Code + GitHub Copilot
优点
插件生态最丰富，几乎所有语言都有支持
Copilot 便宜（10 美元/月），日常补全够用
用户基数大，问题随便搜得到答案
缺点
Copilot 是「行级补全 + 聊天」模式，不会主动改多个文件
跨端调试体验一般，UniApp 真机调试得装 HBuilderX 插件，体验稀烂
不适合「一次写一个模块」这种批量任务
适合场景：单语言项目、小项目、不想折腾的人。
2.2 Cursor
优点
AI 编程体验的标杆，Agent 模式写代码很爽
Cmd+K 选中代码直接改，交互流畅
项目上下文索引做得最好
缺点
20 美元/月，偏贵
对 UniApp 的真机调试支持一般，最终还是得开 HBuilderX
国内访问慢，经常需要代理
适合场景：纯前端项目、海外用户、不在乎成本的人。
2.3 Trae
优点
字节出品，国内访问快
Builder 模式很强，能自主完成「读需求 → 改多文件 → 跑测试」的完整流程
免费（至少目前是）
内置 Skill 系统，可以封装常用操作
缺点
上线时间短，部分细节不如 Cursor 打磨
真机调试依然要靠 HBuilderX
社区文档少，遇到问题得自己摸索
适合场景：国内开发者、AI 编程重度用户、追求免费工具的人。
2.4 HBuilderX
优点
UniApp 官方 IDE，真机调试体验独此一家
启动快、占用低
内置 uni-app 编译器，不用折腾环境
缺点
AI 能力几乎没有
代码补全弱，跳转 / 重构不如 VS Code
插件生态小
适合场景：UniApp 项目真机调试、打包发布。不适合作为主力编码工具。
2.5 IntelliJ IDEA
优点
Java 开发的事实标准，重构 / 调试 / Spring 支持无敌
pig 框架的代码生成器在 IDEA 里跑得最顺
数据库工具内置，不用额外装 DataGrip
缺点
占用大，启动慢
AI 助手是 JetBrains AI Assistant，国内体验一般
不适合写 Vue / UniApp
适合场景：Java 后端开发。
2.6 对比表
三、我的最终方案：三开
3.1 三个 IDE 各司其职
经过反复试错，我的稳定组合是：
选择 Trae 作为主力，除了功能契合度高，还有两个现实因素：一是它提供免费模型额度，日常开发够用，只是用多了偶尔需要排队；二是火山方舟刚推出的 Agent Plan 套餐，前两个月每月 49 元，也想试试看这个套餐的实际使用体验能支撑多久。
| 85% | ||
| 5% | ||
| 10% |
3.2 为什么不再需要 HBuilderX 常驻
HBuilderX 现在提供了命令行工具，新的 Vue3 uniapp 项目能直接用命令行启动。日常的「真机调试 / 预览」可以由 Trae 在沙盒里跑命令完成，HBuilderX 退化成「打包发布专用」——只有出 App 安装包时才打开一次。
IDEA 也退到二线，只负责 maven 依赖管理和打包部署。Java 这部分体量大，Trae 暂时还顶不上，但日常的代码编写已经不需要切到 IDEA 了。
3.3 工作流：告诉 IDE 要什么，剩下的它自己跑
项目根目录下预先建好三个子目录：
uniapp-ui/App 端（Vue3 + UniApp）
server/Java 后端（Spring Boot）
server-ui/管理后台（Vue3）
然后只需要告诉 Trae 要开发什么功能，它会自己走完整条链路：
1生成前端页面 —— 按要求在 uniapp-ui 或 server-ui 里生成 Vue 组件
2生成后台接口 —— 根据前端页面用到的字段，在 server 里生成 Controller / Service / Mapper
3接口联调 —— 按项目 api 封装格式，让前端调用后端接口
4命令行启动 —— HBuilderX CLI + npm 脚本，Trae 在沙盒里把项目跑起来
5读日志自修复 —— Trae 读取命令行日志，发现报错自动定位修复，循环直到跑通
这样的好处
AI 编辑器同时知道「要做什么页面、要写什么接口、怎么对接起来」，全链路在一个工具里闭环，不用在三个 IDE 之间来回切换。IDEA 只在需要 maven 依赖管理 / 打 jar 包 / docker 部署时才上场。
关键是整个闭环由 IDE 自己驱动——它启动项目、它读日志、它修 bug。人只负责提需求和验收结果。
四、AI 编程的正确打开方式
选好了 IDE，接下来是怎么用。AI 编程不是「让 AI 写代码，我看着」，而是有一套方法论。
4.1 Prompt 工程：怎么问 AI
很多人用 AI 写代码就是一句话：「帮我写一个登录页面」。这种问法得到的结果通常是——能用，但很平庸。
正确的 Prompt 应该包含：
目标：要做什么
约束：用什么技术栈、什么风格、不能做什么
上下文：相关的已有代码、设计文档
输出格式：要完整文件还是片段、要带注释还是不带
举个例子，我让 AI 写一个 Todo 列表组件的 Prompt：
帮我写一个 UniApp + Vue3 的 Todo 列表页组件。 要求： 1. 使用 <script setup> 语法 2. 列表项显示：标题、优先级标签、截止时间、完成状态勾选框 3. 优先级用颜色区分：low 灰、medium 蓝、high 橙、urgent 红 4. 截止时间用相对时间显示（今天 / 明天 / 3 天后 / 具体日期） 5. 已完成的任务标题加删除线 6. 点击列表项跳转详情页 7. 数据从 API 拉取，API 文档见 attached 文档 技术栈约束： - UI 用 uView Plus（已经全局注册） - 状态管理用 Pinia - 不要用 Composition API 的 ref，全用 reactive
这种 Prompt 出来的代码，几乎可以直接用。
4.2 上下文投喂：把项目「喂」给 AI
AI 不知道你的项目结构，不知道你的代码风格，不知道你用了什么库。这些都得你告诉它。
Trae 的几种投喂方式：
@文件：直接引用项目里的某个文件
@文件夹：把整个文件夹的代码都喂进去
粘贴文档：把 API 文档、设计稿、需求文档直接粘贴到对话里
Builder 模式：让 AI 自主读取整个项目，自己找相关文件
我的习惯是先投喂再提问。比如要改一个组件，先 @ 这个组件和它依赖的几个文件，再开始提问。AI 有了上下文，回答质量高一个量级。
4.3 Skill 调用：封装重复操作
Trae 有个 Skill 系统，可以把常用的操作封装成「技能」让 AI 调用。比如我封装了几个常用的 Skill：
「生成 CRUD」：输入表名，AI 自动生成 Entity / Mapper / Service / Controller / Vue 列表页 / 表单页
「生成 API 文档」：扫描 Controller，输出 Markdown 格式的 API 文档
「检查代码风格」：扫描代码，按预设规则检查命名 / 注释 / 结构
Skill 的好处是复用。第一次写 Prompt 花了 20 分钟，封装成 Skill 之后，以后每次调用只要 1 分钟。
五、一个真实案例：让 AI 一次写完一个 CRUD 模块
光说不练假把式。下面是一个真实案例，我用 Trae 让 AI 一次写完了「笔记分类」模块的完整 CRUD。
5.1 模块说明
「笔记分类」是一个典型的 CRUD 模块，包含：
后端：Entity / Mapper / Service / Controller
前端：列表页（带搜索、分页）+ 表单页（新增 / 编辑）
数据库：
note_category表
5.2 操作步骤
第一步 · 投喂上下文
我在 Trae 里 @ 了这些文件：
docs/pig-note后端模块规划设计.md（说明表结构）
pig-note-backend/.../entity/SysDict.java（参考实体类风格）
pig-note-frontend/.../note-ai-organized/index.vue（参考列表页风格）
第二步 · 写 Prompt
参考上面三个文件，帮我生成「笔记分类」note_category 的完整 CRUD： 后端： - Entity：NoteCategory - Mapper：NoteCategoryMapper - Service：NoteCategoryService + NoteCategoryServiceImpl - Controller：NoteCategoryController（REST 风格，路径 /note/category） 字段： - id: bigint - name: varchar(64) - icon: varchar(255) - sort_order: int - create_time, update_time, create_by, del_flag（pig 框架标准字段） 前端： - 列表页：列表 + 搜索（按 name）+ 分页 + 新增按钮 + 编辑 / 删除按钮 - 表单页：新增 / 编辑，字段 name / icon / sort_order 风格参考 note-ai-organized 模块。
第三步 · 让 AI 自主执行
Trae 的 Builder 模式会自己读项目结构，自己创建文件，自己写代码。整个过程大概 3 分钟。
第四步 · 人工 review
AI 写完之后，我快速扫一遍：
字段类型对不对（比如
del_flag应该是char(1)不是tinyint）Controller 路径对不对
前端 API 调用路径和后端对不对得上
命名风格一致不一致
通常会改 5-10 处小问题，改完就能跑。
5.3 效果对比
结论： 对于 CRUD 这种「模板化、重复性高」的模块，AI 是降维打击。但对于复杂业务逻辑，还是得人主导，AI 辅助。
六、几个真实的坑
6.1 HBuilderX 真机调试的坑
HBuilderX 的真机调试有时候会「假死」——手机上 App 没反应，但 HBuilderX 显示「已连接」。排查下来发现是「手机开发者选项」里的「USB 调试」被系统自动关了。
解决方案：每次调试前先在手机上确认 USB 调试还开着。
6.2 Trae 项目索引的坑
Trae 第一次打开项目会建索引，这个过程可能要 5-10 分钟。如果你在索引没建完的时候就提问，AI 会找不到相关文件，回答质量暴跌。
解决方案：打开项目后先泡杯茶，等右下角索引完成的提示再开始用。
6.3 三个 IDE 同时开的内存占用
IDEA + Trae + HBuilderX 一起开，内存占用轻松 4G+。我的 16G Mac 经常风扇狂转。
解决方案：
IDEA 关掉不用的插件（比如 Android Support）
HBuilderX 用完就关，不常驻
Trae 是主力，一直开着
七、写在最后
工具是手段，不是目的。我花了一整篇文章讲编辑器选择，不是因为这个事情有多重要，而是因为——选错工具，会持续地拖累你。
如果你也在做 UniApp + Java 后端的项目，我的建议是：
主力 AI 编程：Trae（免费、国内访问快、Builder 模式强）
UniApp 调试：HBuilderX（独此一家，别折腾）
Java 后端：IDEA（事实标准，没有替代）
如果你只做前端，Trae 一个就够。如果你只做 Java，IDEA 一个就够。三开是「全栈 + 跨端 + AI」这种复杂场景下的妥协方案。
下一篇会讲技术选型背后的考量：为什么坚持上 Spring Boot 4 + Spring AI 2.0，以及这些选择带来了什么代价。
系列文章导航
第 1 篇 · 一个人也要把需求画清楚 →
第 2 篇 · 给 AI 一份能看懂的需求 →
第 3 篇 · Todo 功能详细规划 →
第 4 篇 · 编辑器选择困难症（本文）→
第 5 篇 · 技术选型与依赖清单（下一篇）→