Kirrito-k423 设计思路溯源
帮助读者在看到最终实现之前，自己走到下一步设计选择。把设计当作对具体问题的回应，而不是一组需要记忆的名词。
定义理解目标
先写一句读者承诺：读完后能解释原方案在哪个条件下遇到什么限制、新设计改变了什么、为此付出什么。
采用用户已经提供的背景。默认以不熟悉实现细节的技术读者为对象；先交付可操作的解释，不用连续追问阻断工作。
建立证据边界
读取直接相关的一手材料并固定版本。区分以下三种陈述，在可视化中就近标明：
- 源码事实：实现确实执行了什么。
- 设计推导：这个机制可能解决什么约束，以及何时有用。
- 教学假设：为看清关系而设定的资源容量、时间、负载或缩小场景。
只有作者明确表达的动机，才称为作者动机。没有历史证据时，把解释写成合理的设计推导，不编造作者当时的决策过程。代码能证明行为，不能单独证明性能收益。
从最简单的可行方案开始
先确定必须完成的工作和不能改变的结果。用少量对象构造一个朴素方案，让它真正完成任务。
公平呈现常规方案的合理处境：在资源充足、规模较小或现有调度成熟时，它可能最简单且足够快。不得故意选择失效实现衬托新设计。
逐步增加一个压力变量，如并发数、接收容量、负载偏斜或完成时间差。让读者看到哪个资源开始等待，避免一开始展示复杂架构总图。
逐步产生设计
为每一步建立内部因果链：
当前任务 → 已观察到的限制 → 最小改动 → 状态如何变化 → 新代价 → 下一问题
每一步只新增一个机制。保留对象的位置、颜色、名字与工作总量，让相邻状态可以直接比较。对尚未解释的复杂细节渐进披露。
至少展示一次反事实：去掉一个关键机制会怎样；资源充足时新方案是否仍占优。明确区分减少工作量、降低同时竞争、重新排序和转移成本。
不要把逻辑轮次画成真实全局时钟；局部同步、端到端依赖和全局同步必须区分。通信边表示允许访问、待发送请求还是实际传输，必须说清楚；没有路由命中不能画成必然产生数据。
制作可操作的 HTML
制作包含内嵌 CSS、JavaScript 和 SVG 的单文件 HTML，支持离线直接打开。默认使用原生浏览器能力，不引入远程字体或框架。
- 提供上一步、下一步、重置和明确的当前步骤。播放功能必须可暂停，到结尾停止。
- 用同一幅场景里的对象移动、流量变化、队列变化或高亮来表达因果，避免只切换文字或展示静态图集。
- 提供一个与因果关系直接相关的输入，让读者亲自制造或解除瓶颈。
- 显示当前发生什么、为什么采取下一动作，以及当前方案的成本。
- 指标从页面状态计算。标记教学单位与假设，不把动画速度、队列长度或公式估计冒充硬件基准。
- 将源码名词、完整配置和版本引用放到后续阶段或折叠区；首屏先说明任务与约束。
- 保持窄屏可用、按钮可键盘操作、焦点可见、减少动态效果偏好有效；暂停后不得继续偷偷推进。
如需站内发布，遵循仓库现有 HTML 载体契约；本技能本身不授权推送或部署，沿用用户已有授权。
回到真实设计
读者理解小场景后，才展示真实规模与关键映射。逐项说明哪些教学对象对应真实对象、哪些是简化、哪些推论尚未测量。
解释特殊常数或拓扑选择时，只讲证据支持的范围。不能用通用的限流直觉证明某一种编号方式或组大小最优。
验证与交付
实际操作每一步、重置、暂停、边界输入和反事实场景。检查对象覆盖、资源占用与叙述是否一致；缩小场景与真实实例映射应可复算。
用浏览器检查桌面和手机宽度、控制台错误、横向溢出与离线交互；嵌入站点时再检查沙箱兼容。只报告实际执行的验证。
以读者身份回答：不看公式能否说出为什么需要这个机制？能否解释什么时候常规方案足够好？若不能，先修改场景和因果过渡，不继续堆细节。
交付可直接打开的 HTML、简短核心判断及尚未确认的边界。把本次领域知识留在案例中，不把它固化成技能的永久限制。