Cursor多Agent实战：50分钟搭建Next.js全栈博客

项目概览

这是一个使用Cursor IDE多Agent协作模式，在50分钟内从零搭建全栈博客的实战案例。技术栈包括Next.js、Tailwind CSS、Clerk（认证）和Supabase（后端数据库），整个过程通过指挥4个AI Agent分阶段完成开发。

Cursor是基于VS Code的AI增强IDE，其多Agent模式允许开发者同时启动多个独立的AI对话实例，每个Agent拥有独立的上下文窗口和任务范围。与传统的单一AI助手对话不同，多Agent模式模拟了真实团队协作场景——每个Agent相当于一个专注特定领域的开发者。这种模式的优势在于避免单一上下文过载导致的AI性能下降，同时允许不同阶段使用不同的提示策略和模型配置。

技术架构与核心流程

功能设计

博客系统包含以下核心功能：

• 首页：获取并展示所有博客文章，支持响应式布局（小屏1列、中屏2列、大屏3列）
• 创建页面：仅登录用户可访问，支持输入标题、内容和图片URL
• 详情页面：通过动态路由/blog/[id]展示单篇文章
• 认证系统：支持Email和Google登录，未登录用户访问受保护页面会自动跳转到登录页

数据库设计

Supabase的posts表结构：id、title、content、author_id（Clerk User ID）、author_name、image_url、created_at、updated_at。通过RLS规则实现权限控制——任何人可读，仅认证用户可创建。

Supabase是Firebase的开源替代方案，基于PostgreSQL构建，提供实时数据库、认证、存储和边缘函数等后端服务。其核心安全机制RLS（Row Level Security，行级安全策略）是PostgreSQL原生特性，允许在数据库层面定义精细的访问控制规则。RLS通过Policy定义谁可以对哪些行执行什么操作，WITH CHECK子句用于验证INSERT/UPDATE操作时新数据是否满足条件。当与第三方认证（如Clerk）集成时，需要通过自定义JWT解析函数从token中提取用户身份信息，确保只有数据所有者才能修改自己的记录。

多Agent协作开发流程

整个开发过程分为四个阶段，每个阶段启动独立的Agent：

Agent 1：Clerk认证配置

使用Clerk官方提供的Prompt，配置用户认证系统和路由保护中间件。关键点是安装Cursor的Clerk插件，获取对应的Skill和MCP Tools，让AI更准确地完成集成。

Clerk是一个面向现代Web应用的身份认证即服务(Authentication-as-a-Service)平台，提供开箱即用的用户注册、登录、会话管理和多因素认证功能。与传统的自建认证系统（如NextAuth）相比，Clerk的核心优势在于其预构建的UI组件和完善的JWT令牌管理。Clerk为每个认证用户生成包含sub（subject）字段的JWT，这个字段即用户唯一标识符，可被下游服务（如Supabase）用于行级权限验证。Cursor的Clerk插件则为AI提供了最新的API文档和集成模式，减少因文档过时导致的代码错误。

Agent 2：数据库与RLS规则

通过SQL语句创建Supabase数据库表并启用RLS。这里遇到了一个典型问题：RLS规则的with check写法不正确，导致创建文章时报invalid input syntax for user id错误。正确写法需要参考Clerk文档中Supabase集成部分，使用JWT的sub字段匹配author_id。

在Clerk与Supabase集成中，JWT注入的工作原理是：Clerk为已认证用户签发包含用户信息的JWT，开发者在创建Supabase Client时通过accessToken参数传入该JWT。Supabase收到请求后，使用预配置的JWT密钥验证token有效性，并通过auth.uid()函数在RLS策略中提取token的sub字段。这形成了一条完整的信任链：Clerk负责身份验证→JWT携带身份信息→Supabase验证JWT并执行权限策略。常见的错误是RLS策略中使用了错误的字段提取方式，或者JWT模板配置不正确导致sub字段缺失。

Agent 3：页面与业务逻辑

创建所有页面组件和Supabase操作函数。所有数据库操作放在lib文件夹下使用use server，Supabase Client的创建需要注入Clerk的auth token，而非使用service key超级权限。

Next.js 13+引入的'use server'指令标记Server Actions，使函数只在服务端执行，客户端无法直接访问其内部逻辑。这对安全性至关重要——数据库连接字符串、API密钥等敏感信息不会暴露给浏览器。在本项目中，所有Supabase操作通过Server Actions执行意味着：Clerk的auth token在服务端获取和注入，数据库查询在服务端完成后仅将结果返回客户端，从根本上避免了前端直接持有数据库超级权限（service_role key）的安全隐患。这种架构模式也是Next.js官方推荐的数据获取最佳实践。

Agent 4：UI优化

使用frontend design和web design guideline两个Skill，优化整体视觉效果，添加渐变色和图标。这些Skill本质上是预定义的系统提示词，包含设计原则、色彩理论和组件布局的最佳实践，帮助AI生成更符合现代审美标准的UI代码。

关键经验总结

系统集成节点必须人工把控

视频中最有价值的观点是：Clerk与Supabase的集成节点需要开发者自己理解清楚，再交给AI执行。作者手动编写了supabase.ts中的Client创建逻辑，从Clerk的auth中获取token注入Supabase Client，这是AI容易出错的关键连接点。

这个观点揭示了当前AI辅助开发的一个根本局限：AI擅长处理单一系统内的逻辑（如编写React组件或SQL查询），但在两个独立系统的边界处——涉及认证流转、数据格式转换、API版本兼容等问题时——往往缺乏最新的集成知识。这些集成点通常文档更新频繁、存在多种实现路径，AI的训练数据可能已经过时。

模型选择策略

在Plan阶段使用最强模型（如Claude Opus/Sonnet），虽然速度较慢但规划质量更高。对于执行阶段的Agent，可以适当降低模型等级以提高响应速度。这种分层策略的逻辑在于：架构规划需要更强的推理能力和全局视野，而具体的代码生成任务相对模式化，较轻量的模型即可胜任，同时节省API调用成本和等待时间。

Context管理技巧

多Agent模式下需要注意Context消耗。当一个Agent的Context过大时，及时关闭并新建Agent继续后续任务，同时将Plan文件保存到项目中供后续Agent参考。Context窗口（即模型能处理的最大token数）是有限资源，当对话历史过长时，模型会丢失早期信息或整体推理质量下降。通过将规划文档持久化为项目文件（如PLAN.md），新Agent可以快速获取项目全貌而无需重复沟通，这本质上是一种"外部记忆"机制。

总结

这个案例展示了Cursor多Agent工作流的实际效果：将一个全栈项目拆分为认证、数据库、业务逻辑、UI四个阶段并行推进。核心经验是——AI擅长执行明确的任务，但系统间的集成逻辑和架构决策仍需开发者主导。这种人机协作模式代表了当前AI辅助开发的最佳实践方向：开发者扮演架构师和项目经理的角色，负责系统设计、集成决策和质量把控；AI Agent则作为高效的执行者，快速完成各模块的具体实现。

核心要点

• 使用Cursor的4个Agent分阶段协作，50分钟完成Next.js+Supabase+Clerk全栈博客
• Clerk与Supabase的集成节点（JWT token注入、RLS规则配置）是AI容易出错的关键点，需人工把控
• Plan阶段使用最强模型确保架构质量，执行阶段可适当降级提速
• 所有Supabase操作使用use server在服务端执行，通过Clerk auth token替代service key实现权限控制