- 你正在用 AI 构建工具开发新应用，或新增一项主要功能。
- 你能说出一位遇到该问题的人，即使还没和对方聊过。
- 你希望阻止构建工具添加没人要求的功能。
- 你想要一份清单来评判每次构建，而不是到处点点看。
使用场景中文
资格边界
当构建工具一直在猜时，就该用 PRD 了。
一行提示词足以做出演示。一旦你希望别人使用这个应用，构建工具每次修改代码时都需要同样的几项决策。
- 你需要一份经利益相关方签字确认的完整企业级需求文档。
- 你想要一个不需要你做决策就能写出 PRD 的生成器。
- 你期望 PRD 能证明人们想要这个应用；只有真实的人才能证明这一点。
- 你需要安全审查、合规签字或生产就绪认证。
最小完整工作流程
一页纸上的六项决策，然后一次构建一部分。
在一个普通的 Markdown 文件中填写下方模板。每一步都会消除一项构建工具原本需要猜测的内容。
- 01
写明第一位用户和触发时机
写出一个具体的人，以及他们需要这个应用的时刻：「共用一个冰箱的室友，在有人刚为一次采购付完钱之后。」如果你说不出一个人，先和人们聊聊，再开始构建。
- 02
写一项任务和最多三项必备功能
用一句话说明任务，然后列出完成该任务所需的最多三项必备行为。其他一切都放到以后。三项是上限，不是目标。
- 03
明确列出非目标
写明第一版不能包含的内容，例如账号、付款、通知、管理后台或仪表盘。构建工具往往会默认添加这些；写下的非目标让你有理由拒绝它们。
- 04
用平实的语言描述数据和页面
列出应用需要存储的少数几样东西，以及用户会经过的页面。普通名词就够了：清单、条目、谁付的钱、金额。除非有理由，否则把框架选择交给构建工具。
- 05
为每项必备功能设定检查
写出功能可用时你会看到什么：「在一部手机上添加的条目，刷新后会出现在第二部手机上。」避免使用「快」「直观」「现代」这类无法检查的词。
- 06
放到工具会读取的位置，然后构建一部分
把它粘贴到 Lovable 的 knowledge 文件中，或保存为 PRD.md 并在 CLAUDE.md 或 AGENTS.md 中引用。让构建工具先规划再构建，实现一项必备功能，运行对应检查，并在你改变决策时更新 PRD。
可检查的控制
审批卡片示例：只构建必备功能 1
这是一张示意性的任务卡片，不代表已声称的客户结果或已完成的实验。
- 目标
- 作为虚构的 Splitlist PRD 中的必备功能 1，让两位室友能从各自的手机向同一份共享购物清单添加条目。
- 行动
- 在所提供的项目中实现必备功能 1。返回修改内容和每项验收检查的结果，供审阅。
- 对象
- 一个项目及其代码仓库。不涉及登录服务、付款、通知或另外两项必备功能。
- 验收标准
- 在手机 A 上添加的条目，刷新后会出现在手机 B 上；空条目会被拒绝；清单在 390px 宽的屏幕上无需横向滚动即可完整显示；其他页面没有变化。
- 停止条件
- 如果数据模型需要用户账号（PRD 已将其列为非目标），或某项检查无法在沙箱中运行，则停止。
修改拒绝按确切范围审批
可复制的一页式 PRD
八个标题。一页纸。每一行都可检查。
说明性示例：Splitlist 是一个虚构的共享购物清单应用。请用你自己的决策替换每一行；凡是尚未与真实的人确认的内容，都标记为假设。
- 第一位用户和触发时机
- 共用一个冰箱的室友，在其中一人刚为一次采购付完钱之后。假设：他们已经在通过消息分摊费用。
- 一项任务
- 不用电子表格，也能在每次采购后知道谁欠谁多少钱。
- 必备功能（最多三项）
- 1. 从任意手机向同一份共享清单添加条目。2. 将一次采购标记为由某人付款，并填写总额。3. 显示每个人的累计余额。
- 第 1 版的非目标
- 没有账号或密码（分享私密链接），应用内不支持付款，没有通知，不扫描小票，没有管理后台。
- 数据
- 清单、条目（名称、添加人）、采购（付款人、总额、日期）、成员（显示名称）。余额通过计算得出，不单独存储。
- 页面
- 共享清单；标记为已付款的表单；余额。以移动端为先，宽度 390px。
- 验收检查
- 在一部手机上添加的条目，刷新后会出现在另一部手机上。两位成员之间由 A 支付的一次 $42 采购，显示 B 欠 A $21。空条目和负数总额会被拒绝。
- 首位用户测试
- 两位真实的室友用它完成一次采购。通过标准：两人都能在不问你的情况下说出谁欠谁多少钱。记录让他们困惑的地方。
决策记分卡
根据 PRD 能防止什么、能让你检查什么来评判它。
好的 PRD 简短且可测试。这些信号能告诉你它是否在发挥作用。
一页纸
整份 PRD 能放在一屏或一页内，并写明一位用户和一项任务。
已标记假设
凡是尚未与真实的人确认的内容，都被标记为假设。
检查通过
每项必备功能都有一项你可以亲自执行的检查，且最新构建已通过。
守住范围
非目标清单中的内容没有出现在构建中，或已被你删除。
首位用户完成
一位真实用户在没有你帮助的情况下完成了任务。给自己做的演示不算。
已更新
当你改变一项决策时，PRD 在同一次会话中随之更新。
调研证据格式
各工具从哪里读取你的项目背景
文档核查于 2026 年 10 月 21 日。这些工具经常调整背景相关功能；依赖之前请确认当前位置。
Lovable 的 knowledge 文件始终是 Lovable 工作背景的一部分，文档表示好的 knowledge 文件读起来应像一页式简报，而不是 wiki。对于比小调整更大的改动，推荐使用 Plan 模式。
把一页式 PRD 粘贴到 knowledge 文件中，并在每项必备功能前先做规划。
Lovable 最佳实践Claude Code 会在每次会话开始时加载 CLAUDE.md 或代码仓库中的 AGENTS.md 作为背景，并表示具体、简洁的指令会被更一致地遵循。
保持 PRD 简短，并在 CLAUDE.md 或 AGENTS.md 中引用它，让每次会话都从它开始。
Claude Code 记忆文档Cursor 支持在项目根目录和子目录中使用 AGENTS.md，其规则文档建议引用文件，而不是复制文件内容。
把 PRD.md 保持为一个文件，并在 AGENTS.md 或项目规则中指向它。
Cursor 规则文档Soloop 可以在沙箱中从想法或已有代码开始构建，并维护一份可编辑的 Product Doc，记录产品、目标用户、问题、优势和当前重点。文档中没有说明 PRD 生成器。
可以单独使用这个模板，也可以在审批 Build 任务之前，请 Soloop 在聊天中协助起草。
Soloop 产品手册 · 更新于 2026 年 9 月 24 日当前产品边界
按今天实际能运行的功能来规划。
这是一个模板和一套流程，而不是 PRD 生成器。清晰的 PRD 让构建更容易检查，但不能证明有人想要这个应用。Splitlist 示例是虚构的。
模板
免费把八个标题复制到任意 Markdown 文件中。无需注册。
在聊天中起草
已上线描述你的想法，请 Soloop 质疑你的假设，并起草 PRD 供你审阅。
Product Doc
已上线在 Soloop 可编辑的 Product Doc 中记录产品、目标用户、问题和当前重点。
Build
审批后可用Soloop 可以在沙箱中从想法或所提供的代码开始构建，并返回修改内容和检查结果供审阅。
PRD 生成器
不是现有功能没有一键 PRD 生成器；PRD 中的决策由你做出。
其他构建工具
你自己的项目Soloop 不会编辑 Lovable、Cursor 或 Claude Code 项目；请你自行把 PRD 粘贴进去。
继续这个循环
当决策发生变化时，使用下一个资源。
常见问题
进行下一步之前的问题。
Vibe Coding 的 PRD 应该包含什么？
第一位用户和触发时机、一项任务、最多三项必备行为、非目标、数据、页面、每项必备行为的验收检查，以及一次首位用户测试。这些足以让 AI 构建工具停止猜测，也足以让你评判每次构建。
在 Lovable、Cursor 或 Claude Code 中，PRD 应该放在哪里？
在 Lovable 中，把它粘贴到项目的 knowledge 文件里。在 Claude Code 中，保存为 PRD.md，并在 CLAUDE.md 或 AGENTS.md 中引用。在 Cursor 中，从 AGENTS.md 或项目规则中引用它。由于这些功能经常变化，请查看各工具的当前文档。
Vibe Coding PRD 应该写多长？
一页。Lovable 的文档把好的 knowledge 文件描述为一页式简报，Claude Code 的文档表示简洁的指令会被更一致地遵循。把细节放进验收检查，而不是背景介绍。
Soloop 能写 PRD 并构建应用吗？
Soloop 可以在聊天中协助你起草，把要点保存在它的 Product Doc 中，并在你审批 Build 任务后，在沙箱中从想法开始构建。它没有一键 PRD 生成器，也不会编辑其他构建工具中的项目。
带上你已有的产品
带上你的想法和一位目标用户。
复制这份简报，替换括号内容，在选择「从项目开始」后，将其粘贴到 Soloop 首页。简报不会自动传递。你也可以把完成的 PRD 粘贴到任何其他构建工具中。
我想为［具体的人］开发［应用想法］，他们会在［触发时机］时需要它。请帮我写一份一页式 PRD，包括：第一位用户和触发时机、一项任务、最多三项必备行为、非目标、数据、页面、每项必备行为的验收检查，以及一次首位用户测试。请先向我提出澄清问题，并把我尚未确认的内容标记为假设。在我审批 PRD 之前，不要启动 Build 任务。从一个项目开始