在飞书上，我注意到一件挺有意思的事。
有些同事会在个人签名里贴一个文档链接，点进去是介绍自己的——有写过去经历的，有类似简历格式的，也有专门介绍自己在公司做过哪些项目的。内容不一样，但意思都差不多：让别人在跟你聊之前，先知道你是谁。
印象最深的是一个新来的高级设计师。他按天写工作日志，把链接挂在签名里，所有人都能看到他最近在做什么、在推进什么。我有次点进去看了一下，里面记的都是很具体的东西：今天出了哪个方案、和哪个产品对齐了什么、遇到了什么问题。不是表演给人看的那种流水账，更像是一个专业的人在认真对待自己的工作。
我觉得这是一种挺聪明的方式。被动等别人认识你，不如主动让别人知道你是谁、擅长什么、找你能做什么。公司里很多协作机会，其实都是从"哦原来你会这个"开始的。
我也试过，但坚持了两天
受这个启发，我也开了一个飞书文档，打算按天记工作日志。
第一天写得挺认真，第二天写了几行，第三天就忘了。
后来想想，问题出在"写"这件事上。每天下班前要专门打开文档、回想今天做了什么、整理成文字——这个动作本身不难，但偏偏要在最累的时候做，就很难坚持。
后来因为有周会，会前得准备周报，这件事就变成了每周一次的强制复盘。工作日志就这么搁置了。两天的记录，也没好意思挂出去。
一次开会前的周报
这一年我的编码工具换了好几轮：Visual Studio → Cursor → Codex + VS Code → Warp + Claude Code + VS Code。
每次换，都是因为觉得下一个更顺手一点。现在用的是 Warp + Claude Code + VS Code 这套组合，大部分的代码工作都经过 Claude Code——不只是写代码，方案设计、调试思路、写文档，基本都在里面。
有一次周会前，我懒得自己整理周报，就让 Claude Code 帮我写。
效果出乎意料地好。它不只看了 git 提交记录，还翻了过去几天的对话记录，甚至把 git stash 里没提交的改动也一起概括进来了。有些探索性的工作，方向试了一半放弃了，压根没有 git 提交，但它在对话里都能找到痕迹，也给整理进去了。
我当时看着那份周报，觉得比我自己写的要完整。我自己回忆的时候，很容易只记得最近两三天，更早的事就模糊了。但对话记录一直都在，它全找出来了。
那次之后我就想：工作日志这件事，现在可以重新做了。不是靠自己每天去写，而是让它帮我自动记。
为什么选 Notion，不用飞书
我们公司日常用飞书，但我最终还是选了 Notion 来记工作日志。
主要原因是，这份日志我暂时不打算公开，就是给自己看的。用一个和公司平台分开的地方，心理上会更自由一点，写起来也更随意。
做 Skill 的过程
想清楚之后，我开始动手。我想做的就一件事：每次工作结束，不用我操心，自动把这次做了什么写进 Notion。
最开始的方案是：session 结束时，让我手动说一句"写今天的日志"，然后 Claude 来整理写入。这个方案能用，但依赖我自己记得说这句话——和之前手动写日志的问题一样，迟早会忘。
然后草稿放哪里也纠结了一下。一开始想放本地，session 结束就写一个本地文件，简单直接。但本地文件不方便随时查，也没法在手机上看。想想还是放 Notion，手机电脑都能看到，就是多了一层 API 调用。
确定用 Notion 之后，又想到另一个问题：每次 session 都往草稿区追加内容，时间长了会堆很多，不好整理。而且整理这一步我想自己来，不想让它全自动写进主文档，万一哪天整理出来的东西不对，还有机会改。
最后的方案是这样的：
- 每次 session 结束，在后台自动启动一个新的 Claude Code CLI，把本次 session 的摘要写进 Notion 的草稿区
- 这个过程是后台运行的，不阻塞前台，我不用等它
- 太短的 session（比如随手问了一个问题）不记录，只有实质性的工作 session 才写
- 第二天，我手动触发
/work-log，把草稿区的内容整理成正式的工作日志写进主文档
skill 的代码我放在 GitHub 上了：notion-worklog-skills
最终效果
整理之后的工作日志长这样：
按年 → 月 → 周 → 天的层级展开，每天的内容按项目或主题分类，最后有产出和今日总结。
现在我工作结束关掉 Claude Code，后台自动把这次的摘要写进 Notion 草稿区，我不用管。第二天闲下来，跑一下 /work-log，草稿就整理好追加进主文档了。
我唯一要主动做的，就是这一个命令。比之前每天下班后要回忆、要打字，轻松太多了。
这个流程跑到现在还挺顺，没有再出现做了两天就忘的情况。
至于要不要贴到飞书签名里——等积累够了再说吧。