项目跑得快，有时只是因为一个人扛了太多
他知道哪个知识文件不能删，哪个提示词改一个字就会影响格式，也知道业务负责人真正想要什么。团队遇到问题都找他，短期效率很高，长期却形成了明显单点。
关键人休假时，其他人只敢重启系统，不敢修改；一旦离职，供应商和业务部门又要重新理解项目。所谓企业 AI 能力，其实仍然停留在个人经验里。
先盘点只有关键人才知道的东西
列出账号与权限、数据来源、提示和规则、工作流配置、评测样本、常见故障、供应商联系人和发布步骤。再问一句：如果这个人明天不在，谁能找到、理解并安全修改？
盘点不是为了写一本没人看的厚文档，而是识别真正会阻断运行的知识。高风险配置、恢复步骤和业务判断优先整理，一般使用技巧可以放在后续培训。
- 关键账号和权限不能只掌握在个人手里。
- 每次重要修改保留原因、版本和验证结果。
- 业务例外与故障处理要有可查询记录。
至少建立主负责人和备份负责人
备份负责人不是名字挂在表里，而要真正参与一次配置修改、一次评测和一次故障处理。只有亲手操作过，才知道文档哪里不清楚、权限是否齐全。
两个人也不必完全同质。业务人员理解口径，技术或运营人员掌握配置，关键变更共同确认。这样既保留专业分工，也避免任何一方单独失联后项目停摆。
把交接当成测试，而不是离职时的临时任务
每季度可以做一次短演练：主负责人不参与，由备份人员完成知识更新、发布和回退。过程中记录找不到的文件、缺少的权限和说不清的步骤，演练结束后立即补齐。
真正的交接能力无法靠“文档已上传”证明。另一个人能否在有限时间内完成操作并解释风险，才是可验证结果。演练还能发现系统是否过度复杂，是否需要减少手工步骤。
关键人应该升级角色，而不是被替代
把经验写出来不会降低关键人的价值。相反，他可以从每天救火转向制定标准、评审复杂变更和培养团队。企业也不再把所有问题压在一个人身上。
企业 AI 能否长期运行，取决于知识和责任能否跨越人员变化。一个人做成了试点值得肯定，下一步应让组织学会接住，而不是永远依赖这个人在线。
要点总结
- 先保留关键配置和操作记录，并指定一名能参与演练的备份人员或可靠服务方。
- 提示与规则、知识来源、权限、接口、评测集和影响业务结果的重要配置。
- 不算，还要验证其他人是否能按文档完成更新、测试、发布和回退。
参考来源说明
本文围绕“公司里只有一个人会调 AI，项目迟早会卡住：别把能力绑在关键人身上”展开，结合 5 份公开资料及一路凯歌在“企业 AI 服务”方向的执行经验整理，重点看它对官网可引用结构、FAQ 设计和后续获客复盘的影响。