1. 基于大模型的拍照记账应用 PRD 方案

1.1. 产品定位

一款利用大模型能力实现高精度价格单识别的智能记账工具，解决传统 OCR 在复杂小票识别上的不足，提供更自然的交互方式。

1.2. 目标用户画像

1.2.1. 主要用户

• 时间敏感的商务人士/自由职业者： 需要快速、准确记录出差、报销产生的费用，不愿花费时间手动输入。
• 注重效率的家庭记账者： 希望简化日常购物、餐饮等小票的记录过程，方便家庭预算管理。
• 追求新技术体验的用户： 对 AI 技术有兴趣，愿意尝试基于大模型的智能工具。

1.2.2. 痛点

• 传统 OCR 识别不准，需要大量手动修改。
• 记账流程繁琐，容易遗漏或放弃。
• 希望记账工具能更智能地理解消费内容。

1.3. 核心价值主张

1. 复杂小票的智能理解：利用大模型处理各种非标准格式的价格单，显著提升识别准确率。
2. 上下文感知：自动识别商品类别、商家类型等上下文信息，减少用户分类负担。
3. 自我进化：通过用户反馈持续优化识别准确率，越用越精准。

1.4. 竞品分析（简要）

• 传统记账 App (无 OCR 或弱 OCR)： 用户需要手动输入，效率低。
• 带传统 OCR 的记账 App： 对标准格式小票识别尚可，但对复杂、模糊、手写等情况识别率低，修正成本高。
• 通用型 OCR 工具： 只能提取文字，无法结构化理解小票内容。

本产品优势： 专注于利用大模型在复杂小票理解上的突破，提供更智能、更少人工干预的记账体验。

1.5. 用户旅程

[拍照] → [大模型解析] → [智能填充] → [用户确认/修正] → [记账完成]

1.6. MVP 功能清单

1.6.1. 大模型集成模块

• 输入：用户拍摄的价格单图片

• 处理：

  • 图片预处理（自动裁剪、旋转校正）
  • 调用多模态大模型 API（如 GPT-4 Vision、Claude 3 等）
  • 结构化输出解析

• 输出：(示例)

  {
    "merchant_name": "沃尔玛",
    "transaction_date": "2023-11-20",
    "items": [
      {"name": "纯牛奶", "price": 12.5, "quantity": 2, "category": "食品"},
      {"name": "洗发水", "price": 45.0, "quantity": 1, "category": "日用品"}
    ],
    "total_amount": 70.0
  }
  

1.6.2. 智能交互层

• 自动补全：基于历史数据和上下文信息，智能补全商家/商品名称、类别等信息。
• 模糊匹配：“鲜奶 250ml” → 建议匹配为"蒙牛纯牛奶 250ml 装"（从用户历史记录或商品库中匹配）。
• 疑问标注：对大模型识别结果中置信度较低的字段（如价格、数量）进行特殊颜色或图标标记，提示用户重点核对。
• 一键确认/批量修改：提供便捷的操作流程，用户可以快速确认整条记录，或集中修改有疑问的字段。

1.6.3. 反馈学习机制

• 反馈收集：用户在核对识别结果界面进行修改（如更正金额、修改商品名称、重新选择类别）或补充信息的操作，将被视为一次有效反馈。系统需明确告知用户其修正操作可能被用于改善服务，并提供关闭此功能的选项。
• 数据处理：用户修正数据经过严格的匿名化和脱敏处理（例如，移除用户标识，对商家、商品名等进行泛化处理或仅保留结构化关系）后，形成高质量的结构化数据集。
• 模型优化：定期利用该数据集对大模型进行 fine-tuning 或用于训练后处理校准模型。
• 效果闭环：通过模型版本迭代或云端动态更新，将学习成果应用到新的用户识别中，用户应能感知到识别准确率的提升。

1.7. 技术实现路径

1.7.1. 阶段 1：云端原型（快速验证）

• 使用现成大模型 API

• Prompt 示例 (供参考):

  请识别这张图片中的小票信息，并将其转换为 JSON 格式。JSON 应包含以下字段：
  - `merchant_name`: 商家名称 (字符串)
  - `transaction_date`: 交易日期 (字符串, 格式 YYYY-MM-DD)
  - `items`: 商品列表 (数组), 每个商品对象包含:
      - `name`: 商品名称 (字符串)
      - `price`: 商品单价 (数字)
      - `quantity`: 商品数量 (数字, 如果未明确数量则默认为 1)
      - `category`: 商品类别 (字符串, 尝试根据商品名推断，例如：食品、饮品、日用品、餐饮、交通等)
  - `total_amount`: 小票总金额 (数字)
  
  请尽可能准确地提取信息。如果某些信息无法识别，请将对应字段值设为 null。
  

• 示例调用流程:

  # 伪代码示例
  def parse_receipt(image):
      # 调用多模态大模型
      response = gpt4_vision_api(
          image=image,
          prompt="[此处填入设计的详细 Prompt]" # 使用上面或更优化的 Prompt
      )
      
      # 后处理
      try:
          # 尝试解析 JSON，并可加入校验逻辑
          parsed_data = json.loads(response)
          # validate_receipt_data(parsed_data)
          return parsed_data
      except Exception as e:
          # log error
          return manual_fallback(image) # 调用失败或解析失败时的处理
  

1.7.2. 阶段 2：混合架构（成本优化）

• 本地轻量 OCR 预处理
• 关键字段大模型精修
• 缓存常用商家的解析模板

1.7.3. 阶段 3：端侧优化（可选）

• 蒸馏后的小模型部署
• 特定场景的量化模型

1.8. 非功能性需求

1. 安全性： 用户财务数据、小票图片等敏感信息需加密存储和传输，确保数据隐私。提供匿名化处理选项。
2. 性能： 图片上传、大模型调用、结果返回及渲染的整体处理耗时需控制在用户可接受范围（如网络良好时小于 5 秒）。
3. 稳定性/可靠性： 系统应具备高可用性，大模型 API 调用失败时应有 fallback 机制（如提示重试、转为手动输入、使用传统 OCR 等）。
4. 可扩展性： 架构设计需考虑未来支持更多票据类型、更多账本功能、多平台同步等。
5. 易用性： 界面设计简洁直观，拍照、识别、修改、记账的流程顺畅。

1.9. UI/UX 设计原则（新增章节）

• 简洁直观：核心流程（拍照 -> 确认 -> 记账）的操作步骤应尽可能少，界面元素清晰明了。
• 高效修正：对于模型识别不准或需要补充的信息，提供便捷的编辑入口和交互方式。
• 智能引导：在拍照环节提供实时引导（如对齐线、光线提示），提高图片质量。对低置信度的识别结果进行视觉高亮。
• 一致性：整体设计风格和交互模式保持统一。
• (注：具体界面设计详见 [链接到 UI 设计稿/原型])

1.10. 关键指标

1. 核心字段首次识别准确率 (Precision): >85%（总价、商品名称、单价、数量）。
2. 核心字段首次识别召回率 (Recall): >90%（衡量模型是否漏掉了应识别出的信息）。
3. 用户平均单条记录修正字段数: < 1 个。
4. 单次处理平均耗时: <5s（网络良好时）。
5. 用户留存率 (Retention Rate): 次周留存 > 40%，月留存 > 20% (示例目标)。
6. 用户反馈有效率: 用户修正的数据被用于模型优化的比例 > 70%。
7. 识别准确率随时间变化趋势: 监控准确率是否随用户反馈数据的积累而提升。

1.11. 风险与应对

1.12. 迭代计划（细化）

1. V0.1 (技术原型)：实现核心功能：上传单张图片 -> 调用大模型 API -> 解析并输出结构化 JSON 数据。内部验证识别效果。
2. V0.5 (MVP App)：开发 Android/iOS 端应用，集成 V0.1 功能，实现拍照、大模型解析、结果展示（基础列表），支持手动修改并保存为记账记录。支持基础账本功能。
3. V1.0 (用户闭环)：
   • 集成用户反馈机制：用户修正的字段、新增的商品分类等信息将被记录（需用户同意并提供设置开关）。
   • 优化智能交互层：实现"疑问标注"（低置信度字段提示）和"模糊匹配提示"（基于历史数据推荐相似条目）。
   • 初步建立反馈数据处理流程（匿名化、脱敏），为模型 fine-tuning 做准备。
   • 支持至少 5 种常见类型小票（超市、餐饮、加油站、出租车/网约车、在线购物订单截图）。
4. V1.5 (功能增强)：
   • 探索支持自定义识别模板功能（例如，用户可以针对常用但格式特殊的小票进行一次性"校准"，保存优化后的识别规则）。
   • 加入离线记账模式：无网络时支持拍照和基础手动录入，待有网络时自动或手动触发上传识别。
   • 考虑支持多账本/账户管理。
   • 初步尝试支持标准电子发票（如 PDF 或特定版式图片）的识别。
5. V2.0+ (持续优化)：
   • 集成更丰富的记账分析功能（如预算管理、消费报表）。
   • 根据成本和性能数据，评估并实施混合架构或端侧优化方案。
   • 支持更多语言/地区的小票。
   • 深化电子发票、行程单等更多票据类型的识别。

1.13. 商业模式思考（新增章节）

• 初期 (MVP)：免费提供核心功能，聚焦用户增长和产品打磨。
• 中期：
  • 免费增值 (Freemium)：基础识别和记账功能免费，提供高级功能（如无限量票据识别、高级报表、多账本、云同步空间扩容、自定义模板等）作为付费订阅。
  • 用量限制：对免费用户设定每月识别次数或图片数量上限。
• 长期：探索企业报销服务、API 输出等 B 端商业模式。

1.14. 错误处理与边缘场景

1. 图片质量问题：
   • 模糊/反光/角度过大：提示用户重新拍摄，提供拍摄引导（如保持垂直、光线充足）。
   • 非小票图片：模型或预处理层尝试判断，若非小票则提示用户上传有效图片。
   • 图片过大/格式不支持：前端进行压缩或格式检查，提示用户。
2. 大模型 API 调用失败：
   • 网络超时/错误：提示用户检查网络并提供重试按钮。多次失败后可建议稍后重试或转为手动记账。
   • API 返回错误/无法解析：记录错误日志，向用户显示通用错误提示，并引导至手动模式。考虑提供 fallback 到基础 OCR 或纯手动。
   • API 额度用尽：提示用户（如适用免费额度），引导升级或等待额度恢复。
3. 识别结果不佳：
   • 关键信息缺失：允许用户手动补充。
   • 识别错误：用户可方便地修改字段内容。
   • 完全无法识别：提供清晰的"跳过识别，转为手动记账"选项。
4. 用户数据同步失败：
   • 本地缓存机制，网络恢复后自动或手动同步。
   • 提供同步状态指示和手动同步入口。

1.15. 未来展望

1. 智能预算与分析：基于记账数据，提供智能化的预算建议、消费分析和财务预警。
2. 多平台同步：支持 Web 端、小程序等，实现数据跨平台同步。
3. 生态整合：对接银行账户、信用卡账单、第三方支付平台（如支付宝、微信账单），实现自动入账。
4. 企业报销场景：探索面向企业的报销管理功能。
5. 个性化模型：为高频用户或付费用户提供基于其个人数据的个性化 fine-tuned 模型，实现更高精度。
6. 国际化：支持更多国家和地区的货币、语言和小票格式。