我给自动化服务器运维划的几条边界

我希望 Codex 能接手个人服务器里重复、容易漏步骤的工作：检查现状，修改仓库配置，预览差异，部署后验证，再把证据写回来。如果每改一行页面文案都要我重新作决定，自动化没有太大意义。但让它把所有生产操作都当成普通配置变更，也会让我不放心。

能自己推进的事

目前我把目录设计、静态页面、Ansible 模板、常规服务验证和小范围可逆修复交给自动流程。它应先看真实服务器和仓库状态，再决定修改什么；对长期配置，优先回写 Git。部署前跑 check/diff，部署后查实际响应和服务日志，并留下可追溯的记录。这样的工作一旦出错，通常有明确的文件差异和回退路径。

需要人决定的边界

另一类动作可能切断远程访问、丢失数据，或者改变外部世界。我要求这类动作先停下来给出背景、证据、选项和推荐做法。比如更改 SSH 认证或可能断联的防火墙规则，删除数据库或持久卷，重启机器，切换真实 DNS 记录，以及明显增加云资源成本。它们的共同点不是技术上做不到，而是影响可能超出一个可轻松回滚的配置 diff。

域名迁移就是一个具体例子。自动流程先查到了权威 DNS 与预期不一致，也完成了不依赖 DNS 的配置准备；旧地址是否仍承载业务、何时切换真实记录，则由我确认。切换后才从外部重新验证解析、证书和网站。把等待外部决策的部分写清楚，比假设记录已经生效可靠。

证据让自动化有边界感

我不想只读“已经完成”的汇报。一个公开 HTTPS 站点，至少应有普通客户端的证书校验、页面状态、跳转和内容结果；Ansible 则要有部署前差异和最终重复执行的结果。故障排查也应先读日志和监听状态，再改配置。记录里可以保留内部细节供恢复使用，发布到个人网站时则要做脱敏。

这些边界还会继续调整。它们不是对所有服务器通用的规则，而是我目前在单机、个人项目、远程 SSH 运维条件下给自动化设的一条工作线：低风险事务让它连续推进，高影响决策留给人，并要求每一步都能被验证。