VENDOR INTAKE WORKBENCH

厂家 ODC 资料工作台

更现实的工作流不是让工程师逐项手填 144 个要素,而是导入手册、配置表、运营规则或脱敏摘录,先生成 ODC 草案表和边界组合候选,再由企业联系人确认和发布。

公开站点边界 本页不做真实企业认证,也不上传商业敏感文件;仅在浏览器内处理公开资料或脱敏摘录。正式厂家提交应使用企业域名验证、权限审批和后台审核,GitHub 只作为社区贡献的兜底通道。
01

企业验证

使用企业域名邮箱、厂家管理员邀请或合作方白名单确认提交者身份;公共站点不把“选择厂家”当作认证。

02

资料导入

导入用户手册、车主手册、功能说明、配置表、运营规则、OTA 说明或脱敏内部边界文档。

03

ODC 归纳

系统把文本映射到 GB/T 45312—2025 的 144 个要素,标注证据句、参数范围、未明确项和边界组合候选。

04

确认发布

厂家确认可公开字段后,通过后台、API、CSV 审核包或 GitHub 社区通道进入 OpenODC 样例库。

MANUAL TO ODC TABLE

从资料生成 ODC 草案表

浏览器本地处理
导入资料后,将在这里生成 144 个 ODC 要素的草案表。

公开发布不应只依赖 GitHub

推荐形态

厂家门户

企业域名验证、管理员审批、角色权限、版本冻结、法务脱敏和发布确认都在门户内完成。

近期可落地

审核包提交

导出 CSV / JSON / Markdown 审核包,通过邮件、飞书、企业微信或网页表单交给 OpenODC 管理员代录。

规模化

API / 批量同步

适合同时维护多个车型和多个市场版本的 OEM / Tier 1,在 SOP 或 OTA 节点同步公开字段。

社区通道

开源社区 PR

保留给研究者、开发者和熟悉 GitHub 的贡献者;厂家工程师可以优先使用审核包、门户或 API 路径。

厂家确认的最小闭环

环节必须解决的问题OpenODC 需要承接的产物
身份验证谁代表厂家提交,是否有公开授权企业域名、联系人角色、审核记录
资料归纳手册和规则是否覆盖 144 个要素,哪些是缺口ODC 草案表、证据句、来源链接、页码
人工确认哪些字段可以公开,哪些只能内部保存公开字段清单、脱敏说明、版本号
平台发布公开版本如何进入样例库并可追溯审核通过的 JSON、CSV、变更日志和证据快照