程序员节容易让人想起一组漂亮的词匠心、极致、突破、未来。写技术文章时我更愿意把这些词先放到一旁看一眼文章末尾有没有留下具体的运行条件代码出错时有没有一个能复现的输入。工笔画需要底稿。技术分享的底稿是证据。它不一定是一份庞大的测试报告也可能只是一个失败用例、一段命令输出、一条能找到原始含义的规范链接。少了这张底稿再整齐的结论也容易被风吹走。版本号后面还有几个字Vue在10月23日发布的3.6.0-rc.13带有候选版标记。对于喜欢追新框架的人这不是扫兴的注脚而是理解文章边界的一部分。介绍新能力可以写为什么值得试、准备怎样试、迁移会遇到什么。没有跑过的代码就不要附上一张仿佛已经验证过的性能表。使用候选版也不必把自己包装成已经完成大型生产改造的先行者。问题越新坦率的限制越能帮到后来者。图里的三个抽屉是我希望一篇技术笔记能够分别交代的事做了什么、凭什么这样说、还有什么不知道。不是每篇文章都要做成论文但不能让语言的气势替代这三件事。原始证据与解释各有自己的位置性能图可以裁掉与问题无关的区域结论却不能裁掉设备和测试条件。命令输出可以摘录失败的那次运行不能因为不好看就假装没有发生。示例里用的合成数据也应在它出现的地方说明而不是放到很远的角落。面向10月的DevTools月报展示了更方便的性能分析与Agent调试工具。工具越能自动生成解释我们越需要分清哪一部分是原始事件哪一部分是模型或人的判断。读者需要能够沿着解释回到证据而不是只能相信一段听起来熟练的总结。这也适用于没有代码的随笔。一个茶盏、一段夜色可以表达感受不需要为它编出某家公司的千万级流量战役。写作者可以有审美也可以有犹豫。“这个做法我还没在移动端测过”往往比“所有场景都丝滑稳定”更有用。给青年工程师的一点具体建议遇到陌生API先读签名再做最小实验遇到很大的收益数字先问比较条件遇到异常不急着把它解释成某种框架的宿命。把问题缩小到可以观察的范围是一种需要练习的能力。如果今天只能整理一篇笔记不妨把它留成别人可以继续工作的样子版本写清输入给出失败保留引用指向原处。最后写一句范围明确的结论让后来者知道自己站在什么地方。程序员节快乐。愿我们的文字不必很响亮但交给别人的代码、判断和限制都有着落。本文是技术写作随笔没有宣称生产实测、个人项目业绩或全月发文数量提到的工具新闻与版本状态由所链接的一手页面说明。