alibabacloud-ecs-windows-online-troubleshooting

Name: alibabacloud-ecs-windows-online-troubleshooting
Author: aliyun

161stars12forks

How to install alibabacloud-ecs-windows-online-troubleshooting?

aliyun/alibabacloud-ecs-troubleshoot-skills/alibabacloud-ecs-windows-online-troubleshooting

$npx -y skills add aliyun/alibabacloud-ecs-troubleshoot-skills --skill alibabacloud-ecs-windows-online-troubleshooting

Installs into the current project.

Summary

--- name: alibabacloud-ecs-windows-online-troubleshooting description: Use this skill whenever the user reports a problem with a Windows system, Windows Server, or Windows ECS instance, or asks to check, diagnose, inspect, or troubleshoot anything Windows-related. Covers networ

Files · 1

View on GitHub

SKILL.md

1	# Windows ECS 在线诊断 Skill
2
3	## 何时使用本技能
4
5	当用户报告 Windows 实例的故障现象，或要求对 Windows 实例进行问题排查、状态检查时，加载本技能。覆盖范围包括：
6
7	- 网络问题：ping、DNS、DHCP、防火墙、SMB
8	- RDP/远程桌面：连接失败、认证、黑屏、卡顿
9	- 存储/磁盘、系统激活、Windows Update、性能问题
10	- 用户账户/权限、驱动、应用崩溃、安全/证书/TLS、计划任务
11	- 模糊描述如“检查一下系统”或“系统有问题”
12
13	诊断能力清单和问题路由表存放在 `references/REFERENCE.md` 中，在路径规划阶段加载。
14
15	---
16
17	## 诊断执行流程
18
19	### 用户呈现通用规则
20
21	执行过程中向用户呈现进度、排查路径、当前步骤等信息时，禁止暴露 Skill 内部标记，必须用自然语言描述该步骤所对应的诊断功能。需隐藏的内部标记包括但不限于：
22
23	- 内部文件名 / 路径：如 `references/REFERENCE.md`、`references/rdp-service.md`、`references/networking-tcpip.md` 等
24	- 内部术语：如「路由表」「reference」「推测性排查」「动态规划」「step 集合」「事件日志预诊断」等 Skill 设计概念
25	- 内部编号 / 标签：如 `Step 1`、`Step 2` 等机械编号，以及 `Direct/Contributing/Unrelated`、`Critical/Warning/Info`、`MUST` 等词汇的原始字样
26	- 工具调用详情：如「调用 ReadReference / 加载 xxx 文件」之类的实现描述
27
28	示例：
29	- 不要说：「现在执行 rdp-service.md 的步骤」「本问题为 Direct + Critical」
30	- 改为说：「现在检查 TermService 服务状态与 RDP 监听端口配置」「此问题是直接根因且严重影响连接」
31
32	内部标记仅用于工具调用、日志与模型内部推理，不进入对话面向用户的文本。
33
34	### 问题理解
35
36	1. 提取用户问题中的核心现象（错误代码、提示信息、用户操作）
37	2. 确认关键上下文：系统能否启动？当前执行环境（控制台/RDP/云助手）？
38	3. 信息不足时 MUST 先向用户追问（具体现象、错误提示、操作时机等），收集到足够信息后再进入路径规划阶段
39	4. 记录原始问题描述，后续所有分析 MUST 围绕此问题
40
41	### 路径规划
42
43	1. 加载诊断能力与路由表：读取 `references/REFERENCE.md`，获取诊断能力清单和问题路由表
44	2. 事件日志预诊断（可选）：
45	- 采集用户报告时间段内的关键事件日志（System、Application、Security）
46	- 筛选 Error/Critical 级别事件，提取 Event ID 和来源
47	- 根据事件日志特征初步界定问题方向（如网络类、驱动类、服务类、安全类）
48	- 注意：仅采集和预分析，不执行具体诊断步骤
49	3. 路由表匹配（可使用专有知识库和世界知识辅助判断）：
50	- 精确匹配 → 使用既定序列
51	- 模糊匹配 → 使用最接近序列，但标注为「推测性排查」
52	4. 动态规划（未命中路由表时）：
53	- 结合用户问题描述 + 事件日志预诊断结果，从诊断能力清单中选择相关 reference
54	- 组合排查序列，并向用户说明：「此为动态规划的排查路径，非预设场景」
55	5. 输出：有序的 reference 列表（通常 2-5 个，避免过多）+ 规划理由
56	- 向用户展示排查路径时，禁止使用 "Step 1、Step 2" 等无意义编号，必须描述每一步要检查的具体内容（如「检查 TermService 服务状态及监听端口配置」）
57
58	### 逐步执行
59
60	按排查序列逐个加载 reference 执行诊断。
61
62	单个 reference 执行规则：
63	1. 读取 reference 文件（`references/{file}.md`）
64	2. 根据用户问题从步骤集合中选取相关子集
65	3. 严格逐步骤执行：每个步骤必须完成「数据采集 → 分析判定 → 正常/异常结论」全流程后，才能进入下一步。禁止一次性批量采集多个步骤的数据再集中分析
66	- 每个异常判定 MUST 有对应采集数据作为证据
67	- 每个步骤 MUST 给出明确的正常/异常二分结论
68	- 发现的异常 MUST 关联到具体根因
69	- 采集脚本可根据实际情况调整，但应参考 reference 文件中提供的脚本作为起点
70	4. 遇到交叉引用 → 优先处理跳转目标，完成后回到主序列
71	5. 重复引用优化：同一个 reference 被多次引用时只需执行一次，后续直接复用已有结果
72
73	序列控制逻辑：
74	- 提前终止：发现的根因已能完全解释用户所有症状 → 终止后续 reference
75	- 继续执行：仅解释部分症状 → 继续执行后续 reference
76	- 方向修正：执行中发现问题方向与初始规划不符 → 回退到路径规划阶段，基于新线索重新规划
77
78	### 因果链分析
79
80	1. 汇总所有 reference 的发现
81	2. 构建因果关系链（区分直接原因和间接原因）
82	3. 按与用户问题的相关性排列优先级：relation（Direct > Contributing > Unrelated）× severity（Critical > Warning > Info）双维度排序；Unrelated 问题单独列为"其他发现"，不混入主要修复方案
83	4. 无发现时：尝试扩展排查范围；仍无发现 → 如实告知用户，给出建议的排查方向
84
85	### 修复方案
86
87	1. 每个根因提供可执行的修复脚本，MUST 附带验证方法和预期结果
88	2. 按优先级顺序呈现
89	3. 展示完整修复内容给用户，等待明确确认 — 禁止自动执行任何修复命令
90	4. 同题聚合：同一根因的多个修改合并为一个脚本
91	5. 异题分离：不同根因的修复严格分开，逐个确认
92	6. 涉及系统修改的操作 MUST 标注风险
93
94	---
95
96	## 因果链输出规范
97
98	### 因果链示例
99
100	```
101	[用户问题] 远程桌面连不上
102	│
103	├── [Direct] TermService 服务已停止
104	│ └── [Contributing] 依赖服务 RpcSs 异常
105	│
106	└── [Direct] 防火墙阻止 3389 端口
107	└── [Contributing] 公共网络配置文件生效
108	```
109
110	### 修复脚本模板
111
112	```powershell
113	#requires -RunAsAdministrator
114	# 修复：{根因名称}
115	# 风险：{风险说明}
116	# 验证：执行后运行 {验证命令} 确认修复结果
117
118	# --- 修复操作 ---
119	{修复命令}
120
121	# --- 验证 ---
122	{验证命令}
123	```
124
125	### 诊断结论输出模板
126
127	> 诊断结论
128	>
129	> 用户问题：{原始问题描述}
130	>
131	> 共发现 {N} 个问题，按修复优先级排列：
132	>
133	> ---
134	>
135	> 🔴 问题 1（Direct \| Critical）：{root_cause}
136	>
137	> 证据：{采集到的异常数据}
138	>
139	> 分析：{为什么这个问题直接导致了用户看到的现象}
140	>
141	> 因果链：{用户问题} ← {直接原因} ← {间接原因（如有）}
142	>
143	> 修复方案：
144	> ```powershell
145	> {修复脚本}
146	> ```
147	>
148	> 验证：
149	> ```powershell
150	> {验证命令}
151	> ```
152	> 预期结果：{正常状态}
153	>
154	> ---
155	>
156	> 🟡 问题 2（Contributing \| Warning）：{root_cause}
157	> ...
158
159	---
160
161	## Gotchas（易错点）
162
163	### 诊断阶段
164
165	- `Get-WmiObject` 在部分系统上被弃用，优先使用 `Get-CimInstance`
166	- 网络连通性检查需区分 ICMP 被阻止和真正的网络不可达
167	- 命令输出格式简化原则：使用命令采集信息时，输出格式 MUST 尽量简单，减少大模型理解成本。优先使用 `Select-Object` 仅输出关键字段，避免冗长的完整对象输出。示例：
168	- 推荐：`Get-Service TermService \| Select-Object Name, Status, StartType`
169	- 不推荐：`Get-Service TermService`（输出包含大量无关字段）
170	- 推荐：`Get-Process \| Sort-Object CPU -Descending \| Select-Object -First 5 Id, Name, CPU`
171	- 不推荐：`Get-Process \| Sort-Object CPU -Descending \| Select-Object -First 5`（输出 20+ 字段）
172	- PowerShell 格式化输出延迟：`Select-Object` 返回的对象进入延迟格式化队列，后续 `Write-Host` 输出可能先于表格到达控制台，导致输出顺序错乱。采集脚本编写时必须在 `Select-Object` 后追加 `\| Format-Ta

People who liked this also viewed

6 picks

Type

alibabacloud-ecs-windows-online-troubleshooting

161stars12forks

View on GitHub

How to install alibabacloud-ecs-windows-online-troubleshooting?

aliyun/alibabacloud-ecs-troubleshoot-skills/alibabacloud-ecs-windows-online-troubleshooting

$npx -y skills add aliyun/alibabacloud-ecs-troubleshoot-skills --skill alibabacloud-ecs-windows-online-troubleshooting

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Windows ECS 在线诊断 Skill
2
3	## 何时使用本技能
4
5	当用户报告 Windows 实例的故障现象，或要求对 Windows 实例进行问题排查、状态检查时，加载本技能。覆盖范围包括：
6
7	- 网络问题：ping、DNS、DHCP、防火墙、SMB
8	- RDP/远程桌面：连接失败、认证、黑屏、卡顿
9	- 存储/磁盘、系统激活、Windows Update、性能问题
10	- 用户账户/权限、驱动、应用崩溃、安全/证书/TLS、计划任务
11	- 模糊描述如“检查一下系统”或“系统有问题”
12
13	诊断能力清单和问题路由表存放在 `references/REFERENCE.md` 中，在路径规划阶段加载。
14
15	---
16
17	## 诊断执行流程
18
19	### 用户呈现通用规则
20
21	执行过程中向用户呈现进度、排查路径、当前步骤等信息时，禁止暴露 Skill 内部标记，必须用自然语言描述该步骤所对应的诊断功能。需隐藏的内部标记包括但不限于：
22
23	- 内部文件名 / 路径：如 `references/REFERENCE.md`、`references/rdp-service.md`、`references/networking-tcpip.md` 等
24	- 内部术语：如「路由表」「reference」「推测性排查」「动态规划」「step 集合」「事件日志预诊断」等 Skill 设计概念
25	- 内部编号 / 标签：如 `Step 1`、`Step 2` 等机械编号，以及 `Direct/Contributing/Unrelated`、`Critical/Warning/Info`、`MUST` 等词汇的原始字样
26	- 工具调用详情：如「调用 ReadReference / 加载 xxx 文件」之类的实现描述
27
28	示例：
29	- 不要说：「现在执行 rdp-service.md 的步骤」「本问题为 Direct + Critical」
30	- 改为说：「现在检查 TermService 服务状态与 RDP 监听端口配置」「此问题是直接根因且严重影响连接」
31
32	内部标记仅用于工具调用、日志与模型内部推理，不进入对话面向用户的文本。
33
34	### 问题理解
35
36	1. 提取用户问题中的核心现象（错误代码、提示信息、用户操作）
37	2. 确认关键上下文：系统能否启动？当前执行环境（控制台/RDP/云助手）？
38	3. 信息不足时 MUST 先向用户追问（具体现象、错误提示、操作时机等），收集到足够信息后再进入路径规划阶段
39	4. 记录原始问题描述，后续所有分析 MUST 围绕此问题
40
41	### 路径规划
42
43	1. 加载诊断能力与路由表：读取 `references/REFERENCE.md`，获取诊断能力清单和问题路由表
44	2. 事件日志预诊断（可选）：
45	- 采集用户报告时间段内的关键事件日志（System、Application、Security）
46	- 筛选 Error/Critical 级别事件，提取 Event ID 和来源
47	- 根据事件日志特征初步界定问题方向（如网络类、驱动类、服务类、安全类）
48	- 注意：仅采集和预分析，不执行具体诊断步骤
49	3. 路由表匹配（可使用专有知识库和世界知识辅助判断）：
50	- 精确匹配 → 使用既定序列
51	- 模糊匹配 → 使用最接近序列，但标注为「推测性排查」
52	4. 动态规划（未命中路由表时）：
53	- 结合用户问题描述 + 事件日志预诊断结果，从诊断能力清单中选择相关 reference
54	- 组合排查序列，并向用户说明：「此为动态规划的排查路径，非预设场景」
55	5. 输出：有序的 reference 列表（通常 2-5 个，避免过多）+ 规划理由
56	- 向用户展示排查路径时，禁止使用 "Step 1、Step 2" 等无意义编号，必须描述每一步要检查的具体内容（如「检查 TermService 服务状态及监听端口配置」）
57
58	### 逐步执行
59
60	按排查序列逐个加载 reference 执行诊断。
61
62	单个 reference 执行规则：
63	1. 读取 reference 文件（`references/{file}.md`）
64	2. 根据用户问题从步骤集合中选取相关子集
65	3. 严格逐步骤执行：每个步骤必须完成「数据采集 → 分析判定 → 正常/异常结论」全流程后，才能进入下一步。禁止一次性批量采集多个步骤的数据再集中分析
66	- 每个异常判定 MUST 有对应采集数据作为证据
67	- 每个步骤 MUST 给出明确的正常/异常二分结论
68	- 发现的异常 MUST 关联到具体根因
69	- 采集脚本可根据实际情况调整，但应参考 reference 文件中提供的脚本作为起点
70	4. 遇到交叉引用 → 优先处理跳转目标，完成后回到主序列
71	5. 重复引用优化：同一个 reference 被多次引用时只需执行一次，后续直接复用已有结果
72
73	序列控制逻辑：
74	- 提前终止：发现的根因已能完全解释用户所有症状 → 终止后续 reference
75	- 继续执行：仅解释部分症状 → 继续执行后续 reference
76	- 方向修正：执行中发现问题方向与初始规划不符 → 回退到路径规划阶段，基于新线索重新规划
77
78	### 因果链分析
79
80	1. 汇总所有 reference 的发现
81	2. 构建因果关系链（区分直接原因和间接原因）
82	3. 按与用户问题的相关性排列优先级：relation（Direct > Contributing > Unrelated）× severity（Critical > Warning > Info）双维度排序；Unrelated 问题单独列为"其他发现"，不混入主要修复方案
83	4. 无发现时：尝试扩展排查范围；仍无发现 → 如实告知用户，给出建议的排查方向
84
85	### 修复方案
86
87	1. 每个根因提供可执行的修复脚本，MUST 附带验证方法和预期结果
88	2. 按优先级顺序呈现
89	3. 展示完整修复内容给用户，等待明确确认 — 禁止自动执行任何修复命令
90	4. 同题聚合：同一根因的多个修改合并为一个脚本
91	5. 异题分离：不同根因的修复严格分开，逐个确认
92	6. 涉及系统修改的操作 MUST 标注风险
93
94	---
95
96	## 因果链输出规范
97
98	### 因果链示例
99
100	```
101	[用户问题] 远程桌面连不上
102	│
103	├── [Direct] TermService 服务已停止
104	│ └── [Contributing] 依赖服务 RpcSs 异常
105	│
106	└── [Direct] 防火墙阻止 3389 端口
107	└── [Contributing] 公共网络配置文件生效
108	```
109
110	### 修复脚本模板
111
112	```powershell
113	#requires -RunAsAdministrator
114	# 修复：{根因名称}
115	# 风险：{风险说明}
116	# 验证：执行后运行 {验证命令} 确认修复结果
117
118	# --- 修复操作 ---
119	{修复命令}
120
121	# --- 验证 ---
122	{验证命令}
123	```
124
125	### 诊断结论输出模板
126
127	> 诊断结论
128	>
129	> 用户问题：{原始问题描述}
130	>
131	> 共发现 {N} 个问题，按修复优先级排列：
132	>
133	> ---
134	>
135	> 🔴 问题 1（Direct \| Critical）：{root_cause}
136	>
137	> 证据：{采集到的异常数据}
138	>
139	> 分析：{为什么这个问题直接导致了用户看到的现象}
140	>
141	> 因果链：{用户问题} ← {直接原因} ← {间接原因（如有）}
142	>
143	> 修复方案：
144	> ```powershell
145	> {修复脚本}
146	> ```
147	>
148	> 验证：
149	> ```powershell
150	> {验证命令}
151	> ```
152	> 预期结果：{正常状态}
153	>
154	> ---
155	>
156	> 🟡 问题 2（Contributing \| Warning）：{root_cause}
157	> ...
158
159	---
160
161	## Gotchas（易错点）
162
163	### 诊断阶段
164
165	- `Get-WmiObject` 在部分系统上被弃用，优先使用 `Get-CimInstance`
166	- 网络连通性检查需区分 ICMP 被阻止和真正的网络不可达
167	- 命令输出格式简化原则：使用命令采集信息时，输出格式 MUST 尽量简单，减少大模型理解成本。优先使用 `Select-Object` 仅输出关键字段，避免冗长的完整对象输出。示例：
168	- 推荐：`Get-Service TermService \| Select-Object Name, Status, StartType`
169	- 不推荐：`Get-Service TermService`（输出包含大量无关字段）
170	- 推荐：`Get-Process \| Sort-Object CPU -Descending \| Select-Object -First 5 Id, Name, CPU`
171	- 不推荐：`Get-Process \| Sort-Object CPU -Descending \| Select-Object -First 5`（输出 20+ 字段）
172	- PowerShell 格式化输出延迟：`Select-Object` 返回的对象进入延迟格式化队列，后续 `Write-Host` 输出可能先于表格到达控制台，导致输出顺序错乱。采集脚本编写时必须在 `Select-Object` 后追加 `\| Format-Ta

People who liked this also viewed

6 picks

Type