你有没有过这种经历博客草稿箱里躺着十几篇写了一半的文章每篇都想写成精品教程结果一篇都没发出来我曾经就是这样的状态。想分享点什么总觉得素材不够全、验证不够充分、例子不够漂亮越攒心理负担越重最后干脆不写了。后来我改成了一种叫 TILToday I Learned的记录习惯用完全不同的思路做知识沉淀反而坚持了将近两年累计整理了几百条短记录其中不少后来还被扩展成了正式文章或直接在工作中派上了用场。这篇内容想聊的正是这件事TIL 到底是什么它和传统博客写作的本质区别在哪里以及怎么搭一套真正能长期跑下去的 TIL 工作流。如果你也在为输出太难坚持或学了就忘而焦虑这篇文章应该能给你一个低成本的替代方案。1. 博客写作的门槛与 TIL 的诞生逻辑1.1 为什么系统化输出会劝退大多数人先从我自己的问题说起。很早以前我就知道输出倒逼输入这个说法也尝试过写技术博客、整理文章合集。但每次打开新文档脑子里冒出来的第一个念头不是我要记录什么而是这篇文章发出去读者会怎么评价。这个念头一出现写作就没有了轻松的样子。具体来说传统博客写作有几个天然的高门槛选题要够格总觉得内容得足够系统、足够独特别人才有看的必要。于是很多有价值的零散经验因为太小被自动过滤掉了。结构要完整一篇体面的博客要有背景、有步骤、有结论、有截图或代码逻辑链不能断。把一次简单的踩坑整理成这种完整结构成本高得吓人。发布心理压力大文章一旦公开就要接受各种角度的审视。哪怕只是错了一个标点都可能被评论区指出来。这种压力让很多人养成了写完了但不敢发的习惯。我身边不少朋友也是这样包括一些明显比我有经验的人。他们的博客停在 2019 年不是没东西写是每次想写都得等一个大块时间而这个大块时间永远不出现。1.2 TIL 的核心理念给知识一个最低成本的落脚点TIL 能解决这个问题核心在于它主动放弃了系统化这个包袱。TIL 的原始形态特别简单每天或每当学到某个新东西时用几分钟把今天学到了什么原原本本记下来。不追求结构完整不追求读者感受甚至不追求观点正确——只追求一个动作把学到的内容落实成文字。我第一次听说这个概念是在一些开发者社区里看到有人分享自己坚持了几百天的 TIL 仓库——按日期分类的 Markdown 文件每条记录通常只有几行到几十行。有人记录一个快捷键有人记录一个 API 的坑有人记录某个工具的配置方式。没有长篇大论但每一条都是真实的、经过验证的个人经验积累。当时我正好有一件小事想记某个构建工具在特定版本下会忽略配置文件里的某个字段排查了一个下午才靠对比老版本找出来。按以前的习惯这件事得写一篇问题排查全过程才能发博客但当天实在没精力。我就学着 TIL 的做法只写了四行现象、原因、解决、参考链接然后扔进仓库里。神奇的是接下来一个月我真的持续记录了 20 多条。不是因为突然有了意志力而是因为这个习惯的启动成本实在太低了——低到不需要任何仪式感打开编辑器写几行就行。TIL 的诞生逻辑简单说就是先保证记录动作的低成本高频次再谈知识的深度加工。这比一上来就要憋大招的博客写作在可持续性上强太多了。2. TIL 与博客的本质差异频率、成本与反馈回路2.1 从作品思维到记录思维很多人在写东西这件事上被卡住本质上是被作品思维绑架了。作品思维默认每一篇输出都代表你的水平所以你得对每个细节负责。而记录思维完全不同它默认每条记录只是你个人知识库的一次增量备份不需要对任何人负责。这两种思维带来的行为差异非常大。我整理成了一张表你可以对照着看自己更像哪一种对比维度作品思维博客记录思维TIL写作频率通常每周或每月一篇尽量每天一条单篇成本数小时到数天5 到 15 分钟内容范围系统化、通用性强碎片化、个人化心理压力担心被评价几乎没有价值判断以阅读量为准以是否记住了为准容错空间错别字都被放大改起来毫无心理负担这不是说博客不好。而是说博客是沉淀之后的重型输出TIL 是学习过程中的轻量输出。两者的定位本来就是不同的。你完全可以两个都做但如果连轻量输出都没跑通硬撑着做重型输出大概率是三天打鱼两天晒网。2.2 反馈回路的设计差异一个习惯能不能坚持和反馈回路的长度有直接关系。博客写作的反馈回路太长了写一篇文章可能需要两天发布后要等几天才能看到阅读数据再等更久才能验证这篇文章有没有实际帮到别人。这么长的反馈周期对意志力是巨大的消耗。TIL 的反馈回路短得多——你当天记录完当场就能感受到这个东西我确实搞懂了的踏实感。更妙的是TIL 会形成一种类似连续打卡的心理效应。当你坚持到第 30 条、第 100 条的时候你会开始期待下一条因为你不想打断这个统计曲线。稳妥起见打个比方这有点像我以前玩养成类游戏每天做一次简单任务就能看到进度条涨一点做完就觉得很满足根本不需要等到通关才有快感。我自己还有一个额外的反馈机制每周固定抽十分钟把这一周的 TIL 快速扫一遍顺手把其中一两条补全成可以直接对外分享的说法。这个过程相当于给本周的碎片经验做了一次轻度蒸馏既巩固了记忆又为自己积累了一堆可复用的素材。这种双回路——每天记录、每周提炼——让整个系统始终处于有反馈的状态持续运转也就不难了。3. 我的 TIL 工作流从捕获到沉淀的完整链路3.1 捕获环节什么时候该记一条 TIL很多人以为 TIL 必须每天都记于是没东西学的时候硬凑有了倦怠感。我的体会是TIL 的核心不是每天而是学到的当下就记。换句话说它应该是被动触发的而不是主动编排的。我给自己定的捕获标准只有三条满足任意一条就记解决了一个具体问题比如知道了一个错误信息是什么意思、找到了某个软件的字段配置。颠覆了一个旧认知比如发现自己一直用的方法其实是反模式有更优解。发现了一个可复用的技巧比如某个快捷键、某段命令、某种模板下次可能还能用。这三种情况里第三种最常见也最容易漏掉。很多技巧在当时看起来不值一提但三个月后真的需要的时候你已经忘了是在哪里看到的。TIL 的意义很大程度上就在这里——它给你的记忆外置了一个随时可查的增量备份。捕获工具我建议遵循随手可用免切换两个原则。我自己用的是手机上的备忘录加电脑端编辑器双入口白天在工位上想到就立刻写进本地 Markdown 文件通勤路上用手机记几条关键词晚上到家再补成完整条目。你未必需要专用的知识管理软件只要保证从脑子里冒出这条经验到它落到文字的路径足够短就行。3.2 整理与归档轻量目录结构的设计TIL 的记录量一大目录结构就很重要了。但这种整理绝不能复杂到妨碍记录本身。我的方案是这套三层结构til/ ├── 2025-01/ │ ├── 20250106-shell-变量展开陷阱.md │ ├── 20250108-postgresql-索引失效场景.md │ └── ... ├── 2025-02/ │ └── ... └── README.md文件名统一是日期-主题-关键词拼音短串.md按月份建文件夹。这个结构的最大好处就是完全不需要思考往哪放——今天学的就放到当前月份文件名随手敲几个能代表内容的词就行。等到积累几个月后要检索时直接搜关键词就能定位到对应的文件根本不需要维护复杂标签体系。我见过有些人把 TIL 仓库设计成了带数据库、带标签系统、带双向链接的复杂网络结果每天光整理结构就要花半小时。这种系统两周内必定吃灰。对一个记录习惯而言整理成本必须低于 10% 的记录成本否则它就会从习惯变成负担。3.3 发布与备份三种可选方案TIL 虽然不求读者但建议还是保留一份可分享的副本。原因有两个一是本地文件总有丢失的风险二是当你想把某条 TIL 转化为正式博客时一个公开地址的条目标题会更方便你引用和回溯。主流的做法大致有三种我按适用人群给你列一下方案适合人群优点缺点公开代码仓库开发者、习惯用 Git 的人免费、版本管理内置、Markdown 原生有公开压力可能抑制记录意愿私有笔记库如本地笔记软件注重隐私、不习惯公开无压力、自由度高少了外部激励机制静态站点生成有搭建个人站愿望的人自动化程度高、可控性强初期配置成本稍高我自己选择的是本地记录 定期同步到私有仓库的组合。平时记录的草稿和最终整理的条目分开存放草稿完全私密只有当我确认某条内容准确、有价值时才会整理成正式条目推送到仓库。这样既保住了记录的随意性又保留了一条可公开的沉淀路径。4. 一条好的 TIL 应该长什么样4.1 结构模板Lessons / Why / Refs有些人把 TIL 当成一句话朋友圈来记比如今天学会了 X 命令。这当然比什么都不记强但它存在的问题是三个月后翻出来你只知道自己学过它却想不起来当时是在什么场景下学的、踩了什么坑。这等于存了没有上下文的知识检索时根本想不起来用它。我的 TIL 模板是在实践里逐步改出来的现在固定为三段式非常轻但信息量足够What结论用一两句话说清楚你学到的东西是什么。Why原因或场景当时遇到了什么问题为什么这个结论成立如果只有结论没有原因这条知识就是无根的。Refs参考与复现放一个可复现的命令、配置片段或链接确保自己或别人能照着做一遍。举个真实的例子这是我早期记录的一条关键信息做了脱敏# 20250106 shell 变量展开陷阱 What: 在使用双引号包裹时$ 开头的变量仍会被展开 若想保留字面 $ 需要用单引号或转义。 Why: 构建脚本里想让某个参数原样传给下游工具 结果被本地 shell 提前展开了。排查时对比了单双引号 行为才锁定原因。 Refs: echo $HOME vs echo $HOME前者输出路径 后者输出 $HOME 字面量。这条记录我后来至少翻阅过三遍每次都能在十秒内恢复完整的上下文。而如果是当初在博客里写全过程可能反而会因为太啰嗦而懒得回去看。4.2 好 TIL 与坏 TIL 的对比案例为了让你更直观地感受差异我放一组对比。同样是记录正则表达式里的懒惰匹配两种写法差距很大坏例子今天学了正则的懒惰匹配.*?可以匹配尽量少的内容。好例子What: 正则中 .*? 是懒惰匹配意思是尽量少地匹配字符 .* 是贪婪匹配尽量多地匹配。 Why: 解析 HTML 片段时想取两个标记之间的最短内容 一开始用 .* 把整段吞掉了改用 .*? 才对。 Refs: 在 Python 的 re.findall 中试过 re.findall(rb(.*?)/b, ba/b...bb/b) 返回 [a, b]如果用贪婪则只返回一项。坏例子的信息量只有一句结论而好例子同时保存了为什么需要这个知识点和怎么快速验证。同样花三五分钟记录后者的长期价值至少是前三倍的差距。说白了TIL 记的不是结论而是你获得这条结论的上下文。5. 坚持不下去的常见原因与我的解决方法5.1 完美主义与不值得记的心态我现在翻看自己的 TIL 历史发现最大的废弃时刻都出现在同一种心态里——这条太简单了吧也好意思记有一次我卡在一个软件的证书配置上两个小时最后发现只是少加了一个换行符当时的第一反应是这种东西记下来会显得自己很蠢。后来我想明白了一件事TIL 不是简历不需要显得聪明。它真正要服务的对象是未来的你而未来的你大概率会在同样的问题上再卡一次。你说它简单换行符那个问题半年后我同事遇到时我从仓库里翻出记录十秒内给他指了路。当时如果因为太简单没记我就又要从头排查一遍。我的解决方法很简单给所有简单但磨过人的经验单开一个前缀比如文件名里加tiny-前缀。这样既不影响正式条目的调性又暗示自己这种就是专门给笨的时候准备的。心态上轻松多了记录率也稳定了。5.2 记录工具碎片化问题另一个常见问题是工具太多、记录分散。今天记在备忘录里明天写在笔记软件里后天又用聊天工具的文件传输助手发给自己。结果到月底想整理时满世界找记录整理成本翻倍最终干脆放弃。我的经验是入口可以多但出口只能有一个。也就是说无论你在哪里临时记录手机备忘录、聊天框、纸质本子都可以每周必须有一个固定时间把所有临时记录统一收拢到你的 TIL 主仓库。这个每周整理动作是我整个工作流里最不可省略的一环。我习惯放在周五下午的尾巴上花十五分钟一台电脑一个文件夹把这一周的碎片全部归档。过了两个月你就会发现所谓的碎片化问题其实只是缺了一个固定的汇集动作而已。5.3 只记不读的仓鼠病记录习惯养成之后还会遇到一个新问题光是记、重来不看仓库越堆越大但你的知识水平并没有提升。我把这种状态叫仓鼠病——拼命往窝里囤东西却从不真正吃掉它们。治仓鼠病的办法是我前面提到的周提炼。每周整理临时记录时我会顺手做一件事挑出本周最有价值的那条 TIL给它补上一段如果要把这条讲给别人我会怎么说的内容。有时候这段内容其实就是三句话但因为写了这三句话那条 TIL 就从一个被动存档变成了一个你可以随时调用的表达。不定期把这些表达升级成博客片段顺理成章地完成了从 TIL 到正式写作的转化。6. 从 TIL 仓库到个人知识体系的复利效应6.1 检索、聚合与主题重构坚持大半年之后TIL 仓库的第一个价值开始显现检索。某个工具怎么用的、某个参数的含义、某种报错的解决方法过去我依赖浏览器搜索现在优先搜自己的仓库因为里面存的都是我实际验证过的经验准确率反而比很多水文高。第二个价值是聚合。当你的一两百条 TIL 散落在一个主题周围时它们会自动拼出一张图。比如我从来没有专门学过某个框架的部署细节但我的 TIL 里积累了关于它的配置、踩坑、优化、版本对比十几条某天我需要给别人讲这个框架时直接把这些记录按时间顺序读一遍就是一篇有真实经验做底稿的文章雏形。主题重构是我觉得最值钱的一步。每攒够七八条同一主题的 TIL我就抽一个下午把它们重组成一篇完整的博客。由于所有素材都是我自己踩过坑之后写的重组过程极其顺畅通常一两个小时就能成稿。换句话说TIL 不是博客的替代品而是博客的素材工厂与初审编辑器。6.2 TIL 与博客的协同关系最后想说清楚把 TIL 放在博客的对立面其实是个误会。真正可持续的路径是TIL 打底博客拔高。TIL 负责每天都让你的知识系统有增量博客负责在你准备好的时候把增量凝结成作品。它们在反馈周期上互为补充在内容深度上逐级递进。我自己经常做的事是查看三个月前的 TIL 里有没有值得转正的记录。转正的标准很简单这条经验是不是让我后来避免了一次踩坑如果是它就可能对别人也有用我就把它扩展成文章。如果我的任何一篇博客背后没有 TIL 素材支撑那多半是硬写出来的空话。最后再分享一个小技巧是我踩了不少坑之后得出的别把 TIL 当成任务把它当成给未来自己留纸条。你在今天某个卡壳瞬间的灵光一现可能正是三个月后的自己迫切需要的线索。用最轻的方式把它留下来未来的你会感谢现在的你。