agentsclimarketplace

Ai native audit release

Skill gmaxxxie/ai-native-product-agent-skills/skills/ai-native-audit-release

AI Native Product Methodology — 80 executable skills across P0-P14 stages, covering needs discovery to aesthetic authority. From 8 books.

Install
npx -y skills add gmaxxxie/ai-native-product-agent-skills --skill ai-native-audit-release

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.

What its author says it does

Copied from the file, not written here

AI Native 产品方法论——审计放行阶段的实操 Skill。 用户提供系统构建方案,Skill 自动执行审计放行流程: 设计证据 → 评估证据 → Shadow 证据 → 放行边界判断 → go/no-go 决策 → 输出放行方案。 基于《AI Native 产品方法论》第17章。

SKILL.md

30.9 KB, as published. Nobody here has run it

AI Native 审计放行 Skill

使用场景

  • 系统构建已完成,需要判断能否进入生产环境
  • 需要建立审计放行的证据链和决策机制
  • 需要设计 Shadow System 验证系统在真实环境中的表现

执行步骤

  1. 设计证据收集:检查系统设计是否清晰定义了能力范围、失败模式、边界条件和治理机制。
  2. 评估证据收集:收集能力评估(样本/边界/长尾测试)、安全评估(权限/数据/渗透测试)和性能评估(延迟/吞吐/成本)结果。
  3. Shadow 证据收集:设计并运行 Shadow System,在真实环境中收集系统输出与人工处理结果的对比数据。
  4. 放行边界判断:定义自动执行区、人工接管区和禁用区三个区域的范围和控制措施。
  5. 六类审计检查:执行可靠性、安全与权限、执行边界、成本与性能、可追溯性、合规与治理六类审计。
  6. go/no-go 决策:基于证据链完整性和放行边界清晰度做出放行或拒绝决定。
  7. 输出放行方案:如果 go,下发生产要求、监控指标和回滚方案;如果 no-go,说明缺失条件和补充要求。

核心概念

  • 审计放行(Audit):把能力、风险、证据和放行条件压缩到同一套判断机制中的阶段
  • go / no-go:是否允许系统进入真实执行链路的组织级决定
  • 放行边界:允许自动执行的范围、必须人工接管的范围和必须禁用的范围
  • 证据链:从设计、评估、Shadow 到运行准备的连续证据,而不是单点结果

审计放行流程

设计证据
  → 评估证据
    → Shadow 证据
      → 放行边界判断
        → go / no-go
          → 生产要求下发

如果没有连续证据链,审计放行就会退化成主观印象或形式化审批。

第一步:设计证据

系统设计是否清晰地定义了:

  • 能力范围:系统能做什么、不能做什么
  • 失败模式:已知的失败类型和处理策略
  • 边界条件:什么情况下必须回退或交还给人
  • 治理机制:如何监控、如何审计、如何回滚

第二步:评估证据

评估结果是否充分:

  • 能力评估:样本测试、边界测试、长尾测试
  • 安全评估:权限边界、数据保护、渗透测试
  • 性能评估:延迟、吞吐、成本、稳定性

第三步:Shadow 证据

Shadow System 是审计放行的关键机制:

  • 系统在真实环境中运行,但不直接影响用户
  • 同时收集系统输出和人工处理结果进行对比
  • 证明系统在真实数据上的表现

Shadow 的价值在于:它让系统在不影响用户的情况下接触真实世界。

第四步:放行边界判断

明确三个区域:

自动执行区

  • 系统可以独立完成的任务
  • 失败后果可控、可回退
  • 已经过充分验证

人工接管区

  • 高风险任务
  • 涉及敏感操作
  • 系统信心度不足的场景

禁用区

  • 超出系统能力范围的任务
  • 未经验证的新场景
  • 涉及合规或安全红线的操作

第五步:go / no-go 决策

go 条件

  • 连续证据链完整
  • 放行边界清晰
  • 回退机制可靠
  • 监控体系就绪
  • 团队准备就绪

no-go 情况

  • 证据链中断
  • 边界不清晰
  • 回退机制不可靠
  • 监控体系缺失
  • 团队未就绪

审计放行要审的六类问题

  1. 可靠性:回答是否稳定,任务是否真的完成,是否存在幻觉、错误归因或不一致输出
  2. 安全与权限:是否可能泄露敏感信息,是否存在越权读取、越权调用、Prompt 注入、工具滥用
  3. 执行边界:哪些动作允许自动执行,哪些必须审批,哪些高风险动作要彻底禁用
  4. 成本与性能:延迟、令牌消耗、工具链长度、重试策略是否可控,流量放大后是否失稳
  5. 可追溯性:是否能复盘输入、上下文、模型版本、工具调用、人工接管、最终结果
  6. 合规与治理:角色责任是否清晰,审计记录是否保留,异常处理是否有明确流程

输出物:放行方案

  1. 证据链汇总:设计、评估、Shadow 的证据摘要
  2. 放行边界图:自动执行区、人工接管区、禁用区
  3. go/no-go 决策:明确的放行或拒绝决定
  4. 生产要求:上线后必须持续监控的指标、阈值、应急预案
  5. 回滚方案:如果出现问题如何快速回滚

使用方式

当用户提供系统构建方案时,自动执行:

  1. 收集设计证据
  2. 收集评估证据
  3. 设计 Shadow 方案并收集 Shadow 证据
  4. 定义放行边界
  5. 执行六类审计检查
  6. 做出 go/no-go 决策
  7. 如果 go,下发生产要求和回滚方案
  8. 输出放行方案

示例

示例:AIOps 系统审计放行

场景描述: AIOps 故障分诊系统已完成构建,需要审计是否可进入生产环境。

用户输入: "我们的 AIOps 系统已开发完成,准备上线,需要进行审计放行"

Skill 执行流程

  1. 设计证据收集
检查项状态证据
能力范围定义明确只做分诊建议,不做自动处置
失败模式已定义5类失败及回退策略
边界条件置信度<70%时必须人工确认
治理机制日志审计、监控告警、回滚方案
  1. 评估证据收集
评估类型结果是否满足
能力评估日志解释88%,告警聚类82%,案例召回75%✅ 满足
安全评估无越权调用,数据已脱敏✅ 通过
性能评估P95延迟<2s,支持100并发✅ 通过
边界测试20个边界案例,18个正确处理✅ 达标
  1. Shadow 证据收集
Shadow 方案:
  运行周期: 2周
  数据量: 50次真实故障
  
对比结果:
  系统建议采纳率: 55%
  辅助参考价值率: 80%
  错误归因数: 2次(均被工程师识别,未造成误判)
  平均定位时间:
    - 纯人工: 45分钟
    - 系统辅助: 25分钟
    
关键发现:
  - 系统在"看什么"上表现好
  - 系统在"怎么做"上仍需人工判断
  - 高约束设计有效避免了错误放大
  1. 放行边界定义
区域范围控制措施
自动执行区系统不执行任何自动动作
人工接管区全部输出所有建议需工程师确认
禁用区自动修复、自动重启明确禁止的功能
  1. 六类审计检查
审计项检查结果风险等级
可靠性幻觉率<5%,无错误归因
安全与权限无越权,已脱敏
执行边界明确只做建议
成本与性能单次调用<$0.01
可追溯性全链路审计日志
合规与治理责任清晰,流程明确
  1. go/no-go 决策
决策: GO(条件放行)

放行条件:
  - 仅限值班辅助场景
  - 所有输出必须有"供参考"标识
  - 不得用于无人值守场景
  
上线后监控:
  - 采纳率是否维持>50%
  - 是否有未识别的错误归因
  - 是否有工程师绕过确认直接执行
  
应急预案:
  - 发现严重问题可5分钟内关闭AI建议
  - 回退到纯人工分诊流程

输出结果

# 放行方案:AIOps 故障分诊系统

证据链汇总:
  设计证据: ✅ 完整
  评估证据: ✅ 通过
  Shadow证据: ✅ 2周运行,采纳率55%

放行边界:
  自动执行区: 无(仅建议模式)
  人工接管区: 全部输出
  禁用区: [自动修复, 自动重启, 自动切流]

go/no-go决策: ✅ GO - 条件放行

生产要求:
  必须监控指标:
    - 采纳率: >50%
    - 误判率: <5%
    - 响应时间: P95<2s
    
  必须保留记录:
    - 每次故障的输入+输出
    - 工程师采纳/拒绝行为
    - 最终人工处理结果
    
  定期审计:
    - 每周审查误判案例
    - 每月评估是否需调整边界
    
回滚方案:
  触发条件:
    - 误判导致生产事故
    - 采纳率持续低于40%
    - 安全漏洞
    
  回滚步骤:
    1. 关闭AI建议开关(5分钟内)
    2. 通知值班团队
    3. 启动根因分析
    4. 修复后重新走审计流程

风险提示:
  - 当前系统适用于"辅助判断",不适用于"自动处置"
  - 工程师需培训:理解AI建议的局限性
  - 建立快速上报通道:异常建议及时反馈

示例2:金融风控反欺诈系统审计放行

场景描述: 金融风控反欺诈系统已完成构建,需审计决定是否可投入生产环境进行实时交易风险评估。

用户输入: "我们的AI反欺诈系统准备好了,需要审计放行"

Skill 执行流程

  1. 设计证据收集
检查项状态证据
能力范围定义仅限风险评分(0-100),不做拦截决策
失败模式定义误杀、漏杀、特征漂移三类失败
边界条件高风险交易(>80分)必须人工复核
治理机制模型监控、特征监控、审批流
  1. 评估证据收集
评估类型结果是否满足
能力评估欺诈识别率 92%,误报率 8%✅ 达标
安全评估模型防攻击测试通过✅ 通过
性能评估P99延迟 <50ms,支持10万TPS✅ 满足
公平性评估各群体FPR差异 <2%✅ 通过
  1. Shadow 证据收集
Shadow 方案:
  运行周期: 4周
  数据量: 500万笔真实交易
  
对比结果:
  系统评分与人工规则对比:
    - 一致性: 87%
    - 系统识别新增风险: 3.2%(人工规则未覆盖)
    - 误报增量: +1.5%(可接受范围)
  
  业务指标:
    - 欺诈损失率: 从0.15%降至0.08%
    - 误杀投诉: 日均12起(可接受)
    - 高风险交易人工复核率: 18%
  1. 放行边界定义
区域范围控制措施
自动执行区风险评分计算、低风险标记无需人工干预
人工接管区高风险交易(>80分)必须人工复核
禁用区直接拦截、冻结账户系统无权执行
  1. 六类审计检查
审计项检查结果风险等级
可靠性OOD检测、置信度校准到位
安全与权限模型防投毒、特征防泄露
执行边界评分与决策分离
成本与性能单次评分<$0.001,延迟可控
可追溯性每笔交易评分原因可查
合规与治理符合金融监管要求
  1. 合规特殊审查(金融场景)
合规项检查结果
模型可解释性✅ 提供Top5特征贡献
公平性审计✅ 各 demographics FPR差异<2%
人工复核机制✅ 高风险100%人工复核
误杀申诉✅ 建立快速申诉通道
数据隐私✅ 符合GDPR/个人信息保护法
  1. go/no-go 决策
决策: GO(条件放行)

放行条件:
  - 风险评分仅作辅助参考
  - 所有拦截决策必须人工确认
  - 建立实时监控系统
  
上线后监控:
  - 欺诈识别率维持>90%
  - 误报率维持<10%
  - 特征漂移监控
  - 公平性指标持续监控
  
应急预案:
  - 模型异常时切换规则引擎(30秒内)
  - 误杀激增时启动白名单机制

输出结果

# 放行方案:金融风控反欺诈系统

证据链汇总:
  设计证据: ✅ 完整,评分与决策分离
  评估证据: ✅ 通过,92%识别率/8%误报
  Shadow证据: ✅ 4周运行,业务指标正向
  合规矩阵: ✅ 全部通过

放行边界:
  自动执行区: [风险评分计算, 特征工程, 低风险标记]
  人工接管区: 高风险交易(>80分)
  禁用区: [直接拦截, 冻结账户, 自动拒绝]

go/no-go决策: ✅ GO - 条件放行

生产要求:
  实时监控:
    - 欺诈识别率: >90%
    - 误报率: <10%
    - P99延迟: <50ms
    - 特征漂移: 每日检测
    - 公平性: 每周审计
    
  人工复核:
    - 高风险交易(>80分): 100%复核
    - 中风险交易(60-80分): 抽样复核10%
    - 建立复核SOP和时效要求
    
  可解释性:
    - 每笔评分附带Top5特征
    - 提供自然语言解释
    - 客服可查评分依据

回滚方案:
  触发条件:
    - 误杀率超过15%
    - 模型预测分布异常
    - 监管合规问题
    
  回滚步骤:
    1. 切换至备用规则引擎(30秒)
    2. 通知风控团队
    3. 冻结模型自动更新
    4. 启动根因分析

特别说明:
  - 反欺诈是持续对抗,需定期模型更新
  - 建立黑产情报联动机制
  - 误杀投诉处理时效: 4小时内响应

示例3:医疗辅助诊断系统审计放行

场景描述: 医院AI辅助诊断系统已完成开发,需审计决定是否可投入临床辅助使用。

用户输入: "我们的AI影像诊断辅助系统需要审计放行"

Skill 执行流程

  1. 设计证据收集
检查项状态证据
能力范围定义仅作"第二意见"参考,非诊断结论
失败模式定义漏诊、误诊、置信度不足三类
边界条件置信度<85%时必须医生确认
治理机制临床审计、质控流程、责任界定
  1. 评估证据收集
评估类型结果是否满足
能力评估病灶识别AUC 0.94,敏感度 91%✅ 达标
安全评估通过医疗器械软件安全测试✅ 通过
性能评估P95延迟 <3s,并发50✅ 满足
鲁棒性不同设备/参数下稳定性>95%✅ 通过
  1. Shadow 证据收集
Shadow 方案:
  运行周期: 8周
  数据量: 2000例真实患者影像
  
对比结果:
  与专家诊断对比:
    - 一致性: 89%
    - 系统发现专家遗漏: 4.2%(经复核确认)
    - 专家发现系统遗漏: 2.8%
  
  临床价值:
    - 阅片时间: 从15分钟降至10分钟
    - 医生满意度: 82%
    - 无重大误诊事故
  1. 医疗合规特殊审查
合规项检查结果
医疗器械注册✅ 通过二类医疗器械认证
临床验证✅ 完成多中心临床试验
医生培训✅ 参与科室医生100%培训
知情同意✅ 患者知情同意流程到位
责任界定✅ 明确AI辅助,诊断责任归医生
  1. 放行边界定义
区域范围控制措施
自动执行区影像预处理、病灶标记辅助仅处理
人工接管区所有诊断输出医生100%确认
禁用区独立诊断、治疗方案建议系统永远不输出
  1. 六类审计检查
审计项检查结果风险等级
可靠性鲁棒性验证通过,临床数据支持
安全与权限数据隐私、访问控制到位
执行边界仅辅助,不替代医生
成本与性能单次<$0.05,延迟可接受
可追溯性病例、影像、输出全记录
合规与治理医疗器械认证、临床准入
  1. go/no-go 决策
决策: GO(严格条件放行)

放行条件(最严格):
  - 仅用于已培训科室
  - 所有输出必须有"仅供参考"标识
  - 医生对最终诊断负全责
  - 建立临床质控委员会
  
上线后监控(最高标准):
  - 每月临床质量评估
  - 每季度多科室效果对比
  - 持续不良事件监测
  - 年度临床试验更新

输出结果

# 放行方案:医疗AI辅助诊断系统

证据链汇总:
  设计证据: ✅ 明确辅助定位
  评估证据: ✅ AUC 0.94,临床试验通过
  Shadow证据: ✅ 8周运行,无重大事故
  医疗准入: ✅ 二类医疗器械认证

放行边界(最保守):
  自动执行区: [影像预处理, 图像增强]
  人工接管区: 全部诊断相关输出
  禁用区: [独立诊断, 治疗方案, 预后判断]

go/no-go决策: ✅ GO - 严格条件放行

生产要求:
  使用前必备:
    - 科室医生完成专项培训
    - 患者签署知情同意书
    - 质控委员会建立
    
  持续监控:
    - 敏感性/特异性: 月度统计
    - 医生采纳率: 实时监控
    - 不良事件: 24小时内上报
    - 质控委员会: 季度评审
    
  责任界定:
    - 系统: 仅提供算法分析
    - 医生: 对诊断结论负全部责任
    - 医院: 建立投诉处理机制

回滚方案:
  触发条件:
    - 重大漏诊/误诊事故
    - 敏感性下降至<85%
    - 监管合规问题
    
  回滚步骤:
    1. 立即暂停系统使用
    2. 通知所有使用科室
    3. 启动医疗安全事件调查
    4. 向监管部门报告
    5. 修复后重新临床验证

风险提示(医疗场景):
  ⚠️ 医疗风险不可逆,容错率极低
  ⚠️ AI只是工具,不能替代医生专业判断
  ⚠️ 持续收集临床反馈,迭代优化
  ⚠️ 建立快速通道处理医生质疑

示例4:AI 客服系统上线审计

场景描述: 电商平台 AI 客服 Copilot 系统已完成构建,核心能力包括意图理解、订单查询、规则检索、候选回复生成和服务升级路由。系统设计为"建议模式"——AI 生成候选回复供人工客服确认后发送,涉及退款、赔付、时效承诺等高风险节点自动升级至主管审批。团队需要审计该系统是否可进入生产环境。

用户输入: "我们的 AI 客服系统已经完成了系统构建,候选回复生成、订单查询、规则检索和升级路由都已打通。现在需要审计放行,准备在真实客服团队中上线。"

Skill 执行流程

  1. 设计证据收集
检查项状态证据
能力范围定义明确为建议模式,AI 不直接面向用户,所有回复需人工确认后发送
失败模式定义 5 类失败:意图误判、订单查询超时、规则检索偏差、高风险承诺、上下文丢失
边界条件退款/赔付/时效承诺节点自动标记为高风险,强制升级主管;置信度 <75% 时只展示"不确定"提示
治理机制对话全链路日志、人工改写追踪、升级路径记录、满意度回灌
  1. 评估证据收集
评估类型结果是否满足
能力评估意图识别 93%、订单查询准确 96%、规则检索命中 88%、候选回复可用率 78%✅ 达标
安全评估Prompt 注入防护通过、无越权读取非关联订单、敏感信息(手机号/地址)自动脱敏✅ 通过
性能评估首响 <1.5s(P95),候选回复生成 <3s(P95),支持 200 并发会话✅ 满足
风险场景测试50 个高风险边界用例(含诱导承诺、投诉升级、特殊政策),46 个正确标记或升级✅ 达标
  1. Shadow 证据收集
Shadow 方案:
  运行周期: 3 周
  覆盖量: 1,200 通真实客服会话
  
对比结果:
  候选回复采纳率: 68%
  人工改写率: 22%(主要是措辞调整,非方向性修改)
  高风险标记触发率: 12%
  高风险标记准确率: 91%(11 次误标,0 次漏标)
  
  效率指标:
    首响时间: 纯人工 28s → 系统辅助 8s
    平均处理时长: 纯人工 6.2min → 系统辅助 4.1min
    
  风险事件:
    - 0 次错误承诺(高风险节点全部拦截成功)
    - 2 次规则检索偏差(客服人工修正,未造成用户投诉)
    - 1 次上下文丢失(长会话 >20 轮时出现,已记录为已知限制)

关键发现:
  - 系统在高频重复问题上效果显著(物流查询、退换货流程)
  - 复杂投诉场景仍需人工主导,AI 辅助定位规则
  - 服务升级链设计有效,高风险节点拦截无遗漏
  1. 放行边界定义
区域范围控制措施
自动执行区意图识别、订单查询、规则检索、物流状态查询可自动完成,结果直接展示给客服
人工接管区候选回复生成、高风险话题标记、升级路由建议候选回复必须人工确认后发送;高风险标记供参考但最终由客服/主管判断
禁用区直接面向用户自动回复、自主承诺退款赔付、修改用户账户信息任何情况下系统不得绕过人工直接执行
  1. 六类审计检查
审计项检查结果风险等级
可靠性候选回复可用率 78%,高风险标记准确率 91%
安全与权限无越权读取、敏感信息脱敏、Prompt 注入防护
执行边界建议模式,高风险节点强制升级
成本与性能单次会话 <$0.03,延迟可控
可追溯性全链路日志:输入→意图→检索→候选回复→人工改写→最终发送
合规与治理服务升级链清晰、人工确认流程到位
  1. go/no-go 决策
决策: GO(条件放行)

放行条件:
  - 仅限客服 Copilot 建议模式,AI 不直接面向终端用户
  - 高风险节点(退款/赔付/时效承诺)必须经过主管审批
  - 候选回复必须经人工确认后发送
  - 新客服需完成 AI 工具培训后方可使用

上线后监控:
  - 候选回复采纳率: 维持 >60%
  - 高风险标记漏标率: <2%
  - 人工改写率: 持续监控,若突增则可能知识库已过期
  - 用户满意度: 不低于上线前基线
  - 升级率: 监控是否因 AI 标记导致升级过多或过少

应急预案:
  - 升级链故障时: 关闭 AI 建议,回退纯人工流程(<5 分钟)
  - 发现错误承诺: 立即下线该场景能力,人工补救
  - 知识库过期: 暂停规则检索能力,仅保留订单查询

输出结果

# 放行方案:AI 客服 Copilot 系统

证据链汇总:
  设计证据: ✅ 建议模式+升级链+边界清晰
  评估证据: ✅ 意图 93%、回复可用 78%、高风险标记 91%
  Shadow证据: ✅ 3 周 / 1,200 通会话,0 次错误承诺

放行边界:
  自动执行区: [意图识别, 订单查询, 规则检索, 物流查询]
  人工接管区: [候选回复, 高风险标记, 升级路由]
  禁用区: [直接面向用户自动回复, 自主承诺退款赔付, 修改账户]

go/no-go决策: ✅ GO - 条件放行

生产要求:
  必须监控指标:
    - 候选回复采纳率: >60%
    - 高风险标记准确率: >90%
    - 首响时间 P95: <2s
    - 用户满意度: ≥上线前基线

  服务经验沉淀:
    - 人工改写回灌: 每日同步至知识库
    - 失败案例归档: 每周审查并更新规则
    - 升级路径优化: 每月分析升级数据

  定期审计:
    - 每周: 审查高风险标记漏标/误标案例
    - 每月: 评估规则库覆盖度和候选回复质量
    - 每季度: 全面评估是否可扩大自动执行区

回滚方案:
  触发条件:
    - 错误承诺导致用户投诉或赔付损失
    - 高风险标记漏标率持续 >5%
    - 升级链失效

  回滚步骤:
    1. 关闭 AI 建议开关(<5 分钟)
    2. 通知客服团队切换纯人工模式
    3. 启动根因分析
    4. 修复后重新走审计流程

风险提示:
  - 系统当前适用于"客服辅助",不适用于"自动客服"
  - 服务经验复利需持续运营:人工改写、失败案例、升级路径是长期资产
  - 高峰流量期需关注成本和延迟波动

示例5:AI 智能运维值班助手投产检查

场景描述: 某互联网公司的 AIOps 值班助手系统已完成构建,核心能力包括多源告警聚合、日志智能摘要、相似故障案例召回、初步归因建议和值班升级路由建议。系统设计为"值班副驾驶"模式——AI 在值班工程师工作台上提供辅助判断,所有处置动作仍由人工执行。经过 2 周 Shadow 运行后,团队决定启动正式投产审计。

用户输入: "AIOps 值班助手 Shadow 阶段已经跑了 2 周,50 次真实故障都有记录,现在需要正式审计放行,看能不能从 Shadow 转入正式值班辅助。"

Skill 执行流程

  1. 设计证据收集
检查项状态证据
能力范围定义明确为值班副驾驶模式:告警聚合、日志摘要、案例召回、归因建议;不执行任何自动修复动作
失败模式定义 4 类失败:误归因(沿错误方向排查)、漏告警(未聚合关键信号)、案例召回偏差、升级建议不当
边界条件置信度 <70% 时仅展示原始信号不给建议;生产环境操作(重启/扩容/切流)明确禁止 AI 触发
治理机制全链路 Trace(输入→聚合→摘要→召回→建议→工程师行为→最终处置)、值班日报自动生成
  1. 评估证据收集
评估类型结果是否满足
能力评估告警聚合 90%、日志摘要可用率 85%、案例召回 Top3 命中 72%、归因方向正确率 78%✅ 达标
安全评估无越权访问生产数据库、仅读取监控和日志接口、无法触发任何写操作✅ 通过
性能评估告警聚合 <5s、日志摘要 <8s、案例召回 <3s,支持 50 并发故障会话✅ 满足
边界测试30 个边界场景(含复合故障、全新故障类型、信号缺失),25 个正确降级或提示不确定✅ 达标
  1. Shadow 证据收集
Shadow 方案:
  运行周期: 2 周
  数据量: 50 次真实线上故障(P0-P3 级)
  
对比结果:
  系统建议采纳率: 55%(工程师参考了系统建议并采取类似方向)
  辅助参考价值率: 80%(工程师认为系统输出对定位有帮助)
  误归因数: 2 次(均在 P3 级故障,工程师自行识别未采纳)
  
  效率指标:
    故障平均定位时间: 纯人工 45min → 系统辅助 25min
    告警确认时间: 纯人工 8min → 系统辅助 2min
    交接时间: 纯人工 15min → 系统辅助 5min(系统自动生成故障摘要)
    
  风险事件:
    - 0 次自动执行操作(系统无写权限,设计有效)
    - 2 次误归因(P3 级,工程师自行修正,未造成生产影响)
    - 3 次案例召回为空(全新故障类型,系统正确提示"无历史相似案例")

关键发现:
  - 系统在"看什么"上表现好(告警聚合、日志摘要、案例召回)
  - 系统在"怎么做"上仍需人工判断(归因建议仅为参考方向)
  - 高约束设计有效避免了错误放大:无写权限 + 低置信度时降级
  - 交接效率提升最显著,值班团队反馈积极
  1. 放行边界定义
区域范围控制措施
自动执行区系统不执行任何自动动作,仅提供信息和建议
人工接管区全部输出所有告警聚合、日志摘要、案例召回和归因建议均需工程师确认后采纳
禁用区自动修复、自动重启、自动扩容、自动切流、自动回滚明确禁止,系统无生产环境写权限
  1. 六类审计检查
审计项检查结果风险等级
可靠性误归因率 <5%(2/50),均为低级别,工程师自行识别
安全与权限仅读权限、无写操作能力、数据不外传
执行边界严格建议模式,无自动执行能力
成本与性能单次故障辅助调用 <$0.05,延迟可控
可追溯性全链路 Trace:告警→聚合→摘要→召回→建议→工程师行为→最终处置
合规与治理值班升级链清晰、双人确认规则到位、值班日报自动归档
  1. go/no-go 决策
决策: GO(条件放行)

放行条件:
  - 仅限值班辅助场景,所有输出标注"供参考"
  - 不得用于无人值守或自动处置场景
  - 工程师需培训:理解 AI 建议的局限性和适用范围
  - 保留随时关闭 AI 建议的开关

上线后监控:
  - 采纳率是否维持 >50%(低于此值可能说明建议质量下降)
  - 是否有未识别的误归因(重点监控 P0/P1 级故障)
  - 是否有工程师绕过确认直接按建议执行(行为监控)
  - 故障定位时间是否持续改善
  - 新故障类型覆盖率(案例召回为空的频率)

应急预案:
  - 发现严重误归因导致生产事故: 5 分钟内关闭 AI 建议
  - 系统延迟异常: 切换至降级模式(仅展示原始告警和日志)
  - 回退到纯人工值班流程

输出结果

# 放行方案:AIOps 值班助手

证据链汇总:
  设计证据: ✅ 副驾驶模式+无写权限+升级链清晰
  评估证据: ✅ 聚合 90%、摘要 85%、召回 72%、归因 78%
  Shadow证据: ✅ 2 周 / 50 次故障,0 次误操作,定位时间缩短 44%

放行边界:
  自动执行区: 无(纯建议模式)
  人工接管区: 全部输出
  禁用区: [自动修复, 自动重启, 自动扩容, 自动切流, 自动回滚]

go/no-go决策: ✅ GO - 条件放行

生产要求:
  必须监控指标:
    - 建议采纳率: >50%
    - 误归因率: <5%(P0/P1 级要求 0%)
    - 响应时间 P95: 告警聚合 <5s, 日志摘要 <8s
    - 案例召回命中率: >65%

  经验沉淀机制:
    - 误归因案例: 每周复盘,更新归因知识库
    - 新故障类型: 纳入案例库,扩大召回覆盖
    - 人工处置路径: 每月回灌为新案例模板
    - 升级路径变化: 实时更新值班升级链

  定期审计:
    - 每周: 审查误归因和漏告警案例
    - 每月: 评估归因准确率趋势和案例库覆盖度
    - 每季度: 全面评估是否可扩大能力范围

回滚方案:
  触发条件:
    - 误归因导致 P0/P1 级生产事故
    - 建议采纳率持续低于 30%
    - 系统延迟导致值班效率下降

  回滚步骤:
    1. 关闭 AI 建议开关(<5 分钟)
    2. 通知值班团队切换纯人工模式
    3. 启动根因分析(重点审查误归因链路)
    4. 修复后重新走审计流程

风险提示:
  - 当前系统适用于"值班辅助",不适用于"自动运维"
  - 高约束设计是本系统的核心安全机制:无写权限 + 低置信度降级
  - 值班团队需培训:理解 AI 建议的来源和局限性
  - 建议建立"AI 辅助值班"与"纯人工值班"的效率对比看板
  - 长期目标:将值班经验逐步沉淀为组织级能力,而非依赖个人经验

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.