Aira UI 与前沿网站设计调研

• 状态：Research / Design Direction
• 日期：2026-09-01
• 文档版本：1.5
• 调研范围：当前 apps/web 产品工作台、AI 原生 CAD 竞品、工业隐式设计工具、2026 Web 平台能力与品牌官网方向
• 结论：Aira 不应被设计成“深色 CAD + 聊天框”，而应成为一个以画布为中心、以事务为交互骨架、以证据为差异化、以即时响应为底线的高性能可信建模工作台
• 实施文档：UI Workbench 技术实施计划
• 复用审计：UI 开源复用审计

1. 执行结论

Aira 的产品宪法已经给出了一套罕见且足够强的 UI 基础：人和 AI 走同一 typed Patch，修改必须经过 preview → validate → commit，Revision 可恢复，几何结果携带 certificate，拓扑歧义不能静默通过。 这些不只是后端约束，它们应该成为用户第一眼就能理解的产品体验。

当前界面已经证明浏览器内 Rust/WASM、Manifold、OCCT、Three.js、IndexedDB 和 AI task loop 可以协同工作，但视觉结构仍是“技术验证面板”：一个固定宽度左栏同时容纳参数、草图、Patch、历史、AI、 导入导出、测试 Gate 和证书。下一阶段不应只是换颜色或增加圆角，而应重构信息架构。

建议确定以下设计北极星：

Aira 是即时且可验证的设计协作空间。用户在画布中工作，人在界面里表达意图，AI 在隔离任务中提出修改， 内核判定事实；每次交互都立即反馈，每次变化都可预览、可解释、可恢复。

这会导出两套相互关联但不相同的界面：

1. 产品工作台强调画布、上下文操作、候选变更、版本和证据；
2. 品牌官网强调“意图如何变成可信几何”的连续故事，而不是列出技术名词和功能卡片。

2. 项目特性对 UI 的硬约束

以下结论来自 产品宪法、 长期架构计划 和当前实现：

项目特性	UI 必须表达什么	不应采用的常见模式
local-first 浏览器 CAD	本地状态、同步/离线状态、计算阶段和可取消性	把每次修改伪装成云端消息发送
极高交互性能	立即选择与操控、渐进预览、局部重建、明确的后台精确状态	每次鼠标操作都触发全模型精确重建，或用 loading spinner 掩盖主线程阻塞
AI、GUI、CLI 同一事务	人与 AI 产生同一种 diff、preview 和 Revision	AI 聊天拥有一条不可审计的旁路
Candidate 与 committed Revision 分离	当前看到的是草稿、候选还是已提交结果	只靠 toast 告知“已完成”
ExactSolid / MeshSolid / Field 类型显式	当前表示、精度、转换损失和可用操作	用同一种“模型”图标掩盖精度差异
SemanticRef 与 set-valued resolution	选中对象的来源、匹配理由、歧义候选	暴露 Face17 并静默重绑定
Geometry Certificate	结论、保证范围、失败项和原始证据	把哈希与内核字段全部常驻侧栏
Revision / branch / CAS	历史、比较、恢复和 AI task branch	线性撤销栈承担全部版本语义
Lane F 工业隐式	场值探针、缺陷区域、边界/分辨率和认证网格状态	只展示漂亮 lattice 渲染图

UI 的主要任务不是“隐藏复杂性”，而是把复杂性分层：默认显示用户需要做决定的结论，按需展开专业证据。

3. 当前界面审计

本次在真实本地应用中检查了 1280 × 720 桌面视口和 390 × 844 窄屏视口；源码入口为 App.tsx、styles.css（apps/web/src/styles.css） 和 ThreeViewport.tsx。

3.1 已经做对的部分

• 画布占主导面积。 3D 视口是产品中心，而不是结果缩略图。
• 关键系统状态真实可见。 顶栏有 local core 状态，底栏有 worker/cache/head 信息。
• Candidate 不会被伪装成已提交结果。 Patch diff 与 Validate/Commit 是显式步骤。
• 历史和证书已经进入产品面。 这为 Aira 的差异化设计提供了真实数据，不需先造假界面。
• 窄屏没有横向溢出。 当前 390 px 视口下页面宽度保持在可视范围内。

3.2 主要问题

问题	当前证据	用户影响
单栏承担过多职责	左栏包含约 40 个表单/按钮/区域；参数、Phase 1 Gate、Patch、历史、AI、证书共存	主任务不清晰，能力越多越难扩展
内部里程碑替代用户语言	M2、M3、AMIR transaction、Gate 大量出现在首屏	新用户看到工程状态，而不是建模目标
Candidate 模式不够强	目前主要由一张 Patch 卡和按钮表示	用户可能分不清正在查看 preview 还是 head
AI 仍像附加表单	textarea 下排列 gateway、Gate、cancel 和测试按钮	不能表达作用域、计划、阶段、受影响对象和审批
证据只“存在”，尚未“可读”	默认显示 assurance、profile、triangle、tolerance、hash	专家仍需自行解释是否可以继续、风险在哪里
选择反馈过薄	只显示 artifact id 与 triangle index	没有 feature 来源、SemanticRef、可执行命令和影响范围
响应式只改变顺序	390 × 844 时先显示约 58vh 画布，再进入 2330 px 长页面	可查看但不可高效建模；移动端应是 review 模式而非桌面表单纵向堆叠
键盘与焦点体系缺失	CSS 没有 :focus-visible；canvas 使用 outline: none 且没有键盘替代操作	不满足专业工具的键盘效率，也存在可访问性风险
状态栏小字对比不足	#687586 / #10161c 实测约 3.88:1，字号约 10 px	长时间使用和低视力场景下难读

WCAG 2.2 要求键盘焦点不被遮挡、状态消息可由辅助技术识别，AA 级目标尺寸通常至少为 24 × 24 CSS px；拖拽功能还应有单指针替代路径。参见 WCAG 2.2 和 Status Messages 指南。

4. 竞品与前沿范式

完整证据见竞品专题。

5. 建议的信息架构

5.1 桌面工作台

┌ Project / branch / head ───────────── Command search ─── Local / Sync / Share ┐
├──────┬──────────────────┬────────────────────────────────┬─────────────────────┤
│ rail │ Feature / Model  │                                │ Context Inspector   │
│ 48px │ context pane     │          3D / Field Canvas     │ properties / AI /   │
│      │ 260–320px        │                                │ diff / evidence     │
│      │ collapsible      │                                │ 320–400px, dockable │
├──────┴──────────────────┴────────────────────────────────┴─────────────────────┤
│ Transaction strip: Base → Proposed → Previewed → Validated → Committed        │
└───────────────────────────────────────────────────────────────────────────────┘

关键规则：

1. 左侧 rail 只切换 Model / Parameters / History / Assets / Diagnostics，不直接承载完整内容；
2. 左 context pane 和右 inspector 都可折叠，用户可获得纯画布模式；
3. 右 inspector 根据选择和任务切换，不同时展示属性、AI、证书和导出；
4. 底部 transaction strip 是 Aira 的独有骨架，显示当前 base、Candidate、检查进度和 commit 条件；
5. 命令搜索默认快捷键 Ctrl/Cmd + K，结果包含适用工具、最近命令、AI 意图模板与失败原因；
6. 所有 pane 使用 container query 适配自身宽度，而不是依赖一个全局 viewport breakpoint。

5.2 窄屏与触控

完整建模仍应 desktop-first；窄屏不应把桌面侧栏变成 2000 px 以上长表单。建议明确为 Review / Approve 模式：

• 画布占首屏，底部 sheet 在 Changes / Checks / Comment 三个视图间切换；
• 支持 orbit、选择、测量、切换 exploded/section/compare；
• 支持批准或拒绝 Candidate、查看关键失败和恢复 Revision；
• 复杂 sketch、feature authoring、certificate 原始证据和批量导出提示“在完整工作区打开”。

6. 四条核心交互流

6.1 人工精确修改

选择 face/feature
  → 上下文工具与参数出现
  → 输入带单位值
  → 画布 ghost preview + 受影响面高亮
  → transaction strip 显示语义 diff / checks
  → Validate & Commit

数值拖动时只做快速 preview；松手或停止输入后再运行较重检查。旧结果必须携带 Revision 标识，不能覆盖新输入。

6.2 AI 修改

AI composer 不是空白聊天框，而是带结构化上下文的任务入口：

• Scope：当前选择 / 当前 body / 整个 part；
• Base：具体 Revision；
• Constraints：单位、保留对象、制造要求、预算；
• Output：edit / alternatives / explain / inspect；
• Approval：preview only / low-risk auto-commit policy。

提交后形成 task card：Reading → Planning → Proposing → Rebuilding → Checking → Ready for review。 用户可 steer/cancel；完成后默认打开 semantic diff 与 before/after overlay，而不是先展示一段成功文案。

6.3 历史比较与恢复

• 轻量历史：按用户意图显示“Hole radius 6 → 7.5 mm”，哈希作为次级信息；
• Compare 模式：旧版本红、候选蓝、共同区域中性，可切换 isolate/flicker/section；
• 恢复按钮文案使用“Restore as new revision”，并预览即将生成的反向 Patch；
• AI task branch、失败 Candidate 和已发布 head 使用不同节点形状。

6.4 证据与诊断

证书采用三层披露：

1. 结论层：Verified / Draft / Blocked / Unknown，一句话说明能否 commit/export；
2. 检查层：Geometry、References、Units、Manufacturing、Exchange 等组，显示 pass/fail/unknown；
3. 证据层：checker、kernel、tolerance、metrics、hash、receipt 和下载。

只有失败或 unknown 默认展开。成功项保持可访问但不与当前模型争夺注意力。

7. 视觉语言建议

7.1 品牌气质

关键词：精确、克制、可验证、空间感、工程可信。避免把 AI 表现成霓虹魔法或不受控粒子；避免大面积 “液态玻璃”让工业数据显得轻浮。半透明只用于画布上的临时浮层，结构面板保持清晰实体背景。

7.2 颜色角色

建议从“功能卡片各自一色”改为有限的语义色：

角色	建议色相	用途
Neutral	Zinc / graphite	画布、面板、结构与未激活状态
Human / selection	Cyan-blue	人工选择、直接操作、当前参数
AI / delegated task	Violet	AI scope、task branch、模型建议
Candidate / warning	Amber	未提交变化、需要决定的风险
Verified	Mint-green	已通过的权威结论，不用于普通按钮
Failure / destructive	Coral-red	检查失败、删除、不可逆影响
Unknown	Cool gray + pattern	未知/不适用，不能与 pass 共用绿色

色彩不能作为唯一编码；状态同时使用图标、形状和文字。正文与小字目标至少满足 WCAG AA 对比度，焦点使用 2 px 以上高对比 outline。支持 light/dark 两套主题；工程工作台默认 dark，打印、文档和长证据阅读优先 light。

7.3 字体与密度

• UI：继续使用 Inter Variable 或同类中性 variable sans；
• 数值/哈希/单位：使用易区分 0/O、1/l 的等宽字体；
• 数字启用 tabular numerals，单位不做全大写；
• 提供 Comfortable / Compact 两档密度，而不是用 10 px 字体换取空间；
• 面板正文不低于 12–13 px，状态栏不低于 11–12 px。

7.4 动效

动效只解释状态变化：

• 150–220 ms 的 pane、popover 和 selection 过渡；
• Candidate/Head 切换使用几何 morph、ghost 或局部高亮；
• 长任务用阶段进度与可取消反馈，不用无限 shimmer；
• 官网可使用 scroll-linked 模型剖切/分解，但工作台不使用滚动叙事；
• 必须尊重 prefers-reduced-motion。

8. 品牌官网方向

8.1 网站叙事

首页不要以“AI CAD 平台”的抽象标题开场，应直接展示 Aira 独特闭环：

1. Hero：一句价值主张 + 一个真实可操作模型 文案方向：从设计意图到可验证几何。 用户修改一个参数或发出一个有界 AI 指令，模型显示 Candidate，高亮 diff，再出现 Verified。
2. 五步滚动故事 Intent → Typed Patch → Preview → Verify → Commit；滚动驱动同一个模型，而不是五张独立功能卡。
3. 两条产品能力 Exact mechanical CAD 与 industrial implicit/lattice，明确各自 representation 和出口。
4. Trust stack Revision、SemanticRef、Certificate、local-first 以可视证据解释，不堆协议名。
5. 真实证据 展示可复现 Gate、浏览器执行、失败样例和 version binding；避免只放“99.9% accurate”。
6. 开放技术入口 Open demo、Read architecture、Inspect evidence 三类 CTA 对应产品、技术和审计用户。

8.2 页面视觉

推荐“精密工程编辑出版物”而不是常规 SaaS bento：

• 大留白与精密网格交替；
• 黑/石墨产品画布嵌入暖白或浅灰文档页面；
• 极少量蓝紫渐变用于 AI task 路径，不作为全页背景；
• 特写对象使用截面、等值线、拓扑 lineage 和差异叠层，而不是无意义漂浮 3D 球体；
• bento grid 只用于证据摘要或多表示矩阵，不成为所有区块的默认容器。

8.3 前沿 Web 能力的使用边界

• CSS scroll-driven animations 可把官网模型剖切、爆炸和 certificate 进度绑定到滚动，且比主线程 scroll listener 更适合性能稳定的叙事；参见 MDN Scroll-driven Animations。
• View Transition API 已进入 Baseline 2025，可用于案例、文档和产品入口间保持视觉上下文；参见 MDN View Transition API。
• CSS Anchor Positioning 可逐步增强 selection popover 与注释，但部分能力仍需 fallback；参见 MDN CSS Anchor Positioning。
• WebGPU 适合 Field 可视化和后续 GPU compute，但目前仍是 limited availability；产品与官网必须保留 WebGL/静态 poster/video fallback。参见 MDN WebGPU。
• 容器查询已广泛可用，适合 dockable pane 自适应；参见 MDN Container Queries。

前沿不等于堆 API。官网性能目标仍应以真实用户数据为准：75 分位的 LCP ≤ 2.5 s、INP ≤ 200 ms、 CLS ≤ 0.1。3D hero 首屏先显示轻量 poster，交互 runtime 在首屏文案稳定后按需加载。阈值来源： web.dev Core Web Vitals。

9. 建议优先级

P0：先修信息架构，不做纯换肤

1. 将当前左栏拆为 rail、context pane、canvas、inspector、transaction strip；
2. 把 M2/M3/Gate 测试入口移入开发者工具，不出现在默认产品界面；
3. 建立 Candidate / Validating / Committed 三种明确的全局模式；
4. 增加 :focus-visible、状态 live region、键盘命令入口和对比度 token；
5. 把证书改成“结论 → 检查 → 原始证据”三层；
6. 将 390–760 px 定义为 review/approve 布局，不再纵向复制完整桌面表单。

P1：形成 Aira 独有交互

1. selection-driven adaptive tools；
2. AI task branch + scope chips + structured plan/diff；
3. Revision compare 与几何 before/after overlay；
4. SemanticRef 匹配理由与歧义候选面板；
5. Field probe、contour、defect overlay 与 certificate 状态。

P2：品牌官网与设计系统

1. 提取 token、primitive、panel/dock、status、diff、evidence 组件；
2. 建立产品 shell 的 dark/light 与 comfortable/compact 组合；
3. 制作一个可真实运行的 hero mini-demo，复用 production transaction path；
4. 用一个模型串起官网五步叙事，准备无 WebGL 与 reduced-motion fallback；
5. 以 Core Web Vitals、键盘覆盖率、任务完成时间和错误恢复率作为发布 Gate。

P3：垂直切片完成后再做性能工程

1. 锁定工作负载向量、参考 corpus、设备档和 cold/warm cache 条件；
2. 一次性建立 input、pick、scope、Patch、dirty analysis、kernel、transfer、GPU upload、validate 的 trace；
3. 先采基线，再按耗时占比和用户频率确定优化顺序；
4. 将已验证的 dirty-subgraph、early cutoff、latest-wins cancel 和分层 cache 接入 production transaction path；
5. 优化稳定后才冻结分层 SLO 和 CI 回归 Gate，不把研发早期噪声固化成架构目标。

Worktree 协作边界

UI 可以在独立 worktree 开发，建议从已确认的 main commit 创建 codex/ui-workbench，并采用以下文件所有权：

• UI worktree 主要拥有 apps/web/src 下的新 UI components、layout、tokens、styles、fixtures 和交互测试；
• 主线继续拥有 crates、packages/aira-contracts、生成文件、AMIR Schema、geometry/core transaction 语义；
• UI 通过窄 WorkbenchViewModel / adapter 使用主线能力，避免在大型 App.tsx 中直接复制核心状态机；
• UI 如果发现必须扩展 contract，先提交一个独立、最小的接口变更到主线，UI worktree 更新基线后再使用；
• pnpm-lock.yaml、生成文件和共享入口只由明确的一次集成修改，避免两个分支同时机械重写；
• 定期把 main 合入或 rebase 到 UI 分支；最终按“tokens/primitives → shell/layout → feature flows”的小提交顺序集成， 不以一个巨型 UI commit 一次性覆盖主线。

具体的状态所有权、阶段 Gate、依赖进入顺序与高冲突文件见 UI Workbench 技术实施计划。

10. 设计验收指标

目标	可验证指标
画布优先	默认工作区中画布占可用面积 ≥ 60%；辅助 pane 可折叠
修改可理解	用户在 5 秒内能辨认 Head、Candidate 与 blocked 状态
AI 可控	每个 AI 任务都显示 base Revision、scope、阶段、Patch、checks 与取消入口
证据可读	非内核用户能从第一层判断是否可 commit/export；专家可在两次交互内到原始 receipt
历史可恢复	任一 Revision 可在一次主操作中发起 restore-as-new-revision，并在提交前预览
键盘效率	所有非空间绘制命令可通过命令搜索或快捷键触达；无键盘陷阱
可访问性	WCAG 2.2 AA；状态消息可感知；目标尺寸、对比度、焦点和 reduced motion 有自动检查
前期性能纪律	U0/U1 不设置毫秒 Gate；不进行无 profile 依据的组件重写；主线程无同步几何、任务可取消、旧结果不可发布
基线完整性	垂直切片稳定后，operation × representation × quality × complexity × cache × device 矩阵具有可复现数据
后期性能治理	P1 优化后才冻结各矩阵单元的 T_ack / T_firstUseful / T_authoritative 与回归比例，并进入 CI
官网性能	p75 LCP ≤ 2.5 s、INP ≤ 200 ms、CLS ≤ 0.1；3D 不阻塞首屏内容

11. 最终裁决

Aira 的 UI 差异化不应来自更炫的 3D 材质或更像聊天应用，而应来自一个其他 CAD 很少完整呈现、并且足够快到 让用户保持思维连续性的闭环：

意图可见
  → 交互立即反馈
  → 修改有边界
  → Candidate 与 Head 可区分
  → 几何和语义差异可比较
  → 证据决定能否提交
  → Revision 永远可恢复

工作台以这一闭环组织界面，官网以同一闭环组织叙事，并把性能预算作为与 Schema、Patch 和 Certificate 同等级的 产品契约。这样 Aira 才能让产品宪法变成用户可感知的品牌，而不是只存在于 README 和 RFC 中的工程优势。