熟悉我的朋友都知道，我算是一个比较讨厌周报的人。在工作的时候，如果你告诉我某人写了一份三千字的周报，那我一定嗤之以鼻。心里想，这算啥写作比赛或是落伍的向上管理手段。
手写不行，但如果是AI写的呢？这里，要给大家介绍我目前的自动化周报工作流：Notion记录跟踪项目甘特图、GitHub汇总issue、交付和热点关注，整合二者的信息，每周调用大模型自动总结上周工作。
原理介绍
flowchart LR
subgraph Input[输入数据源]
N1[Notion 工单 DB]
N2[Notion GitHub DB]
G1[GitHub Commits]
end
subgraph Sync[同步与采集]
S1[notion_sync.py]
S2[github_collector.py]
end
subgraph Process[处理流程]
A1[analyzer.py]
L1[llm_summarizer.py]
end
subgraph Result[结果输出]
R1[report/*.md]
N3[notifier.py]
B1[Bark]
E1[Email]
end
N1 -- API --> S1
N2 -- API --> S1
G1 -- API --> S2
S1 --> A1
S2 --> A1
A1 --> L1
L1 --> R1
L1 --> N3
N3 --> B1
N3 --> E1
整体技术原理不难，核心是数据打通。通过Notion的甘特图做项目管理；GitHub作为版本控制和交付工具。Notion和GitHub的数据打通，GitHub的数据能够同步到Notion，包括项目仓库情况和star情况；Notion项目能够同步到GitHub Actions，用来做调用大模型的素材输入。
这样一通下来，不用额外的精力，只需要在Notion记录项目进展，每周就能定时收到周报情况。
效果展示
首先关注Notion上的工单情况，包括工单交付、工单进行中和工单延期。
在 Vibe Coding 背景下，提交 commit 和关闭 issue 的速度快了很多。一个工单可能对应多次提交，我需要知道大部分提交在处理什么问题，以此来建立对项目投入的判断力。所以也会关注提交日志和issue的情况：
最后就是阻塞情况同步、下周计划和周效率比较。
为什么写周报
前面说了，我不喜欢写周报。其实不喜欢的是：长篇大论、或是在一个小点上雕花、或是工作3天半，写周报润色1天半。进度同步、风险识别和阶段重点同步这种周报，是有意义的。言简意赅，而非用力过猛地刷印象分。
笔者从上家公司离职后，很快就面临一个问题：当我回顾过去一周，到底干了啥的时候，讲不清楚。特别当你一个人在做方向探索的时候，时间和精力会快速消耗，分散到各处。
那种不确定方向的焦虑感和验证无效的挫败感，反过来致使精力进一步分散。所以在离开公司三个月的时候，我开始重新写周报。
写周报的目的，仅仅是为了忠实记录自己到底干了什么、还要做什么，以此来保持注意力和回顾复盘有参考依据。
选择什么工具
在周报系统搭起来前，我一直用的Todoist来记录当周要做哪些事情，并通过苹果日历，同步展示到我的日程里。现在来看，也没什么毛病。不过就是不适合回顾，适合一次性的工作或是简单重复需要备忘的事项。
在当时，我决定采用Notion来做。主要是看重它对于数据表格的支持。我能够比较清晰地罗列当周做了什么，下周计划做什么。这个事情，在Todoist里搞不出来。
就这样，我沿用在上家公司的周报风格，每周汇总罗列上周干了什么、下周计划干什么。我搞的第一个项目开始系统化迭代，并开始带来部分收入。周报里也清晰记录了它的发展和变化。
遇到什么问题
随着接触的信息源增多、开展的项目越多，积压也越来越多。不少项目开始出现跨月的延期；也有部分项目在当时做出来有意义，再过两周回头看，会觉得意义不大。
我开始在周报系统里面叠加工作优先级，强制指定哪些项目应该优先做、哪些项目应该长期做。我在其中，参考公司项目管理的思路，给自己整了一个甘特图，把自己当周的排期占上。
但还是无可避免的，有项目仅仅是被记录，并未被实施。这种心理压力在一点点累积，直到原定这周的内容，分到下一周再做。中间忘记同步周报，两周一次；或只是简单的复制上周内容，做微小改变。
以上这些，都是项目管理里面比较常出现的问题。进度变化、风向变化，都会带来项目情况的变化。考虑到帕金森定律，预估的时间一定会被占满；根据侯世达定律，实际往往会拖到原计划的两倍甚至多倍。这些问题，经历过大型项目管理的就都知道，这在团队开发中几乎天天出现。
本文暂时不展开说如何做需求管理，后续其他文章会做介绍。我们回到主体部分。
自动化周报解决什么问题
今天这里，想给大家介绍的是，我是如何把写周报这个过程自动化的。如前文所言，大家可以看到写周报对我来说是有心智负担的。汇总不同信息源的进度是重复且枯燥且容易遗漏的，这恰恰适合大模型来做。
除开心智负担，还有个现实情况是：早期部分工作没有被记录下来。仅仅凭感觉要做，所以去做了。但做，其实只做了其中的一环：比如仅项目调研。并未将其作为系统，交付到下游。
用专业术语来说，就是有大量半成品，且不少半成品还未记录在案。后来，我试着在改善：动手之前把它记录到我的Notion甘特图里面，有啥交付物就先记录下来。
所以，自动化周报其实是在帮我把散落的信息集中在一起，做整体呈现。并试图提供交付物、半成品的直观感受。
难以交付是常态，稳定交付是一种能力。而自动化周报，则是向后者靠近的一点点微小努力。
自动化周报不解决什么问题
不解决非自动化部分、不解决日常数据沉淀问题。
所有的一切起源，都需要人工去记录项目进度，并将数据统一集中到特定地方。在这个项目中，载体就是Notion。我在Notion上除开有项目甘特图，还会有从GitHub同步的我关注的仓库star情况，以及我本身的仓库情况。
反过来说，我的所有软件类交付以及部分内容类交付，是通过 GitHub 在做代码管理和版本管理，部署也是通过 GitHub 再接入其他平台实现自动化部署。GitHub 既是流通的管道，也是记录的管道。
当我通过手动跑过大半年后，才明确感知到，这部分有自动化的必要了。参考过一些开源的同步项目，以及借助目前越发强大的第一梯队模型能力，这个项目能够很快落地实现。
该项目的迭代方向
目前数据能够稳定在周一跑出来，给到一些见解。但是它项目管理方面的哲学偏好，还未被注入。时间跨度上，也比较有限，缺少更大跨度的比较。
整体来看，这个项目的输入与输出 token 在 1w 左右，使用 Gemini 3.1 Flash-Lite 作为总结模型，总成本人民币约三分钱，算是很低的消耗。可以塞入更多上下文，或换用更强模型。
建议总结
总的来说，AI工具对于开发效率还是有非常大的帮助。通过常规数据沉淀+链接不同工具+大模型，有很强的可玩性。之前不敢想、没精力做的事情，目前可以很快开发出来。
但是，同样别忽视了常规数据沉淀和工具选型的重要性。如果没有人工的项目判断、进度同步，那么仅仅有大模型，那这就是个空中楼阁。
同样的，如果一开始就想搞大模型，也会犯：手里有个锤子，什么地方都想来一锤子的过错。最后，希望大家玩得开心。适度监控有益，过度监控则会成为牢笼，带来意料之外的动作变形。