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

1.1- 产品定位

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

1.2- 目标用户画像

主要用户：

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

痛点：

• 传统 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- 风险与应对

风险	缓解方案
大模型 API 成本高	1. 本地预处理过滤空白图 2. 设置月度用量上限 3. 探索混合架构
数据隐私问题	1. 强制匿名化处理 2. 用户协议明确说明 3. 提供纯本地模式选项
特殊格式识别失败	1. 保留传统 OCR 作为 fallback 2. 允许用户手动输入
API 服务不稳定	1. 实现重试机制 2. 引入备用模型供应商

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. 国际化: 支持更多国家和地区的货币、语言和小票格式。