ARTICLE · INTELLIGENCE

战地情报 · 详情页

来自尧图项目组的一线实战观察与深度解析

Kun 接入 Google DESIGN.md Alpha 规范:以根目录 DESIGN.md 为唯一项目主题契约的完整落地指南

Kun 接入 Google DESIGN.md Alpha 规范:以根目录 DESIGN.md 为唯一项目主题契约的完整落地指南 人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载导读Kun 的 Design 模式长期存在两份职责重叠的项目级设计契约.kun-design/design-system.json结构化项目主题驱动内置设计系统看板与.kun-design/DESIGN.mdKun/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承载规范性的设计 tokennormative 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 模型。三、文件角色划分谁才是「真源」决策 1Root DESIGN.md is canonical给出了清晰的路径职责表。关键落点见源码常量 src/renderer/src/design/design-md/design-md-paths.ts路径角色说明DESIGN.md工作区根唯一公开主题真源只有该路径会触发自动项目主题发现与固定白板试样.kun-design/HANDOFF.mdKun 项目手递输出旧的.kun-design/DESIGN.md导出迁移至此.kun-design/DESIGN.md兼容性只读路径旧 Kun 手递文件仍可被读取但写入方不再创建它绝不将其解释为项目主题.kun-design/document/design-system.json内部 Kun sidecar无损保存画布组件树仅限内部编辑器状态.kun-design/design-system.json根级旧版仅作为迁移输入本变更之后不再驱动看板其余嵌套产物文件如.kun-design/document/artifact/DESIGN.md继续作为实现笔记存在并被排除在项目主题发现之外。该设计避免了路径启发式猜测并给 Agent 一条无歧义的指令先读根DESIGN.md。设计文档明确记录了被否决的备选方案继续以.kun-design/DESIGN.md为真源。否决理由Google 工具链、编码 Agent 以及用户请求的工作目录发现机制都期望工作区根目录。四、把 Google alpha 契约钉在 Kun 适配器之后4.1 为什么需要适配器决策 2Pin 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: Recordstring, DesignMdColor // raw hex luminance typography: Recordstring, DesignMdTypography // fontFamily/fontSize/fontWeight/lineHeight/letterSpacing rounded: Recordstring, DesignMdDimension spacing: Recordstring, DesignMdDimension components: Recordstring, Recordstring, unknown extensions: Recordstring, 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 小节的切分parseProjectDesignMddesign-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 KiBPROJECT_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 安全边界拒绝可执行 CSSUNSAFE_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 节点决策 3Preserve 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.tsprojectDesignMdExternalRevisionDecision(draft, nextHash)三分支无脏草稿 →applyhash 与 base 相同 →ignore-base-replay防止 watcher 对未变基准的重放抹掉未保存草稿否则 →conflictsaveProjectDesignMdNow在写盘前再次比对 hash不匹配即setConflict保存经由writeDesignWorkspaceFile走既有工作区 IPC 边界watcher 处理原子改名/替换文件系统监听因原子 rename 脱落时WATCH_RECOVERY_MS 1_500的有界恢复读取scheduleRecovery会重新附着监听重复保存被按键合并saveQueuesmap失败则回滚到草稿态。hash 使用 FNV-1a 变体projectDesignMdHash2166136261种子 16777619乘法输出 36 进制。6.3 同步状态机决策 4One synchronization store owns file, draft, diagnostics, and last-valid state把旧的「项目 JSON 同步 store」替换为一个 DESIGN.md 状态机。实现于 project-design-system-store.tszustand状态类型见 design-md-types.ts 的ProjectDesignMdSyncStatus状态含义看板行为loading初始读取进行中无看板missing文件不存在无看板、无空态画布节点ready持久化源有效渲染看板dirty存在有效/无效本地草稿持久化源保持 last-valid 基线除非预览 Theme 编辑invalid持久化文件无效展示诊断存在 last-valid 模型则继续显示conflict草稿创建后外部源已变化保存被阻止saving一次写入进行中重复保存被合并配套规格还要求工作区/文档上下文 fenceactivateWorkspace generation 计数防止迟到的读取或 watcher 事件污染新选中的工作区删除文件清空主题看板与归一化公开 token但不删除内部画布组件状态。七、白板确定性的内置主题试样决策 5The 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 字体卡片随后列出其余字体 tokensurface/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 变量不安全值一律回退并显示诊断。八、InspectorTheme 与 DESIGN.md 双 Tab决策 6Inspector 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.tsuseCanvasUndoStore.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 与规格 6Mapping and Save Apply behavior的映射逻辑在 design-md-native-mapping.tsmapProjectDesignMdToNative把 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 与导出路径同一份源、同一份契约决策 7Agent and export paths operate on the same source把 Agent 工具、提示词与导出全部重定向到根 DESIGN.md。10.1 design_system 工具Kun 侧工具声明位于 kun/src/adapters/tool/design-canvas-tool.tsDESIGN_SYSTEM_TOOL_NAME design_system。其inputSchema与设计文档一致operationcreate/update/apply/validateexpectedHash最后一次观察到的精确 DESIGN.md 源 hash用于冲突安全的更新——hash 不匹配时工具拒绝 patch绝不覆盖外部编辑其他参数name、seedColor默认校准蓝、modelight/dark/both、templateapp/saas/game/editor/mobile/portfolio、toneclean/playful/premium/technical/editorial、sections、targetIds、tokensupsert 精确 token、captureComponents、variants等。工具说明明确Design 画布读取并渲染该文件使用固定内置试样看板保留 Markdown 散文与未知扩展绝不绘制 HTML/SVG/自由样式风格套件看板。10.2 提示词与实现溯源Design 模式的系统提示词html-and-canvas.ts要求 Agent 在构建完整产品或多屏体验前若上方列出了有效根DESIGN.md则先读后设计若缺失则通常先调用design_systemoperation: 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.tsSTITCH_DESIGN_MD_PATH .kun-design/HANDOFF.mdbuildStitchDesignMarkdown当共享 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作为手递导入但绝不会被当作项目主题也不会被自动删除。十一、旧数据迁移与路径消歧决策 8Legacy 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.4acceptLegacyDesignSystemMigration只能在用户确认后调用写根DESIGN.md后旧 JSON 永不自动删除回滚可恢复旧读取器/看板开关而根 DESIGN.md、旧 JSON、内部每文档 sidecar 与旧手递文件都保留在磁盘上——回滚不丢弃任何用户数据。十二、风险与权衡设计文档明确列出七项风险及对策均在仓库中可验证Google schema 为 alpha 且可能变更→ 钉死精确适配器版本、保留 fixtures、暴露支持的规范版本、有意升级package.json中google/design.md0.3.0GOOGLE_DESIGN_MD_SCHEMA_CHANNELGoogle 组件 token 无法编码 Kun 画布树→ sidecar 保持内部Save Apply只做单向语义映射mapProjectDesignMdToNative保留 components结构化编辑可能损伤用户散文/扩展→ patch AST/round-trip 表示保留未知内容回归测试未触碰小节字节稳定patchProjectDesignMd adapter 测试任意 CSS 值成为渲染/安全面→ 校验标量类型、拒绝 url() 值、永不渲染 raw HTML、只做安全样式赋值UNSAFE_CSS_RE大文件拖慢每次 watcher 事件→ 512 KiB 源限制、事件防抖/合并、按 hash 缓存、解析移出热点指针/渲染路径PROJECT_DESIGN_MD_MAX_BYTESsaveQueues合并外部编辑与 Inspector 竞态→ base-hash CAS 与可见冲突状态projectDesignMdExternalRevisionDecisionSave Apply 可能暗示重写 HTML→ 明确其精确范围文件产物重构留给显式 Agent 动作Inspector 的 save 语义 工具说明。十三、迁移计划与落地顺序设计文档给出的七步迁移计划在 tasks.md 中已全部勾选完成引入适配器、归一化类型、fixtures、lint 诊断与根路径常量不改动当前渲染加入 DESIGN.md 同步状态机与兼容检测legacy JSON 看板暂留 fallback flag看板渲染与 Inspector 切换到 DESIGN.md 模型验证 missing/invalid/external-edit 行为重定向 Agent 工具、提示词、实现 hash 与内置 skill 指令项目手递输出移至.kun-design/HANDOFF.md并加兼容读取器加入可选 legacy JSON 转换不删除 legacy 文件聚焦迁移、渲染器、运行时与打包应用验证后移除 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生命周期与 lintuse-project-design-system-sync.ts、project-design-system-store.ts、project-design-md-lint.tsUI 与工具DesignSystemBoardOverlay.tsx、DesignSystemInspector.tsx、design-canvas-tool.ts、design-md-compat.ts需要特别说明的是仓库中的 fixturesdesign-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_MDurl(javascript:...)等边界样本可用于直接验证解析器与试样的安全回退行为。本文描述的「确定性内置试样」「冲突安全编辑」「Save Apply 单批可撤销」等能力均可对照上述源码与 design-md-specimen-model.test.ts、design-md-adapter.test.ts、design-md-apply.test.ts 等测试进一步验证。赞分享人工智能AI Agent自主智能体桌面应用MCP Clients【免费下载链接】KunLocal-first AI agent workspace for coding, writing, design, research, and automation — one runtime for desktop GUI and TUI.项目地址https://gitcode.com/gh_mirrors/de/Kun点击查看免费下载相关推荐Open Design Publication 设计系统DESIGN.md 从编辑排版风格到 Token 契约的完整落地Open Design Publication 设计系统DESIGN.md 从编辑排版风格到 Token 契约的完整落地 本篇以 design systemsAI 应用人工智能AI 技能设计系统媒体生成OpenDesign Dashboard 设计系统实战从 DESIGN.md 视觉规范到 tokens.css 令牌落地的完整解析OpenDesign Dashboard 设计系统实战从 DESIGN.md 视觉规范到 tokens.css 令牌落地的完整解析 导读DashboardAI 应用人工智能AI 技能设计系统媒体生成oh-my-openagent 前端设计研究StyleGallery 空间模式契约的 curl 检索与 DESIGN.md 落地oh my openagent 前端设计研究StyleGallery 空间模式契约的 curl 检索与 DESIGN.md 落地 本篇技术指南围绕 oh my人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
RELATED READING

延伸阅读

更多一线实战笔记与深度复盘,助您持续精进