核心用法
Weekly Engineering Retrospective 是一个专为工程团队设计的周度回顾工具。用户通过 24h、7d（默认）、14d、30d 或 compare 等参数指定时间窗口，工具将自动执行一系列本地 Git 命令，采集提交历史、代码变更量、测试覆盖率等多维数据，最终生成结构化的团队绩效与代码质量报告。
核心流程包括：采集原始数据 → 计算关键指标 → 分析时间分布与工作模式 → 识别代码热点与 PR 规模 → 生成个人与团队层面的深度洞察 → 保存历史数据用于趋势追踪 → 输出 Telegram 格式的叙事报告。
显著优点
1. 团队感知能力：自动识别当前用户，区分「你」与「队友」，提供差异化的个人深度分析与团队概览，特别适合多人协作场景。
2. 数据驱动的反馈文化：每项「表扬」和「成长机会」都锚定在具体的提交记录上，避免空泛评价，建立基于事实的反馈机制。
3. 趋势追踪与对比：通过 memory/ 目录持久化历史数据，支持周环比、双周期对比，帮助团队量化改进效果。
4. 丰富的行为洞察：45 分钟间隙的会话检测、深夜编码聚类识别、Focus Score 专注度评分、fix 比例健康度监测等，超越传统 Git 统计工具的表层数据。
5. 零外部依赖：纯 Markdown 实现，仅调用本地 git 命令，无网络请求、无第三方库，部署简单且可审计。
潜在缺点与局限性
1. Git 历史假设：依赖规范化的 Git 使用习惯（如清晰的 commit message、常规的分支策略）。若团队 squash merge 或 rewrite history，部分指标（如 PR 规模估算）会失真。
2. 时区与本地化：虽承诺「本地时区」，但实际依赖运行环境的时区配置，跨时区协作团队可能出现统计偏差。
3. 语言与编码习惯偏见：conventional commits 前缀分类（feat/fix/refactor 等）对未采用该规范的项目适用性降低；测试文件模式匹配（.test.、_spec. 等）可能无法覆盖所有技术栈的命名惯例。
4. 隐私敏感性：默认分析「所有贡献者」数据，在开源项目或大型组织中可能触及个人数据合规边界（尽管报告建议获取团队同意）。
5. 无 CI/CD 集成：纯本地执行，无法自动集成到 GitHub Actions、GitLab CI 等流水线中实现自动化报告推送。
适合人群
- 技术团队负责人 / Engineering Manager：需要量化团队产出、识别代码质量风险、建立数据驱动的 1:1 反馈。
- Senior Engineer / Tech Lead：希望追踪个人技术影响力、优化工作节奏、向团队展示可量化的贡献。
- 小而精的全栈团队（3-8 人）：成员间信任度高，愿意分享提交数据以换取集体改进。
- 采用 GitHub Flow 或类似轻量级分支策略的团队：工具对 PR 合并模式的假设与该工作流契合。
常规风险
- 数据误读风险：代码行数（LOC）并非价值度量，高 LOC 可能代表过度工程而非生产力。团队需建立「数据辅助决策，而非替代判断」的文化。
- 游戏化副作用：公开排行榜可能引发「刷提交」行为，建议将工具用于自我反思和私密反馈，而非绩效考核。
- 历史数据累积：
memory/目录的持续写入需定期清理策略，避免长期运行后磁盘占用膨胀。 - 权限边界：工具执行
git fetch origin main，需确保运行环境具备仓库读取权限，避免在敏感私有仓库中误操作。