Daily Report

日报自动生成

参数

调用时需要提供四个参数（位置顺序）：

如果用户没给全参数，逐一追问补全后再开始。

执行流程

Step 1: 拉 commit

cd <repo> && git log --format="%h %ad %s" --date=short --since="<commit_from>" --until="<commit_to+1天>" --all

注意 --until 需要 +1 天，因为 git 的 --until 是开区间。

Step 2: 过滤

跳过以下 commit（不写进日报）：

• fmt / fmt: / chore: fmt — 纯格式化
• chore: update cpp-infra submodule — 子模块指针更新
• chore(spot): sync test code with ... — 测试代码同步
• build: 类无业务影响的构建配置微调
• 其他一眼看去没有业务逻辑改动的 commit（如 fix typo、rename X→Y 且改动量 < 5 行）

判断标准：这个 commit 写到日报里，领导看了会觉得你在干活吗？ 如果答案是"不会"，跳过。

Step 3: 按主题分组

把过滤后的 commit 按业务主题分组，不按日历日。分组原则：

• 同一个大目标下的多个 commit 归为一组（如 "domain/strategy/adapter 三层去默认值" 是多个 commit，但归一组）
• 每组要足够大，能撑起一天的工作量
• 如果组太少（比如只有 3 组但要写 6 天），允许把大组拆成两个子项分到相邻两天
• 如果组太多（比如 8 组但要写 6 天），把小组合并到大组里当细节

Step 4: 均分到报告日期

• 有多少天报告日期（report_from 到 report_to 的天数），就输出多少天的日报
• 每天最多两条工作项（detail bullet 不超过 2 个）
• 关键约束：每天必须看起来有足够的工作量。如果某个主题单独放一天显得太轻（比如"全量重命名"），把它合并到相邻更有实质内容的一天，作为那天的细节一笔带过
• 用 date 命令算出日期列表：

  # 计算日期范围
  start=$(date -d "<report_from>" +%s)
  end=$(date -d "<report_to>" +%s)
  while [ $start -le $end ]; do
    date -d "@$start" +%Y-%m-%d
    start=$((start + 86400))
  done
  

Step 5: 写文件

输出到 <repo>/../report/<report_from>_<report_to>.md（即 repo 同级目录的 report/ 下）。

输出格式

紧凑模式：行间只用单个 \n，不插入空行。 日期行紧跟前一天最后一行，段标题紧跟日期行，内容紧跟段标题。

YYYY-MM-DD
1. 今日工作完成情况
- 推进 [mold spot C++ 代码优化] 一句话概括当天做的最主要的事
-- 细节一：做了什么、为什么做、关键结果
-- 细节二：同上
2. 明日工作计划
- 推进 [mold spot C++ 代码优化] 下一句话（接下一日的内容）
YYYY-MM-DD
1. 今日工作完成情况
...
YYYY-MM-DD（最后一天）
1. 今日工作完成情况
...
2. 下周工作计划
- 推进 [mold spot C++ 代码优化] 下周计划（如果有已知的后续工作就写，没有就留个方向性的）

写作规范

1. 大白话 — 像跟同事聊天一样写，不堆技术名词。curl 替换为 httplib 比 替换 HTTP 客户端底层实现为 cpp-httplib 库 好。
2. 精简 — 每天不超过两条 detail bullet。只说最关键的事。小的代码优化不提。
3. 有因果 — 每条 detail 说清楚：做了什么 → 解决了什么问题 → 结果是什么。
4. 避免空洞词 — 不写"优化了代码结构""改进了系统稳定性"这种没信息量的话。写具体的东西。
5. 不暴露轻量工作 — 像"全量重命名""补充注释""格式化"这类工作，如果确需提及，只能作为某条 detail 的前半句铺垫（"完成术语统一后，"），不能独立成条或成天。
6. 项目名保持一致 — 主 bullet 的 [mold spot C++ 代码优化] 标签不动，除非用户要求改。
7. 去 AI 味 — 禁止以下写法，写完必须逐条自查：
   • ❌ 夸张形容词/副词："一眼可见""彻底""完全""极大""显著""完美""丝滑"
   • ❌ 自我表扬："顺手修了""轻松搞定""自然就解决了"
   • ❌ 宏大叙事："基石化改造""大重构""铺平道路""奠定基础""为后续XX彻底扫清障碍"
   • ❌ 无信息量的感慨："改完代码能立刻跑起来验证""体验流畅了很多"
   • ✅ 正确姿势：做了什么就写什么，不加评价。 "修复 Redis 8.x 在 C locale 下崩溃的问题"而非"顺手修了 Redis 崩溃"。改了什么、为什么改、结果怎样，三句讲完，不用形容词。

文件命名

生成的日报文件放在 ./report/ 下，文件名格式：<report_from>_<report_to>.md

如果 ./report/ 目录不存在，创建它。

最后检查

生成后自检：

• 每天都有实质内容，没有任何一天看起来像摸鱼
• 不超过两条 detail bullet / 天
• 没有 fmt、submodule update、小重命名等无意义 commit
• 大白话，不说黑话
• 格式与模板一致（包括空行、缩进、-- 前缀）
• AI 味清零：全文搜索并删除夸张形容词（一眼可见/彻底/极大/显著）、自我表扬（顺手/轻松/搞定）、宏大叙事（铺平道路/扫清障碍/奠定基础）。读一遍，如果像公众号推文就重写。