聚焦可视化说明

用最小的可视化回答当前问题。可视化必须让关系、顺序、层级或变化比短文本更容易理解；如果一句话或短列表已经清楚，直接回答，不创建图表。

选择视图

优先用一张图回答问题；图内用分组同时展示模块或阶段之间的流转及各模块内部处理。只有分支过密、单图难以阅读时才补充分图。

详细格式示例见 references/examples.md，需要对应形式时再读取。

代码架构与数据流

用户要理解代码如何运转时，参考“组件或关键类型 + 工作协程 + 通道/队列 + 外部系统”的结构图，而不是只画文件依赖。先从实际代码追踪消息的生产、传递、消费和返回路径；图中只保留回答问题必需的字段、入口方法和并发单元。

• 用容器或分组表示归属，用带方向的箭头表示数据流；箭头标明消息、read/write 或调用动作。区分创建/持有关系与消息流，勿用同一种箭头暗示两种含义。
• 把通道/队列、工作协程、网络或进程边界画成独立节点；有缓冲、扇出、回流或异步处理时标出实际路径。不要凭类型字段推断运行时流向。
• 在图旁按发生顺序说明数据从哪里来、如何转换或排队、由谁消费、最终到哪里；点明关键分支和阻塞/异步边界。图中的标签与文字使用相同名称。
• 在同一图中用边界圈出模块或阶段，边界内画处理步骤，跨边界箭头画输入输出和交接；让读者能沿箭头从入口读到结果。复杂分支才另画分图，并用同名节点标明它接回主图的位置。
• 只展开理解当前问题所需的模块和路径，避免照搬所有字段、方法或协程。参考 架构与数据流示例。

面向外行的通俗图解

用户输入 /eli5、要求“像给五岁孩子讲”或用最简单的图解说明原理时，读者是完全不了解该主题的人：

• 默认生成自包含的 HTML 图解，大图为主、文字极少；用户指定其他格式时，在该格式里保持同样简单、以图为主的讲法。问题本身一两句话就能说清时直接回答，不生成文件。
• 先确认核心事实，再选类比；类比不能改变关键因果关系。用一句短注说明类比在哪里不成立，避免读者把简化模型当成完整实现。
• 主题依赖最新事实（版本、价格、现状）时，先查可信来源再解释，不凭记忆。
• HTML 无法生成、打开或验证时，退回简短的 ASCII 或 Markdown 图解，不让格式阻塞解释。

最小流程

1. 用一句话写清用户需要理解的关系或变化。
2. 从代码、配置、用户提供的内容或已验证事实中提取最小节点和连接。
3. 选择上表中的最简单形式，删除与问题无关的文件、字段、组件和分支。
4. 在图旁用一两句话解释读图方式和最重要的结论。
5. 复核节点名称、方向、顺序和状态；无法确认的关系标记为“推测”或省略，不把示意图画成已验证事实。

HTML 边界

只有静态文本视图明显不足时才创建 HTML。沿用目标产品的颜色、字体和组件；没有真实设计系统时使用克制的中性样式，不虚构品牌。

• 使用真实标签与经过验证的数据；示例数据必须明确标记。
• 同时检查桌面和窄屏布局。
• 生成后实际打开或渲染，确认无脚本错误、遮挡、溢出和不可读文本。
• 用户未要求持久文件时，写到安全的临时或任务输出目录，不污染源码树。
• 创建文件不等于授权发布或部署。

输出契约

最终结果包括：

• 可视化本体或生成文件的可点击路径；
• 一段简短说明，指出视图覆盖的范围；
• 任何为了清晰而省略、简化或仍未验证的部分；
• HTML 的打开或渲染验证结果。

不要用装饰性图表重复已经清楚的正文，也不要用可视化替代必要的代码、日志或来源证据。