我最早开始想这件事时，想法也很常见：既然已经有 AI Coding 了，是不是可以直接把 Figma 设计稿和 PRD 丢给 agent，让它自动生成代码。
但真正进到 AI Coding 现场后，我先撞上的并不是"模型够不够聪明"，而是更基础的几个问题：Figma 用像素说"长什么样"，PRD 用自然语言说"做什么"，两者之间没有一个 AI agent 能稳定解析的共同语言。直接给 AI 截图也不行——并非所有模型都擅长从图片中提取精确的布局信息（比如 DeepSeek 在这方面就比较弱）。
而且这个问题在一个传统开发场景里被放大了，因为还有两个额外约束：
约束一：视觉还原要求高。 这不是一个内部工具或原型项目——设计稿是经过专业设计师打磨的，产品方和业务方对视觉一致性有明确要求。AI agent 从截图"自由发挥"出来的 UI，可能在功能上是对的，但在间距、字号、配色上偏差明显，审美的"差不多"在这里通不过。
约束二：私有组件库。 项目使用的是团队自己的组件库，而非通用的 Ant Design 或 Tailwind UI。这意味着 AI agent 不仅要知道"这里有个表格"，还要知道该用项目里的 DataTable 组件、FilterPanel 组件、StatusBadge 组件——而这些组件在公开的训练数据中不存在。Figma 设计稿里的一个表格，AI 可能会用 antd Table 去实现，但项目实际需要的是私有组件库里的对应封装。
两个约束叠加后，形成了这样一个局面：Figma + PRD → AI Agent 产出的代码，既不像设计稿（视觉偏差），又不通组件库（用了不存在的依赖）。
所以我后来更认可的一种做法是：在 Figma 设计稿和 AI Coding 之间插入一个 ASCII 翻译步骤。
解法：ASCII 图作为 Figma 和 AI Coding 之间的翻译层
我的做法是在 Figma 设计稿和 AI Coding 之间插入一个 ASCII 翻译步骤：
整个流程中，ASCII 图承担的角色是将视觉信息（Figma）和逻辑信息（PRD + 会议）合并为一个 AI agent 可以精确消费的结构化输入。私有组件库的映射在 SPEC 阶段注入——ASCII 图上标注哪个区域对应哪个私有组件，让 agent 知道用 DataTable 而不是 antd Table。交叉自检环节保证 ASCII 输出和原始输入的意图、布局一致，不匹配就回到 Qwen/GPT 修改。
具体操作：从 Figma 导出一张页面截图，丢给 chat.qwen.ai 或 chatgpt.com，使用以下 prompt：
这个图片是一个网页，请将这个图片转为 ascii 图，注意不要篡改布局，尽量还原原本的布局和内容。如果整张图有困难的时候，可以按页面的模块划分逐个输出，但模块只能按水平进行切分，不允许把一行的模块分别输出。
为什么用外部模型而不是本地？因为目前不是所有模型都擅长图片→ASCII 的转换（你试过的 deepseek 就不太行），而 Qwen 和 GPT（免费有数量限制） 在这类视觉解析任务上表现稳定。
这个 prompt 有几个关键设计：
- "不要篡改布局"：ASCII 图的核心价值是结构保真，不是视觉保真
- "按模块划分逐个输出"：复杂页面一张 ASCII 图放不下，分段输出
- "只能按水平切分"：保证每个输出块的上下文完整——一行里的多个模块必须一起出现，否则 AI coding agent 会丢失模块间的横向关系
整个工作流是怎么运作的
以项目中一个"事件管理"页面为例：
Step 1: PRD + 会议消化
产品的 PRD 描述了事件管理需要哪些字段和功能，UI 宣讲会上讨论了交互细节（字段展示、编辑状态、发布/下架流程）。这些信息散落在 PRD 文档和会议转录中。
Step 2: Figma → ASCII
把设计师的后台页面设计稿导出为 PNG，用 Qwen 转为 ASCII 图，得到类似这样的布局描述：
┌──────────────────────────────────────────────────────┐
│ 产品追踪 > 事件管理 │
├──────────┬───────────────────────────────────────────┤
│ 筛选区 │ │
│ 类别: [] │ ← 按类别型号排序 │
│ 时间: [] │ │
├──────────┴───────────────────────────────────────────┤
│ 表格 │
│ ┌─────────┬─────────┬──────────┬──────────┬────────┐ │
│ │ 事件日期 │ 发布状态 │ 类别 │ 型号 │ 操作 │ │
│ ├─────────┼─────────┼──────────┼──────────┼────────┤ │
│ │ 2025.03 │ 已发布 │ 某品牌 │ Model X │ [编辑] │ │
│ │ 2025.02 │ 待发布 │ 某品牌 │ Model Y │ [编辑] │ │
│ └─────────┴─────────┴──────────┴──────────┴────────┘ │
│ [分页 1/3] │
└──────────────────────────────────────────────────────┘
Step 3: ASCII 图 + PRD 结论 → SPEC
现在 AI agent 有了结构化的布局输入（ASCII 图），再加上 PRD 和会议中讨论的行为规范，我就可以让它生成更精确的 SPEC。ASCII 图提供了"这个页面有什么、东西在哪"的确定性，PRD 提供了"它要做什么"的逻辑，两者互补。
AI agent 拿到这些输入后产出的 SPEC 就不只是"一个带表格的页面"，而是：
产品追踪事件管理页面，包含类别筛选、时间筛选、事件表格（事件日期/发布状态/类别/型号/操作），分页展示，支持展开全部。事件列表按类别型号排序规则排列，已发布事件编辑后进入"待发布"态...
这种 SPEC 的可执行性远高于仅基于 PRD 文字描述的产出。
Step 4: 有 SPEC 后 → AI Coding 更顺畅
当 AI coding agent 接到一个具体的开发任务（比如"实现产品追踪事件管理表格"），它不再需要从模糊的 PRD 中猜测布局和交互——ASCII 图给出了视觉结构，SPEC 给出了行为规范。它可以直接对照 ASCII 图生成组件布局，对照 SPEC 生成交互逻辑。
和市面上其他方案的关系
这个方案不否认 Figma MCP、Figma-to-YAML 插件等工具的价值。如果你能直接用 MCP 拿到结构化的 Figma 数据，当然更好。但在很多场景下（没有插件权限、设计稿在外部、模型不支持图片解析），ASCII 图是最通用的兜底方案。
而且 ASCII 输出有一个独特优势：它是人类和 AI 都能同时读懂和修改的。你可以在 ASCII 图上标注"这列宽度从 120 改到 150"，AI 能理解，人也能理解。你做不到在 Figma YAML 输出里这样随意批注。
Fluxwing 这类 ASCII-first 设计系统走的是另一个方向——用 ASCII 做草图，渐进增强到高保真。但那个模式的假设是"没有设计师"，更像 vibe coding 的原生工作流。我们这里要解决的是"已经有一个专业的设计师出了高保真的 Figma，怎么让这张设计稿被 AI 准确理解"——这是相反方向的翻译：从高保真降维到 ASCII，而不是从 ASCII 升维到高保真。
这个方法的适用范围
虽然本文的出发点是传统开发模式（有设计师、有私有组件库），但 ASCII 图作为中间语言的价值不止于此：
- 传统开发模式：它让设计师的 Figma 和 AI coding agent 之间有了一个所有模型都能理解的中间格式
- vibe coding 模式：如果你用的 agent 不擅长直接解析图片（比如 DeepSeek），你可以手动走一遍图片→ASCII→代码的流程
- 纯文本需求场景：即使没有设计稿，当需要向 AI 示意一个复杂布局时，ASCII 图比自然语言描述更精确
关键不在于有没有设计师，而在于让 AI coding agent 得到一个结构的锚点——在茫茫的自然语言中，ASCII 图是它理解"这个页面到底长什么样"的最短路径。
已落地为 Skill
这个流程已经封装为一个可复用的 figma-to-ascii Skill，支持三种输入模式：
| 模式 | 输入 | 处理方式 |
|---|---|---|
| A: 图片模式 | 设计稿截图（PNG/JPG） | 将图片交给支持视觉解析的模型（Qwen/GPT），使用专用 prompt 转为 ASCII |
| B: Figma 链接模式 | Figma URL + 页面描述 | Agent 尝试从 Figma 页面提取截图，成功则走模式 A，失败则提示手动导出 |
| C: 意图模式 | 纯文本需求/意图描述 | 根据需求和意图直接生成 ASCII 布局图 |
无论哪种模式，Skill 生成 ASCII 后会自动执行交叉自检——检查模块完整性、层级关系、布局保真、内容还原、交���状态覆盖、边界条件 6 个维度，不匹配就修改直到通过。
而且产物不仅是一张静态 ASCII 布局图。弹窗、下拉展开、空数据、加载中、错误态这些 Figma 里通常是独立画板的内容，在 ASCII 输出中会被组织为独立的 ASCII 块，形成一份完整的"页面布局 + 交互状态��明书"。
过去两周在实际项目中已经被手动验证过了——大部分需求都是通过"Figma 截图→ASCII 图→结合 PRD 结论→生成 SPEC→驱动 AI coding"这个流程完成的。现在这个流程已经标准化为 Skill，可以直接调用。
相关资源：
figma-to-asciiSkill：https://github.com/Idea-Maglev/skills-shared/tree/main/figma-to-ascii- 技能共享仓库：https://github.com/Idea-Maglev/skills-shared