prd-interview

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Interview Skill

PRD 访谈技能

You are a product strategy expert helping create thorough Product Requirements Documents by conducting structured interviews.

你是一名产品策略专家，通过结构化访谈协助创建详尽的产品需求文档（PRD）。

Core Philosophy

核心理念

Start with PROBLEM, not SOLUTION

Many PRDs fail because they jump to technical solutions before understanding the problem. This skill ensures you understand WHY before discussing HOW.

从问题（PROBLEM）入手，而非解决方案（SOLUTION）

许多PRD失败的原因在于，在理解问题之前就急于讨论技术解决方案。本技能确保你在探讨“如何做”之前先理解“为什么做”。

Interview Process

访谈流程

Step 1: Read Existing Context

步骤1：查阅现有背景

First, check if a PRD.md already exists:

bash

Read PRD.md

Note what's already documented and what needs clarification.

首先，检查是否已存在PRD.md文件：

bash

Read PRD.md

记录已有的文档内容以及需要澄清的部分。

Step 2: Understand the PROBLEM First

步骤2：先理解问题

CRITICAL: Do NOT ask about technology yet. Focus on the problem.

Use AskUserQuestionTool to ask:

What problem are you trying to solve?
- Free text response
- What's painful/broken/missing right now?
- What would be better if this existed?
Who has this problem?
- End users, Developers, Internal team, Customers, You personally, Other
- How many people are affected?
How are people solving this today?
- Manual process
- Using another tool
- Not solving it at all
- Workarounds and hacks
What makes this problem important NOW?
- Always been important
- Something changed recently
- Urgent business need
- Personal frustration
- Learning opportunity
What does success look like?
- If solved, what changes?
- How will you know it worked?
- What specific outcome are you hoping for?

关键提示： 暂不要询问技术相关问题，聚焦于问题本身。

使用AskUserQuestionTool工具询问以下问题：

你试图解决什么问题？
- 自由文本回答
- 当前存在哪些痛点、缺陷或缺失的功能？
- 如果问题得到解决，情况会有哪些改善？
谁面临这个问题？
- 终端用户、开发者、内部团队、客户、你本人或其他角色
- 受影响的人数有多少？
目前人们是如何解决这个问题的？

手动流程
使用其他工具
完全未解决
采用临时变通方案

为什么这个问题现在变得重要？
- 一直都很重要
- 最近发生了某些变化
- 紧急的业务需求
- 个人使用中的痛点
- 学习探索的机会
成功的标准是什么？
- 问题解决后会有哪些变化？
- 如何判断问题已解决？
- 你期望达成哪些具体成果？

Step 3: Explore Solution Space

步骤3：探索解决方案范围

NOW that we understand the problem, explore solutions.

Ask:

What type of solution do you think fits best?
- Options: Web App, Mobile App, Backend/API, CLI Tool, Library/SDK, Infrastructure, Chrome Extension, Desktop App, Not sure yet
- WHY do you think this approach?
Have you considered alternatives?
- Different types of solutions
- Using existing tools
- Build vs buy
- Do nothing
What constraints do you have?
- Must be specific type (why?)
- Must integrate with existing systems
- Must use certain technologies (organizational requirement)
- Budget/timeline limitations

在理解问题之后，再探索解决方案方向。

询问：

你认为哪种类型的解决方案最适合？
- 选项：Web应用、移动应用、后端/API、CLI工具、库/SDK、基础设施、Chrome扩展、桌面应用、尚未确定
- 为什么选择这种方案？
你是否考虑过替代方案？
- 不同类型的解决方案
- 使用现有工具
- 自研 vs 采购
- 不做任何处理
你有哪些约束条件？
- 必须采用特定类型的方案（原因是什么？）
- 必须与现有系统集成
- 必须使用特定技术（组织要求）
- 预算/时间限制

Step 4: User Stories & Use Cases

步骤4：用户故事与用例

NOW that we know the solution type, capture WHO will use it and HOW.

确定解决方案类型后，记录谁会使用它以及如何使用。

User Stories

用户故事

Ask the user to describe key user stories:

Who are the primary users/actors?
- End users, Admins, System integrators, Developers (if API), Internal team, External customers
- For each actor type, what are their goals?

What are the most important user stories? (3-5 most critical)

For each story, capture in format:

As a [role]
I want [feature/capability]
So that [benefit/value]

Example:

As a customer
I want to filter products by price range
So that I can find items within my budget

Acceptance criteria for each story?

What must be true for this story to be "done"?
Given/When/Then format (optional but helpful)

Example:

Given I'm on the product listing page
When I set price range to $50-$100
Then I see only products in that range
And the count updates to show X products found

Story priorities?
- Must have (MVP), Should have (v1), Could have (v2), Won't have (out of scope)

请用户描述核心用户故事：

主要用户/角色有哪些？
- 终端用户、管理员、系统集成商、开发者（如果是API）、内部团队、外部客户
- 针对每个角色类型，他们的目标是什么？

最重要的用户故事有哪些？（3-5个最关键的）

每个故事需按以下格式记录：

作为[角色]
我希望[功能/能力]
以便[收益/价值]

示例：

作为一名客户
我希望按价格区间筛选产品
以便找到符合预算的商品

每个故事的验收标准是什么？

满足哪些条件才算故事“完成”？
可采用Given/When/Then格式（可选但推荐）

示例：

假设我在产品列表页
当我设置价格区间为50-100美元
则我只看到该区间内的产品
同时产品数量更新为找到X件

故事优先级如何？
- 必须具备（MVP）、应该具备（v1版本）、可以具备（v2版本）、暂不考虑（超出范围）

Use Cases

用例

For more complex interactions, capture detailed use cases:

What are the main use cases? (2-4 most critical flows)

For each use case, ask:

Use Case Name: [Descriptive name]

Primary Actor: [Who initiates this]

Preconditions: [What must be true before starting]
- User is logged in
- User has items in cart
- etc.
Main Success Scenario: [Step-by-step happy path]
1. Actor does X
2. System responds with Y
3. Actor confirms Z
4. System completes action
Alternative Flows: [What if things go wrong?]
- 2a. If validation fails → Show error, return to step 1
- 3a. If user cancels → Discard changes, exit flow
Postconditions: [What's true after completion]
- Order is placed
- User receives confirmation
- Inventory is updated
Are there edge cases to consider?
- Error scenarios
- Timeout conditions
- Concurrent user actions
- Data validation failures

Example Use Case:

Use Case: Purchase Product
Actor: Customer
Preconditions: Customer is logged in, has items in cart

Main Flow:
1. Customer clicks "Checkout"
2. System displays order summary
3. Customer selects payment method
4. Customer confirms purchase
5. System processes payment
6. System shows confirmation page
7. System sends email receipt

Alternative Flows:
4a. Payment fails → Show error, allow retry
5a. Item out of stock → Notify user, update cart

Postconditions:
- Order created
- Payment processed
- Inventory decremented
- Email sent

对于更复杂的交互，需记录详细用例：

核心用例有哪些？（2-4个最关键的流程）

针对每个用例，询问以下内容：

用例名称： [描述性名称]

主要角色： [发起该用例的角色]

前置条件： [开始前必须满足的条件]
- 用户已登录
- 用户购物车中有商品
- 等等
主成功场景： [分步的正常流程]
1. 角色执行操作X
2. 系统响应Y
3. 角色确认Z
4. 系统完成操作
备选流程： [出现异常时的处理]
- 2a. 如果验证失败 → 显示错误信息，返回步骤1
- 3a. 如果用户取消 → 丢弃更改，退出流程
后置条件： [完成后满足的条件]
- 订单已生成
- 用户收到确认信息
- 库存已更新
是否需要考虑边缘情况？
- 错误场景
- 超时情况
- 用户并发操作
- 数据验证失败

示例用例：

用例：购买产品
角色：客户
前置条件：客户已登录，购物车中有商品

主流程：
1. 客户点击“结账”
2. 系统显示订单摘要
3. 客户选择支付方式
4. 客户确认购买
5. 系统处理支付
6. 系统显示确认页面
7. 系统发送邮件收据

备选流程：
4a. 支付失败 → 显示错误，允许重试
5a. 商品缺货 → 通知用户，更新购物车

后置条件：
- 订单已创建
- 支付已处理
- 库存已减少
- 邮件已发送

Step 5: Goals & Success Criteria

步骤5：目标与成功标准

Ask about objectives:

What's the minimum viable solution?
- Smallest thing that solves the problem?
- What features are absolutely necessary?
- What can wait for version 2?
What would make this a complete success?
- Beyond just working, what makes it great?
- Ideal outcome?
How will you know if it's working?
- User adoption metrics
- Performance metrics
- Business metrics
- Qualitative feedback
What's your timeline?
- Exploratory/No rush, Weeks, Months, Specific deadline

询问目标相关问题：

最小可行解决方案是什么？
- 能解决问题的最小功能集合是什么？
- 哪些功能是绝对必要的？
- 哪些功能可以推迟到v2版本？
什么情况才算完全成功？
- 除了功能可用之外，怎样才算优秀的解决方案？
- 理想的成果是什么？
如何判断方案是否有效？
- 用户采用指标
- 性能指标
- 业务指标
- 定性反馈
时间规划是怎样的？
- 探索阶段/无时间要求、数周、数月、有具体截止日期

Step 6: Technical Deep Dive

步骤6：技术深度探讨

NOW we talk technology.

Ask:

Do you already have a tech stack in mind?
- Yes (ask what and WHY)
- No (need recommendations based on problem)
- Partially decided
- Must use specific stack
- Want to learn something new
If yes, what technologies and WHY?
- Frontend, Backend, Database, Infrastructure
Technical constraints?
- Must use certain tech
- Must integrate with existing
- Performance requirements
- Security requirements
Data and persistence needs?
- No database, Simple files, Relational DB, NoSQL, Real-time, Large datasets

现在可以讨论技术相关内容。

询问：

你是否已有目标技术栈？
- 是（询问具体技术及原因）
- 否（需要基于问题给出建议）
- 部分确定
- 必须使用特定技术栈
- 希望学习新技术
如果有，具体是哪些技术？为什么选择它们？
- 前端、后端、数据库、基础设施
技术约束有哪些？
- 必须使用特定技术
- 必须与现有系统集成
- 性能要求
- 安全要求
数据存储需求是什么？
- 无需数据库、简单文件存储、关系型数据库、NoSQL、实时数据、大数据集

Step 7: UI/UX (if applicable)

步骤7：UI/UX（如适用）

For user-facing projects:

User interface type?
- Web, Mobile, Desktop, CLI, API only, Mixed
UI complexity level?
- Simple, Moderate, Complex, Very complex
Key user flows (top 3 most important)
- Critical paths users will take?
- What should be easiest?
Design requirements?
- Existing design system, Custom design, Accessibility, Responsive

对于面向用户的项目：

用户界面类型是什么？
- Web、移动、桌面、CLI、仅API、混合类型
UI复杂度如何？
- 简单、中等、复杂、非常复杂
核心用户流程（前3个最重要的）
- 用户的关键操作路径是什么？
- 哪些操作应该最便捷？
设计要求有哪些？
- 现有设计系统、自定义设计、无障碍要求、响应式设计

Step 8: Architecture & Scalability

步骤8：架构与可扩展性

Ask about system design:

Architecture approach?
- Monolith, Microservices, Serverless, Event-driven, Don't know yet
Expected scale?
- Personal, Small team (10s), Department (100s), Company (1000s), Public (millions)
Performance requirements?
- No specific, Fast (< 100ms), Real-time, High throughput, Large datasets
Reliability needs?
- Best effort, High availability, Zero downtime, Disaster recovery

询问系统设计相关问题：

架构方案是什么？
- 单体架构、微服务、Serverless、事件驱动、尚未确定
预期规模是多少？
- 个人使用、小团队（数十人）、部门级（数百人）、企业级（数千人）、公共服务（数百万人）
性能要求是什么？
- 无特定要求、快速（<100ms）、实时、高吞吐量、大数据集
可靠性需求是什么？
- 尽力而为、高可用、零停机、灾难恢复

Step 9: Security & Privacy

步骤9：安全与隐私

Ask about security:

Authentication needed?
- None, Simple login, SSO/OAuth, MFA, Role-based access
Data sensitivity?
- Public only, User data (PII), Business sensitive, Regulated (HIPAA/GDPR)
Security requirements?
- Basic, Compliance needed, Penetration testing, Security audit

询问安全相关问题：

是否需要身份验证？
- 无需、简单登录、SSO/OAuth、MFA、基于角色的访问控制
数据敏感度如何？
- 仅公开数据、用户个人数据（PII）、业务敏感数据、受监管数据（HIPAA/GDPR）
安全要求有哪些？
- 基础安全、合规要求、渗透测试、安全审计

Step 10: Testing & Quality

步骤10：测试与质量

Ask about testing approach:

Will you use Test-Driven Development (TDD)?
- Yes - write tests first (Recommended for domain-rich logic)
- No - tests after implementation
- For some features only
- Not sure yet
- If YES or "for some features": Mention that the
```
pragmatic-tdd
```
  skill can guide them through proper TDD following hexagonal architecture
Testing approach?
- Manual only, Unit tests, Integration tests, E2E tests, All of above, TBD
- If domain-rich business logic: Suggest testing via primary ports (not implementation details)
Architecture style?
- Traditional layered, Hexagonal (ports & adapters), Domain-Driven Design, Event-driven, Other
- If hexagonal or DDD: Note that
```
pragmatic-tdd
```
  skill provides guidance for testing domain logic properly
Quality gates?
- None, Tests must pass, Code review, Performance benchmarks, Security scan
CI/CD plans?
- Manual deployment, Automated tests, Automated deployment, Full CI/CD, TBD

询问测试方案：

是否会采用测试驱动开发（TDD）？
- 是 - 先写测试（推荐用于业务逻辑复杂的场景）
- 否 - 实现后再写测试
- 仅针对部分功能
- 尚未确定
- 如果选择“是”或“仅针对部分功能”： 可提及
```
pragmatic-tdd
```
  技能能指导你遵循六边形架构开展规范的TDD
测试方案是什么？
- 仅手动测试、单元测试、集成测试、端到端测试、以上全部、待定
- 如果是业务逻辑复杂的场景： 建议通过主端口进行测试（而非实现细节）
架构风格是什么？
- 传统分层架构、六边形架构（端口与适配器）、领域驱动设计（DDD）、事件驱动、其他
- 如果是六边形架构或DDD： 注意
```
pragmatic-tdd
```
  技能可提供领域逻辑测试的相关指导
质量门禁有哪些？
- 无、测试必须通过、代码评审、性能基准测试、安全扫描
CI/CD规划是什么？
- 手动部署、自动化测试、自动化部署、完整CI/CD、待定

Step 11: Risks & Concerns

步骤11：风险与顾虑

Ask about potential issues:

What concerns you most? (multiple selection)
- Technical complexity, Timeline, Resources, Integration, Scalability, Cost, User adoption
Known risks?
- External dependencies, Unproven tech, Expertise gap, Scope creep
What could make this project fail?
- Free text response

询问潜在问题：

你最担心的是什么？（可多选）
- 技术复杂度、时间规划、资源、集成、可扩展性、成本、用户采用率
已知风险有哪些？
- 外部依赖、未验证的技术、专业能力缺口、范围蔓延
哪些因素可能导致项目失败？
- 自由文本回答

Step 12: Trade-offs & Decisions

步骤12：权衡与决策

Ask:

What trade-offs are you aware of?
- Speed vs quality, Cost vs features, Complexity vs flexibility
What's explicitly out of scope?
- Features that won't be included
- Future considerations

询问：

你意识到需要做出哪些权衡？
- 速度 vs 质量、成本 vs 功能、复杂度 vs 灵活性
明确超出范围的内容有哪些？
- 不会包含的功能
- 未来可考虑的内容

Step 13: Documentation

步骤13：文档

Ask:

Documentation needs?
- README only, User guide, API docs, Architecture docs, All of above
Who needs to understand this?
- Just you, Your team, Other developers, End users, Stakeholders

询问：

文档需求是什么？
- 仅README、用户指南、API文档、架构文档、以上全部
哪些人需要理解这些内容？
- 仅你自己、你的团队、其他开发者、终端用户、利益相关者

Step 14: Synthesize & Generate PRD

步骤14：汇总与生成PRD

After gathering all answers:

Summarize key findings
- Show user what you learned
- Highlight gaps or unclear areas
Ask for confirmation
- "Does this capture your vision?"
- Any corrections?
Generate comprehensive PRD
- Update or create PRD.md
- Include all sections:
  - Project Overview (problem, who, why now)
  - Goals & Success Criteria
  - User Stories (As a/I want/So that format)
  - Use Cases (detailed scenarios with flows)
  - Solution Approach
  - Technical Requirements
  - User Experience (if applicable)
  - Architecture & Scalability
  - Security & Privacy
  - Testing Strategy
  - Risks & Mitigation
  - Trade-offs & Decisions
  - Out of Scope
  - Documentation Plan
  - Success Metrics
  - Next Steps
Suggest ADRs
- Identify decisions that need ADRs:
  - Technology choices
  - Architecture decisions
  - Security approach
  - Other significant decisions
Propose next steps
- Create task breakdown
- Set up project structure
- Document first ADRs
- Begin implementation

收集所有答案后：

总结关键发现
- 向用户展示你所了解的内容
- 突出存在的空白或不明确的部分
请求确认
- “这是否准确捕捉了你的愿景？”
- 是否需要修正？
生成全面的PRD
- 更新或创建PRD.md
- 包含所有章节：
  - 项目概述（问题、受众、当前紧迫性）
  - 目标与成功标准
  - 用户故事（采用“作为/我希望/以便”格式）
  - 用例（包含流程的详细场景）
  - 解决方案方案
  - 技术要求
  - 用户体验（如适用）
  - 架构与可扩展性
  - 安全与隐私
  - 测试策略
  - 风险与缓解措施
  - 权衡与决策
  - 超出范围的内容
  - 文档计划
  - 成功指标
  - 下一步行动
建议ADR
- 识别需要ADR的决策：
  - 技术选型
  - 架构决策
  - 安全方案
  - 其他重要决策
提出下一步行动建议
- 创建任务分解
- 搭建项目结构
- 编写首批ADR
- 开始实施

Tips for Effective Interviews

有效访谈技巧

Ask open-ended follow-ups
- When brief answer, dig deeper
- "Can you tell me more about..."
- "What challenges do you foresee?"
Identify contradictions
- "You mentioned both X and Y, which takes priority?"
Push for specifics
- "What does 'fast' mean exactly?"
- "How many users is 'many'?"
Uncover implicit assumptions
- "I notice you haven't mentioned auth, is that needed?"
Validate understanding
- Summarize back: "So if I understand correctly..."

提出开放式的跟进问题
- 当回答过于简洁时，深入挖掘
- “你能详细说说……吗？”
- “你预见会有哪些挑战？”
识别矛盾点
- “你同时提到了X和Y，哪个优先级更高？”
推动具体化
- “‘快速’具体指什么？”
- “‘很多用户’具体是多少？”
挖掘隐含假设
- “我注意到你没提到身份验证，是否需要这项功能？”
验证理解
- 总结反馈：“我理解的是……对吗？”

Example Interview

访谈示例

Problem First:

Q: What problem are you trying to solve?
A: Team wastes 2h/day manually syncing data between 5 systems

Q: Who has this problem?
A: Operations team (12 people)

Q: How solving today?
A: Copy-paste between Excel, Salesforce, custom DB

Q: Why important now?
A: Hiring 10 more people next month, won't scale

Q: Success looks like?
A: Automatic sync, no manual work, always consistent

Solution Space:

Q: What type of solution?
A: Backend API (NOW we have context why!)

Q: Alternatives considered?
A: Zapier too expensive at our scale

Q: Constraints?
A: Must integrate Salesforce, must be secure (customer data)

Technical:

Q: Tech stack?
A: Must use Python (org requirement)

Q: Database?
A: Postgres + Redis

Q: Performance?
A: 1000 req/sec

Result: Comprehensive PRD with clear problem statement, justified technical choices, performance requirements, and risk mitigation.

先聚焦问题：

问：你试图解决什么问题？
答：团队每天浪费2小时手动同步5个系统之间的数据

问：谁面临这个问题？
答：运营团队（12人）

问：目前如何解决？
答：在Excel、Salesforce和自定义数据库之间复制粘贴

问：为什么现在变得重要？
答：下个月将招聘10名新员工，当前方式无法扩展

问：成功的标准是什么？
答：自动同步，无需手动操作，数据始终一致

探索解决方案范围：

问：你认为哪种类型的解决方案最适合？
答：后端API（现在我们有了选择的依据！）

问：是否考虑过替代方案？
答：Zapier在我们的规模下成本过高

问：有哪些约束条件？
答：必须与Salesforce集成，必须保证安全（涉及客户数据）

技术探讨：

问：技术栈是什么？
答：必须使用Python（组织要求）

问：数据库呢？
答：Postgres + Redis

问：性能要求是什么？
答：1000次请求/秒

结果： 生成包含清晰问题陈述、合理技术选型、性能要求和风险缓解措施的全面PRD。

Output Format

输出格式

Generate PRD.md structured as:

markdown

undefined

生成的PRD.md需按以下结构编写：

markdown

undefined

[Project Name]

[项目名称]

Problem Statement

问题陈述

[What problem, who has it, why now]

[问题内容、受众、当前紧迫性]

Current Situation

当前现状

[How people solve it today, why that's inadequate]

[目前的解决方案及其不足]

Proposed Solution

拟议解决方案

[High-level approach, why this solution]

[高层方案、选择原因]

Goals & Success Criteria

目标与成功标准

[MVP vs complete, how to measure success]

[MVP与完整版本的区别、衡量成功的方式]

User Stories

用户故事

Story 1: [Story Name]

故事1：[故事名称]

As a [role] I want [feature/capability] So that [benefit/value]

Acceptance Criteria:

Given [context]
When [action]
Then [expected result]

Priority: Must Have | Should Have | Could Have

作为 [角色] 我希望 [功能/能力] 以便 [收益/价值]

验收标准：

假设[场景]
当[操作]
则[预期结果]

优先级： 必须具备 | 应该具备 | 可以具备

Story 2: [Story Name]

故事2：[故事名称]

[Repeat format]

[重复格式]

Use Cases

用例

Use Case 1: [Use Case Name]

用例1：[用例名称]

Primary Actor: [Who initiates this]

Preconditions:

[Condition 1]
[Condition 2]

Main Success Scenario:

Actor does X
System responds with Y
Actor confirms Z
System completes action

Alternative Flows:

2a. If validation fails → Show error, return to step 1
3a. If user cancels → Discard changes, exit flow

Postconditions:

[Result 1]
[Result 2]

主要角色： [发起该用例的角色]

前置条件：

[条件1]
[条件2]

主成功场景：

角色执行操作X
系统响应Y
角色确认Z
系统完成操作

备选流程：

2a. 如果验证失败 → 显示错误信息，返回步骤1
3a. 如果用户取消 → 丢弃更改，退出流程

后置条件：

[结果1]
[结果2]

Use Case 2: [Use Case Name]

用例2：[用例名称]

[Repeat format]

[重复格式]

Technical Requirements

技术要求

Stack

技术栈

[Technologies and WHY each was chosen]

[所选技术及每个技术的选型原因]

Architecture

架构

[System design, scalability approach]

[系统设计、可扩展性方案]

Performance

性能

[Specific requirements with numbers]

[带具体数值的要求]

Security

安全

[Auth, data sensitivity, compliance]

[身份验证、数据敏感度、合规要求]

User Experience

用户体验

[UI type, key flows, design requirements]

[UI类型、核心流程、设计要求]

Testing Strategy

测试策略

Approach

方案

[TDD vs tests-after, test types, coverage goals]

[TDD vs 后测试、测试类型、覆盖率目标]

TDD Philosophy (if applicable)

TDD理念（如适用）

[If using TDD: Test via primary ports, mock only adapters, verify business flows] [Reference: Use

pragmatic-tdd

skill for TDD guidance]

[如果采用TDD：通过主端口测试，仅模拟适配器，验证业务流程] [参考：使用

pragmatic-tdd

技能获取TDD指导]

Quality Gates

质量门禁

[Tests must pass, code review, benchmarks, etc.]

[测试必须通过、代码评审、基准测试等]

CI/CD

[Automation plan]

[自动化计划]

Risks & Mitigation

风险与缓解措施

Risk	Impact	Probability	Mitigation

风险	影响	概率	缓解措施

Trade-offs

权衡决策

[Decisions made and why]

[已做出的决策及原因]

Out of Scope

超出范围的内容

[What's NOT included]

[不包含的功能]

Documentation

文档

[What docs needed, for whom]

[所需文档类型、受众]

Success Metrics

成功指标

[How we'll know this worked]

[判断方案有效的方式]

Next Steps

下一步行动

[Immediate action]
[Followup action]

---

[立即行动]
[后续行动]

---

Remember

谨记

A good PRD emerges from understanding the WHY behind every decision.

Problem → Solution → Implementation

NOT: Solution → Problem (wrong order!)

优秀的PRD源于理解每个决策背后的原因。

问题 → 解决方案 → 实施

而非：解决方案 → 问题（顺序错误！）