用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 硬件与系统角色配置说明主力电脑Windows 11主要用于代码编写、AI 工具交互界面操作NAS 设备x86 架构支持 Docker安装飞牛 NAS 系统fnOS手机Android 和 iPhone 都会用到主要用于接收通知摄像头萤石摄像头用于家庭监控场景通过 ONVIF/RTSP 接入这里特别说明一下我的 NAS 系统使用的是飞牛 NAS底层基于 Debian Linux对 Docker 支持比较友好。如果你使用的是群晖、威联通或自己组装的 TrueNAS下文思路同样适用只需要把路径和套件安装方式替换一下。2.2 基础软件清单软件/服务用途Docker运行容器化服务PortainerDocker 图形化管理界面非必须但建议安装Ollama在 NAS 上运行开源大模型推理服务easynvr接入 ONVIF 摄像头实现监控视频集中存储Webhook 接收器接收外部 HTTP 请求触发本地脚本rclone把 NAS 的 WebDAV/SMB 目录挂载到其他设备通讯平台机器人钉钉、飞书、企业微信或 Bark 的自定义机器人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 共享目录映射为网络驱动器。操作路径打开“此电脑”。点击“映射网络驱动器”。选择盘符例如Z:。输入 NAS 共享目录地址例如\\192.168.1.100\ai-outputs。勾选“使用其他凭据连接”输入 NAS 用户名和密码。完成挂载。完成后在命令行里可以直接访问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_HOST0.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: - TZAsia/Shanghai部署完成后在浏览器中打开 NAS 的 IP 加对应端口进入 easynvr 管理界面添加萤石摄像头获取摄像头的 RTSP 地址。萤石摄像头默认关闭 RTSP 功能需要在萤石云 App 中开启。在 easynvr 中点击“添加”填写设备名称、RTSP 地址。设置录像存储路径指向/vol1/1000/surveillance目录。开启录像计划保存。完成之后监控视频会持续写入 NAS 硬盘并且由于目录是共享的电脑上的 AI 分析脚本可以直接读取这些视频文件。4.3 其他值得在 NAS 上部署的 Docker 服务除了 Ollama 和 easynvr下面几个容器也可以大幅提升自动化工作流的能力容器用途端口nginx反向代理统一入口80/443watchtower自动更新容器镜像不映射端口postgres轻量数据库存储任务记录5432redis缓存与队列6379webhook接收外部回调触发脚本9000比如部署一个 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 -verbosehooks.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_tokenxxxxx通过 curl 命令即可向群内推送消息curl https://oapi.dingtalk.com/robot/send?access_tokenxxxxx \ -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_tokenxxxxx def send_dingtalk_message(text): data { msgtype: text, text: { content: text } } resp requests.post(webhook_url, jsondata) 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 通知为例如果你使用 iPhoneBark 是一个非常轻量的通知工具。它通过 HTTP GET 请求推送到手机通知栏没有复杂的鉴权流程。curl https://api.day.app/your_device_key/AI任务完成/NAS推理结果已保存Bark 特别适合作为个人开发者的独立通知通道适合不依赖公司群聊的场景。5.4 构建统一通知工具函数为了避免每个脚本都写一遍不同的 Webhook 调用我在本地 AI 工具环境中封装了一个notify.pyimport requests def send_notify(title, content, platformdingtalk): 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 fhttps://api.day.app/你的key/{title}/{content} data {} else: raise ValueError(fUnsupported platform: {platform}) res requests.post(webhook_url, jsondata) return res.json() if __name__ __main__: send_notify(部署完成, NAS 上的 Ollama 服务已正常启动)以后任何需要通知的场景一行代码就能接入不用重复造轮子。6. 从手动到半自动化把这几层真正串起来前面几节分别讲了存储、服务、通讯这一节是整套方案的灵魂——把三层业务串联成一个可流转的工作流。6.1 工作流设计示例假设你现在有一个需求每天定时让 NAS 上的 AI 模型生成一篇产品摘要并把结果发送到钉钉群。整体流程是这样的电脑上的 Python 脚本通过 Docker SDK 或 SSH 远程调用 NAS 上的 Ollama API。Ollama 模型生成文本返回给 Python 脚本。脚本把结果保存到 NAS 的ai-outputs目录。脚本将摘要内容和文件路径推送到钉钉机器人。手机端收到通知点击即可查看文件地址。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, jsonpayload) 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 fsummary_{date_str}.txt file_path fZ:/ai-outputs/{file_name} # Windows 网络驱动器方式 with open(file_path, w, encodingutf-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 21这样每天早上 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. 常见问题与排查思路在实际搭建这套环境的过程中最容易踩到下面几个坑。我整理成了一张表格按“现象 → 原因 → 解决”的顺序说明。问题现象常见原因解决思路Windows 无法映射 NAS 驱动器SMB 协议版本不兼容在 NAS 端开启 SMB2/3或在 Windows 中启用 SMB 1.0不推荐rclone 挂载后目录为空WebDAV 用户权限不足检查 NAS 用户对目标目录的读写权限Ollama API 返回 404模型未拉取完成先执行ollama pull再调用 API钉钉机器人消息发送失败Webhook 地址包含特殊字符未编码检查 access_token 是否正确必要时 URL 编码容器启动后立即退出挂载目录不存在或权限错误先手动创建宿主机目录再给予 777 权限定时任务没有执行cron 环境变量不完整在脚本开头设置 PATH 和 PYTHONPATHNAS 唤醒后 Docker 服务未启动容器未设置 restart 策略为所有容器设置restart: always消息通知延迟较长通讯平台机器人限频控制推送频率合并多条消息为一条 markdown如果遇到定时任务问题可以先手动执行一次脚本确认脚本本身没有依赖交互式输入再检查 cron 日志grep CRON /var/log/syslog如果看到任务已执行但没有输出多半是脚本中的路径没有写绝对路径或者 Python 环境变量不对。8. 最佳实践与工程化建议当这套工作流从“实验”走向“日常使用”就需要建立一些规范。下面这些建议来自我自己的维护经验。8.1 目录与命名规范在自动化工作流中所有文件名和时间戳最好统一格式。例如日期格式统一使用YYYYMMDD_HHMMSS。文件名中不要包含中文和空格避免跨平台兼容问题。不同来源的文件分别放入对应一级目录不要混放在一个下载目录里。8.2 配置管理不要把敏感信息写死在脚本里在我的脚本中钉钉机器人地址、NAS 密码、API Key 等信息都应该通过环境变量或配置文件管理。例如使用.env文件NAS_HOST192.168.1.100 OLLAMA_PORT11434 DINGTALK_WEBHOOKhttps://oapi.dingtalk.com/robot/send?access_tokenxxxxx BARK_API_URLhttps://api.day.app/xxxxxPython 中使用python-dotenv读取from dotenv import load_dotenv import os load_dotenv() DINGTALK_WEBHOOK os.getenv(DINGTALK_WEBHOOK)这样可以避免在代码仓库中泄露敏感信息。8.3 日志记录自动化任务不可见日志就是唯一的排查途径。所有脚本必须记录日志内容至少包括执行开始时间输入参数关键中间结果执行状态成功/失败失败时的错误堆栈Python 中推荐使用logging模块而不是到处printimport logging logging.basicConfig( filename/vol1/1000/scripts/logs/automation.log, levellogging.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 自动化欢迎在评论区聊聊你的方案和踩过的坑。