第 07 期 · 未来设计 · 2026-11-05
文 / 文谦（主视角：企业家 ｜ 副视角：茶产业发展专家，跨行业借镜：交付链）
本文含少量上市公司与融资信息，仅供技术讨论，不构成投资建议。
一个先摆出来的矛盾
同一周，两组数字：
- Figma 2026 Q2 营收 3.701 亿美元、同比 +48%，NDR 136%，毛利率 84%（财报口径，第三方汇总）。10 月它把设计 Agent 推到 GA，开始按 AI credits 收钱，同时上线 Specs。
- Canva 宣布 13 年来首次裁员，1,271 人、占 22%；月活同比少 1,200 万，营收增速指引从 30% 下调到 20%（《澳大利亚金融评论报》，经新浪财经转述，2026-11-04）。
两家的模型能力差别没有这么大。差别在产物。
Canva 的产物是一张图，图的下游是「发出去」，到此结束。Figma 的产物是一个可以继续被引用的场景，下游是开发、是代码、是下一个季度还在用的组件库。
所以这一期我想从工程角度问一个问题，而不是从市场角度：
一份设计文件，要满足什么条件，才能被下游的机器直接消费，而不需要人再翻译一遍？
我把这件事叫交付半径：不需要重画、重审、重写的前提下，这份产出能走多远。
1. 现有链路的断点在哪
把今天的设计→开发链路画出来，断点非常固定：
brief ──> 设计稿 ──> 标注 ──> 代码 ──> 上线
│ │ │
│ │ └─ 组件库漂移：agent 优先复用仓库里的废弃组件
│ └─ 标注是"人写的散文"，不可执行、不可 diff
└─ 决定（为什么用 8px、为什么这个红）只存在于人的脑子与会议纪要
三个断点，各自对应一类技术问题：
| 断点 | 现象 | 工程本质 |
|---|---|---|
| 决定丢失 | 换个人接手就重做一版 | 决策没有结构化载体，只有图像载体 |
| 标注不可执行 | 前端按标注手写，写出来和设计不一致 | 约束是自然语言，没有 lint 与类型 |
| 组件漂移 | agent 生成看似合理、但用了废弃 API | 仓库里没有权威事实源，模型只能就近猜 |
Figma 的 Specs、Google 的 DESIGN.md、Uiverse 的三层 token，本质上都在干同一件事：给这三个断点各补一个可执行载体。
2. 范式：从「生成」到「生成 + 验证 + 追认」
这两年的设计 AI 产品，架构上其实只有两代。
第一代：prompt → artifact
prompt ──> [model] ──> image / screen / code
一次调用，一次产物，无状态。优点是简单，缺点是：不可回归、不可追责、不可复用。这一代已经被压到接近免费——Google Stitch 免费额度是 Rapid 模式 350 次/月、Experimental 模式 250 次/月，且不可提额（Google 官方论坛口径，2026-10）。
第二代：brief → constraint → generate → validate → attest
brief
│
├─> constraint layer（tokens / DESIGN.md / spec entries）
│ │
│ └─> [generator] ──> artifact
│ │
├─> validate（lint / type / rule engine）──┤
│ │
└─> attest（provenance / signature / trace）──> 交付
关键差别不在 generator，在两侧的 constraint 与 validate/attest。模型是可以换的，约束和追认不能换。
这也是我判断「未来设计」这条赛道的核心：真正的产品不在中间那一格，在两头的护栏里。
3. 规格层怎么落地：三个可直接抄的实现
3.1 DESIGN.md：把设计系统写成可 diff 的约束
DESIGN.md 不是一个「文档」，它是一个编译目标。它同时要满足两个消费者：人和 agent。
Google 2026-03-18 在 Stitch 里提出这个概念，2026-04-21 开源草案规范，2026-10-01 发布 CLI（npm @google/stitch），可以在终端生成界面、把本地 dev server 快照回 Stitch。
结构上我建议分两段，缺一不可：
---
version: 3
tokens:
color.action.primary: "#2563EB" # alias 层，禁止直接引用 global
color.bg.canvas: "#F8FAFC"
space.unit: 8
radius.card: 12
motion.enter: 180ms
typography:
heading: { family: Inter, weight: 600, size: 24, lh: 1.3 }
body: { family: Inter, weight: 400, size: 14, lh: 1.6 }
---
## WHY（给模型的自由度边界）
- primary 只用于「主要动作」，不用于装饰。页面内最多一个 primary 按钮。
- 卡片不用投影，用 1px 边框；阴影只留给浮层。
- 信息密度优先于留白：桌面端内容区最小宽度 720px。
## DON'T
1. 不要引入未登记的颜色，即使视觉上更协调。
2. 不要用 12px 以下的正文。
3. 不要给按钮加渐变。
4. 不要在暗色模式下把 primary 反相成浅色。
5. 不要复用已标记 deprecated 的组件。
两个坑，都是实际踩过的：
坑一：只有 WHAT 没有 WHY。 只有 hex 值时，agent 遇到未定义场景（空状态、错误页）会自由发挥，而自由发挥正是「AI 味」的来源。WHY 段是给模型的兜底策略，不是给人看的抒情。
坑二：单层 token 直接给模型。 必须做三层——global（原始值）→ alias（语义）→ component（组件级）。模型拿到 #2563EB 不知道什么时候用，拿到 color.action.primary 才知道语义。Uiverse 的三层架构就是这个思路。
3.2 把约束接进 CI：让 agent 的错变成编译错误
这是我认为最关键的一步。文档写不住的东西，lint 写得住。
// design-lint.ts —— 示意，非某产品源码
import { parseDESIGN } from "./design-md";
import { scanUsage } from "./ast-scan";
const spec = parseDESIGN("DESIGN.md");
export function lintDesign(files: string[]) {
const issues: Issue[] = [];
for (const f of files) {
for (const u of scanUsage(f)) {
// 1) 未登记的色值
if (u.kind === "color" && !spec.hasToken(u.value)) {
issues.push({
file: f, line: u.line, level: "error",
code: "DESIGN001",
msg: `未登记颜色 ${u.value}。可用：${spec.suggest(u.role)}`,
fix: spec.suggest(u.role), // 直接给可执行的修复值
});
}
// 2) 语义误用：primary 用在非主操作上
if (u.kind === "token" && u.token === "color.action.primary") {
const primaryCount = countPrimaryInView(f, u.viewId);
if (primaryCount > 1) {
issues.push({
file: f, line: u.line, level: "error",
code: "DESIGN014",
msg: `同一视图出现 ${primaryCount} 个 primary，规则上限 1`,
fix: "改用 color.action.secondary",
});
}
}
// 3) 废弃组件
if (u.kind === "component" && spec.isDeprecated(u.name)) {
issues.push({
file: f, line: u.line, level: "error",
code: "DESIGN021",
msg: `${u.name} 已废弃，替代：${spec.replacement(u.name)}`,
fix: spec.replacement(u.name),
});
}
}
}
return issues;
}
这里有个设计要点：每条错误必须带 fix 字段。因为你的消费者不是人，是 agent——它需要的是「下一步改什么」，而不是「你错了」。Uiverse 的做法就是把 lint 报错直接当修复指令喂回去，这个闭环成立，一致性才有保证。
3.3 上下文预算：为什么 Once UI 要压到 10KB
Once UI 2.0 的公开说法是「每个任务的上下文控制在约 10KB」，靠的是规则文件（约 2KB）+ 机器可读组件目录 + 任务包 + 组件级 JSON 切片，而不是把整本站文档塞进去。
这条工程约束值得所有做 agent 工具的人抄：
全量上下文成本 = O(文档规模)
切片上下文成本 = O(任务相关子图)
后者才是可扩展的。伪代码：
def build_context(task, catalog, rules, budget=10_000):
ctx = [rules] # ~2KB，永远带
for comp in rank_by_intent(task, catalog): # 按意图排序
if tokens(ctx) + tokens(comp.slice) > budget:
break
ctx.append(comp.slice)
return "\n\n".join(ctx)
rank_by_intent 是关键：把「定价页」「仪表盘」这类意图映射到组件子集，而不是靠向量检索碰运气。检索会召回语义相近但结构不对的组件，这是 agent 生成「看起来对、用起来错」的常见来源。
4. 追认层：审图是这条链路里最硬的一环
规格层解决「下游能不能吃」，追认层解决「吃下去谁负责」。这一层在中国有一个很好的样本。
新疆 BIM 施工图智能审查系统，2026-07-01 上线试运行，全疆 21 家审图机构 100% 接入；「AI 初筛 + 人工复核」使人工复核工作量平均降约 28%、漏审率降约 70%；系统解析 2,000 余项行业标准、5,000 余条条文，覆盖五专业 + 消防/节能专项 500 余条重点规则（兵团在线，2026-11-03）。
从架构看，它做对了三件事：
第一，把规则变成可执行的条文对象，而不是检索。
{
"rule_id": "GB50016-5.5.17-a",
"source": "GB 50016-2014(2018版)",
"version": "2018",
"scope": ["building", "fire"],
"predicate": {
"type": "clearance_min",
"subject": "door.swing.direction",
"against": "occupant_load",
"threshold": "inward_forbidden_when_occupant>50"
},
"evidence_path": ["model.storey[2].door[17]", "schedule.fire_exit[3]"],
"severity": "mandatory"
}
要点是 predicate 可计算、evidence_path 可回溯。这比让模型「读规范然后判断」可靠一个数量级——规则引擎负责确定性，模型只负责把非结构化图面映射到结构化对象。
第二，二三维联动定位。 平面点选一处，模型对应构件亮起。这不是 UI 花活，是降低复核成本的核心：审查者的时间不是花在发现问题，是花在确认问题。
第三，意见可追溯到条文。 每条 output 都带 rule_id，这使「AI 说错了」可以被审计，而不是变成一个黑箱争议。
同样的思路，构力科技 PKPM Agent 2.0 用的是另一条路：把大模型接到跑了几十年的 PKPM 求解器上，产品定义里写了「AI 内容经审核、操作留痕、可回撤」（搜狐「智汇苏建」，2026）。「可回撤」是一个工程承诺，不是一个功能——它要求每一步操作都有 inverse operation，这对系统设计的要求远高于「生成一份报告」。
5. 可测指标：怎么判断一个设计 AI 产品是不是真的有用
我不太信「效率提升 X 倍」这类说法。下面是我认为可以测、且能横向比的六个指标。
| 指标 | 定义 | 采集方式 | 参考阈值（我的判断） |
|---|---|---|---|
| 返工率 | 交付后下游因「不可用」而非「不喜欢」而修改的次数 / 总修改次数 | 版本 diff + 修改理由标签 | < 30% 才算进入规格层 |
| 规格覆盖率 | 被 Spec/DESIGN.md 明确覆盖的界面决策数 / 总决策数 | 设计系统审计脚本 | > 70% 才能喂 agent |
| 漂移率 | agent 生成代码中偏离 token 的比例 | lint 命中数 / 总样式声明数 | < 5% 可上生产 |
| 一次通过率 | 生成产物无需人工修改即可进入下一环节的比例 | 流水线埋点 | 现在是瓶颈，普遍 < 40% |
| 上下文效率 | 完成任务所需 token / 产物行数 | 调用日志 | 越低越好，> 10KB/任务 需优化 |
| 追认成本 | 从产物完成到有人签字的人时 | 工单系统 | 这是 L4 的真正 KPI |
其中第一个最容易被忽略。团队普遍在测「生成速度」，但真正决定价值的是下游返工。Figma 2026 产品设计 AI 报告的裂缝就在这儿：78% 认为提效，只有 58% 认为提质，仅 32% 敢依赖 AI 输出；设计师比开发者更悲观（40% vs 68% 认为质量提升）——样本 2,500 人，全球。
换句话说：速度指标已经饱和，质量指标还在原地。
6. 六个工程易错点（都是踩过的坑）
1. 把非确定性当 bug 修。 Stitch 的同一提示词多次运行结果不同，这是特性不是缺陷。工程上的正确做法是：把「可复现」放在 spec 层（版本化的 DESIGN.md），而不是放在生成层（seed 锁定只能解决一部分）。
2. 用向量检索喂设计上下文。 会召回语义相近但结构不对的组件。用「意图 → 组件子图」的显式映射，比 embedding 靠谱。
3. BIM/IFC 的坐标与单位。 IFC 里长度单位、坐标系、楼层基准不统一，跨工具往返一次就可能偏几厘米。Drafted 能导出 DXF/IFC/Revit，这类互操作的测试成本远高于生成成本——导出格式不是功能，是兼容性债务。
4. 条文映射的版本化。 规范一改，规则库就要重标。新疆系统的 2,000 余项标准、5,000 余条条文不是一次性资产，是持续负债。设计时就要给 rule.version 留位置，否则两年后整套重做。
5. credits 计费反噬使用深度。 Figma GA 起按 AI credits 计量。任何按次计费的设计 AI，都会诱导用户「少试几次」——而设计的价值恰恰来自多方向探索。这是产品设计与计费模型的冲突，不是技术问题。
6. 输出里没有 provenance。 中国司法侧已经把「过程留痕」变成胜负手：北京互联网法院「猫咪晶钻吊坠」案支持确权，靠的是提示词、迭代、草图、选择记录；同年「蝴蝶椅案」中设计师拿不出原始生成记录、且自认无法复现，著作权主张未获支持（法治网，2026-10-22）。欧盟《人工智能法案》相关条款 2026 年起适用，强制内容溯源标注与训练数据披露，特定违规最高罚 1,500 万欧元或全球营业额 3%。留痕不是合规附件，是产品的一部分。
7. 六维分析
7.1 Figma Specs（规格层 / 平台）
- 应用场景：评审结束到开发动工之间。把会议纪要、Slack、评论里的决定变成可引用条目，经 MCP 供编码 agent 读取。
- 技术可行性：高。不需要更强模型，需要把组件、变量、代码层、图表结构化。20 个 MCP 合作方（OpenCode、Dia、JetBrains Junie、Meta Muse 等）已接入。
- 目标用户画像：设计系统成熟的中大型团队（Uber 跨 7 个平台）；ARR > $10K 客户 15,964 家；决策链设计系统负责人 → 设计 VP → 采购。
- 商业前景：按 credits 计费已跑通，但 Agent 的采用率、收入、成本均未披露。第三方示意：1.6 万大客户 × 25% × 2.5 万美元 ≈ 1 亿美元年化（情景，非预测）。
- 竞争优势：决定发生的地方就是数据产生的地方。越成熟的设计系统越难迁走。
- 潜在风险：credits 抑制探索；Specs 仍在 beta，若被当成文档而非资产，会退化成高级注释。
7.2 新疆 BIM 审图（追认层 / 制度）
- 应用场景：施工图报审。AI 初筛强条、人复核关键部位、自动出报告。
- 技术可行性：已验证，但依赖三件事同时成立——规则明确、模型规范、制度强制。缺一条就退化成查错清单。
- 目标用户画像：21 家审图机构（财政付费）、设计单位、施工企业。付费方不是市场，确定性高、天花板低。
- 商业前景：省人工复核工时（28%）与漏审风险（70% 降幅）。模式是项目制 + 运维，难做成 SaaS 复利，但一省跑通后可向其他省复制。
- 竞争优势：标准库与条文映射（2,000+ 标准、5,000+ 条文、500+ 重点规则）与政府系统对接。不是模型能力，是脏活。
- 潜在风险：责任归属未清，人工减不掉只能少做重复；规则库维护是长期成本。
7.3 Rayon（垂直层 / 工作流）
- 应用场景：室内设计师从概念到施工图到材料清单；图纸与规格表同源，改图则清单联动。
- 技术可行性：浏览器 CAD + 实时协同 + DWG 导入，工程难点在几何内核与多人冲突合并，不在 AI。
- 目标用户画像：室内/体验空间设计事务所（维珍航空休息室、CityHub、Coloc Housing）；35 人团队服务专业客户，说明单客价值高。
- 商业前景：€10M A 轮、累计约 €16M，订阅制；客户自述 CityHub 每月省 1 万欧元、Coloc 可行性研究成本每月降 1.1 万欧元。
- 竞争优势：职业专属工作流 + 组件库沉淀。通用工具要赢的是工作流，不是效果图。
- 潜在风险：3D 与 agentic AI 要到 2026 年底才上；若延期，叙事会先于产品透支。
7.4 简版六维（四家）
- Drafted：自建房业主与建筑师前期比选；语言/草图 → 带尺寸平面，导出 DXF/IFC/Revit；12 万用户/月生成 32.5 万套（公司口径）；$16M 种子轮；护城河在格式互操作；风险是变现未定义、方案图到报建图是鸿沟。
- DESIGN.md 生态：独立开发者与小型团队；格式免费（Google 开源），钱在组件库、治理工具与服务；护城河是生态位而非格式；风险是碎片化与 trade dress。
- Spacely AI：事务所渲染与虚拟摆场；嵌在 SketchUp 里；50 多国 1,500 家事务所；仅 $1M 种子轮；护城河是分发位置；风险是渲染层被通用模型拉平。
- Meshy：游戏/电商资产、3D 打印；文/图生 3D + 移动端；1,500 万注册；1.5B 估值；护城河是纹理质量与数据飞轮；风险是它自己已在转向游戏与实时交互。
两个概念阶段（仅记）：过程留痕凭证包（确权材料自动打包）、变更下游账单（改一个参数算出哪些图/清单/报价要重签）。前者等合同模板改，后者等计费方式改。
8. Top 3（与其余三平台一致）
① Figma Specs。 技术上它是「把决策变成可寻址对象」，商业上它是「第一个为规格单独收钱的平台」。工程师该关注的是它的 MCP 接口形态——如果 Specs 变成事实标准，你的设计系统会以「被 agent 读取」的方式存在，而不是以「被设计师打开」的方式存在。
② 新疆 BIM 审图 / 构力 PKPM Agent 2.0。 它是「规则引擎 + 模型 + 人」这个三元结构唯一跑到全覆盖的样本。可抄的部分不是模型，是 rule_id + evidence_path 这套可审计输出格式，以及「可回撤」这个工程承诺。
③ Rayon。 它证明垂直工作流还能收钱：图纸与规格表同源，是把「一致性」做进数据结构，而不是做进提示词。这是最朴素也最难被复制的架构选择。
9. 三个可以立刻动手的动作
-
今天就把 DESIGN.md 写出来，哪怕只有 40 行。 先写 8 个 token + 5 条 DON'T，跑一遍 agent，记录它在哪一屏开始违规。违规点就是你的规格缺口清单。
-
给 lint 加
fix字段。 没有修复建议的报错，对 agent 等于噪音。这是从「人工检查」升级到「自动收敛」的唯一开关。 -
给每个产物存 provenance。 提示词、参数、版本 diff、素材来源，落到一个可导出的 JSON。别等到需要证明「这是我做的」那天才想起来。
设计工具的下一站不是「更会画」，是「更会交代」。
能交代清楚的东西，才走得远。
AI 参与声明：本文使用 AI 辅助检索与资料整理，代码为示意实现，事实核验与判断由作者完成。
免责声明：文中涉及上市公司与融资信息，仅供技术讨论，不构成投资建议。
