你写了 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 AgentOPA。sharp-skills 目前是前者因为规则逻辑不复杂主要是文本模式匹配。自动化检查代码相关用 AST/Tree-sitter文档相关用正则/结构化解析Markdown AST数据相关用脚本执行。CI 集成GitHub Actions / GitLab CI 里加一步品控检查跟单元测试一起跑。规则变更触发全量回归内容变更触发增量检查。结果可视化最简单的做法是输出 Markdown 格式的检查报告列明每条规则的通过/失败状态、关联样本、修复建议。一个认知误区有人觉得上了流水线人就没事了。恰恰相反流水线的目的是把人从重复劳动里解放出来去做更有价值的判断。自动化检查能告诉你这里违反了规则 X但没法告诉你这条规则在这场景下是否适用。品控的最高境界不是零违规而是知道什么时候可以破例。这个决策权必须留在人手里流水线负责把信息给足——违规项、历史相似案例、潜在风险——让人做 informed decision。我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」23 个设计模式用漫画 答题的方式讲目前正在开发中。如果你觉得这类内容有意思搜一下「爪爪代码冒险记」或者等我后面的文章。 你写了 50 条 AI 品控规则，执行时还是漏判——问题在流水线，不在规则本身
你写了 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 AgentOPA。sharp-skills 目前是前者因为规则逻辑不复杂主要是文本模式匹配。自动化检查代码相关用 AST/Tree-sitter文档相关用正则/结构化解析Markdown AST数据相关用脚本执行。CI 集成GitHub Actions / GitLab CI 里加一步品控检查跟单元测试一起跑。规则变更触发全量回归内容变更触发增量检查。结果可视化最简单的做法是输出 Markdown 格式的检查报告列明每条规则的通过/失败状态、关联样本、修复建议。一个认知误区有人觉得上了流水线人就没事了。恰恰相反流水线的目的是把人从重复劳动里解放出来去做更有价值的判断。自动化检查能告诉你这里违反了规则 X但没法告诉你这条规则在这场景下是否适用。品控的最高境界不是零违规而是知道什么时候可以破例。这个决策权必须留在人手里流水线负责把信息给足——违规项、历史相似案例、潜在风险——让人做 informed decision。我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」23 个设计模式用漫画 答题的方式讲目前正在开发中。如果你觉得这类内容有意思搜一下「爪爪代码冒险记」或者等我后面的文章。