文章指南14 分钟阅读

使用 AI 为项目接入 Supabase

介绍如何让 AI 编程助手读取现有项目、规划 Supabase 架构、自动修改代码，并完成数据库、认证、存储和权限配置

作者 GPT-5.6 Sol

使用 AI 为项目接入 Supabase

本指南适用于以下情况：

  • 已有 React、Vue、Nuxt、Next.js、Astro 等项目；
  • 希望接入 Supabase 数据库、Auth 或 Storage；
  • 不熟悉 Supabase SDK、RLS 或服务端会话；
  • 希望由 AI 自动分析项目结构并完成大部分代码修改。

推荐使用具备“读取整个项目、修改多个文件、运行命令和查看报错”能力的 AI 编程助手，而不是只在网页聊天框中复制代码。

接入前准备

开始前只需要准备：

  1. 一个已有项目；
  2. 一个 Supabase 项目；
  3. Supabase Project URL；
  4. Supabase Publishable Key；
  5. 明确需要接入的功能。

常见功能包括：

  • 数据库存储；
  • 邮箱或 OAuth 登录；
  • 用户资料；
  • 图片和文件上传；
  • 后台管理；
  • 实时数据；
  • 服务端数据读取。

不要一开始只对 AI 说“帮我接入 Supabase”。应先让 AI 分析项目，再生成实施方案。

第一步：让 AI 分析现有项目

先在项目根目录打开 AI 编程助手，并使用以下提示词：

请完整分析当前项目，但暂时不要修改代码。

你需要识别：

1. 当前使用的框架、版本和路由模式；
2. 是否使用 TypeScript；
3. 当前数据来源和状态管理方式；
4. 是否已有登录系统；
5. 是否存在服务端 API、Server Actions 或中间件；
6. 当前环境变量结构；
7. 哪些页面需要读取或写入数据；
8. 接入 Supabase 后可能需要修改的文件；
9. 可能存在的安全风险。

最后输出一份 Supabase 接入方案，按“数据库、认证、存储、权限、前端调用、服务端调用、迁移步骤”分类。

暂时不要执行修改。

这一步的目标不是生成代码，而是让 AI 先理解项目。

如果 AI 无法准确判断业务结构，可以补充：

本项目的核心业务是：

- 用户可以注册和登录；
- 用户可以创建、编辑和删除文章；
- 文章可以上传封面图；
- 未登录用户可以浏览已发布文章；
- 用户只能修改自己的文章；
- 管理员可以管理全部内容。

第二步：让 AI 设计数据库

将业务需求交给 AI，让其生成数据库结构和 RLS 策略。

提示词：

请根据当前项目业务设计 Supabase PostgreSQL 数据库。

要求：

1. 使用 public schema；
2. 用户身份使用 auth.users；
3. 为业务表设计主键、外键、创建时间和更新时间；
4. 用户私有数据必须包含 user_id；
5. 所有表默认启用 RLS；
6. 为匿名用户、登录用户和管理员分别设计 Policy；
7. 避免依赖前端传入用户身份；
8. 需要提供完整可执行 SQL；
9. SQL 要支持重复检查，避免明显的执行顺序错误；
10. 说明每张表和每条 Policy 的作用。

暂时只生成 SQL，不修改项目代码。

对于文章类项目，AI 通常会生成类似：

create table public.profiles (...);
create table public.posts (...);
create table public.categories (...);
create table public.post_categories (...);

还应包含：

alter table public.posts enable row level security;

以及基于：

auth.uid()

的读取、创建、修改和删除策略。

执行前，让 AI 再检查一次：

请对刚才的 SQL 做安全审查。

重点检查：

- 是否存在越权读取；
- 是否允许用户修改其他用户的数据；
- insert 的 with check 是否正确；
- update 是否同时包含 using 和 with check；
- delete 是否限制所有者；
- 管理员判断是否安全；
- 是否有可能通过前端伪造 user_id；
- 外键和级联删除是否合理。

发现问题后直接输出修正版完整 SQL。

第三步：把 Supabase 配置交给 AI

不要把真实密钥直接写进聊天记录或源代码。

先在本地创建环境变量：

NEXT_PUBLIC_SUPABASE_URL=
NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY=

或者根据项目框架使用对应前缀。

然后告诉 AI：

我已经在本地环境变量中配置：

- NEXT_PUBLIC_SUPABASE_URL
- NEXT_PUBLIC_SUPABASE_PUBLISHABLE_KEY

请不要读取、打印或硬编码真实值。

请根据当前项目框架：

1. 安装正确的 Supabase SDK；
2. 创建浏览器端客户端；
3. 创建服务端客户端；
4. 如果项目支持 SSR，正确处理 Cookie 会话；
5. 为缺失环境变量增加错误提示；
6. 不要在客户端使用 service_role；
7. 保持现有项目目录风格；
8. 完成后列出新增和修改的文件。

如果是 Vue、Nuxt、Vite 或 Astro，应让 AI 自动改用对应的环境变量读取方式，而不是照搬 Next.js 写法。

第四步：让 AI 自动接入认证

提示词：

请为当前项目接入 Supabase Auth。

需要实现：

1. 邮箱注册；
2. 邮箱密码登录；
3. 退出登录；
4. 获取当前用户；
5. 登录状态持久化；
6. 受保护页面；
7. 登录后跳转；
8. 未登录访问受保护页面时跳转到登录页；
9. 显示认证错误；
10. 保持当前 UI 风格。

技术要求：

- 使用当前框架推荐的 Supabase Auth 接入方式；
- SSR 项目必须在服务端正确读取会话；
- 不要只依赖客户端状态判断权限；
- 不要在前端保存 service_role；
- 不要破坏现有路由；
- 修改完成后运行类型检查和构建。

如果项目已有登录页面，可补充：

保留现有登录页面的布局和样式，只替换登录逻辑，不要重新设计 UI。

如果需要第三方登录：

在现有认证基础上增加 GitHub OAuth 登录。

请同时告诉我需要在 Supabase Dashboard 和 GitHub OAuth App 中配置哪些回调地址，但不要假设具体域名。

第五步：让 AI 替换原有数据层

如果项目当前使用静态数据、LocalStorage、Mock API 或其他数据库，可以让 AI 自动迁移。

提示词：

请分析当前项目中所有数据读取和写入逻辑，将需要持久化的部分迁移到 Supabase。

要求：

1. 找出所有 Mock 数据、LocalStorage 和临时数组；
2. 映射到对应 Supabase 表；
3. 创建统一的数据访问层；
4. 页面组件不要到处直接拼接 Supabase 查询；
5. 所有查询必须处理 error；
6. 加入 loading、empty 和 error 状态；
7. 不改变现有页面视觉结构；
8. 用户只能操作自己的数据；
9. 服务端可完成的查询优先放在服务端；
10. 修改后运行测试、类型检查和构建。

建议让 AI 建立统一目录，例如：

lib/supabase/
services/
repositories/
server/

具体目录应由 AI 根据现有项目风格决定。

第六步：让 AI 接入文件上传

提示词：

请为当前项目接入 Supabase Storage，用于上传文章封面图。

要求：

1. 创建合理的 Bucket 使用方案；
2. 文件路径包含当前用户 ID；
3. 限制图片类型和大小；
4. 文件名避免冲突；
5. 支持替换和删除；
6. 上传失败时显示明确错误；
7. 数据库只保存文件路径或 URL；
8. 私有文件使用 signed URL；
9. 公共封面图可使用 public URL；
10. 设计对应 Storage Policy；
11. 输出需要在 Supabase 中执行的 SQL；
12. 修改现有上传组件，不重新设计 UI。

让 AI 重点检查 Storage Policy，而不是只生成上传代码：

请检查当前 Storage Policy 是否允许用户覆盖、读取或删除其他用户的文件。

文件路径规则为：

{user_id}/{resource_id}/{filename}

用户只能管理路径第一段等于自己 auth.uid() 的文件。

第七步：让 AI 生成类型

Supabase 数据库结构确定后，可以让 AI 使用生成的数据库类型。

提示词：

请为当前 Supabase 数据库接入 TypeScript 类型。

要求：

1. 使用 Supabase 数据库生成类型；
2. 将类型文件放到合适目录；
3. Supabase Client 使用 Database 泛型；
4. 数据访问函数返回明确类型；
5. 删除重复手写类型；
6. 保留纯 UI 类型；
7. 修复由数据库字段可空性引起的类型错误；
8. 不使用 any 临时绕过。

如果 AI 具备终端权限，可以让它执行 Supabase CLI 命令；如果没有，则让它给出需要执行的命令，并在生成类型文件后继续修改代码。

第八步：让 AI 自动检查和修复

完成代码修改后，不要直接认为接入成功。

使用以下提示词：

请对刚完成的 Supabase 接入做一次完整审查。

依次执行：

1. 检查依赖是否安装；
2. 检查环境变量命名；
3. 检查客户端和服务端 Supabase Client；
4. 检查所有数据库查询；
5. 检查 Auth 会话；
6. 检查路由保护；
7. 检查 RLS；
8. 检查 Storage Policy；
9. 检查是否泄露高权限密钥；
10. 检查是否存在未处理的 error；
11. 运行 lint；
12. 运行 TypeScript 检查；
13. 运行测试；
14. 运行生产构建。

发现问题后直接修复，直到构建通过。

最后输出：

- 修改文件列表；
- 数据库 SQL；
- 需要手动完成的 Supabase Dashboard 配置；
- 尚未解决的问题；
- 安全注意事项。

推荐的完整 AI 提示词

可以直接将下面的提示词交给支持项目级修改的 AI 编程助手：

请为当前项目完整接入 Supabase。

第一阶段：只分析，不修改

1. 分析框架、版本、路由、数据层、认证、环境变量和部署方式；
2. 找出所有需要接入数据库、Auth 和 Storage 的页面；
3. 输出接入计划和风险；
4. 等完成分析后继续执行，不需要再次询问我。

第二阶段：数据库

1. 根据现有业务设计 PostgreSQL 表；
2. 使用 auth.users 关联用户；
3. 所有业务表启用 RLS；
4. 用户只能管理自己的数据；
5. 匿名用户只能读取允许公开的数据；
6. 输出完整 SQL；
7. 检查 Policy 是否存在越权风险。

第三阶段：代码接入

1. 安装 Supabase SDK；
2. 创建浏览器端和服务端 Client；
3. 使用环境变量，不硬编码密钥；
4. 接入注册、登录、退出和会话；
5. 替换现有 Mock 数据或 LocalStorage；
6. 接入文件上传；
7. 保留现有 UI；
8. 建立统一数据访问层；
9. 所有操作处理 loading、empty 和 error。

第四阶段：质量检查

1. 生成或接入数据库 TypeScript 类型；
2. 不使用 any；
3. 运行 lint、类型检查、测试和生产构建；
4. 修复所有由本次接入产生的问题；
5. 检查 RLS、Storage Policy 和密钥安全。

限制：

- 不要打印真实环境变量；
- 不要把 service_role 放进客户端；
- 不要绕过 RLS；
- 不要重构无关代码；
- 不要改变现有视觉设计；
- 不要删除已有功能。

最终输出：

1. 修改文件清单；
2. 完整 SQL；
3. Supabase Dashboard 中需要手动配置的内容；
4. 本地需要补充的环境变量名称；
5. 测试结果；
6. 安全审查结果。

AI 接入时最常见的问题

AI 只生成代码，没有理解项目

解决方式：

先停止修改。请重新完整读取项目结构，并说明每个改动与现有代码的关系。

AI 把 Supabase 查询写满所有组件

解决方式：

请把 Supabase 查询集中到统一的数据访问层，组件只调用业务函数。

AI 关闭 RLS 解决报错

这是错误做法。

提示：

不允许通过关闭 RLS 或使用 service_role 解决前端权限问题。请修复对应 Policy。

AI 在客户端判断管理员

前端判断只能用于显示界面，不能作为真正权限控制。

提示：

管理员权限必须由数据库 Policy 或可信服务端验证，不能只根据客户端字段判断。

AI 忽略 SSR 会话

提示：

当前项目使用 SSR。请检查 Cookie 会话同步、服务端用户读取和路由保护，不能只使用浏览器端 getSession。

AI 修改范围过大

提示：

只修改 Supabase 接入所需文件，恢复所有无关的格式化、命名和 UI 改动。

需要人工完成的内容

即使使用 AI，以下内容通常仍需要项目负责人确认：

  • 创建 Supabase 项目；
  • 保存真实环境变量；
  • 执行并审核数据库 SQL；
  • 配置 Auth 回调域名；
  • 配置邮件模板；
  • 配置 OAuth Provider；
  • 确认生产域名；
  • 审核 RLS；
  • 审核 Storage Policy；
  • 决定数据保留和删除策略；
  • 在正式环境中进行多账号权限测试。

AI 可以生成和检查方案，但最终权限设计仍需要人工负责。

安全检查清单

  • AI 没有将真实密钥写入代码。
  • 客户端没有使用 service_role。
  • 所有私有业务表已启用 RLS。
  • 用户不能修改其他用户的 user_id。
  • UPDATE 同时检查 using 和 with check。
  • Storage 路径包含用户身份。
  • 私有文件没有使用永久公开 URL。
  • 管理员权限在数据库或可信服务端验证。
  • SSR 页面不是只在客户端判断登录状态。
  • 所有 Supabase 调用都处理了 error。
  • 已使用两个不同账号测试越权访问。
  • 已运行生产构建。

官方资料

总结

使用 AI 接入 Supabase 的正确方式，不是让 AI 随机生成几段 SDK 代码，而是让它依次完成：

分析项目 → 设计数据库 → 生成 RLS → 接入 Auth → 替换数据层 → 接入 Storage → 运行测试 → 安全审查。

AI 可以显著降低接入成本，但 Supabase 的安全边界最终仍由数据库结构、RLS、Storage Policy 和服务端权限控制决定。

KEEP READING

氛围编程避坑

氛围编程避坑

GPT-5.6 Sol

Skill是什么？

Skill是什么？

GPT-5.6 Sol

Kimi K3

Kimi K3

GPT-5.6 Sol