使用 Trae AI 开发，这 7 条经验帮你少踩一半的坑 🛠️

“

用了大半年，踩坑无数。今天把这 7 条血泪经验全盘托出。

📖 先说背景

最近的主力 AI 编程工具是 Trae。

选它的理由很简单——我在用火山引擎的大模型。

实际工作中，代码开发的大头已经交给了 AI。但它写出来的代码毛病也很明显：前后逻辑不连贯，能用归能用，质量属实一般。所以开发者的角色变了——不再是逐行敲代码，而是把控方向、随时纠偏。

下面这 7 条经验，都是我一行一行代码踩出来的。

一、🔁 把重复踩的坑，打包成 Skill

先看一张使用截图：

用了一段时间后，我发现一个让人很头疼的现象：

大模型对基础问题特别容易"失忆"。

你提醒过它一百遍的事情，它照样忘给你看。在我的项目里，最典型的就是后端模块的启动——IDEA 里点一下就能搞定，到了 AI 纯命令行那儿，启动 10 次挂 8 次。

怎么办？把经验写成 Skill。

我单独开了个目录，把这些反复出现的问题总结成一条条 Skill。每次开新任务，先让 AI 自动去读一遍。说实话，就算这样也不能保证 100% 不出错，但相比之前，出错率下降了不止一个数量级。

想想看：要是 AI 每天都在重启模块、数据库连接、代码规范、Git 提交这些鸡毛蒜皮的事上反复犯错，整体效率得拉低多少？

再举一个具体的例子——数据库查询。

AI 总习惯去翻本地 yaml 文件找数据库连接信息。但实际情况是，真正的配置全在服务器上的 Nacos 里。它在错误的方向上翻了无数次之后，我让它自己总结了一版 Skill：

“

💡 配一个 MCP 也能解决，但整合成 Skill 更直接——生成一个 Skill，只需要一句话。

而且 Skill 支持全局添加，也可以按模块拆分管理，非常灵活。

二、🔐 Git 是你的后悔药

这句话我放在前面说，而且加粗说：

“

⚠️ 无论如何，一定要提交 Git。

尤其是当 AI 搞不定某个功能，代码已经被它改得面目全非的时候——Git 是你唯一的退路。

AI 写的代码，有时候是真的优雅，干净得让你想鼓掌。

但也有的时候，写得跟……算了，不形容了。

所以，人工至少扫一眼。我每次提交后都会过一遍 diff。

因为你永远猜不到 AI 会写出什么神奇的东西。有些写法的清奇程度，让我都忍不住感慨："又学到了，原来代码还能这么写。"

以下是我的 Git 提交流程 Skill：

三、📝 提示越清晰，AI 越听话

这条算不上新鲜，但执行起来很多人会偷懒。

我的经验就一句话：

“

永远不要指望 AI 完全理解你。

我在工作区里建了一个 xx-doc 目录。拿到原始需求后，第一件事不是让 AI 直接写代码，而是先让它生成一份设计文档。

后面需求有调整、有新增，AI 会自己同步更新文档。等开发跑偏的时候，让它重新读一遍文档，就能火速拉回正轨。

需求稍微复杂一点的，我还会亲自看一眼它写的设计文档，确认方向没偏。这一步花不了几分钟，但能省掉后面几个小时甚至几天的返工。

四、🧠 模型也要"因材施教"

不同模型，擅长的事不一样。

有的天生适合推理，有的码代码一把好手。

我现在养成的习惯是：接到需求的时候，先大致估一下难度。

• 日常的 CRUD → auto 模式，够用了
• 复杂逻辑、核心链路 → 切高性能模型

就这么简单。

只能说，贵的模型确实有贵的理由。在真正吃算力的场景下，差异是很明显的。

五、🪝 Hooks：好用，但 AI 配置起来是真费劲

Trae 的 Hooks 和 Claude 的功能完全一致，甚至能直接导入 Claude 的 Hooks 配置。

我的需求很明确：后端代码提交和推送时，自动执行一次代码格式化。

听起来简单对吧？我让 AI 自己来配。

然后就开始了一场拉锯战——确认是不是用 google-java-formatter、加白名单、排查路径依赖……

中间最崩溃的是，AI 会突然来一句："等等，我好像理解错了。"

“

😫 那一刻，头皮发麻。

问题在于：AI 的实现思路，跟你想的经常是两条完全不交叉的路。

但结果是好的——

折腾了大半天，功能搞成了。

六、🧹 代码质量，还是要靠你定规矩

AI 代码的质量方差很大。

有时候写得很漂亮，有时候就很敷衍。我后来琢磨了一下——可能是老代码里过时的写法太多，AI 参考了老代码，所以也跟着写出了一些"上古风格"的实现。

举个例子 🌰：

获取当日日期，我习惯用 Hutool 的 LocalDate API。AI 给我整的是 SimpleDateFormat：

SimpleDateFormat sdf = new SimpleDateFormat(format);
Date dt = sdf.parse(dateStr);

说实话，这个规范我已经写成 Skill 了——

但执行效果只能说一般，我也不确定是不是我用的方式有问题。

还有一个常见毛病：AI 写常量喜欢到处散落，而不是收拢到一个常量类里。

所以我的阶段性结论是：

“

🎯 让 AI 写代码之前，先给它一组约束。 明确开发规范、指定优先使用的工具类。

这块我还在持续摸索，有心得再分享。

七、🌀 当 AI 开始"绕圈"

AI 有一个特别"敬业"的习惯：

“

不管能不能解决问题，它一定会给你一个回应。

有时候它是真的理解了。但更多时候，是你给的资料让它误以为"破局的方向就在前面"——于是，AI 变成了一头倔驴。

用了几个月，我观察到：当权限完全放开之后，AI 很容易陷入逻辑死循环。

说一个我亲身经历的场景——

有一次，我让它排查一个问题。

等了 30 分钟，还没动静。我打开它的思考过程一看，绷不住了：

排查 → 确定方向 A
     → 自我怀疑，排除 A
     → 重新推理
     → 再次确定方向 A
     → 继续怀疑 A
     → 排查 → 确定方向 A → ……

如此反复，循环了好几遍。

“

🌀 原地转圈，乐此不疲。

这时候，只能人工打断。要么等它超时，要么等 5 小时的使用频率限制把它拦下来——但哪个都够呛。

✨ 写在最后

现阶段，人机协同还是王道。

AI 确实已经扛起了大部分代码工作，这一点毋庸置疑。

但方向盘，还是得攥在人手里。

“

方向人把，细节 AI 干——这就是目前最实在的合作姿势。

以上，是我这几个月用 Trae 做实际开发的真实经验。如果你也在用 AI 写代码，希望这 7 条能让你少走点弯路。