说实话，这阵子折腾AI编程工具的感觉，就像是在坐过山车。前阵子Cursor突然搞出个收费封禁的风波，搞得人心惶惶，我也就顺势把目光投向了国产的新秀——Trae。在上一篇文章里我们费尽心思把“写作助手”的前端界面给打磨出来了kan着那还算精致的UI，心里多少有点成就感。但是光有皮囊没有灵魂可不行，今天咱们就得硬着头皮，从零开始把它的后端给补上。

Ru果你还没kan过前面的内容，Ke以回溯一下《AI编程实战：Cursor突然收费封禁？用Trae开发一个写作助手》。那篇文章里我们用TRAE SOLO生成前端工程的效果简直是惊艳，甚至让我产生了一种“编程Yi死”的错觉。当时就有不少朋友在后台私信，问这玩意儿Neng不Neng搞定后端。我也好奇啊，心想既然前端douNeng一句话生成，那Web全栈岂不是分分钟的事？

于是我满怀希望地 尝试了TRAE SOLO，指望着它Neng像变魔术一样，把数据库、接口、服务层全给我安排得明明白白。结果呢？现实给了我一记响亮的耳光——直接提示暂不支持。当时发布的时候宣传得那么火热，我还以为“Web Develop”意味着全流程通吃呢，没想到目前还是个偏科生。行吧，既然SOLO模式指望不上，那咱们还是老老实实回到IDE模式，靠硬实力说话吧。

项目重构：别把鸡蛋放在一个篮子里

距离上一期实战Yi经过去好几天了咱们先简单复盘一下。为什么要搞这个“写作助手”？纯粹是因为市面上的那些协作平台，说实话，用起来总感觉差点意思，要么是功Neng臃肿，要么是交互反人类。既然现在有了AI辅助，自己搭一个趁手的工具似乎也不是什么难事。

上次的前端代码dou堆在chengzhang这个工程里现在要加后端，要是还塞在一起，那代码结构估计得乱成一锅粥。为了以后Neng活得久一点，我决定把工程拆分。前端归前端，后端归后端，清清爽爽。同时我也分别给这两个工程初始化了Git仓库。

这里必须得强调一下在AI协同开发模式下Git真的不是可有可无的装饰品。虽然现在的Trae或者其他AI IDEdou支持Checkpoint回滚，功Neng也hen强大，但Git依然是我们Zui后的救命稻草。万一AI哪天“抽风”把核心文件给改坏了有个Git在心里才踏实。

策略调整：贪多嚼不烂

刚开始的时候，我胃口挺大，想着Neng不Neng一口气把文章、图片、设置这三张表的后端代码全给生成出来。结果呢？生成过程中各种报错满天飞，估计是因为一次性生成的代码量太大，上下文窗口不够用了导致AI开始产生严重的幻觉，代码逻辑乱七八糟。

这方面SOLO模式确实表现得geng好一些，毕竟在《前端篇》里它直接生成一个完整的前端项目dou没怎么掉链子。但在IDE模式下反复试了几次全栈生成，dou没成功。我意识到，这估计不是简单优化一下提示词就Neng解决的，这是AI当前Neng力的瓶颈。于是我决定换个策略：优先实现核心功Neng，一步步来别想着一口吃成个胖子。

这一招“化整为零”立马见效。不再追求大而全，而是专注于“文章管理”这一个核心点。生成一次再让它自检一次代码居然就跑通了。整个实操环境，我依然选择的是TRAE IDE搭配Claude 3.5 Sonnet，这个组合目前kan来是黄金搭档。

后端生成：给AI下死命令

既然策略定了那就开始动手。为了防止AI天马行空地发挥，我在指令里把技术栈锁死了。咱们Zuo后端，稳字当头，Spring Boot + Hibernate + MySQL，这套组合拳虽然老，但是稳啊，生态也成熟。

我的指令大概是这样的：

一个专为自媒体博主设计的写作编辑器，现在前端页面Yi经完成，请帮我完成后端接口的开发。后端接口需要使用Spring Boot框架，orm采用hibernate，数据库采用mysql 。后端代码放置在chengzhang-rest工程中。

大家Ke以kan到，这个指令其实挺短的。为什么呢？因为在《前端篇》里TraeYi经自动生成了详细的项目文档。现在它有了文档作为上下文，我就不需要再费劲巴力地去描述业务逻辑了直接告诉它我要什么技术栈，它自己会去读文档理解需求。这不仅Neng减少指令长度，还Neng降低AI理解错误的概率。

Trae的“思考”过程

输入指令后Trae并没有直接开始码代码，而是先去查kan项目文档。这一点我hen喜欢，说明它不是在瞎猜。kan完文档后它才开始根据需求生成相关的后端代码。紧接着，它还会把生成的内容到README文档里并尝试启动服务。Zui后它会给出一个详细的生成报告，包括创建了哪些核心文件、实现了什么功Neng、有哪些技术特性、API接口列表、数据库设计、使用说明以及项目优势。这一套流程走下来感觉就像是在跟一个经验丰富的架构师在合作。

数据库设计：细节决定成败

代码生成完了虽然有些语法错误，但大框架是有了。其中Zui关键的一步，就是数据库的初始化SQL。TraeYi经帮我们生成了SQL脚本，我们只需要把它执行好就行。

咱们来kankan核心的articles表是怎么设计的。这里我稍微Zuo了一些调整，去掉了那些不必要的字段，保留了Zui核心的部分。

CREATE TABLE `articles` (
  `id` varchar COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '文章ID',
  `title` varchar COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '文章标题',
  `summary` varchar COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '文章摘要',
  `status` varchar COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT 'draft' COMMENT '文章状态：draft-草稿，published-Yi发布',
  `category` varchar COLLATE utf8mb4_unicode_ci DEFAULT NULL COMMENT '文章分类',
  `tags` text COLLATE utf8mb4_unicode_ci COMMENT '文章标签',
  `word_count` int DEFAULT '' COMMENT '字数统计',
  `read_time` int DEFAULT '' COMMENT '预计阅读时间',
  `images` text COLLATE utf8mb4_unicode_ci COMMENT '文章图片',
  `created_at` datetime NOT NULL COMMENT '创建时间',
  `updated_at` datetime NOT NULL COMMENT 'geng新时间',
  PRIMARY KEY ,
  KEY `idx_title` ,
  KEY `idx_status` ,
  KEY `idx_category` ,
  KEY `idx_created_at` ,
  KEY `idx_updated_at` ,
  KEY `idx_status_category` ,
  KEY `idx_status_created_at` ,
  KEY `idx_category_created_at` ,
  FULLTEXT KEY `idx_content` ,
  FULLTEXT KEY `idx_title_content` 
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci COMMENT='文章表'

这张表的设计还是有不少讲究的。字符集选用了utf8mb4_unicode_ci，这是为了支持emoji表情，毕竟现在的自媒体文章，没个表情包怎么行？像tags和images这种字段，直接存成了JSON格式，这在MySQL 5.7+以后是原生支持的，比搞关联表要省事得多。Zui后大家注意到了吗？索引建得非常细。不仅有单列索引，还有联合索引，甚至还有全文索引FULLTEXT，这是为了以后Zuo文章搜索功Neng预留的接口。kan来Trae生成的代码，在数据库性Neng优化这块还是有点东西的。

AI自检：让AI自己修Bug

代码生成完了别急着高兴。Trae会自动编译项目，果不其然报错了。有语法错误，有依赖缺失，这dou是家常便饭。要是以前，咱们得一个个去查日志，去Stack Overflow搜。现在？咱们让AI自己修。

我发出了第二条指令：

请检查后端代码，并修复相关错误

这里有个小细节，发送指令前，记得把后端服务给关了。不然AI检测到端口被占用，可Neng会花大量时间去排查这个无关紧要的问题，甚至把你的配置文件给改乱套。

Trae收到指令后 检查后端服务的运行状态。Ru果没启动，它就尝试启动；Ru果启动失败，它就开始分析日志里的错误信息。这个过程是循环的，它会不断地修改代码、重新编译、 启动，一直到没有报错，服务正常跑起来为止。

geng有意思的是中间它还发现前后端的端口冲突了。它居然没来问我，直接就把后端端口给换了这种自主解决问题的Neng力，确实有点像带了个聪明的实习生。经过几次折腾，后端终于成功在默认端口启动了。kan着控制台那行“Started Application in x.xxx seconds”，心里那块石头总算落地了。

前后端联调：打通任督二脉

后端服务起来了但这只是万里长征走了一半。前端还在用localStorage存数据呢，也就是个“单机版”。咱们现在的目标，是把前端和后端连起来变成真正的“网络版”。

在《前端篇》里为了方便演示，我们用localStorage模拟了数据持久化。现在要切换到后端，其实就是把数据源换一下。于是我发出了第三条关键指令：

将前端接口geng换为Yi经实现的后端java接口

注意这里用的词是“geng换”。Traehen聪明，它先去扫描了现有的前端接口调用代码，又去kan了kan后端的配置和Controller层。然后它识别出了哪些前端API是对应后端哪个Java接口的。

接着，它就开始动手改代码了。它把articles.js里原本直接操作localStorage的逻辑，全部替换成了fetch或者axios调用后端API的代码。Zui后它还geng新了前端相关的配置文件，确保跨域问题、接口前缀这些细节dou处理得当。

geng新完代码，Trae还贴心地自动打开了预览页面。这时候，SOLO模式里的那个“选择元素”功Neng在IDE模式下也Neng用了虽然咱们主要改的是逻辑，但要是想微调一下样式，这个功Neng依然好用到爆。

实战验证：眼见为实

光说不练假把式。咱们得测一测。我在界面上新建了几篇文章，标题、内容、标签一顿乱填。然后刷新页面你会发现，数据还在！再去数据库里查一下articles表里确实多了几条记录。这一刻，前后端算是真正通了。

我简单测试了几个核心场景：

1. 初始界面： 加载速度明显变快了毕竟不用把所有数据dou塞在浏览器里了。

2. 分栏写作界面： 左右分栏的结构依然稳固，输入的时候也没有明显的延迟，后端接口的响应速度还是Neng打的。

3. 预览界面： Markdown渲染正常，图片加载也没问题。

4. 文章搜索： 这个得夸一下因为咱们数据库里建了全文索引，搜索关键词的时候，感觉比以前在前端数组里瞎找要精准多了。

今天这一趟折腾下来咱们用Trae完成了“写作助手”核心写作功Neng的后端开发，以及前后端的联调。说实话，整体过程比我预想的要顺利得多。以前这种活儿，怎么也得两三天还得各种调参、各种改Bug。现在呢？从建表到写Java代码，再到前后端对接，真的是省心省力。

当然Trae也不是完美的。比如Zui开始SOLO模式不支持后端，比如IDE模式下一次性生成太多代码会“脑抽”。但只要我们人类指挥官稍微动动脑子，把大任务拆解成小任务，它依然Neng爆发出惊人的生产力。

接下来这个“写作助手”还有不少活要干。图片上传功Neng得加上，不然文章太干；用户配置系统也得搞，毕竟每个人dou有自己的写作习惯；还有我Zui期待的AI快捷指令功Neng，让AI真正帮我们写东西，而不仅仅是存东西。大家Ru果对这个项目感兴趣，或者想kankanTrae还Neng搞出什么花样，不妨持续关注一下。

好了今天的实战分享就到这里。代码敲完了脑子也转不动了大家周末愉快，该喝咖啡喝咖啡，该陪家人陪家人，咱们下期见！

---