客户交付知识库最容易失败的原因，不是资料不够，而是维护成本过高。对一人公司而言，轻量机制的核心不是持续扩充文档，而是只记录会影响下一次交付的变化：客户反复追问的问题、导致返工的环节、服务边界中的新情况，以及已经验证有效的沟通方式。

先设定更新触发条件

不要把“有空整理”当成维护计划，而应在交付节点设置明确触发条件。项目结束后，记录三类信息：哪些内容可以直接复用，哪些地方造成了误解、返工或延迟，下一次需要新增、删除或修改什么。一次复盘只保留真正改变流程的内容，避免把完整聊天记录堆进知识库。

维护记录可以采用极简结构：问题是什么、适用于什么情况、下次应如何处理、是否需要修改模板。其中“适用条件”尤其重要，因为个人经验不能直接等同于绝对规则。只有写清例外情况，知识库才不会把偶然判断误用到所有客户身上。

用固定节奏控制维护范围

轻量维护可以分为三个层次。每个项目结束后，只补充本次出现的新问题和流程缺口；每月快速检查一次，删除重复或冲突的模板，修正过期的时间、范围和说明；每季度检查一次分类，观察资料是否仍能按客户阶段和项目类型快速找到。只有查找和调用变慢时，才需要调整目录，不要为了形式整齐频繁重构。

维护时还应区分“模板变化”和“服务判断”。启动通知、资料清单、交付说明、验收提醒等规则明确的内容，可以直接更新模板；需求识别、复杂取舍、范围变更协商和客户关系沟通，则应保留为判断参考，不能强行固化成标准答案。

知识库的有效性，最终不取决于文档数量，而取决于它是否进入真实流程。接单前用于确认服务边界，启动时调用资料清单，交付前执行检查，项目结束后完成复盘。每次只解决一个重复问题，经过持续积累，知识库就能在不牺牲个性化服务的前提下，降低沟通消耗并稳定交付质量。