你写了 50 条 AI 品控规则，执行时还是漏判——问题在流水线，不在规则本身
单条规则写得再漂亮，放在手工检查的流程里，漏判率是指数级增长的。
我维护 sharp-skills 半年，最痛的领悟不是"规则该怎么写"，而是"规则该怎么跑"。当你只有 5 条规则时，肉眼扫一遍就能发现问题。但当规则膨胀到 50 条、覆盖 6 个模块、对接 7 个 AI 平台时，"人去看"这个环节本身就是最大的品控漏洞。
这篇聊的不是规则语法，是规则怎么从"写在文件里"变成"跑在流水线上"。
手工检查的死亡陷阱
很多人以为品控就是"写完让一个人过一遍"。这个模式在三个条件下必然崩溃：
规则数量超过工作记忆容量。认知心理学里有个 Magic Number 7±2，人脑短期记忆能同时处理的信息组块就这么大。你让一个人同时记住 50 条规则的检查点，他不是认真检查，他是在表演认真。
规则之间存在隐性依赖。sharp-dataviz 里有一条"坐标轴必须从 0 开始"，sharp-copywriting 里有一条"数据引用必须标注来源"。当一张图表同时违反这两条时，手工检查的人往往只注意到其中一条——因为两条规则分属不同模块，检查者的大脑上下文切换不过来。
检查结果无法复现。同一个人上午和下午的检查标准不一样，不同的人对同一条规则的理解不一样。你没法说"上次过得了这次为什么不行"，因为根本没有"上次"的精确记录。
手工检查的本质，是用人的不可靠性去弥补 AI 的不可靠性。两个不可靠叠加，结果不是更可靠，是更随机。
品控流水线的三层架构
我把品控工程化拆成三层，每层解决不同的问题。
第一层：规则自动化执行
MUST 规则必须能自动检查，这是底线。
什么叫能自动检查？输入给定的前提下，判断结果是确定的，不需要人做价值判断。比如"技术文档中所有代码示例必须可运行"——你可以写个脚本提取代码块、跑编译、看是否报错。这是自动的。
但"代码示例必须体现真实场景"——这很难自动检查，因为"真实"是个语义判断。这种规则归为 SHOULD 或 MAY，留在人工复核层。
第一层的关键决策是：哪些规则上流水线，哪些留给人。我的标准是：能用正则、AST、静态分析、脚本执行搞定的事，绝不让人看。
sharp-skills 的 MUST 规则占比控制在 20% 以内，不是因为 MUST 不重要，而是因为 MUST 必须能自动化。如果一个规则很重要但无法自动化，那它的问题不在重要性，而在表达清晰度——你可能需要把它拆成"可自动检查的原子规则"加"需要人工判断的上下文规则"。
第二层：多模块交叉验证
单模块内没问题，跨模块就可能翻车。
一个典型场景：API 文档（sharp-api-design）里的错误码表格，和演示文稿（sharp-presentation）里的截图，引用了同一个数据。API 文档更新了错误码，但演示文稿里的截图还是旧的。单看各自模块的品控，都过了。放在一起看，就出错了。
交叉验证层解决的就是这种"模块内合法、全局不一致"的问题。实现方式有几种：
全局符号表。把每个模块产出的"关键实体"（API 名称、错误码、数据指标、术语定义）抽成一个符号表，跨模块做引用一致性检查。sharp-skills 里每个模块都有"术语定义 MUST 在首次出现时给出"这条规则，目的就是为了让符号表能自动构建。
依赖图谱。记录产出物之间的引用关系。A 文档引用了 B 图表的数据，当 B 更新时，A 自动进入重检队列。这跟代码里的依赖管理一个逻辑。
冲突检测。两个模块对同一个概念的定义冲突。比如 sharp-tech-writing 说"微服务"是一种架构风格，sharp-copywriting 说"微服务"是一款产品——这种语义冲突必须被标记。
第三层：黄金样本集回归
规则会腐烂，样本集是防腐剂。
这条在 08-15 的文章里展开过，放在流水线语境下再强调一遍：自动化检查必须有"已知正确答案"的测试用例。没有样本集覆盖的规则，等于没写。
流水线的做法是：每次规则变更，跑一遍全量样本集，看通过率变化。新增规则必须伴随新增样本（正例+反例+边界例）。样本集本身也受版本控制，规则回滚时样本状态一并回滚。
sharp-skills 的黄金样本集按模块拆成 6 个子集，每个子集再分合规/违规/边界三类。目前总样本量控制在 200 个左右，全量回归跑完不到 30 秒。这个成本完全可接受，但带来的信心是巨大的——你改了一条规则，能立刻知道有没有误伤。
流水线的执行顺序
三层不是平行关系，是有严格顺序的：
先跑第一层自动化检查。MUST 规则全量扫描，不通过的立即打回，不进入后续环节。这一步的目标是"快速失败"，把明显不合格的东西尽早拦住。
再跑第二层交叉验证。只针对第一层通过的内容，检查跨模块一致性。这一步的成本比第一层高，因为需要加载多个模块的上下文，所以放在后面做。
最后跑第三层样本回归。这个可以异步跑，甚至定时跑（比如每小时/每天），因为样本集变化不频繁。但规则变更时必须同步跑，作为 PR 的 CI 检查项。
三层都通过，才进入人工复核。此时人工的工作不是"找问题"，而是"做判断"——处理那些自动化解决不了的语义问题、权衡取舍、例外审批。
工具的选型建议
不需要从零造轮子，现有工具链足够搭一个能用的流水线：
- 规则引擎：简单的用 JSON/YAML 配置文件 + Python 脚本解析；复杂的可以用 Open Policy Agent（OPA）。sharp-skills 目前是前者，因为规则逻辑不复杂，主要是文本模式匹配。
- 自动化检查：代码相关用 AST/Tree-sitter；文档相关用正则/结构化解析（Markdown AST）；数据相关用脚本执行。
- CI 集成：GitHub Actions / GitLab CI 里加一步"品控检查"，跟单元测试一起跑。规则变更触发全量回归，内容变更触发增量检查。
- 结果可视化：最简单的做法是输出 Markdown 格式的检查报告，列明每条规则的通过/失败状态、关联样本、修复建议。
一个认知误区
有人觉得"上了流水线，人就没事了"。恰恰相反，流水线的目的是把人从重复劳动里解放出来，去做更有价值的判断。
自动化检查能告诉你"这里违反了规则 X"，但没法告诉你"这条规则在这场景下是否适用"。品控的最高境界不是零违规，而是"知道什么时候可以破例"。这个决策权必须留在人手里，流水线负责把信息给足——违规项、历史相似案例、潜在风险——让人做 informed decision。
我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」，23 个设计模式用漫画 + 答题的方式讲，目前正在开发中。如果你觉得这类内容有意思，搜一下「爪爪代码冒险记」，或者等我后面的文章。