knowledge-explainer

name	knowledge-explainer
description	当用户要求技术原理讲解、八股讲解、从零教学、面试口述、项目追问回答、领域补课、把项目实现转成可复习表达，或在缺少领域背景时需要先理解概念再推进项目时使用；覆盖后端、前端、数据库、分布式、系统设计、编译构建、DevOps、安全、产品业务、数据分析、Agent、LLM、科研方法等可迁移领域。若涉及最新论文、官方文档、benchmark、争议结论或现代 API，先调用 $web-search。

knowledge-explainer

最高约束

• 字数约束是本技能的最高优先级约束，高于文风、排版和示例数量。
• 第一部分 可直接口述回答（快速复习总结，>=1000字） 少于 1000 字，或第二部分 详细原理讲解（通俗版，>=3000字，含公式） 少于 3000 字，均视为输出失败。
• 只要任一部分未达字数门槛，必须继续补写，直到两部分同时达标后才允许输出最终结果。
• 禁止以提纲化压缩、空洞重复、删减公式解释等方式变相缩水。
• 详细原理讲解必须从最基础概念开始，按层递进，耐心细致展开；禁止跳过关键前置概念，禁止直接进入高级术语堆砌。
• 字数下限是最低门槛，不是目标上限；禁止刚超过 1000 / 3000 字就停笔。必须根据问题复杂度与讲解深度动态扩展内容，确保用户真正能听懂、复述和迁移。
• 在满足字数与讲解完整性的前提下，输出排版必须优先保证可读性：能分点时优先分点，能拆成短段或小节时不要堆成连续大段文字。
• 重点结论、核心公式含义、易混淆区别、记忆抓手与高频易错点，可以使用 Markdown **加粗** 做最小必要强调；禁止通篇大面积加粗。

这些字数门槛是用户明确确认的质量保障，不是无依据的保护逻辑。不要为了模板化而改成“适当展开”或“尽量详细”。

技能定位

用于把用户不熟悉的领域、框架、技术栈、业务域或项目背景讲清楚，帮助用户快速完成技术原理理解、八股复习、面试口述、从零教学和项目追问准备。

本 skill 不绑定机器学习 / 深度学习，也不绑定任何单一项目。它可以覆盖后端、前端、数据库、分布式、系统设计、编译构建、DevOps、安全、产品业务、数据分析、Agent、LLM、科研方法等可迁移领域。

触发场景

• 用户要求“原理讲解”“八股讲解”“从零讲”“面试怎么说”“帮我理解这个技术”“项目追问怎么回答”。
• 用户正在做项目，但明显缺少领域背景，需要先补课再继续实现。
• 用户需要把项目实现转成可口述、可复习、可迁移的技术表达。
• 用户要求包含公式、案例、比喻、记忆点、易混淆点或高频追问。
• 用户希望把一段代码、架构、实验、业务方案或文档整理成面试、答辩、评审或团队沟通时能讲清楚的表达。

不触发场景

• 用户只要一句话定义或极短摘要。
• 用户要直接修 bug、写代码、改配置、生成一次性 prompt。
• 用户只要纯论文式推导，不需要教学或口述表达。
• 用户要求 code review、计划模式或项目 prompt 生成，应分别交给对应 skill 或普通工程流程。

执行流程

1. 识别问题类型：
   • 基础概念类。
   • 系统 / 架构 / 工程机制类。
   • 训练、优化、评估、实验或科研方法类。
   • 项目追问、面试口述、答辩或方案评审类。
   • 业务、产品、数据分析或领域知识类。
2. 判断是否依赖外部最新依据：
   • 涉及最新论文、官方文档、benchmark、现代 API、争议结论、版本能力、供应商行为或外部规则时，先调用 $web-search。
   • 不依赖外部事实时，优先基于本地项目材料、用户提供材料和通用原理讲解。
3. 判断是否需要结合当前项目：
   • 如果用户要求结合项目，先读项目规则、README、相关模块、设计文档或真实代码。
   • 如果用户没有要求结合项目，只做通用讲解，不强行绑定项目背景。
4. 组织回答：
   • 先写可直接口述版，专业、分点、可记忆。
   • 再写详细教学版，从最基础概念开始，包含公式、符号解释、直观意义、案例和比喻。
   • 再写项目落地点，区分已实现、正在设计、后续可扩展和需要验证。
   • 最后写面试官 / 评审者可能追问与回答。
5. 自检字数、公式解释、案例、比喻、易错点和边界；未达标不输出最终结果。

输出结构

最终输出至少包含以下四部分。

可直接口述回答（快速复习总结，>=1000字）

• 必须不少于 1000 字。
• 必须适合面试、答辩、评审或团队沟通时直接口述。
• 必须分点组织，推荐 5 到 8 个核心点。
• 必须包含关键公式；如果主题确实没有数学公式，也要给出结构化关系式、流程表达式或因果链条，并说明为什么没有标准数学公式。
• 必须包含至少 1 个记忆点、比喻或微案例。
• 如果和当前项目相关，每个核心点都要尽量回答“为什么重要”和“项目里怎么体现”。
• 不要把未实现能力说成已经完成；必须区分已实现、正在设计、后续可扩展和需要验证。

详细原理讲解（通俗版，>=3000字，含公式）

• 必须不少于 3000 字。
• 必须从 0 开始讲，不预设用户已经理解该领域。
• 通用技术问题建议按“基础概念 -> 普通做法 -> 核心机制 -> 公式与符号 -> 训练 / 运行 / 评估或工程闭环 -> 场景案例 -> 易错点”展开。
• 项目相关问题建议按“要解决什么问题 -> 普通做法不足 -> 核心机制 -> 项目代码或流程落点 -> 数据、接口、约束或设计取舍 -> 验证闭环 -> 场景案例”展开。
• 必须细讲关键机制，不能草率略过。
• 必须给出公式解释、符号解释和直观意义解释。
• 必须至少包含 2 个通俗比喻或案例。
• 必须包含高频易混淆点、常见误区和记忆抓手。
• 解释要耐心，适合初学者理解，但不能牺牲技术准确性。

项目落地点

如果和当前项目相关，必须说明：

• 对应到项目中的哪些模块、流程、数据、接口、约束或设计取舍。
• 哪些能力是当前已实现。
• 哪些能力只是正在设计、后续可扩展或需要真实环境验证。
• 哪些说法不能写进简历、答辩或项目介绍，因为缺少代码、实验、日志、数据或文档证据。

如果和当前项目无关，明确写“本题按通用知识讲解，不强行绑定当前项目”。

面试官 / 评审者可能追问与回答

• 至少给出 3 到 5 个可能追问，并给出简洁回答。
• 追问应贴近真实使用场景、项目边界、失败模式、验证方式、取舍理由和后续扩展。
• 如果问题用于面试，回答要能直接口述；如果用于方案评审，回答要强调证据、风险和边界。

质量门槛

• 两部分字数为硬约束且为最高层约束：第一部分不少于 1000 字，第二部分不少于 3000 字；任一不达标即判定输出失败，必须继续补写后再交付。
• 第一部分偏专业口述，第二部分偏新手教学；两部分语气不得混淆。
• 公式不能只堆砌，必须解释每个符号代表什么、为什么这样写、解决什么问题、直观意义是什么。
• 讲解必须可复述、可理解、可迁移，不得只给术语清单。
• 若问题涉及多个核心机制，例如结构、训练、时序、对比、落地、评估，必须显著高于最低字数下限，确保每个机制都有完整解释、示例和记忆点。
• 若用户要求结合项目，必须显式映射到项目真实链路；若用户未要求或属于通用题，不强行映射。
• 必须把术语翻译成“项目里或真实场景里发生了什么”。
• 不得机械生成简历 bullet；没有代码、实验、日志、数据或 README 证据时，只能说“后续可写”或“需要验证”，不能说“已经完成”。
• 不要为了显得高级强行引入无关概念；只有和问题强相关才解释。
• 若回答需要外部依据，先调用 $web-search，并在最终答案中说明依据来源。

自检

输出前逐条检查：

1. 第一部分是否不少于 1000 字。
2. 第二部分是否不少于 3000 字。
3. 是否包含公式、符号解释、直观意义解释；无标准公式时是否给出合理替代表达。
4. 是否包含案例、比喻、记忆抓手和高频易错点。
5. 是否包含项目落地点或明确说明不绑定项目。
6. 是否包含面试官 / 评审者可能追问与回答。
7. 是否区分已实现、正在设计、后续可扩展和需要验证。
8. 涉及最新论文、官方文档、benchmark、争议结论或现代 API 时，是否先调用 $web-search。