--- 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`。