一名自建 homelab 用户近日披露了自己的 AI 开发平台：OpenCode 作为服务运行在独立 VM 中，通过 Web UI 提供持久会话、终端、文件浏览、git diff 和 worktree 支持；AI 负责修改代码并推送 feature branch，用户人工审查 PR，合并后再由 GitOps 部署。
这不是企业级生产平台落地案例，而是一个个人家庭基础设施的受控实验。它真正有参考价值的地方，是把 AI 编码代理放进 Git 工作流，而不是让 AI 直接登录服务、改配置、重启容器。对维护 NAS、Docker 服务和 Home Assistant 的用户来说，这比“AI 自动运维”更现实。
从手工升级到 AI 辅助，省下的是排查时间
作者管理着约十几个 Docker Compose stacks，过去做容器升级要逐个查 release notes、确认 breaking changes、运行更新并手工检查服务状态，常常花掉几小时。现在，AI 先摘要 release notes，用户几分钟内读完关键变化，再决定是否升级。
OpenCode 还被用来给多数容器补 healthcheck。这个动作不炫目，但对 homelab 很实用：家庭服务常见问题不是大规模故障，而是某个容器悄悄挂掉、网络配置绕错、升级后接口变了。
| 维护动作 | 过去做法 | 现在做法 | 判断 |
|---|---|---|---|
| 容器升级 | 人工读每个项目说明 | AI 摘要 release notes | 降低信息整理成本 |
| 配置修改 | 手翻多个 compose 文件 | AI 生成变更，用户看 diff | 适合处理重复性修改 |
| 故障发现 | 事后访问服务才知道 | 补 healthcheck | 提前暴露部分问题 |
| 部署 | 手工改服务或配置 | PR 合并后 GitOps 接管 | 风险边界更清楚 |
这里的效率提升有前提：AI 处理的是文本仓库和配置文件，不是直接控制运行环境。换句话说，它更像一个会读文档、会改 YAML 的初级维护助手，而不是值班工程师。
关键设计不是 AI 能力，而是权限边界
平台的核心约束很明确。OpenCode 有自己的 Git server 用户和独立 SSH key，可以 clone 项目、推送分支，但不能直接推送部署分支。所有变更必须经过 PR，用户满意后手动合并。
这台 VM 只有互联网访问和 Git server 访问权限，不能访问实际服务。作者因此能接受在 VM 内给 OpenCode root 权限，用于安装构建工具或测试依赖。这个取舍很关键：root 权限听上去危险，但如果网络边界隔开、部署链路被 PR 卡住，风险半径就被压在开发环境里。
部署部分由 GitOps 接管：Arcane 管 Docker 服务变更，Home Assistant GitOps 插件管配置，Cloudflare Pages worker 管博客。和直接让 AI 调用 Docker socket、SSH 进主机相比，这套链路慢一点，却更可审计。
横向看，GitHub Copilot、Claude Code、Cursor 等工具更常出现在日常编码场景；GitHub Actions 又能把测试日志、lint 结果和 IaC plan 反馈给代理，形成更快闭环。这个 homelab 方案选择 OpenCode，主要因为作者偏好其厂商无关、插件支持和 Web UI 体验，并非说明它是唯一推荐路线。
受影响的是自建服务用户，短板在 CI 反馈
最直接受益的人，是维护 NAS、Docker、Home Assistant、个人博客和一堆自托管服务的用户。他们的痛点不是没有 Kubernetes，而是配置分散、升级文档多、手机上难以做小改动。现在作者可以从电脑发起任务，在手机上看 PR，合并后让 GitOps 部署。
但这套方案离“自动运维”还有距离。AI 无法访问真实服务，不能直接验证运行结果；PR 需要人工合并；如果 CI 失败，反馈也不顺畅。作者提到，Forgejo Actions 不通过公开 API 暴露 job logs，而他不愿依赖未文档化接口。这意味着代理很难像在 GitHub Actions 上那样读取失败日志、定位测试或 IaC 计划问题。
接下来最该观察的不是 AI 会不会更聪明，而是这些自托管 Git 平台能否给编码代理提供稳定的日志、权限和审计接口。家庭实验室可以容忍半自动流程；一旦类比到生产开发平台，日志可见性、临时环境、访问控制和审计记录就不是锦上添花，而是准入门槛。