分享一个我为了在公司推行“公开构建”而搞的记录流

想在团队里推行 Build in Public 这种文化，最难的不是让大家意识到分享的重要性，而是怎么在不增加打工人负担的前提下，把活儿给记录下来。

之前我们尝试让组员在做项目时随手写博客，结果惨败。原因很简单：一个程序员在死磕了一整天 Bug 之后，面对空白的编辑器，写一篇“体面”的总结简直是一种精神折磨。这种心理负担会导致大家开始逃避，一旦断了一周，之前的技术细节全忘了，最后只能写出一些毫无营养的废话。

为了解决这个问题，我把记录拆成了两个完全不同的维度：

一、 极低成本的碎片化采集（Daily Capture）
要求大家在每天结束工作时，花 1 分钟在各自项目的 build log 里写 1-3 条原始要点。

• 只写 bullet points：发生了什么，为什么有趣，相关链接。
• 禁止写正文：不需要考虑读者，不需要润色。
• 非强制内容化：没出成果就不写，拒绝为了更新而更新。

二、 定期的知识提纯（Weekly Distill）
每周五抽出固定时间，从这一周的碎片记录里挑一个有价值的切入点，扩充成一篇完整的技术文章。因为细节已经在 build log 里存好了，这时候写文章是“创作”而不是“回忆考古”。

在这个过程中我也踩了个坑。最开始我想把所有人的记录汇总到一个中心文件里，结果发现这样违背了开发习惯（记录不在项目目录下）。后来我用 Obsidian 的 Dataview 插件解决了，让每个人在自己的项目文件夹里写 log，然后通过一个动态索引页面把所有更新自动汇总。

这种把“记录”挂载到现有工作流（比如下班前的 Roadmap 更新）中的做法，比单纯靠意志力坚持要有效得多。目前团队的 AI 实践案例多了不少，关键是大家不再觉得写文档是个累赘。