写代码前先写文档：AI产品开发的四份关键文档实践

大多数开发者拿到一个产品想法后，第一反应是打开 Cursor 开始写代码。但如果目标是一个可迭代、可维护的完整产品，在打开 Cursor 之前需要准备的东西远比想象中多。这位 YouTube 创作者的做法值得借鉴：在写任何一行代码之前，先让 AI 生成四份文档——AI 架构上下文、系统设计文档、内嵌构建提示的 PRD、以及设计文档。

这四份文档的核心理念只有一条：不要让 AI 猜产品决策。

不让AI猜：产品定义必须在写代码前完成

创作者在视频中反复强调一个原则："I don't let it guess on the product." 这不是一句口号，而是一条贯穿整个流程的硬性约束。

以 "AI 就绪评分"（AI readiness score）这个功能为例。当创作者第一次让 AI 处理这个概念时，AI 本可以自行"猜测"它是什么——也许是一个百分比，也许是一个等级，也许是一个技能矩阵。但创作者选择了在文档中明确定义：0 到 100 的分数，配合命名等级，卡片上显示职位名称、三项核心优势，并且随着用户采用 AI 的程度动态更新。

如果他把这个定义留给 AI 去猜，最终的产品可能完全偏离预期。这正是文档在 AI 辅助开发中的核心价值：把产品决策权牢牢握在人的手中，让 AI 负责执行而非定义。

PRD：从目标到构建提示的完整施工图

在开启安全加固技能（security hardening skill）后，AI 返回的 PRD 以模块化结构呈现，涵盖以下内容：

• 目标与非目标：明确产品要做什么，以及同样重要的是不做什么
• 用例与成功指标：定义谁在什么场景下使用，以及如何衡量成功
• 产品原则：六条在界面出现之前就写下来的原则
• 11 步用户流程：从进入产品到完成核心任务的完整路径
• 评分机制与分享卡片：功能的具体行为定义
• 数据模型与端点：技术实现的底层结构
• 风险清单：可能出问题的地方

PRD 中最值得关注的部分是末尾的 17 条构建提示（build prompts）。每一条按顺序列出：需要创建的文件、需要编写的测试、以及"完成"的定义标准。这意味着 Cursor 在任何时候都不需要猜测下一步该做什么——它只需要按顺序执行。

创作者特别提到，这 17 条构建提示让 AI 编码变得确定性强得多，因为每一步都有明确的输入和输出。

PRD（Product Requirements Document，产品需求文档） 是产品开发中的标准文档，传统上由产品经理撰写，用于对齐团队对产品功能、范围和优先级的一致理解。在 AI 辅助开发场景中，PRD 的角色发生了根本性变化：它不再只是给人类团队看的沟通文件，而成为直接喂给 AI 编码工具的结构化输入。

传统 PRD 通常侧重于描述"做什么"和"为什么做"，对"怎么做"保持一定的抽象度，留给工程师发挥空间。但 AI 编码工具缺乏人类工程师的领域常识和产品直觉，任何未在文档中明确的信息都可能被"自由发挥"。因此本文中的 PRD 被扩展为一份"施工图"——不仅包含目标、用例、数据模型等常规内容，还在末尾附上了按顺序执行的构建提示。这种"PRD + 构建提示"的混合形态，本质上是把产品定义与执行指令合二为一，让 AI 在每一步都有确定的输入和验收标准。

六条产品原则：在第一个屏幕出现之前就定好

PRD 中最具启发性的部分不是功能列表或数据模型，而是六条在"任何屏幕存在之前"就写下的产品原则：

1. 诚实优先，不制造虚假安慰也不故意制造焦虑——这与 AI 相关产品的可信度高度相关
2. 质量先于成本——在评估推荐时，不因成本低就降低质量标准
3. 估算而非预测——提供的所有数值都是估算，不包装成精确预测
4. 推荐始终可见——用户能看到系统的建议，而非黑箱操作
5. 免费资源优先——推荐学习路径时，免费选项排在前面
6. 默认隐私保护 + 简洁高级感——产品的两个基础体验准则

这六条原则在功能层面会转化为许多具体决策。比如"诚实优先"意味着评分不会为了让用户开心而虚高；"免费资源优先"意味着推荐课程的排序逻辑有明确的价值取向。如果没有在写代码前定下这些原则，后续每一个功能决策都可能变成一次"临时拍脑袋"。

设计系统：从设计文档到可复用组件

设计文档最终被转化为一套完整的设计系统，包含：

• 设计令牌（tokens）：颜色、间距、圆角等基础变量
• 排版规范（typography）：字体、字号、行高的完整体系
• 颜色系统：海军蓝搭配白色背景，传递"高级、简洁、专业"的视觉调性
• 组件库：屏幕由哪些组件构成，每个组件的状态和行为

创作者对结果表示满意——"每一件事都被定义了"，唯一的缺失是图片素材，在要求 AI 补充后也得到了更新。

这套设计系统的一个直接产物是分享卡片（share cards）。用户可以导出竖版卡片，展示自己的 AI 就绪评分，分享到社交平台。卡片上包含评分、命名的等级、职位名称和三项优势——这些内容直接来自 PRD 中的定义，而非设计阶段的临时决策。

设计系统在 AI 辅助开发中的价值尤为明显：当每个颜色、间距、组件状态都被显式定义后，Cursor 生成的代码在视觉一致性上会有质的提升。

设计令牌（Design Tokens） 是设计系统中最基础的原子层，指将颜色、间距、字号、圆角、阴影等视觉决策抽象为命名变量。例如 color-primary 可能对应海军蓝 #1B2A4A，spacing-md 可能对应 16px。令牌的核心价值在于"单一事实来源"：当需要调整品牌色时，只需修改令牌定义，所有引用该令牌的组件自动更新。

在 AI 辅助开发中，设计令牌的作用被进一步放大。当 Cursor 生成代码时，如果令牌被显式定义，AI 会直接引用 var(--color-primary) 而非硬编码 #1B2A4A，从而保证视觉一致性；如果令牌缺失，AI 往往会在不同文件中重复写入具体数值，导致后续修改困难且容易产生视觉偏差。同理，排版规范和组件库的显式定义也减少了 AI 的"猜测空间"，使生成的前端代码更接近专业设计师的产出质量。

路线图：30 项任务与 P0 的边界

路线图以表格形式返回，包含 30 余个项目，每项标注三个维度：领域（area）、优先级（priority）、规模（size）。其中 P0 项构成 Version 1，其余全部归入后续版本。

创作者对 Version 1 有清晰的定位："Version 1 是第一步，不是产品本身。" 这个区分很重要。很多团队把 Version 1 当作"完整产品"来规划，导致 P0 范围不断膨胀，最终既无法按期发布，也难以获得清晰的用户反馈。

路线图中还包含一个值得注意的设计：用户可以通过完成基础免费课程、构建实际应用、上传审核来提升自己的 AI 就绪评分。评分从 30 提升到 70 或 75 时，系统会记录这条改进轨迹，用户可以将其分享给雇主。这形成了一个"学习-认证-提升-分享"的闭环，把评分从一个静态数字变成了动态的成长记录。

P0（Priority 0） 是产品优先级体系中的最高级别，通常代表"必须在上线前完成，否则产品无法发布或核心价值不成立"的任务。与之对应的还有 P1（重要但可延后）、P2（锦上添花）等。P0 的划定直接决定了 Version 1 的范围边界。

在实践中，P0 膨胀是产品延期的最常见原因之一——每个功能看起来都"不可或缺"，最终导致发布遥遥无期。本文中创作者明确将 Version 1 定义为"第一步，不是产品本身"，这是一种有意识的范围约束策略。通过把 30 余项任务中仅有少数划为 P0，其余全部归入后续版本，团队可以在较短时间内获得一个可运行、可反馈的最小产品，而不是在漫长开发后才发现方向偏差。这种思路与精益创业中的 MVP（Minimum Viable Product，最小可行产品）理念一脉相承，但更强调在 AI 辅助开发中通过文档提前锁定范围，避免 AI 在编码过程中自行"补全"未被要求的功能。

这套流程适合谁？

这种方法最适合以下场景：

• 你有一个相对复杂的产品想法，涉及多个功能模块和用户角色
• 你打算用 AI 编码工具（如 Cursor）来加速开发
• 你希望产品在多次迭代后仍然保持结构清晰、决策一致

对于快速验证的小原型，这套流程可能过重。但对于一个你打算从零做到一、并持续迭代的产品，在写第一行代码前花时间把这四份文档做好，省下的是后续反复返工和产品方向摇摆的成本。

下一集，这位创作者将带着所有文档进入 Cursor 的 Agent 模式，逐条执行构建提示并验证测试。这才是真正检验文档质量的时刻。