lionad-morotar/get-secrets

Workflow

1. 从用户输入获取阅读资料，如用户输入为空则从会话上下文获取待处理资料（或知识）
2. 不直接从原文转述，而是先执行 2-3 轮搜索补充：
   • 使用 open-websearch / fetchWebContent / Read 等只读工具
   • 搜索方向必须紧扣用户上下文，例如：具体机制、版本差异、常见踩坑、参数 trade-off、与其他模块的耦合关系
   • 搜索是为了补足用户可能不知道、但对主题有直接帮助的内容
3. 从"搜索结果 + 用户上下文"的交叉点中提炼真正的 Secrets
4. 输出 1-4 条进阶知识，不强制凑数；如果材料过浅或搜索后无高价值发现，输出 0 条并提示用户
5. 为每条知识进行极简验证（仍不超过 2 轮工具调用），确保关键事实无误
6. 按质量与深度排序，只保留最精炼的内容

要求：

1. 绝不修改用户给出的原文档
2. 不要包含对原文档的"审判"或"引用"，专注于知识 2.1 最坏的情况你把原文档的错误以"常见认知错误"间接引导读者
3. 验证过程必须非常简单，每个知识不超过 2 次工具调用
4. 每条知识的输出严格遵循以下格式（仅知识即可，无需输出"验证得分"等杂项）

输出格式

<num>. <一句话brief，控制在15字以内>

<随知识复杂度逐层深入的详细描述>

描述要求：

• 用自然叙述，不要列表式结构（不要"背景：xxx 原理：xxx"）
• 一句话能讲清不用两句话，但信息密度要足够
• 随复杂度自然展开，从现象到机制到影响

与归档的对应关系

输出的 1-4 条知识在后续 distill-and-archive 阶段有两种处理方式：

• 主题相近时，可合并为同一个 #### 四级标题下的若干段落，此时归档后只保留一个 见： 来源；
• 主题独立时，可拆分为多个 #### 四级标题，每个标题对应一个原子知识点，各自保留一个 见：。

质量标准

Secrets 的形态不限于某一固定类型，可以是踩坑、反直觉、工程杠杆、区分度，也可以是耦合关系、版本陷阱、调试技巧、性能暗面等。

只要一条知识满足以下三个特征，就有可能成为真正的 Secret：

• 文档不会直接告诉你
• 有具体场景或失败模式
• 能改变实际决策

硬性过滤：以下情况必须丢弃

• 只是用户原文的换一种说法
• 只是官方文档某句话的转述
• 没有具体机制或具体失败场景
• 是空洞建议（如"要注意异常处理"、"需要优化"）
• 泛泛而谈的最佳实践，没有具体案例或根因分析

禁止事项

• 禁止编造第一人称"我们在xxx项目中遇到"之类的虚假经历
• 禁止输出文档里已经明确写了的基础概念
• 禁止输出泛泛而谈的最佳实践（如"要注意异常处理"）
• 禁止输出没有具体案例或根因分析的空洞观点
• 禁止为了凑满数量而降低质量