ChatGPT 接到文件和浏览器之后

有时, 我已经把问题说得很清楚, 却还没法开始. 文件在电脑里, 报错在终端里, 正在看的页面留在浏览器里, 上一次为什么这样改则写在另一份项目笔记中. 我知道它们彼此有关, 但隔着一个聊天窗口, 还得逐件搬过去.

复制一段代码, 补一张截图, 再解释这份文件放在哪里. 聊到一半, 本地内容变了, 刚才贴进去的又成了旧版本. 有时真正消耗耐心的, 就是这一来一回的搬运.

写好 Wiki 之后, 我想让 ChatGPT 直接查阅这些记录, 读取正在改的文件, 并在授权范围内操作页面.

我后来搭了几条连接. 一条通向本机的开发工作区, 一条延伸到已打开的 Chrome, 还有一条通向常驻 Mini 主机上的知识库.

接通以后, 我开始让它做一些日常的事: 帮我申请想试的新 AI 服务, 去京东找我需要的东西, 或者读一读电脑里正在改的文件.

先让它看见真正的文件

这套本地连接, 我用的是 DevSpace. 它在 Mac 上运行一个 MCP 服务, 把打开工作区, 读取与搜索文件, 编辑与写入等能力交给经过认证的 ChatGPT 调用. MCP 可以理解为双方约定的工具接口: ChatGPT 提出调用, 本地服务执行, 再把结果送回对话.

执行文件操作的, 始终是本机的程序. 单独打开一个聊天窗口, 并不会自动获得我的磁盘访问权. 我日常使用的 Codex 又是另一套工作入口; 这里记录的是给 ChatGPT 另行接上的连接, 两者不能因为都能写代码, 就混成一回事.

我们搭过的 DevSpace 链路, 从 ChatGPT 经认证入口和 Cloudflare Tunnel, 到达本机服务, 再进入允许的工作目录. 本地服务监听回环地址, 对外连通由隧道承担. Cloudflare 是这条链路中的中转方, 文件被读取回对话时, 内容也确实离开了本机, 不能把这种用法称作完全离线.

用起来, 先选定一个工作区, 之后围绕这个工作区读文件, 查内容, 做修改. 它看到的是磁盘上当时的版本, 写下的也是实际文件, 不必由我在聊天和编辑器之间再誊抄一次.

第一次验这条链路, 我们做的事情很小: 从 ChatGPT 读取目录, 创建一个测试文件, 再把它读回来, 最后到本机核对. 只有那份文件真的出现, 内容也一致, 才能说读写走通了. 一个服务进程显示运行中, 还不足以回答这个问题.

在项目里, 我会让它先读现有配置再解释某个行为, 找到实际调用位置再讨论怎么改, 或者把确认过的改动直接写回文件.

DevSpace 还提供 shell 能力, 可以运行检查和构建. 这也意味着, 不能把工作目录白名单误当作整个操作系统的沙箱. 文件工具的路径限制, 与命令进程在宿主机上的权限, 是不同层面的事. 对我来说, 接通之后仍然要看清调用会做什么, 改完仍然要检查 diff 和运行结果.

ChatGPT Developer mode 的官方文档支持通过 MCP 接入读写工具, 同时说明了写操作的确认机制. 真正能做哪些事, 还取决于服务公布的工具与相应权限, 并不是接上一个地址就什么都能做.

浏览器里, 有我已经打开的上下文

文件之外, 浏览器里也放着许多正在进行的事.

有些页面已经登录, 有些内容刚刚展开, 有些问题只有在当前页面里才看得明白. 把网址发过去, 不一定能重现同一个现场. 截图可以保留画面, 却不总适合阅读长段文字, 更不能代替页面上的实际操作.

于是, 我们又给 DevSpace 接了 Chrome.

其中一条路径专门读页面. 它通过 macOS 的 Apple Events 取得已打开页面里加载出来的文字, 链接和部分媒体信息. 对长页面, 可以分段读取. 这样, 我说看一下这个页面, 就不必先把整段内容复制出来.

不过, 页面没有加载的部分, 没有展开的回复, 跨域框架里的内容, 都不能假装已经读过. 读到图片的说明或地址, 也不等于看过图片本身. 这个区别, 在一篇很长的讨论里尤其容易被忽略.

需要动手时, 则由接入的 Chrome DevTools MCP 提供页面列表, 导航, 快照, 点击和输入等工具. 它连接的是已有的 Chrome 会话. 找到正确的标签页, 读取当前快照, 再根据里面的元素操作, 做完重新看结果.

这部分接入曾被一个很具体的问题绊住. 终端里能连接 Chrome, 换到后台服务却读不到需要的文件. 排查后发现, macOS 对运行进程的权限归属才是关键. 后来让有明确身份的 DevSpace Bridge App 持有后端进程, 再为这个 App 授权, 才把这层关系理顺.

连接已有浏览器, 也意味着操作可能带着现有登录态. 所以我保留了有限的工具集合, 没有把任意 JavaScript 执行和文件上传一起开放. 页面上的文字是要处理的材料, 不能因为它写着一句命令, 就变成我对助手的授权.

当时的验证覆盖了测试页面上的读取, 输入, 点击与截图返回. 它说明这些环节已经走通过, 不能因此推论每一个网站都能照常操作. 网站会变, 页面状态也会变, 具体任务仍要看当次结果.

申请一个新 AI 服务

最近申请一个新 AI 服务的体验资格, 就是一件很合适的小事.

我对它好奇, 想用, 却还没把申请流程摸清. 过去遇到这种情况, 往往要自己找入口, 看英文说明, 填表, 再把不确定的问题复制到对话里问. 如今可以让 ChatGPT 陪着往下走, 读当前页面, 理清字段, 在我给出信息以后填入对应的位置.

那次申请里, 有一道题问从哪里知道这个产品. 我说, 推特. 它便填入 X (Twitter). 表单还问了有没有喜欢的 meme, 可以留个链接.

后来, 申请补充信息提交了. 当时的对话记录写下了页面反馈: 对方会审核, 有访问资格再邮件通知.

到这里, 申请已经递出去, 还没有获得资格, 也没有开始调用模型.

后面我又想让它帮忙留意邀请邮件, 却遇到了另一层限制. 那个自动任务环境不能实际读取邮箱, 检查没有走通, 监控随后停了下来. 浏览器里办完申请, 和之后能否在后台持续等邮件, 原来是两项不同的能力.

下次安排邮件监控, 得先确认执行任务的环境能否访问邮箱.

去京东找东西, 协作完成比较

我也让它去京东搜索过想要的物品.

买东西时, 很多精力其实花在筛选上. 搜索词稍微换一下, 出来的东西就不同; 标题看着相近, 点进去才发现是另一个规格. 看过几个标签页, 又得回头确认刚才那一件到底哪里合适.

浏览器接进来以后, 这段过程就有了可以协作的空间. 我说需求, 它在页面上找, 我再根据结果补充偏好. 原先完全由自己承担的搜索与翻页, 可以交出去一部分.

下面用一个示意需求说明这种用法, 不对应某笔真实订单:

帮我在京东找一个桌面用的扩展坞. 先看接口够不够, 再看供电和体积. 把几款合适的放在一起比较, 先不用买.

找到商品以后, 还得核对页面选中的型号, 不能把同一链接下另一个规格的参数抄过来. 写着券后价, 也要弄清它附带什么条件. 看不见的运费和优惠, 就标为未确认.

沿着这个示例, 还可以把比较结果整理到本地笔记里. 浏览器读取商品信息, 文件工具保存结果, 以后再挑时可以继续比较这几项.

至于最后选哪一个, 要不要下单, 仍要等我看过再说.

文件读写, 也可以落在一件小事上

读写本机文件听着像开发者才需要的能力, 实际上也可以很朴素.

比如把一份已有的 Markdown 文档读出来, 找到要补充的段落, 将确认过的文字写回原文件. 修改之后再读一次, 看内容有没有落到正确的位置.

放到开发里, 则可以先搜索某个配置项, 读清它周围的内容, 做一处有范围的修改, 然后运行对应检查. 这样的步骤是工作流示例; 真正的一次改动是否成功, 仍以文件差异和检查结果为准.

合上笔记本以后, 知识库仍有一处入口

本地连接需要 Mac 开着, 服务也在运行.

可是, 如果只是想问一句上次那个项目做到哪里了, 我不希望答案总要等这台笔记本开机.

所以, 我把知识库的一个副本放在常驻的 Mini 上, 又为它准备了独立的 MCP 服务. 它的职责很窄: 搜索笔记, 列出文件, 读取文本, 读取允许范围内的证据图片.

这条入口只读, 没有写入, 删除或 shell 工具, 也不能顺着路径走到任意项目目录. 文件访问在服务端检查, 系统层面也对相关目录加了只读约束.

Mini 使用的是 OpenAI Secure MCP Tunnel. 隧道客户端从主机内部发起向外的 HTTPS 连接, 接收并转交 MCP 请求, 因而不需要为这项知识库服务开放公网入站端口. 它仍然需要正确的账户关联与授权, 服务和隧道也都要保持运行.

两条连接的用途如下:

Mac 合上以后, 第一条连接自然不能照常替它做事. 第二条不依赖 Mac 当时在线, 但只能看到 Mini 已经收到的内容. 同步因此成了整个安排里不可省略的一部分.

多台设备, 怎样读到同一段经历

我的知识库以 MacBook 为主要编辑源, 普通 Markdown 通过私有 Git 仓库同步到 Mini. 其他需要参与的终端, 也可以沿用同一套版本交接规则. 手机或另一台电脑上的 ChatGPT, 则通过配置好的知识库入口查询 Mini 上的副本, 不要求每台阅读设备都克隆一份仓库.

这里有两件不同的事: 编辑端负责让文件版本一致, 查询端负责找到已经同步的资料. 从手机发出一个问题, 不代表手机正在和 Mac 实时同步整个文件夹.

多端编辑最容易出问题的地方, 往往发生在写入之前. 一台机器忙了一会儿, 另一台也留了几处修改, 如果都只顾着把自己的版本推上去, 那些更晚发生的事情未必就能自然合到一起.

我会先确认设备与目录, 保护尚未提交的内容, 拉取远端更新, 再恢复并审查本地修改. 提交前检查差异, 推送前再看一次远端. 遇到无法明确处理的冲突, 就停下来, 保留现场.

Git 也保存了修改历史. 某个结论是什么时候补上的, 后来改过哪些内容, 都可以回头查.

原始私有资料另走一条路. 我没有把它们顺手塞进 Git, 而是通过 SSH 加密传输, 单向增量复制到 Mini 的独立私有目录, 不使用删除目标文件的同步选项. 普通笔记同步成功, 不能顺带说这一部分也完成了, 两条链路要分别核对.

在我的私有配置里, 少量明确授权的原始资料也可以从只读入口查询. 这不意味着整台主机的文件都向 ChatGPT 开放, 更不意味着资料仍只留在主机上: 被工具返回的内容会进入对话. 因此, 查询和文章里都不应附带无关的敏感内容.

定时同步只是兜底. 本机关了, 从本机发起的任务就不能照常执行; 网络没通, 也不能把等待误写成完成. 重要变更需要及时同步, 再核对两端的版本或文件结果.

有过一次, Mac 这一端已经推送, Mini 的 SSH 却没有连上. 那次能确认的, 就只能到推送为止. 后来再查询 Mini, 不能因为我记得本机已经改过, 就认定它一定读到了新内容.

一次工作怎样接着往前走

准备接着做一个旧项目, 可以先让 ChatGPT 从 Mini 的 Wiki 找到上次的决定和未完成项. 回到 Mac 上, 再通过本地工作区读取眼前的代码, 看笔记与现状是否一致. 涉及页面的问题, 则去已有的 Chrome 会话里查看, 或在授权下操作并核对结果.

收尾时, 我通常让 Codex 按 Wiki 的维护规则整理新的事实. 审查修改, 提交普通笔记, 同步到 Mini, 再从查询入口确认能找到更新. Mini 的只读工具本身不会替我写回这些内容.

使用时还要留意资料的版本. 旧笔记可能没跟上代码, Mini 也可能尚未收到 Mac 上的更新. 回答里注明读了哪份文件, 核对起来会方便很多.

本文依据截至 2026-09-19 的个人实现与既有验收记录整理, 不代表写作时重新检查了所有主机的在线状态. 私有入口, 账户标识, 具体路径与凭据均已省略. 文中的读写能力指分别授权的工具, Mini 知识库入口保持只读.