维护者的时间账：1,180 个 issue、148 个 PR 与 612 小时

开源项目最贵的资源不是 CI 分钟，是那个每次都得回消息的人。

一、一年之后，时间去了哪里

2026 年 10 月，许砚做了一次年终复盘。他把日历、提交记录与 issue 时间戳导出来，按「这段工作是为了什么」分类，得到七栏。七栏相加是 612 小时，平均每月 51 小时，按 52 周摊是每周 11.8 小时。

这份记录不是一开始就有的。前半年他只有「感觉最近很忙」，直到一次连续三周没写代码，才决定从日历与提交时间反推。反推的结果比感觉准，也比感觉难看：他原以为每周花 6 小时，实际是 11.8。

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

这 612 小时里，有 210 小时花在 issue 分类上，占 34.3%；96 小时在 PR 评审，占 15.7%；74 小时在依赖与安全，占 12.1%；58 小时在发版，占 9.5%；92 小时在文档，占 15.0%；62 小时在社区问答，占 10.1%；20 小时在商务，占 3.3%。七个百分比相加是 100.0%。

这个分布和大多数人的直觉相反。 人们以为维护开源主要是写代码，实际上写代码在这个项目里几乎不占独立一栏——它散在发版与 PR 评审里。真正占大头的是「分类」与「解释」：issue 要读懂、要复现、要标优先级；文档要写给三种不同水平的人看。

年初的预算是 480 小时，每月 40 小时。实际用了 612 小时，超支 132 小时，超支比例 27.5%。超支没有发生在某一个月，而是每个月多出十来个小时；这种缓慢的超支最难察觉，因为它不会让人崩溃，只会让人再也抽不出整块时间做新功能。

超支的构成也值得看。132 小时里，约 70 小时来自「计划外的高危告警」，约 40 小时来自「一个大型 PR 的反复评审」，剩下 22 小时是文档追赶。三项都不是意外，只是没有提前留预算。

二、七类工作的时间表

把 612 小时按周拆开，会看到更具体的形态。issue 分类平均每周 4 小时，但分布极不均匀：发版后的两周会涨到 8 小时，平静期降到 2 小时。PR 评审平均每周 1.8 小时，但一个 400 行的 PR 就能吃掉 3 小时。

「触发方式」这一列比小时数更重要。可以预约的工作（发版、文档）能排进日程；无法预约的工作（issue、问答）只能靠批处理。把这两类混在一起排期，结果是每天都被打断，整块时间永远排不进去。

批处理的关键是固定时段，不是固定时长。每周二与周四上午各留 90 分钟处理 issue 与问答，其余时间关闭通知；这个安排不会减少工作量，但会把「随机打断」变成「可预期占用」。实测下来，同样 210 小时，批处理版本的上下文切换次数少了约 40%。

issue 分类的 210 小时对应 1,180 个新开 issue，平均每个 10.7 分钟。10.7 分钟做不了修复，只够做四件事：读标题与正文、判断类型、贴标签、写一句「需要什么信息」。这四件事看起来琐碎，但它们决定了这个 issue 会不会在三个月后变成一条「还有人在跟进吗」。

四件事里最省时间的是贴标签，最花时间的是写「需要什么信息」。后者不能用模板敷衍，因为用户往往不知道自己要提供什么；一句具体的「请附上 syncwell --version 与错误日志的前 20 行」，能省掉两轮往返。

周均 11.8 小时听起来可以接受，但它是最容易被低估的数字。它意味着每周有一个完整工作日被占掉，而且这一天是碎的：早上两条 issue，中午一个 PR，晚上一封赞助邮件。碎掉的时间不能用来写需要连续思考的代码。

这也是为什么「每周 11.8 小时」不能直接换算成「每周少上一天半班」。它更像每天少掉两个 40 分钟的整块，而不是少掉一个完整的上午；对需要深度思考的工作，前者的伤害更大。

三、612 小时与 1,920 小时

一年 1,920 小时是一个人的全部可支配工时（按每周 40 小时、48 周计）。612 小时占 31.9%，接近三分之一。这个比例决定了这个项目在你生活里的位置：它不是副业，是一个占掉三分之一产能的主业之一。

超支的 132 小时不是均匀分布的。复盘时发现的规律是：每合并一个外部 PR，平均带来 0.7 个后续 issue；每发一次版，平均带来 12 个新 issue。这两个系数解释了为什么「功能做得越多，维护越重」——不是功能本身重，是功能带来的解释成本重。

系数会随项目阶段变化。功能刚上线时，PR 带来的后续 issue 系数接近 1.2；半年后降到 0.7；如果文档补得上，能降到 0.4。这个下降不是自然发生的，是文档与模板投入的结果。

开源维护的复利是负的。 代码写得越多，需要解释的边界越多；用户越多，重复问题越多；文档越全，需要同步的地方越多。这不是劝退，是提醒：如果不在某个点上做减法，612 会变成 800，再变成 1,000。

减法的顺序应该是：先砍「可以批量处理」的，再砍「可以自动化」的，最后才砍「必须人做」的。社区问答可以改成每周两次集中回复；issue 分类可以先用模板与机器人过滤；依赖告警可以合并成一个每周窗口。最后剩下的「必须人做」，才是真正需要你花时间的那部分。

减法要按季度做，不要一次做完。一次砍太多，社区会觉得项目在收缩；每季度砍一类，配合一次说明，反而更容易被接受。他试过一次砍掉整个中文问答渠道，结果是三个月内流失了 40 多个活跃用户，后来改回「每周一次集中回复」。

四、一次复算与三个被低估的成本

把七类时间换算成钱，会得到一个不太舒服的数字。按净时薪 32.1 美元计，612 小时的机会成本是 19,645 美元，而项目全年净收入是 19,671 美元。两者几乎相等——这意味着这个项目目前刚好覆盖自己的时间成本，没有产生额外盈余。

这个等式还有一个隐含前提：32.1 美元/h 是净时薪，已经扣掉了服务器与支付通道费。如果按毛时薪 38.2 美元算，机会成本是 23,378 美元，比净收入高 3,700 美元；两个结果方向不同，取决于你把自己的一小时算成毛还是净。

复算：
七类：210 + 96 + 74 + 58 + 92 + 62 + 20 = 612 h
占比：210/612 = 34.3%；96/612 = 15.7%；74/612 = 12.1%
      58/612 = 9.5%；92/612 = 15.0%；62/612 = 10.1%；20/612 = 3.3%
月均：612 ÷ 12 = 51 h；周均：612 ÷ 52 = 11.8 h
占全年：612 ÷ 1,920 = 31.9%；折算周数：612 ÷ 40 = 15.3 周
预算：480 h（40 h/月）；超支 612 − 480 = 132 h → 132 ÷ 480 = 27.5%
issue：210 h ÷ 1,180 个 = 10.7 分钟/个
机会成本：612 × 32.1 = 19,645 美元；净收入 19,671 美元；差 26 美元

复算里最值得注意的是最后一行。19,645 与 19,671 只差 26 美元，看起来像精心设计的平衡，实际上是巧合；如果明年 issue 涨到 1,500 个而收入不变，这个平衡就会被打破。

第一个被低估的成本是切换成本。七类工作里有五类是「被打断型」，每次切回来需要重新建立上下文。按每次 8 分钟、每天 3 次计，一年就是 104 小时，这部分没有出现在 612 里。

第二个被低估的成本是等待。一个 issue 从打开到关闭，中位时间是 26 小时首响、11 天关闭；这期间维护者虽然没在工作，但心理上一直挂着。这种「后台占用」不产生小时数，却会压缩真正能深度工作的时间。

后台占用可以用一个代理指标观察：周末打开仓库的次数。他的记录是平均每周 4.2 次，发版周 7 次；这个数字与「感觉累不累」的相关性，比实际工时更高。

第三个被低估的成本是文档同步。92 小时的文档时间里，有 60 小时是在改「已经写过的文档」，因为功能变了。文档不是写完就结束的资产，是跟着代码一起折旧的负债。

70 小时里有一半是在改截图。截图会随 UI 变化而过期，而过期的截图比没有截图更糟：用户会照着做，然后卡在一个不存在的按钮上。后来的做法是每张截图标注版本号，发版时只重拍受影响的几张。

切换成本可以用一个简单实验测：记录每次被打断后，重新进入工作状态需要多久。他的记录是 6 到 11 分钟，中位 8 分钟；如果一天被打断 3 次，就是 24 分钟，一年约 100 小时。

五、行动清单与复算验收

• 连续两周记录每次维护动作的类别与分钟数，别凭记忆估。
• 把七类工作按「可预约」与「被打断」分成两组，各算占比。
• 用年工时除以 1,920，得出这个项目占你多少产能。
• 把年工时和年初预算比一次，算出超支比例。
• 统计每合并一个 PR、每发一次版分别带来多少新 issue。
• 选一类「可批量」的工作，改成固定时段集中处理，观察两周。
• 把「必须人做」的工作单独列出，写出它为什么不能交给别人。
• 用净时薪乘年工时，和项目净收入比一次，看是否覆盖时间成本。

验收标准：任取一周，都能说出维护时间花在哪七类、哪几类被打断、哪几类可以批量。

前四条是「把时间记准」，后四条是「把结构改掉」。如果只有一小时，先做第一条：凭记忆估的时间，通常会漏掉三分之一。

清单里最容易被跳过的是第五条。PR 与发版带来的后续 issue 系数，是判断「这个功能值不值得做」的最直接依据；没有这两个数，功能评审只能靠感觉。

使用边界与实操验收

612 小时是一个样本。 换成 star 更多或更少的项目，绝对数会变，但七类的比例结构通常相似：分类与解释占一半以上。

小时数不等于工时。 这里的 612 小时包含碎片时间，不包含心理占用与切换成本。真实负担通常比数字高 20% 左右。

不要用「热爱」抵扣成本。 热爱可以解释为什么愿意做，不能解释为什么收入覆盖不了时间。账要分开记：情感账记热爱，现金账记 32.1 美元/h。

减法有代价。 关掉某个渠道的问答、拒绝某类 PR、减少发版频率，都会让一部分用户失望。减法的目的不是省钱，是把时间集中到「只有你能做」的部分。

减法也不是永久的。砍掉的渠道可以在项目稳定后恢复，砍掉的功能可以在有人愿意维护时加回；关键是每次砍都要写清「为什么砍、什么条件下恢复」，否则一年后没人记得当初的判断。

时间账要先于收入账。 一个项目月入 5,000 美元但吃掉 100 小时，时薪是 50 美元；另一个月入 1,949 美元但只吃 51 小时，时薪是 38.2 美元。前者总收入高，后者结构更轻；先看时间，再看收入，顺序反了就会做出错误取舍。

关键参考与核验范围

• Open Source Guides：维护者角色 ：用于核对维护者职责与治理结构的常见划分。
• GitHub Docs：管理仓库设置 ：用于核对 issue 模板、标签与仓库配置的落点。
• Keep a Changelog ：用于核对发版说明的结构，减少重复解释。

以上链接于 2026-10-26 实测可公开访问；未核验版本、功能范围与政策更新。核验日期：2026-10-26。

范围上只讨论一个人维护开源项目的时间结构、预算与减法顺序，不讨论团队分工、雇佣维护者与基金会治理。

系列导航

• 上一篇：Open Core 边界：78% 的代码开源，22% 才收费
• 下一篇：Issue 分类：10.7 分钟一个、72 小时首响与 134 个遗留
• 回到目录：一个人的开源产品：4,200 个 star、一百八十个付费与一年 612 小时的维护
• 相关阅读：一个人的运维：可用性、告警、事故与值班