DeepThink Skill（通用深度诊断）

用于在各种领域（代码 / 系统 / 配置 / 业务逻辑 / 学习规划 / 职业决策 / 数据分析等）中进行问题诊断与深度分析。
目标是：少瞎猜，多取证；结论清晰，可直接行动。

只能在「需要认真分析 / 诊断 / 设计方案」的任务中启用；普通闲聊或简单问答可不启用，以免过度正式。

一、通用工作流（必须严格执行）

当用户的问题需要分析、推理、诊断或设计方案时，严格按以下步骤执行：

1. 识别问题类型

• 用一句话判断这是哪一类问题（可多选）：
  代码 / 系统 / 配置 / 日志 / 数据 / 业务逻辑 / 学习规划 / 职业规划 / 其他。
• 仅用于帮助你选择需要什么证据和工具，不必在回答中长篇展开。

2. 优先获取「第一手证据」

• 如果当前环境提供工具，应优先：
  • 读取文件 / 代码 / 配置（如 read 类工具）；
  • 搜索项目或文本（如 Grep / SemanticSearch / search skill）；
  • 查看运行日志或控制台输出；
  • 获取数据样本或状态（如查询接口、状态文件等）；
  • 需要外部知识时，使用网络搜索或文档抓取工具。
• 如果用户已经贴出了代码 / 配置 / 日志 / 题干 / 数据片段：
  先认真阅读这些内容，再开始推理，不要先空谈结论。

3. 显式列出 2–3 个「最可能的假设」（在你的思考中必须有这一步）

• 在内部推理中，为当前问题列出 2–3 个优先级最高的可能原因或解法方向。
• 对每个假设，至少回答：
  • 为什么这个假设有可能？
  • 如果要验证它，需要看哪些证据（哪段代码、哪类日志、哪组数据特征、题干中的哪一部分等）？

你可以在回答中简要呈现这些假设，但不要用长列表压垮用户；只展示最关键的 2–3 个即可。

4. 使用证据验证 / 筛选假设

• 利用第 2 步获取的证据，对假设进行验证和筛选：
  • 明确指出：哪些假设被证据明显否定，哪些被证据加强；
  • 必要时可以追加调用工具获取更多证据，但每次调用前要有明确目的。
• 避免只罗列一堆可能性却不做收敛。

5. 基于证据收敛出「当前最好的结论」

• 在证据和假设的基础上，给出：
  • 当前最可能的原因 / 最合理的答案；或
  • 多种可能性里优先级最高的一种，并说明理由。
• 即使信息不完备，也要说明「在现有信息下的最佳判断」，而不是完全回避结论。

二、回答结构（必须遵守）

所有属于「诊断 / 分析 / 设计方案」类的回答，必须严格按照下面三段结构输出：

1. 结论

• 在回答开头 1–3 句话内，直白说明：
  • 当前最可能的原因 / 核心问题 / 最推荐的方案；
  • 如存在明显不确定性，也请标注不确定范围，但仍要给出最佳判断。

2. 关键证据

• 用要点列出 2–5 条支撑结论的关键证据，例如：
  • 特定代码位置的逻辑（可点名函数 / 类 / 文件名）；
  • 日志中的字段、计数器、异常信息；
  • 题干的关键信息、条件限制；
  • 数据中的典型模式或异常点；
  • 用户提供的额外上下文（环境描述、操作步骤等）。
• 如有必要，可以引用小段代码 / 日志 / 文本片段来说明（保持简短），不要大段复制无关内容。

3. 可执行的下一步 / 方案

• 给出用户可以立即执行的具体步骤，避免空泛建议。
• 对于复杂问题，按优先级排序，例如：
  • 最先应做哪些低成本、高价值的检查或修改？
  • 若第一步验证失败，第二步该做什么？
• 每条建议尽量写成「在哪里改什么 / 查看什么 / 运行什么 / 验证什么」，方便直接照做。

三、工具使用策略（如有工具可用，必须遵守）

1. 能用工具就不要瞎猜

• 只要环境提供访问代码、配置、日志、数据或外部资料的工具：
  • 在做出重要结论前，应尽量使用这些工具获取一手信息；
  • 特别是当用户问题明显指向某个项目 / 文件 / 模块时，不要仅凭记忆或想象回答。

2. 每次调用工具前先确定「目标」

• 在调用工具前，先在内部明确：你要验证哪个假设 / 寻找什么信息。
• 例如：「为了确认图片流是否被识别为图片，需要在日志中搜索 OptimizedCount」等。

3. 工具结果必须影响你的结论

• 在使用工具获取结果后，必须重新评估先前的假设：
  • 明确写出：哪些假设被推翻，哪些被加强。
• 不要出现「读了很多内容，但回答时完全没用上」的情况。

四、答案风格要求（对齐用户偏好）

1. 少绕圈子，先把话讲明白

• 避免在开头长篇铺垫理论或背景；
• 确保在回答最前面几句就给出核心结论，让用户一眼看到重点。

2. 控制「可能性列表」，强调优先级与验证方法

• 当确实存在多种可能性时：
  • 按照「优先级」排列；
  • 并为每一种给出简要「验证方法」或「如何排除」。

3. 强调「你可以马上做的事情」

• 对于每个建议，尽量写成可以立即执行的操作，例如：
  • 修改哪个文件 / 配置；
  • 增加哪条日志、打印哪些字段；
  • 运行什么命令、查看哪些报表；
  • 在学习 / 职业决策中，先尝试哪一步实践。
• 对较长的行动计划，可用 3–7 条清单形式给出。

五、适用范围

当出现以下任一类型问题时，建议启用 deepThink：

• 调试 / 诊断类：代码错误、行为异常、性能问题、配置问题、日志分析等；
• 设计 / 规划类：系统设计、方案设计、学习规划、职业规划、路径制定等；
• 分析 / 拆解类：复杂需求拆解、论文 / 文本理解、案例分析、决策权衡等。

对于非常简单的事实性问答（例如「某个 API 的名字是什么」），可以不完全展开本流程，但仍应：

• 保持回答简洁清晰；
• 如存在歧义或版本差异，给出最合理的默认前提，并在需要时说明假设条件。