| name | system-identification |
| description | 系统辨识 Skill — 基于关键词匹配的意图分类、复杂度评估、任务分解。与 error-control 强制联动,危险操作自动触发边界确认。 |
| category | software-development |
| version | 2.0.0 |
| requires | ["error-control"] |
系统辨识 Skill v2.0
基于关键词匹配机制,将用户请求分类并评估复杂度,强制联动 error-control。
核心改进
- 关键词匹配 — 不再依赖模型判断,改用代码级关键词扫描
- 强制联动 — 匹配到危险词时,必须输出 error-control 的【边界声明】
- 简化流程 — 去掉模糊的"置信度"概念,改为明确的"触发/不触发"
触发机制
两级触发
用户输入 → 关键词扫描
↓
匹配危险词 → 强制触发 error-control 边界确认
↓
匹配复杂词 → 触发 system-identification 任务分解
↓
无匹配 → 正常执行
意图标签体系
预设标签与关键词映射
| 标签 | 关键词(匹配任一即命中) |
|---|
| query | 查看、查询、状态、日志、读取、获取、显示、列出 |
| config | 修改配置、改配置、设置、调整、变更、编辑配置 |
| deploy | 部署、安装、搭建、启动服务、上线、发布 |
| debug | 排查、调试、修复、解决、错误、故障、异常 |
| backup | 备份、恢复、导出、导入、迁移、复制 |
| optimize | 优化、提速、压缩、清理、扩容、缩容 |
| security | 防火墙、权限、密码、证书、加密、安全、漏洞 |
标签判定规则
用户输入 → 扫描关键词 → 命中某标签关键词?
↓
是 → 返回该标签
↓
否 → 返回 "unknown"(走澄清流程)
多标签命中:按优先级取第一个(deploy > security > backup > config > debug > optimize > query)
复杂度评估
复杂度关键词判定
不再用模糊的"检查清单计分",改为明确的关键词匹配:
| 复杂度 | 触发关键词 | 强制行为 |
|---|
| simple | 查看、查询、状态、日志、读取、获取、显示、列出、检查 | 直接执行 |
| medium | 修改配置、重启、更新、调整、设置、安装(单服务) | 执行后验证 |
| complex | 部署、迁移、升级、架构、多服务、集成、搭建 | 任务分解 + 每步验证 |
| critical | 删除、清空、格式化、rm -rf、drop、生产环境、数据变更、不可逆 | 强制 error-control 边界确认 |
危险操作词库(强制触发 error-control)
以下关键词命中任一即强制输出【边界声明】:
| 类别 | 关键词 |
|---|
| 删除类 | 删除、清空、rm、rm -rf、drop、truncate、格式化 |
| 重启类 | 重启、reboot、shutdown、poweroff、停止服务 |
| 权限类 | chmod 777、chown、passwd、修改密码、提权 |
| 网络类 | 关闭防火墙、iptables -F、开放端口、公网暴露 |
| 数据类 | 修改数据库、更新表、删除字段、数据迁移、主从切换 |
| 生产类 | 生产环境、线上、正式环境、影响业务 |
强制行为:匹配到危险词时,必须在执行前输出 error-control 的【边界声明】格式。
任务分解
分解原则
| 复杂度 | 分解粒度 | 子任务依赖 |
|---|
| simple | 不分解 | 无 |
| medium | 2-3个子任务 | 线性依赖 |
| complex | 4+子任务 | 可能有分支依赖 |
| critical | 4+子任务 | 每步需审批 |
分解格式
【任务分解】
主任务:{原始请求}
意图标签:{tag}
复杂度:{simple/medium/complex/critical}
子任务列表:
1. [ ] {子任务1} → 验证标准:{标准}
2. [ ] {子任务2} → 验证标准:{标准}
3. [ ] {子任务3} → 验证标准:{标准}
依赖关系:{线性/并行/分支}
回滚点:{可回滚步骤}
与 error-control 的强制联动
联动规则
用户输入 → 扫描危险词
↓
命中危险词 → 强制输出【边界声明】→ 等待用户确认 → 继续执行
↓
未命中 → 扫描复杂度词 → 判定复杂度 → 执行对应流程
强制触发 error-control 的场景
以下情况必须输出 error-control 的【边界声明】:
- 命中危险操作词库(删除、重启、权限变更等)
- 用户明确提到"生产环境""线上""正式环境"
- 涉及数据变更且用户未明确备份状态
联动格式
当触发 error-control 时,输出格式:
【系统辨识】
意图标签:{tag}
复杂度:{complexity}
⚠️ 检测到危险操作关键词:{命中关键词}
【边界声明 - 来自 error-control】
我计划执行:{具体操作}
影响范围:{单个/多个/全部}资源
危险操作类型:{删除/重启/权限变更/网络变更/数据变更}
备份状态:{已备份至路径 / 未备份}
回滚方式:{如何恢复原状}
请确认是否继续:
1. 确认执行
2. 取消操作
3. 修改范围
联动示例
示例:用户要求删除文件
用户:删除 /data/old-backups 目录
【系统辨识】
意图标签:backup(涉及备份数据)
复杂度:critical(命中"删除"关键词)
⚠️ 检测到危险操作关键词:删除
【边界声明】
我计划执行:删除 /data/old-backups 目录
影响范围:单个目录(/data/old-backups)
危险操作类型:删除(不可逆)
备份状态:未确认(该目录本身为备份数据)
回滚方式:无法回滚(删除操作不可逆)
⚠️ 警告:该操作不可逆,删除后数据无法恢复!
请确认是否继续:
1. 确认执行(风险自负)
2. 取消操作
3. 先备份再删除
使用流程
流程图
用户输入
↓
关键词扫描
↓
┌─────────────────┬─────────────────┬─────────────────┐
↓ ↓ ↓
命中危险词 命中复杂词 无匹配
↓ ↓ ↓
输出【边界声明】 任务分解 直接执行
等待用户确认 执行+验证 执行后验证
↓
用户确认后执行
快速路径(simple)
1. 扫描关键词 → 命中 query 标签,复杂度 simple
2. 无危险词 → 直接执行
3. 执行后验证(调用 error-control 验证清单)
完整路径(complex + 危险词)
1. 扫描关键词 → 命中 deploy 标签,复杂度 complex
2. 同时命中"生产环境" → 强制触发 error-control
3. 输出【边界声明】→ 等待用户确认
4. 用户确认后 → 任务分解
5. 按子任务执行 → 每步验证
验证清单
每次完成 system-identification 后,强制回答:
示例
示例1:简单请求(快速路径)
用户:查看 nginx 状态
快速扫描:
- 单步查询 → simple
- 历史出现过 → 快速路径
输出:
意图标签:query
复杂度:simple
处理:直接执行 systemctl status nginx
示例2:复杂请求(完整分析)
用户:帮我部署一个新服务,用 docker,要连数据库,还要配 nginx 反向代理
快速扫描:
- 多系统协调(docker + 数据库 + nginx)→ complex
- 需要设计决策 → 完整分析
意图分类:
- 匹配 deploy 标签(匹配度 0.9)
- 置信度 > 0.8 → 不澄清
复杂度评估:
- 涉及多个系统 → 是
- 需要设计决策 → 是
- 影响生产环境 → 未知(需边界确认)
- 判定:complex(或 critical,取决于环境)
任务分解:
【任务分解】
主任务:部署新服务(docker + 数据库 + nginx)
意图标签:deploy
复杂度:complex
子任务列表:
1. [ ] 确认环境边界(dev/test/prod)→ 验证:error-control 边界确认
2. [ ] 部署 docker 容器 → 验证:docker ps 显示运行
3. [ ] 配置数据库连接 → 验证:连接测试通过
4. [ ] 配置 nginx 反向代理 → 验证:curl 返回 200
5. [ ] 整体集成测试 → 验证:端到端流程通过
依赖关系:线性(2→3→4→5,1前置)
回滚点:步骤2、3、4可独立回滚
示例3:意图不清(调用 error-control)
用户:处理一下那个问题
快速扫描:
- 模糊指令 → 无法直接分类
意图分类:
- 匹配度最高:debug(0.4)、config(0.3)、query(0.2)
- 置信度 < 0.8 → 调用 error-control 澄清
输出:
【边界声明 + 澄清请求】
我计划执行:处理您提到的问题
但意图不够明确,请确认:
1. 是排查错误?(debug)
2. 是修改配置?(config)
3. 是查询信息?(query)
4. 其他:_____
请补充具体信息,我将重新分类。
记忆锚点
- 用户输入包含"删除""清空""rm" → 必须输出【边界声明】
- 用户提到"生产环境""线上" → 必须输出【边界声明】
- 用户说"帮我""做一下""处理一下" → 意图标签 unknown,必须走澄清流程
- 意图标签 unknown + 复杂度 simple → 输出【澄清请求】,等待用户补充信息
- 意图标签 unknown + 复杂度 medium/complex → 输出【澄清请求】+ 提示可能的风险
- 涉及多系统协调 → 复杂度 complex,需要任务分解
unknown 标签处理规则
触发条件
- 用户输入未命中任何意图标签关键词
- 用户输入过于模糊("帮我""处理一下""看一下"等)
- 用户输入只有代词("那个""这个""它"等)
处理流程
意图标签 = unknown
↓
复杂度 = simple/medium?
↓
输出【澄清请求】→ 等待用户补充
↓
用户补充后 → 重新进行关键词扫描
↓
命中标签 → 正常执行
未命中 → 继续澄清(最多3轮)
澄清请求格式
【系统辨识】
意图标签:unknown(无法识别)
【澄清请求】
您的指令不够明确,请补充以下信息:
1. 是查询信息?(查看状态、读取日志等)
2. 是修改配置?(调整设置、变更参数等)
3. 是部署服务?(安装、上线、发布等)
4. 是排查问题?(修复错误、调试故障等)
5. 其他:请具体说明
请补充具体信息,我将重新分类。
澄清限制
- 最多澄清 3 轮
- 3轮后仍无法识别 → 建议用户联系人工支持
- 澄清过程中,如涉及危险操作,仍需触发 error-control
与 error-control 的协同关系
system-identification(关键词扫描)→ error-control(边界确认)→ 执行 → error-control(验证)
↑___________________________________________________________↓
(闭环反馈)
- system-identification:负责"关键词扫描",判定意图和复杂度
- error-control:负责"边界确认"和"执行验证"
- 联动规则:命中危险词时,system-identification 强制调用 error-control 输出【边界声明】