如果说第一周养虾，还是一个老运维在试探、在验证、在重新找回“敢动手”的感觉，那么第二周，这件事已经明显变了味道。

因为我不再只是养一只虾。

这一周，虾军团正式成军。六只虾，六名战士，一个指挥部。原本那个带着实验性质的小尝试，开始逐渐长出组织感：有分工，有命名，有技能沉淀，有流程边界，也有越来越清晰的人机协作秩序。

这周真正让我印象最深的，并不是它们又完成了多少任务，而是我开始越来越清楚地意识到：AI 运维真正的价值，并不在于替人做决定，而在于让执行更稳定、经验更可复用、流程更像流程。

从“会干活”到“能组织起来”

第一周的时候，我最在意的是一只虾到底能不能把活干成。比如给服务器扩 Swap、做日志轮转、安装 NodeBB、处理 SSL 证书，这些任务的意义在于验证：它到底只是个会说的工具，还是已经能接住真实运维工作。第二周，这个问题基本已经不再需要反复验证了，因为问题升级成了另一个层面：当不止一只虾同时存在时，怎么让它们变成体系，而不是一堆零散能力。

第二周第一天，第 6 只虾正式入编。Dashboard 端口监听正常，gateway 进程正常，一支由 6 名战士组成的虾军团正式成形。也就是从这一天开始，我越来越强烈地感受到，养虾这件事已经不再是“我有了一个助手”，而是“我开始拥有一套可以调度的运维资源”。

展开剩余82%

这种变化看起来像是数量增加，实质上却是思维方式的变化。单只虾更像工具，成军之后，才更像体系。

真正的考验，总是在故障来时出现

第二天，真正的实战来了。

我的“长河教练AI+ITIL圈子”网站崩了。长期以来，网站一直承受恶意流量攻击，这一次性能终于被压垮。面对故障，我没有让虾立刻动手，而是先给出一个非常明确的约束：只分析，不操作。它完成诊断、给出依据、确认问题来源之后，我再授权它一次性修复。修复完成后，我没有让这次经验停留在聊天记录里，而是要求它把针对 XWiki 数据库连接池问题的处理思路沉淀成专属 Skill，供未来复用。

事后回头看，这件事真正有价值的地方，不只是网站修好了，而是我第一次比较完整地看到了一个更成熟的人机协作闭环：先分析，再授权，再执行，最后沉淀成能力资产。这里面每一步都不是虾在自说自话地完成，而是人始终在关键节点上控制方向。

这其实也解释了为什么第二周比第一周更有分量。第一周是“虾能不能干”，第二周开始回答“虾干完之后，组织还能留下些什么”。

最让我意外的，是它开始碰到企业级场景的边界

同样是在这一天，我做了一个更硬核的验证：让 OpenClaw 全自主完成 Samba AD DC 企业级部署。从防火墙端口开放、Samba 安装、域置备，到 OU、用户、组和登录脚本部署，整个过程不需要人工一步步敲命令，最终 AD 域控制器成功上线，相关服务验证通过，还自动生成了方案文档和报告文档。

这件事让我第一次比较具体地看清了“虾的能力上限”到底在哪。过去讨论 AI 运维时，大家很容易停留在脚本级、命令级、工具级想象里，觉得它更适合做一些零散的系统操作。但这一轮验证之后，我开始更愿意把它理解成一种可参与复杂 IT 服务交付过程的执行单元。

它当然还不能替代架构师，也不能替代最终责任人。但它确实已经不止于“会调参数、会跑脚本”了。

养虾到第二周，开始出现真正的“管理问题”

第二周另一个特别真实的变化，是我开始碰到不是技术问题，而是管理问题。

比如 第三天，我发现几只虾在飞书上自主创建文档时，经常会出现“有标题、没正文”的情况。任务形式完成了，任务实质没完成。这个问题看似小，却特别典型：当 AI 承担越来越多动作之后，验收标准就必须从“有没有做”升级成“做得是不是到位”。

我没有选择自己手工补救，而是要求虾自己开发一个 Skill，把“创建文档后验证正文是否成功写入”这件事内建进流程，然后再让所有虾统一学习。

这件事让我想明白了一个很重要的原则：虾的问题，最好让虾自己解决。因为它更理解自己的执行逻辑，也更知道问题最容易出在哪个环节。人真正该做的，不是替它补每一个漏洞，而是把问题上升成规则，把修复沉淀成机制。

这已经不是单纯的“使用工具”了，更像是在训练一支队伍。

第二周最大的进步，是开始知道“证据比口头完成更重要”

第六条，我踩了一个非常值得公开记录的坑。

我让虾设置 crontab：定时检查网站状态，如果不可访问，就自动重启 docker-compose。逻辑很清楚，需求也不复杂，虾也表示“已设置”。但后来我让它把 crontab 具体内容展示出来时，才发现写进去的其实是一条注释，而不是真正的计划任务。最后反复折腾几次，才确认任务真的写入。

这件事对我的提醒特别大。

过去很多时候，人使用 AI 最容易犯的错，就是把“它说完成了”误认为“事情真的完成了”。但在运维场景里，这种差异有时就是一整条 crontab，有时甚至是一整次故障。

所以第二周我给自己定下一条更硬的养虾军规：不要只听它说已完成，一定要看关键执行结果的证据。命令、输出、配置项、监听状态、任务条目，这些都要亲眼见到。说到底，人与 AI 的协作能不能长期稳定，不取决于它多会表达，而取决于你有没有建立起正确的验收习惯。

AI 运维真正可持续的样子，开始浮现出来了

第七天，我做了一次完整的 ITIL 变更管理实战。这件事，在第二周的所有内容里，可能最值得长期回味。

因为对于小微 IT 组织来说，变更管理一直是两难。一方面，人少，一人多岗，强行做严格职责拆分，流程容易流于形式；另一方面，生产变更确实有风险，不能因为团队小就不做控制。OpenClaw 在这次实践里给出的协作方式是：机器人分析问题、提出变更方案、制定回滚计划，再由人类授权执行，随后机器人执行并验证，最后由人类验收。

这一套模式让我真正想明白了第二周最核心的收获：不是虾越来越强，而是“人在哪里”这件事终于开始变清楚。

人不需要再亲自完成每一个低价值动作，但必须出现在关键判断节点上。什么时候动、为什么动、做到什么程度算完成、出了问题怎么定性，这些事不能外包，也不该外包。AI 最适合接手的是执行密集、流程清晰、重复性高的部分，而人真正要守住的是目标、边界、授权和验收。

我想，这大概才是 AI 运维真正能持续下去的姿势。

第一周，我找回的是“准”和“快”。第二周，我开始认真思考“人在哪里”。

从单机运维到多虾协同，从单次任务到技能沉淀，从故障修复到 AD 域部署，从文档治理到事件分析，再到变更管理实战，这一周的每一件事其实都在指向同一个结论：虾可以把执行做到很强，但判断这件事，永远仍然是人的工作。

养虾表面上是在训练虾，实际上更像是在训练自己如何成为一个更合格的指挥者。虾军团正式成军之后，我反而比第一周更清醒了：工具越强，人越要知道自己到底该站在哪个位置。

发布于：广东省