在QAC里做规则裁剪，真正要先分清的一件事是，规则本身和消息本身不是一回事。Perforce官方文档写得很清楚，QAC用RCF，也就是Rule Configuration File，来定义分析过程中发现的warning messages和规则之间的映射关系；项目里的Rule Configuration面板会按层级树的方式展示这些规则和子组，选到最底层规则时，才能看到实际关联的enforcement messages。也就是说，所谓“裁剪规则”，本质上不是把分析器关掉，而是在项目层面对哪些消息归入哪些规则、哪些规则纳入当前合规口径做配置。

　　一、QAC规则怎么裁剪

　　QAC规则裁剪，最稳的做法不是从空白开始重建，而是先选一份合适的RCF做基线，再在项目里做增删和合并。官方文档说明，创建项目时必须选择至少一个CCT、一个ACF和一个RCF，其中RCF负责定义coding standard rules以及对应的enforcement messages。对大多数项目来说，先选对RCF，比后面逐条修规则更省时间。

　　1、先选合适的基础RCF

　　Project Properties里的Rule Configuration File下拉框会显示User Data Location里可用的默认RCF。官方说明列出了几种常见起点，默认文件包含该语言的完整消息集，critbug文件是一套更小的规则集，适合存量代码，security文件则更偏向安全相关缺陷。也有针对特定compliance module的RCF，比如只覆盖单一目标语言的文件。先把基线选对，后面的裁剪会轻很多。

　　2、再用Import做替换、更新或合并

　　如果你已经有一份现成RCF，官方给出的标准入口就是Rule Configuration面板上的Import。导入时可以选Replace、Update或Merge。Replace是整份替换，Update会保留默认映射框架并更新已有组件映射，Merge更适合你已经做过项目级自定义、又想尽量保住现有裁剪结果的场景。对规则裁剪来说，这一步特别重要，因为它决定了你是在重建口径，还是在现有口径上迭代。

　　3、需要大改时再新建规则层级

　　如果默认RCF和现有RCF都不适合当前项目，官方文档说明可以先点Clear清空，再在Rules面板里右键创建新的顶层Rule Group，然后继续创建新规则，并为规则关联消息。保存后，这份新的层级会作为当前Active Configuration下的本地规则配置存在，也可以Export到别的位置。这个能力说明，QAC的规则裁剪不只是“开关内置规则”，也支持你按项目重组一份自己的规则视图。

　　4、裁剪后用Rule Groups检查结果

　　规则裁剪做完以后，不要只看配置文件，最好回到QA·GUI的Rule Groups面板检查实际分析结果。官方说明里提到，这个面板会按Rule Group统计唯一诊断，并展示哪些诊断违反了哪些规则；如果使用了compliance module，结果列表里的Rule列也会直接显示对应规则编号。这样做的价值在于，你能马上看出裁剪后的规则集到底有没有真正对准项目关心的问题，而不是只停留在配置层。

　　二、QAC规则在不同项目如何定制

　　不同项目定制QAC规则，最怕的是一套口径到处硬套。更稳的办法，是先按项目目标分层，再决定RCF用哪一类起点、改到什么程度。Perforce官方给出的默认RCF已经隐含了这种分层思路，完整规则集适合新项目和正式合规，critbug适合先压关键缺陷，security更适合先盯安全问题。也就是说，项目不同，规则定制的起点本来就可以不同。

　　1、存量项目先收紧关键问题

　　如果项目历史包袱重、问题量大，不建议一开始就把完整规则集全压上去。官方提供的critbug文件本来就是reduced set，专门面向legacy code场景。对这类项目，更现实的做法通常是先用critbug或精简后的RCF跑起来，把真正高风险问题收住，再逐步往完整规则集过渡。

　　2、新项目优先对齐完整规则与标准模块

　　如果项目本身就是按MISRA、AUTOSAR或CERT一类标准起步，规则定制更适合从默认完整RCF或对应compliance module的RCF开始，而不是先砍很多规则。官方文档说明，compliance module安装后，规则和结果可以直接按该模块的Rule列展示，这种方式更适合做正式合规管理。

　　3、相近变体项目尽量共用一份规则配置

　　如果你面对的是同一代码基上的多个版本、多个变体或多个客户型号，Validate的streams机制更适合这类场景。官方文档明确写到，多个streams可以共享同一个project rule configuration，issues也会在公共代码上自动保持同步。对规则定制来说，这意味着相近项目不一定要复制出多份独立规则库，能共用时尽量共用，后期维护会轻很多。

　　4、差异大的项目再导出独立RCF

　　如果两个项目在标准、风险重点或语言范围上已经明显不同，那就更适合把当前项目里的规则配置Export成单独文件，再给另一个项目作为新基线导入。官方文档说明，新的规则层级和修改后的规则配置都可以导出到不同名称和位置，这正是做项目级定制最实用的复用方式。

　　三、QAC规则口径怎么收

　　很多团队后面越配越乱，不是因为QAC不能定制，而是没有把“规则基线、项目差异、变体共用”这三层分开。更稳的做法，是先定一份团队级基线RCF，再针对项目做增量裁剪，能共享的变体尽量放在同一project或stream体系里管理。Perforce官方文档拼起来看，其实已经给了这条线，项目必须有自己的RCF，项目里的Rule Configuration可以导入、合并和导出，而streams又能在多个变体间共享同一份规则配置。

　　1、先定团队基线

　　无论是默认RCF、critbug、security，还是你们自己整理过的一份规则文件，最好先沉一份团队通用基线。这样不同项目起步时不会每次都从头选。

　　2、项目层只做必要差异

　　规则口径一旦到了项目层，尽量只处理这个项目特有的要求，不要把所有习惯都混进项目配置里。这样后面做Update或Merge时，规则变更更容易控制。

　　3、变体层优先共享

　　如果只是产品型号、品牌或小范围模块差异，官方streams机制本来就是为“同一代码基多个变体”设计的。能共享一份规则配置时，不要急着拆成多个独立项目。

　　4、结果层要回看规则是否真有用

　　最后不要只盯RCF文件本身，还要回到QA·GUI的Rule Groups和结果列表，看裁剪后的规则集到底有没有把项目真正在意的问题筛出来。规则能不能解释项目风险，比规则文件本身长什么样更重要。

　　总结

　　QAC规则怎么裁剪，最核心的抓手就是RCF。先选对基线文件，再根据项目实际去Replace、Update、Merge，必要时再自建规则层级，比从零乱配更稳。QAC规则在不同项目如何定制，关键则是把存量项目、新项目和多变体项目分开处理，能共用规则配置时尽量共用，差异大的项目再导出独立RCF。把基线、项目和变体这三层收顺，QAC的规则管理通常就不会越做越乱。