4.1 失效模式与调试——软失效 vs 硬失效
小林的 Skill + MCP 方案上线了，但出了问题。他需要知道怎么排查——Skill 出问题和 MCP 出问题，排查方法完全不同。
两种失效模式
Skill 软失效
AI 忽略了 Skill 中的部分指令，但不会报错，也不会告诉你它跳过了什么。
Skill 说"检查 OWASP Top 10"，AI 只检查了其中 6 项，跳过了 4 项——没有任何提示。
MCP 硬失效
工具调用失败，返回明确的错误信息，你知道哪里出了问题。
调用 get_pr_diff 返回 "Error: PR #999 not found"——问题明确，可以处理。
排查方法对比
排查 Skill 问题
Skill 失效是"无声"的，需要主动探测：
1
对比期望 vs 实际
明确定义"AI 应该做到什么"，对比实际输出
2
检查 Skill 是否激活
确认 Skill 被正确加载（检查文件路径、触发条件）
3
缩短 Skill
太长的 Skill 更容易被 AI 忽略
4
加强关键指令
用强调语气："**必须**"、"**不允许跳过**"
5
添加自检提示
在 Skill 末尾加"完成前请确认以上所有项都已检查"
6
A/B 测试
修改前后对比，量化改进效果
Skill 调试案例
问题：AI 跳过了 CSRF 检查排查过程：
1. 确认 Skill 激活 → ✅ 已加载
2. 检查 Skill 长度 → ⚠️ 2000 token，可能过长
3. 缩短到 800 token，突出重点 → 改善不大
4. 在 CSRF 项前加 "**必须检查**" → 有效，AI 不再跳过
经验：
- 强调措辞比增加内容更有效
- 每次只改一个变量，否则不知道什么起了作用
排查 MCP 问题
MCP 失效是"有声"的，排查更直接：
1
查看错误信息
错误信息通常直接指出问题
2
用 Inspector 验证
npx @modelcontextprotocol/inspector 可视化调试3
检查 Server 日志
Server 的 stderr 输出有详细日志
4
验证参数
检查传入参数是否符合 inputSchema
5
检查网络/权限
远程 Server 检查 OAuth、网络连通性
协同失效：两种问题同时出现
当 Skill + MCP 协同工作时，可能同时出现两种失效：
场景 1：Skill 依赖的工具不可用
Skill 说"调用 query_vulnerability_history"，但 Database Server 挂了。
→ MCP 硬失效（明确报错），Skill 应该有降级策略（"如果工具不可用，跳过此步并标注"）
场景 2：工具返回了数据但 AI 不会用
MCP 返回了历史漏洞数据，但 AI 没有按 Skill 要求"重点检查相似文件"。
→ Skill 软失效（AI 忽略了指令），需要加强 Skill 中的相关指令
场景 3：Skill 和 MCP 给出矛盾信息
Skill 说"先安全后性能"，MCP 的工具返回了性能数据，AI 先分析了性能。
→ Skill 软失效，需要在 Skill 中明确优先级并加强措辞
调试检查清单
遇到问题时，按这个顺序排查：
0/5 已完成
✓问题出在 Skill 还是 MCP？（有没有明确报错？）
✓如果是 Skill：AI 是否遵循了指令？是否跳过了某些步骤？
✓如果是 MCP：错误信息是什么？工具参数是否正确？
✓如果是协同：Skill 是否有降级策略？MCP 返回的数据 AI 是否正确使用？
✓修复后是否需要 A/B 测试验证效果？
本节核心要点
- Skill 失效是"软"的——无声无息，需要主动探测
- MCP 失效是"硬"的——明确报错，排查方向清晰
- 协同失效：Skill 依赖的工具挂了（硬失效+需要降级策略），AI 不会用工具返回的数据（软失效+加强指令）
- 调试 Skill 用"对比+缩短+强调"，调试 MCP 用"Inspector+日志+参数验证"