Lessons

先把话说公道:Excel 是一台优秀的计算器,PPT 是一台优秀的放映机。这一章要拆的不是它们,而是一个动作——把文档作为附件发出去。一份文档一旦被附件发出,它就不再是「一份文档」了:每个收件人手里都是一个看起来一样的不同对象。从那一刻起,「哪一份是最新的」这个问题就失去了机械答案,只能靠资历、记忆和嗓门来裁决。

于是团队会自发长出一套补偿机制:命名规范(_最新、_修正、_v2_final)、共享盘、一位「记得住的人」。把这套机制摊开看——它就是一个没有 diff、无人维护、靠自觉运行的版本控制系统。它的每一条土规矩都在试图回答同一个问题:谁,在什么时候,改了什么,为什么。而这个问题,git 在二十年前就已经机械化地解决了。这一章不要求你换工具,只要求你承认:你团队里那套命名规范,是在为一个已经有答案的问题重新发明答案。

把文档换成纯文本、放进版本控制,具体多出六件事:每一行知道自己是谁写的;每一次改动都带着一句说明它为什么发生;任何一个过去的状态都能用一条命令取回;提案可以和现状并存,而不必「另存为」;讨论挂在具体的那一行上,而不是漂在聊天记录里;以及——文档可以被机器检查,链接死没死、术语一致没有,都能在合并之前被拦住。

这里有一个反直觉的点值得当众说破:这六件事没有一件是 Markdown 的功能。Markdown 的贡献只有一个——让 diff 有意义(二进制文件也能存进 git,只是 diff 出来是一团乱码)。真正给出这六种能力的,是「只有一份,且每一次改动都被记录」这件事本身。所以格式之争是小的那一半,存放地之争才是全部。理解了这一点,你就不会在「非要用 Markdown 吗」这种问题上浪费一场会议。

前两章讲的是「文档该放在哪」,这一章讲「谁来搬」。挡住绝大多数团队的其实是三件很具体的事:三年的 Excel 转成纯文本要人力;每天的日报要人写;而且对外交付,老板要的还是那份 PPT。这三件现在都能交给 agent——它读得懂 git 历史、能读写 xlsx 和 pptx、也能按规则批量改文件。

agent 在这一层的位置很具体,值得说清楚两句。第一句:日报不是写出来的,是投影出来的。当输入是提交记录、工单状态、门禁结果这些既成事实时,生成日报是一次派生,不是一次创作。第二句:真相和交付物可以分开。内部用纯文本管真相,要交 Excel 时再从同一份真相导出——于是「对外还得给 Excel」这件事,不再构成把真相留在 Excel 里的理由。这两句合起来,就把这一章的迁移成本从「换一套工作方式」降成了「多加一个导出步骤」。