القائمة
系统辨识 Skill — 基于工程控制论第一章思想，实现用户意图分类、复杂度评估、任务分解。预设标签+动态生成，混合触发。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | system-identification |
| description | 系统辨识 Skill — 基于工程控制论第一章思想，实现用户意图分类、复杂度评估、任务分解。预设标签+动态生成，混合触发。 |
| category | software-development |
| version | 1.0.0 |
| requires | ["error-control"] |
基于钱学森《工程控制论》第一章「引言」思想，将系统辨识概念转化为 AI 意图识别实践。
用户输入 → 快速扫描 → 判断简单/复杂
↓
简单请求 → 快速路径（直接匹配标签，不分解）
↓
复杂请求 → 完整分析（意图分类 + 复杂度评估 + 任务分解）
| 简单请求特征 | 复杂请求特征 |
|---|---|
| 单步可完成 | 多步有依赖 |
| 无系统变更 | 涉及配置/部署/重启 |
| 纯信息查询 | 需要设计决策 |
| 历史出现过 | 全新场景 |
| 1-2个工具调用 | 3+工具调用 |
判定规则：满足任一复杂特征 → 走完整分析路径
deploy|部署服务到服务器|0
query|查询信息或状态|0
debug|排查问题或错误|0
config|修改配置或设置|0
develop|开发或编写代码|0
optimize|优化性能或资源|0
backup|备份或恢复数据|0
security|安全相关操作|0
~/.hermes/skills/system-identification/intent-tags/tags.conf<tag_name>|<description>|<example_count>用户输入 → 匹配现有标签 → 匹配度 > 0.6？
↓
是 → 返回现有标签
↓
否 → 分析历史会话 → 归纳新标签 → 存储到 tags.conf → 返回新标签
动态生成条件：
| 标签 | 判定标准 | 任务分解 | 验证要求 |
|---|---|---|---|
| simple | 单步完成，无依赖，1-2个工具调用 | 不分解，直接执行 | 执行后验证 |
| medium | 多步有依赖，3-5个工具调用，单一系统 | 分解为2-3个子任务 | 每步验证 |
| complex | 跨系统协作，6+工具调用，需设计决策 | 分解为4+子任务，每步验证 | 每步验证 + 整体回归 |
| critical | 影响生产环境，数据变更，不可逆操作 | 强制边界确认，人工审批每步 | 每步审批 + 双重验证 |
计分：0-1项 → simple | 2-3项 → medium | 4-5项 → complex | 6项 → critical
| 复杂度 | 分解粒度 | 子任务依赖 |
|---|---|---|
| simple | 不分解 | 无 |
| medium | 2-3个子任务 | 线性依赖 |
| complex | 4+子任务 | 可能有分支依赖 |
| critical | 4+子任务 | 每步需审批 |
【任务分解】
主任务：{原始请求}
意图标签：{tag}
复杂度：{simple/medium/complex/critical}
子任务列表：
1. [ ] {子任务1} → 验证标准：{标准}
2. [ ] {子任务2} → 验证标准：{标准}
3. [ ] {子任务3} → 验证标准：{标准}
依赖关系：{线性/并行/分支}
回滚点：{可回滚步骤}
# 当意图置信度 < 0.8 时，调用 error-control 澄清机制
clarify_intent() {
local user_input="$1"
local suggested_tags="$2"
# 输出：用户选择的意图或补充信息
# 调用方式：通过 error-control 的边界确认或澄清机制
}
1. 扫描用户输入 → 识别为简单请求
2. 匹配意图标签 → 返回标签 + simple
3. 不分解，直接执行
4. 执行后验证（调用 error-control）
1. 扫描用户输入 → 识别为复杂请求
2. 意图分类 → 匹配/生成标签
3. 置信度 < 0.8？→ 调用 error-control 澄清
4. 复杂度评估 → simple/medium/complex/critical
5. 任务分解 → 子任务列表
6. 输出【任务分解】报告
7. 按 error-control 边界确认 → 执行
每次完成 system-identification 后，强制回答：
用户：查看 nginx 状态
快速扫描：
- 单步查询 → simple
- 历史出现过 → 快速路径
输出：
意图标签：query
复杂度：simple
处理：直接执行 systemctl status nginx
用户：帮我部署一个新服务，用 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可独立回滚
用户：处理一下那个问题
快速扫描：
- 模糊指令 → 无法直接分类
意图分类：
- 匹配度最高：debug（0.4）、config（0.3）、query（0.2）
- 置信度 < 0.8 → 调用 error-control 澄清
输出：
【边界声明 + 澄清请求】
我计划执行：处理您提到的问题
但意图不够明确，请确认：
1. 是排查错误？（debug）
2. 是修改配置？（config）
3. 是查询信息？（query）
4. 其他：_____
请补充具体信息，我将重新分类。
system-identification（识别）→ error-control（确认）→ 执行 → error-control（验证）
↑___________________________________________________________↓
（闭环反馈）