AppSignal 案例：隐私政策解读平台的产品决策复盘
一句话定位：用 AI 把几千字的隐私政策原文，浓缩为一张用户可快速理解的风险信息卡片。
一、项目背景与缘起
1.1 为什么做这个产品
隐私政策是每个 App 用户都会遇到但几乎不会去读的东西。原因很直接：
- 篇幅长：主流 App 的隐私政策通常在 3000–8000 字
- 术语密集："数据处理者"、"第三方共享"、"自动化决策"——每个词都可能涉及法律概念
- 关键条款分散：用户最关心的"你拿了我什么数据"和"我的数据会卖给谁"藏在不同段落里
- 理解门槛高：即便读完了，也很难判断"这对我意味着什么"
市场上已有的解决方案要么是纯法律视角（律师解读），要么是过于简化的评分（只看有没有某个条款），缺乏一个面向普通用户的结构化分析工具。
产品核心假设：如果能把隐私政策的关键风险点提炼成一张"信息卡片"——风险等级 + 一句话结论 + 关键发现 + 白话摘要——用户就能在几十秒内做出基本判断。
1.2 产品目标
- 用户侧：按 App 名称搜索，快速获取隐私风险分析结果
- 运营侧：AI 初稿 + 人工复核的流水线，确保发布内容的质量
- 闭环机制：用户可提交新 App 进入审核，开发者可对结果提出申诉
二、产品定位决策
2.1 核心价值主张
"几秒钟看懂一个 App 隐私条款的关键风险点，而不是让用户自己啃几千字原文。"
产品不做"法律顾问"，不做"合规检测工具"，而是做一个信息翻译器——把法律语言翻译成普通用户能理解的语言。
2.2 目标用户分层
| 用户 | 场景 | 核心需求 |
|---|---|---|
| 普通用户 | 下载新 App 前想了解隐私风险 | 快速判断"安不安全" |
| 运营/审核人员 | 后台管理分析内容 | 高效审核 + 批量操作 |
| 开发者 | 发现自己 App 的分析结果有误 | 申诉通道 + 后台闭环处理 |
2.3 边界声明（关键产品决策）
产品从一开始就明确了边界：
- 平台内容基于公开信息处理与整理，仅供参考
- 平台不构成法律建议、合规建议或专业意见
- 部分内容由 AI 生成，可能存在理解偏差
- 应用名称、图标、商标归各自权利方所有
这不是免责声明凑字数，而是产品定位的核心决策：我们不充当"裁判"，而是做"翻译"。
三、核心产品决策复盘
决策 1：AI 介入方式 —— 辅助工具，非替代者
决策内容：AI 负责初稿分析，人工负责最终审核发布。
为什么这样选：
隐私政策分析涉及法律判断，完全交由 AI 的风险太高——幻觉可能导致错误的风险评级，遗漏可能遗漏关键条款。但完全人工分析又无法规模化。
决策权衡：
- AI 模型选 DeepSeek Chat（中英文都支持，成本可控）
- 调用方式：用户提交后实时调用（非离线批处理），120s 超时
- 降级策略：无 API Key 时用本地规则引擎
fallback_analysis()兜底
效果：AI 完成 80% 的初稿工作，运营人员只需审校关键判断和补充细节。
决策 2：AI 初稿 vs 人工定稿的双轨存储
决策内容：每个 App 独立存储 analysis（当前版本，可人工编辑）和 analysisSource（AI 初稿，可一键恢复）。
为什么这样选：
运营同学编辑后，如果发现改错了或者想恢复 AI 版本的某个判断，需要能"反悔"。双轨存储让这个操作成本降到一次点击。
替代方案 vs 选择理由：
| 方案 | 问题 |
|---|---|
| 只存 AI 结果，人工直接改 | 无法恢复，改错成本高 |
| 存完整历史版本 | 存储膨胀，恢复操作复杂 |
| 双轨存储（选择） | 只需维护两版，恢复路径清晰 |
效果：运营同学可以放心编辑，知道随时可以"回到 AI 初稿"。
决策 3：风险评分双轨制
决策内容：AI 输出风险等级的同时，本地规则引擎 _rubric_risk_level() 也独立打分，最终取二者中的较高者。
为什么这样选：
AI 有时会过于"乐观"——比如面对一个模糊的条款，AI 可能倾向于给"低风险"而非"中风险"。规则引擎作为第二道防线，确保确定性规则不被绕过。
评分维度（共 7 项）：
| 维度 | 说明 |
|---|---|
| 数据收集范围 | 收集了哪些类型的数据 |
| 数据共享情况 | 是否与第三方共享，是否出售 |
| 数据保留期限 | 保留多久，是否明确说明 |
| 用户权利 | 是否提供访问、删除、更正等权利 |
| 儿童隐私 | 是否涉及儿童数据，是否有特殊保护 |
| 跨境传输 | 数据是否出境，是否有安全措施 |
| 政策清晰度 | 表述是否清晰易懂 |
效果：双重校验让风险评级更加稳健，降低了 AI 误判的影响。
决策 4：确定性法律判断过滤
决策内容：AI 输出后，自动替换确定性法律判断用语。
- "违法" → "可能涉及合规风险"
- "非法" → "可能不符合相关要求"
为什么这样选：
AI 可能会输出绝对化的法律判断（"这个条款违法"），这在法律上是危险的——产品不能替代律师。通过后处理过滤这些用语，在产品层面规避法律风险。
决策 5：提交 → 审核 → 申诉的闭环流程
决策内容：用户提交新 App → 自动抓取隐私政策原文 → AI 分析 → 运营审核 → 发布。开发者可申诉。
用户提交 App URL
│
▼
Policy Fetcher 自动抓取政策文本（HTML / PDF）
│
▼
AI 分析 → 生成初稿（analysisSource）
│
▼
status = 'review_ready' ← 等待运营审核
│
▼
运营后台：
├─ 查看/编辑分析结果
├─ 恢复到 AI 初稿
├─ 重新分析
├─ 通过/驳回/退回
│
▼
发布 → 前台可见关键设计点：
- 自动抓取 vs 手动提交：用户只需给 URL，系统自动完成后续所有步骤
- 状态机设计：
pending → processing → review_ready → approved/rejected/needs_revision - 开发者申诉独立流程：
submission: pending → processing → resolved/rejected- 申诉包含证据 URL 和问题描述
- 内置时间线追踪处理过程
- 状态变更后自动邮件通知
决策 6：后台管理功能的范围
决策内容：后台提供 16 个管理页面，覆盖从内容生产到运营管理的全流程。
| 功能 | 解决的问题 |
|---|---|
| 分析工作台 | 运营可手动输入 URL 或粘贴文本触发 AI 分析 |
| APK 分析 | 上传 APK 文件，静态分析权限声明（androguard） |
| 批量抓取 App Store ID | 输入应用名称列表，自动查询 App Store 信息 |
| 任务队列 | 查看后台任务状态，支持失败重试 |
| 审计日志 | 所有操作可追溯 |
| 站点设置 | 免责声明文本、SMTP 配置、邮件模板等可配置 |
取舍考量：后台功能虽然多，但没有做消息队列（Celery/Redis Queue）——所有异步任务直接用 Python async/await 实现。这是为了减少基础设施依赖，简化部署（Docker Compose 三服务搞定）。
四、踩坑与教训
坑 1：隐私政策格式千奇百怪
不是所有隐私政策都是干净的 HTML。遇到过的格式：
- 纯 PDF 文档（需要 pypdf 解析）
- 嵌套在 iframe 里的隐私政策
- 需要滚动加载的动态页面
- 多语言混排（中文政策里夹英文条款）
教训：政策抓取模块需要健壮的 fallback 策略，不应假设输入格式。
坑 2：AI 对法律用语的过敏反应
AI 在某些法律用语上会输出"过于保守"或"过于激进"的判断。比如"我们可能收集您的设备信息"——AI 可能判断为"高风险"，但实际上是行业标准做法。
教训：AI 分析需要结合行业标准（baseline），而不是孤立地分析文本。
坑 3：首次分析自动发布的风险
最初的设计是 AI 分析后自动发布，运营只需在后台查看。但实际发现 AI 的误判率足以影响用户体验——一个误标为"高风险"的 App 会让用户产生不必要的担忧。
决策修正：改为"AI 分析 → 人工审核 → 手动发布"流程，即使这意味着发布延迟。
坑 4：多源数据冲突
当同一个 App 有不同版本的隐私政策时（比如不同国家/地区的版本），分析结果可能不一致。当前没有做版本比对。
待解决问题：需要引入 PolicyVersion 模型来追踪版本历史和支持 diff 比对。
五、对其他 AI PM 的启发
1. AI 产品的"人工审核"不是降级方案，而是核心竞争力
太多 AI 产品追求"全自动"，但 AppSignal 证明了 AI + 人工审核的混合模式在产品可靠性上更具竞争力。AI 降低边际成本，人工保障最终质量。
2. "不做某事"的决策比"做某事"更重要
明确边界（不提供法律建议、不充当裁判）不仅降低了法律风险，更重要的是让产品定位更清晰。用户知道这个产品是"翻译工具"而非"律师"。
3. 双轨制是 AI 产品的经典模式
analysis + analysisSource 的双轨存储、AI + 规则引擎的双重评分、AI 初稿 + 人工定稿——这些双轨设计让 AI 产品在"效率"和"可靠性"之间找到了平衡点。
4. 产品流程的闭环设计
用户不只是消费内容，还可以提交新 App、发起申诉。这个闭环让产品从"静态数据库"变成了"动态社区平台"，用户参与的每一项都有明确的流程和反馈机制。