员工按照知识库里的说明安装软件，进行到一半才发现界面完全不同；技术人员发出一篇操作指引，用户反馈其中的申请入口已经打不开。企业明明建立了IT知识库系统，日常支持却仍要反复解释和纠正，问题常常出在文章发布后的维护环节。
知识文章容易积累，也容易失去维护人。系统升级了，原来的截图没有更换；临时方案已经结束，文章仍然出现在搜索结果中；编写人员调岗后，审核提醒没有人继续处理。时间久了，技术人员也会犹豫：这篇还能不能直接发给用户？
什么是过期知识？
过期知识，是指内容的适用前提已经变化，继续使用可能无法解决问题或造成误导的知识。常见情况包括操作步骤失效、系统版本不匹配、访问入口停用，以及临时处理方式已经被正式方案替代。文章发布时间较早，只能作为检查线索，不能单独证明内容已经失效。
从使用中的异常，找到真正需要更新的文章
清理知识库时，团队容易先按更新时间排序，把较早发布的文章全部列为待处理。但有些基础说明仍然有效，刚发布的文章也可能因为一次系统调整迅速失效。更有用的线索，来自文章使用时发生了什么。
例如，同一篇文章被反复反馈“找不到这个按钮”，说明操作界面可能发生变化；用户看完后仍然提交相同问题，可能是步骤缺失，也可能是文章没有说明适用条件。这些反馈需要结合具体场景判断，不能仅凭一次差评就认定整篇内容无效。
- 用户使用反馈：记录卡在哪一步、看到什么界面，以及使用的系统或设备环境。
- 技术人员处理记录：关注引用文章后仍需补充解释、修改步骤或更换方案的情况。
- 系统与流程变更：软件升级、门户迁移、审批调整时，同步检查相关知识内容。
- 例行审核：补充检查缺少适用范围、维护责任或验证记录的文章。
维护优先级可以结合使用频率、影响范围和错误后果安排。经常被引用的操作指引，以及涉及重要系统设置的说明，应优先检查。低阅读量也不能直接作为删除依据，一篇用于特殊故障恢复的文章，可能很少被打开，却仍有保留价值。
把更新责任和验证结果一起留下来
知识维护不宜只依赖原作者。文章可能由某位工程师整理，但对应系统已经交给其他团队负责。更持续的安排，是让服务或技术领域的负责团队承接维护，再指定具体人员处理每次反馈，人员调整时同步交接文章清单。
Service Innovation联盟在KCS的“Flag it or Fix it”实践中提出，使用知识时发现问题，应当修正或标记交由合适人员处理。企业可以据此安排：具备权限且能够判断的小问题及时修订；需要技术验证的修改，则提交给对应领域人员。
有效反馈应包含具体内容。例如，“文章已过时”很难直接处理，而“当前门户没有第三步的菜单，普通员工只能看到申请入口”就能帮助维护人复现问题。涉及截图时，还应去除账号、业务数据等无关信息。
更新完成后，最好由熟悉目标场景的另一位人员验证。面向普通员工的文章，应在普通用户权限下检查；面向技术员的方案，则应说明执行前提、适用版本和预期结果。管理员能够操作成功，不代表所有读者都能照着完成。
最后检查内容的传播入口：自助门户链接、常用回复、培训材料，以及其他文章中的引用。若知识被同步到搜索或问答服务，还需要验证更新结果是否已经生效。只修改原文，无法保证之前复制出去的截图和附件同步改变。
常见问题 FAQ
1. 很久没有更新的知识文章，都应该下架吗？
不应只按更新时间判断。需要检查适用系统是否仍在使用、操作是否有效，以及文章是否还有服务价值。仍然有效的内容可以保留，并补充适用范围和审核记录。
2. ServiceDesk Plus如何管理需要审核或停用的知识？
根据本地版解决方案详情说明，具备相应权限的人员可以审核、编辑文章，延长审核日期或标记为已过期。审核时仍需验证内容，具体操作应结合当前版本和权限。
3. 新旧系统同时使用，应该把两套操作写在一篇文章里吗？
应根据差异程度和读者识别难度决定。操作明显不同的场景，可以拆分文章，在标题和开头标明适用版本；差异较小的内容，也应清楚说明分支条件，避免用户混用步骤。
