真正能落地的知识沉淀必须绕过“写文档”，将记录变为操作副产品，如故障处理时自动捕获命令输出与日志；用错误信息锚定的“问题卡片”替代经验总结；嵌入新人上手流程并提交至Git；通过上下文自动打标签；最终实现终端自动拦截重复劳动。
问题不是“要不要写”，而是“怎么让知识自动长进系统里”
运维经验沉淀失败，90% 不是因为没人愿意写，而是写了也找不到、用不上、不敢信。真正能落地的流程，必须绕过“写文档”这个动作本身，把记录变成操作的自然副产品。比如一次故障处理完，systemctl status nginx 的输出、journalctl -u nginx --since "2 hours ago" 的日志片段、甚至 curl -I http://localhost 的响应头，都应该在执行命令的同时被结构化捕获——而不是事后凭记忆补。
用“问题卡片”替代“经验总结”，强制绑定触发条件
传统知识库搜不到，常因标题是“Nginx 启动失败”，但实际遇到的是 nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)。有效沉淀必须以错误信息为锚点：
• 标题直接写成：[ERROR 98] nginx bind() failed on port 80
• 内容第一行注明触发条件：当 systemctl start nginx 报此错，且端口被占用时适用
• 解决步骤里不写“检查端口”，而写具体命令：ss -tuln | grep ':80' 和 kill -9 $(lsof -t -i:80)
• 最后加一行验证方式：curl -sI http://localhost | head -1 应返回 HTTP/1.1 200 OK
让新人第一次操作就留下可复用的痕迹
很多团队指望老员工“抽空整理”，结果永远没空。可行做法是：把沉淀嵌入新人上手流程。
• 新人部署第一个服务时，必须填写一张表单（哪怕只是 Markdown 表格），包含：服务名、部署命令全量粘贴、验证成功的完整输出、踩过的坑（如 SELinux 拦截）
• 这张表单直接提交到 Git 仓库的 /runbook/nginx-deploy.md，而非内部 Wiki——版本可控、可 diff、可和 Ansible Playbook 放一起
• 后续每次变更，都要求 git commit -m "fix: nginx deploy fails on CentOS 8 due to firewalld"，历史本身就是知识演进链
