零、总结-写在前面

这篇文章《AI 时代的敏捷开发：AI + Rapid》（AI-Rapid）主要探讨了在人工智能技术爆发的背景下，如何通过 AI 赋能传统的“敏捷开发”模式，以实现更高效、更智能的软件交付。

  • 2022年：只能补全单行代码
  • 2023年：可以生成完整代码片段
  • 2024年：可跨多个文件工作，构建简单应用
  • 2025年：能够创建并重构整个代码库

快捷开发结果

快捷开发

快捷开发周期

任务* 工具 输出 用时
需求 Manus 负责需求分析、竞品调研、技术选型方案对比、编写技术文档或 PRD。 2
原型 v0 与v0对话，生成前端原型。 2
存储 Supabase 生成Table和Function，完成RLS权限配置，所有的数据操作只能在后端通过SUPABASE_SERVICE_ROLE_KEY进行。 2
开发 Cursor 因为是全新项目，先定义完整提示词进行一次全量构建。然后新增功能，并逐个功能微调。 8
发布 Vercel https://rapid-recruit.vercel.app/ 1

  • 15个小时可以完成一个具备基本功能的招聘网站从需求上线：

    • 有考虑全球化支持问题

    • 有考虑未来服务的水平扩展问题

    • 有考虑未来存储优化和多种存储问题

  • StartUp公司在AI支持下做MVP或者产品的初期中期阶段是可行的

    • 初期选择快速开发框架时，考虑后期的扩展
      • 目标就是千万级，先快速验证业务：以下先都不要考虑
      • 全局唯一ID和分片键
      • 不用function、存储过程、view、trigger
    • 业务发展期：
      • 引入缓存、搜索框架、消息队列，支持千万级用户规模
    • 业务爆发期：
      • 系统重构，国内一线大厂的架构。

  • 已经颇具规模和用户体量：

    • 使用当前国内一二线大厂的成熟架构

    • AI作为辅助，用来优化代码，查找问题，提出建议等。

一、AI高效生产力工作流

^_^ 人类 ^_^ **拥有 AI 无法替代的核心资产：架构洞察力、对业务逻辑的深度理解以及对代码质量的“嗅觉”**。

在 2026 年的开发环境下，Manus、Cursor 和 v0 不仅仅是工具，它们分别代表了决策助手、执行终端和 UI/原型引擎。将它们结合起来，你可以从“码农”转变为“技术导演”。

以下是为你量身定制的高效生产力工作流：

1. 角色分工：构建你的 AI 智囊团

要提高生产力，首先要明确这三个工具在你的工作流中扮演的角色：

工具 核心角色 你的操作点
Manus 通用任务 Agent & 调研员 负责需求分析、竞品调研、技术选型方案对比、编写技术文档或 PRD。
v0.dev 前端原型 & UI 生成器 负责快速生成高质量、响应式的 React/Next.js 组件代码，解决“冷启动”问题。
Cursor 主力开发环境 (IDE) 负责核心逻辑编写、存量代码重构、全库上下文关联调试。

2. 黄金组合工作流：从想法到上线

第一阶段：需求起航（Manus）

不要直接写代码。先让 Manus 帮你梳理逻辑。

  • 场景：你需要开发一个复杂的仪表盘系统。
  • 指令：向 Manus 描述业务目标，让它生成技术架构图、数据库 Schema 建议以及API 接口规范。
  • 价值：利用 Manus 强大的 Agent 能力处理脏活累活（如查阅最新的第三方库文档），你负责审核它的设计是否符合架构原则。

第二阶段：视觉与交互快跑（v0）

有了功能列表后，将 UI 需求交给 v0。

  • 场景：需要一个带图表和多重过滤器的 Dashboard。
  • 操作：在 v0 中输入要求，或者直接上传一份手绘草图。v0 会生成基于 Tailwind CSS 和 shadcn/ui 的代码。
  • 价值：省去了你从零调试 CSS 和组件排版的时间，直接拿到“像素级”还原的生产级代码。

第三阶段：核心逻辑集成（Cursor）

最后，将 v0 生成的代码和 Manus 设计的逻辑在 Cursor 中落地。

  • 操作：
    1. 使用 Cursor Agent Mode (@Codebase) 让它理解你现有的项目结构。
    2. 将 v0 的代码粘贴进来，用 Cmd+K 指令：“按项目规范重构此组件，并接入 useSWR 进行数据请求”。
    3. 使用 Composer 功能，一次性修改多个文件（如 Action, Store, Component）。
  • 价值：这是你发挥资深经验的主战场。你通过 AI 快速铺量，然后重点检查并发处理、内存泄漏或安全性问题。

3. 3 条进阶建议

1. 从“手写代码”转向“Spec-Driven（规格驱动）”

资深工程师最强的是定义问题的能力。在 Cursor 或 Manus 中，先写好 .cursorrules 或技术规格文件（Spec）。AI 越像初级开发，你越要像一个好的技术 Leader，提供清晰的约束。

2. 利用 MCP (Model Context Protocol) 扩展边界

2026 年，Cursor 广泛支持 MCP 协议。你可以配置 MCP Server 让 Cursor 直接读取你的数据库 Schema、查看 GitHub Issues 甚至连接 Jira。这让你无需切换窗口，就能在 IDE 里完成全链路开发。

3. 把 AI 当作“代码评审员”

不要只让 AI 写代码，还要让它 review 你的代码。

  • 提示词：“作为一名资深架构师，分析这段代码的潜在性能瓶颈，并检查是否符合 SOLID 原则。”

    这能帮你从不同的维度审视代码，避免因工作忙碌导致的低级疏忽。

二、Cursor

在初创公司中，速度和准确性是生存的关键。使用 Cursor 进行“快捷开发”不仅仅是让 AI 写代码，更是一套从“想法”到“上线”的工程化流程。

以下是初创公司利用 Cursor 实现极速开发的具体步骤：

1. 环境与上下文准备 (Setting the Context)

AI 表现的好坏取决于你给它的“信息质量”。

  1. 编写 instruction.md (需求文档)：

    不要直接开始对话。先在根目录创建一个 Markdown 文件，写明：

    • 核心功能：APP 要解决什么问题？
    • 技术栈：如 Next.js 15, Tailwind CSS, Supabase, Prisma。
    • 代码规范：如“优先使用 Server Components”、“变量名遵循 camelCase”。

  2. 配置 .cursorrules (全局规则)：

    在项目根目录创建此文件。这是 Cursor 的“灵魂”，它定义了 AI 每次生成代码时必须遵守的底线。

    [!TIP]

    示例规则：禁止使用过时的库、强制要求 TypeScript 类型检查、要求代码简洁且无占位符（No placeholders）。

  3. 添加外部文档 (@Docs)：

    如果使用了较新的技术（如刚刚发布的某个 API），在 Settings > Features > Docs 中添加其官方文档链接。这样 AI 就能基于最新版而非 2023 年之前的旧数据写代码。

2. 脚手架与架构设计 (Architecture & Scaffolding)

不要让 AI 一次性写完整套系统，要由大到小。

  1. 利用 Composer (Cmd+I) 构建大框架：

    打开 Composer（Agent 模式），输入：“基于 instruction.md，帮我初始化项目结构，包括文件夹命名、核心依赖安装，以及基础的数据库 Schema。”

  2. 设计数据库模型：

    在 Chat 框中使用 @Codebase 询问：“根据目前的需求，设计 Prisma 模型。请确保考虑了多租户和索引优化。”

  3. 快速 UI 渲染 (V0 + Cursor)：

    初创公司常用的黑科技：先在 V0.dev 生成 UI 代码，然后复制到 Cursor 中，让 AI 进行逻辑填充和接口对接。

3. 模块化迭代开发 (Iterative Development)

这是最核心的“快捷”环节，建议遵循 “Plan -> Execute -> Review” 循环。

  1. 小步快跑：

    将功能拆解。例如：“先实现 Google 登录功能”，完成后再做“用户个人资料页”。

  2. 活用 @ 符号精准锁定：

    • @Files：当你要修改特定文件时。
    • @Web：当你遇到报错，需要搜索最新的解决方案时。
    • @Codebase：当你需要让 AI 理解跨文件的逻辑（如：新加一个字段对全局的影响）时。

  3. 使用 YOLO 模式进行快速调试：

    在设置中开启 YOLO 模式，允许 AI 在 Terminal 中自动运行安装命令或测试脚本，无需你手动点击“允许”，极大提升连贯性。

4. 质量把控与部署 (QA & Deployment)

初创公司容易因为快而产生大量技术债。

  1. AI 驱动的单元测试：

    选中一个组件或函数，按 Cmd+K 输入：“写一个 Vitest 测试案例，覆盖所有的边缘情况。”

  2. 代码审查与重构：

    每完成一个功能，询问：“这段代码有潜在的性能漏洞或安全隐患吗？请帮我重构得更优雅。”

  3. 自动化部署文档：

    让 AI 根据当前项目结构生成 Dockerfile 或 Vercel 部署指南。

5. 初创公司 Cursor 提速表格对照

阶段 传统方式 Cursor 快捷方式 提速比
项目起步 手动配置环境、配置 Lint、写 Boilerplate Composer 一键生成 + .cursorrules 5x
功能开发 查文档、手动敲代码、解决拼写错误 Tab 键补全 + Cmd+K 意图转换 3x
Debug 翻 Stack Overflow、打日志、查类型 @Web 搜索报错 + Chat 分析日志 10x
文档/测试 懒得写，导致后期混乱 Cmd+K 自动生成测试和 README 4x

6. Monorepo（单仓）模式（推荐）

如果你将前端、后端和文档都放在一个大文件夹里管理，这是对 Cursor 最友好的结构，因为 AI 可以轻松跨目录读取上下文。

my-awesome-project/          # 项目根目录
├── docs/                    # 💡 核心：文档中心（AI 的知识库）
│   ├── prd/                 # 产品需求文档
│   ├── api/                 # 接口定义 (Swagger/OpenAPI)
│   ├── sql/                 # 数据库设计/DDL
│   ├── design/              # UI/UX 设计说明
│   └── guides/              # 最佳实践、统一错误码、代码规范
├── frontend/                # 前端源码（React/Vue/Next.js）
│   └── .cursorrules         # 前端专属指令（如：参考 docs/design）
├── backend/                 # 后端源码（Go/Java/Python）
│   └── .cursorrules         # 后端专属指令（如：参考 docs/sql）
└── .cursorrules             # 全局指令（统筹前后端协作）
  • 优点： 在全栈开发时，你可以同时 @docs、@frontend 和 @backend。
  • 适用： 个人开发者或小型敏捷团队，追求极速交付。

三、v0和Cursor

在 v0 + Cursor 的黄金组合中，最推荐的做法是：在 v0 中生成“单个页面”或“核心 UI 模块”，然后在 Cursor 中完成“网站组装”和“逻辑打通”。

1. 为什么不建议在 v0 中直接生成“完整网站”？

虽然 v0 的能力在增强，但它的本质是 UI 生成模型。

  • 上下文丢失： 当你让 v0 生成一个包含 10 个页面的完整项目时，随着对话变长，它可能会忘记之前的 CSS 规范或组件逻辑，导致代码冗余。
  • 路由限制： v0 虽然能模拟路由，但它生成的往往是单文件内的状态切换，而不是标准的 Next.js 项目结构。
  • Cursor 更擅长“全局”： Cursor 拥有整个项目的上下文（Context），它比 v0 更擅长处理跨文件的逻辑、数据库连接和复杂的路由配置。

2. 推荐的协作工作流：v0 (设计) + Cursor (工程)

第一阶段：在 v0 中打磨“视觉稿”

不要让 v0 做逻辑，只让它做看得见的部分。

  1. 按页面拆分： 比如先在 v0 里生成一个极具视觉冲击力的 Landing Page。
  2. 获取代码： 点击 v0 的 Code 按钮，直接复制它生成的 React/Tailwind 代码。
  3. 优势： v0 的审美通常比 Cursor（纯 LLM）要好得多，因为它专门针对 shadcn/ui 和现代网页设计进行了微调。

第二阶段：在 Cursor 中进行“工程化”

将 v0 生成的代码片段丢进 Cursor：

  1. 文件拆分： 在 Cursor 中使用 Cmd + K，让它把 v0 的一大坨代码拆分成标准的 components 和 page.tsx。
  2. 路由构建： 让 Cursor 根据 v0 提供的设计，自动生成 App Router 结构（如 /about, /dashboard）。
  3. 逻辑注入： 在 Cursor 中连接真正的 API、配置身份验证（NextAuth）或连接数据库（Prisma/Supabase）。

3. 协作建议表

任务 推荐工具 理由
整体 UI 风格/配色 v0 可视化反馈快，审美在线。
复杂交互组件 v0 处理动画、拖拽等视觉组件非常专业。
多页面跳转逻辑 Cursor 擅长处理文件夹结构和路由跳转。
API 调用与状态管理 Cursor 能理解整个项目的业务逻辑和环境变量。
SEO 与 元数据配置 Cursor 适合进行细碎的项目配置。

4. 总结建议

你应该把 v0 当作你的“高级前端设计师”，把 Cursor 当作你的“全栈工程师”。

  • 在 v0 中： 专注于一个一个页面的“画稿”，确保每一个页面的 UI 你都满意。
  • 在 Cursor 中： 把这些“画稿”拼凑成一个有灵魂、有逻辑的完整网站。

四、v0 代码集成 Cursor 项目指南

环境准备

  1. v0生成前端，全量拷贝到项目目录

  2. 运行安装命令： 在终端输入以下命令来补全 v0 独有的依赖

    npm install 每次把v0的文件拷贝过来都要执行哦。

  3. 启动开发服务器

    在 Cursor 的终端（Terminal）中，输入以下命令：

    npm run dev
# 或者如果你使用的是 pnpm
pnpm dev

    执行后，终端会显示一个地址（通常是 http://localhost:3000）。按住 Cmd (Mac) 或 Ctrl (Win) 并点击该链接，就能在浏览器看到效果了。

  4. 安装 Supabase SDK（在终端运行）：

    npm install @supabase/supabase-js

  5. .env.local

你需要从 Supabase 控制台（Project Settings -> API）获取以下两个核心参数，并严格按照这个格式写入项目根目录下的 .env.local 文件：

# 你的 Supabase 项目 URL
NEXT_PUBLIC_SUPABASE_URL=https://your-project-id.supabase.co

# 你的 Supabase 匿名 Key (Anon Key)
NEXT_PUBLIC_SUPABASE_ANON_KEY=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

为什么要有 NEXT_PUBLIC_ 前缀？

  • 在 Next.js 中，只有以 NEXT_PUBLIC_ 开头的变量才能在浏览器端（前端）被访问。
  • 如果你打算在前端直接调用 Supabase 获取数据，这两个前缀必须保留。

五、Cursor开始工作

🚀 Cursor 全量动态化构建提示词

任务目标：根据 docs/ 目录下的设计文档，将根目录下的静态 v0 页面全量转化为与 Supabase 联动的动态全栈网站。

第一步：环境与文档读取

  1. 请深度阅读 docs/DATABASE_DESIGN.md 和 docs/database/schema.ts，理解数据库表结构和字段定义。
  2. 确认根目录下 .env.local 中的 Supabase 环境变量已就绪。

第二步：后端基础设施建立

  1. 在 lib/supabase.ts 中初始化 Supabase 客户端（使用 NEXT_PUBLIC_ 变量）。
  2. 参考 .cursorrules 的规范，在 server/queries/ 目录下创建数据读取逻辑（如获取职位列表、获取人才信息）。
  3. 在 server/actions/ 目录下创建数据写入逻辑（如用户注册、投递简历、发布职位），使用 Next.js Server Actions 实现。

第三步：前端页面动态化（关键）

  1. 首页与列表页：修改 app/page.tsx 及相关列表组件，将静态 Hardcoded 的假数据替换为从 Supabase 实时抓取的真实数据。
  2. 表单联调：找到所有的 Form 或 Button 提交处，连接到对应的 Server Actions，并添加加载状态（Loading）和成功/失败的 Toast 提示。
  3. 详情页构建：如果 v0 只有列表，请根据文档自动生成动态详情页（如 /jobs/[id]）。

第四步：安全与规范

  1. 严格遵守“前后端分离”原则：数据库直接操作逻辑必须放在 server/ 文件夹。
  2. 检查所有 Import 路径，确保搬运过来的 v0 组件能正确引用 lib/ 里的工具。
  3. 确保所有新生成的代码符合 docs/SECURITY_BEST_PRACTICES.md 中的安全规范。

执行要求：请一次性扫描整个项目，先列出你的执行计划，经我确认后开始批量修改。

💡 在让 Cursor 执行前，给你几个小贴士：

  1. 打开文件：在输入提示词前，建议你在 Cursor 里先点开 docs/DATABASE_DESIGN.md，这样 AI 会更优先关注这个文件的内容。
  2. 分步确认：Cursor 可能会一次性修改几十个文件。如果它列出的计划里有你不确定的地方，你可以说：“先只做首页的动态化，成功后再做表单提交。”
  3. 检查 components.json：因为 v0 用了很多 shadcn 组件，如果 Cursor 报错说找不到组件，让它运行 npx shadcn-ui@latest add [组件名]。

现在，你可以按下 Cmd + I 开启你的全量构建了。完成后，运行 npm run dev 看看你的数据库数据是不是已经出现在页面上了！

🚀基于后端中转（Service Role）修复连接超时

请直接给 Cursor 下达这个修正后的指令，它会帮你把“后端中转”逻辑做扎实：

任务：基于后端中转（Service Role）修复连接超时

要求：

  1. 后端客户端初始化：在 lib/supabase-admin.ts (新建) 中，使用 NEXT_PUBLIC_SUPABASE_URL 和 SUPABASE_SERVICE_ROLE_KEY 创建一个服务端专用的客户端。
    • 注意：确保这个文件里没有 NEXT_PUBLIC 前缀引用 Service Role Key。
  2. 重构 Server 逻辑：
    • 修改 server/queries/ 和 server/actions/ 中的所有函数。
    • 彻底弃用 DATABASE_URL、drizzle 或 postgres 的直连方式。
    • 统一调用 lib/supabase-admin.ts 中的高权限客户端，使用 .from('table').select() 语法。
  3. 安全性检查：
    • 确保 SUPABASE_SERVICE_ROLE_KEY 永远不会出现在任何标记为 'use client' 的组件中。
    • 所有的数据库操作必须封装在标记为 'use server' 的函数或 Server Components 中。
  4. 连接验证：
    • 在 server/queries/ 中写一个 testAdminConnection 函数，尝试读取 jobs 表的总数。
    • 在控制台打印结果，验证通过 HTTPS (API 模式) 是否解决了超时问题。

Service Role Key（高权限 API）对比端口直连

这是一个非常深刻的问题。简单来说：解决 5432 端口（直连）不通的问题，和你选择用 Service Role Key（高权限 API），其实是两个层面的事情，但结合起来确实是目前的“最优解”。

我们要区分 “连接通道” 和 “访问权限”：

1. 为什么“放弃 5432 走 API”是更好的选择？（连接通道层面）

如果你非要修好 5432 端口直连，你会面临以下痛苦：

  • 网络环境极其脆弱：今天你的 VPN 代理了 TCP 流量能连上，明天换个网络环境或 VPN 节点可能就断了。
  • 部署环境限制：即使你本地修好了，很多 Serverless 部署平台（如 Vercel）对原生 PostgreSQL 连接数有限制，容易产生连接溢出。
  • 开发体验差：每次启动都要配置复杂的系统级代理。

结论：改走 HTTPS API (443端口) 是实战派的选择，因为它极度稳定且符合现代 Serverless 开发趋势。

2. 为什么“使用 Service Role Key”是更好的选择？（访问权限层面）

这正是你架构的高明之处：

方案 安全性 灵活性 复杂度
前端用 Anon Key 低（依赖数据库 RLS 策略） 差（只能做基础增删改） 简单
后端用 Service Role 极高（Key 隐藏在服务器） 极强（可以做任何逻辑） 中等

结论：

  • 如果你只用 Anon Key，你得在 Supabase 后台写复杂的 SQL 策略（RLS）。
  • 你选择 Service Role Key + 后端中转，意味着你可以把权限逻辑写在 Next.js 的代码里（比如：if (user.isAdmin) { ... }）。这对开发者来说更直观、更好维护。

3. 最终结论：你的方案是“降维打击”

你现在的方案（后端 + Service Role + API 模式）实际上是：

  1. 用 API 模式 绕过了 5432 端口的网络封锁。
  2. 用 Service Role 绕过了 RLS 的配置麻烦。
  3. 用 后端中转 保证了核心密钥的安全。

六、Supabase 数据库优化百万级数据

这是一个非常经典的思想冲突。在大厂（阿里、腾讯、字节等）的规范中，“禁止存储过程/触发器”几乎是铁律，主要原因是：

  1. 扩展性差：代码逻辑消耗数据库 CPU，而数据库是最难扩容的（IO 密集型）。
  2. 版本控制难：SQL 代码不像 Java/Go 代码可以方便地进行 Code Review、CI/CD 和回滚。
  3. 调试痛苦：PL/pgSQL 的单步调试非常反人类。

但是，为什么 Supabase（以及像 PostgREST 这种现代架构）反其道而行之？

1. 架构哲学的本质转变：BaaS vs. 微服务

大厂的架构是“微服务 + 应用层”，而 Supabase 属于 BaaS (Backend as a Service)。

  • 大厂模式（Fat Backend）：数据库只作为“哑存储（Dumb Storage）”。复杂的权限、校验、逻辑全部写在 Java 层。
  • Supabase 模式（Thin Backend）：利用数据库的强大功能。PostgreSQL 已经存在了 30 多年，它的 RLS（行级安全）、Function 和事务其实非常成熟。

2. 为什么在 Supabase 中推荐写 Function？

在 100 万级数据量下，有几个现实问题逼着你把逻辑下沉：

  • 网络延迟（N+1 问题）： 如果你要在 Java 代码里处理 100 万行数据，你必须把数据 fetch 出来。即便分批，网络开销也非常大。在数据库内部，逻辑离数据只有“0 距离”。
  • 原子性与数据一致性： 没有 Java 层的分布式事务管理器，要在 TS 后端保证多个操作的原子性，写在一个 Function 事务里是最稳妥的选择。
  • 性能瓶颈的转移： Supabase 提供的服务器（通常是 AWS/GCP 上的实例）性能很强。对于 100 万行这种中等规模的数据，数据库消耗的那点 CPU 处理业务逻辑，往往比 TS/Node.js 层处理 JSON 序列化的开销还要小。

3. 如何在“大厂规范”和“Supabase 便利”间寻找平衡？

如果你担心以后维护困难，可以采取“混合模式”：

✅ 建议这样做（现代做法）：

  1. 数据密集型逻辑入库：如“批量扣费”、“统计报表聚合”、“带有复杂条件的大规模分页”。这些操作在数据库内完成。
  2. 外部交互逻辑入后端：如“发送邮件”、“调用支付网关”、“生成 PDF”。这些逻辑写在 Supabase Edge Functions (TS) 中。
  3. 使用索引保护：无论逻辑写在哪，确保 Function 内部的 SQL 经过 EXPLAIN ANALYZE 优化，不要让逻辑变成全表扫描。

4. 解决“版本控制”痛点

针对大厂开发者最担心的版本管理问题，Supabase 推荐使用 Supabase CLI。

  • 你可以将所有的 Function 写在本地的 .sql 迁移文件中。
  • 通过 Git 进行版本管理。
  • 使用 supabase db push 部署。
  • 这样，你的 SQL 逻辑就像 Java 代码一样，可以追踪、可以回滚、可以被 Review。

总结：工具是为了业务服务的

大厂严禁业务逻辑入库是为了支撑千万级甚至亿级 DAU 的横向扩展。但如果你的数据量在 100 万到 1000 万 级别，利用好 PostgreSQL 的 Function 反而能让你用极低的人力成本，实现极高性能的系统。

七、Vercel部署

  1. 项目推送GitHub：https://github.com/pumadong/rapid-recruit

  2. Vercel配置Project：https://vercel.com/

    .env/.envlocal定义的环境变量，需要在project中配置：

    • NEXT_PUBLIC_SUPABASE_URL
    • SUPABASE_SERVICE_ROLE_KEY
    • JWT_SECRET

  3. 部署：https://rapid-recruit.vercel.app/