配置能力治理规则

本页把“配置能力清单”的治理规则、判定方式、处理动作和站内使用位置整理成一套统一资料。它用于约束配置能力数据库、功能编辑、项目交付物、车型配置对比和 UX-Audit 中的能力命名、匹配、复核与发布。

6 列治理主题、规则、判定 / 应用、处理动作、责任对象、版本状态。

15 条覆盖定义、来源、命名、解耦、证据、匹配、复核和发布门槛。

8 类位置用于数据库、功能编辑、项目交付物、配置对比和评测链路。

4 级复核P0 到 P3 区分人工确认、低置信度、初匹配和待发布项。

一个治理规则有哪些内容

每条治理规则都要能回答六个问题：管什么、原则是什么、怎么判断、命中后怎么处理、谁负责、当前处于什么治理状态。没有处理动作的规则只能算说明文字，不能作为数据库和项目交付物的发布依据。

字段	含义	写法要求
治理主题	规则管理的对象、关系、流程或风险点。	使用短名，如能力定义、能力来源、服务状态关系、发布门槛。
规则	必须遵守的治理原则。	写成可执行原则，避免只写背景说明。
判定 / 应用	判断是否符合规则的方法，或规则适用场景。	说明什么情况算命中、什么情况不算。
处理动作	命中规则后要合并、拆分、下移、标记、复核或发布的动作。	动作必须能落到表、字段、关系或流程状态。
责任对象	负责确认、维护、发布或抽样复核的角色。	可用 Capability Owner、Data Steward、Standards Committee 等。
版本状态	规则当前所处阶段。	长期原则、已执行、本轮新增、保守启用、待确认、待后续。

核心原则

能力不是硬件配置能力描述用户可感知或用户需要执行的能力单元，不直接写成芯片、雷达、摄像头、屏幕、材料或算法。
一项能力一个主要结果同一名称里出现多个动作、场景、触发条件或体验结果时，优先拆分。
来源必须可追溯能力来自官方配置、参数表、项目需求、实测验证或人工确认资料；无来源则标记待确认。
能力和技术方案解耦技术方案变化后，能力名称应仍然成立；方案语言下移到配置项、参数、服务状态或备注。
服务状态不是能力身份同一配置能力可有多个服务状态；服务状态用于说明当前车型、功能或项目中的状态证据。
人工确认不等于发布正式发布前还要检查边界、来源、适用范围、重复项、关系表和复用性。

标准治理规则

治理主题	规则	判定 / 应用	处理动作	责任对象	版本状态
能力定义	配置能力必须描述车辆可提供的用户可感知能力或用户需要执行的能力单元。	用户能否感知该能力带来的功能、体验或服务结果。	硬件、材料、参数、供应商和技术路线下移到配置项、参数、技术方案或来源字段。	Capability Owner	长期原则
能力来源	配置能力只允许从官方配置、参数表、产品说明、项目需求、实测验证或已确认资料中提取。	来源可追溯，不能只来自销售话术、二次解读或模型猜测。	无来源或来源不稳定的能力标记为 `TBD/待确认`，不得进入正式清单。	Data Steward	长期原则
能力命名	一个能力名称只表达一个主要能力结果。	名称中同时包含多个动作、场景、触发条件或结果时，需要拆分。	拆分为多个能力项，并保留原始来源映射。	Capability Steward	已执行
配置与能力解耦	配置能力不写成搭载、配备、支持某芯片、雷达、屏幕、材料、算法或阈值。	更换供应商、硬件、材料或算法后，能力名称仍应成立。	技术方案写入配置项、参数、实现方式或备注字段。	Capability Owner	长期原则
触发/执行类型	配置能力可分为 `触发` 与 `执行`，该类型不同于配置模块或配置类别。	触发类表达条件、状态、用户/环境变化；执行类表达车辆响应或功能动作。	类型缺失或混淆时标记待复核；不要用模块名替代能力类型。	Capability Steward	长期原则
用户感受优先	传感器检测、算法识别和环境测量不是默认配置能力；只有用户可感知或业务流程需要的结果才可成为能力。	例如“检测光照”不是能力，“天气好但昏暗”可作为触发类用户感知条件。	检测逻辑写入技术方案或传感器配对，能力名称写用户感知/使用结果。	Capability Owner	长期原则
车型适用	每条能力必须能关联到车型、年款、版本、配置包或项目范围。	无法定位适用范围时，不进入正式清单。	标记为待核验，补充适用版本和来源。	Data Steward	长期原则
证据要求	每个能力项至少保留一个来源证据。	官方配置表、说明书、项目交付物、实测记录、数据库行均可作为证据。	缺证据项进入 P1 复核池。	Data Steward	已执行
变体合并	同义、近义、营销名称不同但能力边界一致的项应合并。	判断用户结果、使用场景、触发条件和可验证边界是否一致。	保留标准名，别名进入 alias、备注或来源映射。	Capability Steward	已执行
复合能力	一个配置项可支撑多个能力，一个能力也可被多个配置项支撑。	摄像头、雷达、座舱 OS 等配置可支撑感知、泊车、影像、账号等多种能力。	建立配置项-能力关系表或服务状态关系，不在能力字段重复大段文本。	Data Steward	长期原则
服务状态关系	服务状态是配置能力在特定功能、项目或车型中的状态证据，不等同于能力身份。	同一配置能力可有多个服务状态；未生效状态也应保留以说明边界。	输出时每个服务状态独立行，标注是否生效和来源。	Data Steward	已执行
匹配优先	项目需求、功能流程和场景拆解优先匹配已有配置能力。	能力结果一致时使用已有项；只因技术方案相近不能强行匹配。	若新增，必须列出相近能力和不选用理由。	Capability Steward	已执行
分级匹配	匹配时先按配置模块、类别、关键词预筛选，再按用户结果与边界精确判断。	禁止全量遍历后只给一个无证据结论。	输出候选、命中理由、排除理由和来源。	Data Steward	已执行
人工复核	人工确认优先，但人工确认不等于正式发布。	P0 可进入抽样；P1 为低置信度、规则校准或多义复合项；P2/P3 为中高置信度初匹配。	按优先级复核，记录人工意见、修改记录和责任人。	Audit Owner / Capability Owner	长期原则
发布门槛	配置能力转 Official 前必须完成边界、来源、适用范围、重复项、关系表和复用性检查。	任一门槛未过时不得发布为正式能力。	标准委员会批准后转 Official Capability。	Standards Committee	待后续

哪些地方会用到

配置能力数据库控制能力命名、来源、适用范围、服务状态和重复项治理。 用户与环境数据库区分用户/环境状态与车辆配置能力，避免把传感器检测误写成能力。 功能编辑平台从功能需求拆解触发/执行能力，保持流程节点和能力身份分离。 功能清单约束功能核心流程、完整流程和配置能力字段的输出口径。 项目交付物审核赵需求、钱数据、孙架构交付物中的能力拆解、匹配和流程 JSON。 车型配置对比当配置项进入能力层时，检查是否需要拆成能力、配置项、参数和服务状态关系。 UX-Audit使用配置能力作为功能/场景证据时，保留能力与评测规则的边界。 规则库与旧版配置能力规则共同使用；本页作为治理口径和发布门槛的更新版说明。

复核优先级

P0已人工复核或事实错误风险极低，可进入抽样或发布门槛检查。

P1低置信度、来源不足、规则校准、复合多义或影响发布质量，优先逐条复核。

P2中置信度原初匹配，按模块、项目或车型抽样后批量确认。

P3高置信度原初匹配但未正式批准，保留证据并等待发布门槛。

Skill 输出要求

已同步创建 configuration-capability-governance skill。以后涉及配置能力清单、配置能力数据库、功能/场景拆解、服务状态匹配或项目交付物复核时，应先使用该 skill，再输出六列治理规则、能力匹配表、复核优先级和发布门槛结论。