前言

这篇文章，其实是我那篇《玩Android×AI Coding：从产品到代码。完整跑通一套 AI 软件研发工作流》里 「AI 不仅能使用工具，也能创造工具」 的展。

在那一节里我提到了一件事：

当 AI 已经能参与产品、UX、视觉和工程时我真正缺的。可能已经不是某个现成工具，而是一个更适合 AI 理解、AI 消费、AI 接力 Coding 的中间层。话说回来，

于是我没有继续折腾 Figma 的付费能力。也没有继续找 Axure、墨刀的平替。

我直接让 AI 和我一起，做了一个新的工具：

AIWireframeViewer。

它不是设计稿工具，也不是页面生成器。它是一个 JSON 驱动的低保真原型查看器。

使用者痛点

• 高保真设计稿只能给人看，无法直接供代码生成或 AI 消费。其实，
• 传统原型链接只能手工点击。缺少可编程的交互描述，
• 设计文件与代码世界脱节，导致从设计到实现的转化成本极高。
• 现有原型工具的坐标程序、层级结构不统一，导致跨团队协作时出现解释歧义。
• 缺少结构化校验。一旦 JSON 手写错误，就会在运行时才暴露问题。
• 无法把生成的原型直接喂给后续的 AI Coding 环节，只能靠人工复制粘贴文字说明。

为什么我要自己造这个工具

当时我已经有了这些东西：

• API 文档
• PRD
• 信息架构
• Wireframe 布局文档
• 视觉规范
• 组件映射思路

按正常流程。接下来似乎应该把这些东西继续塞给现有原型工具，生成一个可交互原型。但我很快发现，现有工具都不是我真正想要的。

我想要的不是…

• 一个只能给人看的高保真设计稿；
• 一个只能手工点击的原型链接；
• 一个和代码世界完全脱节的设计文件。

我真正想要的是…

换个角度我需要的不是“更漂亮的原型”，而是“更可计算的原型"。

AIWireframeViewer 目前是一个基于 React + Vite + TypeScript 实现的 JSON 驱动低保真原型查看器。其实，V1 已经具备两种模式：

• Edit​or: 项目工作台、页面排布、页面列表视图；
• Runtime​: 从入口页开始运行交互、跳转、回退和历史栈。

• • React
• • Vite
• • TypeScript
• • React Router
• • AJV
• • Vitest
• • Playwright

The viewer does not hard‑code pages in JSX;instead it drives UI from three JSON sources:

• • /project/manifest.json
• • /wireframes/*.json
• • /schema/*.json

This means React is merely a container – real description of “what this prototype is” lives in JSON.

我想解决的。不是“渲染页面”，而是“定义中间语言”

If you only want a demo you could quickly:

1. Create a single React page;Add routing; Add a few buttons for navigation; Add a sidebar / workbench.

This would give you something that “looks like a prototype”,but it would be just anor front‑end project – nothing more.

The real problems I cared about are:

li>Is prototype structure independent of code?li>Can we validate it rar than trusting any hand‑written JSON?li>Can we feed this structure back to an AI for furr coding?

I refore started by defining a **middle language** instead of jumping straight into a renderer.

从两层语言模型来看，

li>Project Layer – describes whole application;li>Wireframe Layer – describes each individual screen .

为什么要分成 Project Layer 和 Wireframe Layer？

Project Layer：描述整个项目

{ "projectId": "ai-wireframe-viewer-demo","entryPage": "home","schema": { "project": "../schema/project.schema.json"。"wireframe": "../schema/wireframe.schema.json" },"pages": }

The manifest only stores **references**,never copies page contents. It answers questions like:

li>Which pages belong to project?li>What is entry page?怎么说呢，li>Where are page files located?li>What is initial workbench layout?

Wireframe Layer：描述单个页面

li>Page identifier。viewport,element tree,coordinates & size;li>Interaction definitions;li>Navigation summary and meta‑data.

This separation brings immediate benefits:

l i>Pages can be reused across projects;l i>Project‑level metadata never pollutes page definitions;l i>Each page can be validated and loaded independently;l i>Future multi‑project support stays clean.

Wireframe 协议是怎么设计出来的？不过，

顶层结构

{ “schemaVersion”: “.”,“page”: { “id”: “home”,“title”: “首页”,“level”: “primary” },“viewport”: { “width”:,“height”:,“unit”: “dp” },“canvasPosition”: { “x”:。“y”: },“coordinateSpace”: “page”,“elements”:,“navigation”: {},“metadata”:{}}

关键取舍

坐标程序固定为 page

• 简单而且最不容易出错。

仅保留两个根容器

name 与显示内容分离

{ 至于"id"，"search-submit-text","type":"text","name":"搜索提交文本","text":"搜索","x":,"y":,"width":,"height":,"fixed":true,"scrollable":false。"visible":true,"coordinateSpace":"page","layout":{},"style":{},"children":,"interactions": }

The field responsibilities are split:

交互先收敛后发散
为什么我要加上 Schema？

If you think writing JSON files is trivial,you’ll soon hit runtime chaos without validation.

{ “issues”： } { const manifest = await readJsonAsset;const projectSchema = await readJsonAsset;const wireframeSchema = await readJsonAsset;issues.push);issues.push);for { const wireframe = await readJsonAsset;issues.push);issues.push);pages.push，} if { throw new ProjectValidationError);} return loadedProject;} V1 已经能做到什么程度？
AI 在这里到底扮演什么角色？话说回来，

I deliberately avoid positioning this as an *auto‑generate‑code‑by‑AI* tool.

The AI’s job here is to **produce structured Wireframe JSON** from prompts or design documents. That structured output can n be:
V1 为何仍保留一些“不完美”？ // Intentional limitations in V1: • canvasPosition duplicated in manifest & wireframes • supplemental cross‑file validation still lives outside pure JSON Schema • viewer.version only declares minimum/recommended compatibility • only fixed‑layer & scroll‑layer supported • ... intentional restraint to stabilize core pipeline first. ​ ​ ​ ​ ​ ​ ​ ​ ​​⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠​ ​​​​​​​​​ ​​ // End of list ​​​ ​ ​​​ ​​​ ​ ​ ​​ ​​​ ​​ ​ ​​ ​ ​ ​ ​ `` `. These constraints keep V1 lightweight while guaranteeing that ** whole chain—from Manifest loading through Runtime execution—is reliable**.

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

-- --

---

---

---

--

---

---

---

---

---

---

---

---

---

---

---

---

---

---

---

"回头看这件事，我最在意的从来不是「我做了一个 Viewer」——而是「整条链路打通了」：Project -> Wireframe -> Schema -> Loader -> Renderer -> Runtime。当 AI 已经能够参与研发，我们要做的不止让它写代码。提供一套适合协作的输入与中间层。"

"AIWireframViewer 是这条道路上的第一步先，也是一次成功实验。"

---