企业官网建设流程全解析

• 人工智能
• AI Agent
• 自主智能体
• 桌面应用
• MCP Clients

导读

Kun 的 Design 模式长期存在两份职责重叠的项目级设计契约：.kun-design/design-system.json（结构化项目主题，驱动内置设计系统看板）与.kun-design/DESIGN.md（Kun/Stitch 风格的手递交付文档，但并非 Google 发布的 DESIGN.md 格式）。本文基于仓库中的 OpenSpec 变更设计文档 openspec/changes/support-google-design-md/design.md 及其配套的 proposal.md、两份能力规格（google-design-md-source/spec.md 与 design-md-theme-board/spec.md），完整讲解 Kun 如何采纳 Google 发布的 alpha DESIGN.md 规范：让工作区根目录DESIGN.md成为唯一公开主题契约，同时保留 Kun 原生画布组件树的内部编辑状态。读完本文，你将掌握该方案的文件角色划分、适配器封装、解析校验与冲突安全编辑机制、确定性白板试样、Save/Save & Apply语义、Agent 工具链路以及旧数据迁移路径，并能对照仓库源码理解每一处设计决策的落点。

一、背景：两份重叠契约引发的双重真源问题

1.1 旧方案的痛点

在引入本变更之前，Kun 的项目级设计系统存在两份功能部分重叠、格式却互不兼容的契约：

• .kun-design/design-system.json：作为结构化项目主题被文件监听（watcher）持续跟踪，驱动内置的设计系统看板（design-system board）；
• .kun-design/DESIGN.md：由 Kun 生成、采用 Stitch 风格的「表格 + 散文」手递交付文档，但其结构并不符合 Google 发布的 DESIGN.md schema。

此外，每个 HTML/SVG 产物还可以拥有各自的嵌套DESIGN.md（屏幕级实现笔记），每个 DesignDocument 内部则持久化着包含 Kun 画布组件树（canvas component trees）的富design-system.json。Google alpha DESIGN.md schema 能够表达语义化组件 token，却无法表达这些编辑器专属的 shape 树、slot、variant 覆盖或画布身份。

其结果正如 proposal.md 所述：两份竞争的真源（competing sources of truth）并存，由 Stitch 或其他编码 Agent 创建的 DESIGN.md 无法自动出现在 Design 白板上。

1.2 Google 发布格式的本质

Google 已发布的 alpha DESIGN.md 规范定义了一个工作区根级DESIGN.md文件，其结构为：

• YAML front matter：承载规范性的设计 token（normative tokens）；
• 有序 Markdown 小节：承载设计 rationale（设计理由）。

alpha schema 允许任意颜色与字体 token 名称、token 引用（token references）、组件属性定义以及未知的扩展内容；其 linter 还会报告结构（structural）、引用（reference）、对比度（contrast）与小节顺序（section-order）层面的发现项（findings）。

本变更横跨渲染器持久化、白板渲染、工具协议、提示词、代码手递、迁移与包依赖，因此设计文档特别强调：实现必须保留无关的工作区内容、经受住原子编辑器保存，并避免把用户手写的 Markdown 变成可执行的 HTML。

二、目标与非目标

2.1 目标

• 让根目录DESIGN.md成为项目主题的唯一公开真源；
• 接受 Google Stitch 生成的文件，并符合已发布的 alpha schema；
• 直接基于 token 渲染一个确定性的、有用的主题试样（theme specimen），无需 Agent 额外绘制 HTML/SVG 风格套件产物；
• 提供带校验、冲突检测、Save与Save & Apply的安全主题与原始 DESIGN.md 编辑；
• 让同一份解析后的契约同时驱动生成、校验、实现与导出路径；
• 将 Kun 特有的富组件树作为内部编辑器状态保留，且不被 sidecar 覆盖 DESIGN.md；
• 无数据损失地迁移旧版项目 JSON，并消歧现有的 Kun 手递路径。

2.2 非目标

• 像素级复制 Google Stitch 的界面外观或使用 Google 专有素材；
• 执行 DESIGN.md 中的 Markdown HTML、加载远程字体或求值任意 CSS；
• 按下Save & Apply时重写任意已有 HTML/SVG 产物；
• 在本变更中移除嵌套产物 DESIGN.md 实现笔记；
• 自动实现 alpha 规范的每一个未来修订；
• 用 Google 语义组件 token 映射替代 Kun 原生画布组件树/variant 模型。

三、文件角色划分：谁才是「真源」

决策 1（Root DESIGN.md is canonical）给出了清晰的路径职责表。关键落点见源码常量 src/renderer/src/design/design-md/design-md-paths.ts：

其余嵌套产物文件（如.kun-design/<document>/<artifact>/DESIGN.md）继续作为实现笔记存在，并被排除在项目主题发现之外。该设计避免了路径启发式猜测，并给 Agent 一条无歧义的指令：先读根DESIGN.md。

设计文档明确记录了被否决的备选方案：继续以.kun-design/DESIGN.md为真源。否决理由：Google 工具链、编码 Agent 以及用户请求的工作目录发现机制都期望工作区根目录。

四、把 Google alpha 契约钉在 Kun 适配器之后

4.1 为什么需要适配器

决策 2（Pin the Google alpha contract behind a Kun adapter）要求新增一个design-md适配器，由其独占与已钉死版本的官方@google/design.md程序化 linter/schema 的交互；Kun 其余部分只消费一个稳定的内部模型。仓库中该适配器位于 src/renderer/src/design/design-md/design-md-adapter.ts，官方 lint 调用封装在 src/main/services/project-design-md-lint.ts，后者直接import { lint } from '@google/design.md/linter'并将 findings、designSystem 的 colors/typography/rounded/spacing 与 sections 归一化后回传渲染器。

钉死版本的依据：package.json中固定了"@google/design.md": "0.3.0"，且 design-md-paths.ts 导出了GOOGLE_DESIGN_MD_PACKAGE_VERSION = '0.3.0'与GOOGLE_DESIGN_MD_SCHEMA_CHANNEL = 'alpha'，用于对外暴露所支持的规范版本。钉死让应用免受 alpha 规范频繁变动的影响——升级钉死版本成为一次有意的兼容性变更，且必须用 Google 仓库的 fixtures 与用户提供的样本回归验证。

4.2 归一化内部模型

适配器对外暴露的稳定模型定义在 src/renderer/src/design/design-md/design-md-types.ts，与设计文档给出的类型骨架一一对应：

type ProjectDesignMdDocument = { name: string description?: string colors: Record<string, DesignMdColor> // raw + hex + luminance typography: Record<string, DesignMdTypography> // fontFamily/fontSize/fontWeight/lineHeight/letterSpacing rounded: Record<string, DesignMdDimension> spacing: Record<string, DesignMdDimension> components: Record<string, Record<string, unknown>> extensions: Record<string, unknown> // 未知顶层键 sections: DesignMdMarkdownSection[] raw: string sourceHash: string }

（设计文档中的path: 'DESIGN.md'与diagnostics在实现中由路径常量与同步状态 store 承担，类型细节略有收敛，语义一致。）

适配器负责校验：第一个 YAML fence、规范标量/对象类型、CSS 颜色与尺寸语法、token 引用、重复小节、规范小节顺序以及文件大小上限。未知顶层键、未知 token 名、未知小节与未知组件属性一律保留；不支持的组件属性只产生警告，绝不进行破坏性归一化。

设计文档同样记录了被否决的备选方案：复用旧版基于表格的解析器。否决理由：它无法往返 YAML front matter、引用、任意 token 名与官方 lint 语义。

五、解析、校验与安全边界：从 front matter 到诊断

5.1 front matter 与 Markdown 小节的切分

parseProjectDesignMd（design-md-adapter.ts）先校验内容以---开头并匹配闭合的 YAML fence（/^---[ \t]*\r?\n([\s\S]*?)\r?\n---/），然后用parseDocument(source.yaml, { strict: true, uniqueKeys: true })（yaml 包）解析 front matter，用正则把剩余 Markdown 按#~######标题切分为有序小节，并检测重复标题。其校验项包括：

• 截断读取（truncated）与超过512 KiB（PROJECT_DESIGN_MD_MAX_BYTES = 512 * 1024）时报 error；
• 顶层name必须为非空字符串；
• colors/typography/rounded/spacing/components中至少有一个非空对象；
• 合并官方 lint findings（标记source: 'google'）与 Kun 本地诊断（标记source: 'kun'）；
• 重复 Markdown 小节报 error；
• 对每个 token 值做引用解析。

5.2 token 引用解析

resolveDesignMdReference支持{colors.primary}形式的引用，逐点解析路径（path.split('.')），并带三重防护：

• 环引用检测：visited集合，命中即抛Circular token reference；
• 未解析引用检测：valueAt返回 undefined 即抛Unresolved token reference；
• 深度上限：MAX_REFERENCE_DEPTH = 32，防止深层嵌套拖垮解析。

5.3 安全边界：拒绝可执行 CSS

UNSAFE_CSS_RE = /(?:url\s*\(|@import|expression\s*\(|javascript:)/i会递归扫描所有 token 值，命中即产生 error 级诊断。这落实了设计文档与两份规格中的硬性约束：只有通过校验的 CSS 颜色与尺寸才能进入内联样式；url()、远程字体源、样式表导入、标记、脚本与事件属性永远不会被渲染；字体族值只选择本机/系统字体并带有安全回退。

5.4 判定与 last-valid 行为

parseProjectDesignMd返回{ ok, document, diagnostics }，只要存在 error 级诊断即视为无效。配套规格 google-design-md-source/spec.md 明确：当后续持久化修订无效时，看板继续渲染最后一个有效模型；若首次观察到的文件就无效，则只展示错误入口，绝不捏造主题试样。这一「last valid」行为由下文的状态机直接支撑。

六、编辑与持久化：round-trip 保真 + 冲突安全

6.1 结构化编辑只补丁已识别的 YAML 节点

决策 3（Preserve user-authored content during edits）的核心是绝不整文件重生成。解析同时产出归一化模型与可往返（round-trip）的文档表示；Theme 结构化编辑只 patch 已识别的 YAML 节点，raw tab 的编辑则整体替换草稿源。Markdown 散文、未知小节、未知 YAML 键与扩展值在结构化保存中逐字节保留。

实现上patchProjectDesignMd(content, patches)用 yaml 包的document.setIn([section, key], value)/document.deleteIn(...)修改 AST，再拼接回---\n${yaml}\n---\n${markdown}并重新解析校验；DesignMdStructuredPatch只允许落在colors/typography/rounded/spacing/components五个小节内。配套的 design-md-adapter.test.ts 对「未触碰小节字节稳定」做了回归覆盖（tasks.md 2.5 的「byte-stable untouched sections」）。

设计文档明确记录了被否决的备选方案：从归一化 token 重新生成整个文件。否决理由：这会抹掉 rationale 与扩展内容——恰恰是 DESIGN.md 中给 Agent 传达意图的部分。

6.2 base-hash 比较交换与冲突状态

保存前的竞态防护是 base-hash 比较交换（compare-and-swap）。写入前，编辑器重新读取DESIGN.md 并把当前磁盘 hash 与草稿的 base hash 对比；不一致则进入conflict状态并拒绝覆盖，用户可选择「重新加载外部版本」或「复制我的草稿」（Inspector 中的两个按钮分别对应reloadConflict与saveMineAfterConflict，见 DesignSystemInspector.tsx）。

实现细节见 use-project-design-system-sync.ts：

• projectDesignMdExternalRevisionDecision(draft, nextHash)三分支：无脏草稿 →apply；hash 与 base 相同 →ignore-base-replay（防止 watcher 对未变基准的重放抹掉未保存草稿）；否则 →conflict；
• saveProjectDesignMdNow在写盘前再次比对 hash，不匹配即setConflict；
• 保存经由writeDesignWorkspaceFile走既有工作区 IPC 边界，watcher 处理原子改名/替换；文件系统监听因原子 rename 脱落时，WATCH_RECOVERY_MS = 1_500的有界恢复读取（scheduleRecovery）会重新附着监听；
• 重复保存被按键合并（saveQueuesmap），失败则回滚到草稿态。

hash 使用 FNV-1a 变体（projectDesignMdHash，2166136261种子 +16777619乘法，输出 36 进制）。

6.3 同步状态机

决策 4（One synchronization store owns file, draft, diagnostics, and last-valid state）把旧的「项目 JSON 同步 store」替换为一个 DESIGN.md 状态机。实现于 project-design-system-store.ts（zustand），状态类型见 design-md-types.ts 的ProjectDesignMdSyncStatus：

配套规格还要求：工作区/文档上下文 fence（activateWorkspace+ generation 计数）防止迟到的读取或 watcher 事件污染新选中的工作区；删除文件清空主题看板与归一化公开 token，但不删除内部画布组件状态。

七、白板：确定性的内置主题试样

决策 5（The board is a deterministic built-in specimen）规定试样保持内置渲染器身份，定位在画布坐标中随看板平移缩放，永不求值 Markdown HTML，也永不成为持久化的画布形状或产物。其渲染入口是 DesignSystemBoardOverlay.tsx，模型构建在 design-md-specimen-model.ts。

7.1 试样内容

固定布局包含：

• 四个重点调色板卡片（primary、secondary、tertiary、neutral/surface/background，带语义回退），每个附带仅用于可视化的生成色调梯度；
• 按 token 名启发式确定性选出的 display/headline、body、label 字体卡片，随后列出其余字体 token；
• surface/background 卡片、primary/secondary/inverted/outlined 控件、input/search、progress、navigation、chips/actions、圆角与间距样本；
• 来自 front matter 的语义组件 token 示例，未解析引用会可见地诊断。

亮点是确定性回退：FEATURED_ROLE_GROUPS = [['primary'], ['secondary'], ['tertiary'], ['neutral','surface','background']]，语义角色缺失时按索引取第 N 个 token 名作为回退（names[index]），补充 token 按字典序稳定排列，供试样展示「多于重点网格」的剩余 token——不会丢弃。

7.2 明暗预览与安全样式

明/暗预览模式是查看者偏好：初始由 surface 亮度推断，可切换且不修改 DESIGN.md。所有布局顺序按「语义优先级 → token 名字典序」稳定。颜色文本色由readableDesignMdTextColor用亮度公式(r*299 + g*587 + b*114)/1000 > 145决定深/浅前景。只有通过校验的 CSS 颜色与尺寸才进入内联 style（如--ds-surface等 CSS 变量），不安全值一律回退并显示诊断。

八、Inspector：Theme 与 DESIGN.md 双 Tab

决策 6（Inspector is DOM UI; the specimen stays in canvas coordinates）要求选择项目主题试样时打开右侧 Design inspector，含Theme与DESIGN.md两个 Tab。实现于 DesignSystemInspector.tsx：

• 它是普通 React overlay，不是 SVGforeignObject，因此文本编辑、诊断、滚动、键盘焦点与无障碍在任何画布缩放级别下都可靠；
• ThemeTab 编辑本地结构化草稿（预览模式、种子/语义颜色、字体、圆角、间距、组件 token 属性）；
• DESIGN.mdTab 复用现有代码编辑器原语，带 YAML/Markdown 高亮、实时诊断、复制与未保存状态；切换 Tab 绝不静默归一化或丢弃 raw 修改——当 raw 草稿无效而用户切到 Theme 时，最后一次可解析的结构化草稿继续可见，无效 raw 草稿被保留以待修正；
• 底部操作区提供Reset（丢弃脏草稿）、Save、Save & Apply三按钮，存在阻塞性校验或冲突错误时禁用保存。

两个动作的语义边界（也是规格 design-md-theme-board/spec.md 的硬性要求）：

• Save：校验并持久化 DESIGN.md，随后 watcher/commit 路径更新试样与 Agent 上下文；
• Save & Apply：先完成 Save，再把兼容的颜色/字体/间距/圆角值映射进当前 DesignDocument 的原生DesignSystemStore，在一个可撤销批次内更新 token 关联的原生画布对象（实现见 design-md-apply.ts：useCanvasUndoStore.getState().withGroup('Apply DESIGN.md', ...)遍历shape.tokenBindings，用resolveTokenPatch解析并updateShape，返回affectedIds供 UI 提示「Saved and applied to N linked layers」）；
• HTML/SVG 产物不会被盲目重写：UI 会明确说明已有文件内容需要 Agent 显式重构。

九、语义映射：Google token 与 Kun 原生 token 的桥接

决策 6 与规格 6（Mapping and Save & Apply behavior）的映射逻辑在 design-md-native-mapping.ts：

• mapProjectDesignMdToNative把 DESIGN.md 的colors.*（hex）、spacing.*与rounded.*（px/rem 数值化，rem 按 16px 折算）、typography.*（fontFamily/fontSize/fontWeight/lineHeight）映射为 Kun 原生DesignToken，同时保留当前 system 中非 DESIGN.md 来源的 token 与全部 components（富组件树不被覆盖）；
• 对brand/*、surface/*、text/*、border/*、type/*、space/*、radius/*这类原生命名 token（含斜杠），nativeTokenPublicPath与designMdTokenForNativeName提供反向解析，使 token 绑定（tokenBindings）能持续命中；
• 反方向serializeNativeDesignSystemAsDesignMd把原生 DesignSystem 序列化回 DESIGN.md（无现存文档时生成含## Brand & Style、## Colors、## Typography基础小节的模板），并通过patchProjectDesignMd保留既有散文；
• removeProjectDesignMdNativeTokens在文件缺失时清掉colors./spacing./rounded./typography.前缀的公开 token，恢复内部状态。

一个值得注意的实现细节：persistNativeDesignSystemToProjectDesignMd仅在显式design_system操作后调用——普通文档 sidecar 加载绝不会自动创建DESIGN.md，防止内部状态反向污染公开契约。

十、Agent 与导出路径：同一份源、同一份契约

决策 7（Agent and export paths operate on the same source）把 Agent 工具、提示词与导出全部重定向到根 DESIGN.md。

10.1 design_system 工具

Kun 侧工具声明位于 kun/src/adapters/tool/design-canvas-tool.ts（DESIGN_SYSTEM_TOOL_NAME = 'design_system'）。其inputSchema与设计文档一致：

• operation：create/update/apply/validate；
• expectedHash：最后一次观察到的精确 DESIGN.md 源 hash，用于冲突安全的更新——hash 不匹配时工具拒绝 patch，绝不覆盖外部编辑；
• 其他参数：name、seedColor（默认校准蓝）、mode（light/dark/both）、template（app/saas/game/editor/mobile/portfolio）、tone（clean/playful/premium/technical/editorial）、sections、targetIds、tokens（upsert 精确 token）、captureComponents、variants等。

工具说明明确：Design 画布读取并渲染该文件，使用固定内置试样看板，保留 Markdown 散文与未知扩展，绝不绘制 HTML/SVG/自由样式风格套件看板。

10.2 提示词与实现溯源

Design 模式的系统提示词（html-and-canvas.ts）要求 Agent 在构建完整产品或多屏体验前：若上方列出了有效根DESIGN.md则先读后设计；若缺失则通常先调用design_system（operation: "create"）再design_create_screen，让各屏共享真实项目级基础。同时硬性约束「DESIGN-SYSTEM CLAIMS MUST BE FACTUAL」：只有根 DESIGN.md 已列出或本轮design_system调用成功，才允许声称各屏共享统一设计系统；每屏的.kun-design/.../DESIGN.md笔记与视觉相似的页面 CSS 都不算项目设计系统。

实现溯源：共享提示类型 shared.ts 携带当前有效根 DESIGN.md 的精确源 hash（缺失/无效/冲突源省略），用于实现 provenance 与漂移检测——这正是设计文档「implementation provenance hashes the exact valid source」的落点。

10.3 导出：HANDOFF.md 引用而非复制

design.export现在写入.kun-design/HANDOFF.md。生成器见 design-md-compat.ts（STITCH_DESIGN_MD_PATH = '.kun-design/HANDOFF.md'，buildStitchDesignMarkdown）：当共享 token 文件恰为DESIGN.md时，Tokens 与 Components 小节不再内嵌第二份竞争 token 表，而是写「See rootDESIGN.md. Token values are intentionally not duplicated in this generated handoff.」并给出实现指引「Read root DESIGN.md first」。对应的旧.kun-design/DESIGN.md手递仍可被parseStitchDesignMarkdown/importStitchDesignMarkdown作为手递导入，但绝不会被当作项目主题，也不会被自动删除。

十一、旧数据迁移与路径消歧

决策 8（Legacy conversion is explicit and reversible）与实现 design-md-legacy-migration.ts：

• 若根DESIGN.md缺失且.kun-design/design-system.json有效，UI 提供迁移草稿（createLegacyDesignSystemMigrationDraft）：把支持的 token 映射进 Google 小节，尽可能转换语义组件属性，并将不可映射的富组件树细节记录在内部 sidecar 与迁移说明中；tokenCount、preservedComponentNames、notes一并返回。迁移草稿会附带## Migration Notes小节，说明「旧文件未被修改或删除」；
• 看板在迁移草稿被保存前保持隐藏——旧 JSON 单独存在绝不渲染看板（tasks.md 8.4）；
• acceptLegacyDesignSystemMigration只能在用户确认后调用，写根DESIGN.md后旧 JSON 永不自动删除；
• 回滚可恢复旧读取器/看板开关，而根 DESIGN.md、旧 JSON、内部每文档 sidecar 与旧手递文件都保留在磁盘上——回滚不丢弃任何用户数据。

十二、风险与权衡

设计文档明确列出七项风险及对策，均在仓库中可验证：

1. Google schema 为 alpha 且可能变更→ 钉死精确适配器版本、保留 fixtures、暴露支持的规范版本、有意升级（package.json中@google/design.md@0.3.0+GOOGLE_DESIGN_MD_SCHEMA_CHANNEL）；
2. Google 组件 token 无法编码 Kun 画布树→ sidecar 保持内部，Save & Apply只做单向语义映射（mapProjectDesignMdToNative保留 components）；
3. 结构化编辑可能损伤用户散文/扩展→ patch AST/round-trip 表示，保留未知内容，回归测试未触碰小节字节稳定（patchProjectDesignMd+ adapter 测试）；
4. 任意 CSS 值成为渲染/安全面→ 校验标量类型、拒绝 url() 值、永不渲染 raw HTML、只做安全样式赋值（UNSAFE_CSS_RE）；
5. 大文件拖慢每次 watcher 事件→ 512 KiB 源限制、事件防抖/合并、按 hash 缓存、解析移出热点指针/渲染路径（PROJECT_DESIGN_MD_MAX_BYTES+saveQueues合并）；
6. 外部编辑与 Inspector 竞态→ base-hash CAS 与可见冲突状态（projectDesignMdExternalRevisionDecision）；
7. Save & Apply 可能暗示重写 HTML→ 明确其精确范围，文件产物重构留给显式 Agent 动作（Inspector 的 save 语义 + 工具说明）。

十三、迁移计划与落地顺序

设计文档给出的七步迁移计划，在 tasks.md 中已全部勾选完成：

1. 引入适配器、归一化类型、fixtures、lint 诊断与根路径常量，不改动当前渲染；
2. 加入 DESIGN.md 同步状态机与兼容检测（legacy JSON 看板暂留 fallback flag）；
3. 看板渲染与 Inspector 切换到 DESIGN.md 模型，验证 missing/invalid/external-edit 行为；
4. 重定向 Agent 工具、提示词、实现 hash 与内置 skill 指令；
5. 项目手递输出移至.kun-design/HANDOFF.md并加兼容读取器；
6. 加入可选 legacy JSON 转换，不删除 legacy 文件；
7. 聚焦迁移、渲染器、运行时与打包应用验证后，移除 legacy 项目 JSON 看板 fallback。

回滚只需恢复 legacy 读取器/看板开关；根 DESIGN.md、旧 JSON、内部 sidecar 与旧手递文件全部保留，因此回滚不丢数据。

十四、开放问题

• 未来版本是否应将嵌套产物DESIGN.md笔记重命名为NOTES.md？本变更保持其兼容，并把发现范围限定在工作区根；
• 未来 Google 规范版本是否会增加标准的明暗模式/主题扩展？在那之前，明暗预览保持为 Kun 查看者状态，而非自定义规范 token。

十五、深入阅读路径

• 变更设计与决策全文：openspec/changes/support-google-design-md/design.md、proposal.md、tasks.md
• 能力规格：google-design-md-source/spec.md、design-md-theme-board/spec.md
• 实现源码：design-md-paths.ts、design-md-types.ts、design-md-adapter.ts、design-md-specimen-model.ts、design-md-native-mapping.ts、design-md-apply.ts、design-md-legacy-migration.ts、design-md-fixtures.ts
• 生命周期与 lint：use-project-design-system-sync.ts、project-design-system-store.ts、project-design-md-lint.ts
• UI 与工具：DesignSystemBoardOverlay.tsx、DesignSystemInspector.tsx、design-canvas-tool.ts、design-md-compat.ts

需要特别说明的是：仓库中的 fixtures（design-md-fixtures.ts）包含一份完整的LUMINOUS_STAGE_DESIGN_MD官方风格样本（含 surface 色阶、Sora/Hanken Grotesk/Geist 字体层级、rounded/spacing 与七段 Markdown rationale），以及OFFICIAL_STYLE_DESIGN_MD、INVALID_DESIGN_MD（断引用）、UNSAFE_DESIGN_MD（url(javascript:...)）等边界样本，可用于直接验证解析器与试样的安全回退行为。本文描述的「确定性内置试样」「冲突安全编辑」「Save & Apply 单批可撤销」等能力，均可对照上述源码与 design-md-specimen-model.test.ts、design-md-adapter.test.ts、design-md-apply.test.ts 等测试进一步验证。

• 人工智能
• AI Agent
• 自主智能体
• 桌面应用
• MCP Clients