常见误区

使用 Skill 时的一些常见误区和改进建议。

误区 1：用错 Skill

问题: 用 review 做安全审查，用 simplify 做架构重构。

# 错误
/review 检查登录接口有没有 SQL 注入

# 正确
/security-review 检查登录接口的安全性

Skill 各有专攻，选对工具事半功倍。参考 场景选择指南。

误区 2：同时使用互斥的 Skill

问题: 同时激活 caveman（精简）和 grill-me（深度追问）。

这两个 Skill 的沟通模式完全相反 — 一个要极简，一个要穷尽追问。结果两者都做不好。

建议: 一次只用一个 Skill，完成后再切换。

误区 3：对探索性工作使用 TDD

问题: 还不确定要做什么就开始写测试。

# 还没想清楚需求
/tdd 做一个推荐系统

TDD 适合明确的需求。不确定方案时先用 prototype 探索。

误区 4：跳过诊断直接修复

问题: 看到 Bug 症状就改代码，不改根因。

# 看到错误就直接 try-catch
/tdd 修复支付回调偶发失败，加点重试逻辑

先用 /diagnose 找到根因。盲目修复可能掩盖真正的问题。

误区 5：过度使用 Skill

问题: 简单的代码注释也要 /review，改一行配置也要 /tdd。

Skill 有启动成本（加载上下文）。简单任务直接做更快。

误区 6：忽略 Skill 的「不适���场景」

每个 Skill 文档都明确列出了不适用场景。比如：

• simplify 不做架构重构
• review 不做安全专项审查
• prototype 的代码不用于生产

忽略这些边界会导致输出质量下降。

误区 7：原型代码直接用于生产

# 错误流程
/prototype 做用户系统 → 原型能用 → 直接部署

prototype 强调可丢弃。原型验证完设计后，用 tdd 重新正式实现。

误区 8：长会话不管理上下文

连续使用多个复杂 Skill 会快速消耗上下文窗口。

建议:

• 用 caveman 模式减少 token
• 用 handoff 在任务完成一个阶段后交接
• 用 loop 把定期检查放到后台

误区 9：不审查 Skill 输出

Skill 的输出是 AI 生成的，可能有错误。尤其是：

• 安全审查的误报/漏报
• 代码生成忽略项目约定
• PRD 遗漏业务上下文

永远 Review Skill 的输出，不要盲目接受。

总结

误区	正确做法
用错 Skill	参考场景选择指南
Skill 互斥	一次一个
探索用 TDD	先用 prototype
跳过诊断	先 diagnose
过度使用	简单任务直接做
忽略边界	读「不适用场景」
原型投产	原型后 tdd 重新实现
不管理上下文	caveman / handoff
不审查输出	永远 Review