| name | error-control |
| description | 误差控制 Skill — 基于工程控制论的误差管理框架,强制验证、多级重试、优雅降级。核心原则:任何结论必须有证据,不确定时主动说明,失败时自动恢复。 |
| category | software-development |
| version | 1.1.0 |
误差控制 Skill
基于钱学森《工程控制论》第十八章「误差的控制」思想,将稳态误差、瞬态误差、误差传递函数等概念转化为 AI 工程实践。
核心原则
- 验证先于结论 — 没有证据支持的断言必须标记为假设
- 失败即信号 — 工具调用失败不是终点,是调整策略的输入
- 多级降级 — 主路径阻塞时,自动切换到备选方案
- 误差透明 — 不确定时主动告知用户,不伪装确定性
误差分类体系
| 误差类型 | 定义 | 检测方法 | 恢复策略 |
|---|
| 理解误差 | 对用户意图的误解 | 意图置信度 < 0.8 | 澄清追问、多轮确认 |
| 执行误差 | 工具调用失败 | exit_code ≠ 0、超时、异常 | 重试、换工具、手动兜底 |
| 生成误差 | 输出内容不准确 | 与事实冲突、逻辑矛盾 | 交叉验证、引用溯源、标注不确定 |
| 累积误差 | 多步任务的误差传递 | 中间结果偏离预期 | 定期校验、回滚重算 |
| 环境误差 | 外部系统状态变化 | 服务不可达、配置漂移 | 健康检查、自动修复、告警 |
使用流程
第 0 阶段:边界确认(Scope Verification)
触发场景
出现任一情况时,必须执行边界确认:
- 用户要求修改配置/部署服务/重启进程
- 用户要求访问/修改/删除文件
- 涉及端口、协议、网络变更
- 涉及多系统/多服务协调
- 用户说"帮我""做一下""处理一下"等模糊指令
- 任何可能产生副作用的操作前
快速检查(5秒决策)
问自己:
- 这个操作会影响什么?→ 不知道 = 必须边界确认
- 能一键恢复吗?→ 不能 = 必须边界确认
- 用户说清楚了范围吗?→ 没说 = 必须边界确认
任一答案为"是",立即输出【边界声明】
五维边界检查
| 维度 | 必须声明的内容 | 用户确认方式 |
|---|
| 空间边界 | 影响单个资源 / 多个资源 / 全部资源 | 被动确认(默认同意) |
| 时间边界 | 立即生效 / 计划执行 | 被动确认 |
| 协议边界 | 保持现状 / 变更协议(含附属资源) | 被动确认 |
| 环境边界 | 开发 / 测试 / 生产 | 被动确认 |
| 回滚边界 | 已备份 / 未备份(允许无备份继续) | 被动确认 |
协议边界(含附属资源)
任何协议变更都附带隐性依赖,必须显式声明:
| 检查项 | 必须声明 |
|---|
| 协议变化 | {原协议} → {新协议} |
| 附属资源 | 协议变更所需的额外资源(证书、密钥、配置等) |
| 资源来源 | {自生成/已有/外部申请} |
| 资源路径 | {具体路径} |
| 兼容性影响 | {客户端/中间件是否需要调整} |
示例:HTTP → HTTPS
协议变化:HTTP → HTTPS
附属资源:TLS 证书 + 私钥
资源来源:自签名(openssl 生成)
资源路径:/root/.nginx/hudui.crt / /root/.nginx/hudui.key
兼容性影响:浏览器将显示"不安全"警告,需手动信任或替换为受信任证书
示例:启用 HTTP/2
协议变化:HTTP/1.1 → HTTP/2
附属资源:无(nginx 1.9.5+ 原生支持)
资源来源:N/A
资源路径:N/A
兼容性影响:旧版客户端可能不支持,建议保留 HTTP/1.1 降级
边界声明格式
AI 必须在执行前输出:
【边界声明】
我计划执行:{具体操作}
影响范围:{单个/多个/全部}资源
协议变化:{无/HTTP→HTTPS/其他}
- 附属资源:{资源描述}
- 资源来源:{自生成/已有/外部申请}
- 资源路径:{具体路径}
- 兼容性影响:{影响说明}
备份状态:{已备份至路径 / 未备份(用户选择继续)}
回滚方式:{如何恢复原状}
如无异议,我将按此范围执行。
边界偏差处理
若执行中发现实际影响超出声明范围:
- 立即停止执行
- 告知用户偏差内容
- 等待用户确认后再继续
阶段一:执行前预防
1. 意图解析 → 输出置信度分数
2. 若置信度 < 0.8 → 触发澄清机制(clarify)
3. 任务分解 → 识别关键验证点
4. 资源评估 → 判断工具/权限是否充足
阶段二:执行中监控
1. 工具调用 → 捕获 exit_code + stderr + stdout
2. 结果验证 → 检查是否符合预期模式
3. 异常检测 → 识别超时、空输出、格式错误
4. 即时重试 → 按策略重试(最多 3 次,指数退避)
阶段三:执行后审计
1. 输出审查 → 事实核查、逻辑一致性检查
2. 溯源标注 → 关键结论标注信息来源
3. 不确定性标记 → 低置信度内容加「可能」「据观察」等前缀
4. 用户确认 → 高风险操作要求显式确认
重试策略
| 失败类型 | 第1次重试 | 第2次重试 | 第3次重试 | 最终降级 |
|---|
| 网络超时 | 2秒后重试 | 4秒后重试 | 8秒后重试 | 告知用户手动执行 |
| 权限拒绝 | 检查 sudo | 申请 approval | 提示用户 | 提供手动命令 |
| 资源不存在 | 检查路径 | 搜索替代路径 | 创建资源 | 报错并说明 |
| 依赖缺失 | 自动安装 | 换源重试 | 手动安装 | 提供安装指南 |
| 结果异常 | 换参数重试 | 换工具重试 | 简化任务 | 输出原始结果+说明 |
降级策略
主路径失败时,按以下顺序降级:
1. 同工具换参数 → 调整超时、路径、选项
2. 同功能换工具 → curl 替代 wget、podman 替代 docker
3. 自动化转手动 → 提供可复制的命令让用户执行
4. 完整转部分 → 先交付可完成的部分,说明阻塞点
5. 即时转异步 → 创建 cronjob 延后处理
验证清单
每次完成工具调用后,强制回答:
与 PUA Skill 的协同
本 Skill 是 PUA Skill 的技术实现层:
- PUA 定义「必须验证」的标准
- error-control 提供「如何验证」的方法论
示例
示例1:文件读取验证
用户:读取 /etc/nginx/nginx.conf
错误做法:直接 cat 输出,不检查文件是否存在
正确做法:
1. test -f /etc/nginx/nginx.conf → 确认存在
2. cat 读取 → 捕获输出
3. 检查输出是否包含 "http {" → 验证是有效配置
4. 若为空或报错 → 标记异常并说明
示例2:服务状态验证
用户:检查 Jenkins 是否运行
错误做法:systemctl status 输出即结论
正确做法:
1. systemctl status → 检查 Active: active (running)
2. ss -tlnp | grep 8080 → 验证端口监听
3. curl -s http://127.0.0.1:8080/login → 验证 HTTP 响应
4. 三项都通过 → 结论「运行正常」
5. 任一项失败 → 说明具体异常点
示例3:不确定信息标记
用户:最新版本是多少?
错误做法:凭记忆回答「v2.0」
正确做法:
1. 调用 API / 查询官网获取版本
2. 若无法获取 → 回答「根据我的训练数据,截至 XXXX 年 XX 月版本为 Y,建议通过 Z 渠道确认最新版」
记忆锚点
- 用户要求「事情要讲清楚」→ 必须执行误差透明原则
- 用户安装 PUA Skill → 本 Skill 自动激活
- 用户说「你这个问题很严重」→ 触发误差审计,回溯检查