以前使用 ChatGPT 辅助开发时，我经常遇到一个问题：
ChatGPT 可以分析代码、给出命令、生成修改方案，但真正执行时，很多操作还是需要我自己在本地终端完成。
一个很常见的流程是：
ChatGPT 给出命令
↓
复制命令
↓
切换到终端执行
↓
复制执行结果
↓
回到 ChatGPT
↓
继续分析下一步如果只是执行一两条命令，这当然没有什么问题。
但如果维护的是一个长期项目，一个任务需要连续读取多个文件、检查 Git 状态、执行测试、分析结果、再次修改，那么这种在 ChatGPT 和本地终端之间不断“复制—粘贴—切换”的操作，很快就会变成明显的效率损耗。
最近我开始实际使用 Desktop Commander 的 Remote MCP，把 ChatGPT 和自己的 Ubuntu 开发环境连接起来。
使用一段时间之后，我发现：
Desktop Commander 真正提高的，并不只是“执行命令”的效率，而是减少了 ChatGPT 与本地开发环境之间大量没有必要的人工中转。
当然，它也不是无限制使用的。Remote MCP 本身存在 Tool calls 使用额度，而且如果工作流中还涉及 Codex，也需要额外注意 Codex 自己的额度消耗。
这篇文章记录一下我实际安装、连接和使用 Desktop Commander 的过程。
一、Desktop Commander 解决的是什么问题？
Desktop Commander 可以通过 Remote MCP，让 ChatGPT 在经过授权以后访问自己的电脑。
它能够让 ChatGPT 接触到真实的：
文件系统
Git 仓库
项目源代码
配置文件
本地终端
命令执行结果以前如果我问 ChatGPT：
这个测试为什么失败？ChatGPT 本身并不知道我的本地项目当前到底是什么状态。
我通常需要手动把这些东西提供给它：
git status --short
git log -1 --oneline
git diff然后再复制测试输出、相关代码和配置文件。
有时候一个问题需要检查五六个文件，我还需要继续把不同文件的内容粘贴到聊天里。
Desktop Commander 的意义，就是在 ChatGPT 和本地电脑之间增加了一座桥。
从原来的：
ChatGPT
↓
我
↓
本地电脑逐渐变成：
ChatGPT
↓
Desktop Commander
↓
Remote MCP
↓
本地电脑这样一来，很多原本必须由我负责传递的信息，就可以由 ChatGPT 自己获取。
二、通过 Remote MCP 连接自己的电脑
Desktop Commander 首先需要把电脑注册为一个可以通过 Remote MCP 访问的设备。
进入设备连接页面以后，会看到类似下面的命令：
npx @wonderwhy-er/desktop-commander@latest remote
我目前使用的是 Ubuntu，所以直接在本地终端运行这条命令。
运行以后，Desktop Commander 会引导浏览器完成设备授权。
这里有一个很重要的点：
ChatGPT 并不是安装插件以后就自动拥有本机访问权限。
电脑必须先经过明确的 Remote MCP 设备授权。
三、验证设备
Remote MCP 启动以后，浏览器会进入设备验证页面。
页面中会显示设备验证码，并要求确认：
Verify Device
确认以后，页面会显示：
Device verified
This device is now authorized.
到这里，这台电脑才正式成为一个已经授权的 Remote MCP 设备。
四、确认电脑已经 Online
返回 Desktop Commander 控制台以后，可以看到已经授权的设备。
我的设备显示为：
wangqiang-ThinkPad-T570状态：
Online
这个页面还有一个我比较在意的设计：
可以随时点击：
Revoke撤销某台设备的授权。
也就是说，Remote MCP 并不是授权以后就完全失去控制。
如果以后某台电脑不再使用，可以主动断开。
页面同时还能看到 Desktop Commander 支持的使用入口，包括 ChatGPT、Claude 和其他 MCP Client。
所以更准确地说，Desktop Commander 提供的是一条 Remote MCP 通道，而 ChatGPT 是可以使用这条通道的客户端之一。
五、在 ChatGPT 中安装 Remote Desktop Commander
设备连接完成以后，还需要在 ChatGPT 中安装 Remote Desktop Commander。
插件页面对它的功能描述其实已经比较清楚：
ChatGPT 可以通过 Desktop Commander 的 Remote MCP，访问已经授权电脑的文件系统和终端。
安装完成以后，可以看到：
Remote Desktop Commander 插件已安装并且可以直接：
在聊天中试用
到这里，完整链路基本建立：
ChatGPT
↓
Remote Desktop Commander
↓
Remote MCP
↓
我的 Ubuntu
↓
本地文件 / Git 仓库 / Terminal六、真正有价值的不是“帮我执行一条命令”
一开始看到 Remote MCP 时，我其实没有马上觉得它特别重要。
因为单纯从功能上来看：
ChatGPT 可以帮我运行终端命令。
这件事情似乎也没有多复杂。
但真正使用以后，我发现，它最重要的价值其实不是执行某一条命令，而是：
让 ChatGPT 可以直接获取开发环境的上下文。
这两件事情的价值完全不同。
例如以前排查一个问题，我可能需要自己告诉 ChatGPT：
当前 Git HEAD 是什么
working tree 是否 clean
最近修改了哪些文件
某个测试为什么失败
配置文件现在是什么内容
相关文档规定的流程是什么现在 ChatGPT 在获得授权以后，可以自己去检查其中很多内容。
于是开发模式从：
我负责收集信息
↓
我把信息发送给 ChatGPT
↓
ChatGPT 分析
↓
ChatGPT 给我命令
↓
我执行命令
↓
我再把结果发回来变成了：
我定义任务目标和边界
↓
ChatGPT 自己获取必要上下文
↓
ChatGPT 分析
↓
ChatGPT 执行部分操作
↓
根据真实结果继续处理
↓
我负责关键决策和最终确认这才是我感觉效率提升最明显的地方。
七、我目前主要把它用于 go-tour-i18n
我现在比较典型的实际使用场景，是自己的：
go-tour-i18n项目。
这是我长期维护的 A Tour of Go 多语言翻译项目。
随着语言数量不断增加，现在这个项目早就已经不只是“把英文翻译成其他语言”。
它逐渐形成了一套比较完整的工程工作流：
Locale 初始化
↓
Glossary
↓
TranslationUnit export
↓
语言生成
↓
Process
↓
Validation
↓
Candidate Snapshot
↓
独立 Quality Check
↓
Revision
↓
Promotion
↓
Course SEO
↓
Locale Surface Review
↓
Preview
↓
Production其中很多阶段又存在严格的：
输入文件
状态检查
Git identity
validation
review gate
promotion gate
production gate以前即使 ChatGPT 理解整个流程，它依然有一个天然限制：
它不知道我本地仓库此刻到底处于哪个状态。
于是我需要不停告诉它：
当前 HEAD 是什么
git status 是什么
刚刚执行的 CLI 返回什么
哪个 batch 已经完成
哪个文件发生了修改
当前 diff 是什么现在有了 Desktop Commander，这部分信息中的很多内容可以直接从本地环境读取。
对于这种长期维护、状态很多、流程又比较严格的项目，价值尤其明显。
八、我最喜欢它处理的几类任务
目前实际使用下来，我认为 Desktop Commander 最适合的是那些需要不断读取上下文和连续判断的开发任务。
例如阅读仓库规则。
我的项目里有很多正式文档：
AGENTS.md
docs/...以前为了避免 ChatGPT 使用旧规则，我需要不断提醒：
请以当前仓库文件为准，不要使用聊天里的旧内容。
现在它可以直接读取当前文件。
另一个很适合的场景是 Git 状态检查。
开发过程中下面这些命令出现得非常频繁：
git status --short
git diff
git diff --cached
git log -1 --oneline这些操作本身几乎没有什么思考价值，但以前必须由我负责执行和复制。
还有一些问题需要同时检查：
源代码
测试
配置
manifest
glossary
文档如果完全依靠聊天上传和复制，操作会非常繁琐。
Remote MCP 对这种问题帮助很明显。
九、Desktop Commander 也不意味着“所有事情都让 AI 做”
不过，在开始使用 Remote MCP 以后，我反而更加确定了一件事情：
能自动执行，并不意味着所有操作都应该自动执行。
我现在更愿意把 Desktop Commander 当成一个能够真正进入开发环境的高级助手，而不是把整台电脑完全交给 AI。
例如 Production 发布、DNS/CDN 修改、破坏性命令、重要 Git 提交、线上服务变更，以及必须人工完成的视觉验收，我仍然会保留明确的人工控制。
尤其是：
rm
部署
发布
DNS 修改
线上配置修改
账号操作
付款操作这类操作的风险和简单读取文件完全不是一个级别。
所以我更喜欢的使用方式是：
AI 负责读取、分析和机械性操作
人负责边界、风险和最终决策而不是追求“全自动”。
十、Desktop Commander 本身也有使用额度
这一点是我真正开始频繁使用以后才特别关注的。
Desktop Commander 控制台左下角会显示：
Tool calls我截图时的状态是：
12%
1,234 of 10,000 this month下面同时还有：
Upgrade to Pro
也就是说，至少我目前使用的方案并不是无限调用。
如果只是偶尔让 ChatGPT：
看一个文件
查一次 Git 状态
运行一条命令那么调用量可能增长得比较慢。
但如果真正开始把它用于持续开发，一个“任务”背后往往并不只是一条 Tool call。
ChatGPT 可能需要：
列目录
↓
读取文件
↓
搜索代码
↓
读取第二个文件
↓
运行命令
↓
读取命令结果
↓
修改文件
↓
再次测试所以一个看起来并不复杂的任务，实际上可能产生多次调用。
这一点让我开始意识到：
Remote MCP 本身也是一种需要管理的开发资源。
十一、Desktop Commander 的 Tool calls 和 Codex 额度不是一回事
这里还有一个很容易混淆的问题。
我现在同时也会使用 Codex。
在相关开发界面中，可以看到：
本地
关联 Codex Web
云端以及：
5 小时
1 周
剩余用量
Desktop Commander 和 Codex 的额度需要分开理解。
Desktop Commander 这一侧，我现在最直观能够看到的是：
Remote MCP Tool calls例如：
1,234 / 10,000 this month而 Codex 则有自己的使用额度。
但这里还有一个我实际使用以后才注意到的细节：
Codex 的额度并不只是我主动进入 Codex、手动发送任务时才可能消耗。
在使用 ChatGPT 处理开发任务的过程中，我有时会看到 ChatGPT 把部分任务继续交给 Codex 执行。
也就是说，从我的实际使用角度看：
我没有主动打开 Codex并不能简单等同于：
这一轮一定没有使用 Codex 额度因此现在我会把这几个资源分开观察：
ChatGPT 本身的使用
Desktop Commander Remote MCP Tool calls
Codex 使用额度一次完整的开发任务，有可能涉及其中不止一种。
这也改变了我后面对工具的分工。
我的目标不是所有开发任务都让 Codex 完成。
相反，我更希望：
能够安全由普通 ChatGPT + Desktop Commander 完成
↓
尽量使用这套组合
真正需要 repository-level 修改、复杂诊断或更重开发任务
↓
再使用 Codex这样可以让不同工具各自做更适合的事情，同时也更容易控制额度。
十二、它真正节省的是“人工中转”
用了几天以后，如果一定要我总结 Desktop Commander 最大的价值，我觉得不是：
AI 能运行终端了。
而是：
大量人工中转消失了。
以前我有很多时间花在：
复制 ChatGPT 命令
↓
切到 Terminal
↓
执行
↓
复制输出
↓
切回 ChatGPT
↓
粘贴结果
↓
等待下一条命令这里绝大部分动作几乎不包含真正的判断。
但它们会持续打断思路。
当一个任务持续半个小时甚至几个小时以后，这种切换次数非常可观。
Remote MCP 并没有替代最重要的技术判断。
它更多是在减少这些：
人其实没有必要亲自做，但以前又不得不做的机械操作。
这可能也是为什么我用了以后会明显感觉开发效率提高。
十三、为什么我现在越来越看重这种模式？
最近这一两年，AI 编程工具越来越多。
很多工具都在强调：
生成代码
自动修改项目
自动完成任务但我现在越来越觉得，真正影响长期开发效率的，并不只有模型能不能生成正确代码。
还有一个很现实的问题：
模型能不能看到真实的工作环境。
如果 AI 每次开始任务，都只能看到用户复制进去的一小段内容，那么即使模型本身很聪明，也会产生大量上下文传递成本。
而 Remote MCP 这种模式解决的是：
AI
↓
直接接触真实开发环境这使得 ChatGPT 不再只是“根据我提供的一小块材料回答问题”。
它开始能够主动获取完成任务需要的信息。
我觉得这个变化可能比单纯再提高一点代码生成能力更加实际。
十四、哪些人可能最适合使用？
如果平时只是偶尔问 ChatGPT：
这段代码是什么意思？或者：
帮我写一个函数。那么 Desktop Commander 带来的提升可能没有那么明显。
但是如果平时经常维护真实项目，而且工作中存在大量：
- Git 仓库操作
- 多文件分析
- 测试排错
- 日志分析
- 配置检查
- CLI 工作流
- 重复性的项目维护
那么 Remote MCP 的价值会更加明显。
我自己显然属于后一种情况。
尤其是 go-tour-i18n 这种越来越工程化的项目，很多工作其实并不难，但步骤非常多。
这类项目恰好很适合减少人工中转。
十五、现在我对 Desktop Commander 的定位
经过这次实际使用，我暂时不会把 Desktop Commander 定义成：
AI 全自动开发工具。
我更愿意把它理解成：
ChatGPT 和真实开发环境之间缺少的那座桥。
ChatGPT 本身已经可以：
理解需求
分析代码
设计方案
生成修改
判断错误
解释测试结果而 Desktop Commander 补上的则是：
真实文件系统
真实 Git 仓库
真实 Terminal
真实项目状态
真实执行结果当这两部分连接起来以后，开发体验确实发生了比较明显的变化。
十六、目前还需要继续观察的问题
虽然我现在已经确认 Desktop Commander 对自己的开发工作有帮助，但还没有到“以后所有开发工作都依赖它”的程度。
我目前最关心的还是两个实际问题。
第一个是：
每月的 Tool calls 对我的真实开发强度到底够不够？
我现在已经开始把它用于比较长的开发流程。
如果调用量持续增加，那么后面是否需要升级方案，需要根据实际使用数据判断。
第二个是：
哪些任务交给 ChatGPT + Desktop Commander 最划算，哪些任务仍然更适合 Codex？
现在我已经发现，两者并不是简单的替代关系。
Desktop Commander 更适合帮助 ChatGPT获得真实本地环境，而 Codex 在复杂代码修改和更重的 repository-level 工作上仍然有自己的价值。
我现在更希望形成一种稳定的分工，而不是所有任务都塞给同一个工具。
总结
以前我使用 ChatGPT 做开发时，它更像一个坐在旁边的技术顾问：
我给它材料
↓
它分析
↓
它告诉我怎么做
↓
我自己执行连接 Desktop Commander Remote MCP 以后，它开始更接近一个真正进入开发环境的协作者：
我提出目标
↓
ChatGPT 查看真实仓库
↓
读取需要的文件
↓
运行部分命令
↓
根据真实结果继续分析
↓
我负责关键决策和最终确认我觉得这才是这类工具最有价值的方向。
不是让 AI 代替人承担所有决定，而是：
把没有必要由人承担的机械操作交给工具，把真正需要判断的事情留给人。
至少从我目前在 go-tour-i18n 项目中的实际体验来看，Desktop Commander 确实已经开始提高我的开发效率。
接下来我还会继续观察它的 Remote MCP Tool calls 消耗、长期稳定性，以及 ChatGPT、Desktop Commander 和 Codex 三者怎样分工最合理。
如果后面使用方式有比较明显的变化，我再继续记录。
需要长期技术维护或远程问题排查？
我是拥有 15+ 年经验的 PHP / Go 后端工程师，长期关注已有系统维护、Bug 修复、性能优化、服务器排查、WordPress 网站维护和小功能迭代。
如果你的项目遇到以下情况，可以先从一次小问题排查开始合作：
- ✅ PHP / Laravel / Yii2 老项目无人维护
- ✅ Go / Gin 后端接口需要排查或优化
- ✅ WordPress 网站访问慢、报错或插件冲突
- ✅ Nginx / MySQL / Redis / Linux 服务器异常
- ✅ CDN / Cloudflare / DNS / HTTPS 配置问题
- ✅ 需要长期远程技术支持或兼职维护
更多介绍请查看：关于我 & 合作
微信：13980074657
邮箱：shuijingwanwq@gmail.com
Telegram：@shuijingwan
GitHub：https://github.com/shuijingwan