用途
Explainer 技能用于创建清晰、有洞察力的解释，覆盖代码、技术概念和技术决策三类对象。其核心原则是：清晰优先于完整——只有被理解的解释才有用。
解释流程
- 理解问题：区分字面问题（"这是做什么的？"）与深层问题（"为什么存在？""怎么工作的？"），并考虑提问者背景（初级与高级开发者需要不同深度的解释）。
- 收集完整上下文：在解释前阅读相关代码、周边代码（函数、类、模块）、关联代码（调用方与被调用方）、测试（揭示预期行为）、注释（原始推理）、Git 历史（演变过程）。反模式是解释自己只部分理解的代码。
- 组织结构：从宽到窄——一句话总结、目的（解决什么问题）、高层方法、实现细节、边界情况、相关概念。
- 选择合适深度：针对"做什么"、"怎么工作"、"为什么用这个方案"分别给出不同层次的回答，避免用实现术语回答意图问题。
解释格式模板
- 代码解释格式：包含 What it does（一句话总结）、Purpose（存在原因）、How it works（高层步骤）、Key details（关键实现细节）、Example（具体示例）、Related（相关链接）。
- 概念解释格式：包含概念定义、Why it matters（实际重要性）、How it works（去术语化解释）、Example（具体例子）、In our codebase（代码库中的使用位置）、Common pitfalls（常见陷阱）。
- 决策解释格式：包含 Decision（决定了什么）、Context（背景）、Options considered（备选项及优缺点）、Choice（选择及理由）、Trade-offs accepted（接受的取舍）、References（参考链接）。
写作准则
- 具体化：不用"使用了常见设计模式"，而说明具体是哪种模式及其机制。
- 谨慎使用类比：如餐厅厨房类比（订单=action、厨师=reducer、取餐区=store），但若不用类比更清楚则跳过。
- 展示而非仅陈述：用带注释的代码示例说明过滤与映射逻辑。
- 避免术语：除非正在解释术语本身。
常见场景
技能覆盖四类场景的处理方式：解释错误信息（发生了什么、位置、原因、修复代码及原理）、解释"为什么不用 X"（背景、选择 Y 的理由、取舍、X 更合适的条件）、解释遗留代码（当前功能、历史、为何显得奇怪、修改时的约束、相关现代替代）。
反模式
- 假设读者已知：应解释 HOC、connect() 等术语或给出文档链接。
- 过度解释显而易见代码：只解释有非直观逻辑的行（如折扣在税前应用）。
- 模糊引用：应给出具体文件与行号，而非"和其他地方类似"。
- 问"为什么"却答"怎么做"：应回答选择该数据结构的原因（如 Set 自动去重），而非其 API 用法。
验证清单
解释后检查：是否回答了实际被问的问题、是否无需读三遍即可理解、术语是否已解释或链接、是否有具体示例、是否避免了不必要的复杂、代码库新人能否理解。
与其他技能的集成
解释代码质量问题时使用 code-reviewer 技能；解释行为时使用 proof-of-work 技能（展示实际输出）；解释为何更简单更好时使用 simplicity-principles 技能；解释其他技能覆盖的模式时引用相应技能。
限制
资料未提供该技能的具体安装方式、运行环境、平台支持、收费模式或版本信息。