error-control

name	error-control
description	误差控制 Skill — 基于工程控制论的误差管理框架，强制验证、多级重试、优雅降级。核心原则：任何结论必须有证据，不确定时主动说明，失败时自动恢复。
category	software-development
version	1.1.0

误差控制 Skill

基于钱学森《工程控制论》第十八章「误差的控制」思想，将稳态误差、瞬态误差、误差传递函数等概念转化为 AI 工程实践。

核心原则

1. 验证先于结论 — 没有证据支持的断言必须标记为假设
2. 失败即信号 — 工具调用失败不是终点，是调整策略的输入
3. 多级降级 — 主路径阻塞时，自动切换到备选方案
4. 误差透明 — 不确定时主动告知用户，不伪装确定性

误差分类体系

误差类型	定义	检测方法	恢复策略
理解误差	对用户意图的误解	意图置信度 < 0.8	澄清追问、多轮确认
执行误差	工具调用失败	exit_code ≠ 0、超时、异常	重试、换工具、手动兜底
生成误差	输出内容不准确	与事实冲突、逻辑矛盾	交叉验证、引用溯源、标注不确定
累积误差	多步任务的误差传递	中间结果偏离预期	定期校验、回滚重算
环境误差	外部系统状态变化	服务不可达、配置漂移	健康检查、自动修复、告警

使用流程

第 0 阶段：边界确认（Scope Verification）

触发场景

出现任一情况时，必须执行边界确认：

• 用户要求修改配置/部署服务/重启进程
• 用户要求访问/修改/删除文件
• 涉及端口、协议、网络变更
• 涉及多系统/多服务协调
• 用户说"帮我""做一下""处理一下"等模糊指令
• 任何可能产生副作用的操作前

快速检查（5秒决策）

问自己：

1. 这个操作会影响什么？→ 不知道 = 必须边界确认
2. 能一键恢复吗？→ 不能 = 必须边界确认
3. 用户说清楚了范围吗？→ 没说 = 必须边界确认

任一答案为"是"，立即输出【边界声明】

五维边界检查

维度	必须声明的内容	用户确认方式
空间边界	影响单个资源 / 多个资源 / 全部资源	被动确认（默认同意）
时间边界	立即生效 / 计划执行	被动确认
协议边界	保持现状 / 变更协议（含附属资源）	被动确认
环境边界	开发 / 测试 / 生产	被动确认
回滚边界	已备份 / 未备份（允许无备份继续）	被动确认

协议边界（含附属资源）

任何协议变更都附带隐性依赖，必须显式声明：

检查项	必须声明
协议变化	{原协议} → {新协议}
附属资源	协议变更所需的额外资源（证书、密钥、配置等）
资源来源	{自生成/已有/外部申请}
资源路径	{具体路径}
兼容性影响	{客户端/中间件是否需要调整}

示例：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 延后处理

验证清单

每次完成工具调用后，强制回答：

• exit_code 是否为 0？
• stdout 是否包含预期内容？
• stderr 是否有警告/错误？
• 结果是否可被独立验证？
• 若用户质疑，我能否提供证据？

与 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 自动激活
• 用户说「你这个问题很严重」→ 触发误差审计，回溯检查