不要从工具出发找场景，要从场景出发选工具。
场景一：刚写完一段代码，想快速检查有没有明显问题
你花了半小时写完一个 Word 文档解析模块，准备提交。不确定有没有冗余逻辑或低级错误。
用 /simplify
/simplify它自动扫描你最近改动的代码，检查复用性、质量和效率，发现问题直接修复。不需要指定文件，不需要描述上下文，一个命令搞定。
- 模型：sonnet（快，成本低）
- 耗时：几十秒
- 适合：日常自查，改完就跑一遍的习惯
场景二：要提 PR 了，想在同事 review 前自己先过一遍
代码基本写完了，准备提 PR。你想在同事看之前，先用 AI 做一轮严格的审查，避免低级问题浪费 reviewer 的时间。
用 code-reviewer
用 code-reviewer 审查 src/word_parser.py它跑在 opus 模型上，输出结构化报告：
- critical — 会导致 bug 或数据丢失的问题
- major — 逻辑缺陷、边界条件遗漏、SOLID 原则违反
- minor — 命名不规范、风格不一致
实际案例：在 RAG 项目中，它指出通过 rels 遍历提取 Word 图片会遗漏 VML 嵌入的图片，建议改用 zipfile 直接读取 word/media/。这类问题人工 review 很容易漏。
- 模型：opus（深度推理）
- 耗时：1-2 分钟
- 适合：提 PR 前的最后一道关
场景三：项目要上线，担心有安全漏洞
你的 RAG 系统接受用户上传 Word 文件，解析后存入向量数据库。上线前需要确认没有安全隐患。
用 security-reviewer
用 security-reviewer 检查这个项目它专注 OWASP Top 10，针对文件处理场景会重点检查：
-
上传文件有没有大小限制（zip 炸弹防护）
-
解压路径有没有穿越风险（
../../../etc/passwd） -
临时文件用完是否清理（
/tmp/ocr_temp.png残留） -
有没有硬编码的密钥或凭证
-
模型：sonnet
-
耗时：1-2 分钟
-
适合：涉及用户输入、文件上传、外部调用的项目上线前
场景四：脑子里有个模糊的想法，还没想清楚怎么做
老板说”我们需要一个知识库系统，能搜索 Word 文档里的内容”。你大概知道要做 RAG，但具体怎么处理图片、表格、分块策略、向量数据库选型，全都没想清楚。
用 /deep-interview
/deep-interview 我想设计一个 RAG 系统来处理企业 Word 文档它不会直接给你方案，而是反复追问：
- “文档里有图片吗？图片里有文字吗？”
- “表格需要保留行列结构还是拍平成文本？”
- “文档量级是千级还是万级？”
- “OCR 识别失败怎么兜底？”
- “PaddleOCR 模型占 1-2GB 内存，批量处理时怎么管理？”
每轮追问后用数学方式评估需求的模糊度，直到足够清晰才输出方案。
关键价值：它问的问题往往是你没想到的。
- 模型：sonnet
- 耗时：5-15 分钟（取决于讨论轮数）
- 适合：项目初期，需求还是一句话的阶段
场景五：方案已经有了，但不确定有没有盲点
你设计好了 RAG 系统的架构：python-docx 提取内容 → PaddleOCR 识别图片 → 按 500 字分块 → 存入 Chroma → LLM 生成回答。看起来没问题，但总觉得不踏实。
用 critic
用 critic 审查我的技术方案：python-docx + PaddleOCR 解析 Word，分块后存入 Chroma 做 RAG它从多个视角挑战你的设计：
-
“图片 OCR 结果放在文档最后，丢失了位置上下文，检索时会不会答非所问？”
-
“500 字固定分块会把表格切断，考虑过按语义边界分块吗？”
-
“Chroma 在 10 万级文档时的查询延迟你测过吗？”
-
“PaddleOCR 对手写体和低分辨率图片识别率会显著下降，有降级策略吗？”
-
模型：opus（深度推理）
-
耗时：1-3 分钟
-
适合：方案成型后、动手写代码前
场景六：技术选型拿不定主意
PaddleOCR、Tesseract、EasyOCR 三个 OCR 引擎，到底选哪个？你查了文档，各有优劣，自己倾向 PaddleOCR 但不确定是否有偏见。
用 /ccg（三模型会诊）
/ccg PaddleOCR vs Tesseract vs EasyOCR，中文企业文档场景哪个更合适流程：
- Claude 分析问题维度
- 并行请求 Codex 和 Gemini 各自独立给出评估
- Claude 综合三方观点，给出最终建议
三个模型独立思考，避免单一模型的确认偏误。
- 模型：Claude + Codex + Gemini
- 耗时：2-3 分钟
- 适合：二选一或三选一的技术选型，且各方案差异不明显
场景七：需要从系统架构层面做决策
文档量预计从 1 万增长到 10 万，现在用 Chroma 单机够用，但担心后续扛不住。要不要现在就换 Milvus？微服务拆分还是保持单体？
用 architect
用 architect 帮我评估：RAG 系统从 Chroma 迁移到 Milvus 的必要性和时机，当前 1 万文档，预计半年到 10 万特点：
- opus 模型驱动，推理深度最强
- 只读模式 — 只给建议不改代码，讨论阶段不引入变更
- 长期视角 — 考虑技术债务、团队能力、迁移成本、未来扩展
它回答的不是”能不能做”，而是”现在该不该做、什么时候做、怎么做成本最低”。
- 模型：opus
- 耗时：2-5 分钟
- 适合：架构选型、技术演进路线、系统边界划分
场景八：方案讨论完了，想直接落地实现
经过 deep-interview 和 critic 的讨论，方案已经清晰了。不想再手动拆任务，想让 AI 直接按方案执行。
用 /ralplan
/ralplan 实现 RAG 文档解析系统：python-docx 提取文本和表格，PaddleOCR 识别图片中文，按语义边界分块，存入 Chroma流程：
- 规划阶段 — 生成实现计划，你可以反复讨论修改
- 共识确认 — 满意后确认方案
- 自动执行 — 进入 ralph 循环，持续实现直到完成并通过验证
从讨论到落地无缝衔接，中间不断档。
- 模型：opus（规划）+ sonnet（执行）
- 耗时：取决于项目复杂度
- 适合：方案明确后的一键落地
场景速查表
| 你正在面对的场景 | 用什么 | 模型 |
|---|---|---|
| 写完代码，快速自查 | /simplify | sonnet |
| 提 PR 前，严格审查 | code-reviewer | opus |
| 上线前，安全扫描 | security-reviewer | sonnet |
| 想法模糊，需要理清 | /deep-interview | sonnet |
| 方案已有，找盲点 | critic | opus |
| 选型纠结，要多方意见 | /ccg | 三模型 |
| 架构决策，长期权衡 | architect | opus |
| 方案确认，直接执行 | /ralplan | opus+sonnet |
一句话原则
需求模糊先 interview，方案成型找 critic，选型纠结上 ccg，架构决策靠 architect，写完代码跑 simplify，提 PR 前过 reviewer，上线之前查 security。