一、我是谁，我卡在哪
我是做 Node.js 后端开发的，日常维护一个内部 CLI 工具，每周需要给团队发发布日报，汇总本周的 commit、PR、issue 情况。之前都是手动整理，从 GitHub 拉数据、分类、写总结，每次要1-2小时，而且容易漏掉关键改动。
二、我用 TraeWork 怎么解决的
模式：Work
具体实践步骤：
第一步：把需求拆解告诉 TraeWork——“帮我写一个 Node.js 脚本，用 GitHub API 拉取本周的 commits、merged PRs、open issues，按类型分类”
TraeWork 立刻给出了基于 @octokit/rest 的方案，还提醒我要处理 pagination（超过 30 条结果要翻页）。
第二步：让 TraeWork 帮我设计 markdown 日报模板，包含：
- 本周合并 PR 汇总（带作者和链接）
- 新增 Issue 分类（bug/enhancement/question）
- 代码量统计（additions/deletions）
第三步：在本地测试脚本时遇到 GitHub API rate limit 问题，TraeWork 帮我加上了 token 认证和缓存机制。
第四步：把整套流程固化成一个可复用的工作流，现在每周一早上运行一行命令就生成日报。
三、提效前后对比
| 环节 | 以前 | 现在 |
|---|---|---|
| 拉取 GitHub 数据 | 20分钟（手动翻页） | 30秒（自动分页） |
| 分类整理 | 40分钟（人工判断） | 10秒（自动标签匹配） |
| 撰写总结 | 30分钟 | 已包含在模板中 |
| 总计 | ~1.5小时 | ~5分钟 |
四、成果展示
产物1：Node.js 数据拉取脚本核心逻辑
const { Octokit } = require('@octokit/rest');
const octokit = new Octokit({ auth: process.env.GITHUB_TOKEN });
async function generateWeeklyReport(owner, repo, since, until) {
const [commits, pulls, issues] = await Promise.all([
octokit.rest.repos.listCommits({ owner, repo, since, until, per_page: 100 }),
octokit.rest.pulls.list({ owner, repo, state: 'closed', per_page: 100 }),
octokit.rest.issues.listForRepo({ owner, repo, state: 'all', since, per_page: 100 })
]);
const mergedPRs = pulls.data.filter(pr =>
pr.merged_at && pr.merged_at >= since && pr.merged_at <= until
);
return { commits: commits.data, mergedPRs, issues: issues.data };
}
产物2：Markdown 日报模板（由 TraeWork 设计）
产物3：完整的 TraeWork 对话执行记录
五、实践经验总结
-
给 TraeWork 提供清晰的输入格式：比如告诉它"用 ISO 8601 格式处理日期"，输出会更稳定，减少后期调整。
-
分步骤执行，不要一次性堆太多需求：我先让它写数据拉取，再写模板渲染，最后做错误处理。每步验证通过后再下一步，比一次性给大任务成功率高很多。
-
注意 API 限制：GitHub REST API 有每小时 5000 次的 rate limit，TraeWork 一开始没加认证，测试几次就触发了限制。记得提醒它加上 token 和缓存。
六、分享你的实操对话
关键对话步骤已勾选分享，主要围绕：
- 第一轮：需求拆解和方案设计
- 第二轮：分页处理和 rate limit 优化
- 第三轮：markdown 模板美化和分类逻辑完善