简介： 从 ChatGPT 文件库把 Markdown 自动存入 GitHub，关键不只是连接器。本文说明 MCP、定时任务、变更检测、去重、校验与安全删除之间的区别。
ChatGPT 文件库里积攒了很多文章草稿，GitHub 也能通过连接工具创建文件。把两边接起来，稿子不就能自己搬家了吗？
只要当前会话有权读取源文件并写入 GitHub，按指令转存就有实现路径。但要让它在新文件出现时自动启动，还得有人负责发现“有新货到了”。
仓库里有叉车，有司机，还有打开的大门。偏偏没人装门铃。
一、会搬文件，不等于知道什么时候搬
可靠的同步至少包括四件事：发现变更、读取原件、写入仓库、读回核对。
GitHub 提供创建和更新仓库文件的正式 API。更新现有文件需要当前文件的 SHA，并且要具备相应权限。[3] ChatGPT 文件库的用途则是保存和再次使用上传或生成的文件。[1]
关键区别在于：聊天时能够访问某份文件，并不等于外部程序可以自动订阅整个文件库的新文件通知。截至 2026 年 10 月 18 日，本次核对的公开说明没有证实一个面向普通用户、直接以文件库“新增文件”为触发条件的通用同步功能。
车能开，发车信号还得另想办法。
二、装上 MCP，门铃就会自己响吗？
MCP 是让 AI 与外部工具对接的一种通用方式。正确授权的 GitHub 工具能提供文件创建、修改等操作。
但 MCP 本身不会凭空赋予“列出全部文件库内容”“监听文件新增”“全天无人值守”这些能力。需要分别确认工具到底能读取什么、写入什么，以及谁负责调用它。
“连接器安装成功！”
“那新稿子来了会自动处理吗？”
“这个……得有人通知。”
这不是全自动快递机器人，而是随时等电话通知上班的快递员。
三、定时任务能否补上这一环？
ChatGPT 的定时任务支持按时间执行；在符合条件的环境中，还能响应某些已连接应用的事件。官方提到的 GitHub 事件示例包括受支持的拉取请求活动。[2]
然而 GitHub 上发生拉取请求，与 ChatGPT 文件库新增一篇稿子是两种事件。还得实际测试任务能否枚举和读取目标文件，能否完成 GitHub 写入，是否会因审批而暂停。官方也说明，在项目中创建的任务无法访问该项目上传或保存的文件。[2]
因此，“每天扫描未转存草稿”值得测试，却不能仅凭设置了定时任务就宣称完全自动化。
四、真正无人值守：先选对原稿存放处
如果目标是持续自动同步，可以把最终 Markdown 放在具备正式 API 或变更通知的存储服务中。
完成草稿 → 保存到可授权访问的存储位置 → 定时检查或接收事件 → 只把差异写入 GitHub → 再读取并校验
GitHub Actions 支持定时运行工作流。[4] 但 GitHub 的定时器不会自动获得读取另一个平台文件的权限。身份验证、使用额度、密钥保护以及项目既有的执行限制，都必须单独处理。如果仓库禁止新建 Actions 工作流，就沿用已获批准的执行环境。
少量文件直接在聊天里批量转存通常更省事。稿子长期大量产生时，先设计变更检测才更稳定。
五、比传输失败更糟糕的是“以为传成功了”
假设一份 Markdown 包含 12 个语言版本，上传显示成功，实际只保存了前六种语言。
机器人自豪地说：“已签收！”
打开箱子一看，后半截空气倒是装得挺满。
安全的同步需要：用稳定的原稿标识和内容哈希防止重复提交；将新建与更新分开，并检测冲突；从 GitHub 重新读取完整文件，比较全文、语言数量和哈希；把“草稿完成”“仓库已保存”“网站已发布”作为不同状态记录。
删除源文件必须放在最后，而且只删除已经核对过完整内容与正确目标路径的文件。 模糊、失败、冲突的原稿保留以便重试。
自动化能放大效率，也能放大误删。清理机器人如果未经核验就把十篇原稿扫进垃圾桶，那职位应该改成拆迁队。
结论：缺的不是第二辆叉车
想先搬运现有文件，就在能访问两端的聊天环境里批量传送并核对。想定期处理，先拿少量文件验证任务权限。想完全无人值守，则优先建立可检测变化的源存储和稳定执行环境。
真正的问题是：谁在何时发出开始传输的信号？
发现、读取、提交、核对，四步闭环才叫同步。
先装门铃，再买叉车。十台机器人一起盯着仓库门，也不会让货物自己出发。
参考资料（4条）
- OpenAI, File storage and Library in ChatGPT: https://help.openai.com/en/articles/20001052-file-storage-and-library-in-chatgpt
- OpenAI, Scheduled tasks in ChatGPT: https://help.openai.com/en/articles/10291617-scheduled-tasks-in-chatgpt
- GitHub, REST API endpoints for repository contents: https://docs.github.com/en/rest/repos/contents
- GitHub, Events that trigger workflows: https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
