用NAS+Docker+Webhook打造个人AI自动化工作流

先从一张桌面开始说起。

平时写代码、跑模型、做自动化任务，最烦的就是“东西太散”。模型输出放在电脑上，数据存在 NAS 里，通知发到微信、钉钉、飞书，几套系统互不相通。每次想跑一条完整流程，都要手动把文件拷来拷去，再去各个平台点一遍——效率低，还容易漏。

这篇文章我想以“无脚本桌面实拍”的方式，完整拆解一下我自己日常在用的 AI 工具环境：电脑、NAS、通讯平台是如何被打通成一条自动化工作流的。文章不会只展示工具截图，而是会讲清每一层的分工、关键配置和串联思路。如果你想在已有 NAS 的基础上，把本地 AI 工具和消息通知真正用起来，这篇应该能给你一套可落地的参考方案。

适合阅读的人群有两类：一是已经有一台 NAS，但主要只用来存电影、备份照片，还没发挥出它作为“家庭服务器”能力的朋友；二是本地已经在用 AI 大模型、自动化脚本，但总觉得文件同步、任务触发、消息通知之间很割裂的开发者。

1. 先把“AI 工具环境”这个概念拆清楚

很多人一听到“AI 工具环境”，第一反应是显卡、显存、大模型权重。但在我这套方案里，AI 工具环境并不是指某一台性能强劲的电脑，而是指一组能协同工作的基础设施。

1.1 个人 AI 工具环境的三层结构

我的日常 AI 工作流可以拆成三个层面：

• 交互与计算层：主力电脑、笔记本，负责跑图形界面、轻量模型推理、写代码和手动操作。
• 存储与服务层：NAS，负责 7×24 小时运行容器服务、集中存储数据、定时执行后台任务。
• 通讯与通知层：微信、钉钉、飞书、Bark 这类平台，负责把 AI 任务结果推送到手机和电脑。

以前这三层是割裂的，我需要手动处理中间的数据搬运和状态同步。现在要做的事情，就是让它们自己“串起来”。

1.2 为什么 NAS 在自动化工作流里越来越重要

NAS 最容易被低估的一点，是它不只是一块网盘。

它的本质是一台低功耗、常开的服务器。你可以在这台服务器上安装 Docker，跑数据库、跑 Web 服务、跑自动化脚本，甚至跑轻量级大模型推理。因为 NAS 常年不关机，所以它很适合做定时任务的执行者、文件的中转站和消息通知的转发节点。

在我这套环境里，NAS 承担了三个具体角色：

• 文件协调中心：电脑产生的 AI 输出、下载工具下载的文件、监控摄像头拍到的视频，统一按规则落到 NAS 指定目录。
• 服务运行中心：通过 Docker 运行 Ollama、easynvr、Webhook 接收器等常驻服务。
• 任务调度中心：NAS 自带的任务计划或容器中的 cron，按时间触发 AI 任务、备份任务和通知任务。

1.3 通讯平台在自动化中的真实位置

通讯平台不能只用来聊天。它其实是最好的消息出口。

当 AI 任务跑完、NAS 备份完成、某个服务异常退出，系统可以把消息推送到钉钉群、飞书群、企业微信群，或者直接推到手机的 Bark 通知。你只需要在通讯平台里创建一个自定义机器人，拿到 Webhook 地址，后续所有自动化任务都可以通过 HTTP 请求把结果送过去。

这样做的好处很明显：不需要自己开发一套 App，不需要维护短信服务，所有终端天然就是手机和电脑上的聊天软件。

2. 环境准备：我的硬件、系统和软件清单

为了让后面的流程描述有参考价值，先交代一下我当前这套环境的基础配置。你可以根据实际情况替换，不需要完全一致。

2.1 硬件与系统

这里特别说明一下：我的 NAS 系统使用的是飞牛 NAS，底层基于 Debian Linux，对 Docker 支持比较友好。如果你使用的是群晖、威联通或自己组装的 TrueNAS，下文思路同样适用，只需要把路径和套件安装方式替换一下。

2.2 基础软件清单

2.3 网络规划建议

这一节很重要。自动化工作流能跑通，依赖网络规划是否清晰。

• NAS 使用固定 IP：在路由器后台为 NAS 绑定一个静态 IP，例如192.168.1.100。否则每次 DHCP 分配变化都会导致电脑挂载目录失败、Webhook 回调失败。
• 为容器服务固定端口：避免容器重启后端口冲突。
• 创建专用目录结构：建议在 NAS 上建一套统一的共享目录，例如：

/nas-data/ ├── downloads/ # 下载文件目录 ├── ai-outputs/ # AI 生成结果目录 ├── surveillance/ # 监控录像目录 ├── backups/ # 系统与数据备份目录 └── app-data/ # 容器持久化数据目录

目录结构越早设计清楚，后续自动化流程写起来越轻松。

3. 基础设施搭建：把电脑与 NAS 存储打通

自动化工作流的第一步，是让电脑和 NAS 之间文件可以随时互访。这听起来简单，但很多人第一步就没做好——他们每次都是通过浏览器登录 NAS 网页端上传下载文件，这是“手动操作”的典型表现，不可能自动化的。

3.1 Windows 电脑挂载 NAS 目录为本地磁盘

在 Windows 上，最直接的方式是通过 SMB 协议把 NAS 共享目录映射为网络驱动器。

操作路径：

1. 打开“此电脑”。
2. 点击“映射网络驱动器”。
3. 选择盘符，例如Z:。
4. 输入 NAS 共享目录地址，例如\\192.168.1.100\ai-outputs。
5. 勾选“使用其他凭据连接”，输入 NAS 用户名和密码。
6. 完成挂载。

完成后，在命令行里可以直接访问：

Z:\

这样，任何 AI 工具、Python 脚本、下载软件，都可以把文件直接写入Z:，而实际存储的位置已经是 NAS 硬盘。

3.2 使用 rclone 挂载 WebDAV 目录

如果你的 NAS 开启了 WebDAV 服务，或者在别的设备上也想访问 NAS 目录，rclone 是很好的选择。

先安装 rclone，然后进行配置：

rclone config

按照交互提示，选择 WebDAV 类型，填写 NAS 地址和账户：

URL = http://192.168.1.100:5005 Vendor = Other User = your_username Pass = your_password

配置完成后，可以先用命令验证连通性：

rclone lsd nas-webdav:

如果能看到 NAS 上的目录列表，说明 WebDAV 配置成功。接下来把 WebDAV 远程目录挂载为本地路径：

mkdir -p ~/nas-mount rclone mount nas-webdav:/ ~/nas-mount --daemon

这样在本地 Linux 或 macOS 机器上，~/nas-mount目录就等价于 NAS 上的根目录。这个方式同样适合群晖 NAS 开启 WebDAV 后的场景。

3.3 文件同步策略

挂载之后，还需要确定“哪些文件需要自动同步”。我的规则很简单：

• 电脑上生成的 AI 输出，直接写入网络驱动器。
• 临时文件留本地。
• NAS 上的备份目录通过 rclone 定期同步到另一台设备或网盘。

这里用 rsync 做一个最简单的同步示例：

rsync -avz --delete /d/ai-outputs/ /e/nas-backup/

如果希望自动化，可以在 Windows 任务计划程序中创建定时任务，每天凌晨执行这条命令。

4. 核心功能实战：NAS 上的容器服务与 AI 模型

存储打通之后，下一步是让 NAS“跑起来”。这里我会用几个具体案例展示 NAS 在自动化工作流中能承担的任务。

4.1 在 NAS 上部署 Ollama，提供大模型推理服务

Ollama 是一个可以在本地运行大模型的开源工具，支持 CPU 和 GPU 推理。在 NAS 上部署 Ollama，可以让 NAS 成为一个 7×24 小时可用的 AI 推理节点，电脑端通过 API 调用即可。

飞牛 NAS 自带 Docker 管理界面，也可以通过命令行部署。使用 Docker 部署的配置如下：

version: "3.8" services: ollama: image: ollama/ollama:latest container_name: ollama restart: always ports: - "11434:11434" volumes: - /vol1/1000/app-data/ollama:/root/.ollama environment: - OLLAMA_HOST=0.0.0.0

部署完成后，进入容器执行模型拉取命令。例如拉取一个轻量模型：

ollama pull qwen2.5:7b

之后在电脑上，可以直接通过 API 调用 NAS 上的模型：

curl http://192.168.1.100:11434/api/generate -d '{ "model": "qwen2.5:7b", "prompt": "用一句话介绍什么是NAS" }'

返回结果就是模型生成的文本。

这样的部署方式解决了什么问题？电脑不需要安装大模型，不需要占用本地显存或内存。轻量任务全部交给 NAS，电脑只负责展示结果。

4.2 接入萤石摄像头：通过 easynvr Docker 实现监控视频集中存储

监控与 AI 工作流看似不相关，但实际上，很多自动化流程需要“视觉信号输入”。比如检测到有人移动后，自动拍摄照片并调用 AI 分析可疑程度。

在 NAS 上用 Docker 部署 easynvr 是一个常见的做法。easynvr 支持接入 ONVIF 协议摄像头，并提供 RTSP/RTMP/HTTP-FLV 拉流能力。

部署 easynvr 的 Docker 配置如下：

version: "3.8" services: easynvr: image: easynvr/easynvr:latest container_name: easynvr restart: always network_mode: host volumes: - /vol1/1000/app-data/easynvr:/easynvr environment: - TZ=Asia/Shanghai

部署完成后，在浏览器中打开 NAS 的 IP 加对应端口，进入 easynvr 管理界面，添加萤石摄像头：

1. 获取摄像头的 RTSP 地址。萤石摄像头默认关闭 RTSP 功能，需要在萤石云 App 中开启。
2. 在 easynvr 中点击“添加”，填写设备名称、RTSP 地址。
3. 设置录像存储路径，指向/vol1/1000/surveillance目录。
4. 开启录像计划，保存。

完成之后，监控视频会持续写入 NAS 硬盘，并且由于目录是共享的，电脑上的 AI 分析脚本可以直接读取这些视频文件。

4.3 其他值得在 NAS 上部署的 Docker 服务

除了 Ollama 和 easynvr，下面几个容器也可以大幅提升自动化工作流的能力：

比如部署一个 webhook 服务，可以使用 adnanh/webhook 镜像：

version: "3.8" services: webhook: image: almir/webhook container_name: webhook restart: always ports: - "9000:9000" volumes: - /vol1/1000/app-data/webhook:/etc/webhook command: -hooks=/etc/webhook/hooks.json -verbose

hooks.json文件中可以定义如下规则：

[ { "id": "restart-ollama", "execute-command": "/usr/bin/docker", "command-working-directory": "/", "pass-arguments-to-command": [ { "source": "string", "name": "restart" }, { "source": "string", "name": "ollama" } ] } ]

那么当外部请求http://192.168.1.100:9000/hooks/restart-ollama时，NAS 会自动执行docker restart ollama。这就为远程重启服务提供了安全、受控的接口。

5. 打通通讯平台：把 AI 任务结果推进手机和群聊

存储和服务就绪后，还需要解决“如何通知人”这一步。我选择通过通讯平台的自定义机器人来实现。

5.1 以钉钉自定义机器人为例

在钉钉群中添加自定义机器人后，会获得一个 Webhook 地址，例如：

https://oapi.dingtalk.com/robot/send?access_token=xxxxx

通过 curl 命令即可向群内推送消息：

curl 'https://oapi.dingtalk.com/robot/send?access_token=xxxxx' \ -H 'Content-Type: application/json' \ -d '{ "msgtype": "markdown", "markdown": { "title": "AI任务完成", "text": "## AI 绘图任务已完成 \n 文件地址: /nas/ai-outputs/20250101.png" } }'

在 Python 脚本中，发送消息同样非常简单：

import requests webhook_url = "https://oapi.dingtalk.com/robot/send?access_token=xxxxx" def send_dingtalk_message(text): data = { "msgtype": "text", "text": { "content": text } } resp = requests.post(webhook_url, json=data) print(resp.json()) send_dingtalk_message("AI 任务已完成，请查收。")

5.2 以飞书自定义机器人为例

飞书的自定义机器人同样支持 Webhook 方式。拿到地址后，发送消息的示例：

curl -X POST https://open.feishu.cn/open-apis/bot/v2/hook/xxxxx \ -H 'Content-Type: application/json' \ -d '{ "msg_type": "text", "content": { "text": "NAS 备份任务已完成" } }'

5.3 以手机 Bark 通知为例

如果你使用 iPhone，Bark 是一个非常轻量的通知工具。它通过 HTTP GET 请求推送到手机通知栏，没有复杂的鉴权流程。

curl https://api.day.app/your_device_key/AI任务完成/NAS推理结果已保存

Bark 特别适合作为个人开发者的独立通知通道，适合不依赖公司群聊的场景。

5.4 构建统一通知工具函数

为了避免每个脚本都写一遍不同的 Webhook 调用，我在本地 AI 工具环境中封装了一个notify.py：

import requests def send_notify(title, content, platform="dingtalk"): if platform == "dingtalk": webhook_url = "你的钉钉机器人地址" data = { "msgtype": "markdown", "markdown": { "title": title, "text": f"### {title}\n\n{content}" } } elif platform == "feishu": webhook_url = "你的飞书机器人地址" data = { "msg_type": "text", "content": { "text": f"{title}\n{content}" } } elif platform == "bark": webhook_url = f"https://api.day.app/你的key/{title}/{content}" data = {} else: raise ValueError(f"Unsupported platform: {platform}") res = requests.post(webhook_url, json=data) return res.json() if __name__ == "__main__": send_notify("部署完成", "NAS 上的 Ollama 服务已正常启动")

以后任何需要通知的场景，一行代码就能接入，不用重复造轮子。

6. 从手动到半自动化：把这几层真正串起来

前面几节分别讲了存储、服务、通讯，这一节是整套方案的灵魂——把三层业务串联成一个可流转的工作流。

6.1 工作流设计示例

假设你现在有一个需求：每天定时让 NAS 上的 AI 模型生成一篇产品摘要，并把结果发送到钉钉群。

整体流程是这样的：

1. 电脑上的 Python 脚本通过 Docker SDK 或 SSH 远程调用 NAS 上的 Ollama API。
2. Ollama 模型生成文本，返回给 Python 脚本。
3. 脚本把结果保存到 NAS 的ai-outputs目录。
4. 脚本将摘要内容和文件路径推送到钉钉机器人。
5. 手机端收到通知，点击即可查看文件地址。

6.2 核心代码：AI 生成 + 文件保存 + 消息通知

import requests from datetime import datetime from notify import send_notify # 1. 调用 NAS 上的 Ollama 模型 def generate_summary(topic): api_url = "http://192.168.1.100:11434/api/generate" payload = { "model": "qwen2.5:7b", "prompt": f"请为以下主题生成100字以内的摘要：{topic}", "stream": False } res = requests.post(api_url, json=payload) return res.json().get("response", "") # 2. 保存结果到 NAS def save_to_nas(content): date_str = datetime.now().strftime("%Y%m%d_%H%M%S") file_name = f"summary_{date_str}.txt" file_path = f"Z:/ai-outputs/{file_name}" # Windows 网络驱动器方式 with open(file_path, "w", encoding="utf-8") as f: f.write(content) return file_path # 3. 主流程 if __name__ == "__main__": response = generate_summary("如何搭建家庭NAS自动化工作流") path = save_to_nas(response) send_notify("AI 摘要任务完成", f"内容：{response}\n文件路径：{path}") print("工作流执行完成")

这个脚本展示的就是一个最小的自动化闭环：AI 推理 → 文件存储 → 消息通知。

6.3 在 NAS 上设置定时任务

上面的代码是在电脑上运行。如果希望 NAS 自己直接运行这个流程，可以把脚本上传到 NAS，然后通过飞牛 NAS 的任务计划功能，设置每天定时执行。

调度配置示例：

0 8 * * * cd /vol1/1000/scripts && python3 ai_summary.py >> /vol1/1000/scripts/logs/ai_summary.log 2>&1

这样每天早上 8 点，NAS 就会自行执行 AI 任务，并把结果推送到通讯平台。电脑不需要开机，全流程一样能完成。

6.4 更进阶：基于文件事件触发任务

定时任务适合固定节奏。但有些场景希望“有文件变化就触发”，例如：

• 下载目录有新文件 → 自动调用 AI 给文件分类。
• 监控目录出现新视频 → 自动截帧并调用 AI 分析。
• NAS 备份完成 → 自动发送通知。

在 Linux 环境中，可以用inotifywait监听目录变动：

while true; do inotifywait -e create /vol1/1000/downloads/ python3 /vol1/1000/scripts/handle_new_file.py done

这样，自动化工作流就从“定时生产”升级为“事件驱动”模式。

7. 常见问题与排查思路

在实际搭建这套环境的过程中，最容易踩到下面几个坑。我整理成了一张表格，按“现象 → 原因 → 解决”的顺序说明。

如果遇到定时任务问题，可以先手动执行一次脚本，确认脚本本身没有依赖交互式输入，再检查 cron 日志：

grep CRON /var/log/syslog

如果看到任务已执行但没有输出，多半是脚本中的路径没有写绝对路径，或者 Python 环境变量不对。

8. 最佳实践与工程化建议

当这套工作流从“实验”走向“日常使用”，就需要建立一些规范。下面这些建议来自我自己的维护经验。

8.1 目录与命名规范

在自动化工作流中，所有文件名和时间戳最好统一格式。例如：

• 日期格式统一使用YYYYMMDD_HHMMSS。
• 文件名中不要包含中文和空格，避免跨平台兼容问题。
• 不同来源的文件分别放入对应一级目录，不要混放在一个下载目录里。

8.2 配置管理：不要把敏感信息写死在脚本里

在我的脚本中，钉钉机器人地址、NAS 密码、API Key 等信息都应该通过环境变量或配置文件管理。例如使用.env文件：

NAS_HOST=192.168.1.100 OLLAMA_PORT=11434 DINGTALK_WEBHOOK=https://oapi.dingtalk.com/robot/send?access_token=xxxxx BARK_API_URL=https://api.day.app/xxxxx

Python 中使用python-dotenv读取：

from dotenv import load_dotenv import os load_dotenv() DINGTALK_WEBHOOK = os.getenv("DINGTALK_WEBHOOK")

这样可以避免在代码仓库中泄露敏感信息。

8.3 日志记录

自动化任务不可见，日志就是唯一的排查途径。所有脚本必须记录日志，内容至少包括：

• 执行开始时间
• 输入参数
• 关键中间结果
• 执行状态（成功/失败）
• 失败时的错误堆栈

Python 中推荐使用logging模块，而不是到处print：

import logging logging.basicConfig( filename="/vol1/1000/scripts/logs/automation.log", level=logging.INFO, format="%(asctime)s - %(levelname)s - %(message)s" ) logging.info("AI 任务开始执行") logging.error("调用 Ollama 接口失败")

8.4 使用 API 调用而不是 SSH 拼命令

如果你经常需要远程操作 NAS 上的服务，尽量使用 API。比如 Ollama 提供完整的 HTTP API，重启 Docker 服务则可以通过 Portainer API 或 webhook 完成，比 SSH 上去敲命令更安全、更容易集成到脚本里。

8.5 安全边界与权限控制

NAS 上的服务如果暴露到外网，必须谨慎。以下几点很重要：

• 不要把 Docker 端口直接映射到公网。
• Webhook 服务必须设置 token 校验。
• 通讯机器人只能在受信任的群组中使用，避免泄露。
• 定期更新 Docker 镜像和 NAS 系统补丁。

8.6 备份优先

自动化工作流越复杂，配置和数据越需要备份。建议至少保留以下备份：

• Docker 容器的docker-compose.yml文件。
• .env配置文件。
• webhook 的hooks.json。
• AI 模型生成的关键数据文件。

这些文件体积不大，可以推到私有 Git 仓库或云盘备份，避免 NAS 系统故障后配置全部丢失。

9. 拓展：这套环境还能玩出什么

如果你已经完成了上面的搭建，其实已经拥有一个基础的“个人 AI 基础设施”。在此基础上，还可以继续拓展几种实用的玩法。

9.1 把 NAS 变成个人知识库

用 NAS 上的 Docker 部署一个支持全文搜索的笔记服务，例如 memos、outline 或思源笔记。然后用这套自动化工作流把 AI 生成的内容自动写入知识库，实现“生成即沉淀”。

9.2 摄像头画面 AI 分析

用前面部署好的 easynvr，定时截取摄像头画面帧，再调用 Ollama 的多模态模型，实现简单的异常检测。比如发现画面中有陌生人时，自动发送钉钉消息到家里的群。

9.3 下载自动化

下载工具（如 qBittorrent）支持 WebUI 和 API。可以编写一个脚本，监听下载完成的种子，自动调用 AI 对文件重命名、分类，并推送到通讯平台。

9.4 群晖 NAS / 飞牛 NAS 上的同类实践

这套思路不只适用于飞牛 NAS。群晖 NAS 一样可以安装 Docker 服务，部署 Ollama、easynvr、webhook。群晖还可以通过 DDNS 和反向代理，把容器服务统一暴露到安全入口。迁移时只需要保证 docker-compose 文件中的volumes路径改成新环境下的实际路径即可。

10. 写在最后

对普通用户来说，一台 NAS 可能只是备份工具；但如果你愿意花一个周末时间去配置 Docker、Webhook 和消息通知，它能变成真正意义上的自动化中枢。电脑负责交互、NAS 负责执行、通讯平台负责通知，三者各司其职，工作流就自然跑起来了。

这套环境里没有刻意追求复杂的脚本。整篇思路的核心，是善用已有的 Docker 生态、HTTP API 和 Webhook 标准接口，用少量代码把服务连接起来。实际上，你不需要成为编程高手，只需要学会阅读接口文档、调整 JSON 数据结构，就能把大部分流程打通。

自动化永远是先从一台自己看得见摸得着的设备开始。如果你现在手里正好有一台 NAS，不妨从部署一个 Ollama 容器开始，然后试着给钉钉群发一条通知。等这两步成功了，再考虑下一步的摄像头接入、文件联动和任务调度。

希望这篇文字能给你一点有用的启发。如果你也在折腾 NAS 自动化，欢迎在评论区聊聊你的方案和踩过的坑。