hot_comment_radar/docs/PRD.md

PRD.md：小红书 / 抖音热榜评论抓取 + AI 分析报告工具

1. 文档信息与版本说明

• 文档阶段：PRD（Product Requirement Document，产品需求文档）
• 需求来源：docs/RequirementsDoc.md
• API Spike 依据：docs/API-Spike-Xiaohongshu.md、docs/API-Spike-Douyin.md
• 项目类型：学习型小工具 / 全栈流程演示项目
• MVP 周期：约 4 天（单人开发）
• 目标用户：组内成员 / 演示使用
• 当前版本目标：定义产品功能、用户流程、页面需求与验收标准

1.1 范围说明

本 PRD 严格继承当前 RequirementsDoc.md 的范围，不扩展到此前讨论中但未进入需求文档的能力。

MVP 重点是跑通「手动触发抓取 → 获取热点榜单 → 拆分热点相关内容条目 → 抓取一级评论 → AI 分析 → 页面展示 → 导出」的完整闭环。

小红书与抖音的最小抓取链路已通过 API Spike 验证，PRD 阶段不锁定所有接口字段细节，后续由 DevelopmentPlan 和开发实现补充字段映射、分页、限流与异常处理方案。

2. 产品概述

本产品是一个面向组内成员的内部演示型工具，用于从小红书和抖音获取少量热点榜单，将每个热点拆分为相关内容条目，抓取内容条目下的一级评论，并通过 AI 对评论进行情绪和讨论方向分析。抖音内容条目为视频，小红书内容条目统一称为笔记，不区分图文和视频。用户可以在 Web 页面查看热点列表、热点级汇总报告、内容条目列表、内容条目级分析报告和评论明细，也可以导出 CSV 评论明细、Markdown 热点级汇总报告和 Markdown 内容条目级报告。

产品不追求首版大规模采集、复杂权限、定时任务或平台级深度分析。MVP 成功的核心判断是全流程是否可用、结果是否可查看、导出是否可获得。

3. 产品目标

3.1 总体目标

在 4 天单人开发周期内，完成一个可本机或局域网部署的全栈演示产品，体现从外部数据接入、数据存储、AI 结构化分析到 Web 展示与导出的完整链路。

3.2 MVP 目标

MVP 必须达成：

1. 用户可以在页面选择平台并手动触发抓取任务。
2. 系统可以获取小红书或抖音的 Top N 热点榜单。
3. 系统可以将每个热点拆分出相关内容条目，并抓取每条内容条目的一级评论。
4. 系统可以对评论生成情绪分类和方向标签。
5. 系统可以生成热点级汇总报告和内容条目级分析报告。
6. 用户可以查看任务、热点、内容条目、报告和评论明细。
7. 用户可以导出 CSV 评论明细、Markdown 热点级汇总报告和 Markdown 内容条目级报告。
8. 系统可以通过 Docker Compose 启动并在浏览器访问。

3.3 产品原则

• 流程完整优先于规模和复杂度。
• 页面简洁可用优先于视觉精细度。
• 统计数据来自结构化分析结果，避免只依赖 AI 自由总结。
• 外部 API 和 AI 输出 schema 保持可调整，不在 PRD 阶段锁死技术细节。

4. 目标用户与使用场景

4.1 目标用户

• 组内开发者：验证接口、联调流程、演示全栈能力。
• 产品或数据分析同事：查看热点内容评论的基础情绪和方向分布。
• 演示观看者：理解抓取、分析、展示、导出的完整产品闭环。

4.2 用户权限

MVP 默认不做登录和权限控制。所有能访问系统页面的用户拥有相同功能权限。

如果后续教学或审阅场景明确要求访问控制，可追加单管理员账号方案；该能力不属于当前 PRD 的默认范围。

4.3 核心使用场景

用户希望快速查看某个平台热点下相关内容条目的评论基础反馈时：

1. 打开 Web 页面。
2. 选择平台：小红书或抖音。
3. 点击按钮手动创建抓取任务。
4. 等待系统完成热点榜单获取、内容条目拆分、评论抓取和 AI 分析。
5. 在热点列表和内容条目列表中查看抓取到的热点及其相关视频/笔记。
6. 进入热点汇总报告页，查看该热点下所有内容条目的整体评论分析。
7. 进入内容条目详情页，查看内容条目级分析报告和评论明细。
8. 按需导出 CSV 评论明细或 Markdown 分析报告。

5. 核心用户流程

5.1 手动抓取与分析流程

1. 用户进入首页或任务页。
2. 用户选择平台。
3. 用户点击「开始抓取」或同类操作按钮。
4. 系统创建一条抓取任务并立即返回任务记录，任务状态进入「运行中」。
5. 后端在后台继续执行任务，不要求前端 HTTP 请求一直阻塞等待完成。
6. 系统调用外部 API 获取该平台 Top N 热点榜单。
7. 系统将每个热点拆分为相关内容条目。
8. 系统依次抓取每条内容条目的一级评论。
9. 系统调用 AI 对评论进行结构化分析。
10. 系统生成内容条目级分析报告。
11. 系统按热点聚合内容条目级结果，生成热点级汇总报告。
12. 任务完成后状态变为「成功」；如全局失败则状态变为「失败」并展示错误原因。
13. 用户通过刷新任务列表或点击刷新按钮查看最新状态，然后查看结果或执行导出。

5.2 结果查看流程

1. 用户在任务列表中选择某次任务。
2. 系统展示该任务下的热点列表。
3. 用户展开或进入某个热点，查看该热点下的相关内容条目。
4. 用户可以进入热点级汇总报告，查看该热点下所有内容条目的整体评论情况。
5. 用户选择某个内容条目进入详情页。
6. 系统展示热点基础信息、内容条目基础信息、内容条目级分析报告和评论明细。
7. 用户可以根据评论情绪或方向标签理解该内容条目的讨论情况。

5.3 导出流程

1. 用户在内容条目详情页点击导出入口。
2. 导出该内容条目的评论明细时，系统生成 CSV 文件。
3. 导出热点级汇总报告或内容条目级报告时，系统生成 Markdown 文件。
4. 用户下载文件用于本地分析、分享或归档。

6. 功能需求

6.1 平台选择

用户需要能够在前端页面选择抓取平台。

支持平台：

• 小红书
• 抖音

验收标准：

• 页面存在平台选择控件。
• 用户可以明确选择小红书或抖音。
• 创建任务时，任务记录中保存所选平台。

6.2 手动创建抓取任务

MVP 仅支持用户手动触发任务，不支持定时自动任务。

功能要求：

• 用户点击按钮后，系统创建一条抓取任务。
• 任务初始状态为「运行中」。
• 任务记录需要保存平台、触发时间、任务状态和错误信息。
• 同一用户可以重复触发任务；多次任务视为独立执行。
• 后端允许采用简单后台任务模型，创建任务后立即返回任务 ID 或任务记录，抓取、分析和报告生成在后台继续执行。
• MVP 不要求 WebSocket，也不强制自动轮询；前端至少提供刷新按钮或页面刷新能力用于查看最新任务状态。

验收标准：

• 用户能从页面创建抓取任务。
• 任务创建后能在页面看到任务记录。
• 任务完成后状态能更新为成功或失败。
• 用户无需等待一次 HTTP 请求完成全部抓取和 AI 分析。

6.3 热点榜单获取与内容条目拆分

系统需要通过现有外部 API 获取所选平台的热点榜单，并拆分出每个热点下的相关内容条目。

功能要求：

• 每次任务默认抓取 Top 5 热点。
• 支持通过配置调整到 Top 10 热点。
• MVP 不追求 Top 50 或更大规模。
• 每个热点需要拆分出相关内容条目：
  • 默认每个热点最多拆分 5 条内容条目；
  • 支持通过配置调整到 10 条内容条目；
  • 如果某个热点下内容条目不足 5 条，则抓取全部可获得内容条目；
  • MVP 不追求穷尽单个热点下所有视频/笔记；
  • 抖音内容条目为视频；
  • 小红书内容条目统一称为笔记，不区分图文和视频。
• 默认抓取规模约为：5 个热点 × 每热点 5 条内容条目 × 每条内容条目 50 条一级评论 = 1,250 条评论 / 平台 / 任务。
• 系统保存平台、热点排名、热点标题、内容条目 ID、标题或摘要、URL、抓取时间等可用字段。

验收标准：

• 系统能按默认规模获取 Top 5 热点并展示在页面。
• 系统能展示每个热点下最多 5 条相关内容条目。
• 热点、内容条目与任务有关联关系。
• API 字段缺失时，页面能以可用字段展示，不阻塞整体流程。

6.4 一级评论抓取

系统需要抓取每条内容条目下的一级评论。

功能要求：

• 仅抓取一级评论。
• 默认单条内容条目评论上限为 50 条。
• 支持通过配置调整到 100 条。
• 评论不足上限时抓取全部可获得评论。
• 抓取顺序以 API 默认顺序为准，不强制按时间或热度排序。
• 数据按任务隔离：每次任务独立保存自己的热点、内容条目和评论结果。
• 同一任务内，同一内容条目下以评论 ID 进行基础去重；跨任务不强制全局去重。

验收标准：

• 系统能为每条成功获取的内容条目抓取一级评论。
• 评论记录至少包含评论内容和所属内容条目。
• 如 API 提供评论 ID、作者、点赞数、评论时间，应尽量保存并展示。
• 同一内容条目同一评论 ID 不重复入库，或重复抓取时更新已有记录。

6.5 AI 评论级结构化分析

系统需要对评论进行 AI 结构化分析。

分析字段：

• 情绪倾向：正向、负向、中性。
• 方向标签：开放标签，由 AI 根据评论内容生成，每条评论可有 1~3 个标签。
• 简短理由：可选字段，用一句话解释情绪或标签判断。

功能要求：

• 不预设固定标签字典。
• AI 可以生成如价格争议、外观种草、使用体验、质量吐槽、求购买链接、玩梗讨论等标签。
• 近义标签合并不作为 MVP 强制要求。
• 分析结果必须与原始评论关联。
• AI 分析默认采用批量处理思路，例如每批 10~20 条评论，具体批量大小在 DevelopmentPlan 中确认。
• 如果 AI 返回内容无法解析或缺失必填字段，单条评论应标记为「未知」情绪、空标签或分析失败原因，不应阻塞后续评论分析。

验收标准：

• 已抓取评论能生成情绪分类。
• 已抓取评论能生成至少一个方向标签，或在无法判断时给出空标签/未知标签。
• 评论明细页能展示评论内容、情绪和标签。
• AI 分析失败的单条评论不会导致整个任务崩溃。

6.6 热点级汇总报告

系统需要为每个热点生成一份轻量热点级汇总报告。

报告内容：

• 热点基础信息。
• 该热点下内容条目数量。
• 总评论样本数量。
• 正向、负向、中性评论整体数量和占比。
• Top 5 方向标签及数量。
• 典型评论若干。
• AI 生成的简短热点总结。

功能要求：

• 热点级汇总报告基于该热点下所有已分析内容条目的评论级结构化结果聚合生成。
• 情绪分布和标签分布应由评论级结构化结果计算。
• 方向标签统计按标签字面值聚合，MVP 仅展示出现频次最高的 Top 5 标签及数量，不要求语义近义标签自动归并。
• 典型评论默认在该热点下按情绪分组后按点赞数降序选取。
• 热点级总结由 AI 基于统计结果、Top 标签和典型评论生成，建议不超过 300 字。
• MVP 不做平台级日报或跨热点汇总。

验收标准：

• 每个已完成分析的热点可查看一份热点级汇总报告。
• 报告中的内容条目数、样本数、情绪数量和占比与该热点下评论明细一致。
• 报告可以导出为 Markdown。

6.7 内容条目级分析报告

系统需要为每条内容条目生成一份内容条目级分析报告。

报告内容：

• 样本评论数量。
• 正向、负向、中性评论数量和占比。
• 主要方向标签及占比。
• 典型正向评论 1~2 条。
• 典型负向评论 1~2 条。
• 典型中性评论 1~2 条。
• AI 生成的简短内容条目级总结。

功能要求：

• 情绪分布和标签分布应由评论级结构化结果计算。
• 方向标签统计按标签字面值聚合，MVP 仅展示出现频次最高的 Top 5 标签及数量，不要求语义近义标签自动归并。
• 典型评论默认按情绪分组后按点赞数降序选取每类前 1~2 条。
• 如果点赞数字段不可用，典型评论按抓取顺序选取每类前 1~2 条。
• 内容条目级总结由 AI 基于统计结果、Top 标签和典型评论生成，建议不超过 200 字。
• 总结强调事实统计和常见观点，不要求深度运营洞察。

验收标准：

• 每条已完成分析的内容条目可查看一份内容条目级报告。
• 报告中的样本数、情绪数量和占比与评论明细一致。
• 报告可以导出为 Markdown。

7. 页面与交互需求

7.1 任务列表 / 首页

页面目标：让用户创建抓取任务并查看任务状态。

页面元素：

• 平台选择控件。
• 手动触发按钮。
• 刷新任务列表按钮。
• 任务列表。
• 任务状态：运行中、成功、失败。
• 任务基础信息：平台、创建时间、热点数量、内容条目数量、错误原因。
• 可选进度信息：已处理内容条目数 / 总内容条目数。

交互要求：

• 用户选择平台后点击按钮创建任务。
• 创建后任务列表能展示新任务。
• 任务失败时展示简要错误原因。
• 用户点击任务行进入该任务的热点与内容条目列表页。
• MVP 不单独设计任务详情页；任务状态、错误原因和基础进度在任务列表行内展示，或在热点与内容条目列表页顶部展示。
• 用户通过刷新按钮或页面刷新获取任务最新状态；自动轮询可作为实现优化，不是 MVP 必须项。

7.2 热点与内容条目列表页

页面目标：展示某次任务抓取到的热点，以及每个热点下的相关内容条目。

页面元素：

• 平台。
• 抓取时间或任务标识。
• 任务状态、错误原因和基础进度。
• 热点排名。
• 热点标题或摘要。
• 进入热点级汇总报告的操作入口。
• 内容条目标题或摘要。
• 内容条目类型：抖音视频 / 小红书笔记。
• 分析状态。
• 进入详情的操作入口。

交互要求：

• 用户可以从任务进入热点与内容条目列表。
• 用户可以查看热点下的相关内容条目。
• 用户可以进入热点级汇总报告。
• 用户可以点击内容条目进入详情页。

7.3 热点级汇总报告页

页面目标：展示单个热点下所有内容条目的整体评论分析。

页面元素：

• 热点基础信息。
• 内容条目数量。
• 总评论样本数量。
• 情绪分布。
• Top 5 方向标签。
• 典型评论。
• 简短热点总结。
• 导出 Markdown 热点级汇总报告入口。

7.4 内容条目详情页

页面目标：展示内容条目级分析报告和评论明细。

页面元素：

• 热点基础信息。
• 内容条目基础信息。
• 样本评论数量。
• 情绪分布。
• 标签分布。
• 典型评论。
• 简短总结。
• 评论明细列表。
• 导出 Markdown 报告入口。
• 导出 CSV 评论明细入口。
• 可选开发调试信息入口：展示该内容条目或评论的原始 JSON，仅供开发和排障使用，不作为正式用户功能。

交互要求：

• 用户能同时查看统计结果和原始评论。
• 导出入口应清晰可见。

7.5 评论明细展示

评论明细至少展示：

• 评论内容。
• 情绪倾向。
• 方向标签。
• 点赞数（如有）。
• 评论时间（如有）。
• 作者基础信息（如有）。

MVP 不强制提供复杂筛选、搜索或人工校正。

8. 数据与分析结果需求

8.1 任务数据

任务需要记录：

• 任务 ID。
• 平台。
• 创建时间。
• 状态。
• 错误原因。
• 已获取热点数。
• 已获取内容条目数。
• 可选进度信息，如已处理内容条目数 / 总内容条目数。

8.2 热点与内容条目数据

热点需要记录：

• 平台。
• 任务 ID。
• 排名。
• 热点 ID。
• 热点标题或摘要。
• 热度值或榜单指标（如 API 提供）。
• 原始 API 响应 raw_data，用于接口联调和排障。

内容条目需要记录：

• 平台。
• 任务 ID。
• 所属热点 ID。
• 内容条目 ID。
• 内容条目类型：抖音视频 / 小红书笔记。
• 标题或内容摘要。
• URL。
• 抓取状态或分析状态。
• 原始 API 响应 raw_data，用于接口联调和排障。

字段以 API 实际返回能力为准。

8.3 评论数据

评论需要记录：

• 评论 ID。
• 所属热点。
• 所属内容条目。
• 评论内容。
• 作者基础信息。
• 点赞数。
• 评论时间。
• 情绪倾向。
• 方向标签。
• 可选简短理由。
• 原始评论 API 响应 raw_data。
• 可选 AI 原始响应 ai_raw_data，用于排查 AI 输出解析问题。

字段以 API 实际返回能力为准。原始评论内容必须保留。

8.4 报告数据

热点级汇总报告需要记录或可重新生成：

• 热点基础信息。
• 内容条目数量。
• 总评论样本数量。
• 情绪统计。
• 标签统计。
• 典型评论。
• 简短热点总结。

内容条目级报告需要记录或可重新生成：

• 样本评论数量。
• 情绪统计。
• 标签统计。
• 典型评论。
• 简短总结。

报告统计应来自评论级结构化结果。

9. 导出需求

9.1 Markdown 热点级汇总报告导出

导出入口：

• 热点级汇总报告页。

建议内容：

• 热点基础信息。
• 内容条目数量。
• 总评论样本数量。
• 情绪分布。
• Top 方向标签。
• 典型评论。
• 热点总结。

验收标准：

• 用户能下载 Markdown 文件。
• Markdown 内容结构清晰，满足常见 Markdown 阅读器可解析的基本格式。
• Markdown 报告与页面展示的热点级汇总报告一致。

9.2 Markdown 内容条目级报告导出

导出入口：

• 内容条目详情页。

建议内容：

• 所属热点信息。
• 内容条目基础信息。
• 评论样本数量。
• 情绪分布。
• Top 方向标签。
• 典型评论。
• 内容条目总结。

验收标准：

• 用户能下载 Markdown 文件。
• Markdown 内容结构清晰，满足常见 Markdown 阅读器可解析的基本格式。
• Markdown 报告与页面展示的内容条目级报告一致。

9.3 CSV 内容条目评论明细导出

导出入口：

• 内容条目详情页。

建议字段：

• 平台。
• 抓取日期或任务标识。
• 热点 ID。
• 热点标题或摘要。
• 内容条目 ID。
• 内容条目标题或摘要。
• 评论 ID。
• 评论内容。
• 情绪倾向。
• 方向标签。
• 点赞数。
• 评论时间。

验收标准：

• 用户能下载 CSV 文件。
• CSV 编码建议为 UTF-8；是否添加 BOM 由 DevelopmentPlan 确认。
• CSV 内容能用常见表格工具打开。
• CSV 中的评论数据与页面展示一致。

10. 异常与状态需求

10.1 任务状态

MVP 支持三种任务状态：

• 运行中。
• 成功。
• 失败。

可选展示：

• 已处理内容条目数 / 总内容条目数。
• 成功内容条目数 / 失败内容条目数。

状态判定规则：

• 全部流程仍在执行时，任务状态为「运行中」。
• 至少有 1 条内容条目成功完成抓取和分析时，任务最终状态可标记为「成功」，同时在任务行或列表页顶部展示失败内容条目数和错误信息。
• 如果没有任何内容条目成功完成抓取和分析，任务最终状态标记为「失败」。
• MVP 不新增「部分成功」状态。

10.2 错误展示

任务失败时需要展示简要错误原因，例如：

• API 请求失败。
• API 响应异常。
• AI 调用失败或超时。
• 数据入库失败。

错误信息不要求面向非技术用户完全友好，但必须足够支持开发者排查。

10.3 容错行为

• 单个热点或内容条目抓取/分析失败时，应记录错误并尝试继续处理剩余内容。
• MVP 不要求实现部分成功状态。
• MVP 不要求自动补跑、单条内容条目重试、分布式锁或复杂任务恢复。
• AI 单条解析失败时，该评论标记为未知或分析失败，不阻塞其他评论。

11. 非功能需求

11.1 可用性

• 页面结构应简单清晰。
• 用户能快速知道当前有哪些任务、任务是否成功、内容条目分析结果在哪里查看。
• 错误信息应可见。

11.2 可维护性

• 外部 API 调用、数据存储、AI 分析、报告生成、页面展示和导出应保持模块边界清晰。
• 平台、Top N、单条内容条目评论上限应可配置。
• AI 提示词和输出结构应便于后续调整。

11.3 数据质量

• 保留原始评论内容。
• 评论级 AI 结果可追溯到原始评论。
• 报告统计由结构化结果计算。
• 不因 AI 总结文本替代结构化统计。

11.4 安全与配置

• API Key、AI Key 等敏感配置不得写入代码仓库。
• 敏感配置通过环境变量或未纳入版本控制的配置文件管理。
• MVP 默认用于内部环境，不面向公网开放。

12. MVP 成功标准

MVP 必须满足：

1. 系统可以通过 Docker Compose 启动，并能在浏览器访问。
2. 用户可以从页面手动触发抓取任务。
3. 用户可以选择小红书或抖音作为平台。
4. 系统可以从外部 API 获取所选平台默认 Top 5 热点。
5. 系统可以从每个热点拆分出默认最多 5 条相关内容条目，并为每条内容条目抓取默认最多 50 条一级评论。
6. 系统可以为评论生成情绪分类和方向标签。
7. 系统可以生成热点级汇总报告和内容条目级分析报告。
8. 用户可以查看任务列表、热点列表、热点级汇总报告、内容条目列表、内容条目详情和评论明细。
9. 用户可以导出 CSV 评论明细。
10. 用户可以导出 Markdown 热点级汇总报告和内容条目级分析报告。
11. 任务失败时，页面能展示失败状态和简要错误原因。

质量与稳定性目标为尽力达成，不作为硬性阻塞：

• 情绪分类与方向标签人工抽查时方向基本合理；建议演示验收时随机抽查 10 条评论，7 条及以上判断方向可接受即视为基本可用。
• 报告统计数据与评论结构化结果一致。
• 单个热点或内容条目失败不导致整批任务完全不可用。

13. Out of Scope

以下能力不纳入当前 MVP：

• 定时自动抓取任务。
• 任务并发控制、分布式锁、复杂任务调度。
• 自动补跑、任务阶段粒度展示、单条内容条目单独重试。
• Top 50 及以上热点抓取。
• 单条内容条目 200 条及以上评论抓取。
• 平台级每日汇总报告。
• 跨热点聚合 Top 话题和平台层总结。
• 登录鉴权。
• 多用户与角色权限管理。
• 操作审计。
• Excel 导出。
• 用户侧正式 JSON 导出。
• 二级评论抓取。
• 评论回复、自动发布、私信运营。
• 长期趋势分析。
• 品牌专题分析。
• 关键词筛选热点。
• 移动端适配。
• 复杂 BI 大屏。
• 评论人工标注校正工作台。
• 自动形成运营建议或营销动作。
• 外部分享链接、公开访问和权限控制。

14. 待确认事项

以下事项不阻塞 PRD。小红书 / 抖音最小抓取链路已通过 API Spike 验证，后续需要在 DevelopmentPlan 和开发阶段确认工程化细节：

1. 小红书 / 抖音热点榜单、内容条目与评论数据的字段映射和兼容策略。
2. 小红书 / 抖音热点到内容条目的关联落库方式。
3. 小红书 / 抖音评论 API 的分页策略、排序规则、限流策略和异常码。
4. 外部 API 在默认规模和配置上限下的稳定性。
5. AI 服务提供商、模型名称、费用和调用速率限制。
6. AI 输出结构的具体 schema，例如字段名称、枚举值和标签格式。
7. Docker Compose 中数据库和任务处理方案的具体技术选型。
8. 前后端核心 API 接口设计，包括创建任务、查询任务列表、查询热点与内容条目列表、查询内容条目详情、导出 CSV 和导出 Markdown。
9. 前端状态刷新机制是否从手动刷新升级为简单定时轮询。
10. Docker Compose 启动验收细节，包括是否自动初始化数据库、是否需要 migration、首页访问是否作为健康判断。
11. 是否提供 /health 健康检查端点，用于部署和联调验证。
12. API Spike 中的真实 JSON 样例应作为 DevelopmentPlan 与开发实现的字段映射依据。

15. 后续文档衔接说明

PRD 完成并通过审阅后，后续文档按以下顺序推进：

1. FeatureSummary.md：拆解功能模块、优先级和版本边界。
2. DevelopmentPlan.md：确定技术选型、架构、接口、数据模型和开发计划。
3. UIDesign.md：定义关键页面结构、信息层级和交互细节。
4. TDD.md：定义测试驱动开发计划和验收测试场景。
5. Tasks.md：拆解具体开发任务、依赖关系和排期。

每份主文档产出后，按 RequirementsDoc.md 中定义的审阅流程生成独立 review 文件，汇总修订并经用户确认后再进入下一阶段。

DevelopmentPlan.md 需要优先决策：

• 后台任务实现方式：简单线程/协程、任务队列或其他方案。
• AI 批量调用大小、输出解析、失败兜底和内容条目级总结 prompt。
• 数据模型是否沿用 PRD 默认的按任务隔离策略。
• 数据库、前端框架、后端框架和 Docker Compose 组件。
• 前后端 API 契约和状态刷新机制。