真正能落地的知识沉淀必须绕过“写文档”，将记录变为操作副产品，如故障处理时自动捕获命令输出与日志；用错误信息锚定的“问题卡片”替代经验总结；嵌入新人上手流程并提交至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"，历史本身就是知识演进链
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
不维护标签体系，就等于没有检索能力
光有内容没用，查不出来就是废纸。标签必须来自真实操作上下文：
• 环境类标签：centos7、cloud-init、docker-host
• 触发类标签：error-98、timeout-during-rsync、fstab-mount-fail
• 风险类标签：requires-reboot、breaks-ssl-termination、unsafe-in-prod
这些标签不能靠人工打，而应由脚本在提交时自动提取：比如检测到命令含 rm -rf 就加 unsafe-in-prod；发现 /etc/fstab 被修改就加 requires-reboot。否则标签会迅速失效。
最常被忽略的一点：知识沉淀不是为了归档，而是为了拦截重复劳动。如果一个新人在执行 systemctl restart mysql 前，终端能自动弹出匹配的卡片并提示“上次重启失败因 innodb_force_recovery=1 未清除”，那才算真正跑通了闭环。
