临近月报截止日，最费时间的常常是回忆过去一个月到底改了什么。代码散在不同项目里，工作过程夹在聊天记录、临时笔记和文件时间中，回头整理很容易遗漏。

Git 已经记录了提交时间、修改文件和提交说明。把这些记录按时间取出来，再交给大语言模型整理，可以得到一份完成工作的列表。它帮人找回线索，最后写进报告的内容仍要由人决定。

Summary

把 Git 记录整理成一份可人工核对的工作回顾初稿。

整体流程并不复杂

整套做法可以压成一条线。

收集代码 → 按项目提交 Git → 读取指定时间窗 → 本地脱敏
        → LLM 整理初稿 → 人工校对 → 保存最终版

开头两步决定了后面的报告有没有东西可写。脚本分散在多个目录时，可以定时把需要保留的代码收集到一个 Git 仓库。这里只收代码和必要配置，数据、缓存、运行结果、密钥文件与符号链接都排除在外。

提交时按照项目分组，比把所有变化塞进同一个 backup 提交更有用。提交说明也要写出具体动作，例如“增加输入检查”或“修正批处理参数”。长期只写 update、fix，模型看到的仍是一串无法解释的文件变化。

这一步解决的是版本留存和工作记录。备份仓库如果还在同一块磁盘上，无法应对磁盘损坏；重要代码还要放到独立介质或权限受控的远端。

按报告周期读取记录

到了月末，脚本只需读取报告周期内的提交摘要和变更路径。学校或单位若按每月 22 日到次月 21 日统计，就把起止时间写成明确的时间点。

git log \
  --since="2026-04-22 00:00:00 +0800" \
  --until="2026-05-22 00:00:00 +0800"

用次月 22 日零点作为终点，可以覆盖 21 日全天。时间窗要按自己的报告制度调整，并固定时区，避免月末边界前后漏掉提交。具体参数可以参考 Git log 文档。

送给模型的内容不需要很多。提交说明用来判断做过哪些改动，文件路径帮助区分项目，再附上提交数量和变更文件数，通常已经足够形成回顾框架。源码正文、完整差异和实验数据不应默认进入提示词。

提示词要说清任务范围。模型可以归组、概括和润色，不能从文件名推断研究结果，也不能自行宣布某项工作已经完成。

请根据给定时间窗内的 Git 提交摘要和脱敏后的文件路径，
整理一份待人工复核的工作回顾初稿。
 
按项目归组，只写记录能够支持的内容。
无法确认的结果、原因和计划统一标注“待作者确认”。
不要生成可直接提交的最终报告。

这几句已经包含关键限制。输入来自哪里、模型可以做什么、证据不足时怎样处理，都有明确说明。报告格式可以再按实际模板补充，没有必要把提示词写成一份很长的技术规范。

Git 能说明哪些文件在什么时间被修改，却不会记录全部工作。文献阅读、会议讨论、实验操作、方案取舍和临时判断若没有留下提交，初稿里就不会出现。人工校对时要补回这些内容，也要删掉模型根据文件名产生的过度推断。

带有“完成”“解决”“验证”“提升”等词的句子，需要逐条回到提交记录和实际结果中确认。提交说明只能证明当时怎样描述改动，无法单独证明研究结论成立。经过核对和补写之后，报告才具备提交条件。

最后还要检查隐私。提交信息和目录名可能带出研究方向、合作者、服务器名称或未发表结果。进入托管模型之前，先在本地删除真实路径、姓名、单位、密钥和敏感项目名。报告样例、源码差异、实验指标与未发表结论不进入提示词。保密条件不满足时，流程停在本地 Git 汇总即可。

保存时至少区分模型初稿和人工确认后的最终稿，并记录对应的时间窗。这样过一段时间再翻出来，也不会把未经核对的内容误当成正式报告。