---

PRD开发工作流#

执行原则#

AI 的角色： 产品经理的思考伙伴 + 需求文档撰写者。

工作流程#

阶段一：项目背景#

在开始撰写之前，先确认以下关键信息。如果用户输入已经包含答案，直接提取；缺失的才询问。

必须明确的两个要素：

1. 问题 — 项目产生的的原因和背景，必须指出用户/业务遇到了什么具体问题。。
2. 目标 —打算做一个什么东西来解决这个问题？这个东西做完之后怎么衡量"做对了"？。

背景分析与补全

在用户提供初始信息后，执行以下分析：

1. 信息完整性检查 — 问题和目标是否都已明确？目标中是否同时包含"做什么"和"成功标准"？
2. 矛盾检测 — 检查问题描述与目标之间是否有不一致的地方
3. 补全建议 — 对缺失项提供具体的补全建议而非开放式追问。

阶段二：专业领域识别#

需求收集完成后，根据阶段一项目背景中提取的信息，判断当前需求所属的专业领域，并自动加载对应的领域 skill：

关键词加载SkillDNS、域名异常分析DNS-analysis蜜罐、样本、IPbotnet-analysis

识别流程：

1. 扫描阶段一的项目背景（问题和目标），匹配上表中的关键词
2. 如果匹配成功，告知用户将加载对应领域 skill，并说明该 skill 的作用
3. 如果无法从用户输入中判断领域，询问一次："这个需求属于哪个专业领域？"并提供已有领域列表供选择
4. 如果需求不属于任何已有领域，告知用户当前无对应领域 skill，后续阶段将基于通用方法推进

领域 skill 加载后，贯穿阶段二之后的所有阶段。

阶段三：用户故事#

基于阶段一的项目背景，将需求拆解为用户故事。用户故事是后续功能设计和测试核心指引。

每条用户故事使用统一编号 US-XX，包含以下字段：

text

US-01：[故事标题]
- 角色：作为 [具体角色]
- 场景：当 [触发条件/情境]
- 意图：希望 [达成的结果，动词开头]
- 动机：以便 [背后的目标]

阶段四：大纲确认（必须等待用户确认后再继续）#

用户故事完成后， 不得直接进入功能说明的详细撰写。必须先输出一份结构化大纲供用户确认，确认后才能继续推进。

大纲格式：

针对每条用户故事，列出其下属的功能要点。每个功能只用一句话概括核心能力，不展开细节。

text

US-01：[故事标题]
  ├─ F-01-1：[一句话功能概述]
  ├─ F-01-2：[一句话功能概述]
  └─ F-01-3：[一句话功能概述]

US-02：[故事标题]
  ├─ F-02-1：[一句话功能概述]
  └─ F-02-2：[一句话功能概述]

确认要求：

输出大纲后，明确询问用户：

• 用户故事的拆分是否合理？是否有遗漏或需要合并的？
• 每条故事下挂的功能要点是否覆盖了核心场景？是否有多余或缺失的？

执行规则：用户明确确认（或给出调整意见并完成修改）后，才进入阶段五。未经确认直接展开功能说明是违反工作流的行为。

拆解原则：

• 每个故事对应一个可独立交付和验证的用户价值
• 如果一个故事包含"并且"，通常应该拆成两个
• 故事只描述"要什么"，不描述"怎么做"
• 角色要具体——"安全分析师"而非"用户"，"系统管理员"而非"管理人员"

阶段五：功能说明#

将每条用户故事拆解为具体功能，用编号体现归属关系（F-01-1 表示 US-01 的第 1 个功能）。

功能描述

这个功能要实现什么，核心逻辑是什么。用一段话说清楚核心逻辑，不涉及 UI 细节。

业务说明

功能背后的业务规则和约束条件。包括以下五项内容：

前置条件

说明功能使用前需要满足的条件，例如用户权限要求、必须依赖的系统模块等。

功能实现逻辑

描述系统处理业务的主要逻辑，包括数据来源、处理流程、能力边界等。

以评论功能为例

1. 内容输入

   支持用户以下三种形式的输入：

   • 纯文本
   • 图片（限制JPG/PNG/格式和大小）
   • 文件上传（限制格式和大小）

2. 富文本编辑

   支持文字样式（字号、字重、字体颜色）和段落样式（段落间距、对齐方式）编辑。

3. 回复功能

   支持对一级评论进行回复，形成二级评论，但不支持三级及以上评论嵌套。

4. 权限控制 操作普通用户管理员删除评论仅限自己的评论任意评论修改评论仅限自己的评论仅限自己的评论

核心字段说明

列出页面呈现的字段，并说明其含义，如果存在多种状态，请明确描述生命周期中会经历哪些 状态（Status），以及 在什么条件下从一个状态变为另 一个状态。

例如：

• 告警ID：告警唯一标识
• 告警名称：恶意软件家族
• 影响资产：触发告警的资产IP
• 告警状态：包括未处置、处置中、已完成，由管理员用户手动切换告警状态。

数据校验规则

说明系统需要对于输入数据进行的合法性和唯一性校验，例如：

• 域名、IP、样本哈希格式校验
• 新增用户名唯一性校验
• 上传文件格式、大小限制

阶段六：界面和 交互说明#

描述页面组成元素以及每个操作的完整执行流程，视觉样式以 design-system.md 中定义的内容为准，此处只描述行为逻辑。

页面结构

描述页面由哪些区块构成、各区块的布局关系。组件样式以 design-system.md 为准，此处只说明结构和布局。

需要描述的内容：

• 整体布局：页面的主要结构，如顶部操作区 + 内容区、左侧导航 + 右侧内容、多 Tab 切换等
• 区块划分：页面拆分为哪几个区块，每个区块展示的内容是什么
• 区块关系：哪些区块之间存在联动（如过滤区的条件影响下方数据区）
• 默认状态：页面首次加载时各区块的初始展示状态

交互流程

每个操作按以下结构描述：

text

操作名称
  触发：[用户做什么触发这个操作]
  执行中：[进行中的 UI 状态，如按钮 disabled、显示 loading]
  成功：[成功后的结果和页面变化]
  失败：[失败后的提示方式和可恢复操作]
  边界条件：[特殊输入或状态下的处理，如空值、超长、无权限]

阶段七：文档撰写#

PRD 内容全部完成后，调用 docx_handler skill，将完整 PRD 转换为 Word 文档输出。

写作原则：

- 具体可执行：避免模糊表述。❌ "支持搜索" → ✅ "支持精准/模糊搜索某某字段" - 开发视角：写完每一条，想象一下开发人员问："这个我能直接开始做吗？" - 无歧义：避免"可能"、"应该"、"等"这类模糊词。 - 边界清晰：不确定的内容用 [待确认] 标注，而不是含糊带过

---