98 lines
7.9 KiB
Markdown
98 lines
7.9 KiB
Markdown
# `PRD.md` 审阅报告
|
||
|
||
- 审阅对象：`docs/PRD.md`
|
||
- 文档版本：Draft v0.1
|
||
- 审阅时间：2026-04-02
|
||
- 审阅人：Codex
|
||
|
||
## 1. 总体结论
|
||
|
||
这份 PRD 已经明显从“需求草案”推进到“可指导 MVP 设计、研发拆解和验收”的阶段。相较前一版 `RequirementsDoc.md`，文档已经补齐了产品目标与非目标、任务状态机、评论抽样口径、数据标准化规则、数据与合规边界、成功指标和验收标准，整体方向正确，范围控制也比较克制。
|
||
|
||
如果要据此直接进入详细设计和开发排期，当前版本还建议再补齐 3 个 P0 级定义：任务状态的粒度与重试规则、AI 报告的结构化 Schema、搜索与登录态检查的先后关系。这三个点如果不继续收敛，开发阶段仍容易出现前后端契约不一致、异常路径理解不一致和历史结果不可追踪的问题。
|
||
|
||
## 2. 相比前序需求文档的明显进步
|
||
|
||
| 维度 | 本版补强点 | 价值 |
|
||
| --- | --- | --- |
|
||
| 目标定义 | 明确了产品目标与非目标 | 让 MVP 范围更可控，减少后续需求膨胀 |
|
||
| 任务机制 | 增加了完整任务状态机 | 有利于处理长任务、阻塞任务和部分成功任务 |
|
||
| 抽样口径 | 明确了评论按链接抽样、分层抽样和总量上限 | 降低实现歧义，提升分析稳定性 |
|
||
| 数据口径 | 增加商品/评论标准化字段定义 | 为跨平台比较和报告生成提供统一基础 |
|
||
| 报告约束 | 明确要求结构化输出、证据引用、置信度标记 | 提升报告的可追溯性和可信度 |
|
||
| 安全合规 | 增加会话、数据留存和合规边界 | 把高风险问题前置到产品定义阶段 |
|
||
| 验收闭环 | 增加成功指标与 MVP 验收标准 | 让“做完”和“可用”之间有可执行判断标准 |
|
||
|
||
## 3. 当前文档的主要优点
|
||
|
||
### 3.1 产品边界足够清晰
|
||
|
||
文档明确把产品定位为“任务型分析工具”，而不是“持续监控平台”。覆盖平台、输入方式、输出形态和非目标都写得比较克制，这使 MVP 范围收敛得更合理。
|
||
|
||
### 3.2 主流程和价值闭环已经成立
|
||
|
||
从“关键词输入”到“候选召回”到“人工确认”再到“抓取、标准化、AI 分析、报告回看”，主流程完整且顺序清楚，已经具备产品化工作流的骨架。
|
||
|
||
### 3.3 对真实世界异常的考虑比较成熟
|
||
|
||
文档没有把平台访问理想化，而是明确承认登录失效、验证码、风控拦截、平台失败和部分成功是常态，并为此设计了 `Blocked`、`PartialCompleted` 等状态。这一点很重要，说明文档是在为真实可运行场景做定义，而不是只写 happy path。
|
||
|
||
### 3.4 多链接与证据回溯设计合理
|
||
|
||
同一平台允许多选，并采用链接级、平台级、跨平台级三级聚合，这个决策很关键。它既承认多店铺、多销售页并存是常态，又避免了报告被链接级细节完全淹没。
|
||
|
||
### 3.5 数据标准化与报告可信度意识较强
|
||
|
||
文档明确要求保留原始字段、允许标准化空值、强制证据优先于结论，并要求关键结论尽量附带来源范围、证据数量和证据引用。这使产品不只是“会生成结论”，而是朝着“结论可验证”推进。
|
||
|
||
## 4. 仍需明确的关键问题
|
||
|
||
下表列出当前最值得继续补齐的点。
|
||
|
||
| 优先级 | 问题 | 当前表现 | 影响 | 建议补充 |
|
||
| --- | --- | --- | --- | --- |
|
||
| P0 | 任务状态粒度仍偏粗 | 目前状态机主要是任务级状态，但 `Blocked`、`PartialCompleted`、`Failed` 实际混入了平台级异常 | 一旦某个平台阻塞，容易出现“整任务阻塞”还是“其余平台继续”的实现分歧 | 增加 `task_status` 与 `platform_status` 两层状态；明确单平台阻塞、单平台失败、多平台成功时的流转规则 |
|
||
| P0 | AI 报告仍缺少可执行 Schema | 文档说明了报告模块和结论卡片要素，但没有定义稳定的数据结构 | 前后端接口、存储模型和提示词约束都可能漂移，导致“都叫结构化，实际格式不同” | 定义固定报告 Schema，例如摘要、平台洞察、风险主题、证据引用、置信度枚举和样本不足标记的字段级约束 |
|
||
| P0 | 搜索与登录校验的顺序存在歧义 | 新建任务页要求展示平台可用性提示，主流程中又是先搜索、后检查会话 | 对需要登录才能搜索的平台，产品交互和技术实现都可能出现冲突 | 明确哪些平台的搜索依赖登录态；定义预检查、搜索、确认、抓取前校验的先后关系和降级路径 |
|
||
| P1 | 失败重试后的报告版本规则未定义 | 文档支持 `PartialCompleted` 后重试失败平台，但未说明是覆盖旧报告还是生成新版本 | 可能破坏历史回看、审计和用户对“当次结果”的理解 | 增加报告版本策略，至少明确重试是否生成新快照、历史版本是否保留、展示哪个版本为默认 |
|
||
| P1 | 候选商品卡片的去重与差异展示规则不够明确 | 当前只定义了候选项应展示哪些字段，没有定义重复候选、同店多 SKU、同款不同规格如何提示 | 用户确认效率和正确性会受到影响 | 增加候选卡片的去重规则、规格差异展示规则和平台内排序依据 |
|
||
| P1 | 成功指标偏效率导向，缺少“正确性”衡量 | 当前指标覆盖完成率、时长和可追溯率，但缺少确认对象正确性或报告有效性的抽检指标 | 系统可能“稳定产出”，但不一定“稳定产出正确对象和可信结论” | 增加候选确认准确性抽检、证据引用有效率或试运行报告采纳率等质量指标 |
|
||
|
||
## 5. 建议优先补齐的五个决策
|
||
|
||
如果只优先补五件事，建议按下面顺序推进：
|
||
|
||
1. 明确任务级与平台级双层状态机。
|
||
重点回答单平台 `Blocked` 时，其余平台是否继续，以及最终是进入 `Blocked`、`PartialCompleted` 还是 `Completed`。
|
||
|
||
2. 冻结 AI 报告的结构化 Schema。
|
||
需要从“模块要求”进一步收敛到“字段契约”，否则开发和提示词工程很难稳定。
|
||
|
||
3. 明确搜索、登录检查和抓取校验的交互顺序。
|
||
这会直接影响任务入口、异常提示和用户操作成本。
|
||
|
||
4. 明确失败重试与报告版本策略。
|
||
否则历史任务页和报告页的“回看”语义会变得不稳定。
|
||
|
||
5. 补充质量类成功指标。
|
||
让 MVP 不只看“任务跑完没有”，还看“跑出来的对象和结论是否可信”。
|
||
|
||
## 6. 建议补进下一版 PRD 的补充口径
|
||
|
||
以下内容可以直接演化为下一版 PRD 的补充条款。
|
||
|
||
| 模块 | 建议补充口径 |
|
||
| --- | --- |
|
||
| 状态机 | 每个任务维护一个 `task_status`，每个平台维护一个 `platform_status`；任务最终状态由平台状态汇总决定 |
|
||
| 搜索前检查 | 明确平台可用性提示的来源，是静态能力检查、登录态检查，还是最近一次访问结果 |
|
||
| 报告结构 | 为报告定义固定字段，如 `summary`、`platform_insights[]`、`positive_themes[]`、`negative_themes[]`、`evidences[]`、`confidence` |
|
||
| 证据引用 | 证据引用至少包含平台、链接、评论 ID 或评论索引、抓取时间，避免“有引用但无法定位原证据” |
|
||
| 失败重试 | 重试失败平台后，保留旧报告快照，并对新报告标记版本号与更新时间 |
|
||
| 质量指标 | 增加人工抽检指标，如候选确认准确率、证据引用有效率、报告被采纳率 |
|
||
|
||
## 7. 最终判断
|
||
|
||
这份 PRD 的方向是对的，而且已经解决了前一版需求文档中大部分真正会阻塞开发的定义缺口。当前版本已经足以支持原型设计、数据模型初稿和任务流程拆解。
|
||
|
||
剩下的问题不在于“还差很多功能点”，而在于“还差少数几个会决定实现一致性的硬约束”。只要把状态粒度、报告 Schema 和搜索/登录顺序这三个问题继续收紧，这份文档就可以作为 MVP 研发和验收的正式基线文档。
|