一个人管多家公司：我的工具与工作流

这是一篇示例文章，用来演示代码块高亮和行内代码排版。

同时管几家公司，最大的问题不是工作量，是上下文切换的成本。从一家公司的财务问题切到另一家的技术问题，光是想起“上次说到哪了”就要十几分钟。

我的解决办法是把所有需要记忆的东西都挪出脑子。

原则：所有状态都要有一个唯一的落点#

每一类信息只有一个权威位置，不允许同一件事存在两份“当前状态”。

• 经营、治理、知识 → 一个知识库
• 执行层的运维和派单 → 各自公司的后台系统
• 文件本体 → 云盘，知识库里只放索引

这条规则我花了大半年才真正执行下去。之前同一份数据在三个地方各有一版，每次都要先花时间判断哪个是对的。

每天的入口只有一个#

工作日志用最笨的方式：在手机上发一条消息，自动落到知识库。

# 发给助理机器人的一条消息，前缀决定它落到哪
记 #jolt 和运营确认了下周的排班口径

关键是强动词前缀。不用自然语言理解去猜意图，前缀是什么就走哪条分支，出错了我立刻知道是哪一步错的。

早期我试过让模型自己判断该记到哪，结果是它有时候会假装记录成功——日志里看着正常，实际什么都没写进去。查了很久才发现。从那之后所有写入路径都改成确定性脚本，模型只负责整理文字。

报告自动化：只做会重复的#

判断一件事值不值得自动化，我用一个很简单的标准：

这件事一年会发生多少次？乘以每次花的时间，超过一天就自动化。

按这个标准筛下来，真正值得做的其实不多。我目前跑着的只有三类：

其余想过的都没做，因为算下来不划算。

一个反例#

我曾经花了两天做一个自动汇总周报的东西。它每周省我十分钟，一年不到九个小时——两天的开发时间要三年才回本，而这套流程大概率活不过一年。

这是典型的“因为能做所以做了”。

定期检查自动化本身#

自动化最危险的地方是它悄悄坏掉而你不知道。我的做法是每月一号跑一次自检，把所有定时任务的最近执行状态推给我。

# 每月 1 号 09:00 自检并推送结果
0 9 1 * * /usr/local/bin/self-check.sh

有一次一个依赖的模型服务下线了，整条链路停了十天我才发现——就是因为当时没有这个自检。