1. 项目概述一个为AI时代重构的PRD生成技能如果你是一名产品经理、独立开发者或者正在用AI工具比如Cursor、v0快速构建原型那你肯定对写PRD产品需求文档这件事又爱又恨。爱的是一份清晰的文档能对齐团队、指导开发恨的是传统的PRD写作过程往往冗长、静态而且写出来的文档AI工具“看”不懂工程师也未必爱看。我们常常陷入一个怪圈花几天时间写了一份几十页的文档结果在跟AI结对编程时还得把需求拆碎了、用自然语言重新描述一遍效率并没有本质提升。今天要聊的这个项目——johnnychauvet/prd-skill就是瞄准这个痛点来的。它不是一个新工具而是一个给Claude CodeAnthropic推出的AI编程助手用的“自定义技能”。简单说你把它安装到你的Claude Code环境里就能通过一个简单的/prd命令启动一个对话式的需求发现流程最终生成一份结构化、且专门为AI原型工具优化的PRD。这份文档的神奇之处在于它同时服务于两个“读者”你的真人团队产品、设计、研发和你的AI编程伙伴如Cursor、v0、Lovable。它用一套统一的语言把“为什么要做”和“要做什么”讲清楚让AI能直接理解并开始生成代码省去了中间大量的翻译和解释工作。这个技能的核心价值是提效和降本。对于独立开发者或小团队它能让你在构思阶段就产出机器可读的规格无缝对接后续的AI辅助开发。对于稍大一点的团队它提供了一种基于“待完成工作”Jobs to Be Done和“用户故事”User Stories的标准化需求沟通框架减少歧义。接下来我会带你深入拆解它的设计思路、实操细节并分享如何最大化利用它来提升你的产品构建流程。2. 核心设计哲学从“为什么”出发构建人机协同的桥梁2.1 为什么传统PRD在AI时代不够用了在深入这个技能的具体实现前我们得先理解它要解决的根本问题。传统的PRD无论是Word文档、Confluence页面还是Notion模板本质上是为人与人之间的沟通设计的。它们依赖自然语言的丰富性、上下文和人类的共同理解。但AI工具特别是代码生成AI处理这类自由格式文本时存在几个致命短板信息提取困难AI需要从大段描述中识别出关键实体如组件名、数据字段、API端点这个过程容易出错或遗漏。意图模糊一句“用户应该能方便地管理他们的订阅”对人类来说可能指向一个包含列表、详情、取消按钮的页面但对AI来说这个“方便”太抽象它可能生成一个简陋的按钮也可能生成一个过度复杂的仪表盘。缺乏结构化输入像v0、Lovable这类UI生成工具以及Cursor的代码生成功能最擅长处理的是明确、结构化的指令。比如“生成一个包含id、name、status字段的用户列表组件并带分页”远比一段散文式的需求描述有效。prd-skill的设计者洞察到了这一点与其让AI去“猜”我们的需求不如我们主动提供一份AI“友好”的规格说明书。这份说明书的核心是将人类的产品意图翻译成机器AI可高效执行的构建指令。2.2 JTBD 用户故事构建清晰的需求逻辑链这个技能采用“待完成工作”Jobs to Be Done, JTBD和“用户故事”User Stories作为需求的双层框架这不是简单的堆砌而是一套严谨的、从动机到实现的推导逻辑。JTBD层定义“为什么”JTBD的经典句式是“当**[情境]我想要[动机]以便我能[预期结果]**。” 这个技能在对话中会引导你思考这个层面。例如对于一个图片上传功能JTBD可能是“当我在撰写博客文章时我想要快速插入并裁剪图片以便我能更专注于内容创作而不是处理图片格式。”为什么这很重要对于AI工具而言理解“为什么”能防止它生成“技术上正确但产品上错误”的方案。如果AI只知道“需要图片上传按钮”它可能生成一个基础的文件选择器。但如果它知道用户的核心动机是“快速插入并裁剪以便专注创作”它就更有可能生成一个集成了预览、简单裁剪如固定比例选择和一键插入的组件。JTBD为AI的“创作”提供了目标和约束。用户故事层定义“做什么”用户故事是JTBD的具体实现格式为“作为**[角色]我想要[动作]以便[收益]**。” 在prd-skill生成的文档中每个用户故事都有唯一ID如US1, US2并且会明确关联到它所服务的JTBD。例如对应上面的JTBD用户故事可能是US1: 作为博客作者我想要从本地选择一张图片上传以便将其插入到文章中。US2: 作为博客作者我想要在上传前对图片进行简单的矩形裁剪以便调整图片的焦点区域。US3: 作为博客作者我想要在插入前预览图片在文章中的效果以便确保排版美观。两层框架如何协同工作JTBD是战略层关注用户目标和场景用户故事是战术层关注具体的、可交付的功能点。这个技能通过强制建立两者的关联确保了每一个要开发的功能点都有明确的、源自用户真实需求的“出身证明”。在生成的PRD中这会形成一个清晰的追溯矩阵无论是团队成员评审还是AI在生成某个组件代码时都能立刻明白这个功能存在的终极意义从而做出更合理的决策。2.3 为AI工具量身定制的文档结构这是prd-skill最精妙的部分。它生成的PRD不是通用模板其每一个章节都预设了“消费者”——某类AI工具。我们来看看几个关键章节的设计意图AI构建摘要AI Build Summary这是整个文档的“电梯演讲”。Cursor或Replit这类需要理解全局的AI会首先阅读这部分。它用最精炼的语言描述了产品是什么、核心价值是什么、以及关键的技术约束。这相当于给AI设定了一个正确的初始认知方向。组件清单Component Inventoryv0、Lovable、bolt.new这类UI生成工具其工作单元是组件如Button、DataTable、UserProfileCard。这个章节会列出所有需要的前端UI组件并附带简短描述和关键属性。AI拿到这个清单就可以像根据采购单进货一样逐个生成或组装这些组件。数据模型Data Models以TypeScript接口的形式定义。这是给AI的“数据宪法”。当Cursor需要生成一个处理用户数据的函数时它不必猜测user对象有没有emailVerified字段直接引用这里定义的User接口即可确保生成的代码是类型安全的前后端数据定义一致。API/集成接口API / Integration Surface明确定义了端点URL、方法、请求/响应格式和可能的错误码。这对于生成服务端路由如使用Next.js API Routes, Express.js和前端API客户端如使用TanStack Query, SWR的AI来说是直接的脚手架。状态管理映射State Management Map明确指示哪些状态应该存储在客户端如React Context, Zustand哪些需要从服务器获取哪些应该放在URL查询参数中。这能有效避免AI在架构上犯低级错误比如把本应全局共享的用户信息放在组件局部状态里。技术栈推荐Tech Stack Recommendation直接锁定框架、库和关键工具版本如“Next.js 14, Tailwind CSS, Prisma, PostgreSQL”。这防止了AI在生成代码时混用不兼容的库比如同时建议Redux和MobX保证了技术栈的一致性。建议的文件结构Suggested File Structure一个ASCII树状图。这为AI的“项目脚手架”功能提供了明确的目录蓝图。AI可以依此创建app/、components/、lib/、types/等文件夹和初始文件让项目从一开始就保持清晰的组织。验收标准Acceptance Criteria这是给AI测试代理如果使用的检查清单。每个用户故事都附带一系列可验证的、二进制是/否的标准。AI在生成代码后可以对照这些标准进行初步的自我验证。通过这种“按需供应”的结构化输出prd-skill让PRD从一份被动的“阅读材料”变成了主动的“构建指令集”。3. 从安装到生成完整实操指南3.1 环境准备与技能安装首先你需要一个能运行Claude Code的环境。目前这通常意味着你需要在支持Claude Code的编辑器或IDE中请根据官方渠道获取最新信息。安装prd-skill本身极其简单它本质上就是一个Markdown文件。安装步骤获取技能文件你需要先拿到SKILL.md文件。通常你需要克隆或下载johnnychauvet/prd-skill这个仓库。git clone https://github.com/johnnychauvet/prd-skill.git cd prd-skill选择安装模式全局安装推荐让/prd命令在所有项目中都可用。# 确保目标目录存在 mkdir -p ~/.claude/commands # 复制技能文件并重命名为 prd.md cp SKILL.md ~/.claude/commands/prd.md这样无论你在哪个项目目录下打开Claude Code都可以使用/prd命令。项目本地安装只在你当前的项目中可用。这适合团队协作确保每个人都使用同一版本的技能。# 在当前项目根目录下创建命令文件夹 mkdir -p .claude/commands # 复制技能文件 cp SKILL.md .claude/commands/prd.md记得将.claude文件夹加入你的.gitignore文件或者将prd.md纳入版本管理视团队规范而定。验证安装重启你的编辑器/IDE中的Claude Code界面。在聊天输入框中键入/你应该能在弹出的命令列表中看到prd选项。实操心得路径问题在Windows系统上全局路径~/.claude/commands对应的是C:\Users\你的用户名\.claude\commands。如果遇到命令未加载的情况首先检查文件是否复制到了正确的位置并且文件名是prd.md注意不是SKILL.md。Claude Code通常会自动扫描这些目录但偶尔需要重启IDE或重新加载窗口。3.2 启动与交互对话式需求发现安装完成后使用起来非常直观。基本用法在Claude Code的聊天框中直接输入/prd按下回车Claude Code便会加载这个自定义技能并开启一个结构化的对话流程。它会一步步引导你就像一个有经验的产品顾问在对你进行访谈。带参数的快捷方式如果你已经想好了功能或项目的名称可以预填充标题跳过初始命名步骤/prd “用户仪表盘重设计”这样对话会直接从针对“用户仪表盘重设计”的澄清问题开始。交互流程详解典型的对话流程会涵盖以下几个关键阶段每个阶段都旨在抽取结构化信息目标与问题定义它会问“这个产品/功能主要解决什么问题”、“目标用户是谁”。你的回答应该尽量具体避免“让生活更美好”这类空话。例如“为自由职业者提供一个极简的发票创建、发送和跟踪工具解决他们手动制作Excel发票、遗忘催款的痛点。”核心场景JTBD挖掘技能会引导你描述1-3个最主要的用户场景并用JTBD框架来表述。这是核心输入请务必思考清楚。例如“当自由职业者完成了一个项目需要向客户收款时他想要在1分钟内生成一份看起来专业、包含所有法律要求信息的发票以便能快速发出并开始收款流程而不用去研究模板或法律条款。”用户故事分解基于JTBD技能会帮你梳理出具体的用户故事。它会问“为了实现上述目标用户需要能执行哪些具体操作” 你可以列出如“创建新发票”、“添加客户信息”、“预览并发送发票”等。技能会帮你将它们格式化为标准用户故事。技术约束与偏好它会询问你偏好的技术栈、是否需要考虑移动端、是否有必须集成的第三方服务等。即使你没有明确偏好也建议在这里给出方向比如“前端用ReactUI库用Ant Design状态管理用Zustand”。这能极大提升后续AI生成代码的准确性和可用性。如果你回答“无所谓”技能会使用其内置的默认推荐通常是当前流行的全栈方案如Next.js Tailwind Prisma但这可能不完全符合你的项目。细节追问对于关键的用户故事它会追问细节以形成验收标准。例如对于“预览发票”它可能会问“预览需要是实时的吗需要模拟不同设备的显示效果吗用户能否在预览时直接修改内容”整个对话过程是迭代和引导式的。你可以随时补充或修正之前的回答。它的目标不是一次性问完所有问题而是确保覆盖生成一份高质量、AI友好的PRD所必需的核心要素。3.3 输出解读与成果应用对话结束后Claude Code会基于你的输入生成一份完整的Markdown格式的PRD。你应该将其保存为一个文件例如PRD.md。生成的PRD结构示例文档会非常长但结构清晰。以下是一个简化版的核心章节示意# 产品需求文档自由职业者发票工具 ## 1. AI构建摘要 一个让自由职业者能快速创建、发送并跟踪发票状态的Web应用。技术栈基于Next.js 14 (App Router)使用Tailwind CSS进行样式设计后端采用Prisma ORM连接PostgreSQL数据库。核心价值在于将开票流程从30分钟缩短至2分钟。 ## 2. 待完成工作 (JTBD) - JTBD1: 当完成项目需要收款时我想要快速生成专业发票以便及时发起收款流程。 - JTBD2: 当发出发票后我想要清晰跟踪哪些已付、哪些逾期以便有效进行催款。 ## 3. 用户故事与验收标准 - US1 (服务于JTBD1): 作为自由职业者我想要通过表单输入项目详情、小时费率与税费以便自动计算总金额。 - 验收标准 - AC1.1: 表单包含项目描述、工作时间、时薪、税率(%)字段。 - AC1.2: 总金额时薪*工作时间*(1税率)实时计算并显示。 - US2 (服务于JTBD1): 作为自由职业者我想要添加或从通讯录选择客户信息并一键生成PDF发票。 - 验收标准... - US3 (服务于JTBD2): 作为自由职业者我想要在仪表盘上以卡片列表形式查看所有发票及其状态待发送、已发送、已支付、逾期。 - 验收标准... ## 4. 组件清单 - InvoiceForm: 包含项目信息、客户信息、计算逻辑的表单组件。 - InvoicePreview: 实时渲染发票PDF样式的预览组件。 - InvoiceCard: 展示单张发票摘要编号、客户、金额、状态的卡片组件。 - DashboardHeader: 包含统计概览本月收入、未结发票数的头部区域。 - StatusBadge: 根据发票状态显示不同颜色标签的原子组件。 ## 5. 数据模型 (TypeScript) typescript interface Invoice { id: string; invoiceNumber: string; clientId: string; projectDescription: string; hoursWorked: number; hourlyRate: number; taxRate: number; totalAmount: number; // 计算字段 status: draft | sent | paid | overdue; dueDate: Date; createdAt: Date; } interface Client { id: string; name: string; email: string; company?: string; }6. API接口GET /api/invoices- 获取当前用户的发票列表支持按状态过滤。POST /api/invoices- 创建新发票草稿。GET /api/invoices/[id]/pdf- 生成并返回指定发票的PDF文件。PATCH /api/invoices/[id]/status- 更新发票状态如标记为已支付。7. 状态管理映射服务器状态: 用户信息、发票列表、客户列表。使用TanStack Query从API获取并缓存。全局客户端状态: 当前选中的发票、UI主题。使用Zustand store管理。本地组件状态: 表单输入值、预览模态框开关。使用ReactuseState。8. 技术栈推荐框架: Next.js 14 (App Router) for full-stack React.样式: Tailwind CSS for utility-first styling.ORM: Prisma for type-safe database access.数据库: PostgreSQL (via Supabase or Railway).状态管理: Zustand for client state, TanStack Query for server state.PDF生成: react-pdf/renderer or pdf-lib.9. 建议的文件结构/app /api /invoices route.ts /invoices /[id] page.tsx page.tsx /dashboard page.tsx /components /invoices InvoiceForm.tsx InvoiceCard.tsx /ui Button.tsx Card.tsx /lib db.ts /api-client invoices.ts /types index.ts10. 验收标准详细列表...**如何应用这份PRD** 1. **与团队评审**将这份PRD分享给产品、设计、研发伙伴。由于其结构清晰JTBD-用户故事-验收标准评审效率会很高大家能快速理解功能背后的“为什么”和“是什么”。 2. **喂给AI工具** - **Cursor**你可以直接打开Cursor将整个PRD或某个章节如“组件清单”、“数据模型”粘贴到聊天中并给出指令如“请根据这份PRD的InvoiceForm组件描述和数据模型生成一个React组件使用Tailwind CSS样式。” - **v0 / Lovable**将“组件清单”和“数据模型”部分输入可以生成对应的UI界面。你甚至可以把“建议的文件结构”给Cursor让它帮你搭建初始项目脚手架。 - **Replit**在Replit的AI辅助模式下提供PRD中的“API接口”和“数据模型”部分可以快速生成服务器端路由和数据库操作代码。 3. **作为开发蓝图**即使不重度依赖AI这份结构化的文档本身也是极佳的开发指南。前端工程师看“组件清单”和“状态管理映射”后端工程师看“数据模型”和“API接口”大家共享同一份事实来源减少沟通成本。 ## 4. 高级定制与实战技巧 ### 4.1 根据项目复杂度调整PRD prd-skill的对话流程是灵活的生成的PRD内容也会根据你的回答进行增减。 - **对于简单功能如一个设置页面**在对话中当被问到某些部分如复杂的API设计、多端适配时你可以直接回答“不适用”或“暂不需要”。技能会聪明地省略这些章节让文档保持简洁。 - **对于大型、跨团队项目**你可以在对话中主动提供更多信息。例如在谈到“约束与依赖”时详细说明需要与另一个团队的用户认证服务对接。生成的PRD可能会在相关章节如“API/集成接口”、“开放问题”中突出这部分依赖关系。你甚至可以事后手动在PRD中添加一个“**依赖关系图**”或“**团队分工**”章节。 - **对于设计驱动型项目**在“提议的体验Proposed Experience”部分多花些笔墨。描述关键的屏幕流、交互细节、动效要求以及具体的可访问性标准如WCAG AA级别。这些细节对于v0这类UI生成工具尤其有价值。 - **对于API优先或后端密集型项目**重点深化“数据模型”和“API接口”部分。在对话中详细描述每个实体的关系、API的认证方式如JWT、分页格式、错误码定义。你甚至可以在生成PRD后手动补充Swagger/OpenAPI格式的片段使其对生成后端代码的AI工具更友好。 ### 4.2 自定义技能模板 如果你发现默认的PRD模板不完全符合你团队的习惯或者你想加入一些特定的检查项如“安全与隐私考量”、“数据分析埋点”你可以直接修改SKILL.md文件。 **修改步骤** 1. 用文本编辑器打开你克隆的仓库中的SKILL.md文件。 2. 这个文件本身就是一个大型的、结构化的提示词Prompt。你可以找到各个章节对应的生成逻辑通常以##标题和后续的引导语形式存在。 3. 进行定制化修改。例如如果你想在“技术栈推荐”后增加一个“部署与运维考量”章节你可以在相应位置添加一段引导语比如 ## 部署与运维考量 [请描述项目上线后的部署环境如Vercel, AWS、监控需求、日志策略以及预期的扩缩容考虑。] 4. 保存文件并重新复制到你的Claude命令目录cp SKILL.md ~/.claude/commands/prd.md。 5. 重启Claude Code下次使用/prd时新的模板就会生效。 **注意事项修改模板的风险** 修改SKILL.md需要一定的提示词工程经验。不当的修改可能会破坏对话流程的逻辑连贯性导致Claude无法正确理解或生成混乱的内容。建议先备份原文件每次只做小的增量修改并充分测试。最好的实践是基于原模板生成几份PRD找到你觉得缺失或冗余的固定部分再有针对性地调整模板。 ### 4.3 与不同AI工具链的集成实践 prd-skill生成的PRD是一个通用的中间件如何与下游工具高效衔接有一些技巧 - **Cursor PRD**这是最流畅的组合。在Cursor中你可以开启一个“Agent”会话将整个PRD文件作为上下文喂给它。然后你可以用非常具体的指令驱动开发例如“基于PRD中的US1和组件清单创建InvoiceForm组件使用Shadcn/ui的组件库和React Hook Form进行表单管理。” Cursor能基于PRD中的完整上下文生成风格一致、数据模型匹配的代码。 - **v0 组件清单**将PRD中“组件清单”部分复制到v0的提示词中效果极佳。例如输入“请生成一个包含以下组件的发票仪表盘页面DashboardHeader显示统计卡片、InvoiceCard列表带状态标签和操作按钮、一个浮动操作按钮用于创建新发票。使用Tailwind CSS风格保持专业简洁。” v0能精准理解每个组件的作用并生成对应UI。 - **Lovable 数据模型/API**Lovable擅长从数据模型生成CRUD界面。将PRD中的Invoice和Client接口定义以及GET /api/invoices等API描述提供给Lovable它可以快速搭建出带有列表、详情、表单页面的完整管理后台原型。 - **全流程串联**一个理想的工作流是1) 用/prd生成需求文档2) 用Cursor根据“文件结构”搭建项目骨架3) 用v0根据“组件清单”生成核心页面UI4) 用Cursor或手动编码根据“数据模型”和“API接口”实现后端逻辑。PRD作为唯一的真相源贯穿始终。 ## 5. 常见问题与避坑指南 在实际使用prd-skill和基于其输出进行开发的过程中我遇到并总结了一些典型问题和解决方案。 ### 5.1 技能使用阶段的问题 **Q1: 输入/prd后没有反应或者提示“命令未找到”。** - **检查1文件路径和名称**。确保prd.md文件被正确复制到了~/.claude/commands/或.claude/commands/目录下且文件名**完全一致**注意大小写通常是全小写。 - **检查2Claude Code版本与兼容性**。确认你使用的编辑器/IDE插件支持自定义命令功能。有时需要重启IDE或重新加载窗口来使新命令生效。 - **检查3命令前缀**。有些环境可能需要更具体的命令如/skill prd但根据原项目说明标准命令是/prd。以你的Claude Code环境为准。 **Q2: 在与技能的对话中我的回答被误解或引导方向不对。** - **技巧保持回答具体、结构化**。AI基于你的回答生成后续问题。如果你回答“让用户体验更好”它无法获得有效信息。尝试用“减少用户从点击到完成所需的步骤数从5步减到2步”这样的具体目标来回答。 - **技巧主动引导**。如果技能问的问题不是你当前关心的你可以直接说“我们先跳过这个问题我更想聚焦在XX方面”然后清晰地陈述你的需求。技能有很好的上下文理解能力会跟随你的引导。 - **技巧迭代修正**。如果你发现之前某个问题的回答不准确可以在后续对话中补充或纠正例如“关于之前提到的用户角色我需要补充一点实际上还有一类管理员用户...”。技能会尝试整合这些信息。 ### 5.2 PRD内容与生成阶段的问题 **Q3: 生成的PRD在某些章节如技术栈上推荐了我不喜欢或不熟悉的工具。** - **预防**在对话的“技术约束与偏好”环节**一定要明确表达你的选择**。不要说“都可以”或“你推荐吧”。直接给出你的技术栈如“前端用Vue 3 Element Plus后端用Go Gin数据库用MySQL”。 - **补救**如果已经生成了直接手动修改PRD文档中“技术栈推荐”部分即可。PRD是给你用的不是一成不变的圣旨。 **Q4: 生成的用户故事或验收标准太泛泛不够具体无法直接指导开发或测试。** - **根因**这通常是因为你在描述JTBD和用户故事时回答得不够细致。JTBD中的“预期结果”和用户故事中的“收益”需要是可衡量的。 - **优化方法**使用“SMART”原则来审视你的描述。例如将“以便能快速发出发票”改为“以便能在2分钟内完成从打开应用到发票发送至客户邮箱的全流程”。这样后续的验收标准自然就会包含“创建发票表单加载时间3秒”、“PDF生成时间5秒”等具体条款。 ### 5.3 与AI开发工具协作阶段的问题 **Q5: 我把PRD给Cursor但它生成的代码忽略了数据模型中的某些字段。** - **排查**首先检查PRD中“数据模型”部分的TypeScript接口定义是否清晰、完整。确保没有拼写错误所有字段都有明确的类型。 - **技巧分步指令**。不要一次性让AI生成整个复杂组件。先让它根据接口生成一个基础的、只有类型和结构的组件框架。然后再基于这个框架分步指令它添加表单逻辑、样式、事件处理等。例如“请先根据Invoice接口生成一个包含所有字段的React组件props类型和一个空的表单结构。” - **技巧引用具体章节**。在给AI的指令中明确指出参考来源。如“请参考PRD中‘数据模型’章节定义的Invoice接口以及‘组件清单’中对InvoiceForm的描述生成该组件。” **Q6: 用v0生成的UI与我的产品设计风格不符。** - **预防**在PRD的“提议的体验”或“非功能性需求”部分如果技能引导你提到了加入对设计风格的描述。例如“采用Material Design 3设计语言主色为#6750A4圆角大小为8dp。” - **补救**v0等工具生成的UI通常是基础HTML和Tailwind CSS。你可以将其作为功能完整的“高保真原型”然后由设计师或前端工程师在其基础上应用统一的设计令牌Design Tokens、组件库主题进行重构。PRD确保了功能结构的正确性视觉风格是相对独立且易于调整的层。 **Q7: 团队同事不习惯看这种结构化的PRD还是想要传统的Word文档。** - **策略**将prd-skill生成的Markdown文档作为**核心事实来源**。然后你可以利用工具如Pandoc或简单的复制粘贴将其内容重组到团队习惯的Word或Confluence模板中。结构化PRD的优势在于其内容已经是模块化的迁移成本很低。你可以向团队展示这份文档如何能直接转化为AI可执行的指令从而加快原型验证速度这本身就是一个强大的说服点。 ### 5.4 思维转变最大的“坑”是期待AI完全替代思考 最后也是最关键的一点prd-skill是一个强大的**辅助**工具而不是**替代**工具。它不能替代你对产品深入的思考和对用户需求本质的洞察。它最大的价值在于将你清晰的思考高效地转化为一种对人和机器都友好的表达形式。 最常见的“坑”是用户期望通过一个模糊的想法就能让技能对话自动导出一份完美的PRD。这不可能。技能只能基于你输入的信息质量进行输出。你思考得越深入对场景、用户、边界条件梳理得越清楚对话时提供的信息越具体、越结构化最终生成的PRD质量就越高对后续AI辅助开发的助力也就越大。 因此在使用这个技能时请把它当作一个严格的“产品思维教练”。它通过问题迫使你厘清那些你原本可能想含糊过去的部分。这个过程本身就是最大的价值所在。当一份优秀的、人机皆可读的PRD诞生时你的产品方案其实已经在脑海中经历了数次迭代变得无比清晰了。