daily-note-monthly-review

面向工作沉淀的月度日志处理 Skill。核心产物：

• 一份原始月度归档（不改原文）
• 一份结构化月度总结（由 Claude 撰写，事实优先，禁止脑补）
• 一份可被周报、绩效、复盘复用的事实层输入

设计原则

• 事实优先：只从原始记录中提取和归纳，不虚构缺失信息
• 原文不动：归档文件保留原始 Markdown，不做改写
• 总结与日志分离：归档和总结是两个独立文件
• 结构化输出：使用固定模板，便于二次消费
• 允许总结，禁止脑补：可以把多条记录归纳为一个主题，但不得凭空生成不存在的"成果"或"结论"

触发条件

当用户需要以下任何操作时，使用此 Skill：

• 按月拆分 Daily Note.md
• 生成月度工作总结
• 整理工作日志
• 为周报/月报/绩效准备素材
• 回顾某月项目进展

输入契约

必需输入

input_file

output_dir

Daily Note 需具备明确的标题层级结构（年 → 月 → 日期），具体格式约定参见

reference/daily-note-format.md

可选参数

summary_mode: project_focused    # light | project_focused | engineering_review
overwrite_policy: overwrite      # append | overwrite | skip_existing
month_filter: null               # 只处理指定月份，如 "2026-03"
project_filters: []              # 只保留特定项目视角
evidence_mode: strict            # strict | best_effort

参数说明：

• summary_mode

  ：控制总结深度。

  light

  只提炼主线和关键词；

  project_focused

  （默认）按项目归并，提炼重点事项；

  engineering_review

  强化问题/方案/风险/验证结构

• overwrite_policy

  ：已有文件时的处理策略。

  overwrite

  （默认）覆盖，

  append

  追加，

  skip_existing

  跳过

• month_filter

  ：只处理指定月份，格式

  YYYY-MM

  ，

  null

  表示处理所有月份

• project_filters

  ：只保留指定项目的视角，如

  ["项目A"]

  ，空列表表示不限

• evidence_mode

  ：

  strict

  （默认）要求每条总结都有原文依据，

  best_effort

  允许适度归纳

• real_projects

  ：手动指定真实项目列表（可选）。默认自动检测（出现天数 >= 2 天的项目视为真实项目）

• real_project_min_days

  ：自动检测真实项目的最少出现天数阈值（默认 2）

输出契约

1. 月度归档文件

YYYY-MM.md

• 保留原始 Markdown 内容，不改写
• 按原始日期顺序组织
• 不跨月重排

2. 月度总结分析文件

YYYY-MM.summary.md

• 由 Claude（而非脚本）基于骨架数据和模板撰写
• 使用

  reference/worklog-summary-template.md

  中定义的格式和规则
• 显式区分"事实"、"归纳"、"信息缺口"
• 不输出缺乏依据的判断

3. 执行摘要（终端输出）

{
  "months_created": ["2026-03"],
  "months_updated": [],
  "summaries_created": ["2026-03.summary.md"],
  "summary_mode": "project_focused",
  "projects_detected": ["项目A", "项目B"],
  "high_frequency_topics": ["核心模块", "性能优化", "API集成"],
  "warnings": []
}

执行步骤

按以下顺序执行，每步完成后进入下一步。如果某步失败，向用户报告错误内容，不要跳过继续。

Step 1：读取与预检

1. 确认

   input_file

   存在且可读
2. 检查编码（必须是 UTF-8）
3. 识别标题层级结构，确认至少存在月级别和日级别的标题
4. 如果格式不符合预期，提示用户检查

   reference/daily-note-format.md

   中的格式约定

格式识别规则：

年标题：  ^#\s*\d{4}\s*年
月标题：  ^##\s*\d{4}\s*年\s*\d{1,2}\s*月
日标题：  ^###\s*\d{4}\.\d{2}\.\d{2}

注意：年月标题中的"年"和"月"前后可能有空格（如

2026 年 3 月

Step 2：按月拆分归档

1. 运行

   scripts/split_daily_note.py

   ，传入

   input_file

   和

   output_dir

2. 脚本解析年/月/日节点，将同月内容合并输出为

   YYYY-MM.md

3. 如果 Daily Note 中缺少

   ##

   月级标题（只有

   #

   年标题和

   ###

   日期标题），脚本会自动从日期推断月份
4. 按

   overwrite_policy

   处理已有文件
5. 如果指定了

   month_filter

   ，只输出该月
6. 检查脚本输出，确认生成的月度文件数量和内容正确

Step 3：提取工作信号

1. 对每个需要生成总结的月份，运行

   scripts/extract_worklog_signals.py

2. 脚本从月度归档中提取结构化信号：
   • 项目标签（

     - [xxx]

     格式）
   • 模块标签（

     - {xxx}

     格式，兼容 Tab 和 4 空格缩进）
   • 类别标签（

     【能力升级】

     、

     【结构变更】

     、

     【问题定位】

     等）
   • 完成状态（

     [x]

     已完成 /

     [ ]

     未完成）
   • 具体工作内容文本
   • 任务子条目：自动捕获任务下方的缩进子列表（详细说明、规模信息等）
   • 当日焦点：从

     > 🎯 当日焦点：

     行提取每日工作重心
   • 内联状态标记：识别

     【后续动作】

     、

     【进行中】

     、

     【待执行】

     、

     【性能优化】

     等内联标记
3. 输出中间层 JSON 结构，供下一步使用
4. 将中间层 JSON 保存到

   output_dir

   下（文件名

   YYYY-MM.signals.json

   ），方便调试和复用

Step 4：构建总结

分两步完成：先用脚本生成骨架 JSON，再由 Claude 撰写总结。

4a：脚本生成骨架 JSON

1. 运行

   scripts/build_monthly_review.py

   ，传入信号 JSON 路径和输出目录路径
2. 脚本完成确定性工作：
   • 按项目归并条目
   • 统计已完成/未完成事项
   • 收集高频关键词
   • 识别风险词和下一步信号
   • 自动识别真实项目：出现天数 >= 2 天的项目视为真实项目（可通过

     --real-projects

     手动覆盖）
   • 保留任务子条目：每个任务附带其详细说明，供归纳时参考
   • 收集当日焦点：各日期的工作重心摘要
3. 输出结构化骨架 JSON（

   YYYY-MM.skeleton.json

   ）

4b：Claude 撰写总结

读取

reference/worklog-summary-template.md

YYYY-MM.skeleton.json

YYYY-MM.md

骨架数据中的

daily_focuses

category_distribution

work_phases

然后按模板格式撰写

YYYY-MM.summary.md

重要约束：

• evidence_mode=strict

  时，每条总结必须能在原文中找到对应条目
• 不要把"优化中"说成"已完成"
• 不要把多条独立的小修复包装成"重大成果"
• 如果某个项目在当月只有零星记录，如实说明"记录较少"，不要强行展开
• 同一任务跨多个项目时，只在活跃天数最多的项目下列出，避免重复
• 利用子条目做归纳：骨架数据中每个任务附带的

  details

  字段包含详细说明，应作为归纳主题段落的素材来源，而非逐条罗列任务本身

取舍规则（必须遵守）：

• 每个项目最多保留 2-3 个核心主题，其余合并为一句"日常优化包括..."
• 代码变更数字只在净增 >300 行或净减 >200 行时保留，其余不写具体数字
• 配置调整、文档优化、<50 行变更的小修复一律合并，不单独列出
• 运维类工作（日志、监控、通知、CI/CD）合并为一句
• "本月概览"应包含工作节奏判断（如"上半月集中...下半月转向..."），可参考

  work_phases

章节结构：

• 本月概览：2-4 句话叙事
• 工作量分布：表格，使用骨架中的

  category_distribution

• 本月主线：每个真实项目一行
• [项目名]：叙事段落（1-3 段），不是加粗标题列表
• 问题与风险：从骨架的

  risks

  和未完成事项中提取，每条一行
• 下月衔接：从骨架的

  next_actions

  中提取，每条一行
• 数据说明：统计口径、误检测说明等
• 误检测项目（不在

  real_projects

  列表中的）不单独展开
• 总结总长度控制在 80-120 行以内
• 输出格式以

  reference/worklog-summary-template.md

  为准

Step 5：输出执行摘要

在终端输出结构化执行摘要（JSON 格式），包含：

• 处理的月份列表
• 生成的文件列表
• 检测到的项目列表
• 高频主题
• 警告信息（如格式异常、归类模糊项等）

项目归类规则

项目通过 Daily Note 中的

- [项目名]

- [xxx]

核心原则：

• 以

  [项目名]

  标签为归类依据，不根据内容猜测
• 遇到未识别的标签，保留原始标签，在总结数据说明中提示
• Markdown 链接

  [文本](URL)

  不是项目标签，注意区分

详细归类规则参见

reference/project-tagging-guide.md

工作类别识别

日志中的工作类别通过

【xxx】

【能力升级】

【结构变更】

【问题定位】

【配置调整】

【文档优化】

【阶段总结】

【阶段冻结】

状态信号识别

已完成信号

• 任务列表标记为

  [x]

• 文本中出现：完成、已完成、已接入、已验证、已修复、已落地

进行中信号

• 任务列表标记为

  [ ]

• 文本中出现：调整中、优化中、联调中、测试中、迭代中

风险信号

• 文本中出现：风险、问题、阻塞、不稳定、兼容性、待确认、未验证

下一步信号

• 文本中出现：下一步、后续、待补、计划、准备、需要继续

边界与非目标

此 Skill 不负责：

• 改写原始 Daily Note
• 写汇报文案
• 生成绩效表述
• 判断工作价值高低
• 把零散记录包装成"成果"

此 Skill 只负责：

• 拆分 → 归档 → 提炼 → 结构化输出

更上层的"周报风格化输出""绩效包装"应由其他 Skill 处理。

错误处理

1. 文件不存在：报告路径，提示用户检查
2. 编码异常：报告具体位置，建议用 UTF-8 重新保存
3. 标题层级不识别：展示实际找到的标题层级，提示用户参考

   reference/daily-note-format.md

   调整
4. 某月无内容：正常处理，生成空月度文件，在总结中标注"本月无记录"
5. 脚本执行失败：报告完整错误信息，不要吞掉异常

reference 文件说明

reference/daily-note-format.md

reference/worklog-summary-template.md

reference/project-tagging-guide.md