你可能遇到过这种情况。
打开一个仓库，发现里面有几十个文件：有的从飞书搬过来的，有的是早期写的草稿，有的是半成品。它们格式不统一、结构不清晰、有些已经过时了。你意识到应该整理一下，但一想到要改几十个文件就头疼。
有两种方式可以处理这种局面。
第一种是"渐进式改进"：每天改几个，慢慢磨。优点是稳步推进，不影响日常节奏。缺点是战线拉得太长——第一个文件改了，最后一个文件还没动的时候，前面的风格可能又变了。改了三个文件后，因为别的事情中断一个月，回来发现前面的改动已经不敢确认是不是还在正确的方向上。
第二种是"批量维护"：关起门来，一次性处理完所有文件。优点是风格统一、逻辑连贯、一次到位。缺点是强度大，需要有人能在短时间内做出所有关键判断，而且必须有人有能力做这些判断。
这两种方式都是有效的。问题的关键在于：什么时候该用哪一种？
什么时候该批量维护¶
决定是否批量维护，主要看三个条件是否同时满足。
第一，底座还没铺好。 如果这个仓库已经运转了很久，文档基本完善，只是有些小修小补——那就用渐进式。但如果这个仓库还处在"草稿堆"阶段，结构没定、风格没统一、很多文件还是草稿状态——那就值得一次批量维护，把底座铺好。
判断标准：你是在原有的地基上装修，还是连地基都没打？前者用渐进式，后者用批量维护。
第二，判断标准已经清楚了。 批量维护需要有人能在短时间内对所有文件做出判断——这个该删、这个该改、这个该迁移到另一个仓库。如果这些判断标准还没想清楚，批量维护就会变成一个不断纠结的过程——每个文件都要重新思考"这个到底要不要"，效率不升反降。
判断标准：如果你拿到一个文件，三秒钟就能说出它该去哪——那就够了。如果你需要看五分钟还在犹豫——那说明标准还没形成，先想清楚再来。
第三，有足够的时间窗口。 批量维护是一次性的高强度投入，不能被打断。需要一段连续的、不受干扰的时间。如果时间被切成碎片，每次回来都要重新进入状态，那批量维护的效率比渐进式还低。
判断标准：你有一段至少连续数小时的时间吗？有的话可以。如果只有零散的半小时，那不如去做渐进式改进。
设计者注： 这三个条件缺一不可。如果底座没铺好但判断标准不清楚——先想清楚再来，不要图快。如果底座没铺好但没有时间窗口——先别做，等时间窗口出现。如果判断标准清楚、时间也有，但底座已经铺好了——那你需要的不再是批量维护，而是日常维护。批量维护是建地基，不是搞装修。
批量维护时怎么拿捏分寸¶
批量维护最怕的不是工作量太大，而是分寸没拿捏好。分寸体现在两个地方。
第一，追不追求完美。 批量维护的目标不是"一次把所有东西写到最好"，而是"把结构定下来，让后续的日常维护有据可依"。如果你在某个文件上花了四十分钟斟酌措辞，你可能已经越过了批量维护的边界——你在做打磨，不是在铺底座。
分寸的判断标准是：这个改动影响的是"它应该长什么样"，还是"它应该放在哪"？前者是底座问题，值得在批量维护中解决。后者是雕琢问题，应该留给日常维护。
第二，一次性铺多大。 批量维护覆盖的范围取决于做判断的人能看清多远。如果你能同时看透章程、手册、教程三个仓库，那就一起铺。如果你只能看清其中一个，那就只铺一个。
不是一次覆盖越多越好。覆盖范围超过判断能力，就会在每个决策点上来回纠结。
设计者注： 创始人模式下，创始人能看清的范围通常比团队大。所以批量维护往往由创始人发起，这不是因为创始人权力大，而是因为创始人能在一瞬间做出一系列判断——“这个改章程、那个写教程、那个直接删”。这种判断速度是批量维护可持续的前提。如果做判断的人每走一步都要停下来思考，批量维护就跑不动了。
批量维护做完之后¶
批量维护做完的标志不是"所有文件都完美了"，而是"后续的渐进式改进可以顺畅进行了"。
如果你做完批量维护后，团队可以按照新确定的风格和结构继续改进——那这次批量维护是成功的。如果你做完之后，大家仍然不知道怎么新增文件、怎么修改现有文件——那说明底座还没铺清楚，需要再补一层。
另一个判断标志是：你不再需要亲自推动每一次改动了。批量维护的最后一步，应该是把决策权从你手中交出去。
最后¶
批量维护和渐进式改进不是对立的选择，它们是同一件事的两个阶段。先用批量维护把底座铺好，再用渐进式改进持续优化。不铺底座直接渐进式，会在错误的路上越走越远。铺完底座后还继续批量维护，会在精雕细琢中浪费大量时间。
什么时候切换？当每新增一个文件时，你知道它该去哪、该长什么样——这时候就可以从批量维护切换到渐进改进了。