把 LLM 当作可编程、可约束、可验证的组件：AI 质量治理的三条线
导读：本文分享 Agent 技能平台（技能市场）AI 质量治理的设计与落地，用覆盖全生命周期的三条治理线——上架门禁（静态扫描 + 对话质检 + 自动修复引导）、发布审核与质检（分享超阈值自动触发人工审核）、运行期健康度（观测采样 + 四维评分 + 报告触达），并守住两条红线：机器结论永远只当审核输入、不当裁决，基础设施抖动不误伤作者内容。核心认知是把 LLM 当作"可编程、可约束、可验证"的推理组件，工程本质是"数据喂养、规则驯化、测试兜底"；案例包括把 LLM 门禁从发布关键路径改为"放行 + 异步质检 + 通知"以平衡业务节奏、健康报告优化建议只引用真实指标以杜绝幻觉数字。适合做 AI 应用或 Agent 平台质量治理、工程化的技术管理者与工程师阅读。
分类：AI编程 ｜ 标签：LLM、AI工程、质量治理
最近在自研的 Agent 技能平台（以下简称"技能市场"）项目中，我负责质量治理相关的设计与落地，核心目标是让技能市场沿着「能用 → 可信 → 可运营」的路径往前走。围绕这个目标，我搭建了上架门禁、发布审核与质检、运行期健康度三条治理线，并沉淀了一套「把 LLM 当作可编程、可约束、可验证组件」的认知方法。这篇文章把这些实践整理成可复用的经验，希望对做 AI 应用质量治理的同学有参考价值。
一、三条治理线
AI 应用的质量问题不能只靠上线前人工 review，也不能只靠上线后看指标，需要一个覆盖全生命周期的治理体系。我在技能市场里落地了三条治理线：
1. 上架门禁：静态扫描 + 对话质检
技能是 Agent 平台上的核心资产，作者上传技能时就要把好第一道关：
- 静态扫描：技能上传时自动做静态扫描，检查代码与配置层面的风险点；
- 对话质检：分享（发布）时再做一轮对话质检，基于技能的实际交互内容校验质量；
- 改造引导与自动修复：用户技能不通过时，不只给一个"不通过"的结论，而是提供改造引导与一键自动修复，也可以直接在平台内优化后重新提交。
门禁的目标是把明显不合格的技能挡在上架之前，减少流向审核与运行期的劣质内容。
2. 发布审核与质检
门禁挡不住的内容，交给发布审核兜底：
- 分享人数超过阈值时自动触发审核，把流量变大的内容交给更严格的人工把关；
- 对话质检结果作为人工审核的直观建议——审核者不用自己逐条翻对话记录，而是先看机器整理出的质检结论，再据此做判断。
这里的关键是：机器质检负责"帮人看得快、看得全"，最终决定权仍然在人。
3. 运行期健康度
上架、审核都通过之后，还要回答"运行期好不好"：
- 观测采样：通过观测平台对技能运行时的调用进行采样，拿到真实的线上运行数据；
- 四维健康度评分：在采样数据基础上，从多个维度（如可用性、质量、性能、安全等）计算健康度评分；
- 报告与通知调度：生成健康报告，通过通知与调度机制触达相关方，推动问题被看到、被处理。
需要特别强调安全优先的设计：别人分享的技能不对外展示健康报告，trace 链接也默认关闭，防止用户对话数据外泄。安全不是上线后补的补丁，而是从一开始就写进产品形态的设计约束。
二、三层治理的递进设计：职责单一、不越界
三条治理线看似独立，背后是一套递进的治理设计，我用三句话概括三层的职责：
- 门禁管「能不能进」：决定一个技能是否有资格进入市场；
- 审核管「内容可不可信」：决定进入市场的技能内容是否可信、是否经得起推敲；
- 健康度管「运行期好不好」：决定已上线的技能在实际使用中是否健康、是否需要干预。
各层职责单一、互不越界：门禁不该替审核做"可信度"的最终判断，审核也不该去重跑运行期的指标计算。职责拆清楚之后，每一层的输入、输出、决策权都变得可定义、可测试、可演进——这也是它能稳定运转的前提。
三、两条红线
在治理体系的运转过程中，我给自己划了两条红线，任何功能设计都不能越过：
- 机器结论永远只当审核输入，不当裁决。LLM 的判断天然带有概率性，可以用来提建议、给证据、降低人的检索成本，但"是否通过"这类裁决权必须保留在人工审核手里；
- 基础设施抖动不误伤作者内容。治理系统的评判对象是技能内容本身，观测平台的采样抖动、网络波动属于基础设施问题，不能让这些非内容因素影响作者的评分与处置。
此外还有一条底线原则：指标口径严谨，靠真实线上数据较真；安全考量前置进设计，而非事后补救。
四、对 AI 的认知：可编程、可约束、可验证的推理组件
做完这三条治理线，我对 AI 的定位有了一个更清晰的认知：
AI 是可编程、可约束、可验证的推理组件：产出质量取决于任务边界与约束设计——无约束的 LLM 会编数据、给不落地的建议，加上硬性规则后即可信可用。工程上的本质是「数据喂养、规则驯化、测试兜底」。
拆开来看有三层含义：
- 可编程：LLM 可以被放进具体的业务流程里，作为工作流中的一个环节，而不是一个黑盒；
- 可约束：它的输出必须受任务边界（prompt 与上下文设计）和硬性规则约束，约束设计直接决定产出质量。没有约束的 LLM 会编数据、会给出无法落地的建议；
- 可验证：每一处 AI 产出都要能够被验证——能对上真实指标、能跑测试、能被人复核。
落到工程上就是三件事：数据喂养（给模型真实、干净的输入）、规则驯化（用规则把模型行为约束在边界内）、测试兜底（用测试用例守住质量底线）。
五、落地案例
案例一：静态扫描门禁与业务节奏的平衡
最初我把 LLM 静态扫描门禁放到发布质量的关键路径上——扫描不通过就不允许发布，试图用 AI 一刀切卡住所有问题。实践中很快发现，这种"一刀切"会拖慢发布节奏：规则过严误伤正常内容，规则过松又失去意义，而卡在关键路径上任何误判都会直接阻塞作者。
后来调整为发布后异步质检 + 通知：先放行，质检异步执行，结果以通知形式触达作者与相关方。这样既保住了治理的覆盖面，又不再打断正常发布节奏——这体现了对 AI 能力边界与业务节奏的平衡：AI 适合做"宽覆盖的发现与提醒"，不适合做"低误伤的实时拦截"。
案例二：健康报告的 AI 优化建议只引用真实指标
运行期健康报告的优化建议，我用 LLM 自动生成可执行的修复动作，结构是「问题 + 数据依据 → 动作 → 预期」。最关键的一条约束是：建议只引用真实指标。模型可以基于采样数据组织语言、给出推断与动作建议，但不允许凭空编造数字——所有数据依据必须来自观测平台采到的真实指标，从机制上杜绝"看起来很有道理、实际是幻觉"的建议。
案例三：质检 → 修复的闭环
质检不能只停在"发现问题"这一步。对质检不通过的技能，系统会在消息中附加跳转平台提问的入口，引导作者带着质检结果去与平台内的助手沟通、完成修复，形成「技能质检 → 修复」的闭环。问题从发现到解决在一条链路上走完，而不是质检报告发完就石沉大海。
六、学习方式：问题驱动
最后记录一下我在这类 AI 工程项目上的学习方式——问题驱动：
- 每次线上故障、每轮评审意见，都沉淀为规则或测试用例，让一次性的教训变成体系的一部分；
- 主动补齐自己的评估体系、采样、配置热更新等短板，而不是等出了问题再临时补；
- 每次发版后做复盘，把教训变成下一轮迭代的输入；
- 写产品功能时，优先思考"这个功能在 AI 时代该怎么实现更好"——用 AI 的能力重新设计链路，而不是给旧流程简单地加一个 AI 按钮。
三条治理线、两层防御原则、一套对 AI 的认知方法，构成了这次项目里最值得带走的沉淀。如果你也在做 Agent 平台或 LLM 应用的工程化，希望这套思路能给你一些参考。