我做了一个 4MB 的 Markdown 编辑器，可以直接“运行算法”
最近做了一个比较有意思的小项目：
👉 一个支持“算法可视化”的 Markdown 编辑器
和普通 Markdown 编辑器不同的是，它不仅能写内容，还可以在文档中直接运行算法，并实时展示过程。
一、先看效果
比如写一段排序：
:sort{array=[64,34,25,12,22,11,90], algorithm="bubble", speed=400}
右侧会直接展示排序过程动画（支持播放 / 单步 / 重置）。
再比如查找：
:search{algorithm="interpolation", target=50, array=[10,20,30,40,50,60,70,80,90]}
可以看到查找路径。
图算法也支持：
:graph{algorithm="dijkstra", startNode="A"}
会动态展示最短路径更新过程。
二、为什么要做这个？
一开始其实只是想解决一个很简单的问题：
👉 算法讲解太抽象了
很多时候我们写算法笔记，大概是这样：
1. 比较相邻元素
2. 交换
3. 重复
但这种描述：
- 不直观
- 不好理解
- 不适合教学
于是我在想：
👉 能不能让 Markdown “动起来”？
也就是：
写下算法，同时看到它运行的过程
三、核心设计：DSL + 实时渲染
这个项目的核心是一个简单的 DSL（领域特定语言）：
:sort{...}
:search{...}
:graph{...}
编辑器在解析 Markdown 时：
- 识别这些指令
- 转换为组件
- 在右侧实时渲染
本质上是：
Markdown → AST → 组件 → 动画
四、目前支持的能力
目前已经实现了一些基础能力：
1. 排序算法
- 冒泡排序
- 快速排序
- 归并排序
- 插入排序
支持：
- 动画播放
- 单步执行
- 高亮比较 / 交换
2. 查找算法
- 线性查找
- 二分查找
- 插值查找
3. 图算法
- BFS
- DFS
- Dijkstra
支持：
- 节点高亮
- 距离更新
- 访问路径展示
五、为什么体积只有 4MB？
这个项目有一个比较极端的点：
👉 整个程序目前不到 4MB
主要原因：
- 没有使用 Electron
- 没有内置 Chromium
- 使用原生 GUI
带来的好处是：
- 启动快
- 占用低
- 分发轻量
六、一些设计思考
在实现过程中，有几个关键点：
1. Markdown 不只是“展示”，还可以“执行”
传统 Markdown：
展示内容
现在变成：
描述行为 + 执行逻辑
2. 可视化是理解算法的关键
相比文字描述：
👉 动画 + 状态变化 更容易理解
3. 从“工具”走向“平台”
目前正在考虑把所有组件插件化：
core（编辑器） + plugins（算法组件）
用户可以：
- 按需安装算法
- 自定义组件
七、接下来准备做什么
后续计划：
- 支持更多算法（图 / DP / 树）
- 插件系统（组件外置）
- 统一 DSL 规范
- 支持用户自定义组件
八、想听听大家的建议
目前还在早期阶段，有几个问题想请教：
- 这种“在 Markdown 里运行算法”的形式，有实际使用场景吗？
- 是应该专注“算法教学”，还是做成通用组件平台？
- 有没有类似工具用过但体验不好的？
九、项目地址
刚整理好代码，准备放到 GitHub，如果有兴趣可以一起交流。
（如果有人想体验我可以放下载链接）
最后
这个项目一开始只是一个小工具，但做着做着发现：
👉 它可能不只是一个编辑器，而是一种“可执行文档”的尝试
欢迎大家拍砖 🙏
