12 篇文章带有标签 “design”

——写给完全不懂硬件的软件工程师的硬件设计入门读本

这份文档假设你从未接触过硬件设计。它一边讲这个项目做了什么、怎么做的， 一边把理解每个环节所需的硬件基础知识讲清楚。 读完后你应该能：看懂这套设计文件、知道每个文件是干什么的、 并能自己动手改一个尺寸、重新生成模型、拿去 3D 打印。

1. 这个项目是什么

我们团队做了一套「AI 智能会议系统」软件：开会时实时把语音转成文字、 区分是谁在说话（说话人分离）、会后自动生成会议纪要。这套软件完全离线 跑在一台 NVIDIA Jetson AGX Thor 开发套件上（一块带强大 AI 算力的卡片式电脑， 可以粗略理解为"一台浓缩到巴掌大、专门跑 AI 的小型工作站"）。

软件跑在芯片上，但芯片不能裸着摆在会议桌上。这个项目要做的， 就是给这套软件造一个 "身体"：一台放在公司会议室（20 人以内）桌上的 硬件终端——它有外壳、有麦克风阵列、有扬声器、有状态屏、有摄像头， 内部把 Thor 开发套件和这些器件安排得井井有条。

这台终端叫 智会 T1 (SmartMeet T1)，长这样：

需要说明的是：本项目交付的是结构设计与工程文档（外壳和内部布局怎么设计、 怎么装配、买什么零件），不包括电路设计和软件代码。

本文件研究了 /Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked/resources/templates 目录下的全部 *.tpl 模板（12个文件），每个文件作为独立章节，原文（含 Jinja 占位符与 XML 标签）原样保留在代码块中。 基于你提供的 WorkBuddy Prompt 模板文件，以下是其整体架构与各模板关系的思维导图（Mermaid 格式）：

mindmap
  root((WorkBuddy Prompt 模板))
    分类与概览
      共12个模板
      分类：模式提醒 / 系统提醒 / 身份上下文 / 主Prompt
      主Prompt分4个场景：Ask·编码 / Ask·通用 / Craft·编码 / Craft·设计 / 专家·编码 / 专家·通用 / 通用Craft
    模式提醒片段
      ask-mode-reminder
        Ask模式硬性规则：只读·不编辑·不运行命令
        建议切换至Craft
      craft-mode-reminder
        Craft模式能力激活：可自由编辑与创建文件
        直接执行任务
    系统提醒片段
      system-reminder
        占位标签
        运行时由系统注入提醒
    身份上下文模板
      user-context-expert-identity
        专家模式身份注入
        含BOOTSTRAP.md / USER.md
        聚焦产品身份与语气占位
      user-context-identity
        通用身份注入
        含SOUL.md / IDENTITY.md / USER.md
        用户自定义指令与语气风格覆盖
    主Prompt·Ask模式
      workbuddy-ask-prompt
        纯对话场景
        只读工具·不可编辑
        可视化工具（read_me / show_widget）
        MCP配置引导
      workbuddy-ask-coding-prompt
        Ask + 编码场景
        与ask-prompt同源
        强调代码库上下文与只读分析
    主Prompt·Craft模式
      workbuddy-prompt
        通用Craft默认主提示
        能力总览·Agent循环·结果呈现
        自动化任务与技能管理
      workbuddy-craft-coding-prompt
        Craft + 编码场景
        Agent循环·任务管理工具
        技能积累与反思（SkillManage）
        自动化（automation_update）
        可视化与多模态生成
      workbuddy-craft-design-prompt
        Craft + 设计场景
        智能设计助手角色
        画布三段式回复格式
        文生UI·截图验证
        目标节点优先原则
    主Prompt·专家模式
      workbuddy-expert-prompt
        专家模式通用（AGENTIC）
        角色覆盖·产物概览
        松弛自然沟通风格
        多模态生成与技能积累
      workbuddy-expert-coding-prompt
        专家 + 编码场景
        与expert-prompt同源
        聚焦编码任务与产物交付

该图清晰呈现了：

• 4 大类模板（模式提醒、系统提醒、身份上下文、主 Prompt）
• 7 种主 Prompt 场景（Ask 通用、Ask 编码、Craft 通用、Craft 编码、Craft 设计、专家通用、专家编码）
• 各模板的核心定位与关键约束（只读/可编辑、身份注入、可视化、自动化、技能管理等）

模板概览

mindmap
  root((Hallmark))
    是什么
      反 AI 味的设计技能
      让 AI 生成的网页像人做的
      Together AI 出品 · MIT 开源
    给谁用
      Claude Code
      Cursor
      Codex
    核心功能 · 四个动词
      默认 · 新建设计
        预检扫描现有项目
        设计三问 · 受众/用途/基调
        先预览后写码
      audit · 体检
        给旧代码查 AI 味
        只出清单不改代码
      redesign · 重构
        留文案和品牌
        推翻视觉重做
      study · 提取 DNA
        从截图或 URL 学设计
        拒绝像素级抄袭
    凭什么不像 AI
      21 种页面结构
      20 个主题 · 4 流派
      58 道俗套检测门
      六维交付自评
    关键机制
      log.json 强制每次不重样
      tokens.css 设计系统可移植
      design.md 锁定整站风格
    怎么用
      npx skills add nutlope/hallmark

项目地址：https://github.com/Nutlope/hallmark 在线演示：https://www.usehallmark.com 许可证：MIT

一、这是什么

Hallmark 是一个面向 AI 编程助手（Claude Code、Cursor、Codex）的设计技能（Skill），由 Together AI 出品。它解决的问题很具体：大模型生成的网页 UI 总有股"一眼 AI"的味道——居中大标题、紫蓝渐变、三列等宽卡片、Inter 字体……Hallmark 用一套强制规则把这些"默认审美"全部禁掉。

它的核心理念是结构多样性优先于视觉多样性：两个不同需求（brief）生成的页面，不应该只是同一模板换了配色，而应该像两个真正不同的网站。为此它内置了：

• 21 种宏观结构（macrostructure）——页面的整体骨架，如 Bento Grid、Long Document、Manifesto、Marquee Hero、Stat-Led 等
• 20 个命名主题（theme）——分属四个流派（genre），外加一个"自定义主题"隐藏分支
• 50 个组件原型——9 种 Hero、14 种导航、8 种页脚、5 种节标题等
• 58 道"防俗套检测门"（slop test）+ 交付前六维自评——任何一项不达标就打回重做

数据来源：codebuddy-plugins-official 市场 manifest（共 207 个插件，2026-07-16） 整理口径：从 207 个插件中筛出 软件开发生命周期、安全、办公、设计 四个领域；一个插件只归入一个主领域，跨领域插件在说明中以「兼属 ××」标注；其余 32 个插件列入文末「未归入」。

一、软件开发生命周期（134）

1.1 需求、规划与项目管理（8）

插件名	来源	说明
requirements-driven-workflow	官方	需求驱动开发工作流，含 90% 质量门控的功能实现流程
interview	外部	访谈式命令，用于细化大型功能计划与规格
conductor	外部	上下文驱动开发：上下文 → 规格与计划 → 实施的结构化工作流
agent-team-agile-workflow	官方	BMAD 敏捷工作流，含 PO、架构师、SM、开发、QA 角色代理与交互式审批
taskmaster	外部	基于 AI 的任务管理系统，提供命令、代理和 MCP 集成
commands-project-setup	外部	项目初始化与搭建命令
commands-project-task-management	外部	任务管理与项目跟踪命令
feature-dev	官方	全面功能开发工作流，含代码库探索、架构设计与质量审查智能体

1.2 架构与设计（软件架构）（7）

一套面向 Agent 应用设计者的系统化设计原则、架构模式与实战指南。

基于对 WorkBuddy（CodeBuddy Code）工作空间源码、系统提示词、文档与架构的深度分析提炼而成。

目录

1. 概述：从 Chatbot 到 Agent 的范式跃迁
2. 原则一：闭环执行架构
3. 原则二：人格化身份体系
4. 原则三：分层记忆系统
5. 原则四：纵深防御安全模型
6. 原则五：渐进式能力扩展
7. 原则六：多模态工作模式
8. 原则七：上下文精细管理
9. 原则八：可组合的工具哲学
10. 系统架构全景图
11. 可复用的设计模式清单
12. 设计决策框架
13. 常见反模式

1. 概述：从 Chatbot 到 Agent 的范式跃迁

1.1 Chatbot 和 Agent 的本质区别

维度	Chatbot	Agent
核心能力	理解并回答	理解、计划、执行、验证
与环境的交互	被动接收文本	主动感知文件系统、网络、工具
输出的性质	文本回答	实际行动（文件变更、API 调用、部署）
正确性保障	依赖训练数据	通过执行测试、编译、对比等方式自我验证
会话生命周期	一问一答，无持续性	跨多轮持久化，可中断恢复
用户角色	提问者	协作者/监督者

设计 Agent 系统，首先要完成这个认知跃迁：Agent 不是"更强的 Chatbot"，而是一种全新的交互范式。

1.2 Agent 设计的核心张力

在设计 Agent 系统时，始终面临以下四对核心张力：

WorkBuddy 介绍

AI 专家团 全场景办公

WorkBuddy 是全能 AI 工作台，一人指挥，全行业专家执行，从策略到交付一站搞定

免部署·安装即用 ｜ 多专家·多模型协同 ｜ 全平台·桌面 / 主流 IM / 小程序

100+ 领域专家组成你的虚拟团队，运营、设计、数据、开发等全角色场景覆盖

一句话指令自主规划并交付完整结果

多专家并行协作，一个人顶一支团队

MCP 生态 + 自定义 Skills，能力无限扩展

设计系统（Design System）

• 场景：设计系统
• 模型：Deepseek-V4-Flash

输入（宫崎骏的太空之城风格设计系统）

帮我建立一套完整的 Design System，包含颜色体系、字体层级、间距规则和基础组件规范文档，风格为宫崎骏的太空之城

输出

基于 /Applications/WorkBuddy.app/Contents/Resources/app.asar.unpacked 逆向分析 WorkBuddy Desktop v5.2.5 + CodeBuddy CLI v2.106.4 | 腾讯出品

一、整体架构概览

graph TB
    subgraph "操作系统层"
        OS["macOS / Windows<br/>Darwin / Win32"]
        FSE["FSEvents API<br/>(macOS 文件监听)"]
        PTY["Pseudoterminal API<br/>(openpty / ConPTY)"]
        SQLITE["SQLite Engine<br/>(C++ 绑定)"]
    end

    subgraph "Electron 应用外壳 (WorkBuddy Desktop v5.2.5)"
        ELECTRON["Electron Main Process<br/>Node.js + Chromium"]
        RENDER["Renderer Process<br/>React/Vue UI + WebView"]
        DEVTOOLS["DevTools Panel<br/>Ghostty WASM Terminal"]
        PRELOAD["Preload Scripts<br/>IPC 安全桥接"]
    end

    subgraph "CLI 核心宿主 (CodeBuddy CLI v2.106.4)"
        CLI["cli/bin/codebuddy<br/>Node.js 启动器"]
        TUI["TUI Mode<br/>Ink + React 19<br/>~16MB Bundle"]
        DAEMON["Daemon Mode<br/>HTTP Server<br/>Port 51862+"]
        HEADLESS["Headless Mode<br/>-p / --print<br/>CI/CD 管道"]
        WEBUI["Web UI<br/>Workers / Logs / Metrics"]
    end

    subgraph "原生模块层 (app.asar.unpacked)"
        NATIVE_MOD["node_modules/"]
        BETTER_SQL["better-sqlite3<br/>v12.8.0 (MIT)"]
        NODE_PTY["node-pty<br/>v1.1.0 (Microsoft)"]
        LYDELL_PTY["@lydell/node-pty-darwin-arm64<br/>v1.2.0-beta.12"]
        DOCS_ENGINE["@tencent/docs-engine<br/>v0.0.1-beta.9"]
        FSE_MOD["fsevents<br/>(nunjucks 嵌套依赖)"]
    end

    subgraph "资源与扩展层 (resources/)"
        RES["resources/"]
        BUILT_PLUGINS["builtin-plugins/"]
        BUILT_SKILLS["builtin-skills/<br/>15 个内置技能"]
        BUILT_MCP["builtin-mcp-apps/"]
        TEMPLATES["templates/<br/>Nunjucks 提示词模板"]
        DEVTERM["devtools-terminal/<br/>Chrome Extension v3"]
        BRANDING["channel-branding/<br/>OEM 品牌资源"]
    end

    subgraph "AI 推理后端"
        BACKEND["copilot.tencent.com<br/>AI 推理集群"]
        MCP_PROXY["MCP Connector Proxy<br/>Port 61047"]
    end

    subgraph "用户数据层 (~/.workbuddy/)"
        USER_DATA["~/.workbuddy/"]
        DB["workbuddy.db<br/>(SQLite + WAL)"]
        SOUL["SOUL.md<br/>AI 灵魂"]
        IDENTITY["IDENTITY.md<br/>智能体身份"]
        MEMORY["memory/<br/>项目级记忆"]
        SESSIONS["sessions/<br/>会话 JSON"]
        TRACES["traces/<br/>运行追踪"]
    end

    OS --> ELECTRON
    ELECTRON --> RENDER
    ELECTRON --> PRELOAD
    RENDER --> DEVTOOLS

    ELECTRON -->|spawn| CLI
    CLI --> TUI
    CLI --> DAEMON
    CLI --> HEADLESS
    DAEMON --> WEBUI

    NATIVE_MOD --> BETTER_SQL
    NATIVE_MOD --> NODE_PTY
    NATIVE_MOD --> LYDELL_PTY
    NATIVE_MOD --> DOCS_ENGINE
    NATIVE_MOD --> FSE_MOD

    CLI --> NATIVE_MOD
    CLI --> RES

    RES --> BUILT_PLUGINS
    RES --> BUILT_SKILLS
    RES --> BUILT_MCP
    RES --> TEMPLATES
    RES --> DEVTERM
    RES --> BRANDING

    TUI -->|HTTP/WebSocket| BACKEND
    DAEMON -->|HTTP API| BACKEND
    HEADLESS -->|HTTP API| BACKEND
    BACKEND -->|MCP STDIO/SSE/HTTP| MCP_PROXY

    CLI -->|读写| USER_DATA
    DAEMON -->|读写| DB
    TUI -->|读取| SOUL
    TUI -->|读取| IDENTITY
    TUI -->|读取| MEMORY
    TUI -->|写入| SESSIONS
    TUI -->|写入| TRACES

    FSE -->|API 调用| FSE_MOD
    PTY -->|API 调用| NODE_PTY
    PTY -->|API 调用| LYDELL_PTY
    SQLITE -->|C++ 绑定| BETTER_SQL

    DOCS_ENGINE -->|"FFI 加载：libeditor_sdk_ffi.dylib (172 MB)"| EXT1
    DOCS_ENGINE -->|"HTTP Server：127.0.0.1:39099 本地文档预览"| EXT2
    DEVTERM -->|"WASM 执行：ghostty-vt.wasm 终端仿真"| EXT3
    EXT1 & EXT2 & EXT3:::dummy
    classDef dummy fill:none,stroke:none

    style ELECTRON fill:#e1f5fe
    style CLI fill:#fff3e0
    style BACKEND fill:#e8f5e9
    style USER_DATA fill:#fce4ec
    style NATIVE_MOD fill:#f3e5f5
    style RES fill:#e0f2f1

二、Electron 主进程与 CLI 双层架构

flowchart LR
    subgraph "Electron 主进程"
        direction TB
        EP1["app-instance.ts<br/>多实例检测"]
        EP2["auth.ts<br/>腾讯云 OAuth"]
        EP3["daemon-app-server-*.ts<br/>守护进程服务"]
        EP4["desktop-monitor-service.ts<br/>桌面监控"]
        EP5["helpers.ts<br/>工具函数集"]
        EP6["file-authentication-storage.ts<br/>文件认证存储"]
    end

    subgraph "CLI 进程 (Node.js 子进程)"
        direction TB
        C1["bin/codebuddy<br/>入口启动器"]
        C2["V8 Compile Cache<br/>~37% 启动加速"]
        C3["Node >= 18.20.8<br/>版本检查"]
        C4["Headless 路由<br/>--print / daemon / -p"]
        C5["TUI Bundle<br/>codebuddy.js<br/>Ink + React 19<br/>~16MB"]
        C6["Headless Bundle<br/>codebuddy-headless.js"]
    end

    subgraph "通信层"
        COM1["stdio<br/>标准输入输出"]
        COM2["HTTP<br/>Web UI / API"]
        COM3["WebSocket<br/>实时消息"]
        COM4["IPC<br/>Electron 内部"]
    end

    EP1 -->|"spawn('node', ['bin/codebuddy'])"| C1
    EP3 -->|HTTP 端口| COM2

    C1 --> C2
    C1 --> C3
    C1 --> C4
    C4 -->|TUI 模式| C5
    C4 -->|无头模式| C6

    C5 -->|stdio| COM1
    C5 -->|WebSocket| COM3
    C6 -->|HTTP| COM2
    EP1 -->|IPC| COM4
    RENDER["Renderer Process<br/>(UI 渲染)"] -->|IPC| COM4

    style EP1 fill:#e3f2fd
    style EP2 fill:#e3f2fd
    style EP3 fill:#e3f2fd
    style C1 fill:#fff8e1
    style C5 fill:#fff8e1
    style C6 fill:#fff8e1

关键设计决策：

• Desktop 与 CLI 版本分离：WorkBuddy Desktop v5.2.5 是 Electron 外壳，CodeBuddy CLI v2.106.4 是独立 Node.js 进程，两者版本独立演进
• 双 Bundle 策略：TUI 模式用 ink + React 19 提供交互终端，Headless 模式剔除 UI 依赖，显著减小启动开销
• V8 Compile Cache：通过 enableCompileCache() 将 ~16MB bundle 的加载时间从 ~400ms 降到 ~254ms
• --version 快速路径：直接返回版本号，跳过 DI 容器初始化和网络请求

三、原生模块与资源分层

graph LR
    subgraph "app.asar.unpacked 目录"
        direction TB
        subgraph "cli/ 目录"
            CLI_DIR["cli/"]
            CLI_BIN["bin/codebuddy<br/>入口脚本"]
            CLI_DIST["dist/<br/>codebuddy.js / codebuddy-headless.js"]
            CLI_WASM["dist/wasm/<br/>tree-sitter.wasm<br/>tree-sitter-bash.wasm"]
            CLI_WEBUI["dist/web-ui/<br/>docs/ (200+ 篇)"]
            CLI_VENDOR["vendor/<br/>sandbox / ripgrep / genie-trash"]
            CLI_PKG["package.json<br/>@genie/agent-cli"]
        end
        
        subgraph "node_modules/ 目录"
            NODE_DIR["node_modules/"]
            BETTER["better-sqlite3<br/>v12.8.0<br/>SQLite 数据库绑定"]
            NODE_PTY["node-pty<br/>v1.1.0<br/>Microsoft 伪终端"]
            LYDELL["@lydell/<br/>node-pty-darwin-arm64<br/>v1.2.0-beta.12"]
            TENCENT["@tencent/<br/>docs-engine<br/>v0.0.1-beta.9"]
            NJ["nunjucks<br/>+ fsevents<br/>模板引擎"]
        end
        
        subgraph "resources/ 目录"
            RES_DIR["resources/"]
            PLUGINS["builtin-plugins/<br/>weixinpay (MCP)"]
            SKILLS["builtin-skills/<br/>15 个技能"]
            MCP_APPS["builtin-mcp-apps/<br/>Ardot / Agently"]
            TEMPLATES["templates/<br/>8 模板 + 7 风格"]
            DEVT["devtools-terminal/<br/>Ghostty WASM"]
            BRAND["channel-branding/<br/>OEM 品牌"]
            PRELOADS["*-preload.js<br/>IPC 预加载脚本"]
        end
    end

    CLI_DIR --> CLI_BIN
    CLI_DIR --> CLI_DIST
    CLI_DIR --> CLI_WASM
    CLI_DIR --> CLI_WEBUI
    CLI_DIR --> CLI_VENDOR
    CLI_DIR --> CLI_PKG

    NODE_DIR --> BETTER
    NODE_DIR --> NODE_PTY
    NODE_DIR --> LYDELL
    NODE_DIR --> TENCENT
    NODE_DIR --> NJ

    RES_DIR --> PLUGINS
    RES_DIR --> SKILLS
    RES_DIR --> MCP_APPS
    RES_DIR --> TEMPLATES
    RES_DIR --> DEVT
    RES_DIR --> BRAND
    RES_DIR --> PRELOADS

    style BETTER fill:#ffebee
    style NODE_PTY fill:#ffebee
    style LYDELL fill:#ffebee
    style TENCENT fill:#ffebee
    style PLUGINS fill:#e8f5e9
    style SKILLS fill:#e8f5e9
    style MCP_APPS fill:#e8f5e9

为什么需要 app.asar.unpacked？

mindmap
  root((找到你的未知))
    【是什么】
      Anthropic 官方 agentic coding 指南
      核心观点：减少并管理未知 = 核心技能
      高手特征：未知少、懂代码库也懂模型
    【给谁用】
      用 Claude Code 的开发者
      面对陌生代码库/新领域的人
      想让 AI 协作更可控的人
    【核心框架：未知四象限】
      已知已知
        写进提示词的需求
      已知未知
        知道自己还没搞懂
      未知已知
        太显然没写 看到才认出
      未知未知
        完全没想到的坑 最危险
    【关键机制】
      告知起点上下文
        经验水平 思路进度 熟悉程度
      指令粒度要平衡
        太细→错过更优路径
        太粗→模型乱假设
      趁便宜先暴露未知
        原型期改成本远低于实施后
    【核心方法：按阶段】
      实施前
        盲点扫描：让 Claude 列出你的未知未知
        头脑风暴+原型：快速看到多种方向
        访谈：让 Claude 逐题问你澄清歧义
        参考引用：给源码当参照 比截图好
        实施计划：把易改决策放前面评审
      实施中
        实施笔记：记录偏离计划的决策
      实施后
        宣讲文档：加速评审者理解与批准
        测验：通过测验才算真懂 才合并
    【一句话精髓】
      让 Claude 帮你找未知
      在代价变大之前

原文：A field guide to Claude Fable 5: Finding your unknowns 作者：Thariq Shihipar（Anthropic 技术团队成员）

在使用 Claude Code 时，我常常想起地图与领土之间的区别。

地图，即待完成工作的表征，是我的提示词、技能和上下文——是我提供给 Claude 的东西。领土，则是工作需要实际发生的地方：代码库、现实世界、真实的约束条件。

地图与领土之间的差距，就是我所说的未知（unknowns）。当 Claude 遇到一个未知时，它需要根据对我意图的最佳猜测来做出决策。工作量越大，Claude 可能遇到的未知就越多。

Claude Fable 是我遇到的第一个模型，其工作质量的瓶颈在于我澄清未知的能力。

重要的是，仅仅提前规划并不总是足够的。你可能会在深入实现时发现未知，或者你的未知可能指向一个事实：你其实应该用完全不同的方式来解决问题。

我发现，使用 Fable 工作是一个迭代过程——在实现之前、之中和之后，不断发现自己的未知。

认识你的未知

你的未知是什么？当我带着问题来找 Claude 时，我倾向于将其分解为四种类型：

• 已知的已知（Known Knowns）：这本质上就是我的提示词中的内容。我告诉智能体我想要什么？
• 已知的未知（Known Unknowns）：我还有什么没搞清楚的，但我已经意识到我还没搞清楚？
• 未知的已知（Unknown Knowns）：有哪些事情如此显而易见，以至于我永远不会写下来，但看到时却能认出来？
• 未知的未知（Unknown Unknowns）：我完全没有考虑过什么？有哪些知识是我不知道自己不知道的？我知道某件事可以做得多好？

官网定位一句话：将文字、草图、截图、语音指令，一键生成 Web / 移动端高保真界面、可交互原型与可直接投入开发的前端代码，打通「灵感→设计→开发」完整工作流。 访问入口：stitch.withgoogle.com

🚀 Stitch：从想法到落地

Stitch 提倡“设计先行，边做边改”。告别面对空白页的焦虑，无需追求一步到位，通过不断迭代轻松产出优秀设计。

1. 极简起步：三步提示词公式

写下你的初始想法，无需死磕细节，给一个大概的“配方”即可生成：

• [想法] 是什么 + [主题] 风格氛围 + [内容] 核心板块。

2. 精准迭代：每次只改动一点

生成初稿后，构思才真正开始。

• 小步快跑： 每次锁定一个问题，用具体指令（配合 UI/UX 词汇）让 AI 修改。
• 全局调整： 善用“编辑主题”一键更换深浅模式、颜色和字体。

3. 验证与交付：从静态到上线

• 动效测试： 一键生成交互式“原型”，测试按钮悬停、文本输入等真实体验。
• 多端导出： 导出 HTML 和图片包。HTML 是万能资产，可借助大模型轻松转换为 React、Vue 或手机原生代码（Flutter/SwiftUI 等）。

💡 核心寄语： 别想太多，先生成，再优化。持续构思，直到满意！

• Everything you need to know

欢迎来到 Stitch。今天您将学习如何从设计切入并专注于概念构思。关键在于不要过度思考。

DESIGN.md是什么？

每个项目都有自己的视觉标识：颜色、字体、间距、组件样式。传统上，这些内容存储在 Figma 文件、品牌 PDF 或设计师的脑海中。AI 智能体无法读取这些格式。

DESIGN.md 改变了这一点。 它是一个纯文本设计系统文档，人类和智能体都可以阅读、编辑和执行。可以将其视为 AGENTS.md 的设计对应物：

文件	阅读者	定义内容
README.md	人类	项目是什么
AGENTS.md	编码智能体	如何构建项目
DESIGN.md	设计智能体	项目应该长什么样、什么感觉

它能给你带来什么

当像 Stitch 这样的设计智能体读取你的 DESIGN.md 时，它生成的每个屏幕都遵循相同的视觉规则：你的调色板、你的排版、你的组件模式。没有它，每个屏幕都是孤立的；有了它，它们看起来属于同一个产品。

DESIGN.md 是一个活的产物，而不是静态配置文件。它随着你的设计演变而演变。智能体生成它，你完善它，并在迭代过程中重新应用到屏幕上。

在底层，每个 DESIGN.md 都有两层：YAML 前置元数据包含机器可读的设计令牌（精确的十六进制值、字体属性、间距尺度）和Markdown 正文提供人类可读的设计原理说明。令牌为智能体提供精确值。散文告诉它们为什么这些值存在。完整的格式请参阅规范。

设计理念

DESIGN.md 规范是一个基础，而非规定。

• DESIGN.md

一种用于向编码智能体描述视觉识别系统的格式规范。DESIGN.md 让智能体对设计系统拥有持久、结构化的理解。

格式

DESIGN.md 文件将机器可读的设计令牌（YAML 前置元数据）与人类可读的设计原理（Markdown 正文）相结合。令牌为智能体提供精确值，正文则解释这些值为何存在以及如何使用。

---
name: Heritage
colors:
  primary: "#1A1C1E"
  secondary: "#6C7278"
  tertiary: "#B8422E"
  neutral: "#F7F5F2"
typography:
  h1:
    fontFamily: Public Sans
    fontSize: 3rem
  body-md:
    fontFamily: Public Sans
    fontSize: 1rem
  label-caps:
// ...

读取此文件的智能体将生成一个 UI：Public Sans 字体的深墨标题、温暖石灰石背景，以及波士顿陶土色的行动号召按钮。

快速开始

对照规范验证 DESIGN.md，捕获损坏的令牌引用、检查 WCAG 对比度比率，并输出结构化发现——所有结果均以智能体可处理的 JSON 格式呈现。