如何把 GitHub PR 整理成 Notion 周报

整理工程周报，通常需要逐条查看 PR、复制链接，再区分哪些改动已经合并、哪些还需要审查。

连接 GitHub 和 Notion 后，你可以在团队聊天中让 Leina 获取 PR、整理附有来源链接的草稿，再把检查过的版本追加到 Notion。把生成草稿和写入文档分开，便于在发布前核对数量与内容。

第一次运行时，选择一个已经结束的完整周，方便用熟悉的记录检查结果。

明确周报的统计范围

让 Agent 获取记录之前，先定义哪些 PR 应该进入周报。第一次可以只选择一个仓库和一个完整周。

部分	纳入规则	表达的内容
本周已合并	合并时间落在指定的起止时间内	这段时间进入目标分支的改动
当前仍开放	查询时 PR 处于开放状态	进行中的工作、草稿状态及有记录的审查阻塞

关于开放中的 PR： 当前列表反映查询时的仓库状态。要说明上周结束时有哪些 PR 仍开放，需要当时保存的快照，或之后状态变化的证据。保留带日期的周报，可以为后续比较积累快照。

你可以用 GitHub 的状态与合并时间搜索条件检查来源记录：

repo:OWNER/REPOSITORY is:pr is:merged merged:2026-09-28T00:00:00+00:00..2026-10-04T23:59:59+00:00

替换仓库和日期，并保持搜索与周报使用同一时区。这个示例的 +00:00 表示 UTC；如果团队使用其他时区，请换成对应统计窗口的时区偏移。

连接 GitHub 和 Notion

在 Leina 控制台中授权两类连接：

GitHub： 连接能够读取目标仓库的账号，并确认连接提供周报需要的 PR 信息。
Notion： 写入时，使用能够读取目标页面并追加内容的连接。

在集成中检查支持的操作，在连接中核对已授权账号。发起请求的成员也需要获得这些连接的使用权限。先在接入 Leina 的团队聊天中生成草稿，检查后再写入 Notion。

让 Agent 生成可检查的草稿

请求中应要求保留来源链接，并明确怎样处理缺失信息。可以复制并修改下面的内容：

为 [owner/repository] 准备一份工程周报，统计 [起始时间戳] 到 [结束时间戳]，使用 [时区]。

已合并 PR： 列出在这个窗口内合并的全部 PR。每项包含编号、标题、作者、合并时间、来源链接，并根据 PR 描述和工具能够获取的改动，用 1–2 句话概括内容。

当前仍开放的 PR： 列出查询时仍开放的 PR，标明草稿状态，以及有记录的审查人或阻塞事项。

缺失信息： 如果 PR 描述为空，或影响不明确，标注“影响未记录”，不要推测业务原因或成果。

获取说明： 标注获取时间；在工具支持的情况下读取范围内全部结果页，说明未完整获取或无法访问的记录。

在聊天中返回完整草稿，先不要写入 Notion。

如果团队有统一的 Markdown 格式，可以提供空白周报模板作为格式参考。

对照 GitHub 检查草稿

写入 Notion 前，核对记录列表并抽查摘要：

核对 PR 数量： 在 GitHub 搜索中运行合并时间查询，比较搜索结果与草稿中的已合并列表。
核对时间边界： 检查起止时间附近的 PR，确认筛选所用的时间戳和时区一致。
区分关闭与合并： 确认没有把直接关闭、未经合并的 PR 纳入已合并部分。
核对部署证据： 合并到 main 只说明代码进入该分支。只有部署记录或其他明确来源证明某个环境已经部署，才能在周报中这样描述；发布标签本身仅标识代码版本。
检查摘要依据： 对“修正错字”或“更新依赖”这样的 PR，摘要应围绕实际改动，避免推测不存在的架构改善。

PR 描述缺失等问题应保留“未记录”标注。这些信息也可以帮助团队改进后续的 PR 描述。

把检查过的周报追加到 Notion

确认草稿准确后，再让 Leina 写入指定页面：

将检查过的周报追加到 [Notion 页面 URL]，使用标题“[仓库] — [统计周期]”。

先检查该标题是否已经存在。如果存在，先展示已有部分，再处理修改。

保留页面中其他已有内容。

写入后，读回新增部分并返回页面链接。如果写入结果不确定，重试前先检查页面；无法核实时请说明。

这样可以在文档发生变化之前检查草稿。具体能执行哪些操作，仍由连接权限决定。向团队分享前，也应检查保存后的内容。

跑通之后，可以把这套请求整理成可复用的 Skill，以后换一个统计窗口继续使用。其他成员也需要获得相应的连接权限。