我为什么开始写周报

一、起因很尴尬

大概两年前，我领导找我聊晋升。聊到一半他问："你这一年主要做了哪些事？"

我张了张嘴，说了三件，然后……卡住了。

不是没做事。是做了太多事，多到我自己都记不全。每天忙得脚不沾地，但被问到"你这一年到底干了啥"的时候，脑子里只有一团模糊的忙碌感，像一杯被搅浑的水。

那次对话之后，我做了一个决定：每周五花 20 分钟写周报。不是给领导看的那种，是写给自己看的。

二、我的周报长什么样

不汇报、不邀功、不写"本周完成需求 3 个"。我的周报只有四个板块：

1. 本周做了什么（流水账级别）

- 订单服务重构：完成支付链路迁移，涉及 4 个接口
- 帮新人排查了一次 Redis 连接泄漏
- 参加架构评审 2 次，提了关于消息队列选型的反对意见
- 写了 CoreDNS 故障复盘文档

不修饰、不包装。就是"这周干了啥"的原始记录。

2. 本周学到了什么（哪怕一句话）

- Redis 连接池的 evictExpiredConnections 默认 15 分钟跑一次，
  批量关闭连接时会阻塞工作线程
- K8s HPA 基于自定义指标时，metrics-server 的采集间隔
  决定了扩容响应速度的下限
- 代码审查时"先说意图再给方案"比直接说"这样写不好"有效得多

3. 本周踩了什么坑（给自己留证据）

- 本地改了 hosts 忘了清，导致联调环境一直连错 DB，
  排查了 40 分钟（丢人但真实）
- 给 CoreDNS 加 cache 插件时配错了 TTL，导致 DNS 变更
  10 分钟才生效，差点影响发布窗口

4. 下周想做什么（哪怕没做到）

- 把订单服务的监控告警补全（延迟、错误率、队列长度）
- 读一下 Resilience4j 的 CircuitBreaker 源码
- 约 DBA 聊一下分库分表方案

三、写了两年，它给我的回报远超预期

回报一：晋升答辩时，我有了弹药库

上次晋升，答辩材料里 70% 的素材直接来自周报。不是因为我提前准备了答辩——而是周报本身就是最好的"工作证据链"。你做过什么、解决了什么问题、学到了什么，白纸黑字，清清楚楚。

回报二：年终复盘从"痛苦"变成"整理"

以前写年终总结，要从 Git log、日历、聊天记录里大海捞针。现在？把 52 篇周报翻一遍，挑重点串起来就行。半小时搞定。

回报三：它帮我发现了"假忙碌"

有几次周五写周报，写完一看——这周忙了五天，但"学到了什么"那一栏写不出来。那一刻我意识到：这周只是在重复劳动，没有任何成长。

这种觉察本身就很值钱。它逼我在下周主动调整——哪怕只是抽一小时读源码、学个新东西，也不至于让一周白过。

回报四：它让我看到了自己的成长曲线

翻半年前的周报，你会发现很多当时觉得"好难好复杂"的问题，现在看来已经 trivial 了。这种"回头看"的视角，是日常忙碌中永远得不到的。它给你一种踏实的确认：我确实在变强。

四、为什么"写给自己看"比"写给领导看"有效得多

写给领导看的周报，你会不自觉地：

• 挑好的说
• 包装成果
• 回避失败
• 凑字数

写给自己的周报，你反而会更诚实：

• 这周确实没啥产出？那就写"没产出"，然后想想为什么
• 踩了低级错误？写下来，下次长记性
• 学了个很简单的东西？也写下来，因为"简单"是后见之明

诚实的记录，才是有价值的记录。

五、怎么开始？三个降低启动门槛的建议

1. 别追求格式完美

第一周哪怕只写三行，也比不写强。格式可以慢慢迭代，关键是先开始。

2. 周五下午固定时间写

我固定在周五 17:00~17:20。这个时间段大脑已经不太想做深度工作了，正好用来回顾和记录。形成习惯后，到那个时间手会自动打开文档。

3. 用你最顺手的工具

• 飞书文档 / Notion / Obsidian 都行
• 甚至一个 Markdown 文件也行
• 关键是能快速打开、快速写、以后能搜

我用的 Obsidian，每周一个文件，按 2026-W43.md 命名。两年下来，文件夹里整整齐齐 100+ 个文件。

六、一个意外的副作用

写周报半年后，我发现自己的周一周二状态变了。

因为知道周五要"交作业给自己"，周一周二会不自觉地多想一步："这件事值不值得写进周报？"如果答案是"不值得"，我会问自己："那为什么还要花时间做？"

周报像一个每周一次的"人生代码审查"——你 review 的不是代码，是你自己的时间和成长。