上一次，借助 Trae 复现一个线上问题并寻求方法最终解决一个 Request header is too large 问题算是对 Trae 有了初步了解。
这次，从头开发一个项目，看看 Trae 表现如何。在这之前，翻阅了一下掘金小册，看看 Trae 的前端工程师是如何理解 Trae 的产品能力的。
1、Trae 开发者视角的介绍
这里重点关注 AI 编码应用层，当前主流产品的构建思路一般就是插件与 Native 两种。这有点类似于 Electron、Flutter 等跨平台技术与 Android 原生开发的关系。
对于 Java 生态来说，IDEA 自然是绕不过的高墙，使用插件开发效率高上线快，不需要解决跨平台问题，这都由 IDE 本身来完成。像通义灵码、MarsCode 都是这个思路，IDE+插件。但问题就是受限于 IDE API 能力，感知上下文能力有限，性能自然也要受损。
而桌面端 VSCode 基于 Electron 开发，Electron 中有两个核心进程：主进程和渲染进程。主进程是一个 Node.js 进程，用于提供一些系统级的 API，例如 I/O 操作；而渲染进程是一个浏览器进程，用于视窗中元素的渲染，IDE 的原生 UI 能力会直接基于主进程与渲染进程中的 IPC 通信完成。
于是，Cursor、Windsurf 等选择了做 AI Native IDE。重新开发一个 IDE 成本高昂，好的选择自然是借助 VSCode 的开源生态完成，于是就有了这些「魔改」的 VSCode。Trae 对标 Cursor 也是遵循了同样的思路。
至于 Trae 的能力，目前主要有 Chat 和 Builder（Beta） 两种。Chat 又分为 Inline Chat 和 Side Chat，在上一篇中都有体验到。这种对话式的 AI 交互方式还是沿用自 ChatGPT 刚发布时的习惯，与开发流程没有过深结合。虽然上下文引用、图片上传、静默补全都是不错的交互方式，但毕竟没有完全接管工作区，没法和 AI 插件拉开距离。
所以我认为真正有可能颠覆开发模式的是 Builder 模式，它的成熟形态应该是接管工作区，也就是接近自动驾驶水平。开发者是关键决策者，不断决策 Apply 还是 Deny，并快速验证决策结果，形成决策循环。这就和 TDD 思路不谋而合。
因此，继续深入 Builder 模式，才是体现 IDE 用户体验的关键。当然这很难，Cursor 和 Windsurf 离 IDEA 这样的 IDE 仍然还有不小差距，Trae 也要坚持努力。
2、一小时仿造一个掘金主页工程
那么，就从仿造一个掘金主页继续吧。
至于为什么是一小时，来自于小册标题给的时间，一小时可以简单完成一个登录、文章管理这样的模块。我就从生成一个主页开始。
使用 Builder 模式，模型选用 Claude-3.5-Sonnet。考虑到后台我更熟悉 Java 这块，于是指定使用 Spring Boot 框架生成后台程序。Trae 巴拉巴拉一口气创建了十几个文件。
Spring Boot 依赖也添加了不少，security、jpa、jwt。还加入了 MySQL 依赖，为了减少外部依赖我让它替换成内存数据库，这样前端一个进程、后端一个进程就可以跑起来了。
工程初始化过程应该算是结束了，下面到了花费时间最长的解决编译报错问题。不断编译不断报错不断引用错误提问，大概经历了二十轮左右编译通过并可以正常运行了。
我还问它是否可以替换前端技术选型，有意思的是还蛮坚持使用 React 的，不知道是 Claude 还是字节的调校结果。
看下最后的前端效果，额，提升空间还蛮大的。毕竟是通过掘金主页地址提问的，上传图片一直失败。
3、使用小结
使用 Spring Boot 后端、React 前端、内存数据库与 Mock 数据简单生成了一个仿掘金主页的 Web 工程。除了配色和标签，如果没有稀土掘金几个字估计是认不出这是仿的哪个网站设计。如果使用上 Claude-3.7-Sonnet 或者能成功上传图片重新设计估计会好许多。
但这已经能够看出一些成效的，一小时给出这个前端效果效率上应该超过了很多 UI/UE+前端开发了。没错，我说的就是起步开发效率，至于迭代效率还有待进一步验证，毕竟大多数时间接触的都是遗留系统。
耗费的时间，一方面是访问模型的不稳定经常出现服务异常，另一方面针对编译错误如果没有专业知识直接引用错误对话解决成功率并不高。
至于视觉还原度是下一步尝试的方向，同时结合数据库可以实现一些存储能力，让子弹飞一会儿。
