选择算法诊断页的交互结构

三种方案都能展示“正常功能 → 当前问题 → 原因 → 后果 → 纠正方案 → 预期结果”。请重点比较:第一眼是否容易理解,以及点击后能否逐层深入。

B · 推荐:双层算法地图
算法基线 | 问题叠加 | 修正预演  [当前:问题叠加]
输入路径 曲率计算 ⚠ 平滑约束 输出轨迹
原因
边界导数不连续
影响传播
曲率峰值 → 控制抖动
纠正预演
新约束 → 预期稳定

基线流程 + 故障/修正叠加层

先固定展示算法正常机制;点击问题后在同一流程上高亮故障节点、原因和影响,再切换到修正方案预演。上下文不丢失,最适合函数与算法诊断。

A · 线性故事链
1. 原算法功能 输入如何变成输出
↓ 点击继续
2. 当前问题 异常发生在哪里
3. 原因与后果 为什么错、会导致什么
4. 纠正与预期 改什么、预计变成什么

从上到下的诊断故事

阅读顺序最直观,适合汇报展示;但算法复杂或问题较多时页面会变长,比较多个问题时容易失去原流程位置。

C · 自由探索工作台
函数列表

calculate()

smooth()

validate()
可缩放算法关系图
节点可自由点击
节点详情
输入
源码位置
问题
根因
影响
验证

图谱式诊断工作台

探索能力最强,适合大型算法和多个函数;但实现与维护成本最高,日报第一次打开时也更容易让读者迷失。

我的建议:选择 B。它保留原算法作为稳定“地图”,问题和解决方案都是同一张地图上的可切换叠加层,最符合你强调的“点击就能理解目前状况和修正后结果”。