规范即新线框图:2026 年的规范驱动设计
规范驱动设计取代了线框图。本文将介绍一份优秀的设计规范应该是什么样子,它如何与人工智能工具协同工作,以及如何编写你的第一个设计规范。

线框图已成累赘。如今,规格说明才是交付产品的关键。
二十年来,线框图一直是产品设计的核心。方框、箭头、低保真矩形、占位符文案,它是第一个交付物,是定位工具,是你在真正开始绘制像素之前,需要拖入 Figma 文件的内容。
到了 2026 年,这个工具的地位已悄然下降。人工智能代码生成器能够更好地理解结构化意图,而非线框图,产品经理们也直接将规格说明导入 Cursor。
工程师们直接从 spec.md 文件交付功能,无需任何 Figma 链接。原型图如今已成为最后一步,甚至可能根本不会出现。
这并非工具的问题,而是工艺的转变。将规格说明视为主要交付物的设计师,交付速度更快,交接更顺畅,最终拥有的自主权也远超以往使用像素文件时。那些在画布上不停地拖动矩形的设计师们,眼睁睁地看着自己的影响力正在实时消逝。
为什么线框图失去了主导地位
线框图曾经风靡一时,因为过去交付一个屏幕需要四个人、三次交接和一个迭代周期。你需要低保真度的原型,因为高保真度的原型成本高昂。你需要一个翻译层,因为工程师和产品经理无法通过查看线框图文件就达成共识。
那个时代已经一去不复返了。Cursor、v0、Bolt 以及之后的四个工具,只需几分钟就能根据清晰的功能描述生成工作界面。它们无法解读你的线框图,但它们可以解读你的规格说明。
瓶颈转移了。像素现在很便宜,而意图才是稀缺资源。
线框图编码布局。规范编码了意图、行为、边界情况以及功能正确的条件。猜猜代码生成工具真正需要的是哪一个?
团队层面也在悄然发生着转变。设计师与产品经理的角色日益模糊,设计工程师的角色日益凸显,大多数产品团队中专职研究员的消失。所有这些都指向同一个方向。能够有效跨越这些模糊角色的,是文本,而不是方框。
线框图本质上是为那些还无法看到实物的人类设计的规划工具。而人工智能工具只需几秒钟就能根据描述渲染出一个尚可接受的工作界面。“让我们看看”的成本大幅降低。
当你能够以比绘制低保真版本更短的时间生成一个真正的交互式界面时,低保真版本就失去了意义。你要么直接使用规范,要么直接制作原型,完全跳过矩形。
模型解释“是什么”。规范解释“为什么”。
模型回答一个问题:它应该是什么样子。规范能够解答那些更复杂的问题。例如,它是做什么用的?它的用户是谁?
当数据为空时会发生什么?当网络出现故障时会发生什么?这里的“成功”究竟意味着什么?
2026 年,优秀的设计师会先编写规范,然后让视觉效果从中自然而然地产生。而不是反过来。视觉效果是决策的下游产物,而决策则存在于规范之中。
这并非什么新奇的观点。资深设计师多年来一直在编写结构化的原理说明。真正的新变化在于,规范现在是 AI 工具直接使用的资源,这意味着规范的编写质量至关重要。
模糊的规范会产生模糊的输出,而这种模糊的代价不再仅仅是让工程师感到困惑,而是导致你不得不放弃一个半成品的功能。
优秀设计规范的构成
能够经受住工程师和 AI 双重考验的规范都具有稳定的结构。在研究了数百个来自快速交付产品团队的规范之后,我们发现这种模式是一致的。

一份完整的设计规范包含七个部分,顺序如下:
-
意图:一段文字,阐述此功能存在的意义、它解决的用户问题以及产品发布后的变化。
-
范围:明确列出哪些功能包含在内,哪些功能明确排除在外,排除列表比包含列表更详细。
-
行为:逐步描述用户与功能交互时发生的情况,包括触发器、状态、转换和结果。
-
边界情况:一份枯燥乏味但又必不可少的列表:空状态、错误状态、加载状态、权限被拒绝、网络离线、达到速率限制、数据过期。
-
成功标准:我们如何判断功能是否有效,采用可衡量的标准而非主观感受,例如“保存率超过 40%”而不是“用户对保存操作感到满意”。
-
评估。 我们将自动测试以确认实现符合预期,这正是 AI 工作流程与传统设计真正不同的地方。
-
可访问性和文案。 WCAG 要求、键盘路径、屏幕阅读器行为以及用户看到的每一个字符串,都要以产品自身的语言呈现。
以上是工作核心。一些规范会添加“参考”部分,链接到设计系统标记、类似功能或先例。一些规范还会添加“风险”部分,标记团队在构建过程中应注意的事项。以上七点是不可妥协的。
请注意其中缺少的内容。没有屏幕截图,没有布局图,也没有方框和箭头流程图。规范将功能描述为一组约束和行为,而不是一张图片。
实践中的“线框图优先”与“规范优先”
从“线框图优先”到“规范优先”的转变,改变的不仅仅是最终的成果。它改变了谁负责什么、何时负责以及工作在团队中的流转方式。
|维度 | 线框图优先工作流程 | 规范优先工作流程 |
|---|---|---|
| 主要工件 | Figma 包含低保真屏幕的文件 | Markdown 规范,约 200 至 500 行 |
| 首次构建时间 | 3 至 7 天 | 当天,通常在同一小时 |
| 工程师输入时间 | 原型“完成”后 | 规范编写期间 |
| AI 工具参与 | 有限,后期 | 主要构建路径 |
| 边缘案例覆盖率 | 在质量保证阶段发现 | 在第 4 部分预先编写 |
| 交付格式 | Figma 链接加注释 | 规范文件加设计标记 |
| 迭代单元 | 屏幕或流程 | 规范章节 |
| 意图所在 | 在设计师的脑海中 | 体现在页面上,以文字形式呈现 |
规范优先列并非未来状态。这就是速度最快的产品团队在 2026 年的运作方式。而那些速度较慢的团队仍然把“线框图优先”的理念称为“设计”。

规范如何通过 AI 工具传递
一份编写良好的规范并非永远存放在 Notion 中的交付物,而是一种输入。
当你搭建功能框架时,规范就是你粘贴到 Cursor 中的内容。当你需要一条可行的路径时,规范就是你交给 Claude Code 的内容。当你生成初始 UI 时,v0 会读取规范。当你启动原型时,Bolt 会使用规范。

同样的工件,以不同的传递方式,驱动着构建过程的每个部分。
工程师在实现过程中会参考规范。设计系统团队会使用它来验证令牌的使用情况。QA 团队会根据成功标准编写测试并评估相关部分。甚至市场营销团队也可以从意图段落中提取发布文案。
这就是“规范即工件”转变的真正优势所在。一个权威的规范源,只需编写一次,即可被所有工具和所有角色使用。再也不用面对“Figma 已过时,但 Linear 工单里有最新版本”的情况了。设计师也不用再追着工程师更新后端约束后的模拟文档了。
规范存在于代码仓库中。它随代码一起移动,并在拉取请求中进行审查。规范一旦更改,更改就会被跟踪、记录日期并注明贡献者。试试用 Figma 文件做这些。
编写经得起工程师和 AI 考验的规范
发现糟糕规范最快的方法是将其交给代码生成器,然后查看返回的结果。如果输出错误,则规范本身也是错误的。模型就像一个严厉但公正的编辑器。
糟糕的规范有一些共同特征。他们使用团队内部人员难以理解的产品术语,并且用 UI 组件(例如“模态框”)而非用户操作(例如“用户确认保存”)来描述交互。他们忽略了边界情况,因为编写者认为读者会自行理解。他们把成功标准隐藏在某个人的脑子里。
好的规格说明是具体的。它们描述的是行为,而不是组件,并且用简洁的语言描述空状态。它们用系统可以衡量的数值来定义成功。它们读起来枯燥乏味,因为只有枯燥才能避免歧义。
一个有用的测试:把你的规格说明交给一个从未见过产品的人,让他描述一下最终会构建出什么。如果他能做到,那么规格说明就很好。如果他问了三个需要澄清的问题,那么规格说明就有三个漏洞。修补这些漏洞,然后发布产品。
洞察: 代码生成器是你规格说明遇到的最诚实的编辑器。如果构建结果有问题,那么编写的规格说明也有问题。
一个完整的带注释的迷你规格说明
以下是一个实际功能的可用规格说明示例。这是针对假想的 SaaS 产品的保存到集合模式,编写简洁,可直接复制粘贴到代码仓库中。
# Spec: Save to Collection
## Intent
Users browsing content need a way to bookmark items into named groups
so they can return to them later. Without this, repeat visit rate
drops and high-intent users churn.
## Scope
In: save action on any content card. Collection picker. Default
"Saved" collection. Create new collection inline.
Out: collection sharing. Collaborative collections. Collection
cover images. Reordering items within a collection.
## Behavior
1. User clicks the save icon on a content card.
2. Picker opens, anchored to the card, listing user's collections
plus a "+ New collection" row.
3. User selects a collection. Item is saved. Picker closes.
Toast confirms with collection name and an Undo action.
4. If user selects "+ New collection", inline input appears.
On submit, collection is created and item is saved to it.
## Edge cases
- User not signed in: clicking save opens auth modal,
resumes save action after auth.
- No collections exist: picker shows "+ New collection" only,
with placeholder text "Save your first item."
- Network error mid-save: toast shows error, save action remains
available, item is not marked saved.
- Item already in target collection: picker shows checkmark,
selecting it removes the item from that collection.
- User hits free-tier collection limit: "+ New collection"
row shows lock icon and routes to upgrade.
## Success criteria
- 30%+ of weekly active users save at least one item per month.
- Average user has 2.4+ collections within 30 days of first save.
- 60%+ of saved items are revisited within 14 days.
## Evals
- E2E: save flow completes in under 2 seconds on 4G.
- Unit: collection picker renders correctly with 0, 1, 50 collections.
- Visual: picker anchoring stays within viewport on all breakpoints.
## Accessibility and copy
- Save button: aria-label "Save to collection".
- Picker is fully keyboard navigable. Esc closes.
- Focus returns to save button on close.
- Toast is announced via aria-live="polite".
- Copy: "Saved to [Collection]" / "Undo" / "Save your first item".
该规范大约 40 行,不包含任何像素。AI 工具只需一次即可根据它构建出该功能的可用版本。工程师只需 15 分钟即可完成范围界定,而 QA 负责人可以直接从评估部分编写测试计划。
这就是最终成果。不是 Figma 文件,也不是流程图。就是这个。
如何编写你的第一个规范
如果你从未编写过规范,请从这里开始。选择一个你熟悉的简单功能,并打开一个空白的 Markdown 文件。使用上面的七节模板,并设置 90 分钟的计时器。
首先编写意图段落。如果你无法用三句话写出意图,说明你还没有真正理解该功能。停下来,弄清楚这一点,然后再继续。
然后编写范围。 “排除项”列表是最重要的部分。强迫自己写下这项功能不具备的五种特性。大多数规范的真正边界都在这里。
接下来是行为描述。用编号列表的形式,用通俗易懂的语言,就像在向一位从未用过该产品的聪明朋友解释一样。不要使用组件名称,不要使用设计术语,只需描述用户的操作以及发生的情况即可。
边界情况在第一次编写时是最难的部分。阅读你的行为列表,并在每一步都问自己“如果失败了怎么办”。
例如:数据为空、权限错误、网络速度慢。用户中途退出。将每一种情况都用一句话写下来。
成功标准和评估是将模糊的愿景转化为可衡量的目标的地方。“用户会喜欢它”不是一个成功标准。“保存率高于 30%”才是。选择三个你在评审中会认真考虑的数字。
最后是可访问性和文案。编写每个字符串,定义键盘路径,并指定 aria-labels。这一部分确保了清晰度,这是其他任何部分都无法做到的。
将文件保存在代码仓库中,而不是 Notion 目录下。在功能文件夹中将其命名为 spec.md。从现在开始,这就是源代码。
洞察: 位于代码仓库中的规范会随代码一起移动。位于 Notion 目录下的规范会在构建开始时立即失效。
设计系统的作用
规范驱动的设计只有在底层设计系统稳固的情况下才能奏效。规范描述意图,设计系统提供实现要素。如果系统混乱不堪,规范最终会将这种混乱带入每个功能中。
在 2026 年快速交付的团队会将他们的设计系统视为 AI 工具的公共 API。令牌的命名基于其用途,而非外观。组件具有文档化的属性、预期行为和可访问性契约。系统中的每个组件页面都像一个小型规范,包含意图、行为、边界情况和代码。
当规范引用组件时,它指向的是一份稳定的契约,而不是一张截图。“使用标准 Card 组件,高度级别为 2”就足够了。AI 工具会读取组件文档,规范会将其解读为约束条件,从而确保构建结果在不同功能之间保持一致。
如果你的设计系统仍然是一个充斥着未命名本地样式的 Figma 库,那么在完全采用规范优先之前,你还有很多功课要做。用简洁的英语编写组件文档。根据标记的含义命名它们。将系统本身视为你编写的第一份规范。
线框图仍然有用武之地
规范取代了大多数线框图。但并非所有线框图都会被规范取代。在某些情况下,低保真视觉效果仍然是正确的选择,而否认这一点只是为了标新立异。

以下三种情况线框图仍然有用武之地:
-
真正新颖的布局。 当你创造一种全新的空间模式,而设计系统尚未支持时,你需要绘制出来,因为光靠文字描述是不够的,空间构想需要空间草图来呈现。
-
核心版块和品牌驱动时刻。 在营销页面、产品发布页面和核心模块中,布局本身就是信息,因为规范无法传达“感觉很贵”的信息,而线框图至少可以在视觉设计师接手之前给出一些提示。
-
非产品部门的领导层协调。 如果你要向尚未采用规范驱动工作流程的高管团队进行演示,线框图仍然是通用语言,用作翻译工具而非主要成果。
以上就是三种情况。其他情况下,规范才是更好的选择,而线框图则是一种你应该放弃的习惯。
设计师的新作品集
作品集的问题紧随作品展示之后。如果说规范就是作品,那么作品集又该如何呈现呢?
2026 年最优秀的作品集以规范摘录而非屏幕模型为核心。一个包含意图段落、极端情况列表以及已发布功能截图的页面,比十张 Dribbble 作品集截图更能吸引招聘经理的眼球。
它展现了决策能力,展现了范围界定,也展现了候选人实际胜任工作的能力。
模型图库依然存在,但它是作品集的第二层级,而非第一层级。视觉效果展现的是品味,规范展现的是思维。你真正想加入的公司,其招聘经理筛选的正是思维能力。
迈向 2026 年的设计师应该围绕三到五个案例研究来重建他们的作品集,每个案例研究都以规范为核心,并以已发布成果作为结尾。不是 Figma 链接,而是已发布的成品。规范才是贯穿始终的主线。
初级设计师应该如何提升技能
目前初级设计师大致可以分为两类。一类把人工智能工具当作需要藏起来的作弊工具,另一类则将其视为新的专业技能。只有后者才能在五年后拥有稳定的职业发展。
提升技能的途径很简单。学习写作,但不是“学习如何撰写设计评审反馈”。而是学习撰写结构化的技术文档,就像产品经理撰写产品需求文档(PRD)或工程师撰写需求文档(RFC)那样。
阅读优秀的规范文档,模仿它们,并请一位资深人士帮你修改你的规范文档。
每天花一个小时在 Cursor 或 Claude Code 中查看你编写的规范文档,观察实际构建的内容以及与你的预期不符之处。每一个偏差都代表着规范文档中的一个漏洞。修补漏洞,然后继续运行。每天重复这个循环,持续三个月,就能彻底改变你对设计的思考方式。
不要再浪费时间在 Figma 插件的教程上了。开始花时间培养结构化思维,这种思维方式经得起每一次工具更迭。规范会一直存在,而像素级渲染则会过时。
洞察: 能够编写优秀规范的初级设计师比只会渲染像素的同行高出两个层级。这种差距每周都在扩大。
同时,还需要掌握两项相关的技能。首先,要学会阅读代码,以便能够审查 AI 工具根据你的规范构建的内容。你不需要编写生产环境代码,但你需要查看组件文件,并了解它是否符合你指定的行为。
其次,要学习评估。编写测试来验证“空状态渲染出正确的内容”现在是设计人员的职责,而不仅仅是工程师的职责。规范定义了正确性,评估则确保了正确性。能够编写规范和评估的设计师比只会渲染像素的设计师高出两个层级。
这对设计师意味着什么
像素级渲染现在是一项初级任务,它由工具自动化,并被模板商品化。这项工作已经提升到了更高的层级。现在的工作重点是意图设计、范围界定、边缘案例思考,以及撰写足够优秀的文档,以便人工智能工具能够根据你的文字描述生成功能。
这并非是对设计工作的降级,恰恰相反。如今,能够编写优秀规范的设计师比以往任何时候都更贴近产品策略,拥有比以往工作流程更大的影响力。
一个养成良好规范编写习惯的设计师就能完成过去一个四人团队才能完成的工作。产出差距是真实存在的,并且每周都在扩大。
本周的工作内容精简而具体。选择你正在开发的一个功能,编写规范,并使用七个部分。同时将其交给工程师和人工智能工具。
看看结果如何。与你使用线框图生成的内容进行比较。两者之间的差距,正是新旧工艺之间的差距。
线框图曾经非常有用,而规范现在才真正有用。开始编写下一份规范吧。
hero:
key: hero
prompt: "voxel illustration. A wireframe and a spec document side by side, with the spec glowing brighter. Soft pastel palette. Editorial. The composition does not include any human figures."
alt: "A wireframe and a design spec document side by side, the spec glowing brighter"
width: 1600
height: 900
inline-1:
key: spec-anatomy
prompt: "voxel illustration showing a spec document with labeled sections: intent, scope, behavior, edge cases, success criteria, evals. Soft pastel."
alt: "A spec document with labeled sections: intent, scope, behavior, edge cases, success criteria, evals"
width: 1400
height: 900
inline-2:
key: workflow-comparison
prompt: "voxel split illustration. Left: designer pushing pixels in figma forever. Right: designer writing a clear spec, AI tools building. Soft pastel. The composition does not include any human figures."
alt: "Split illustration comparing endless pixel pushing on the left to a clear spec driving AI tools on the right"
width: 1400
height: 900
inline-3:
key: spec-routing
prompt: "voxel illustration: a single spec document at the top, branching arrows down into Cursor, Claude Code, v0, Bolt, design system docs. Soft pastel. The composition does not include any human figures."
alt: "A single spec document at the top, branching arrows down into Cursor, Claude Code, v0, Bolt, design system docs"
width: 1400
height: 900
inline-4:
key: when-wireframes-still-work
prompt: "voxel illustration: a few preserved wireframes for novel layouts and hero sections, the rest fading into mist. Soft pastel. The composition does not include any human figures."
alt: "A few preserved wireframes for novel layouts and hero sections, the rest fading into mist"
width: 1400
height: 900
Want a design partner who ships specs that AI tools and engineers both read cleanly? Brainy writes them every day.
Get Started

