Workbuddy + Trae 使用实战笔记（一个 C# 开发的真实体验）

最近在尝试把 AI 工具真正用进日常开发里，不是那种“写两行 demo”的用法，而是希望它能参与到完整开发流程。

目前主要在用两样东西：Workbuddy + Trae，这里简单记录一下实际使用感受，给有类似想法的人做个参考。

---

一、为什么会同时用两个工具？

一开始我也只用一个 AI（类似 ChatGPT / Copilot 这种），后来发现一个问题：

👉 它们更像“助手”，而不是“参与开发流程的人”

比如：

• 能帮你写函数，但不会帮你规划模块
• 能回答问题，但不会持续跟踪一个任务
• 上下文一长，就开始跑偏

所以后来尝试分开用：

• 一个负责“想清楚怎么做”
• 一个负责“把代码写出来”

---

二、Workbuddy：更像一个“会思考的记录本”

Workbuddy 给我的感觉，不是写代码的工具，而是：

👉 用来整理思路、拆任务、维持上下文

我一般这样用它：

1. 拆需求

比如我有个需求：

做一个日志分析工具（C#，上位机用）

我会先丢给 Workbuddy，让它帮我拆：

• 日志结构设计
• 解析逻辑
• UI 展示方式
• 性能问题（大文件）

它给出的东西不一定完美，但有个好处：

👉 比我自己从 0 开始想要快很多

---

2. 持续记录上下文

这个其实挺关键的。

有些工具聊几轮就“失忆”了，但 Workbuddy 更像：

👉 一直在同一个“项目上下文”里

比如我后面再问：

• 日志解析慢怎么办
• UI 卡顿怎么处理

它能接着前面的内容继续分析，而不是重新来一遍。

---

三、Trae：更偏“动手能力”

Trae 的定位就很明确：

 直接在代码层面干活

我主要用它做几件事：

1. 写基础代码

比如：

• 类结构
• DTO
• 工具类
• 简单算法

优点是：

 省时间，但前提是你自己要知道要什么

---

2. 改现有代码

这个比“从零写”更有价值：

• 改同步 → 异步
• 拆方法
• 加缓存
• 优化循环

有时候我会直接说：

“这一段太慢了，帮我优化一下”

它给的方案不一定最优，但通常是一个可以继续改的起点。

---

3. 修一些常规 bug

比如：

• 空引用
• 边界问题
• 简单逻辑错误

这种它处理起来还是挺快的。

---

四、实际工作流（我现在基本这么用）

目前比较顺的一种方式是：

1️⃣ 先用 Workbuddy 理清楚

• 这个功能要拆成哪几块
• 每块大概怎么做
• 有没有明显风险点

---

2️⃣ 再用 Trae 写代码

• 一块一块实现
• 不追求一次写完
• 边写边改

---

3️⃣ 遇到问题再回 Workbuddy

比如：

• 性能瓶颈
• 架构是否合理
• 有没有更简单的实现方式

---

👉 本质就是来回切：

思考（Workbuddy） ↔ 执行（Trae）

---

五、一些比较真实的感受

说点实际的，不吹：

👍 有用的地方

1. 减少“从 0 开始”的压力
   • 特别是新功能或新项目
2. 代码起步更快
   • 基础结构不用自己手写
3. 思路更容易展开
   • 有时候它会给你一个你没想到的角度

---

👎 不太行的地方

1. 不能完全依赖
   • 复杂逻辑还是要自己兜底
2. 有时候会“自信但错误”
   • 需要你能看出来哪里不对
3. 上下文一乱就容易跑偏
   • 需要自己控制节奏

---

六、几个使用上的建议

算是踩坑总结：

1. 不要一口气让它做完整系统

这种基本都会翻车：

“帮我写一个完整项目”

建议：

👉 拆小任务，一块一块来

---

2. 自己要有基本判断能力

AI 写的代码：

• 能用 ≠ 合理
• 能跑 ≠ 可维护

---

3. 控制上下文很重要

• 一次只解决一个问题
• 不要在同一段对话里混很多需求

---

七、总结

如果简单说一句：

Workbuddy 更像“帮你想”，Trae 更像“帮你做”

这套组合不是说有多神，但在实际开发里：

确实能减少一些重复劳动，让节奏更顺一点

---

如果你也是做 C#、上位机或者工具开发的，可以自己试试这种搭配，看看适不适合你自己的工作方式。