从想法到上线只用 6 小时：这套 AI 工具链工作流，把"像 PM 一样思考"做到极致

本文改编自国外独立开发者 Cam（X 账号 @churnwavecam）的一篇 X 长串。他用这套流程，只花 6 小时就把一个叫 Weft 的想法做成了真正能用的产品，还集成了 ChatGPT 和 Stripe。

>

原文链接：https://threadreaderapp.com/thread/1906047786409153014.html

>

以下为中文改编整理，操作步骤、工具名、提示词和代码保留英文原样，方便你直接对照使用。

核心主题：像 PM 一样行动

Cam 的整套流程只讲一件事：act like a PM——像产品经理一样行动。

他的观察很扎心：现在太多 vibe coder 和独立开发者，拿到 AI 工具就直接开干，结果返工不断、关键细节翻车。其实只要补上产品经理那几个"规定动作"，AI 的产出效率能翻 10 倍，还能避开致命的坑。

下面是他完整公开的 7 步流程，每一步都有明确分工：哪个 AI 工具干什么活、为什么这样安排、以及大多数人踩过的坑。

第 0 步：先看一个真实案例

在讲流程之前，先看 Cam 自己的战绩：

"I took Weft from an idea to a working product integrated with ChatGPT and Stripe in 6 hours with this process."

一个想法，6 小时，变成真正跑起来的产品，支付（Stripe）和 AI 能力（ChatGPT）都接上了。这不是 demo，是能用的东西。这套流程就是为这种结果设计的。

注意他的措辞：working product（能用的产品），不是"跑起来的 demo"。区别在于：用户能注册登录、数据能存下来、钱能收进来。后面你会看到，每一步都是冲着这个标准去的。

第 1 步：想法 → PRD（用 ChatGPT）

You need a product requirements doc.（你需要一份产品需求文档。）

第一步不是写代码，而是用 ChatGPT 把想法变成一份 PRD（产品需求文档）。Cam 特别提到，用推理能力强的模型效果更好（他当时用的是 o3-mini-high，现在你可以用任何推理能力强的模型，比如 o 系列或 Claude 的深度思考模式）。

一份合格的 PRD 至少要包含：

·产品轮廓：这个 App 到底是干什么的（一句话 + 几段展开）；

·用户故事（User Stories）：谁来用、在什么场景下、要完成什么事；

·功能清单：必须有的功能有哪些，优先级怎么排；

·数据库需求：需要存什么数据，表大概长什么样。

Cam 说：This is the heartbeat of the flow.（这是整个流程的心脏。）

为什么？因为 PRD 是后面所有步骤的"上下文地基"。AI 工具最大的问题不是不会写代码，而是不知道你要什么。把需求先想清楚、写下来，后面每一步 AI 都有据可依。

实操：PRD 提示词长什么样

你可以这样开场（英文提示词效果通常更稳定）：

I want to build [你的产品一句话描述]. Help me write a PRD that includes:          1. Product overview and target users          2. User stories in "As a [role], I want [goal], so that [benefit]" format          3. Feature list with Must-have / Nice-to-have priorities          4. Database schema: tables, key fields, and relationships          Ask me clarifying questions before you start writing.

最后一句很关键：先让 AI 反问你。好的 PM 在写 PRD 之前会先问问题——目标用户是谁、第一个版本不做什么、数据量大概多大。让 AI 先提问，你回答完再让它写，PRD 质量会高一个档次。

一个具体例子

假设你想做一个"家庭记账"小应用。PRD 里应该出现这样的用户故事：

As a parent, I want to record an expense in under 10 seconds,          so that I don't give up on tracking after a week.

以及这样的数据表设计：

Table: expenses          - id (uuid, primary key)          - user_id (uuid, foreign key → users.id)          - amount (decimal)          - category (text)          - note (text, optional)          - created_at (timestamp)

把这些写进 PRD，后面 Lovable 建数据库时直接照抄，几乎不用返工。

第 2 步：PRD → UI 原型（用 uxpilot.ai）

拿着 PRD，去 uxpilot.ai 生成 UI 原型图（mockups）。

Cam 对这个工具评价很高，还专门 @ 了它的创始人 Adam Fard。操作很简单：把 PRD 喂进去，让它为每个页面生成设计稿。

这一步的关键动作：

1.在 uxpilot 里反复微调（fine tune），直到界面顺眼；

2.导出到 Figma（export to Figma）。

"Feel your idea come to life through seeing it."（看着想法变成看得见的界面，那种感觉完全不一样。）

走到这一步，你手里已经有了两样东西：一份 PRD + 一套 UI 原型。注意，还没写一行代码，但产品已经"看得见"了——这就是 PM 式的工作方式。

为什么原型要在写代码之前

Cam 没明说，但逻辑很清楚：改一张设计稿的成本是分钟级的，改已经写好的代码是小时级的。很多 vibe coding 翻车现场都是"代码写完了才发现流程别扭"，根子就是跳过了原型这一步。

在原型阶段要确认三件事：

·页面跳转逻辑通不通（用户从 A 到 B 要点几次）；

·核心操作够不够顺（比如记账要在 10 秒内完成，按钮放哪）；

·有没有漏掉 PRD 里的关键页面。

第 3 步：把 PRD + UI 喂给 Lovable，开建

Time to head to @lovable_dev.

把 PRD 和 UI 原型一起交给 Lovable，让它开始搭建。先从基础界面和基础功能起步，让 AI 把脚手架（scaffolding）的重活干完。

给 Lovable 的初始指令可以这样写：

Build the MVP based on the attached PRD and UI mockups.          Start with the basic UI and core functionality only.          Use Supabase for auth and database (we'll configure it next).          Don't build nice-to-have features yet.

Cam 特别强调了一个大多数人都会踩的坑：

"#1 mistake people make = going to Lovable before they have the PRD and UI to work from. You'll get something. But it won't be the best."

（人们犯的头号错误：还没准备好 PRD 和 UI 就直接冲进 Lovable。你确实能得到点东西，但绝对不是最好的版本。）

顺序就是质量。PRD 和 UI 是 Lovable 发挥好的前提，跳过它们等于让 AI 在没有地图的情况下盖楼。

这一步的验收标准

Lovable 第一轮交付后，别急着加功能，先检查：

3.页面长得像不像原型（还原度）；

4.核心流程能不能点通（比如从首页到记账完成）；

5.代码结构清不清晰（后面你要进 Cursor 接着干，结构乱会很痛苦）。

第 4 步：让 Lovable 给你排 roadmap

有意思的一步：别自己规划下一步，让 Lovable 来设计 roadmap。

到这个时候，Lovable 已经吃透了你的 PRD、看过 UI、还亲手搭了基础架构——它对项目的理解，可能比你自己还系统化。直接问它：

Based on the PRD, the UI mockups, and what you've built so far,          give me an ordered roadmap for completing this MVP.          List each step with what it involves and what "done" looks like.

做完这一步，你手里有四样东西：

·PRD

·UI 原型

·基础脚手架

·一份 AI 为你排好的开发路线图（roadmap）

roadmap 的价值在于排序：先做认证还是先做核心功能？支付接在哪一步？这些顺序问题，AI 结合它已知的代码现状能排得比你凭感觉更合理。

第 5 步：认证和数据库，用 Supabase

Auth and database via @supabase.

用户登录、账号管理、数据库——全部走 Supabase。Cam 的原话很干脆：

"Another reason I love Lovable = it's going to tell you to do this next. And it can DO IT FOR YOU."

（我喜欢 Lovable 的另一个原因：它会主动告诉你下一步该做这个，而且它能直接替你做完。）

让 Lovable 帮你把 Supabase 的 auth 接上，挂到账号管理页面上；数据库结构也让它根据 PRD 来设计。你要做的只是确认，而不是从零配置。

这一步为什么独立成章

很多新手会把"登录注册"当成小事往后拖，结果产品快做完了才发现：没有用户体系，之前写的所有"我的数据"页面都得返工。Cam 把 auth 和数据库提前到第 5 步（脚手架刚搭完），就是 PM 思维：先把地基里最难返工的部分浇好。

Supabase 在这里的角色是"后端即服务"：

·auth：邮箱/手机登录、OAuth，一行配置的事；

·database：Postgres，表结构按 PRD 建；

·RLS policies：行级安全策略，保证用户只能看到自己的数据——让 Lovable 帮你生成，别手写。

第 6 步：建一个 /docs 目录，锁死上下文

Very important.（非常重要。）Cam 用了最高级别的强调。

让 Lovable 在项目里创建一个 /docs 目录，把 PRD、roadmap 存进去，再让它基于现有进度生成一份基础项目文档：

Create a /docs directory in the project root.          Save the PRD as docs/PRD.md and the roadmap as docs/ROADMAP.md.          Then generate docs/ARCHITECTURE.md describing the current codebase:          tech stack, folder structure, database schema, and auth flow.

为什么这一步值得单独拎出来？因为 AI 编程最大的隐形杀手是上下文丢失。今天聊的需求，明天 AI 就忘了；换个工具、开个新会话，之前所有的决策都得重讲一遍。

/docs 目录就是你的"上下文保险柜"：所有关键文档沉淀在一个地方，任何时候、任何工具接手，先读 docs 就能对齐。

docs 里建议放这四份

第 7 步：从 GitHub 拉下来，进 Cursor 开干

最后一步：把代码从 GitHub 拉到本地，进 Cursor 大干一场。

这时候 /docs 目录的价值就体现出来了：

"Give Cursor FULL CONTEXT of what you're building, what it needs to help with, and the work Lovable has already done."

（把完整上下文喂给 Cursor：你在做什么、需要它帮什么、Lovable 已经完成了哪些工作。）

在 Cursor 里开工的第一句话可以是：

Read docs/PRD.md, docs/ROADMAP.md and docs/ARCHITECTURE.md first.          Then help me with [具体任务].          The codebase was scaffolded by Lovable; keep the existing structure and conventions.

Cursor 负责的是深度开发和精细打磨——修 bug、加复杂逻辑、优化体验。有了前面沉淀的全部上下文，它不需要你从头解释，直接就能进入状态。

Lovable 和 Cursor 怎么分工

这是整套流程里最容易困惑的点，Cam 的安排其实很清晰：

·Lovable：从 0 到 1，重的是"搭起来"——界面、脚手架、Supabase 接入；

·Cursor：从 1 到 N，重的是"打磨好"——复杂逻辑、性能、边界情况。

一个管广度，一个管深度。中间用 /docs 交接，就像 PM 把需求文档交接给开发团队。

Cam 的总结：缺的不是工具，是 PM 动作

整篇长串的结尾，Cam 把观点收得很紧：

"It feels like too many vibe coders and indie hackers aren't doing the PM motions that can 10X their output and avoid critical mishaps. Act and think like a PM. And let your AI engineering team do the work."

（太多 vibe coder 和独立开发者，跳过了那些能让产出翻 10 倍、避开重大翻车的 PM 动作。像 PM 一样思考和行动，然后让你的"AI 工程团队"去干活。）

这句话值得琢磨：他把 ChatGPT、Lovable、Cursor 这些工具称为 "AI engineering team"（AI 工程团队）——而你，是这个团队的 PM。PM 不亲自写每一行代码，PM 负责把方向、需求、优先级和上下文管好，执行交给团队。

给中文读者的四点落地提示

6.工具都有平替思路：uxpilot、Lovable、Supabase 都是国外工具，核心逻辑是"PRD → 原型 → 搭建 → 数据"，你完全可以用自己顺手的工具链复刻这个顺序，顺序比工具重要。

7.PRD 值得花 30 分钟：第一步别省时间。一份认真的 PRD，后面能省掉数小时的返工，这是全流程 ROI 最高的一步。

8./docs 习惯越早养越好：哪怕你只用一个 AI 编程工具，也建议维护 docs 目录。上下文是你和 AI 协作中最贵的生产资料。

9.6 小时是高手成绩，别较真：Cam 能 6 小时上线是因为他对每个工具都极熟。你第一次跑这套流程，花一个周末做出 MVP，同样是巨大胜利。先把流程跑通，再谈速度。

—— —— ——

*改编自 @churnwavecam 的 X 长串，全文共 7 步。原文：https://threadreaderapp.com/thread/1906047786409153014.html*