离线名片提取：审核 OCR 字段并生成 vCard 联系人草稿

直接回答

名片提取在 OCR 之后还有一层重要边界：识别出的字符必须映射到联系人交换格式，且不能猜测缺失的身份信息。OCR 只是候选文本来源，不是最终联系人。将每个建议字段关联到原始识别行或图像区域，让审核者知道姓名、公司、职位、邮箱或电话确实出现在哪里。保留可见拼写和 Unicode 字符。如果卡片只有一个显示姓名，不要擅自拆成名和姓；如果有两个号码或地址，要先保留两个候选，让用户决定如何处理。 vCard 4.0 是表示个人或其他实体的标准格式，可表达姓名、组织、地址、邮箱以及多个电话。应将审核通过的字段映射到对应属性，并在印刷内容明确提供时保留电话或邮箱类型、首选顺序等有意义参数。不要把 Logo、职位或网站误映射成姓名字段。生成文件时要遵循 RFC 的文本转义、字符编码和长行折叠规则。每个 vCard 4.0 对象都必须紧跟 BEGIN:VCARD 写 VERSION:4.0，并包含必需的 FN 格式化姓名。N 是含五部分的结构化姓名字段；只有来源能支持时才填写，未知部分留空，不要推断。RFC 6350 建议按不超过 75 个 octet 折行，而非 75 个 Unicode 字符，并且不能拆开 UTF-8 多字节序列。Android Contacts Provider 的 API 示例不能证明每款联系人应用或导入器都接受 vCard 4.0 或多个预填电话号码；要在目标应用中实测往返，显示被拒绝或未处理的字段，并保留可审核草稿作为备用。vCard 结构有效，只说明格式可解析；它不证明 OCR 值正确，也不代表联系人同意保存。 识别字段和联系人映射应分开。OCR 可以返回 blocks、lines、elements 等文本结构，联系人则有自己的字段 schema 和多值规则。一行里出现两个电话号码时，可以保留为两个 TEL 属性；“Mobile”等标签只有在关联明确时才能用于类型。公司和个人姓名可能并排出现。若布局存在歧义，应保留为待选择项，而不是按常见卡片样式猜测。审核时可显示原始识别文本，但不要把它写入普通诊断日志。 联系人草稿比静默写入更安全。Android Contacts Provider 提供结构化联系人数据，并支持通过设备联系人应用的 Intent 添加条目。工作流可以先显示预填草稿供用户检查和保存。启动前允许用户检查字段映射、删除不需要的信息、修正拼写或取消。不能只因显示姓名相同就自动把候选合并进已有联系人：同名者可能是不同的人，一张名片也可能有共享公司电话。任何重复项提示都应可由用户审核并撤销。 把图片和提取出的联系方式视为敏感用户数据。说明原图是否留在设备、何时删除临时裁剪图或 OCR 文本、导出是否生成独立副本。“端侧”只描述推理位置，不证明整个应用没有其他网络或备份行为。交给联系人应用时，核对目标账号与同步设置：保存后的联系人可能由接收应用同步到其他服务。这一目的地要与本地 OCR 分开说明，也不能承诺控制另一个应用的留存行为。优先使用用户选定的本地图像、可见草稿和明确保存/导出动作。不得暗示本仓库或 Cove Photo 已实现名片扫描、vCard 导出或 Contacts Provider 集成。 用合成名片验证完整管线，不要宣称准确率。样例应包含单一显示姓名、不应重排的姓/名、多组电话、工作邮箱、带重音或非拉丁字符的姓名、需要 vCard 转义的标点、需要折行的长字段、Logo、空字段和刻意含糊的文字布局。分别断言解析出的属性和往返序列化结果，再测试审核、修正、取消、vCard 导入及 Android 联系人草稿跳转。测试记录说明流程在哪里受测，不代表跨设备、语种、光线或卡片样式的 OCR 准确率。 完整实现路径从拍照或选文件开始，保留 OCR 证据，提出字段映射，用户确认后再序列化并验证联系人应用交接。如果用户需要文件，提供带预览的 vCard 和明确目的地；如果只想添加联系人，则走平台联系人插入流程，由用户在联系人应用中提交。把“已识别”“已映射”“已审核”和“已保存”作为不同状态，这样未完成的扫描不会伪装成联系人已创建。

用户扫描一张印有两个电话号码的名片

用户选择了本地保存的名片图片。OCR 识别出姓名、公司、职位、两个带有不同印刷标签的电话号码和一个邮箱。姓名含重音符号，旁边的网站地址又与公司一行很近。应用需要准备有用的联系人草稿，但不能猜字段关系或自动写入通讯录。

决策

保留 OCR 文本及字段来源，只把关系清楚的值映射到 vCard 属性；将网站关联和不确定姓名部分留给用户审核；只有用户确认字段集合后才打开预填联系人草稿。

预期结果

用户可以在保存前修正或移除字段。导出的 vCard 保留多个电话号码和 Unicode；记录不宣称 OCR 准确率，也不把该流程说成现有 Cove 功能。

需要收集的证据

只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：

• OCR-DEDICATED-01：ML Kit 将识别文字组织为 blocks、lines、elements 等结构单元。
• PRIVACY-01：本地推理不证明应用没有其他网络或数据路径。

任务质量需要有版本记录的语料和验收规则；流畅的单条样例不等于准确度结果。

实施流程

1. 选择本地来源并保留识别依据. 记录选中的图片来源以及裁切、旋转变换。审核期间让每个识别 block 和 line 都能关联到图像区域。不要把名片内容写入诊断日志；临时裁剪图的留存时间应符合事先说明的任务策略。
2. 提出字段候选但不补造缺失信息. 映射可见姓名、组织、职位、电话、邮箱和网站。保留多值及其印刷标签。姓名拆分关系不明确或原文没有结构化部分时保持空缺，不按照常见名片布局推断。
3. 构建符合标准的 vCard 表示. 将审核过的值映射到 vCard 4.0 属性；只有来源明确支持时才保留 TYPE 或 PREF；正确编码 Unicode、转义文本并按规范折叠长行。格式校验与内容是否经用户确认是两项不同检查。
4. 显示可审核的联系人草稿. 把每个建议字段和 OCR 来源并列显示，允许编辑、移除或取消，并标出含糊字段与可能重复项。如果用户选择创建 Android 联系人，将预填草稿交给联系人应用，并由用户最终决定是否保存。
5. 测试导出、导入和删除路径. 用合成夹具往返序列化 vCard，并检查包含姓名、多号码、邮箱和 Unicode 的联系人草稿。验证取消、临时图像清理，以及删除来源图片后单独导出的文件是否仍保留。

让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。

验收标准

• 每个联系人字段都可追溯到识别文本，或明确保持为空/歧义；不会编造缺失的姓名组成部分。
• vCard 4.0 输出保留 Unicode 和多个电话/邮箱属性，并且其结构解析与 OCR 内容正确性分开验证。
• 不会静默保存或合并联系人；用户可以检查、修正、移除、取消，并明确提交草稿或导出文件。

决策对照表

需要避免的失败模式

• 把 OCR 识别直接当成已确认联系人
• 根据常见卡片布局猜测姓名或号码关系
• 忽略 vCard 字符转义与长行折叠

还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。

最小复现记录

发布检查表

• ☐ 主要搜索问题已回答，且没有未经支持的数字。
• ☐ 所有模型文件和运行时版本均已固定。
• ☐ 代表性任务和失败处理策略均有说明。
• ☐ 生命周期、取消、清理和回退均已测试。
• ☐ 用户内容与网络边界均有说明。
• ☐ 结论只适用于被记录的配置。
• ☐ 新增测试结果时链接到原始方法或证据。

来源与相关证据

• ML Kit text recognition
• IETF RFC 6350：vCard 4.0 数据格式
• Android Developers：Contacts Provider 与插入 Intent
• Android API：ContactsContract

中文部署与排错专题见。奇连 AI 端侧专题。

常见问题