一批纯文本、等宽字符风格的绘图和 UI 草图工具重新冒头。代表是 Mockdown、Wiretext、Monodraw：有的跑在网页上，有的偏桌面使用，有的仍是 Mac 原生应用。
这不是设计工具革命。它更像一次小而准的提醒：当软件越来越能做一切，主动限制格式、颜色和操作，反而能把人从花活里拉回来。纯文本没赢在好看，赢在可维护。
发生了什么：老式等宽字符，被做成了新工具
这类工具借的是 1970s-1980s TUI 的气质。字符终端、文本界面、Turbo Vision 那套东西，核心是用固定宽度字符组织信息。今天换了外壳：浏览器、桌面应用、鼠标、触控板，还有更顺手的编辑体验。
这里的“ASCII”多半是口语说法，不等于严格只支持 ASCII 字符。重点不是字符集考古，而是等宽文本的表达方式：字符占位固定，结构容易对齐，复制到 README、代码注释、issue、技术规范里也不容易散架。
| 工具 | 可用形态 | 更适合做什么 | 现实判断 |
|---|---|---|---|
| Mockdown | 网页可用，移动端也能打开 | 低调图表、快速草图、AI 生成入口 | 门槛低，适合临时起稿 |
| Wiretext | 网页可用，但更偏桌面操作 | UI 线框、结构草图 | 更像产品和设计协作的轻工具 |
| Monodraw | Mac 桌面应用 | 代码文档内嵌图、精细字符图 | 更成熟，但平台更窄 |
典型用途很清楚：低调图表、代码文档内嵌、UI 草图、AI 生成和修改入口。它们不负责把设计稿交付到像素级，也不该承担品牌视觉。它们负责把关系讲明白。
为什么重要：纯文本的长处是可维护，不是万能
纯文本图有三件硬优势：可移植、可编辑、可版本控制。一个放在 Markdown、README 或代码注释里的图，可以被复制，可以被 grep，可以进 Git diff，也可以在 pull request 里直接看出改动。
这对开发者和技术写作者很实际。架构图、调用链、状态流，不必总是以截图形式躺在文档里。截图一旦过期，修改成本很高。纯文本图至少能跟代码一起 review、回滚、补丁化。
对产品设计师和 AI 工具重度用户，动作也很明确：早期别急着开 Figma 调组件。先用 Wiretext 或 Mockdown 把页面结构、信息层级、状态变化写出来。需要 AI 帮忙时，也优先让它生成可改的文本线框，而不是指望它稳定操作复杂画布。
它和现有工具不是一条赛道。
| 对比对象 | 强项 | 不适合替代的部分 |
|---|---|---|
| Mermaid | 更适合流程图、时序图等规范化图表 | 不适合随手画自由布局和 UI 草图 |
| Excalidraw | 更像白板，适合手绘感表达 | 文本 diff 和代码库内嵌不如纯文本自然 |
| Figma | 强在高保真设计、组件、协作和交付 | 早期结构讨论时容易被视觉细节拖走 |
| 纯文本绘图工具 | 可编辑、低干扰、适合进代码库 | 不适合复杂视觉、品牌稿、真实设计系统 |
边界必须说清。纯文本不是万能格式。复杂交互、视觉规范、设计系统、品牌表达，还是该交给专业工具。拿它替代 Figma，是误用；拿它替代没人维护的流程截图，才是正用。
我的判断：限制不是落后，是把控制权拿回来
“少则得，多则惑。”这句话放在今天的软件里很准。功能越满，选择越多，注意力越容易被格式吃掉。你本来想画一个接口草图，最后半小时耗在圆角、阴影、配色和自动布局上。
纯文本工具的锋利之处，是先砍掉这些诱惑。它逼你回答更基础的问题：结构是什么，信息怎么流，状态怎么变。它不让你用漂亮遮住混乱。
这也是它和 AI 时代合拍的地方。大模型处理文本更自然。让 AI 改一段字符图、补一个线框、调整一个流程说明，通常比让它稳定控制复杂视觉工具更顺。这里没有神话，只有接口更简单。
历史上类似的事反复出现。电报、早期报业、命令行、BBS，都靠低带宽和低装饰换来高传播。今天不完全一样。过去是硬件逼人简陋，今天是人在富媒体环境里主动克制。差别就在这里：过去是没得选，今天是知道什么不选。
接下来该看两件事。
- 它们能不能进入日常工作流.README、PR、issue、技术规范、AI 编程助手。
- 它们会不会停在“好玩截图”.看着新鲜，但没人愿意长期维护。
如果团队已经有成熟 Figma 流程，不需要迁移。更现实的做法是分层：早期结构讨论用纯文本或线框工具，进入视觉交付再回到 Figma。开发团队也不必重画所有旧图，先从最容易过期的架构说明、接口流程和部署草图下手。
我不太买账的是把它包装成复古审美。复古只是外壳。真正的利益点是控制成本：少一个格式依赖，少一次截图过期，少一轮无效视觉争论。工具越全，人越容易散。能把人按回问题本身的限制，今天反而值钱。