#不翻文档不写配置，让 AI 在 NAS 上 5 分钟装好一个服务

昨天我在 NAS 上装密码管理器 Vaultwarden，跟 AI 说了一句话，五分钟服务就跑起来了。

回头想想以前自己装的过程——搜文档、配参数、改配置、查日志——我才意识到，那些步骤里真正需要我判断的，其实只有一件事：这个服务要不要装。剩下的全是摩擦。

#部署服务的摩擦从哪来

买了绿联 NAS 之后，我想在上面装点服务。比如密码管理器 Vaultwarden、监控工具 Uptime Kuma，这些应用商店里都没有，得自己用 Docker 装。

问题是，每次装一个新服务，我都得：

1. 搜文档，看这个服务怎么用 Docker 部署
2. 找到 docker-compose.yml 模板
3. 理解环境变量都是干什么的
4. 配置端口映射
5. 处理权限问题
6. 测试能不能跑起来

每一步都不复杂，但连起来就很烦。尤其是环境变量那部分，稍微配错一个，服务就起不来，然后你得回去查日志、改配置、重启容器。

有时候我只是想装个小工具，结果光配置就花了半小时。

更糟糕的是，等过了两个月，我想再装一个类似的服务，发现之前怎么配的全忘了，又得重新查一遍文档。

说白了，这不是技术难度的问题，是决策密度的问题。

每个环节都要你做判断：这个参数填什么？端口用哪个？数据目录放哪？要不要开代理？

这种持续的微决策，会把一个本来 10 分钟能完成的事，拖成 1 小时。

更要命的是，这种摩擦会让你产生「心理成本」。

以前我想装个服务，得先做心理建设：「今天有空吗？会不会又卡在某个配置上？算了，改天再说吧。」

结果就是，很多想法一直停在「想装」的阶段，根本没动手。

#我后来的做法：开 SSH，把权限交给 AI

我发现绿联 NAS 可以开 SSH。SSH 简单说就是一个远程控制协议，开了之后，你可以用命令行远程操作 NAS。

开了之后，我就能让 Claude Code 或者 CodeX 这类编程 CLI 工具直接连上去，接管整个部署流程。

我只需要告诉它：「帮我在 NAS 的 Docker 里装一个 Vaultwarden。」

补充一句：这里是在 NAS 的 Docker 里部署服务，不是直接往系统里装软件。服务跑在容器里，和 NAS 系统隔离，不会弄乱环境。

然后 AI 会：

• SSH 连到 NAS
• 读取我的用户密码（我会在提示词里告诉它）
• 在 Docker 里创建服务目录
• 生成 docker-compose.yml 配置文件
• 配置端口和数据目录
• 拉取镜像、启动容器
• 测试服务是否正常

整个过程我不用管。它会按标准流程执行，遇到问题会告诉我，大部分情况下 5 分钟就完成了。

这不是「自动化脚本」，是把执行权限委托给了一个会判断的系统。

#为什么这件事降低了执行摩擦

省时间是附带的。真正的变化是，它把「连续微决策」变成了「单次委托」。

以前我要操心的事：

• 端口会不会冲突？
• 环境变量要不要加引号？
• 数据目录权限对不对？
• 镜像拉取要不要走代理？

现在这些判断全在 AI 那边。我只需要做一次决策：「装这个服务」。

这让我从「执行者」变成了「发起者」。

我不再需要维持对细节的持续注意力，可以把精力留给更上层的判断：这个服务值不值得装？装了之后怎么用？

#具体怎么做：两步准备

整个过程分两步。

#第一步：在绿联 NAS 中开启 SSH

绿联 NAS 默认没开 SSH，需要手动开。

路径：控制面板 → 终端机 → 启用 SSH 服务

找到 NAS 的 IP 地址：控制面板 → 关于本机 → 常规  → 网络模块中就能看到 IP 地址，记下来，后面提示词里会用到。

#第二步：准备一段标准提示词

我准备了一段标准提示词，每次要部署服务时，直接粘贴给 Claude Code 或 CodeX。

核心就三件事：告诉 AI 在哪执行（NAS 地址和密码）、怎么连接（SSH）、按什么流程走（创建目录 → 生成配置 → 启动容器 → 测试）。

完整模板放在文末了，可以直接复用。

这段提示词的好处是，不需要我每次重新解释环境，AI 拿到就能直接进入执行状态。

#不是效率工具，是执行结构的一部分

我不会把它定位成「效率工具」。

它更像是执行链路上的一个降摩擦组件。

我一直觉得，行动受阻往往不是因为没计划，而是执行路径太长。 路径上堆了一堆微决策，你就是不想动手。

以前装个服务之前，我脑子里想的不是「怎么装」，而是「又要折腾多久」。这种心理预期本身就在消耗行动力。

现在我只需要判断一件事：「这个服务值得装吗？」

一个判断替代了十几个微决策，行动自然就快了。

#「会用但记不住」的人，摩擦最大

说实话，这个方法不是给技术专家用的。

技术专家写个脚本，10 分钟搞定，不需要 AI。

它更适合那些「懂一点，但不够熟」的人。

比如我，知道一点点 Docker 怎么用，但记不住每个参数；知道怎么配置环境变量，但懒得每次翻文档。

我需要的不是「学会」，是「做完」。

AI 的作用，就是把「我知道怎么做，但懒得做」的事，变成「我说一句，它帮我做」。

这不是偷懒，是把注意力留给更值得投入的地方。

#最后

这篇文章不是在教你怎么在 NAS 中安装 Docker 服务。

我想说的是一个更上层的变化：当 AI 可以接管技术执行，摩擦点就从「怎么做」转移到了「要不要做」。

以前阻碍我行动的，是环境变量、端口映射、权限配置这些技术细节。现在这些都可以委托出去，真正卡住我的反而是判断力——我是不是清楚自己要什么，我能不能用一句话把需求说清楚。

AI 能帮你降低执行复杂度，但帮不了你做决策。

回头看，我在 NAS 部署这件事上踩的坑，没有一个是技术问题，全是结构问题。

附：标准提示词模板（可直接复用）

请帮我在绿联 NAS 的 Docker 中部署一个新服务。NAS 信息：- NAS 地址：`你的NAS IP地址`（比如 192.168.99.150）- 用户名：`你的NAS用户名`- 密码：`你的NAS密码`我想部署的服务：`<在这里写服务名，比如 Vaultwarden>`部署流程：1. 通过 SSH 连接到 NAS2. 在 `/home/<你的用户名>/<service>` 创建服务目录3. 生成 `docker-compose.yml` 配置文件4. 在 Docker 中启动容器5. 测试服务是否正常运行请严格按照这个流程执行，遇到问题及时告诉我。

把模板里的 你的NAS IP地址、你的NAS用户名、你的NAS密码 替换成你的实际信息，把 <在这里写服务名> 替换成你要装的服务（比如 Vaultwarden、Uptime Kuma），然后粘贴给 Claude Code 或 CodeX，就可以开始了。

写给新朋友的简介

EPOS 是一个持续进化的个人操作系统模型。

这是其中一次真实运行记录。

我是麦先生。

我会持续记录系统如何从混乱走向稳态。

关注「麦先生说」，一起构建属于自己的个人操作系统。