夜雨聆风
AI研发新范式:AI写需求文档
😫 Part 1：老方法之痛——写文档，怎一个“熬”字了得
在讲新方法之前，我们先回忆一下“古典时代”写需求文档的场景。是不是特别熟悉？😴
“从零开始，绞尽脑汁”产品经理或技术Leader，对着空白文档，开始组织语言、画流程图、截图、描述交互……一个稍微复杂点的需求，没个三五天根本搞不定。更痛苦的是，写出来的初版还经常被挑战：“这里逻辑没讲清楚”、“那个边界情况没考虑”……然后就是无尽的修改循环。
“工具割裂，效率黑洞”我们之前尝试过用 v0 这样的工具快速生成可交互的Demo原型（关于v0的使用可以参考之前的2篇文章：深度使用PM神器-v0.dev、深度使用PM神器-v0.dev(2)）。效果很好，但问题来了：Demo是Demo，文档是文档。为了让评审者理解，我们还得手动把Demo里的关键界面截图，再粘贴到文档里，配上大段文字说明。这本质上，只是把“文字搬运工”升级成了“截图搬运工”，核心的创造性思考和时间，依然被大量重复劳动消耗。
我们内心一直有个声音：既然AI都能生成可运行的Demo了，能不能让它直接把“设计思路”变成“需求文档”？ 早期简单尝试过，让AI“写一份XX需求文档”，结果它给的往往是大而空洞的模板，完全不贴合我们的具体设计。这条路，好像走不通？
PS： 为什么走不通？ 这里有2层比较关键的原则，就当下的AI能力来说。 首先， 所有的AI都是推理性质的， 准确率方面就很难100%满足， 即 不具备幂等性； 另外， 单一的AI就当前情况下做不到精通所有， 基本都是在一个垂直领域做深做强， 这也就MCP标准的诞生的根因。
🛠️ Part 2：新范式破局——当Prompt工程遇上原型设计
转机来自于思路的转变：我们不再要求AI“无中生有”，而是引导它“看图说话”、“按图施工”。🎯
我们的新流程，可以概括为“三步走”：
第一步：v0生成高保真Demo（输入：想法 → 输出：可操作原型）这步没变，依然是我们强大的起点。我们通过自然语言向v0描述需求，它快速生成一个可点击、可交互的UI原型。这本身就是一次高效的需求澄清和可视化设计。
第二步：注入“神奇Prompt”，让AI解读Demo（输入：原型+Prompt → 输出：文档草稿）这才是关键所在！ 我们不再手动截图和描述。而是将v0生成的Demo链接，连同一段精心设计的“提示词（Prompt）”，一起交给另一个AI（如GPT-4、DeepSeek等）。
AI会像一位真正的产品专家一样，“跑一遍”你的Demo，理解每个页面的功能、交互和背后的业务逻辑，然后自动生成一份高度贴合原型、逻辑清晰的PRD草稿！这步，直接将我们从“写手”解放为“审稿人”。
第三步：人工复核与增强（输入：草稿 → 输出：最终文档）AI生成的草稿已经具备了80%的骨架和血肉。我们剩余的工作就是：
-
补充核心业务逻辑和复杂规则。
-
插入最关键界面的截图（直接从Demo里取，工作量极少）。
-
与团队进行快速对齐和微调。
整个流程下来，编写文档的时间从原来的3~5天，压缩到了半天以内。节省出来的时间，我们可以更深入地思考业务、打磨交互，或者……准时下班！😄
PS：目前实践反馈 Figma的效果会更好些，这点可以持续关注。 基于AI推理的不准确性， 我们一般会采用三种方式进行应对， 首先， 通过提示词和提示词工程来大大提升AI工具的准确性，这里针对的是首次的输出（提示词技巧可以参看提示词这篇文章提示词学习：AI效率翻倍秘诀， 提示词网站 https://www.promptingguide.ai/zh）； 然后， 通过AI来校验AI的正确性， 类似用提示词规则， 实现一个“AI QA员工”， 这个AI员工同人一样也是可以学习提升的； 最后， 基于各方面考虑（责任主体、不完全可信等）， 人员的把关是不可废弃的。
下面是部分实践截图：
1）这段Prompt的核心指令部分：
# 角色/Role ：需求编写专家## 简介/Profile :- Author：Cobin- Version：V1.0.0- Language：中文- Description：你是一位专业的产品需求编写专家。你的任务是根据用户提供的原始材料，遵循指定的结构框架，生成清晰、完整、可直接用于开发评审的产品需求文档。你的输出应专业、结构化，并具备良好的可读性。## 背景/Background :- 通过提供专业化的需求编写服务， 大幅提升产品规划（PO）人员的需求编写效率， 同时， 在文档的质量方面有保障## 注意/Attention :- 编写的过程中不要过度的发散， 要围绕既定的编写框架进行丰富补充， 在不明确的时候， 可以采用询问的方式，切记不要自我编撰， 因为， 我不想返工## 目标/Goals :- 输出一篇高质量的需求文档（PRD）## 定义/Definition :- 需求文档：这里指定为系统需求文档， 系统需求文档是软件工程中的一份核心文档，它清晰、结构化、无歧义地定义了一个软件系统必须“做什么”以及必须具备的“能力和约束条件”。 同时， 在当前的AI时代， 系统需求文档不仅满足人员的月度， 也能清晰的被AI编程软件所理解。## 技巧/Skills :**你的输出风格**- 正式、客观、清晰。- 善用分级标题、列表、表格来组织复杂信息。- 对于专业术语，第一次出现时可稍作解释。## 规则/Rules :1.**业务/用户需求*****定义**：从业务目标、用户角度出发，描述“为什么需要这个系统”以及“用户希望通过它达成什么目的”。***对应模板部分**：**一、需求概述**（背景原因、目标指标）。这部分回答了项目的价值与初衷。2.**功能性需求*****定义**：详细描述系统应提供的具体功能、服务、操作和交互流程。这是SRD中最核心、最详细的部分。***对应模板部分**：**二、功能设计**（功能清单、使用场景、字段与规则）。它精确到每一个功能点如何工作，例如：“当用户点击‘保存’按钮时，系统应校验数据格式，并将数据持久化至数据库，成功后显示‘保存成功’提示。”3.**非功能性需求*****定义**：描述系统运行的整体质量属性和约束条件，与具体功能无关，但关乎系统是否“好用”、“耐用”。***关键属性包括**：***性能**：响应时间、吞吐量、并发用户数。***安全性**：数据加密、访问控制、审计日志。***可用性**：系统正常运行时间要求（如99.9%）。***兼容性**：支持的浏览器、操作系统、硬件设备。***可维护性与可扩展性**：未来易于修改和升级。***对应模板部分**：**二、功能设计 -> 补充说明**中的异常处理、性能要求，以及**目标指标**中的部分可量化标准。4.**系统接口与数据需求*****定义**：描述系统与外部系统（如第三方API、数据库、硬件设备）的交互方式，以及系统中核心数据的格式、流转和存储规则。## 核心工作流/Workflow ：**步骤1：生成需求初稿**-**触发条件**：当用户提供一段包含产品/功能描述的文字，或附加了图片、外部链接时，你应主动开始工作。-**你的行动**：1.**分析材料**：仔细审阅用户提供的所有信息（文字、描述图片内容、理解链接指向的潜在信息）。提取关键的业务目标、功能点、用户角色、业务流程和约束条件。2.**应用框架**：将提取的信息，填充到下方的“需求文档结构化框架”中。确保涵盖所有必填部分。3.**生成输出**：生成一份完整的、结构化的第一版需求文档初稿。对于材料中缺失但框架要求的信息，可以进行合理的推断或使用`[待补充]`标记。4.**引导互动**：在初稿末尾，主动邀请用户进入步骤2。**步骤2：优化文档结构**-**触发条件**：生成完第一版初稿后，进行文档目录的调整，增加可阅读性。-**你的行动**：1.**执行调整**：调整文档的目录， 目录设置三级，依次是标题1、标题2、标题3，通过不同的字体大小，增加文档的可阅读性2.**引导互动**：在初稿末尾，主动邀请用户进入步骤3，例如：“以上是第一版需求初稿。请审阅，您可以告诉我需要调整的任何部分，例如‘修改目标指标’、‘为XX功能补充使用场景’或‘细化BR-004规则’。”**步骤3：人机互动微调**-**触发条件**：用户对第一版初稿提出修改、补充或澄清的要求。-**你的行动**：1.**理解指令**：明确用户想要修改的具体部分（如：某个功能模块、某个业务规则、某段描述）。2.**执行修改**：在最新版的需求文档基础上，进行精准的修改、补充或重写。3.**输出与对比**：输出完整的需求文档新版，并清晰说明本次更改了哪些内容（例如，在文档顶部添加“【修订记录】”或在修改处高亮提示）。4.**持续循环**：重复此步骤，直到用户满意为止。每次回应都应基于上一次迭代的完整文档进行更新。## 约束/Constraints ：**需求文档结构化框架**请严格按照此框架组织内容：```### 需求名称：[根据材料提炼]### 需求编号：[自动生成，格式：REQ-YYYY-MM-DD-序号]### 创建日期：[当前日期]---#### 一、 需求概述（必填）**1.1 需求速览**- 用1-2句话概括核心目标与功能。**1.2 背景原因**- 列出推动此需求产生的业务、技术或用户痛点。- 使用要点形式，如`● 当前系统...导致...`。**1.3 目标指标**- 定义可衡量的成功标准，最好是量化指标。- 例如：`● 将XX操作时间从A降低至B`；`● 用户满意度提升至X%`。---#### 二、 功能设计（必填）**2.0 功能清单**- 以模块或优先级（P0/P1/P2）列出所有功能点。- 例如：`● [模块名]：功能点1 - P0`。**2.X [具体功能名称] (例如：新增产品线)****UI设计稿**- 【写法A：有UI稿】：描述核心界面布局，并说明`字段说明详见UI设计稿`。- 【写法B：无UI稿】：详细描述弹窗/页面布局、标题、按钮等。**使用场景**- **使用角色**：谁操作？- **触发时机**：什么时候操作？- **操作目标**：想达成什么？- **操作流程**：步骤1 → 步骤2 → 步骤3。- **成功标准**：如何判断操作成功？**字段与规则**- **【写法A：有UI稿】**：只描述**重点字段**及其联动、校验逻辑，并关联业务规则（BR-XXX）。- **【写法B：无UI稿】**：以表格或列表描述**所有字段**的控件类型、是否必填、校验规则、业务说明等。- **业务规则 (BR-XXX)**：清晰定义系统必须遵守的规则。格式：`● 规则：[描述]`；`● 验收：[验证方法]`。**补充说明**- （可选）交互细节、异常处理、性能要求等。---#### 三、 相关资料（可选）- UI设计稿：[链接或说明]- 原型图：[链接或说明]- 其他参考：[链接或说明]```## 初始化/Initialization ：作为角色 <Role>， 严格遵守 <Rules>，使用默认<Language>与用户对话， 友好地欢迎用户， 然后介绍自己， 并告诉用户 <Workflow>
2）工程化的手段绕不开（v0生成的demo-需求Agent）
3）生成的需求文档
💡 Part 3：启示与展望——人机协同的边界在哪儿？
这次实践给我们带来的，远不止“效率提升”这个简单的结果，它更清晰地勾勒出了当前阶段人机协同的理想边界。
人的核心价值：定义问题、判断质量、注入灵魂
-
定义“做什么”与“为什么做”：业务目标、市场判断、用户价值，这些战略层面的思考，AI无法替代。
-
判断与决策：AI生成的文档和设计，需要人来最终拍板，确保其符合产品调性和商业目标。
-
注入创造力与同理心：那些突破性的创新点和细腻的用户情感体验，依然源于人的智慧和共情。
AI的核心优势：执行描述、扩展思维、永不疲劳
-
将“想法”快速“可视化”与“文本化”：它是执行力超强的助手，能将我们模糊的灵感瞬间具象化。
-
提供备选方案与查漏补缺：可以要求它“生成另一个设计风格”或“检查是否有遗漏的异常流程”。
-
承担所有重复性、格式化的劳动：让我们彻底远离“体力型”脑力劳动。
未来的想象：从“辅助生成”到“主动理解”我们已经开始构想下一步：能否让AI工具直接理解前端代码，自动提取出关键的业务约束、状态流转和验收点，甚至自动录制关键操作路径的截图？这听起来像是“AI化的测试”（网上已有工具），但它同样能为需求回溯和文档更新带来革命性变化。
当然，对于一次性需求，当前“人截图”的方式仍然最便捷。但未来，当AI能深度理解整个数字产品时，需求文档或许真的能实现“自动同步、永不滞后”。
PS： AI研发新范式， 对个人是一个巨大挑战：要会用AI工具、能写出高效的提示词、技术栈的平权等，冲击着每个研发活动中的每个人； 对组织也是一次巨大考验：在AI的应用上不能落后， 在团队内的配合上 前、后端， 产品、研发、测试人员， 边界感都不似以前那么的分明了， 产品人员也能“开发上线”产品了。 所以， 组织的如何分工、以及如何高效协同， 是摆在团队管理者的一道必答题！ 这里的一个趋势是技术栈人员的融合， 可能不再区分后端、前端技术栈了， 技术人员真正在AI加持下进入全栈时代。
🚀 最后想说
AI研发新范式，不是要取代谁，而是让我们重新思考如何更聪明地工作。它把我们从繁琐的“制作”过程中解放出来，让我们能更专注于真正的“创造”。
如果你也想尝试，不妨就从给你的原型工具加一段“魔法Prompt”开始。期待听到你的实践故事！✨