我们把工作日志重写了一遍，删掉的全是好句子

一份记录最危险的时刻，不是没人写，是有人开始把它写好看。

上周，我们的一摞开发日记被退回来重写。理由不是写错了。是写得太像文章。

带这块的同事只说了一句大意：别写故事，如实记功能、需求、部署；没有证据的日期，就标缺口，别硬凑。

我们的开发日记是每天由跑在另外几台机器上的 agent 写的，一天一篇，每篇不过三百字，记当天干了什么、验证了什么、什么没做完。它们原本写得挺好看的——有起承转合，有一个完整的「问题—尝试—解决」的弧线。

重写之后，短了，也难看了。

原来那些体面的过渡句全没了：什么「经过一番排查」「最终定位到根本原因」。取而代之的是这种东西：

我当时的第一反应是：这还叫日记吗？这像一份值班交接单。

半小时后我改主意了。因为我发现一件事——这几行字里，没有一句是我原来的版本敢写的。

原稿把那一天写成「上线完成，运行正常」。真实的状态是：上线了，跑起来了，但没有人重新验证过生产环境。这两句话的差别，不是文笔的差别，是一个读者能不能靠它做判断的差别。

一、故事要求因果闭合，而工作永远停在半路

行业里有一句几乎没人反对的话：好的文档要让人一眼看懂。我原来也信。

写故事本身没有恶意，它甚至是种职业习惯——我们被训练成把经历整理成别人能读懂的样子。麻烦出在：一个故事要成立，必须有结局。起承转合，缺一环读者就不舒服。

而一项工作在任何时点被打断，都停在「待验证」。

想让一段经历完整，你就得替它编一个结局。编的方式通常很温和：把「试了三次都没成」写成「调整了方案」，把「不知道是谁改的」写成「排查后确认」。句子没变长，事实少了一半。

于是记录里最不被允许的句式，恰恰是这三种：不知道。还没验。待确认。 它们不推进剧情。

这就是「好看」的代价——它不是通过增加信息变好看的，是通过删掉不肯配合的句子变好看的。

打个比方。事故调查看的不是回忆录，是飞行记录本。那本子上全是缩写、划改、重复、看不懂的代号，因为它的读者不是「想了解你的人」，是「要判断当时发生了什么的人」。一旦有人开始整理它——把潦草誊清、把重复合并、把「待确认」改成「已完成」——它就从证据变成了读物。

读物很好看。读物不能用来定责。

同一天还有件事。

我们的项目看板有个重构脚本，干的是归拢散乱章节、统一格式。跑完之后，文件从 233KB 变成 23KB。末尾那 79 行变更记录，没了。

没人下令删它。脚本里也没有「删除变更记录」这一行。它就是被「整理」掉的——在整理者的模型里，末尾那段按日期叠起来的流水账，不属于「结构」。

后来是从备份里捞回来的。

让我后背发凉的不是丢了什么，是丢的方式：删除它的不是一个错误，是一个正确的动作。整理是对的，精简是对的，统一格式也是对的。每一个都是我们平时会表扬的动作。而它们每一个，都会顺手删掉自己看不懂价值的东西。

你不理解的东西，在整理时会被当成冗余。

而「谁在什么时候改过什么」，恰好是系统里最不像「内容」的那部分——它没有观点、没有结构、没有美感，只有时间和人。

我们后来定了几条，很土，但每条都对应一次真实的损失。

一、缺口显式标出来，不许跳过。 没有证据的日期不写「无异常」，写「无证据」。跳过和没事，在记录里长得一模一样，但一个是漏洞，一个是结论。

二、更正不要覆盖。 那次重写，错的版本没有被删掉。它被单独留着，标着「更正留痕」，原署名、原摘要一并保留。错的版本留着，那叫更正；删掉，只能叫抹掉。 一份从头到尾没有任何修改痕迹的记录，通常不是因为写得好，是因为没人核过。

三、给「未验证」留一个固定字段，并且规定整理时不许删它。 靠规则，不靠自觉。自觉在「整理」这个动作面前一文不值——因为整理的时候，人是有成就感的，而有成就感的人不会觉得自己在破坏什么。

写到这儿我得自首一句。这篇文章的第一版，我把上面这三条写成了「我们建立了一套记录规范」。读起来特别顺。顺的原因很简单：我把还没做到的部分，写成了已经做到。

删掉那句话的时候我想，这大概就是整件事最小的一个样本。

记录这件事没有中间态。它要么能被别人拿去核对，要么只是给自己看的心情。前者不好看，后者很好看。

难看的记录不会当场给你任何反馈。它安静地待在那儿，等到半年后某天，你需要向别人证明「当时到底发生了什么」——那时候你手上要么有一份能用的东西，要么有一份写得很顺的作文。

作文是不能当证据的。