看到一种现象没想通：明明写着公开的博客，又很怕“无关的人”看到，不想公开就设私密，或者干脆发朋友圈。

发公开博客，不就是想让大家来看么。

后来想了想，大概是每个人对“公开”的定义不一样：有人把博客当广场，希望人多；有人把博客当客厅，只请熟人。都成立，只是门开在不同地方。

我把门开在门口，想看就看；真不想给人看的，直接锁进抽屉。

我以前把“没有升级”理解成拖延，好像只要版本号还停在旧处，就说明维护没有跟上。

现在更愿意把等待也写进判断里。旧版本的健康检查通过，只能说明当前系统还能工作；上游版本的迁移和接口变化没有经过恢复演练，则说明升级的风险还没有被量出来。两件事同时成立时，暂缓切换并不是把问题藏起来，而是承认手里的证据还不够。

版本更新最终还是要做，但顺序不能只由“最新”两个字决定。先确认数据库备份能恢复，先把 API 兼容性和回滚路径走一遍，再安排窗口切换。等到可以回答“失败时退回哪里”这个问题，升级才不只是一次下载。

今天在工程软件的首页停了一会儿。

最近设计列表很长，电子纸转接板、无线串口工具、键盘、复制过来的工程文件和一些还没有继续往下做的实验项目挨在一起。它们都有名字，也都有最近更新时间。列表看起来像一条正在加速的进度条，我却不太敢把它当成项目进度。

文件先有了，项目才刚刚开始

一个工程出现在列表里，通常只说明它被创建过、导入过，或者最近有人打开过。它可以是一个临时的验证，也可以是一块从别人的工程复制出来、准备慢慢改的板子。文件名后面的 copy、版本号和日期能帮助我认出它，却不能替它回答：原理图是否完整，封装是否正确，关键器件有没有落地，或者这块板子有没有经过一次真实的测试。

以前我会把“已经建立工程”写成“项目开始推进”。现在会把两个动作分开：第一个动作只是把材料放到一个可以继续工作的地方，第二个动作才是对一个具体问题做了选择。哪怕只是确认一个触点、换一个连接器、把电源路径画清楚，也比在列表里多一个名字更接近进度。

最近更新时间很诚实，也很有限

工程软件会告诉我某个文件什么时候被保存，GitHub 会告诉我某个仓库什么时候有提交，语雀会留下某条记录的更新时间。这些时间都是真的，但它们回答的问题不一样。

一次保存可以只是改了一个名字，也可能是一次重要的布线调整。一次提交可能只更新说明，也可能刚好把一个长期卡住的接口接通。页面上的“更新于”没有办法替我判断这两种情况，更不能把它们排成一条看起来连续的故事。

所以我开始给自己的项目多留一个状态栏：这次改动解决了什么，下一步要用什么证据确认，当前还缺什么。状态栏不需要漂亮，甚至可以只写“已导入”“待测量”“仿真通过”“实物未验收”。它的作用，是防止我过几个月再打开时，把“我曾经想做”误认成“我已经做过”。

复制项目也有它自己的来路

列表里有不少带有复制痕迹的工程。复制不是坏事，很多硬件项目本来就从参考设计开始；真正容易出问题的是复制以后忘了补上自己的判断。

一块转接板从别人那里借来尺寸、封装和布局，不等于我的屏幕、排线和外壳也能照搬。一个无线模块的参考电路可以帮助我少走弯路，但它不会替我确认供电峰值、天线净空和实际连接器的方向。复制文件带来的是一个起点，不是一次验收。

我想把“参考来源”也写进工程记录里。哪一部分来自公开例程，哪一部分是自己测的，哪一处只是暂时猜测，最好在第一次修改时就留下来。后来如果发现引脚定义错了，至少知道应该回到哪一个来源重查，而不是在一堆复制文件里继续找一个看起来像答案的数字。

列表越来越长以后，我反而想做减法

工程变多以后，想法从来不缺，缺的是注意力——每一个名字都会分走一点。今天打开一个项目，想起另一个还没验证的接口；准备画一块新板，又担心上一块板的电源问题没有记录完。列表因此变成一种轻微的噪声：它不断提醒我还有很多事情，却不告诉我哪一件应该先做。

我现在会把工程分成三层。第一层是可以继续动手的项目：材料、问题和下一步都清楚。第二层是等待证据的项目：方向还在，但需要规格书、测量或一次构建才能继续。第三层是暂存和参考：它们可以留在仓库里，却不应该出现在本周的待办里。

这个分层不要求删除旧文件，也不要求把所有实验整理成漂亮的作品集。它只是把“存在过”与“正在推进”分开。一个暂存的工程不必被强行赋予结论，一次没有通过的测量也可以保留为记录，而不是用下一次保存把它盖过去。

真实进度通常不在列表最上面

项目往前走的时候，留下来的往往是一条不太显眼的证据：一张重新量过的尺寸表，一次知道为什么失败的测试，一根终于确认方向的排线，或者一段别人能够照着复现的说明。

这些东西不一定让列表看起来更热闹，却会让下一次打开工程时少猜一点。对我来说，这比把首页塞满“正在进行”的项目更有用。因为我最终需要的不是一份证明自己很忙的清单，而是一张能把手伸回现场的地图。

以后再看到工程列表变长，我会先问三个问题：这个文件来自哪里，现在能证明什么，下一步需要什么证据。如果只能回答第一个问题，它就还是一个材料；能回答到第二个，它才是一份记录；等第三个问题也有了明确动作，项目才算真的向前走了一小步。

今天复核手记列表时，发现一条很小、却很容易被忽略的问题：卡片标题已经显示了一遍，正文开头又用一级标题重复了一遍。

这不是文章内容多了一句那么简单。页面标题属于列表和详情的导航，正文一级标题属于文章内部结构；两个层级都在说同一件事，读者就会先看到一次，再被迫确认一次。以后候选稿的正文从二级标题开始，页面标题只留给外层组件。改完还要看列表、详情和缓存后的真实页面，不能只在 Markdown 文件里觉得“已经删掉了”。

E6 这种形态刚出来，很多家都在跟进：有做挂件的，有做便签屏的，少数派那边好像也在做。

7 寸以上的又太贵。看了一圈定价和预售，把产品做轻量、价格压低的这条路，反而更有优势——半成品敢直接拿出来卖还卖得动的，说明这个价位真的有需求。

自己做东西的时候，轻量化和成本这两关，也得从一开始就算进设计里，不能等画完板子再想。

早上做梦醒来，想到初高中为什么没有好好学习，呜呜呜。

中午外卖又送错了，来来回回折腾一顿，心里想的居然是：那我自己吃啥啊。

工程页面上的更新时间，和项目真正发生变化的时间，经常不是同一天。

文件被打开、名字被改掉、参考工程被复制过来，都会让列表出现一个新的日期；但真正的进展可能发生在更早的一次测量、一次提交，或者一句“这里还没有规格书”的判断里。它们都是真实时间，只是指向不同的事情。

所以我不想再用最近更新时间去铺一条看起来整齐的项目历史。以后写归档时，会把“页面更新”“代码提交”“实际验证”分开标出来。时间线不必漂亮，先保证读者不会把保存动作误认成完成结论。

今天独立解决了一道积分的题目。虽然还是看着公式套的，但也算是我自己套出来的啦。

沉浸下来的时候，时间过得真快。

我很喜欢一些博客的写法：从一个动作开始，写到一半允许自己改口，最后停在一个具体的选择上。这样的文字看起来松弛，背后其实很依赖作者自己的生活和证据。

我可以学习这种节奏，却不能把它当成一套皮肤。句子、标题、配图和第一人称经历都有来路。把别人的文章换几个同义词再发布，读起来也许像了，文章却没有自己的现场；更糟的是，它会把原作者的身份和表达一起带走。

以后外部博客只负责提醒我“可以怎样组织材料”：先写动作还是先写背景，哪里该停下来承认没做完，技术细节和日常感受怎样互相照应。真正进入我的文章的，应该是自己的提交、一次卡住的排查、一张确实拍过的照片，或者一条能够回读的备忘录。没有这些东西，就把它留在阅读笔记里，不硬凑成经历。

风格借鉴的终点不是更像某个人，而是更像自己说话时的停顿。

预约了明天下午的下午茶。嘿嘿。

券是之前攒的，8 月 30 日过期，终于赶在最后一周赶上了。周天去。

有些快乐就是这么小：一张快过期的券，一个正好空的下午。