ChatGPT 如何连接 GitHub、Vercel 和 Supabase？

ChatGPT 如何连接 GitHub、Vercel 和 Supabase？完整授权与踩坑记录

现在的 ChatGPT 已经不只是用来问问题或写代码了。对于使用 GitHub、Vercel、Supabase 开发网站、SaaS、CRM 或内部工具的人来说，如果把这几个平台直接连接到 ChatGPT，很多原本需要在多个后台之间来回切换的工作，可以直接在一个对话里完成。

我最近给自己的一个 CRM 项目连接了 GitHub、Vercel 和 Supabase。整个过程看起来并不复杂，但实际配置时遇到了一个很典型的问题：

关键结论 界面显示“已连接”，并不代表 ChatGPT 已经真正获得项目访问权限。

 

尤其是 GitHub，这一点非常容易误判。下面记录完整的配置过程，以及几个比较容易踩坑的地方。

为什么要把 GitHub、Vercel 和 Supabase 接入 ChatGPT？

这三个平台基本覆盖了一个现代 Web 项目的核心开发链路：GitHub 负责代码和版本管理，Vercel 负责构建、Preview 和 Production 部署，Supabase 负责 PostgreSQL 数据库、Authentication、RLS、Edge Functions 等后端能力。

如果三者都连接成功，以后遇到“最新代码已经 Push 了，为什么网站还是报错？”这类问题，就可以让 ChatGPT 按 GitHub → Vercel → Supabase 的顺序依次检查。

以前可能需要自己打开三个后台、复制错误日志、切换页面，再把信息发给 AI。连接之后，很多读取和排查过程可以直接完成。

一、连接 GitHub：显示 Connected 还不够

GitHub 是这次最容易出问题的一步。最开始，我在 ChatGPT 中连接了 GitHub。授权完成以后，界面已经显示 Connected，看起来似乎已经配置完成。

但是实际让 ChatGPT 读取当前账号中的 Repository 时，却返回 0 repositories。也就是说：GitHub 账号已经识别出来了，但 ChatGPT 看不到实际代码仓库。

GitHub OAuth 授权和 Repository 权限不是一回事

这次问题的关键就在这里。GitHub 的连接实际上存在两个层级：第一层是 GitHub 账号授权，第二层是 GitHub App 对具体 Repository 的访问权限。

记住这一点 账号授权成功 ≠ 私有仓库已经授权。

 

所以即使 ChatGPT 已经知道当前登录的是哪个 GitHub 用户，也可能仍然无法读取你的私有 Repository。

正确做法：给 ChatGPT Codex Connector 安装仓库权限

重新进行 GitHub 授权后，会进入 GitHub App 的安装页面。这里通常可以选择 All repositories 或 Only select repositories。

如果只是需要 ChatGPT 操作某一个项目，更建议选择 Only select repositories，然后只选择需要访问的仓库。比如我这里选择的是 youran-crm。这样权限范围更小，也更容易管理。

选择完成以后，点击 Install & Authorize。再次返回 ChatGPT 检查，这一次就可以正常读取仓库名称、默认分支、Visibility、Branches、Commits 等信息。这才算 GitHub 真正连接成功。

二、连接 Vercel：建议只授权指定项目

Vercel 的逻辑与 GitHub 类似。在 ChatGPT 里连接 Vercel 后，会进入 Vercel 的 OAuth 授权页面。这里会看到 Access to all current and future projects，以及当前账号下的项目列表。

如果只有一个项目需要让 ChatGPT 管理，没有必要开放整个 Vercel 账号。我这里直接选择了 youran-crm，而没有勾选所有项目权限。

点击 Authorize 完成授权后，就可以让 ChatGPT 直接读取 Vercel 项目。

如何确认 Vercel 真的连接成功？

只看 ChatGPT 中出现 Vercel 插件还不够。真正有效的验证方式是，让 ChatGPT 读取 Vercel Team 和 Project。

我的实际验证中，可以继续读取 Deployment、Build Logs、Runtime Logs、Preview Deployment、Production Deployment 等信息。这意味着 Vercel 已经不是简单的“账号已登录”，而是项目本身已经开放给 ChatGPT。

三、连接 Supabase

Supabase 的连接相对直接。在 ChatGPT 中选择 Supabase 并完成授权后，就可以读取当前账号下的 Supabase Projects。我的项目中同时存在正式环境和开发环境。

连接成功后，ChatGPT 可以继续读取数据库 Tables、Rows、RLS 状态、SQL、Migrations、Logs、Edge Functions、Authentication 相关信息等。

Supabase 最需要注意的是 Production 和 Dev

如果一个项目同时存在正式环境和开发环境，这一点尤其重要。以后如果让 ChatGPT 执行 SQL 或修改 Schema，一定要先明确修改哪个环境。

建议 开发环境先验证，生产环境后执行。涉及 ALTER TABLE、DROP TABLE、Migration、RLS Policy、Function、Trigger 等操作时，不建议直接在 Production 上尝试。

三个平台连接后，实际能做什么？

完成 GitHub、Vercel 和 Supabase 的连接后，ChatGPT 就可以同时看到项目的三个关键层面：代码、部署、数据库。

例如线上出现 500 错误，可以先检查 Vercel Runtime Logs；如果错误来自某个 API Route，再查看 GitHub 对应代码；如果错误与数据库权限有关，再检查 Supabase RLS 或 SQL。原本分散在三个平台的排查流程，就可以变成一个连续的工作流。

实际连接后，我做了一次三端检查

完成连接之后，我让 ChatGPT 对整个 CRM 项目进行了一次只读检查。检查结果显示，GitHub 的 V3 开发分支与 Vercel 最新 Preview Deployment 的 Commit SHA 一致，说明最新开发代码已经正确部署到 Preview。

与此同时，Production 仍然运行稳定分支，而 Supabase 中也保持了正式库与开发库的区分。这类三端一致性检查，对于持续开发中的项目非常实用。

最大的坑：Connected 不代表 Project Access 已完成

这次整个配置过程中，最值得记录的一点就是：插件显示 Connected，不代表项目权限一定正确。

如果 GitHub 已经连接，但 Repository 数量是 0，或者 ChatGPT 能看到 GitHub 用户却无法读取私有仓库，应优先检查 ChatGPT Codex Connector 是否已经 Install 到对应 Repository，而不是反复退出账号重新登录。

Vercel 也类似。如果账号已经授权，但 ChatGPT 无法读取项目，需要进一步确认项目 Scope 是否授权。

是否应该授权所有 Repository 和 Project？

个人项目或小团队开发，更适合遵循最小权限原则：GitHub 只选择需要操作的 Repository；Vercel 只选择需要操作的 Project；Supabase 明确区分 Production 和 Dev。

这样做虽然在第一次配置时多一步，但长期来说更安全。尤其是当 ChatGPT 后续可以执行代码、SQL、部署和数据库操作时，权限范围越明确越好。

连接以后是不是完全不需要自己操作后台？

并不是。连接之后最大的变化是：日常读取、检查、排错和大量开发操作可以直接在 ChatGPT 中完成。但是 Production Deployment、生产数据库 Migration、删除数据、修改 RLS、更改 Authentication 等高影响操作，仍然应该在明确确认后再执行。

所以更准确地说，ChatGPT 可以逐渐变成项目的统一操作入口，但不意味着所有高风险操作都应自动执行。

最后

把 GitHub、Vercel 和 Supabase 接入 ChatGPT 后，最明显的变化不是“AI 写代码更快了”，而是项目上下文终于可以连起来。

GitHub 里是代码，Vercel 里是部署，Supabase 里是数据和后端。以前这三个系统之间的信息需要开发者自己搬运；连接之后，ChatGPT 可以直接帮助检查这三个环节之间是否一致。

对于经常使用 Next.js、Vercel、Supabase、GitHub 进行独立开发的人来说，这种工作方式值得尝试。尤其是当项目逐渐变复杂以后，减少后台之间的切换，本身就能节省不少时间。