Weekly Report Writer (周报撰写助手)

概览

此技能自动化了周报/双周报的创建过程。它通过查找指定日期范围内的所有相关文档，阅读其内容，并根据模板或分层结构合成信息。它特别注重项目的连续性（追踪上一份报告的任务状态）和内容的深度（通过链接溯源）。

何时使用

当用户要求：

• “写我的周报”或“起草本周摘要”。
• 总结两个日期之间的进度。
• 基于上一份报告和一组新文档创建新报告。

此技能在文档知识库，如 Obsidian 知识库中特别有效。

核心准则

1. 语言风格：去大词、去黑话、极简平实

• 以朴素事实与具体动作为锚：句式直接采用「动词 + 具体产出/方案/结论」，严禁堆砌企业大词与黑话（禁用“赋能”、“拉通对齐”、“打法”、“抓手”、“深度闭环”、“降载”、“合规治理”等浮夸修辞，替换为“打包”、“反馈”、“接口限流”、“排期开发”等朴素动作）。
• 保留关键技术参数与避坑细节：记录具体框架名称、运行环境、关键配置参数、性能指标与排查出的实际根因。
• 草案与规划必须明确边界：凡属初步设想、架构提案类事项，应以「草案规划 - ...」注明，并写明「目前仅为草案，待进一步确认后再执行」，避免将初步讨论表述为已进入实质开发。
• 观察与待定事项收拢文末：对于尚无实质动作的外部动态观察、待排期事项，收敛至文末板块，注明「目前保持关注，暂未展开具体动作」。

2. 事情聚类方案：按项目/领域主线聚合（严禁流水账）

周报严禁按工作日流水账罗列，按 3~5 个项目模块 / 技术领域进行聚类（例如）：

1. 核心模块开发与版本交付：关键功能实现、原型构建、交付物打包、问题排查与修复。
2. 架构设计与技术方案规划：模块接口对接、技术选型验证、工具链改进与架构设计草案。
3. 运行监控与问题改进：系统运行指标观察、性能瓶颈分析、用户反馈处理与自动化脚本编写。
4. 工程基建与稳定性维护：配置管理、安全策略、常规功能迭代与体验优化。
5. 💡 关注事项与待办承接：固定放在末尾，归集暂无直接动作的观察项，以及移交或延后的积压待办。

3. 符号体系定义

• 🟩：已完成（有文档/记录支撑的工作成果）。
• 🟨：进行中 / 推进中。
• 🟥：待办 / 搁置（统一归入 🟥，不再单设符号）。
• 💡：新想法 / 个人思考 / 关注事项。
• ❇️：代码 / Agent 侧工作。指源自本地代码仓库提交或 Agent 会话、未在当周 Obsidian 笔记中记录的工程进展，用 ❇️ 标注。

4. 排版规范：三层事项结构、纯文本无格式约束与行尾脚注引用

1. 单层紧凑结构（彻底废弃冗余的“团队对外同步”）：
   • 默认直接输出单层 ## 02. 状态同步，按 4~5 个业务板块推进。
   • 严禁默认生成与个人状态高度重叠（40%+ 重复率）的“第二部分：团队对外同步”，除非用户特别明确要求。
2. 「领域 -> 事项 -> 四要素」三层描述结构：
   • 第一层（领域）：使用三级标题 ### 1. {业务主线 / 领域名称}
   • 第二层（事项）：使用五级标题 ##### {具体事项名称}（严禁将不同事项的“做了什么”与“还要做什么”打散混排在同一个大列表下）
   • 第三层（四要素）：在每个事项下以无序列表 - 依次展开（严禁加粗字段名）：
     • - 任务目标：{简述该事项的目标与定位}[^N]。
     • - 🟩 做了什么：{平实描述具体动作、技术细节与工程产出（含 ❇️ 项）}[^M]。
     • - 效果：{当前已取得的阶段性结果、数据指标或就绪状态}。
     • - 🟨 还要做什么：{下一步计划、承接的未完结待办或外部依赖}。
3. 全文纯文本约束（严禁粗体与行内代码反引号）：
   • 生成的周报正文中，全文严禁使用 **粗体**、**粗体冒号：** 以及 `codefences`（行内反引号代码格式），全部使用不带格式的纯文本。
4. 正文行尾脚注引用（Footnotes）：
   • 正文严禁在加粗标题或句子中间硬插长双链：双链过长会切碎中文阅读语流。
   • 统一收纳至行尾：每条进展只在最末尾（句号后）追加角标 [^N]（如 ... 完成模块重构 [^2]。 或 ... 补充边界用例测试 [^3] [^4]。）。严禁放在加粗小标题后或句子半中间。
   • 01 导语去重：01 文档生成说明中仅保留简明导言（如 对照继承上一期周报 [^1] 的待办事项，文中所涉具体方案与交付文档见文末引用列表。），不再重复罗列长篇清单。
   • 文末统一收口：在文末设置 ## 03. 参考文档与来源，统一展开 [^1]: [[...]]。在 Obsidian 实时预览或阅读视图下，正文自动渲染为精美上标，悬停即弹出笔记预览，点击直达文末并支持回跳锚点 ↩。

工作流

第一步：定位周期与上一份周报

1. 自动推断与定位：
   • 优先在笔记库根目录中按文件名模式（如 *📅 本周摘要*.md）检索最近的一份周报。
   • 读取该周报的标题与元数据，提取其报告周期（如 2026-09-07 - 2026-09-14），推断本期报告的开始日期（即上一期的结束日期）及结束日期（当前日期）。
2. 轻量确认：
   • 若自动推断成功，向用户简短报备周期与继承来源；若未推断出，再向用户询问周期、笔记库路径与上一份周报路径。

第二步：查找并筛选周期内文档

1. 检索文档：
   • 在笔记库根目录检索文件名日期处于本周期内的 Markdown 文件（格式如 YYYY-MM-DD-hh 分类 - 标题.md）。
2. 筛选策略：
   • 重点关注：Jira 需求单、技术方案设计、会议纪要、排查复盘、阶段交付总结、调研报告、Idea 文档。
   • 跳过/略读：纯外部摘录原文（文档摘录）、未整理的语音转写原始文本。
3. 向用户确认：
   • 简短列出本周期拟纳入的文档清单，由用户快速确认或增减。

第三步：扫描代码仓库与 Agent 工作（补充 ❇️ 项）—— 最佳提取实践

为全面捕捉「已完成代码实现/工程联调，但在 Obsidian 笔记中未记录或仅轻描淡写提及」的工作，执行以下最佳实践流程：

1. 确定扫描范围与周期：
   • 以本期起始日期（START_DATE，即上一期结束日期）到当前日期为基准。
   • 扫描目标包括：工作区所有 Git 仓库（~/workspace/*）以及 Agent 会话目录（~/.gemini/antigravity/brain/）。
2. 执行扫描脚本快速摸底：
   • 优先运行内置脚本提取周期内的 Git 提交与工程会话：

     python3 scripts/scan_agent_work.py --since YYYY-MM-DD

   • 脚本会自动聚合活跃代码仓库的 git log（按提交条数和摘要过滤），并抓取当期修改的 Antigravity 会话的首轮工程意图。
3. 去噪与过滤（关键准则）：
   • 严格过滤：剔除纯个人闲聊、概念性纯问答（如 side questions）、无实质工程/代码改动的临时会话，以及无规则变更的日常占位提交（如空 sync chore）。
   • 重点保留：有实体代码落盘、Bug 修复（fix）、新功能封装（feat）、工程文档沉淀（docs）、架构重构、自动化脚本及交付包构建。
4. Obsidian 交叉比对与去重：
   • 将初筛出的工程项与本周期内 Obsidian 笔记进行关键词检索比对：
     • 若 Obsidian 笔记中已有完整的专题记录，则按常规 🟩 记录，并在正文中保留 [[WikiLink]] 关联。
     • 若该项工作仅体现在代码提交或 Agent 实施过程中、Obsidian 中未记录，则确认为纯工程项，打上 ❇️ 标记。
5. 聚类映射与规范化表述：
   • 将提炼出的 ❇️ 条目映射至既定的 4~6 个业务主线聚类中。
   • 输出格式规范：
     • ❇️ 简明事项标题（所属仓库/模块）：动作 + 成果 + 关键技术参数/避坑细节（commit SHA / 关联会话）。（严禁使用粗体或反引号）
     • 保持语言平实、克制，以真实工程事实为依据。

第四步：深度溯源与严格待办继承

1. 链接追踪（深度溯源）：
   • 阅读每日小结或会议纪要时，若遇到包含 [[文档链接]] 的关键成果，必须读取被引用的具体文档，提取真实产出、量化指标与技术细节。
2. 严格的待办继承机制：
   • 必须逐条核对上一期周报中列出的所有待办与推进中事项（🟨 / 🟥）：
     • 已完成项：在本期列入 🟩 做了什么，并补充交付成果与文档链接。
     • 未结/推进中项：必须继承到本期的 🟨 还要做什么 / 🟥 待办继承，说明当前阻碍、依赖方或排期变化。搁置与待办统一标记为 🟥。

第五步：起草结构化草稿（单层状态与文末脚注）

严格按如下单层脚注模板起草：

---
title: YYYY-MM-DD-hh 📅 本周摘要 YYYY-MM-DD - YYYY-MM-DD
date created: YYYY-MM-DD dddd HH:mm
creator: cafe3310 与 Coding Agent (Antigravity) 协作生成
background: 汇总 YYYY-MM-DD 至 YYYY-MM-DD 工作进展，对照上一期周报 [[上一期周报]] 的待办事项。主要包含...
references:
  - "[[上一期周报]]"
  - "[[重点文档A]]"
tags: [Type-规划, Project-X-...]
date modified: YYYY-MM-DD dddd HH:mm
---

## 01. 文档生成说明

本文档由 Coding Agent (Antigravity) 协作生成。汇总周期为 YYYY-MM-DD 至 YYYY-MM-DD，对照继承上一期周报 [^1] 的待办事项，文中所涉具体方案与交付文档见文末引用列表。

---

## 02. 状态同步

### 1. {业务主线 / 领域 A}

##### {具体事项 1}
- 任务目标：{简述任务目标与背景定位}[^2]。
- 🟩 做了什么：{平实描述动作与过程，保留技术细节；若有纯代码仓/Agent 侧工作则在此以 ❇️ 标注}[^2] [^3]。
- 效果：{简述阶段性效果、量化结果或交付状态}[^2]。
- 🟨 还要做什么：{下一步动作说明，承接上期未完结项}[^3]。

##### {具体事项 2}
- 任务目标：...
- 🟩 做了什么：...
- 效果：...
- 🟨 还要做什么：...

### 2. {业务主线 / 领域 B}
...

### N. 💡 关注事项

##### {关注事项类别}
- {事项说明}：{目前保持关注，暂不展开具体动作；或 🟥 待办移交说明}[^N]。

---

## 03. 参考文档与来源

[^1]: [[上一期周报]]
[^2]: [[重点文档A]]
[^3]: [[重点文档B]]

第六步：逐板块交互确认与定稿

在初稿合成完成后，严禁直接收工，必须进入「逐板块交互确认」流程：

1. 逐板块循环提问：
   • 依次遍历每个业务工作聚类（板块），向用户展示该板块草稿，询问描述合理性与遗漏事项。
   • 收到反馈后手术式精准更新，避免擅自引入大词或黑话。
2. 全局最终确认与格式核验：
   • 在所有既定板块确认完毕后，进行最后一轮全局询问：“是否有其他需要记录的事情？”
   • 格式核验：
     • 检查正文中的所有脚注是否均位于行尾（标点后），严禁插在加粗小标题后或半句中。
     • 检查文末 ## 03. 参考文档与来源 的 [^N]: [[...]] 序号是否完整且按序对应。
     • 确保未生成冗余的“第二部分：团队对外同步”。
   • 写入目标文件并在 Obsidian 中调起预览。