一万AI分享 把 DSH 变成 24 小时 AI 牛马：飞牛 NAS 与 Linux 异地访问实战
把 DSH 变成 24 小时 AI 牛马：飞牛 NAS 与 Linux 异地访问实战
说明：蒲公英的套餐、节点数量、带宽和客户端支持情况可能调整，使用前请以官方页面当前显示为准。
如果把 DeepSeek Harness（下文简称 DSH）只放在自己的电脑上，它就是一个不错的 AI 编程工具。
但如果把它放到一台不太关机的飞牛 NAS，或者一台长期在线的 Linux 服务器上，事情就不一样了。
它会慢慢变成一个 24 小时在线的 AI 程序员：
- 项目放进去，让 DSH 自己分析；
- 出现 Bug 时，让它自己检查日志和代码；
- 需要跑命令、改文件时，远程打开浏览器就能安排；
- 人可以出门，NAS 或服务器继续在家里干活。
问题也随之而来：
人在外面时，怎么打开家里 NAS 上真正运行的 DSH？
这篇文章围绕这个问题，比较三种异地访问方案，并重点记录我目前更常用的蒲公英虚拟组网方式。
一、先说结论：三种方案怎么选
| 方案 | 更适合谁 | 优点 | 需要接受的限制 |
|---|---|---|---|
| FN Connect | 只使用飞牛 NAS，希望少配置 | 系统自带，入门简单 | 受飞牛远程服务和套餐规则影响 |
| Cloudflare Tunnel | 预算为零、愿意自己折腾 | 免费、灵活，适合发布指定 Web 服务 | 需要域名和 Tunnel 配置，晚高峰线路体验可能波动 |
| 蒲公英 | NAS、Linux、电脑、手机都要互相访问 | 设备加入虚拟局域网，使用虚拟 IP 直连 | 每台设备要安装客户端；P2P 未打通时会走转发链路 |
如果只讨论“飞牛 NAS 接入蒲公英”，我建议的顺序是：fnOS 应用中心官方插件 > Docker Compose 客户端 > Linux 命令行客户端。原生插件最省事；插件缺失或希望统一管理配置时再用 Compose；Linux 命令行更适合没有 Docker、愿意自己维护依赖和服务自启动的用户。
我的选择逻辑很简单：
- 只想远程管理飞牛，先用 FN Connect；
- 想把某个服务发布到公网，且愿意维护域名和访问策略，可以考虑 Cloudflare Tunnel；
- 不想给每个服务开公网端口，还要在 NAS、Linux、笔记本和手机之间来回切换，蒲公英这种虚拟组网更符合我的使用习惯。
这不是说其中某一种方案一定最好。它们解决问题的方式不同，最终还是要看设备数量、网络环境、预算和你能接受多少维护工作。
二、DSH 到底适合做什么
Harness 这个词不用先研究得太复杂。简单理解，DSH 把三个东西放到了一起：
- 模型：负责理解需求和生成方案；
- 工作区：让模型读取项目文件和目录结构；
- 工具调用：在得到授权后读取文件、修改代码、执行命令并返回结果。
普通网页聊天通常是“你提问，AI 返回一段代码，你再复制到电脑里执行”。DSH 更像一个开发工作台：你给它一个项目目录，它可以先分析目录和依赖，再按照你的要求修改文件、运行测试或启动项目。
我喜欢它的另一个原因是自由度比较高。插件、Skills、MCP 和子 Agent 都可以根据自己的工作流继续扩展，而且项目本身是开源的。
当然，能做什么取决于它拥有的权限。不要把包含生产密钥、SSH 私钥、数据库密码或客户资料的目录直接交给它，也不要一上来就授权删除文件、重置服务或修改系统配置。
三、为什么要把 DSH 放到 NAS 或 Linux
1. 它可以一直在线
主力电脑不一定每天开着，NAS 和服务器通常更适合长时间运行。
把 DSH 放在这些设备上后，模型可以在后台慢慢分析项目。你不需要一直守在电脑旁边，过一段时间回来查看结果即可。
2. 它有 Web UI
只要浏览器能够访问 DSH，设备类型就不再那么重要。
电脑可以访问，手机也可以访问。你在办公室、路上或其他网络环境中，只要能够连回家里的设备，就能继续使用同一个 DSH 工作区。
3. 它更适合异地办公
我目前的一些服务和 API 项目已经放在长期在线的环境里。需要修 Bug 时，打开浏览器把问题交给 DSH，让它先分析、再测试，人不一定要坐在服务器旁边。
这也是我想解决远程访问问题的原因：不是单纯“打开一个网页”，而是把整套开发环境带出门。
四、第一种方案：FN Connect
FN Connect 是飞牛系统自带的远程访问方式，优点是不用另外搭建网络服务，配置路径也比较短。
如果你只有一台飞牛 NAS，主要需求是：
- 偶尔查看 NAS 文件；
- 远程打开飞牛后台；
- 在外面临时使用 DSH；
那么可以先从 FN Connect 开始。
需要注意两点：
- 带宽、连接方式和免费额度以飞牛当前页面显示为准；
- 远程访问 NAS 等于把自己的数据交给一条长期在线的访问链路，账号安全和设备管理不能省略。
飞牛之前出现过引发关注的安全事件。这里不是说 FN Connect 现在一定不安全，而是我个人会更谨慎：官方远程服务可以用，但不会把所有远程需求都压在同一条链路上。
五、第二种方案：Cloudflare Tunnel
Cloudflare Tunnel 是我使用时间比较长的一种方案。它可以把指定的内网服务通过 Tunnel 暴露出去，基础使用成本较低，也不需要直接在家里路由器上开放入站端口。
它的优点很明确：
- 免费方案可以先体验；
- 域名、访问策略和反向代理都比较灵活；
- 适合只发布某一个 Web 服务，而不是把整个局域网搬到公网。
但它也有我不太喜欢的地方。
白天访问通常没有问题，晚高峰偶尔会出现页面转圈、消息慢半拍的情况。普通网页慢一点还能接受，DSH 需要连续进行模型交互，点一下等一会儿，Vibe Coding 很容易变成 Vibe 等待。
Cloudflare Tunnel 仍然是一个实用选项，尤其适合预算为零、愿意自己维护域名、Tunnel、访问策略和线路优化的用户。只是如果你的目标是访问多台设备上的多个服务，配置量会逐渐增加。
六、第三种方案：蒲公英虚拟组网
蒲公英的思路和前两种不一样。
它不是把 DSH 单独发布到公网，而是把 NAS、Linux 服务器、笔记本和手机加入同一个虚拟网络。人在外面时，通过蒲公英分配的虚拟 IP 访问设备，看起来就像还在家里的局域网中。
蒲公英的官方活动页目前将这项服务定位为面向 AI 开发者的轻量化组网服务，支持通过虚拟 IP 访问本地 Web 应用和 SSH。官方页面列出了 Windows、macOS、Linux、iOS、Android 和 Docker 等客户端形态，具体支持范围和套餐以当前页面为准。
官方下载入口：
为什么我更喜欢这种方式
我的要求其实不复杂：
- 不想给每个服务都开公网端口；
- 不想每个项目都配一套域名和反向代理；
- 不想反复折腾优选 IP；
- 希望 NAS、Linux、电脑和手机之间可以直接互相访问。
虚拟组网刚好把这些设备放进同一张“假局域网”里。它解决的不是某一个 DSH 页面，而是整套远程开发环境的连通性。
七、飞牛 NAS 用户：优先原生插件，Compose 作为备选
先给飞牛用户一个明确结论：
如果你的 fnOS 应用中心能够搜索到“蒲公英”，优先安装官方插件；只有在插件不可用，或者你希望用 Docker Compose 统一管理时，再使用下面这套方案。
蒲公英官方的飞牛教程走的是“应用中心安装插件”路线，步骤更少，也不需要自己处理容器权限。Compose 方案的优势是配置文件可复制、可迁移，适合已经在使用 Docker 的用户。
这套判断和参数来自官方资料： 飞牛 NAS 安装教程、蒲公英客户端下载页以及 bestoray/pgyvpn 官方镜像。镜像标签、套餐和客户端支持范围可能更新，部署前仍应以官方页面为准。
这里部署的是蒲公英客户端，不是蒲公英服务端：
- 客户端的作用是让飞牛 NAS 加入虚拟网络，获得一个可从外部访问的虚拟 IP；
- 服务端面向转发、旁路转发或资源代理等场景，官方 Docker 说明要求更高权限和服务端成员 SID；
- 只是为了从手机或笔记本访问 NAS 上的 DSH，不需要部署服务端，也不要把服务端配置照搬过来。
如果已经安装了 fnOS 原生插件，请不要再同时启动下面的容器，避免两个客户端争抢同一台 NAS 的网络资源。
1. 准备账号和目录
你需要准备：
- 一个贝锐账号，或者蒲公英控制台中已经授权的客户端成员 UID；
- 对应的登录密码；
- fnOS 中一个可以读写的共享目录；
- 已经安装并能正常运行 Docker/容器管理功能。
在文件管理中创建一个项目目录，例如：
docker/pgyvpn/├── docker-compose.yml└── data/ ├── config/ └── log/目录名称可以换成自己喜欢的名字。下面的相对路径都以 docker-compose.yml 所在目录为基准。
2. 创建并修改唯一的 Compose 文件
在同一个目录新建 docker-compose.yml，完整粘贴以下内容，然后只修改 PGY_USERNAME 和 PGY_PASSWORD 两行：
services: pgyvpn: image: bestoray/pgyvpn:latest container_name: pgyvpn restart: unless-stopped network_mode: host cap_add: - NET_ADMIN devices: - /dev/net/tun:/dev/net/tun environment: PGY_USERNAME: "YOUR_PGY_USERNAME" # 修改为你的贝锐账号或客户端成员 UID PGY_PASSWORD: "YOUR_PGY_PASSWORD" # 修改为对应的登录密码 volumes: - ./data/config:/etc/oray/pgyvpn - ./data/log:/var/log/oray提醒：只需要修改上面
PGY_USERNAME和PGY_PASSWORD两行，其他配置保持不变。
把 YOUR_PGY_USERNAME 换成自己的贝锐账号或客户端成员 UID，把 YOUR_PGY_PASSWORD 换成对应的登录密码。PGY_USERNAME 支持贝锐账号或 UID；它和 DSH 使用的模型 API Key 不是一回事。不要保留示例值，否则容器虽然能启动，蒲公英客户端却无法登录。
因为账号和密码直接写在 Compose 文件中，这里不再创建 .env。这个文件只保存在自己的 NAS 上，不要上传到 GitHub、截图发群或发给别人；如果通过终端管理，也建议限制文件的读取权限。密码中含有空格、# 等字符时，保留外层英文双引号；如果密码本身含有双引号，请按 YAML 规则进行转义。
示例采用官方镜像的 latest 标签，用户无需修改这一行。后续镜像版本由维护者根据官方发布情况更新；升级前先备份 data/config，并保留回滚用的旧标签。
这份配置对应官方 Docker 客户端的关键参数：
network_mode: host：让容器直接使用 NAS 的网络栈，避免虚拟网卡和端口映射互相干扰；cap_add: NET_ADMIN：允许客户端创建和管理虚拟网络接口；/dev/net/tun：蒲公英客户端创建 TUN 虚拟网卡所需的设备；- 两个目录挂载：保存配置和日志，重建容器后不需要重新从零开始。
不要自行添加 ports。 这是主机网络模式，蒲公英不会替 DSH 转发 Web 端口；DSH 仍然使用它自己的监听端口。也不建议默认勾选 privileged 特权模式，客户端先按上面的最小权限配置运行即可。官方文档中 privileged 针对的是服务端转发场景，不是普通客户端接入。
3. 在 fnOS 中一键启动
不同版本的 fnOS 可能把入口叫作“Docker 管理器”“容器管理”或“Compose 项目”，但流程基本一致：
- 打开 fnOS 的 Docker/容器管理页面；
- 进入 Compose 项目，选择“新建项目”；
- 项目目录选择刚才的 docker/pgyvpn；
- 如果页面支持直接编辑 Compose，就粘贴上面的配置；如果页面要求上传文件，选择
docker-compose.yml； - 点击创建并启动。
如果你更习惯终端，也可以在项目目录执行：
docker compose up -d第一次启动会拉取官方镜像，速度取决于 NAS 的网络和镜像仓库连通性。容器显示“运行中”后，先不要急着打开 DSH，继续检查蒲公英客户端是否真的登录成功。
4. 检查登录状态和虚拟 IP
在 fnOS 容器管理页面打开 pgyvpn 的日志，或者执行：
docker logs --tail=100 pgyvpn重点看是否出现登录成功、虚拟网卡创建和获得虚拟 IP 等信息，不要把包含账号或密码的日志原样发到评论区。
如果镜像没有自动完成登录，可以打开容器终端执行官方客户端命令：
docker exec -it pgyvpn /bin/shpgyvisitor退出终端后，在蒲公英控制台或成员列表中找到这台飞牛 NAS，记录它的虚拟 IP。这个地址通常不是家里的 192.168.x.x，而是蒲公英分配的虚拟网段地址。
5. 从外部网络访问 DSH
在手机上关闭 Wi-Fi，切换到 5G 或其他外部网络，并先安装蒲公英手机客户端、登录同一账号或已授权成员。然后访问：
http://NAS虚拟IP:DSH端口例如 DSH 端口为 3000，就把地址写成：
http://172.16.0.10:3000如果蒲公英显示在线但页面打不开，优先检查 DSH 是否只监听了 127.0.0.1。这种情况下，虚拟网络本身是通的，但 DSH 只接受 NAS 本机连接；应按 DSH 当前版本的配置方式调整监听地址，同时保留登录认证和 NAS 防火墙，不要为了省事直接把所有服务暴露到公网。
6. 飞牛 Compose 常见问题
| 现象 | 先检查什么 |
|---|---|
| 日志提示无法创建 TUN 或虚拟网卡 | 确认 NAS 存在 /dev/net/tun，Compose 同时包含 NET_ADMIN 和 devices，并使用主机网络模式 |
| 容器运行但没有虚拟 IP | 检查 Compose 中的 PGY_USERNAME、PGY_PASSWORD 是否已替换；必要时改用控制台提供的客户端 UID |
| 页面提示端口映射冲突 | 删除 Compose 中的 ports，主机网络模式不需要端口映射 |
| 镜像拉取失败或架构不匹配 | 确认 NAS CPU 架构和 Docker 仓库连通性；也可以先使用 fnOS 应用中心的官方插件 |
| P2P 未建立、访问速度很慢 | 在蒲公英客户端查看是否走了转发链路，套餐和转发带宽以当前官方页面为准 |
只有在确认 TUN、账号和网络模式都正确、日志仍明确要求更高权限时，才考虑在 fnOS 界面临时测试特权模式。特权容器会扩大对 NAS 主机的访问范围，测试完成后应优先回到最小权限配置。
7. 停止、升级和回滚
升级前先备份 data/config。在 fnOS Compose 项目页面停止并重新拉取镜像即可；终端方式为：
docker compose pulldocker compose up -d如果需要撤销本次部署：
docker compose down这只会停止并移除蒲公英客户端容器，不会删除 DSH 工作区；data/config 和 data/log 也会保留。确认不再使用后，再从蒲公英控制台移除这台设备的授权。
八、从注册到打开 DSH：完整操作流程
下面按我视频里的使用顺序整理。示例中的 172.16.0.x 只是格式示意，实际地址以蒲公英客户端显示为准。
第一步：注册或登录贝锐账号
没有账号就注册贝锐账号，已有账号直接登录。
这里不需要先研究复杂的 NAT、端口映射或公网 IP。先把账号准备好，后面每台设备都使用同一个账号登录。
第二步：先确认免费节点是否够用
视频录制时，我的测试场景是：
- 一台飞牛 NAS；
- 一台外出的笔记本；
- 一部手机。
三台设备刚好可以组成一个最小测试闭环。
如果你也是这种规模，建议先查看当前页面是否有可用的体验节点，不够再考虑购买更多成员。蒲公英的免费节点、成员数量、价格和活动规则可能变化，不要把视频中的数字当成永久承诺。
第三步：在需要互访的设备上安装客户端
打开蒲公英客户端下载页，按设备类型安装：
- 飞牛 NAS：按当前系统支持的方式部署客户端；如果使用 Docker 版本，要确认容器网络和持久化配置；
- Linux 服务器：安装 Linux 客户端；
- Windows 或 macOS 笔记本：安装桌面客户端；
- 手机：安装 Android 或 iOS 客户端。
不要把电脑客户端安装包直接套到 NAS 上。NAS 端能否使用原生包、Docker 或其他方式，要以当前设备架构和官方支持为准。
第四步：所有设备登录同一个账号
依次在 NAS、笔记本和手机上打开蒲公英客户端，并登录刚才注册的同一个贝锐账号。
按照官方快速上手流程，设备登录后会自动进入同一个虚拟网络。正常情况下，你不需要自己配置路由器端口映射，也不需要申请公网 IP。
此时打开成员列表，应该可以看到各台设备及其连接状态。
第五步：记下 NAS 的虚拟 IP
在成员列表中找到飞牛 NAS，记录它显示的虚拟 IP，例如：
172.16.0.10这个地址可以理解成 NAS 在虚拟局域网中的新门牌号。之后访问 DSH、SSH 或其他 Web 项目时，都使用这个虚拟 IP，而不是家里的普通内网 IP。
第六步：用手机网络打开 DSH
先关闭手机 Wi-Fi，确认手机使用的是 5G 或其他外部网络。
然后在手机浏览器输入：
http://172.16.0.10:<DSH端口>把 172.16.0.10 换成你自己的 NAS 虚拟 IP，把 <DSH端口> 换成实际端口。
如果页面能够打开，看到的就是 NAS 上真正运行的 DSH，不是阉割版网页。原来的工作区、模型配置和工具能力仍然由 NAS 上的实例提供。
第七步：用只读任务测试
第一次不要直接让 DSH 重构整个项目。先用一个不会修改文件的任务确认链路正常：
请先读取当前工作区的目录结构，告诉我项目使用的主要技术、启动方式和可能的风险。不要修改任何文件，也不要执行删除、安装或重启命令。如果它能正常读取目录，再测试更具体的项目检查：
请检查当前项目是否可以在本地启动。只执行读取和检查命令，不要修改文件；如果必须执行下一步操作，请先列出方案并等待我确认。这样可以分开确认：
- 手机是否能访问 NAS；
- DSH 页面是否正常；
- API 密钥和模型是否能调用；
- 工作区是否有正确的读写权限；
- 工具调用是否符合预期。
九、Linux 服务器和本地 Web 项目也能这样访问
Linux 服务器的流程完全一样：
- 安装蒲公英客户端；
- 登录同一个贝锐账号；
- 在成员列表中找到 Linux 服务器的虚拟 IP；
- 通过虚拟 IP 和端口访问服务。
SSH 远程登录
例如：
ssh user@172.16.0.20其中 172.16.0.20 是 Linux 服务器的蒲公英虚拟 IP，user 换成服务器上的实际用户。
SSH 能否连接，还取决于服务器的 sshd 配置、防火墙和账号权限。蒲公英只负责把网络路径打通，不会替你修复 Linux 登录配置。
访问本地 Web 项目
如果 DSH 在 Linux 服务器上启动了一个 Web 项目，例如端口是 3000，手机或笔记本可以访问：
http://172.16.0.20:3000这意味着你不仅可以远程让 DSH 写代码，还可以在手机上直接查看它启动的 Web 页面，形成“远程改代码 + 远程看效果”的闭环。
十、一定要检查 P2P 还是转发
虚拟组网能连上，不代表一定走的是点对点直连。
如果两边 P2P 成功，数据通常直接在设备之间传输，速度主要取决于两端本地网络。若网络环境比较特殊，P2P 没有打通，就可能通过平台转发。
蒲公英官方活动页目前展示的规则是：
- P2P 直连不限流量、不限速；
- P2P 未建立时，转发带宽为 2 Mbps。
套餐和规则可能调整，实际以当前页面和账户状态为准。
所以安装完成后，建议第一时间打开连接状态查看：
- 是否显示 P2P；
- 是否出现转发标识；
- 延迟和丢包是否正常；
- 实际访问 DSH 时是否明显变慢。
不要看到“不限流量”就直接开始狂喜。如果实际每天都在走 2 Mbps 转发，体验和 P2P 直连会完全不同。
十一、远程访问时的安全边界
1. 虚拟局域网不等于自动安全
蒲公英解决的是设备之间的访问路径，不会替你完成 DSH 的身份认证。DSH、NAS 后台、SSH 仍然要使用强密码和最小权限。
2. 不要把 DSH 管理端口裸露到公网
虚拟组网的价值之一，就是可以不把 DSH 直接发布到公网。除非你明确知道反向代理、HTTPS、访问控制和日志审计怎么配置，否则不要为了“手机能打开”而直接开放公网端口。
3. 工作区里不要放真实密钥
DSH 可以读取工作区文件。下面这些内容建议使用脱敏副本，或者放在应用无法直接读取的位置：
.env文件；- SSH 私钥；
- 云厂商 Access Key；
- 数据库密码；
- 生产环境配置；
- 客户资料和隐私数据。
4. 给设备做台账
手机、笔记本或 NAS 更换、丢失、转手时，要及时从虚拟网络中移除旧设备。不要让已经不再受控的设备继续保留访问权限。
5. 先只读，后执行
涉及删除文件、安装依赖、重启服务、修改防火墙或数据库操作时，先让 DSH 解释方案，确认影响范围，再允许它执行。
十二、常见问题
1. 手机能登录蒲公英，但打不开 DSH
依次检查：
- NAS 和手机是否登录同一个账号；
- NAS 客户端是否在线；
- 使用的是 NAS 的虚拟 IP，而不是家里的普通内网 IP；
- DSH 端口是否填写正确；
- NAS 防火墙是否允许来自虚拟网卡的访问；
- DSH 是否只监听
127.0.0.1； - 手机是否真的已经关闭 Wi-Fi。
如果 DSH 只绑定本机回环地址，即使虚拟网络已连通，其他设备也无法访问。调整监听地址前，先查清 DSH 当前版本的配置方式，不要盲目把所有服务开放到 0.0.0.0。
2. 页面能打开，但模型没有回复
这通常不是组网本身的问题。检查：
- DSH 的 API Key 是否有效；
- 模型接口地址和模型名称是否正确；
- NAS 能否访问模型服务；
- 账户是否还有额度；
- DSH 日志中是否有超时或鉴权错误。
蒲公英负责设备互访，不会自动解决模型 API 的网络、额度或鉴权问题。
3. P2P 没有成功，访问速度很慢
先确认连接是否走了转发。如果是，2 Mbps 转发带宽会影响大文件传输和交互体验。
可以尝试：
- 检查两端客户端版本；
- 更换网络环境测试；
- 确认系统没有拦截客户端所需的通信；
- 查看当前套餐和平台状态；
- 在不同时间段比较延迟和速度。
不要只根据一次 Ping 结果判断长期体验。
4. SSH 连不上，但 Web 页面正常
这通常说明虚拟网络基本可达，问题集中在 SSH 服务本身。检查：
- SSH 端口是否还是默认的
22； sshd是否正在运行；- 服务器防火墙是否放行；
- 登录用户是否允许远程登录；
- 是否需要指定私钥或其他认证方式。
5. 飞牛文件管理里看不到 DSH 项目
远程组网只解决访问路径，不会改变 DSH 的工作区配置。确认项目是否放到了应用实际使用的工作目录，并检查应用用户的读写权限。
十三、我最后怎么选
如果只是偶尔在外面管理一台飞牛 NAS，FN Connect 足够简单。
如果只想把一个 Web 服务发布给外部访问，并且愿意自己维护域名、Tunnel 和访问控制，Cloudflare Tunnel 仍然很实用。
如果设备数量比较多，NAS、Linux、电脑和手机都要互相访问，又不想给每个项目单独开公网端口，那么蒲公英的虚拟局域网更适合我。
它的核心价值不是“让 DSH 多一个入口”，而是让整套开发环境拥有一个统一的远程访问路径：
NAS / Linux 服务器 ↓ DSH 工作区 ↓蒲公英虚拟 IP 访问 ↓手机、笔记本、外部网络总结
把 DSH 放到一台 24 小时在线的 NAS 或 Linux 服务器上，它就不再只是“当前电脑里的 AI 工具”，而更像一个随时可以接活的远程开发助手。
异地访问方案可以按下面的思路选择：
- 飞牛用户优先试 FN Connect；
- 只发布单个 Web 服务，可以考虑 Cloudflare Tunnel；
- 多台设备要互相访问，又不想暴露公网端口，可以尝试蒲公英虚拟组网；
- 组网成功后，用虚拟 IP 加端口访问 DSH 或其他本地 Web 服务；
- 先确认 P2P 或转发状态，再评估实际速度；
- 无论使用哪种方案，都要保管好账号、API Key、SSH 凭据和工作区数据。
一台长期在线的 NAS，加上 DSH，再把异地访问这一步补上，带来的感觉确实很像：家里一直有一个 AI 程序员在等着接活。
不过它毕竟是能读文件、改代码和执行命令的工具。远程方便的同时，也要保留人工确认和备份习惯。
相关链接：
支持与分享
如果这篇文章对你有帮助，欢迎分享给更多人或赞助支持！