产品需求文档（PRD）
1. 背景与目标
小团队的用户反馈分散、无结构、轻重混杂。FeedLens v0.1 要验证一件事：一个可以本地运行的 64M 小模型，能否把短反馈整理成可统计、可排序的结构，并且质量明显好于关键词规则。
v0.1 的成功不以用户量衡量，而以三个问题是否有了基于证据的答案来衡量：
- 模型在独立测试集上达到预设标准了吗？（见 项目背景 的 A1–A5）
- 一个陌生访客能在两分钟内理解它是做什么的、并亲手跑通一次吗？
- 它在哪些情况下不可靠，说清楚了吗？
2. 用户与场景
主要用户：小团队产品经理。主要场景：每周把一批评论贴进来，快速找出最急的问题和类别分布。详见 用户与场景分析。
3. 任务定义
输入：一条中文反馈，2–140 字。
输出：
| 字段 | 取值 | 定义 |
|---|---|---|
| 类别 | 功能故障 / 性能体验 / 功能建议 / 界面交互 / 账号登录 / 支付订单 / 广告骚扰 / 表扬认可 / 其他 | 用户最主要的诉求；并列时取影响更严重的一项 |
| 情感 | 正面 / 中性 / 负面 | 报告问题或不满=负面；建议、咨询且无明显不满=中性；认可、感谢=正面 |
| 紧急度 | 高 / 中 / 低 | 高=核心流程被阻断、资金损失、数据丢失、账号安全；中=功能或体验明显受损但仍可用；低=不影响使用 |
| 摘要 | 不超过 20 字 | “发生了什么 / 想要什么”，不带情绪词，能直接作工单标题 |
为什么是这四个字段：类别回答“归谁处理”，紧急度回答“先处理谁”，情感用于统计口碑走向，摘要用于免去重读原文。再多的字段（如涉及的功能模块、设备型号）需要实体抽取，超出了 v0.1 小模型的可靠范围。
为什么限制 140 字：训练数据的长度分布集中在 50 字以内；限制输入长度是在告诉用户模型的能力边界，而不是让它对长文本给出没有依据的结果。
为什么输出是四行文本而不是 JSON：MiniMind 的词表只有 6400，引号、花括号这类符号会被切成零碎的 token，增加出错位置。固定的“字段名：值”四行格式更短，也更容易校验。解析成 JSON 由程序完成（feedlens/schema.py）。
4. 功能需求
优先级：P0 = v0.1 必须有；P1 = 应该有；P2 = 后续版本。
4.1 单条分析（P0）
| 编号 | 需求 | 验收标准 |
|---|---|---|
| F1 | 输入一条反馈并提交 | 文本框带字数计数；支持按钮和 Ctrl/⌘+Enter 提交 |
| F2 | 展示四个字段 | 类别、紧急度以标签呈现，摘要为主视觉；同时展示原文 |
| F3 | 加载状态 | 提交后按钮禁用并显示加载动画，结果区显示骨架屏 |
| F4 | 输入校验 | 少于 2 字或超过 140 字时不发请求，就地提示原因 |
| F5 | 透明度 | 可展开查看模型原始输出、耗时、生成 token 数 |
| F6 | 格式失败的处理 | 模型输出不合规时明确告知，展示原始输出，不做任何兜底替换 |
| F7 | 示例 | 提供若干可点击示例，一点即填入并分析 |
| F8 | 规则基线对照（P1） | 可展开查看规则基线的结果，与模型不一致的字段高亮，并标注“非模型” |
4.2 批量分诊（P0）
| 编号 | 需求 | 验收标准 |
|---|---|---|
| B1 | 每行一条，最多 50 条 | 实时显示条数；超限或单条超长时提示具体是第几条 |
| B2 | 结果按紧急度从高到低排序 | 高紧急度在最前；格式失败的排在最后并标明 |
| B3 | 汇总 | 总数、高紧急度条数、负面占比、格式未通过条数；类别分布条形图 |
| B4 | 导出 | 一键导出 CSV（UTF-8 带 BOM，表格软件可直接打开） |
4.3 评测结果页（P0）
| 编号 | 需求 | 验收标准 |
|---|---|---|
| E1 | 展示各系统在两份测试集上的指标 | 数据从后端读取评测输出文件，页面不写死任何数字 |
| E2 | 说明数据性质 | 页面明确写出训练和测试数据均为合成数据 |
| E3 | 没有结果时 | 显示“尚无评测结果”和生成方法，而不是空表或示例数字 |
4.4 模型状态与演示模式（P0）
| 编号 | 需求 | 验收标准 |
|---|---|---|
| M1 | 顶栏常驻模型状态 | 已加载：模型名、版本、设备；未加载：显示“演示数据” |
| M2 | 演示模式 | 找不到权重时服务仍能启动；页面顶部出现横幅；只能查看预置示例，每张结果卡带“演示数据”戳记 |
| M3 | 接入真实权重 | 只需设置一个环境变量指向模型目录并重启，无需改代码 |
4.5 接口（P1）
| 接口 | 用途 |
|---|---|
GET /api/status |
模型是否加载、版本、限制、标签集合 |
POST /api/analyze |
单条分析 |
POST /api/analyze_batch |
批量分析与汇总 |
GET /api/eval |
评测结果摘要 |
5. 非功能需求
| 类别 | 要求 |
|---|---|
| 延迟 | CPU 上单条请求 P95 < 500 ms |
| 资源 | 不需要 GPU；内存占用在普通笔记本可接受范围内 |
| 可用性 | 窄屏（手机）下所有功能可用，表格可横向滚动 |
| 可访问性 | 键盘可操作，有焦点样式，结果区域使用 aria-live |
| 安全 | 所有用户输入和模型输出以纯文本渲染，不拼接 HTML；权重加载只反序列化张量 |
| 诚实 | 任何非模型产生的内容（演示数据、规则基线）都有明确标注 |
6. 不做什么
| 不做 | 原因 |
|---|---|
| 接入应用商店、客服系统等数据源 | 先验证核心能力；渠道接入是工程量，不是不确定性所在 |
| 多标签 / 一条反馈拆成多个诉求 | 会显著增加任务难度，小模型能否胜任需要单独验证 |
| 相似反馈聚类、趋势图 | 需要向量检索或额外模型，属于下一阶段 |
| 用户账号、历史记录 | 与验证目标无关 |
| 用规则或大模型对模型结果做自动修正 | 会让“模型到底行不行”变得说不清 |
7. 指标
| 层面 | 指标 | 目标 | 数据来源 |
|---|---|---|---|
| 模型 | 格式合规率、三标签全对率、摘要 ROUGE-L | 见 A1–A4 | eval/results/ |
| 性能 | 单请求 P95 延迟 | < 500 ms | eval/results/ |
| 产品（待上线后收集） | 批量分诊后用户修改标签的比例；摘要被直接采用的比例 | 待定 | 需要埋点，v0.1 未实现 |
8. 风险
| 风险 | 影响 | 应对 |
|---|---|---|
| 合成数据与真实反馈差距大 | 线上效果远低于测试集 | 额外建一份不经过语法的手写测试集；文档与页面明确标注；把获取真实数据列为首要待办 |
| 用户过度信任结果 | 漏掉被错判为低紧急度的严重问题 | 始终展示原文和原始输出；说明卡写明不能用于自动决策 |
| 类别体系不符合实际 | 大量反馈落入“其他” | 类别集中定义在一处；用真实数据验证 H3 |
9. 功能验收记录
验收方式和结果见 项目复盘 的“实际执行过的验证”一节。
本页由 docs/04-prd.md 生成。