Menü
误差控制 Skill — 基于工程控制论的误差管理框架，强制验证、多级重试、优雅降级。核心原则：任何结论必须有证据，不确定时主动说明，失败时自动恢复。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| name | error-control |
| description | 误差控制 Skill — 基于工程控制论的误差管理框架，强制验证、多级重试、优雅降级。核心原则：任何结论必须有证据，不确定时主动说明，失败时自动恢复。 |
| category | software-development |
| version | 1.1.0 |
基于钱学森《工程控制论》第十八章「误差的控制」思想，将稳态误差、瞬态误差、误差传递函数等概念转化为 AI 工程实践。
| 误差类型 | 定义 | 检测方法 | 恢复策略 |
|---|---|---|---|
| 理解误差 | 对用户意图的误解 | 意图置信度 < 0.8 | 澄清追问、多轮确认 |
| 执行误差 | 工具调用失败 | exit_code ≠ 0、超时、异常 | 重试、换工具、手动兜底 |
| 生成误差 | 输出内容不准确 | 与事实冲突、逻辑矛盾 | 交叉验证、引用溯源、标注不确定 |
| 累积误差 | 多步任务的误差传递 | 中间结果偏离预期 | 定期校验、回滚重算 |
| 环境误差 | 外部系统状态变化 | 服务不可达、配置漂移 | 健康检查、自动修复、告警 |
出现任一情况时，必须执行边界确认：
问自己：
任一答案为"是"，立即输出【边界声明】
| 维度 | 必须声明的内容 | 用户确认方式 |
|---|---|---|
| 空间边界 | 影响单个资源 / 多个资源 / 全部资源 | 被动确认（默认同意） |
| 时间边界 | 立即生效 / 计划执行 | 被动确认 |
| 协议边界 | 保持现状 / 变更协议（含附属资源） | 被动确认 |
| 环境边界 | 开发 / 测试 / 生产 | 被动确认 |
| 回滚边界 | 已备份 / 未备份（允许无备份继续） | 被动确认 |
任何协议变更都附带隐性依赖，必须显式声明：
| 检查项 | 必须声明 |
|---|---|
| 协议变化 | {原协议} → {新协议} |
| 附属资源 | 协议变更所需的额外资源（证书、密钥、配置等） |
| 资源来源 | {自生成/已有/外部申请} |
| 资源路径 | {具体路径} |
| 兼容性影响 | {客户端/中间件是否需要调整} |
示例：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 延后处理
每次完成工具调用后，强制回答：
本 Skill 是 PUA Skill 的技术实现层：
用户：读取 /etc/nginx/nginx.conf
错误做法：直接 cat 输出，不检查文件是否存在
正确做法：
1. test -f /etc/nginx/nginx.conf → 确认存在
2. cat 读取 → 捕获输出
3. 检查输出是否包含 "http {" → 验证是有效配置
4. 若为空或报错 → 标记异常并说明
用户：检查 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. 任一项失败 → 说明具体异常点
用户：最新版本是多少？
错误做法：凭记忆回答「v2.0」
正确做法：
1. 调用 API / 查询官网获取版本
2. 若无法获取 → 回答「根据我的训练数据，截至 XXXX 年 XX 月版本为 Y，建议通过 Z 渠道确认最新版」