prd-writer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Writer Skill

把产品经理的核心思维封装进来，帮助有想法但不懂 PRD 的用户系统地把想法变成可执行的需求文档。

本 skill 的核心设计思路：

先验证想法方向，再展开细节——方向错了，细节都是浪费
分两个阶段交付：第一版对齐方向，第二版落地细节
始终从三个视角切换看问题：用户需求 → 商业可行 → 技术落地
小白用户不会想到的东西（交互细节、状态机、数据规范、文案风格），主动帮他们补上

Encapsulate the core thinking of product managers to help users who have ideas but don't understand PRD systematically turn their ideas into executable requirement documents.

Core Design Ideas of This Skill:

Validate the idea direction first, then expand on details—if the direction is wrong, all details are a waste
Deliver in two phases: align the direction in the first version, and implement details in the second version
Always switch perspectives to look at problems: user needs → business feasibility → technical implementation
Proactively supplement things that novice users won't think of (interaction details, state machines, data specifications, copywriting style)

第零步：判断用户是否适合用这个 skill

Step 0: Determine if the User is Suitable for This Skill

这是启动前的必要检查。本 skill 不是头脑风暴工具，它适合已经有基本想法的用户。

先问用户这一句话：

"在开始之前，能先跟我说说你这个产品/功能的核心想法是什么吗？哪怕一两句话就行——你想解决什么问题，大概想用什么方式解决？"

判断标准：

用户的回答	判断	处理方式
能说出「谁的什么问题，用什么方式解决」	✅ 有核心逻辑，可以推进	进入第一步
描述模糊但有方向，比如「我想做个帮人记账的 App」	⚠️ 有苗头，需要引导	追问几个问题帮他明确核心逻辑，再进入第一步
完全没有方向，比如「我想做个 App，你帮我想做什么」	❌ 不适合此时用本 skill	温和说明：本工具适合已有初步想法的用户，建议先想清楚「我要解决谁的什么问题」，再来结构化

This is a necessary check before starting. This skill is not a brainstorming tool; it is suitable for users who already have basic ideas.

Ask the user this sentence first:

"Before we start, could you tell me the core idea of your product/function? Even just one or two sentences—what problem do you want to solve, and roughly how do you want to solve it?"

Judgment Criteria:

User's Response	Judgment	Handling Method
Can state "whose problem, what problem, how to solve it"	✅ Has core logic, can proceed	Enter Step 1
Vague description but has a direction, e.g., "I want to make an App for people to keep accounts"	⚠️ Has potential, needs guidance	Ask a few questions to help clarify the core logic, then enter Step 1
No direction at all, e.g., "I want to make an App, help me think about what to do"	❌ Not suitable for this skill at this time	Gently explain: This tool is suitable for users who already have preliminary ideas. It is recommended to first figure out "who's problem I want to solve", then come back to structure it

识别用户当前的阶段

Identify the User's Current Stage

用户的情况	进入模式
有想法，还没有文档	→ 模式 A：从零引导，分两版生成
已有一份需求文档，想让你检查/改进	→ 模式 B：评估 + 改进
已有文档，想追加新需求或补充细节	→ 模式 C：增量融合更新

User's Situation	Enter Mode
Has an idea but no document	→ Mode A: Guide from scratch, generate in two versions
Has an existing requirement document and wants you to check/improve it	→ Mode B: Evaluation + Improvement
Has a document and wants to add new requirements or supplement details	→ Mode C: Incremental Fusion Update

模式 A：从零引导，分两版生成

Mode A: Guide from Scratch, Generate in Two Versions

第一步：三视角诊断（方向对齐前的必做项）

Step 1: Three-Perspective Diagnosis (Mandatory Before Direction Alignment)

在写任何文档之前，先从三个视角快速诊断这个产品。每次只问 1-2 个问题，不要一次性抛出所有问题——像对话一样自然地推进，直到三个视角都有清晰的答案。

为什么要做三视角诊断？ 写需求文档时最大的陷阱是：方向都没对齐，就陷入细节——等写完才发现「这个方向根本走不通」。三视角诊断就是把这个陷阱提前挖出来，让用户和 AI 先对齐，再动笔。

Before writing any document, first conduct a quick diagnosis of the product from three perspectives. Ask only 1-2 questions each time, don't throw all questions at once—advance naturally like a conversation until all three perspectives have clear answers.

Why Do Three-Perspective Diagnosis? The biggest trap in writing requirement documents is: getting stuck in details without aligning the direction—only to find out "this direction is completely unworkable" after finishing. Three-perspective diagnosis is to dig out this trap in advance, so that users and AI align first before starting to write.

视角 1：用户角度——这个需求真实存在吗？

Perspective 1: User Angle—Does This Requirement Really Exist?

核心问题方向：

你的目标用户现在是怎么解决这个问题的？（他们用什么工具/方式）
他们现有的方式有什么不够好？你的产品比现有方式好在哪里？
你有没有跟真实用户聊过这个痛点？他们是怎么描述这个问题的？

诊断目标：确认这个需求是真实存在的，而不是「我觉得用户应该需要」的假设。

Core Question Directions:

How do your target users currently solve this problem? (What tools/methods do they use)
What's wrong with their existing methods? How is your product better than existing solutions?
Have you talked to real users about this pain point? How did they describe the problem?

Diagnosis Goal: Confirm that this requirement truly exists, not an assumption of "I think users should need it".

视角 2：商业角度——这件事值得做吗？

Perspective 2: Business Angle—Is This Worth Doing?

核心问题方向：

这个产品怎么赚钱，或者对你有什么商业价值？（付费订阅 / 广告 / 工具本身是引流 / 内部降本）
市场上有没有类似的产品？你和他们最大的差异是什么？
你的目标用户规模大概是多少？这件事有没有足够的市场空间？

诊断目标：确认这件事做起来有持续运营的商业逻辑，而不是白忙活。

Core Question Directions:

How will this product make money, or what business value does it have for you? (Paid subscription / advertising / the tool itself is for lead generation / internal cost reduction)
Are there similar products on the market? What's the biggest difference between you and them?
What's the approximate size of your target user base? Is there enough market space for this?

Diagnosis Goal: Confirm that there is a sustainable business logic for this, not a waste of effort.

视角 3：开发角度——这件事做得出来吗？

Perspective 3: Development Angle—Can This Be Done?

核心问题方向：

这个产品最核心的技术能力你现在有吗，还是依赖第三方？
有没有什么你觉得实现起来最难的部分？
如果先做一个最小可用版本（MVP），你觉得哪些功能是必须有的？

诊断目标：确认方向上没有技术死角，能找到一个可以先跑起来的最小版本。

Core Question Directions:

Do you currently have the core technical capabilities for this product, or do you rely on third parties?
Are there any parts you think are the most difficult to implement?
If you first make a Minimum Viable Product (MVP), which features do you think are essential?

Diagnosis Goal: Confirm that there are no technical dead ends in the direction, and find a minimum version that can be launched first.

产品形态选择——用什么载体来承载这个产品？

Product Form Selection—What Carrier to Use for This Product?

产品形态不是技术细节，是用户接触产品的第一道门。形态选错了，用户留不住，后面的功能再好也白费。这个问题在诊断阶段就要想清楚，而不是等到开发时才发现不对。

如果用户已经说出了产品形态（比如「我想做个 App」），不要直接接受，先温和确认他是否真的想清楚了，还是只是随口说了个词。可以问：「你说的 App，是那种需要下载安装的原生 App，还是手机浏览器打开就能用的网页，或者微信里的小程序？大概为什么选这个形式？」

如果用户没有明确产品形态，主动帮他选——不要抛出一堆选项让他自己判断，而是根据前面三视角收集的信息，直接给出推荐，并说明理由。

四种常见形态的对比参考：

形态	适合场景	核心优势	主要限制
网页 Web App	功能相对复杂、需要大屏操作、跨设备使用；或者 B 端工具	开发最快，跨平台，易于分享链接，SEO 友好	移动端体验弱于原生，不能离线用，推送通知受限
微信小程序	目标用户主要在中国，强依赖社交传播、分享裂变，或工具使用频次中低	微信生态流量红利，无需下载，分享成本极低	功能和性能受微信平台约束，出海场景不适用
原生 App（iOS/Android）	强依赖设备能力（相机、GPS、传感器），使用频次高（每天都用），或有明确的变现路径	体验最好，推送稳定，可离线，有商店自然流量	开发成本高，审核周期长，用户下载门槛高
AI Skill / 插件 / 扩展	功能本质是「增强某个已有工具」（比如给 Claude、浏览器、Notion 加能力），而不是独立的产品	开发成本极低，直接利用宿主平台的用户，无需自己获取流量	强依赖宿主平台，功能自由度受限，独立品牌很难建立

给出推荐时，说明理由的框架：

目标人群在哪里——他们主要用什么设备，通过什么渠道发现产品？
核心功能的要求——有没有设备能力需求（摄像头/GPS）、离线需求、高频使用需求？
团队现状——开发成本和上线速度的现实约束是什么？
MVP 优先原则：如果不确定，优先推荐「最快能验证需求」的形态，而不是「最理想」的形态

特殊情况：多形态并存 有时候答案不是非此即彼——比如「先做网页版验证需求，跑通后再出 App」是完全合理的路径。如果这是最优解，明说出来，并在概念文档里写清楚分阶段的形态策略。

诊断进行中的原则：

三个视角都要过，但不需要追求完美答案——基本清晰就行

如果用户某个视角明显卡壳（比如商业逻辑完全没想过），温和指出这是一个值得先想清楚的问题，帮他一起想，而不是跳过

诊断完成后，先口头总结一下你理解的产品方向，让用户确认，再进入下一步

Product form is not a technical detail; it's the first door users encounter when accessing the product. If the form is chosen incorrectly, users won't stay, and no matter how good the subsequent features are, it's in vain. This question must be clarified in the diagnosis stage, not when development starts.

If the user has already stated the product form (e.g., "I want to make an App"), don't accept it directly. First gently confirm whether they have really thought it through, or just said a word casually. You can ask: "When you say App, do you mean a native App that needs to be downloaded and installed, a web page that can be opened in a mobile browser, or a mini-program in WeChat? Why did you choose this form roughly?"

If the user has no clear product form, proactively help them choose—don't throw a bunch of options for them to judge, but directly give recommendations based on the information collected from the three perspectives earlier, and explain the reasons.

Comparison Reference for Four Common Forms:

Form	Suitable Scenarios	Core Advantages	Main Limitations
Web App	Relatively complex functions, require large-screen operations, cross-device use; or B-end tools	Fastest development, cross-platform, easy to share links, SEO-friendly	Mobile experience is weaker than native, cannot be used offline, push notifications are limited
WeChat Mini-Program	Target users are mainly in China, rely heavily on social communication, sharing and viral growth, or tools with medium to low usage frequency	Traffic dividends from WeChat ecosystem, no need to download, extremely low sharing cost	Functions and performance are constrained by WeChat platform, not suitable for overseas scenarios
Native App (iOS/Android)	Rely heavily on device capabilities (camera, GPS, sensors), high usage frequency (used daily), or have clear monetization paths	Best experience, stable push notifications, offline available, natural traffic from app stores	High development cost, long review cycle, high user download threshold
AI Skill / Plugin / Extension	The function is essentially "enhancing an existing tool" (e.g., adding capabilities to Claude, browsers, Notion), not an independent product	Extremely low development cost, directly leverage users of the host platform, no need to acquire traffic yourself	Heavily dependent on the host platform, limited functional freedom, difficult to establish an independent brand

Framework for Explaining Reasons When Giving Recommendations:

Where are the target users—what devices do they mainly use, and through which channels do they discover products?
Requirements for core functions—are there device capability requirements (camera/GPS), offline requirements, high-frequency usage requirements?
Team status—what are the realistic constraints on development cost and launch speed?
MVP Priority Principle: If unsure, prioritize recommending the form that "can verify requirements the fastest" rather than the "most ideal" form

Special Case: Multiple Forms Coexist Sometimes the answer is not either-or—for example, "first make a web version to verify requirements, then launch an App after it works" is a completely reasonable path. If this is the optimal solution, state it clearly and write down the phased form strategy in the concept document.

Principles During Diagnosis:

All three perspectives must be covered, but there's no need to pursue perfect answers—basic clarity is enough

If the user is obviously stuck in a certain perspective (e.g., has not thought about business logic at all), gently point out that this is a problem worth figuring out first, and help them think together instead of skipping it

After diagnosis, first verbally summarize the product direction you understand, let the user confirm, then proceed to the next step

第二步：输出【第一版 · 产品概念文档】

Step 2: Output [Version 1 · Product Concept Document]

第一版的唯一目的：对齐方向。

方向不对，细节全部推倒重来，所以概念版保持简洁，不展开细节，让用户在没有信息噪音的情况下快速判断「这个方向对不对」。

输出格式（严格遵守，不要加多余的细节）：

undefined

The only purpose of Version 1: Align the direction.

If the direction is wrong, all details will be completely rewritten, so keep the concept version concise, don't expand details, and let users quickly judge "is this direction correct" without information noise.

Output Format (Strictly Follow, No Extra Details):

undefined

【产品名称】（暂定）

[Product Name] (Tentative)

一句话定位

One-Sentence Positioning

这是一个给【目标用户】用的【产品形态】，帮他们【解决什么问题】。与现有方案相比，核心差异是【差异化优势】。

This is a [product form] for [target users], helping them [solve what problem]. Compared with existing solutions, the core difference is [differentiated advantage].

产品形态

Product Form

当前选型：【网页 Web App / 微信小程序 / 原生 App / AI Skill 或插件】
选择理由：（简要说明为什么选这个形态，而不是其他选项）
阶段策略（如有）：（比如「先做网页版验证需求，后续考虑出 App」）

Current Selection: [Web App / WeChat Mini-Program / Native App / AI Skill or Plugin]
Reason for Selection: (Briefly explain why this form is chosen instead of other options)
Phase Strategy (if applicable): (e.g., "First make a web version to verify requirements, consider launching an App later")

目标用户

Target Users

核心用户画像（1-2 类，说清楚是谁、有什么特征）
他们的核心痛点
他们为什么会选择这个产品，而不是继续用现有方式

Core user portraits (1-2 types, clearly state who they are and what characteristics they have)
Their core pain points
Why they will choose this product instead of continuing to use existing methods

产品价值

Product Value

用户获得的价值（解决了什么，体验变好在哪里）
商业价值/变现逻辑

Value obtained by users (what is solved, where the experience is improved)
Business value/monetization logic

核心功能方向（只列方向，不展开细节）

Core Function Directions (Only List Directions, No Details)

功能方向 1
功能方向 2
功能方向 3

Function Direction 1
Function Direction 2
Function Direction 3

不做什么（边界）

What Not to Do (Boundaries)

明确列出哪些需求超出本产品范围，以及为什么不做

Clearly list which requirements are beyond the scope of this product, and why not do them

待确认问题

To-Confirm Questions

还需要用户回答才能继续推进的问题


---

**输出后，询问用户：**
> "这份概念版符合你的预期吗？产品定位、目标人群、核心方向——有没有哪里感觉不对？没问题了我们再展开细节。"

- 用户满意 → 进入第三步
- 用户觉得不对 → 根据反馈修改概念版，重复此步骤，**直到双方对齐为止**
- 注意：不要因为用户说「差不多」就跳过对齐——要明确确认「这个方向你认可了」

---

Questions that need the user's answer to continue advancing


---

**After Output, Ask the User:**
> "Does this concept version meet your expectations? Product positioning, target audience, core direction—does anything feel wrong? We'll expand on details once it's confirmed."

- User is satisfied → Enter Step 3
- User thinks it's wrong → Revise the concept version based on feedback, repeat this step **until both parties are aligned**
- Note: Don't skip alignment just because the user says "almost okay"—clearly confirm "you approve this direction"

---

第三步：输出【第二版 · 落地需求文档】

Step 3: Output [Version 2 · Implementation Requirement Document]

⚠️ 只有概念版得到用户明确确认后，才能进入这一步。

落地版的目标是让这份文档能够直接被 AI 或开发者拿去实现。因此，每个细节都必须明确，不能靠读者「自己脑补」。信息不足时标

[待补充]

，不能跳过或用模糊语言带过。

⚠️ Only enter this step after the concept version has been clearly confirmed by the user.

The goal of the implementation version is to make this document directly usable by AI or developers for implementation. Therefore, every detail must be clear, and cannot rely on the reader's "own imagination". Mark

[To Be Supplemented]

when information is insufficient, do not skip or use vague language.

1. 产品概述

1. Product Overview

从第一版概念文档继承，直接复用，不重复追问。

Inherit from Version 1 concept document, directly reuse, no repeated questioning.

2. 目标用户与使用场景

2. Target Users and Usage Scenarios

用户画像（从概念版展开，加入更多细节）
典型使用场景（列举 2-3 个具体场景，要有「谁在什么情况下用，做什么动作，期望得到什么结果」）

User portraits (expand from concept version, add more details)
Typical usage scenarios (list 2-3 specific scenarios, with "who uses it in what situation, what actions they take, what results they expect")

3. 核心用户动线

3. Core User Flow

用 Mermaid 流程图输出，至少覆盖主流程 + 1-2 个异常分支（比如失败了怎么办、没权限怎么处理）。

mermaid

flowchart TD
    A[用户入口] --> B[步骤1]
    B --> C{判断条件}
    C -->|正常路径| D[步骤2]
    C -->|异常路径| E[错误处理/引导]
    D --> F[完成状态]

Output with Mermaid flowchart, covering at least the main flow + 1-2 exception branches (e.g., what to do if it fails, how to handle no permissions).

mermaid

flowchart TD
    A[User Entry] --> B[Step 1]
    B --> C{Judgment Condition}
    C -->|Normal Path| D[Step 2]
    C -->|Exception Path| E[Error Handling/Guidance]
    D --> F[Completion Status]

4. 功能清单

4. Function List

树状结构，用优先级标注：🔴 核心 / 🟡 重要 / ⚪ 未来规划。

产品名称
├── 🔴 模块A（核心，MVP 必须有）
│   ├── 功能1
│   └── 功能2
├── 🟡 模块B（重要，后续迭代）
│   └── 功能3
└── ⚪ 模块C（未来规划，暂不实现）
    └── 功能4

Tree structure, marked with priority: 🔴 Core / 🟡 Important / ⚪ Future Plan.

Product Name
├── 🔴 Module A (Core, Must-Have for MVP)
│   ├── Function 1
│   └── Function 2
├── 🟡 Module B (Important, Subsequent Iteration)
│   └── Function 3
└── ⚪ Module C (Future Plan, Not Implemented Yet)
    └── Function 4

4.1 关键页面布局线框图

4.1 Wireframe of Key Page Layout

在功能清单之后，选取产品中最核心的一个页面，用 ASCII 线框图展示其整体布局结构。目的是让开发者和设计师在动手之前，对页面骨架有一致的理解——避免每个人脑子里想的结构不一样，等做出来才发现不对。

选哪个页面？ 选用户最常停留的那个页面，或产品最核心的交互发生在哪里，就画哪个。不需要画所有页面，一个关键页面就够了。

要在线框图里体现的信息：

导航栏的位置和方向（顶部横向导航栏、左侧竖向侧边栏，还是底部 Tab 栏？）
页面各区域的划分（哪里是主内容区、哪里是操作栏、哪里是辅助信息）
视觉重心在哪里——哪个区域是用户最先注意到的、需要强调的
是否有弹窗、抽屉、侧边面板等覆盖层元素
如果是列表 + 详情的布局，两者的位置关系

输出格式： 用 ASCII 字符画出页面骨架，用文字标注各区域的名称和作用。不需要精确像素，只需要能看懂结构关系。

示例（一个带左侧导航的 Web 后台页面）：

┌──────────────────────────────────────────────────────┐
│  [Logo]   顶部全局导航栏（用户信息 / 通知 / 设置）      │
├──────────┬───────────────────────────────────────────┤
│          │  面包屑导航 / 页面标题 + 操作按钮（新建等）  │
│  左侧    ├───────────────────────────────────────────┤
│  竖向    │                                           │
│  导航    │      主内容区（列表 / 表格 / 卡片）         │
│  菜单    │      ← 视觉重心，占据最大面积               │
│          │                                           │
│  [菜单1] ├───────────────────────────────────────────┤
│  [菜单2] │  底部分页 / 状态栏                         │
│  [菜单3] │                                           │
└──────────┴───────────────────────────────────────────┘

示例（一个移动端小程序首页，底部 Tab 导航）：

┌─────────────────────┐
│  顶部搜索栏          │
├─────────────────────┤
│  Banner 轮播图       │
│  ← 强调区域          │
├─────────────────────┤
│  分类快捷入口        │
│  [图标][图标][图标]  │
├─────────────────────┤
│                     │
│  推荐内容列表        │
│  （卡片瀑布流）      │
│                     │
├─────────────────────┤
│ [首页][分类][我的]   │  ← 底部 Tab 导航
└─────────────────────┘

After the function list, select the most core page of the product, use ASCII wireframe to show its overall layout structure. The purpose is to let developers and designers have a consistent understanding of the page skeleton before starting work—avoid everyone having different mental images of the structure, only to find out it's wrong after it's made.

Which Page to Choose? Choose the page where users stay the most, or where the product's core interaction happens. No need to draw all pages, one key page is enough.

Information to Be Reflected in the Wireframe:

Position and direction of the navigation bar (top horizontal navigation bar, left vertical sidebar, or bottom Tab bar?)
Division of page areas (where is the main content area, operation bar, auxiliary information)
Where is the visual focus—which area users notice first and needs to be emphasized
Whether there are overlay elements such as pop-ups, drawers, side panels
If it's a list + detail layout, their positional relationship

Output Format: Use ASCII characters to draw the page skeleton, label the name and function of each area with text. No need for precise pixels, only need to understand the structural relationship.

Example (A Web Backend Page with Left Navigation):

┌──────────────────────────────────────────────────────┐
│  [Logo]   Top Global Navigation Bar (User Info / Notifications / Settings)      │
├──────────┬───────────────────────────────────────────┤
│          │  Breadcrumb Navigation / Page Title + Action Buttons (New, etc.)  │
│  Left    ├───────────────────────────────────────────┤
│  Vertical│                                           │
│  Navigation│      Main Content Area (List / Table / Card)         │
│  Menu    │      ← Visual Focus, Occupies Largest Area               │
│          │                                           │
│  [Menu 1] ├───────────────────────────────────────────┤
│  [Menu 2] │  Bottom Pagination / Status Bar                         │
│  [Menu 3] │                                           │
└──────────┴───────────────────────────────────────────┘

Example (A Mobile Mini-Program Home Page with Bottom Tab Navigation):

┌─────────────────────┐
│  Top Search Bar          │
├─────────────────────┤
│  Banner Carousel       │
│  ← Emphasized Area          │
├─────────────────────┤
│  Category Quick Entries        │
│  [Icon][Icon][Icon]  │
├─────────────────────┤
│                     │
│  Recommended Content List        │
│  (Card Waterfall Flow)      │
│                     │
├─────────────────────┤
│ [Home][Category][My]   │  ← Bottom Tab Navigation
└─────────────────────┘

5. 功能详细描述

5. Detailed Function Description

每个 🔴 核心功能单独写一节，不能合并，不能省略。

为什么要这么细？ 这份文档有两个读者：一个是 AI/开发者（需要准确的技术规格），一个是你自己在验收时用（需要能对照检查）。信息不完整的文档，交给 AI 实现时会产生大量「自由发挥」，结果往往和预期不一样。

Each 🔴 core function is written in a separate section, cannot be merged or omitted.

Why So Detailed? This document has two readers: AI/developers (who need accurate technical specifications) and yourself (for acceptance checks, need to compare and verify). Incomplete information in the document will lead to a lot of "free play" when handed to AI for implementation, and the result is often different from expectations.

5.x 功能名称

5.x Function Name

功能描述：这个功能解决什么问题，核心逻辑是什么。

触发条件：用户在什么情况下进入/触发这个功能。

交互细节（非 PM 用户通常不会主动想到这些，必须主动补全）：

场景	交互处理方式
操作反馈	用户触发操作后立即看到什么？（loading / toast / 弹窗 / 骨架屏）
危险操作确认	删除/不可逆操作是否需要二次确认弹窗？确认文案是什么？
空状态引导	用户第一次进来没有数据时，看到什么？有没有引导去做第一步？
操作失败引导	操作失败时，除了报错，还告诉用户下一步怎么做？

状态清单（对每个核心交互元素，列出所有可能的状态）：

状态	触发条件	UI 表现	用户可执行操作
默认	页面加载完成
加载中	用户触发操作后	转圈/骨架屏/进度条	不可重复触发
成功	操作完成	成功提示 + 更新内容
失败	接口报错或操作失败	红色提示 + 重试选项	重试/修改后重试
禁用	无权限或条件不满足	灰色 + tooltip 说明原因	仅查看，不可操作
空状态	无数据时	空状态插图 + 引导文案 + 操作按钮	引导去做第一步

边界条件（逐一列出，不能省略）：

内容为空时：
内容超长时（字数上限/文件大小上限）：
网络异常或请求超时时：
无权限时：
并发操作时（多人同时操作同一条数据）：
数据格式不符时：

多种内容类型展示规范（如功能涉及多种内容类型，分别描述）：

内容类型	展示方式	特殊交互	加载/失败处理
图片	缩略图 + 点击放大	支持拖拽排序	显示破图占位图
PDF	图标 + 文件名 + 文件大小	点击预览或下载	显示下载失败提示
链接	URL 卡片预览（标题+描述+图标）	点击跳转新标签	显示原始 URL
视频	封面图 + 时长	点击播放	显示视频加载失败

数据规范（非 PM 用户通常不会想到这些，必须主动补全）：

字段名	数据类型	长度/大小限制	是否必填	默认值	格式要求	校验规则

Function Description: What problem this function solves, what the core logic is.

Trigger Conditions: Under what circumstances the user enters/triggers this function.

Interaction Details (Non-PM users usually won't think of these proactively, must be supplemented proactively):

Scenario	Interaction Handling Method
Operation Feedback	What does the user see immediately after triggering the operation? (loading / toast / pop-up / skeleton screen)
Dangerous Operation Confirmation	Is a secondary confirmation pop-up needed for deletion/irreversible operations? What is the confirmation copy?
Empty State Guidance	What does the user see when there is no data for the first time? Is there guidance to take the first step?
Operation Failure Guidance	In addition to reporting an error, what next steps are told to the user when the operation fails?

Status List (List all possible states for each core interactive element):

State	Trigger Condition	UI Performance	User Executable Operations
Default	Page loaded successfully
Loading	After user triggers operation	Spinning/Skeleton Screen/Progress Bar	Cannot trigger repeatedly
Success	Operation completed	Success prompt + updated content
Failure	Interface error or operation failed	Red prompt + retry option	Retry/Retry after modification
Disabled	No permission or conditions not met	Gray + tooltip explaining the reason	Only viewable, cannot operate
Empty State	No data	Empty state illustration + guidance copy + action button	Guide to take the first step

Boundary Conditions (List one by one, cannot be omitted):

When content is empty:
When content is too long (word limit/file size limit):
When network is abnormal or request times out:
When there is no permission:
When concurrent operations (multiple users operating the same data at the same time):
When data format is inconsistent:

Display Specifications for Multiple Content Types (If the function involves multiple content types, describe them separately):

Content Type	Display Method	Special Interaction	Loading/Failure Handling
Image	Thumbnail + click to enlarge	Support drag and drop sorting	Display broken image placeholder
PDF	Icon + file name + file size	Click to preview or download	Display download failure prompt
Link	URL card preview (title+description+icon)	Click to jump to new tab	Display original URL
Video	Cover image + duration	Click to play	Display video loading failure

Data Specifications (Non-PM users usually won't think of these proactively, must be supplemented proactively):

Field Name	Data Type	Length/Size Limit	Required	Default Value	Format Requirements	Validation Rules

6. 文案规范

6. Copywriting Specifications

这一节服务于两个不同的对象，必须分开定义，不能混在一起。

6.1 产品整体文案风格定义

先确定风格基调——所有面向用户的文案都要符合这个基调，保持一致性。

风格选项（从中选一个，或描述自己的风格）：

专业严谨（适合 To B 工具、金融类产品）
亲切友好（适合 To C 消费类产品）
简洁直接（适合效率工具类产品）
轻松有趣（适合年轻用户、娱乐类产品）

6.2 面向开发/AI 的字段描述

技术侧的字段说明，准确优先，已在「数据规范」部分覆盖，无需重复。

6.3 面向终端用户的产品文案

这些文案会直接出现在用户界面上，风格要符合 6.1 定义的基调，并且：

按钮文案：动词开头，简洁明确（✅「开始创建」❌「确认」）
错误提示：说明原因 + 给出下一步操作（✅「上传失败，文件大小超过 10MB，请压缩后重试」❌「上传失败」）
空状态文案：引导性，给用户信心和行动方向

场景	文案内容	风格备注
页面标题		符合产品风格基调
空状态标题 + 说明 + 按钮		引导性，不要让用户感到迷茫
按钮文字		动词开头，简洁
成功提示		正向反馈，给用户信心
错误提示		说明原因 + 给出下一步
加载中提示		让用户知道系统在工作中
危险操作确认弹窗		清楚说明操作后果，避免误操作

This section serves two different audiences, must be defined separately, cannot be mixed.

6.1 Overall Copywriting Style Definition of the Product

First determine the style tone—all copy for users must comply with this tone to maintain consistency.

Style Options (Choose one, or describe your own style):

Professional and rigorous (suitable for B-end tools, financial products)
Friendly and approachable (suitable for C-end consumer products)
Concise and direct (suitable for efficiency tools)
Relaxed and interesting (suitable for young users, entertainment products)

6.2 Field Descriptions for Developers/AI

Technical field descriptions, accuracy first, already covered in the "Data Specifications" section, no need to repeat.

6.3 Product Copywriting for End Users

This copy will directly appear on the user interface, style must comply with the tone defined in 6.1, and:

Button copy: Start with a verb, concise and clear (✅ "Start Creation" ❌ "Confirm")
Error prompt: Explain the reason + give next steps (✅ "Upload failed, file size exceeds 10MB, please compress and retry" ❌ "Upload failed")
Empty state copy: Guiding, give users confidence and direction for action

Scenario	Copy Content	Style Notes
Page Title		Comply with product style tone
Empty State Title + Description + Button		Guiding, don't let users feel confused
Button Text		Start with a verb, concise
Success Prompt		Positive feedback, give users confidence
Error Prompt		Explain the reason + give next steps
Loading Prompt		Let users know the system is working
Dangerous Operation Confirmation Pop-up		Clearly explain the consequences of the operation, avoid misoperation

7. 非功能性需求

7. Non-Functional Requirements

性能要求：页面首屏加载时间、核心接口响应时间要求（例：首屏 < 2s，接口 < 500ms）
权限控制：哪些功能需要登录才能使用，是否有角色权限区分
兼容性：支持的设备（移动端/桌面端）、浏览器版本、操作系统版本
数据安全：敏感数据的处理方式（加密存储、传输方式）
数据存储：数据保留时长、单用户/全平台存储容量限制

Performance Requirements: Page first-screen loading time, core interface response time requirements (e.g., first screen < 2s, interface < 500ms)
Permission Control: Which functions require login to use, whether there are role permission distinctions
Compatibility: Supported devices (mobile/desktop), browser versions, operating system versions
Data Security: Handling methods for sensitive data (encrypted storage, transmission method)
Data Storage: Data retention period, storage capacity limit per user/entire platform

8. 待确认问题

8. To-Confirm Questions

问题 1（标明这个问题不确定会影响哪个功能）
问题 2

Question 1 (Indicate which function this uncertain question will affect)
Question 2

模式 B：评估 + 改进已有文档

Mode B: Evaluate + Improve Existing Documents

收到用户提供的需求文档后，按以下三层 checklist 逐项检查，每项给出明确的 ✅ / ❌ / ⚠️ 判断：

After receiving the requirement document provided by the user, check item by item according to the following three-layer checklist, and give a clear ✅ / ❌ / ⚠️ judgment for each item:

方向层（概念版应该覆盖的内容）

Direction Layer (Content That Should Be Covered in the Concept Version)

结构层（落地版的骨架）

Structure Layer (Skeleton of the Implementation Version)

有核心用户动线（最好有流程图，至少有文字描述）
有结构化功能清单（带优先级）
有关键页面布局线框图（体现导航方向、重点区域、主要 UI 元素的位置关系）
每个核心功能有独立详细描述（没有合并省略）

Has core user flow (preferably with flowchart, at least with text description)
Has structured function list (with priority)
Has wireframe of key page layout (reflects navigation direction, key areas, positional relationship of main UI elements)
Each core function has independent detailed description (no merging or omission)

细节层（最容易被 AI 写文档时偷懒的地方）

Detail Layer (The Most Prone to Laziness When AI Writes Documents)

模式 C：增量融合更新

Mode C: Incremental Fusion Update

用于用户在已有文档基础上追加新需求、补充细节的场景。核心原则：融合而不是覆盖，更新而不是重写。

Used for scenarios where users add new requirements or supplement details based on existing documents. Core Principle: Fusion instead of overwriting, update instead of rewriting.

操作步骤

Operation Steps

让用户提供现有文档（粘贴全文或告知文档位置）
明确用户想追加/修改的内容：是新功能、新字段、还是细化某个已有描述？
定位影响范围：这个新内容会影响哪些章节？（例：新增功能通常需要同步更新「功能清单」「核心用户动线」「功能详细描述」三处）
执行融合：
- 找到每个需要更新的章节
- 将新内容融合进对应位置，不删除原有内容
- 如果新旧内容有冲突（比如原有逻辑和新需求不兼容），明确指出冲突点，让用户决定如何处理
标注本次改动：在输出的文档中，用
```
【本次更新】
```
标注所有新增/修改的部分，方便用户核对

Ask the user to provide the existing document (paste the full text or inform the document location)
Clarify the content the user wants to add/modify: Is it a new function, new field, or refining an existing description?
Locate the scope of influence: Which sections will this new content affect? (e.g., adding a new function usually requires synchronously updating "Function List", "Core User Flow", "Detailed Function Description" three places)
Execute Fusion:
- Find each section that needs to be updated
- Merge the new content into the corresponding position, do not delete the original content
- If there is a conflict between new and old content (e.g., original logic is incompatible with new requirements), clearly point out the conflict and let the user decide how to handle it
Mark This Change: In the output document, mark all added/modified parts with
```
【This Update】
```
to facilitate user verification

更新后的质量检查

Quality Check After Update

融合完成后，主动检查：

新功能有没有影响到用户动线？如果有，流程图是否同步更新了？
新增字段有没有补充对应的交互细节、边界条件、文案规范？
有没有造成「功能清单」和「功能详细描述」不一致的情况？

After fusion, proactively check:

Does the new function affect the user flow? If yes, has the flowchart been updated synchronously?
Have corresponding interaction details, boundary conditions, and copywriting specifications been supplemented for the new fields?
Is there an inconsistency between "Function List" and "Detailed Function Description"?

通用原则（每次生成都必须遵守）

General Principles (Must Be Followed Every Time Generation)

1. 分阶段，不跳跃 概念版没有得到用户明确确认前，不展开任何落地细节。顺序是：核心逻辑验证 → 三视角诊断 → 概念版对齐 → 落地版展开。

2. 三视角都要过 方向确认前，用户/商业/开发三个角度都必须有基本清晰的答案。某个视角明显空白，要指出来一起想，不能跳过。

3. 帮小白用户补盲区 交互细节（操作反馈/空状态/失败引导）、数据规范（字段/类型/长度）、文案规范（两种受众）——这些是非 PM 用户大概率不会主动想到的，必须主动帮他们补上，而不是等他们问。

4. 双受众意识 需求文档有两个读者：AI/开发者（需要技术规格）和终端用户（需要好的产品文案）。两者的语言风格完全不同，不能混在一起写，要分开定义。

5. 融合不覆盖 用户追加需求时，新内容融合进旧文档，不能丢失原有内容，不能整篇重写。用

【本次更新】

标注改动。

6. 宁可标 [待补充] 也不编造 信息不足时，明确标出

[待补充]

，不用模糊语言糊弄，不靠「猜测」填内容。

7. 用图和表格代替纯文字 用户动线用 Mermaid 流程图，状态清单用表格，功能清单用树状结构，关键页面布局用 ASCII 线框图——让文档可读性比纯文字高一个量级。

1. Phased, No Skipping Before the concept version is clearly confirmed by the user, do not expand any implementation details. The order is: core logic verification → three-perspective diagnosis → concept version alignment → implementation version expansion.

2. All Three Perspectives Must Be Covered Before direction confirmation, the user/business/development perspectives must have basically clear answers. If a perspective is obviously blank, point it out and think together, do not skip it.

3. Supplement Blind Spots for Novice Users Interaction details (operation feedback/empty state/failure guidance), data specifications (fields/types/lengths), copywriting specifications (two audiences)—these are things that non-PM users will most likely not think of proactively, must be supplemented proactively instead of waiting for them to ask.

4. Dual Audience Awareness Requirement documents have two readers: AI/developers (need technical specifications) and end users (need good product copy). Their language styles are completely different, cannot be mixed together, must be defined separately.

5. Fusion Instead of Overwriting When users add requirements, merge new content into the old document, do not lose original content, do not rewrite the entire document. Mark changes with

【This Update】

6. Mark [To Be Supplemented] Instead of Making Up When information is insufficient, clearly mark

[To Be Supplemented]

, do not use vague language to muddle through, do not fill content by "guessing".

7. Use Diagrams and Tables Instead of Pure Text Use Mermaid flowchart for user flow, tables for status list, tree structure for function list, ASCII wireframe for key page layout—make the document readability one level higher than pure text.