直接回答
发行声明审核应从用户实际拿到的内容开始，而不仅看直接依赖文件或模型卡。一个 Android 本地 AI 功能可能包含应用代码、传递依赖、原生运行时、分词器或图像处理器、转换工具、随包资源，以及安装后下载的文件。这些组件可能由不同组织发布并适用不同条款。应为每个发行变体建立清单，把每项内容绑定到准确版本、来源和交付路径。源码包、APK、App Bundle 分包和单独下载的模型包未必包含相同组件。 对每项内容保存上游许可原文或权威条款链接、适用的版本/修订、准确匹配时的机器可读标识符，以及文本中明确要求的声明、署名、源代码提供、修改标记或再分发条件。SPDX 标识有助于一致识别常见许可文本；它不能解释某个自定义模型协议，也不能证明标识填对了。如果准确制品的许可含糊，就记录问题并暂停“已获准”结论。模型家族名称下的基础版、指令版、量化版或转换文件可能来源和条款不同。 软件依赖、模型制品和构建工具要分开盘点。转换器可能只在构建时使用、不随应用分发，但转换输出仍需溯源和许可审核。按需下载的模型即使不在 APK 字节中，也属于产品交付体验的一部分。Gradle 依赖生成的 OSS 声明不会自动发现由代码库、服务器或首次启动流程下载的模型文件。应将依赖图和最终包内容与模型来源文档互相核对。 不要根据“开放”“社区”或“允许商业使用”等标签推断义务。要读准确许可和版本。例如 Apache License 2.0 包含保留通知和附带许可副本等条件，但这个例子不能证明其他库或任何模型也适用相同条款。SPDX 是许可目录和表达词汇，不是法律结论引擎。清单要写明谁看过哪些来源；不确定的问题应交给合格审核者，而不能改写成整体批准。 一份有用的发行检查应双向核对：每项交付组件都能追溯到权威许可来源和发行制品；每项适用声明都出现在实际分发或展示位置，例如应用内声明页或随包文件。还要检查语言、离线可访问性，以及用户安装后能否找到声明。不能假设网页或仓库中的文件会自动随模型下载到用户设备。 最后保留变更历史。依赖升级、新量化结果、重新打包的分词器、模型来源变化，或从内置切换为下载，都可能改变清单。对比修订、重建组件列表，并审核变化的许可文本，不要直接复制上一版批准。本清单提供可追溯的发行审核证据，不保证法律合规，不构成法律建议，也不认证任何模型可以再分发。
现有 Android 应用新增模型转换文件
团队的应用已使用一套许可较宽松的原生运行时。现在团队转换了从另一来源取得的模型，并计划通过自己的下载端点提供文件。现有软件声明只列出了 Gradle 依赖，没有提到下载模型、分词器或转换工具。
决策
按发行版本盘点应用代码、原生库、构建工具和下载制品，关联准确许可来源，并在描述再分发状态前审核声明的位置。
预期结果
发行记录能说明审核过什么、还缺什么，但不会推断模型和运行时共用同一许可，也不直接给出法律结论。
需要收集的证据
只有将以下证据与同一模型文件和测试运行关联起来，结论才可复核：
- COVE-MODEL-02：当前模型配置没有摘要，不能据此推断制品经过验证。
- PRIVACY-01：本地推理不意味着产品的所有其他数据或交付路径都相同。
收到完整字节流还不够；最终落盘、完整性、运行时加载和恢复路径也必须验证。
实施流程
- 冻结发行与交付变体. 记录应用版本、构建变体、APK或Bundle产物、动态功能、模型交付渠道和准确候选发行包。把应用包及单独下载的文件作为不同交付制品分别核对。
- 从多种证据来源建立组件清单. 合并解析后的直接与传递依赖、最终包内原生库、随包资源、模型及分词器清单、转换工具，以及服务器实际提供的文件。记录来源、版本、责任方，并标明随应用发货还是只在构建时使用。
- 把权威条款绑定到准确修订. 链接上游许可原文或条款页，并写明适用制品修订。仅在文本准确匹配时使用 SPDX 标识；自定义或不确定条款要保留权威链接并交由审核，不要猜测归类。
- 把明确条件映射到声明位置. 将每项已审核许可的声明或署名要求转成可跟踪事项。确认选定的应用内声明页或随包文件确实进入该分发渠道；若产品依赖本地资源，还检查离线时是否可访问。
- 审核变更并保留未决问题. 把当前清单与上一发行版对照，标记新文件、变化条款、缺失文本以及无法固定来源的制品。不要默默关闭未决项；在作出再分发声明前安排责任人审核。
让每个阶段的状态都可观察。失败信息应指出阶段、模型、运行时和恢复动作，同时避免记录用户私密内容。
验收标准
- 每个交付模型、运行时、原生库、分词器和构建工具都记录准确版本或修订、来源、交付路径和许可证据。
- 只在与审核文本准确匹配时填写 SPDX 标识；自定义或有疑问的条款明确保留为待审核。
- 适用声明映射到真实发行位置，并按用户最终收到的相同制品集合完成检查。
决策对照表
| 维度 | 选择或证据 | 解读方式 |
|---|---|---|
| 仅扫描依赖声明 | 从构建依赖图生成声明列表 | 有助于列出软件依赖，但可能漏掉模型资源、外部下载、转换器或图外打包组件。 |
| 发行组件清单 | 核对依赖、包内容、资源、工具和交付证据 | 提供可审核的交付组件映射，但仍依赖来源准确及人工解释。 |
| 法律审核结论 | 由合格审核者阅读准确条款并核对计划中的发行方式 | 针对实际发行解释条款；自动生成的声明报告本身不能给出该结论。 |
需要避免的失败模式
- 只扫描 Gradle 依赖而漏掉模型和运行时下载
- 把 SPDX 代码当作许可解释或再分发批准
- 因同一模型家族名称而推定所有变体条款相同
还要避免静默回退、版本未固定、缺少取消处理，以及把不同配置的结果混在一起下结论。失败运行也应与成功记录一并保存。
最小复现记录
| 层级 | 记录内容 |
|---|---|
| 设备 | 厂商、型号、芯片、内存档位、操作系统版本 |
| 软件 | 应用版本和 Git 提交号 |
| 模型 | 系列、变体、版本、格式、文件长度、摘要、量化方式 |
| 运行时 | 名称、版本、请求后端及实际后端证据 |
| 工作负载 | 样例版本、输入摘要、提示词摘要、输出策略 |
| 结果 | 完成、失败、取消、回退及保护隐私的诊断信息 |
发布检查表
- ☐ 主要搜索问题已回答，且没有未经支持的数字。
- ☐ 所有模型文件和运行时版本均已固定。
- ☐ 代表性任务和失败处理策略均有说明。
- ☐ 生命周期、取消、清理和回退均已测试。
- ☐ 用户内容与网络边界均有说明。
- ☐ 结论只适用于被记录的配置。
- ☐ 新增测试结果时链接到原始方法或证据。
来源与相关证据
中文部署与排错专题见。奇连 AI 端侧专题。
常见问题
填写 SPDX 标识就证明模型获准再分发了吗？
没有。它只是来源准确时对某个许可表达的标准化标识。仍要审核准确制品条款和具体交付方式，尤其是自定义模型协议或转换后的文件。
模型安装后才下载，还需要列入声明清单吗？
不要直接省略。即使 APK 中没有模型字节，它仍属于产品交付路径。应记录来源、修订、许可、下载位置，以及必要声明如何到达接收方。
只更新分词器，可以沿用上一版审核吗？
不应未经检查直接沿用。分词器或处理器可能有独立来源和许可；新修订也改变了组件清单。应检查准确的新文件和适用条款。