1. 我是谁，以及我遇到了什么问题
我是一名 Node.js/TypeScript 后端开发者，日常负责公司内部系统的飞书（Lark）集成开发。最近接手了一个飞书消息推送模块，需要支持：文本消息、卡片消息、批量推送、发送重试、消息模板管理。
痛点：旧代码是一个 800 行的单文件，所有逻辑耦合在一起，没有类型定义，错误处理全靠 try-catch 一把梭。更要命的是，Lark API 的 token 管理逻辑分散在 3 个地方，每次 token 过期都会导致雪崩式重试，API 调用量严重超标。
2. 我是怎么用 TraeCode 解决这件事的
使用模式：IDE 模式 + SOLO 模式混合使用
第一步：代码理解与架构设计（SOLO 模式）
我把整个旧代码文件拖入 TraeCode，用 @Workspace 指令让 AI 先理解现有逻辑：
提示词：
@Workspace 分析这个飞书消息推送模块的代码结构，识别所有问题：代码耦合点、token 管理缺陷、错误处理漏洞，并给出重构方案。
TraeCode 在 30 秒内给出了详细分析：
- Token 管理分散在 3 个函数中，没有统一的过期处理
- 所有 API 调用没有重试机制，失败即抛异常
- 消息模板用字符串拼接，缺乏类型安全
- 建议拆分为：TokenManager、MessageBuilder、LarkClient、RetryHandler 四个模块
第二步：分层重构（IDE 模式）
我按照 TraeCode 的建议，逐个模块进行重构：
// TokenManager - 带缓存的 token 管理
class TokenManager {
private token: string | null = null;
private expiresAt: number = 0;
async getToken(): Promise<string> {
if (this.token && Date.now() < this.expiresAt - 60000) {
return this.token; // 提前 1 分钟刷新
}
const resp = await this.fetchToken();
this.token = resp.token;
this.expiresAt = Date.now() + resp.expire * 1000;
return this.token;
}
}
TraeCode 帮我生成了带 TTL 缓存的 TokenManager，token 过期前 60 秒自动刷新，彻底解决了雪崩式重试问题。
第三步：消息模板类型化
我把旧的消息构建逻辑描述给 TraeCode：
提示词：
将飞书卡片消息构建改为类型安全的 Builder 模式，支持文本、Markdown、按钮、图片等元素
它生成了完整的类型定义和 Builder 链式调用：
const card = new CardBuilder()
.setTitle('构建通知')
.addMarkdown(`**项目**: ${projectName}
**状态**: ✅ 成功`)
.addButton('查看详情', url)
.setColor('green')
.build();
第四步：指数退避重试
TraeCode 帮我实现了带 jitter 的指数退避重试：
async function withRetry<T>(fn: () => Promise<T>, maxRetries = 3): Promise<T> {
for (let i = 0; i <= maxRetries; i++) {
try {
return await fn();
} catch (e) {
if (i === maxRetries) throw e;
const delay = Math.min(1000 * 2 ** i + Math.random() * 1000, 10000);
await sleep(delay);
}
}
throw new Error('unreachable');
}
3. 成果展示
- 代码从 800 行缩减到 480 行，模块清晰、职责单一
- Token 管理统一化，API 调用量从日均 8000+ 降到 3200 左右，降幅 60%
- 消息发送成功率从 94% 提升到 99.7%
- 所有模块通过 TypeScript 严格模式编译，零 any 类型
- 补充了 30+ 个单元测试，核心逻辑覆盖率 92%
4. 效率对比
- 以前：手动梳理 800 行耦合代码至少 2 小时，重构过程中反复改 bug 又花半天
- 现在：TraeCode 30 秒完成代码分析，按模块逐个重构，总共 2 小时完成 + 测试通过
5. 经验和技巧总结
- 先分析再动手：用 SOLO 模式让 AI 先理解代码整体结构，比自己闷头看代码效率高 10 倍
- 模块化重构：不要一次性让 AI 重写全部代码，按模块拆分，每个模块改完验证通过再继续
- Token 管理是 API 集成的关键：飞书 API 有严格的调用频率限制，务必实现带缓存的 token 管理和指数退避重试，否则很容易触发限流