lionad-morotar Workflow
- 从用户输入获取阅读资料，如用户输入为空则从会话上下文获取待处理资料（或知识）
- 不直接从原文转述，而是先执行 2-3 轮搜索补充：
- 使用
open-websearch/fetchWebContent/Read等只读工具 - 搜索方向必须紧扣用户上下文，例如：具体机制、版本差异、常见踩坑、参数 trade-off、与其他模块的耦合关系
- 搜索是为了补足用户可能不知道、但对主题有直接帮助的内容
- 使用
- 从"搜索结果 + 用户上下文"的交叉点中提炼真正的 Secrets
- 输出 1-4 条进阶知识，不强制凑数；如果材料过浅或搜索后无高价值发现，输出 0 条并提示用户
- 为每条知识进行极简验证（仍不超过 2 轮工具调用），确保关键事实无误
- 按质量与深度排序，只保留最精炼的内容
要求：
- 绝不修改用户给出的原文档
- 不要包含对原文档的"审判"或"引用"，专注于知识 2.1 最坏的情况你把原文档的错误以"常见认知错误"间接引导读者
- 验证过程必须非常简单，每个知识不超过 2 次工具调用
- 每条知识的输出严格遵循以下格式（仅知识即可，无需输出"验证得分"等杂项）
输出格式
<num>. <一句话brief，控制在15字以内>
<随知识复杂度逐层深入的详细描述>
描述要求：
- 用自然叙述，不要列表式结构（不要"背景：xxx 原理：xxx"）
- 一句话能讲清不用两句话，但信息密度要足够
- 随复杂度自然展开，从现象到机制到影响
与归档的对应关系
输出的 1-4 条知识在后续 distill-and-archive 阶段有两种处理方式：
- 主题相近时，可合并为同一个
####四级标题下的若干段落，此时归档后只保留一个见：来源； - 主题独立时，可拆分为多个
####四级标题，每个标题对应一个原子知识点，各自保留一个见：。
质量标准
Secrets 的形态不限于某一固定类型，可以是踩坑、反直觉、工程杠杆、区分度，也可以是耦合关系、版本陷阱、调试技巧、性能暗面等。
只要一条知识满足以下三个特征，就有可能成为真正的 Secret：
- 文档不会直接告诉你
- 有具体场景或失败模式
- 能改变实际决策
硬性过滤：以下情况必须丢弃
- 只是用户原文的换一种说法
- 只是官方文档某句话的转述
- 没有具体机制或具体失败场景
- 是空洞建议（如"要注意异常处理"、"需要优化"）
- 泛泛而谈的最佳实践，没有具体案例或根因分析
禁止事项
- 禁止编造第一人称"我们在xxx项目中遇到"之类的虚假经历
- 禁止输出文档里已经明确写了的基础概念
- 禁止输出泛泛而谈的最佳实践（如"要注意异常处理"）
- 禁止输出没有具体案例或根因分析的空洞观点
- 禁止为了凑满数量而降低质量