# Design Reasoning Trace

> 从基础目标、资源约束和常规方案出发，溯源复杂技术设计的动机与取舍，并生成从简单场景逐步演化的离线交互 HTML。用户表示看懂实现却不理解为什么这样设计、要求讲设计出发点、比较常规方案、反推设计思路或动态分步可视化时使用。

- Skill: `kirrito-k423/design-reasoning-trace` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add kirrito-k423/design-reasoning-trace`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kirrito-k423/design-reasoning-trace/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: Kirrito-k423 (https://skillmd.com/u/kirrito-k423)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/kirrito-k423/design-reasoning-trace

---


# 设计思路溯源

帮助读者在看到最终实现之前，自己走到下一步设计选择。把设计当作对具体问题的回应，而不是一组需要记忆的名词。

## 定义理解目标

先写一句读者承诺：读完后能解释原方案在哪个条件下遇到什么限制、新设计改变了什么、为此付出什么。

采用用户已经提供的背景。默认以不熟悉实现细节的技术读者为对象；先交付可操作的解释，不用连续追问阻断工作。

## 建立证据边界

读取直接相关的一手材料并固定版本。区分以下三种陈述，在可视化中就近标明：

- **源码事实**：实现确实执行了什么。
- **设计推导**：这个机制可能解决什么约束，以及何时有用。
- **教学假设**：为看清关系而设定的资源容量、时间、负载或缩小场景。

只有作者明确表达的动机，才称为作者动机。没有历史证据时，把解释写成合理的设计推导，不编造作者当时的决策过程。代码能证明行为，不能单独证明性能收益。

## 从最简单的可行方案开始

先确定必须完成的工作和不能改变的结果。用少量对象构造一个朴素方案，让它真正完成任务。

公平呈现常规方案的合理处境：在资源充足、规模较小或现有调度成熟时，它可能最简单且足够快。不得故意选择失效实现衬托新设计。

逐步增加一个压力变量，如并发数、接收容量、负载偏斜或完成时间差。让读者看到哪个资源开始等待，避免一开始展示复杂架构总图。

## 逐步产生设计

为每一步建立内部因果链：

```text
当前任务 → 已观察到的限制 → 最小改动 → 状态如何变化 → 新代价 → 下一问题
```

每一步只新增一个机制。保留对象的位置、颜色、名字与工作总量，让相邻状态可以直接比较。对尚未解释的复杂细节渐进披露。

至少展示一次反事实：去掉一个关键机制会怎样；资源充足时新方案是否仍占优。明确区分减少工作量、降低同时竞争、重新排序和转移成本。

不要把逻辑轮次画成真实全局时钟；局部同步、端到端依赖和全局同步必须区分。通信边表示允许访问、待发送请求还是实际传输，必须说清楚；没有路由命中不能画成必然产生数据。

## 制作可操作的 HTML

制作包含内嵌 CSS、JavaScript 和 SVG 的单文件 HTML，支持离线直接打开。默认使用原生浏览器能力，不引入远程字体或框架。

- 提供上一步、下一步、重置和明确的当前步骤。播放功能必须可暂停，到结尾停止。
- 用同一幅场景里的对象移动、流量变化、队列变化或高亮来表达因果，避免只切换文字或展示静态图集。
- 提供一个与因果关系直接相关的输入，让读者亲自制造或解除瓶颈。
- 显示当前发生什么、为什么采取下一动作，以及当前方案的成本。
- 指标从页面状态计算。标记教学单位与假设，不把动画速度、队列长度或公式估计冒充硬件基准。
- 将源码名词、完整配置和版本引用放到后续阶段或折叠区；首屏先说明任务与约束。
- 保持窄屏可用、按钮可键盘操作、焦点可见、减少动态效果偏好有效；暂停后不得继续偷偷推进。

如需站内发布，遵循仓库现有 HTML 载体契约；本技能本身不授权推送或部署，沿用用户已有授权。

## 回到真实设计

读者理解小场景后，才展示真实规模与关键映射。逐项说明哪些教学对象对应真实对象、哪些是简化、哪些推论尚未测量。

解释特殊常数或拓扑选择时，只讲证据支持的范围。不能用通用的限流直觉证明某一种编号方式或组大小最优。

## 验证与交付

实际操作每一步、重置、暂停、边界输入和反事实场景。检查对象覆盖、资源占用与叙述是否一致；缩小场景与真实实例映射应可复算。

用浏览器检查桌面和手机宽度、控制台错误、横向溢出与离线交互；嵌入站点时再检查沙箱兼容。只报告实际执行的验证。

以读者身份回答：不看公式能否说出为什么需要这个机制？能否解释什么时候常规方案足够好？若不能，先修改场景和因果过渡，不继续堆细节。

交付可直接打开的 HTML、简短核心判断及尚未确认的边界。把本次领域知识留在案例中，不把它固化成技能的永久限制。