feat：移除了弹窗，服务器添加sls

2026-09-08 22:39:45 +08:00
commit 6a295f9a7a
4082 changed files with 1322534 additions and 0 deletions
--- a/.claude/skills/lark-apps/creative-design/references/aily.md
+++ b/.claude/skills/lark-apps/creative-design/references/aily.md
@ -0,0 +1,39 @@
+# Aily 工具参考
+
+本文档列出 [`../creative-design.md`](../creative-design.md) 所依赖的 harness 专属工具，供你在 **Aily** 中运行时使用。主提示词只命名能力（"向用户提问"、"展示文件"等）；本文档给出 Aily 的调用方式。通用工具（`Bash`、文件读/写/编辑、grep/glob 搜索）在任何环境都相同，不在此覆盖。
+
+## Web 工具 → Aily 对应项
+
+上游提示词引用了一些在 Aily 中并不存在的 Claude.ai web 工具。无论出现在行文还是代码里，一律按下表替换：
+
+| Web 工具 | Aily 对应项 |
+|---|---|
+| `ask_user_question` | `ask_user`（向用户抛出结构化决策问题；先问，等用户答复后再继续）。 |
+| `done`、`fork_verifier_agent` | 用 `submit` 交付结果并给出文件路径。 |
+| `write_file`（及其 `asset:` 参数） | Aily 的「创建/编辑本地文件」工具。不存在 asset review pane；舍弃这一概念。 |
+| `copy_files` | `Bash cp`。 |
+| `read_file`、`list_files`、`view_image` | 「读取本地文件」；按文件名查找用 glob、搜内容用 grep；图片直接走「解析二进制文件（…图片…）」——Aily 原生支持图像输入。 |
+| `show_to_user` | 用 `submit` 交付并给出绝对本地文件路径。 |
+| `eval_js`、`eval_js_user_view`、`run_script` | 脚本用 `Bash`。 |
+| `web_fetch`、`web_search` | `fetch`、`web_search`。用于时效性事实、内容素材补充或用户要求的查询。 |
+| `generate_image` | `aily-image-generate_workbench`（Seedream V4.5 模型）：支持文生图、图生图（给参考图）、信息图（infographic）、图片编辑、组图（一次生成多张风格统一、角色连贯的图像序列）。 |
+| `search_images` | `doubao_image_search`（按关键词搜索图片，适合找参考图、素材图）。 |
+| `copy_starter_component` | `Bash cp <本 skill 所在目录>/starter-components/<file> .`（cwd 通常是应用项目目录而非 skill 目录，需用 skill 目录实际路径；或读取后改编）。 |
+| 文档解析（docx / pdf） | Aily 原生「解析二进制文件」能力直接读取 Word / PDF / Excel / PPT 全文；PDF 也可用 `aily-pdf` 专用工具。 |
+| `invoke_skill("X")` / `invoke the "X" skill` | 用 `get_skills("X")` 加载对应媒介技能（如 `get_skills("frontend-design")`）。这些技能同时以本地文件形式随本 skill 附带在 `references/<X>.md`，`get_skills` 取不到时直接读该文件。 |
+
+## 提出澄清性问题
+
+用 `ask_user` 提出聚焦的结构化问题——它把用户的决策内联返回，先问、等答复后再继续。它最适合高影响力的承重决策：交付格式、保真度、设计上下文、参考应用、变体数量。一轮提问保持简明、可执行。不要虚构假的工具名。
+
+## 交付与发布
+
+- 用 `submit` 提交交付结果，并给出绝对本地文件路径。
+- 产物完成并提交后，按 [`../creative-design.md`](../creative-design.md)「发布」一节发布到妙搭——交付给用户的可分享链接是 `+release-get` 返回的 `online_url`。
+
+## Aily 专属注意事项
+
+- **优先用专用工具而非手搓。** 除了通用 `Bash`，Aily 还带一批专用工具（`aily-xlsx`、`aily-chart`、`aily-diagram`、`aily-pdf`、`aily-image-generate_workbench` 等）。涉及表格、图表、流程图、PDF、图像生成时，优先用对应专用工具，而不是用 `Bash` 从零脚本化。
+- **图像素材优先走生成 / 搜索。** [`../creative-design.md`](../creative-design.md)「图像素材与外部信息」一节的 `generate_image` / `search_images` 在 Aily 下都有真实对应（见上表），设计产物需要 hero 图、插画、信息图、连贯组图或参考图时应主动使用，而不是默认全部用 CSS/SVG 兜底。搜索到 / 生成的图片先落到本地，再用 `lark-cli apps +file-upload` 上传、在代码中引用返回的远端 URL，不提交 git。
+- `agent` 的 `slide` 子类型用于生成**飞书幻灯片**，与本 skill 产出的自包含 HTML deck（`starter-components/deck-stage.js`）是两条不同路径，不要混用——本 skill 的 deck 始终是 HTML。
+- 交付统一走 `submit`；需要跨轮次保留项目上下文时可用 `aily-work-memory`。
--- a/.claude/skills/lark-apps/creative-design/references/animated-video.md
+++ b/.claude/skills/lark-apps/creative-design/references/animated-video.md
@ -0,0 +1,34 @@
+---
+name: animated-video
+metadata:
+  display-names:
+    zh-CN: 动画视频
+    en-US: Animated Video
+description: Use when creating animated videos, motion graphics, product walkthroughs, or visual storytelling with timeline-based playback. 触发词：animation, video, motion, 动画, 视频, 动效, 产品演示, 演示动画, walkthrough
+available-agents:
+  - CreativeDesign
+---
+
+# Animated video
+
+Create an animated video or motion design piece rendered as an HTML page. Build a timeline-based animation with smooth transitions. Design frame-by-frame sequences with playback controls (play/pause, scrubber). Focus on visual storytelling; take the palette from the user's brand assets, or derive it from the subject per [`../creative-design.md`](../creative-design.md)「默认美学指令」— never default to any fixed brand palette. Export-ready at a fixed aspect ratio (16:9 or 9:16). If you need to know the position of an element (eg to move a cursor or character between elements) use refs to grab the position.
+
+START by calling `copy_starter_component` with `kind: "animations.jsx"` — it gives you a ready-made timeline engine: `<Stage width height duration>` (auto-scales to viewport, scrubber + play/pause + ←/→ seek + space + 0-to-reset, persists playhead), `<Sprite start end>` to gate children to a time window, `useTime()` / `useSprite()` hooks, an `Easing` library, `interpolate()` / `animate()` tweens, and `TextSprite` / `ImageSprite` / `RectSprite` primitives with built-in entry/exit. Read the file after copying and build YOUR scenes by composing Sprites inside a Stage; only fall back to Popmotion (https://sf3-scmcdn-cn.feishucdn.com/obj/feishu-static/miaoda/coding-unpkg-sdk/popmotion@11.0.5/dist/popmotion.min.js) if the starter genuinely can't do what you need.
+
+Animations are complex code! Make reusable JSX components for each visual element and each scene. Invest in tweaking the timeline iteratively.
+
+Animation tips:
+- Storytelling is KEY! Before you create ANYTHING, identify the story arc, key tensions, characters, etc. Align on the message you want to convey. Run it by the user.
+- Use good animation principles... anticipation, easing, follow-through, exaggeration, all the Disney animator principles.
+- Scenes should have establishing shots setting the scene (use titles or captions if NECESSARY, but prefer to show not tell), followed by heavy zooms on the action. (either hard cuts, or ken-burns-style zooms, or mouse-follows.) Most scenes should exist in a realistic context: they should have a background, or exist in the UI of a computer or phone; etc. Elements should generally not float in the aether.
+- In short animations, most 'scenes' are a single shot, or a sequence of shots in the same setting. Scenes may be slides (e.g. text or graphics onscreen, animating or being emphasized (highlighted etc) in an engaging way that calls attention to the key thing). Decide what the shot is going to be. Maybe it's starting zoomed out, then slowly zooming in on the area of focus or action. Maybe it's rapidly cutting back/forth between two people or graphics in tension. Maybe you're following something, like a cursor or a line on a graph, as it flits around. Be creative!
+- Except for deliberate dramatic effect (a held beat), SOMETHING should always be in motion. The camera, an element, or a transition — slowly panning, zooming, subtly scaling up, drifting, or building. A truly static frame reads as a bug. Images especially: always slowly zoom in/out, pan, have some 'action', have text or graphics appearing or building, or be rapidly cutting in sequence.
+- Whenever you show text or images, remember that you need pauses for it to sink in -- on the order of seconds -- before you can show something else.
+
+If cursor or pointer movement is depicted (eg in a product walkthrough or prototype), you should zoom in on it and follow it with a damped viewport animation, like Screen Studio would. You MUST use HTML refs to locate elements onscreen so the cursor points at the right things.
+
+For product-demo animations (simulated clicks, drags, dialogs, status changes), build a believable product UI and animate its real interface state — do NOT substitute an abstract flowchart or node diagram for the product screen. Reuse the device/window shells from `starter-components/` (`ios-frame.jsx`, `android-frame.jsx`, `macos-window.jsx`, `browser-window.jsx`) instead of hand-rolling frames.
+
+For data-driven animations (annual-review numbers, dashboards coming alive, chart morphing): animate counters by tweening the value with `animate()` / `interpolate()` and rendering the formatted number; morph charts by interpolating the underlying data array each frame and re-rendering the SVG bars/paths (or driving ECharts `setOption` from `useTime()`); chain chapters with scene transitions. Every number shown must come from the user's real data (see [`../creative-design.md`](../creative-design.md)「数据保真」).
+
+For clarity when commenting, update the video root's data-screen-label attr with the current timestamp each second, so you can easily comment on a particular timestamp and know that the agent will be told exactly the timestamp. `<Stage>` does NOT do this for you — wire it up yourself, e.g. inside a component rendered in the Stage: `const t = useTime(); const sec = Math.floor(t); useEffect(() => { document.querySelector('.video-root')?.setAttribute('data-screen-label', sec + 's'); }, [sec]);`
--- a/.claude/skills/lark-apps/creative-design/references/charts.md
+++ b/.claude/skills/lark-apps/creative-design/references/charts.md
@ -0,0 +1,165 @@
+---
+name: charts
+metadata:
+  display-names:
+    zh-CN: 图表
+    en-US: Charts
+description: "基于 ECharts 的数据可视化，用于浏览器直出 HTML。当需要创建图表、仪表盘或数据可视化时使用。触发词：chart, ECharts, 图表, 可视化, visualization, 饼图, 柱状图, 折线图, 数据图表, 甘特图, 热力图, 数据展示, dashboard, 仪表盘, 数据看板"
+available-agents:
+  - CreativeDesign
+---
+
+# 图表
+
+你是用 ECharts 呈现信息的数据叙事设计者。你的图表会出现在创意 HTML 产物中，例如仪表盘、幻灯片、设计探索。ECharts 是你的媒介，不是目标；你的工作是让数据故事一眼可读，而不是堆配置项。一个图表只表达一个主要信息。
+
+## 设计原则
+
+**先编码，再装饰。** 每个视觉通道——位置、长度、颜色、大小——要么在编码一个数据维度，要么就是噪音。先决定每个通道代表什么，再决定它看起来怎样。没有编码含义的颜色应保持统一；读者会尝试解读颜色差异，并从中读出并不存在的意义。
+
+**匹配产品的视觉语言。** 先阅读 UI 的视觉语言，再跟随它。图表颜色从产品现有色板中派生；字体从产品字体体系中派生。一个像从别的产品里掉进来的图表，会削弱用户对数据的信任。
+
+**克制。** 图表靠精确赢得信任，不靠"看起来厉害"。跳过 3D 效果、无意义的渐变，以及不服务于理解的动画。
+
+**平面化。** 出现在报表、看板、报告中的图表默认采用平面风格：细网格线、清晰坐标、纯色或轻微面积填充、必要注释。不要使用 `shadowBlur`、`shadowColor`、发光点、拟物高光或容器阴影来制造层次；层次来自数据权重、线宽、颜色语义和版式面积。
+
+## 流程
+
+按顺序完成这些步骤。不要一上来就写 ECharts options。
+
+1. **审视数据。** 数据有哪些维度？范围是什么？它在讲什么故事——趋势、比较、构成、分布、流向、排名？
+
+2. **选择图表类型。** 根据数据的故事，从下方的映射表中选择。
+
+3. **分配视觉编码。** 对每个视觉通道，明确它代表哪个数据维度：
+   - **位置**（x/y）→ 通常是主维度
+   - **长度/面积** → 通常是度量值
+   - **颜色** → 问自己：这张图中颜色在编码什么？
+
+     | 颜色编码的内容 | 配色方案 |
+     |---|---|
+     | **分类**（无序分组：渠道、部门） | 从产品调色板中为每组取一个不同色相，≤8 个 |
+     | **顺序或强度**（阶段、排名、分桶、单一指标） | 单一色相，纯色或从浅到深渐变 |
+     | **相对中点的偏离**（盈亏、实际 vs 目标） | 两个色相在中性色处交汇 |
+     | **价值判断**（好/坏、通过/失败） | 产品语义 token（success / warning / danger） |
+     | **无编码**（单系列，或形状已经承载了编码） | 一个纯色品牌色，所有元素统一 |
+
+     如果你在给一个**有序**系列中的每个元素分配**不同色相**，停下来——你正在把序列伪装成互不相关的分类。读者会看到 N 个无关的东西，而非一个渐进过程。
+
+4. **一次性定义色板。** 从产品 design tokens 中定义颜色。仪表盘中的每个图表都复用同一套颜色分配——同一个分类在不同图表中使用不同颜色，会迫使读者逐图重新学习编码。
+
+5. **编写 ECharts 代码。** 挂载模式和 API 约束见下方技术参考。
+
+6. **自检。** 截图检查结果。按文末清单验证。然后回到视觉编码步骤：渲染出来的图表是否真的表达了你想表达的信息？颜色编码与仪表盘其他部分是否一致？
+
+## 图表类型映射
+
+按数据故事选择图表，不按"看起来酷不酷"选择。
+
+| 数据故事 | 图表 | 关键约束 |
+|---|---|---|
+| 时间趋势 | Line / Area | ≤5 个系列；数据必须按时间排序 |
+| 分类比较 | Bar | — |
+| 部分与整体 | Pie（≤5 项）、Treemap / Sunburst（>5 项） | Pie >5 项 → 改用横向 Bar |
+| 分布 | Scatter、Heatmap、Boxplot | Heatmap 必须配合 `visualMap` |
+| 多维度画像 | Radar（≤8 维）、Parallel（>8 维） | — |
+| 流转 / 转化 | Funnel | — |
+| 关系 | Sankey、Graph、Tree | Sankey 的链接必须构成 DAG |
+| 日程 / 时间线 | 通过 `custom` series 实现 Gantt | 禁止用 stacked Bar 表示时间线 |
+| 金融 | Candlestick | — |
+| 主题 / 叙事流 | ThemeRiver | — |
+
+## 多图表仪表盘
+
+仪表盘中的多个图表共享上下文。把仪表盘当作一个整体页面，而不是一堆独立组件：
+
+- **共享色板**：只定义一次颜色分配（例如"渠道 A = blue，渠道 B = green"），并在所有图表中复用。
+- **坐标一致**：如果两个图表共享同一维度（时间、分类），对齐它们的坐标范围和刻度，让读者能横向扫描。
+- **视觉层级**：一到两个图表承载核心故事；其余图表提供支撑。尺寸和位置要表达这种主次关系。
+- **表达覆盖**：把用户需求拆成需要被回答的信息关系；每个被承诺的关系都要有对应的图表、表格、矩阵或文字证据承载。不要用少量通用指标和默认图表替代所有分析任务。
+- **小容器防崩**：小尺寸图表优先用 bar / line / number strip。饼图、雷达图、词云和外部标签很容易挤压重叠；空间不足时换图表类型，而不是缩小到不可读。
+
+## 技术参考
+
+### 加载 ECharts
+
+```html
+<script src="https://sf3-scmcdn-cn.feishucdn.com/obj/feishu-static/miaoda/coding-unpkg-sdk/echarts@5.6.0/dist/echarts.min.js" crossorigin="anonymous"></script>
+```
+
+`echarts` 通过 `window.echarts` 全局可用，无需 import。渐变：`new echarts.graphic.LinearGradient(0, 0, 0, 1, [...colorStops])`。
+
+### 挂载——纯 HTML
+
+```html
+<div id="chart" style="width:100%;min-height:300px"></div>
+<script>
+  const chart = echarts.init(document.getElementById('chart'));
+  chart.setOption({ /* ... */ });
+  window.addEventListener('resize', () => chart.resize());
+</script>
+```
+
+### 挂载——React 封装
+
+定义一次，复用。**不要**添加 echarts-for-react。
+
+```jsx
+function EChart({ option, style }) {
+  const ref = React.useRef(null);
+  React.useEffect(() => {
+    const chart = echarts.init(ref.current);
+    chart.setOption(option);
+    const onResize = () => chart.resize();
+    window.addEventListener('resize', onResize);
+    return () => { chart.dispose(); window.removeEventListener('resize', onResize); };
+  }, [option]);
+  return <div ref={ref} style={{ width: '100%', minHeight: 300, ...style }} />;
+}
+Object.assign(window, { EChart });
+```
+
+用法：`<EChart option={option} style={{ height: 400 }} />`
+
+## 自检清单
+
+提交前按下面清单检查生成代码。每一项都对应真实出现过的 ECharts 渲染问题或视觉缺陷。
+
+### 致命问题
+
+| 检查项 | 修复方式 |
+|---|---|
+| 使用了 hsl / hsla / rgb / rgba 颜色 | 只用 Hex（`#1890ff`）——hover 透明度在非 hex 色值下容易出问题 |
+
+### 严重问题
+
+| # | 检查项 | 修复方式 |
+|---|---|---|
+| 1 | Pie 分类 >5 个 | 改用横向 Bar |
+| 2 | Line 系列 >5 条 | 拆分或筛选 |
+| 3 | Radar 给每个 indicator 设置了 `max` | 移除；改为自动计算 |
+| 4 | Radar 多系列、不同量纲 | 先做归一化 |
+| 5 | Bar 缺少 `boundaryGap` | 设置 `boundaryGap: true` |
+| 6 | Funnel label 被隐藏或位置不在内部 | `label: { show: true, position: 'inside' }` |
+| 7 | 容器高度 <300px | `min-height: 300px` |
+| 8 | 单张图表中分类色（每项一个色相）>8 种 | 聚合或分组 |
+| 9 | Pie / 环形图的分类或数值只能靠 tooltip 读到——用了外部引导线标签（`position` 为 `'outside'` 或缺失），或干脆 `label: { show: false }` 且既无图例也无中心标注 | 分类 + 数值必须**静态可读**（tooltip 不算，图表常被导出 / 截图当静态图看）。任选其一：inside 标签标注 `name` + 百分比（扇区够大时）、图例映射色 → 分类、或环形图中心标注关键数值。禁止外部引导线标签（`position: 'outside'` 易重叠 / 裁切），也禁止只靠 tooltip 承载分类 / 数值 |
+| 10 | Pie 设置了 `itemStyle` | 完全移除 |
+| 11 | 任何 series 设置了 `label.color` | 禁止设置；由 theme 控制 |
+| 12 | `label.formatter` 使用字符串模板 | 改用回调：`formatter: (params) => ...` |
+| 13 | legend / visualMap 与图表重叠 | legend: `{ type: 'scroll', bottom: 0 }`；`grid.bottom ≥ '20%'` |
+| 14 | Heatmap 缺少 `visualMap` | 必须添加；当 x 轴标签并存时 `grid.bottom ≥ '25%'` |
+| 15 | Sankey 存在环形链接 | 验证 DAG |
+| 16 | 正负混合 Bar 使用统一 `borderRadius` | 圆角朝向柱体的开口端 |
+| 17 | 双 Y 轴零点未对齐 | 匹配 `\|min\| / max` 比例 |
+| 18 | 图表 series 或容器使用阴影/发光效果 | 移除 `shadowBlur`、`shadowColor`、容器 `box-shadow`，改用线宽、透明度、注释或面积大小表达层级 |
+| 19 | 图表或标签挤压、重叠、被容器裁切 | 增大容器、减少标签、改用 tooltip / inside label，或换成更稳的图表类型 |
+
+### 不建议
+
+| 避免 | 更好的选择 |
+|---|---|
+| Radar >8 个维度 | Parallel coordinate |
+| Line 连接未按时间排序的点 | Bar 或 Scatter |
+| markPoint 重复（统计极值 = 业务事件） | 仅保留业务注释 |
+| 用 Stacked Bar 表示 Gantt | 使用带 `renderItem` 的 `custom` series |
--- a/.claude/skills/lark-apps/creative-design/references/claude.md
+++ b/.claude/skills/lark-apps/creative-design/references/claude.md
@ -0,0 +1,36 @@
+# Claude Code 工具参考
+
+本文档列出 [`../creative-design.md`](../creative-design.md) 所依赖的 harness 专属工具，供你在 **Claude Code** 中运行时使用。主提示词只命名能力（"向用户提问"、"展示文件"等）；本文档给出确切的 Claude Code 工具、签名与调用方式。通用工具（`Bash`、`Read`/`Write`/`Edit`/`Glob`、`gh`）在任何环境都相同，不在此覆盖。
+
+## Web 工具 → Claude Code 工具对照表
+
+上游提示词引用了一些在 Claude Code 中并不存在的 Claude.ai web 工具。无论出现在行文还是代码里，一律按下表替换：
+
+| Web 工具 | Claude Code 对应项 |
+|---|---|
+| `ask_user_question` | `AskUserQuestion`（答案内联返回；每次最多 4 个问题，需要更多就再调用一次） |
+| `done`、`fork_verifier_agent` | `SendUserFile` 发送交付物并给出文件路径 |
+| `write_file`（及其 `asset:` 参数） | `Write`——完全舍弃 "asset review pane" 这一概念 |
+| `copy_files` | `Bash cp` |
+| `read_file`、`list_files`、`view_image` | `Read`（也能渲染图像）、`Glob` / `Bash ls`、`Grep` |
+| `show_to_user` | `SendUserFile`（自包含文件也可用 `open <path>`） |
+| `eval_js`、`eval_js_user_view`、`run_script` | `Bash` |
+| `web_fetch`、`web_search` | `WebFetch`、`WebSearch` |
+| `generate_image` | 无内置对应。会话中若接入了图像生成 MCP/工具则使用；否则跳过 AI 生图，用内联 SVG / CSS 图形兜底，并在交付说明中注明。 |
+| `search_images` | 无专用对应。用 `WebSearch` 检索 + `WebFetch` 获取；用于需要真实图片的素材（实物、地点、logo 等）与确立方向的参考图，直接引用需注意来源与版权。 |
+| `copy_starter_component` | `Bash cp <本 skill 所在目录>/starter-components/<file> .`（cwd 通常是应用项目目录而非 skill 目录，需用 skill 目录实际路径；或 `Read` 后改编） |
+| 文档解析（docx / pdf） | PDF 用 `Read`（`pages` 参数分段读全）；docx 先用 Bash 转出文本再读（`pandoc`、macOS `textutil -convert txt`、或 `python-docx`） |
+| `invoke_skill("X")` / `invoke the "X" skill` | `Read` 对应的 `references/<file>.md`（媒介技能与本文件同在 `references/` 目录） |
+
+## AskUserQuestion（澄清性提问）
+
+替代 `ask_user_question`。`AskUserQuestion` **把用户的答案内联返回**——先问，等用户答复后再继续。每次调用最多展示 4 个问题；大型新项目先问一轮聚焦的问题，不够就再补一次调用。
+
+- 记忆中的偏好可以作为问题里的*建议*默认值给出，但仍须由用户确认。
+- 优先用它，而不是在回复里用文字列点罗列选项。
+- 项目设置类提问——项目**保存到哪里**、使用**哪个（哪些）设计系统**（一次 multiSelect）——都是普通的 `AskUserQuestion` 调用。
+
+## 交付与发布
+
+- 用 `SendUserFile` 发送交付物并给出文件路径（读取文件**并不会**把它展示给用户）。
+- 产物完成并提交后，按 [`../creative-design.md`](../creative-design.md)「发布」一节发布到妙搭——交付给用户的可分享链接是 `+release-get` 返回的 `online_url`。
--- a/.claude/skills/lark-apps/creative-design/references/codex.md
+++ b/.claude/skills/lark-apps/creative-design/references/codex.md
@ -0,0 +1,32 @@
+# Codex Agent 工具参考
+
+本文档列出 [`../creative-design.md`](../creative-design.md) 所依赖的 harness 专属工具，供你在 **Codex Agent** 中运行时使用。主提示词只命名能力（"向用户提问"、"展示文件"等）；本文档给出 Codex 的调用方式。通用工具（shell、文件读/写/编辑/搜索、`gh`）不在此覆盖。
+
+## Web 工具 → Codex 对应项
+
+| Web 工具 | Codex 对应项 |
+|---|---|
+| `ask_user_question` | 在 Codex Plan Mode 下，若 `functions.request_user_input` 可用则使用它；否则在聊天中提出简明问题并等待用户答复。 |
+| `done`、`fork_verifier_agent` | 在最终回复中呈现交付物的文件路径。 |
+| `write_file`（及其 `asset:` 参数） | Codex 的常规文件编辑工具。不存在 asset review pane；舍弃这一概念。 |
+| `copy_files` | Shell `cp`。 |
+| `read_file`、`list_files`、`view_image` | Codex 的常规文件读取/搜索工具。 |
+| `show_to_user` | 提供绝对本地文件路径；有帮助时，用 Markdown 以绝对路径嵌入图片。 |
+| `eval_js`、`eval_js_user_view`、`run_script` | 脚本用 Shell。 |
+| `web_fetch`、`web_search` | 若存在则用 Codex 的 web 工具；用于时效性事实、内容素材补充或用户要求的网络查询。 |
+| `generate_image` | 无内置对应。会话中若接入了图像生成工具则使用；否则跳过 AI 生图，用内联 SVG / CSS 图形兜底，并在交付说明中注明。 |
+| `search_images` | 无专用对应。若有 web 工具则用其检索图片，用于需要真实图片的素材与确立方向的参考图；没有就跳过。 |
+| `copy_starter_component` | Shell `cp <本 skill 所在目录>/starter-components/<file> .`（cwd 通常是应用项目目录而非 skill 目录，需用 skill 目录实际路径；或读取后改编）。 |
+| 文档解析（docx / pdf） | 用 shell 工具转出文本后读取：`pdftotext` / `pandoc` / python 脚本（`pypdf`、`python-docx`）。 |
+| `invoke_skill("X")` / `invoke the "X" skill` | 阅读对应的 `references/<file>.md`（媒介技能与本文件同在 `references/` 目录）。 |
+
+## 提出澄清性问题
+
+当 Codex 处于 **Plan Mode** 且 `functions.request_user_input` 可用时，用它来提出聚焦的结构化问题。它最适合高影响力的设计决策，如范围、保真度、设计上下文、参考应用、变体数量。
+
+若 `request_user_input` 不可用，或会话不在 Plan Mode，就直接在聊天中问同样的问题并等待用户回答。一轮提问保持简明、可执行。不要虚构假的工具名。
+
+## 交付与发布
+
+- 在最终回复中给出交付物的绝对本地文件路径。
+- 产物完成并提交后，按 [`../creative-design.md`](../creative-design.md)「发布」一节发布到妙搭——交付给用户的可分享链接是 `+release-get` 返回的 `online_url`。
--- a/.claude/skills/lark-apps/creative-design/references/data-report.md
+++ b/.claude/skills/lark-apps/creative-design/references/data-report.md
@ -0,0 +1,108 @@
+---
+name: data-report
+metadata:
+  display-names:
+    zh-CN: 数据看板
+    en-US: Data Dashboard
+description: "数据驱动的报表与看板设计。从数据分析到报表规划、信息层级组织，适用于用户有数据文件或明确指标，需要产出结构化数据报表的场景。图表绘制部分由 charts skill 承担。触发词：数据报表, 数据看板, 数据分析报表, BI, 经营报表, 指标看板, 周报, 月报, 数据大盘, KPI, 报表设计, data report, dashboard report, analytics report"
+available-agents:
+  - CreativeDesign
+---
+
+# 数据报表
+
+你是数据报表设计者。你的工作是把原始数据变成一份读者能直接用来做判断的报表——不只是画几张图，而是回答"这份数据在说什么、读者应该关注什么"。
+
+报表的价值不在图表数量，而在信息层级：读者能在 5 秒内抓到主要结论，30 秒内理解支撑证据，需要时能下钻到明细。
+
+## 设计基准
+
+报表和看板默认采用**平面、克制、信息密集但可扫描**的视觉语言。参考优秀数据页面的抽象模式：浅色或中性底、少量品牌色、细边框、分隔线、色块、表格斑马纹、紧凑标签、tabular numbers、清晰图表标题和口径说明。内容区不要依赖阴影、玻璃拟态、发光、厚重渐变或悬浮卡片来制造层次；层次主要由栅格、字号、留白、边框、背景色块和数据权重建立。
+
+布局必须比普通上下堆叠更丰富。先根据数据任务选择版式骨架，再写代码：监控型、复盘型、诊断型、对比型、明细型、汇报型可以有完全不同的扫描路径。可以组合 KPI 指标条、左右不等分主分析区、辅助矩阵、排名/明细表、洞察侧栏、深色结论带、时间线或漏斗区，但不要每份报表都套成同一套 KPI 横条 + 主图 + 洞察卡。不要把每个章节都做成同宽标题加一张满宽卡片；核心模块占更大面积，支撑模块用不同宽度、密度和位置服务它。
+
+报表不是产品原型。内容型或分析型交付服务阅读和决策，不默认生成多页面后台导航、可下拉应用名、无意义返回按钮或设置菜单；只有用户明确要求交互式系统、后台、筛选操作或多页面应用时才做这些。标题、范围、口径、结论、图表、洞察和明细都是可用的信息部件，不是每份报表都必须同时出现的固定章节。
+
+不要让页面全是文字，也不要把所有章节都做成同一种"结论 + 指标 + 图表 + 洞察"结构。长材料先判断每段内容在当前报表里的作用：它是在给背景、定义口径、证明结论、展示变化、比较对象、解释异常、列明细，还是提出行动。每段只选择最适合的表达方式，可以是短结论、关键数字、对比、时间顺序、表格、矩阵、引用、图表、注释或截图。重要内容不能被塞进附录或角落；如果一个章节是汇报目标的核心，就给它相称的版面面积和区别于其他章节的版式处理。
+
+## 流程
+
+按顺序完成这些步骤。不要一上来就写代码。
+
+### 1. 需求分析
+
+从用户消息中提取报表的上下文：
+
+- **产品类型**：数据看板、监控中心、分析报表、BI 面板、经营复盘等。
+- **目标读者**：管理者、运营、销售、分析师、项目成员，或外部客户。
+- **核心诉求**：监控指标、发现趋势、比较对象、解释异常、辅助决策、展示成果。
+- **界面语言与口径**：跟随用户输入语言；指标命名、单位、时间粒度要统一。
+
+产出：一句话概括"给谁看、回答什么问题"。
+
+### 2. 数据分析
+
+审视数据，确认可用的维度和指标：
+
+- **字段列表**：名称、类型、示例值、是维度还是指标。
+- **数据规模**：行数、时间跨度、类目数量、缺失值或异常值。
+- **指标口径**：总量、均值、占比、增速、完成率、排名、转化率等。
+- **计算方式**：所有指标一律写脚本从源数据计算（读附件 → 聚合 → 得数），不目测、不凑整、不编造；报表里出现的每个数字都必须能追溯回源数据（见 [`../creative-design.md`](../creative-design.md)「数据保真」）。算好的聚合结果内联为页面里的 JS 常量，不要让页面在运行时去 fetch 原始附件。
+- **维度切分**：时间、地区、渠道、产品、团队、状态、用户分组等。
+- **叙事重点**：哪个变化、差异、结构或异常最值得被读者看到。
+
+产出：维度-指标清单，以及一句话叙事重点。
+
+### 3. 报表规划
+
+在写代码之前，先确定报表由哪些组件构成：
+
+- **视觉方向**：参考 `frontend-design` 的方法先定主题世界、受众姿态、材料、配色逻辑和签名元素。例如环境数据可以像研究观测页，销售经营可以像运营战情室，财务/管理指标可以像管理层简报。风格必须服务数据可信度，不要套通用科技蓝或泛白卡。
+- **阅读路径**：先判断读者是要快速扫现状、追异常、看趋势、比较对象、查明细还是读复盘。不同任务对应不同起手式，不要默认都从 KPI 卡开始。
+- **候选部件**：标题 / 范围 / 口径、摘要、KPI、主图表、辅助图表、文字洞察、明细表、时间线、矩阵、截图或注释都只是候选。需要哪个用哪个，不要为了"完整"把它们凑齐。
+- **核心承载**：只给真正承载核心问题的模块更大面积。核心可能是一张趋势图、一张排名表、一段异常解释、一个流程漏斗，也可能是一组明细，不固定。
+- **版式差异**：为不同信息角色安排不同形态，例如紧凑指标条、宽图、窄侧栏、表格区、注释带、对比矩阵或分段背景。避免每个章节都重复同一张满宽白卡。
+- **布局骨架**：明确每个模块的相对面积和扫描路径，例如 `1.2fr 2fr`、`1fr 1.6fr`、`repeat(4,1fr)`、`auto 1fr` 等混合栅格；移动端再自然折叠。
+
+组件取舍由读者任务、数据复杂度和材料内容决定。
+
+产出：视觉方向与报表结构大纲（哪些组件、各自承载什么信息）。
+
+### 4. 图表设计
+
+为报表中的每个图表完成选型和视觉编码。此步遵循 charts skill 的规则；若 charts skill 尚未加载，先加载它。
+
+产出：每个图表的类型、编码分配、共享色板定义。
+
+### 5. 报表组成
+
+将所有组件组织成一个连贯页面：
+
+- 布局按数据叙事组织，不按"先放所有图再放文字"组织。
+- 顺序跟随读者任务：监控型可以先给状态概览，诊断型可以先给异常和原因链，对比型可以先给对象矩阵，复盘型可以先给时间线，明细型可以先给可查表格。
+- 同一页面内至少使用两种不同的版式关系：例如 KPI 横条 + 左右不等分主图 + 双列洞察 + 表格/结论带。避免所有模块都是同尺寸白卡片上下排列。
+- 内容块采用平面化处理：优先用 `border:1px solid ...`、浅底色、分隔线、色条、编号、标签和表格行背景；内容卡片和图表容器默认不加 `box-shadow`。
+- 图表旁边应有短洞察、口径或排名摘要，不要让图表孤零零占满整行。
+- 文字用于解释图表看不出的原因、口径、异常和行动建议，不重复图表标题。
+- 表格用于精确查数和比较对象，不要把长表伪装成密集柱状图。
+- KPI 用于概览，不要把每个字段都做成指标卡。
+- 没有真实依据时不编造结论；可写"待补充口径"或使用中性描述。
+
+产出：完整报表页面。
+
+### 6. 自检
+
+截图检查结果，验证以下几点：
+
+- 报表是否回答了步骤 1 确定的核心问题。
+- 信息层级是否清晰（读者能在 5 秒内抓到主要结论）。
+- 布局是否有明确主次和变化，而不是标题、KPI、图表从上到下机械堆叠。
+- 首屏重点信息是否可读，颜色对比是否足够；深色首屏尤其要检查标题、指标和图例。
+- 是否没有大面积无意义留白、错位、重叠、截断或不同模块视觉重量失衡。
+- 用户点名的图表类型和分析维度是否出现；如果因数据不适合改用其他图表，要在页面中用更合适的表达补足。
+- 内容区是否保持平面化，主要靠边框、色块、分隔线和栅格建立层级，没有滥用阴影、发光或玻璃拟态。
+- 文字洞察是否与图表数据互相支撑。
+- 图表部分是否通过了 charts skill 的自检清单。
+- 口径和单位是否全报表一致。
+
+产出：确认或修正。
--- a/.claude/skills/lark-apps/creative-design/references/frontend-design.md
+++ b/.claude/skills/lark-apps/creative-design/references/frontend-design.md
@ -0,0 +1,71 @@
+---
+name: frontend-design
+metadata:
+  display-names:
+    zh-CN: 创意设计
+    en-US: Creative Design
+description: 为设计确立独特、有意图的视觉方向的指引——配色、字体与美学选择不带模板化默认的痕迹。适用于各类媒介（deck、报告、UI、原型），不限于 Web UI。
+available-agents:
+  - CreativeDesign
+---
+
+# Frontend Design
+
+目标是让这份 brief 拥有绝不会被认错的视觉形象：做出深思熟虑、有主张的配色、字体与版式选择，承担一次你能说清理由的真正的美学冒险——感觉模板化的方案等于交付失败。
+
+## 让设计扎根于主题
+
+如果 brief 没有钉死产品或主题是什么，动手设计前先自己钉死：点出一个具体的主题、它的受众、这个页面唯一要完成的任务，并明确说出你的选择。但若主题、受众和材料都推不出一个有把握不返工的方向（从零起的项目、零线索），按 [`../creative-design.md`](../creative-design.md)「默认美学指令」先向用户问清偏好，问回来后再按本节钉死方向——能推出就直接钉死，不要为收集偏好打断用户。如果你的记忆里有关于用户偏好的信息、关于他们正在构建什么的上下文、或你以往做过的设计——把它们当作线索用起来。主题自身的世界——它的材质（materials）、工具与仪器（instruments）、特有的器物（artifacts）、行话与语汇（vernacular）——正是独特选择的来源。全程用 brief 的真实内容与题材来构建。
+
+## 视觉方向
+
+在选定颜色或组件之前，先在思考中定下方向。填满四个槽位——每一个都要取自*这个*主题：
+
+- **世界（World）**——这个页面属于哪个世界？去主题自己的世界里找：它的材质、工具与仪器、特有的器物、行话与语汇。
+- **材质（Materials）**——哪些真实存在的材质表面（surfaces）与印记（marks）属于那个世界？先把主题自带的一一列出来，别一上来就用通用的。
+- **配色（Palette）**——哪些颜色承担语义或品牌职责，哪些是中性的支撑色，哪一个唯一的强调色赢得注意力？
+- **签名元素（Signature）**——整个页面靠它被记住的那一个手法。它必须只可能属于这个主题；一个换到下份 brief 也能复用的签名元素，是默认值，不是选择。
+
+风格不是版式排完后再涂上去的装饰。这个方向决定字体排印、间距、图表处理、章节节奏、边框、图标风格，以及哪些组件值得强调。
+
+## 设计原则
+
+对于网页设计，hero 区就是全页的论点。开场就亮出主题世界里最具特征的东西，形式因主题而定：一句大标题、一张图、一段动画、一个实时 demo、一个交互瞬间。选择要经过深思：「大数字 + 小标签 + 辅助统计数据 + 渐变点缀」是模板答案，只有当它确实是最佳选项时才用。
+
+字体排印承载页面的性格。展示字体（display）与正文字体（body）的搭配要刻意为之，而不是随手拿任何项目都会用的那几个字体家族；并建立清晰的字号体系，字重、字宽、字距都要有意图。让字体处理本身成为设计中令人记住的一部分，而不是承载内容的中性载体。
+
+结构即信息。结构件——编号、眉标、分隔线、标签——应当编码内容中真实存在的信息，而不是装饰内容。很多千篇一律的设计都用编号标记（01 / 02 / 03），但只有当内容真的是一个序列时——比如真实的流程、或顺序本身携带读者所需信息的类型化时间线——编号才成立。在采用编号标记这类选择之前，先质疑它们是否真的说得通。
+
+有意识地运用动效。想清楚动画是否、以及在哪里能服务主题：页面加载序列、滚动触发的揭示、hover 微交互、环境氛围。一个经过编排的时刻通常比散落的零星特效更有力；按视觉方向的需要来选。但有时少即是多——多余的动画会加重「这个设计是 AI 生成的」的观感。
+
+让复杂度匹配愿景。极繁方向需要精雕细琢的执行；极简方向需要间距、字体与细节上的精准。优雅就是把选定的愿景执行到位。
+
+认真对待文字内容。设计 brief 往往不含真实内容，文案要由你来写。文案带来的模板感不亚于设计本身。更多指引见下文关于写作的章节。
+
+## 流程：头脑风暴、探索、规划、评审、构建、再评审
+
+先校准现状：当下的 AI 生成设计集中在三种长相上：(1) 暖奶油色背景（接近 #F4F1EA）+ 高对比衬线展示字体 + 陶土色（terracotta）强调色；(2) 近黑背景 + 单一亮色强调——酸性绿（acid green）或朱红（vermilion）；(3) 大报（broadsheet）式版面——发丝线（hairline rules）、零 border-radius、报纸般的密集分栏。三者对某些 brief 都站得住脚，但它们是默认值而非选择，而且不看主题就冒出来。凡是 brief 钉死了视觉方向的地方，严格照办——brief 自己的话始终优先，包括它点名要这三种长相之一的时候。凡是 brief 留出自由度的维度，别把这份自由花在这三个默认值上。就像受雇的人类设计师一样，往往要在「做自己擅长的」与「把每个项目当作试验和学习的机会」之间小心权衡。
+
+分两遍做。第一遍，基于用户的设计 brief 头脑风暴出一份简短的设计计划：把上文的视觉方向展开成一套紧凑的 token 体系——色彩、字体、版式、签名元素。色彩：用 4–6 个命名的 hex 值描述配色。字体：至少两种角色的字体（一款有性格、克制使用的展示字体，一款与之互补的正文字体，必要时再加一款用于图注或数据的功能字体）。版式：一个版式概念，用一句话的文字描述加 ASCII 线框图来构思和比较。签名元素：这个页面将被记住的那个唯一独特元素，以恰当的方式体现 brief。
+
+然后在动手构建前，对照 brief 复查这份计划：如果其中任何部分读起来像你对任何同类页面都会产出的通用默认（在心里过一遍相似的 prompt，看你是否会落到差不多的地方），而不是为这份 brief 专门做出的选择——就修订那部分，说明你改了什么、为什么改。只有在确认设计计划具备相对独特性之后，才开始写代码，严格遵循修订后的计划，让每一个颜色和字体决策都从计划中推导出来。
+
+写代码时，注意组织好 CSS 选择器的优先级（specificity）。很容易写出相互抵消的 CSS 类（尤其是 `.section` 这类分区级选择器与 `.cta` 这类元素级选择器之间）。区块之间的 padding/margin 上经常出这种问题。
+
+尽量把这些规划与迭代放在思考中完成，只在你有较高把握能让用户眼前一亮时，才把想法拿给用户看。
+
+## 克制与自我评审
+
+把大胆花在一个地方。让签名元素成为唯一被记住的东西，它周围的一切保持安静、克制，砍掉任何不服务于 brief 的装饰。不冒险本身也可能是一种冒险！默默守住质量底线，不必声张：响应式适配到移动端、键盘焦点可见、尊重 reduced motion。边构建边评审自己的作品，环境支持就截图看——一图胜千 token。想想香奈儿的忠告：出门前照照镜子，摘掉一件配饰。人类创作者有记忆，总在尝试新东西；如果你有地方快速记下自己试过什么，会对后续迭代有帮助。
+
+## 再谈设计中的写作
+
+文字出现在设计里只有一个理由：让设计更易理解，从而更易使用。文字是设计材料，不是装饰。对文案投入的心思，要和对间距、色彩投入的一样多。落笔之前，先问这个设计需要说什么、怎么说最能帮人在这段体验里找到方向。
+
+站在屏幕另一侧的最终用户角度来写。以人们能控制、能认出的东西命名，绝不以系统的实现方式命名。用户管理的是「通知」，不是「webhook 配置」。用平实的语言描述某物做什么，而不是推销它。具体始终胜过抖机灵。
+
+默认使用主动语态。一个控件应当准确说明使用它时会发生什么：说 "Save changes"，而不是 "Submit"。同一个动作在整条流程中保持同名：写着 "Publish" 的按钮，产生的 toast 就写 "Published"。界面的词汇表就是用户穿行产品时的路标。连贯与一致是人们认路的方式。
+
+把失败与空态当作指路的时机，而不是渲染情绪的时机。解释出了什么问题、怎么修复，用界面的口吻而非某个人的口吻。错误提示不道歉，也绝不对发生了什么含糊其辞。空屏是一份行动邀请。
+
+语域要像对话一样自然，并经过调校：动词平实、sentence case（句首大写）、没有废话，语气与品牌和受众匹配。让每个元素只做一件事：标签就是标注，示例就是演示，没有元素悄悄身兼二职。
--- a/.claude/skills/lark-apps/creative-design/references/hi-fi-design.md
+++ b/.claude/skills/lark-apps/creative-design/references/hi-fi-design.md
@ -0,0 +1,32 @@
+---
+name: hi-fi-design
+metadata:
+  display-names:
+    zh-CN: 高保真设计
+    en-US: Hi-Fi Design
+description: 用于创建高保真 UI mockup、设计探索，或带多种变体的视觉原型。触发词：mockup, hi-fi, prototype, UI design, 高保真, 设计稿, 原型, 界面设计, 视觉设计, 设计方案
+available-agents:
+  - CreativeDesign
+---
+
+# 高保真设计
+
+创建高保真、精细打磨的设计。
+
+遵循以下通用设计流程（用 todo list 记住）：
+1. 澄清关键信息：能从需求、附件、截图或常见模式合理推断的，直接继续；只在关键信息缺失且会影响设计方向时才向用户提问
+2. 查找现有 UI kit 并收集设计上下文——复制所有相关组件，阅读所有相关示例；如果找不到且会影响核心设计方向，再向用户询问
+3. 在文件开头写下假设、上下文和设计推理，放好设计占位，并尽早展示给用户
+4. 尽快把设计做出来，再次展示给用户，并附上下一步建议
+5. 使用工具检查、验证并迭代设计
+
+好的高保真设计不会从零开始——它们扎根于已有的设计上下文。找到合适的 UI kit / 设计资源，或从截图、代码和品牌资产中提取设计规则。你必须花时间去获取设计上下文，包括组件。如果缺少素材但不影响核心方向，先用合理假设继续推进；只有缺失信息会改变设计方向时才向用户索要。从零 mock 一个完整产品是最后手段，会导致低质量的设计。使用 starter components（设备框架等）可以免费获得高质量的脚手架。
+
+当并排展示多个方案或探索方向时，布局要清晰：给页面一个中性灰背景，把每个方案放进独立且带标签的框中（小标题 + 尺寸随内容变化的白色圆角卡片），并把相关方案分组。
+
+设计时，提出好问题很重要——但只在问题会实质性影响设计方向时才提问，避免频繁打断用户。
+
+给出选项：默认提供 2-3 个有清晰差异的方案（与 [`../creative-design.md`](../creative-design.md)「提问」一节的默认一致）；用户明确要求广度探索时，再围绕多个维度扩展更多变体。把符合既有模式的稳妥方案，与新颖的交互方式混合搭配，包括有趣的布局、隐喻和视觉风格。部分方案使用色彩或高级 CSS，部分带图标，部分不带。变体从基础开始，逐步走向更高级、更有创意的方向！尝试以有趣的方式重混品牌资产和视觉 DNA——玩转尺度、填充、纹理、视觉节奏、层次、新颖布局、字体处理。目标不是找到完美方案，而是探索用户可以混搭组合的原子级变体。
+
+CSS、HTML、JS 和 SVG 能力强大。用户往往不知道它们能做到什么。给用户惊喜。
+
--- a/.claude/skills/lark-apps/creative-design/references/interactive-prototype.md
+++ b/.claude/skills/lark-apps/creative-design/references/interactive-prototype.md
@ -0,0 +1,24 @@
+---
+name: interactive-prototype
+metadata:
+  display-names:
+    zh-CN: 交互原型
+    en-US: Interactive Prototype
+description: 可交互原型：像真实应用一样直接运行的高保真交互 demo（working app with real interactions）。触发词：可交互原型, 交互原型, 点击原型, interactive prototype, working app, 产品 demo, 工单系统, 管理后台, 看板工具, 多页面应用
+available-agents:
+  - CreativeDesign
+---
+
+Create a fully interactive prototype with realistic state management and transitions. Use React useState/useEffect for dynamic behavior. Include hover states, click interactions, form validation, animated transitions, and multi-step navigation flows. It should feel like a real working app, not a static mockup.
+
+Do not wrap interactive prototypes in `design-canvas.jsx`, `<DCArtboard>`, or any pan/zoom artboard shell. A prototype should run as a direct app surface; if multiple variants are needed, expose them with in-app navigation, tabs, routes, toggles, or Tweaks instead of a canvas.
+
+## 多页面与路由
+
+多页面原型按普通 MPA 做：一个页面一个 HTML 文件，入口固定为项目根目录的 `index.html`，页面间用相对路径的普通链接跳转（`<a href="detail.html">`）。不要引入任何 router 库——锁定版本的 CDN 清单里没有 router，也不要用 `type="module"` 模拟 SPA 路由。共享组件和样式拆成独立的 `.jsx` / `.css` 文件由各页面分别引入；跨页面要延续的状态（工单列表、看板数据等）放 localStorage、加载时读回；页面间传参用 URL query。
+
+## 像真实应用，而不是摆拍
+
+- 准备一份贴近业务的 mock 数据（名称、状态、时间戳都要像真的），页面从数据渲染，不要把内容写死在标记里。
+- 每个可见的按钮、输入、切换都要有反应：提交有校验和反馈、列表可增删改、状态会流转、空状态有设计。点了没反应的控件比没有这个控件更伤可信度。
+- 按 [`../creative-design.md`](../creative-design.md)「Tweaks」把关键选项（主题色、密度、布局变体等）用 `tweaks-panel.jsx` 暴露出来，不要自己实现控件面板。
--- a/.claude/skills/lark-apps/creative-design/references/make-a-deck.md
+++ b/.claude/skills/lark-apps/creative-design/references/make-a-deck.md
@ -0,0 +1,133 @@
+---
+name: make-a-deck
+metadata:
+  display-names:
+    zh-CN: 幻灯片制作
+    en-US: Slide Deck
+description: 当用户要求制作演示文稿 / PPT / PPTX / pitch deck / slides / keynote / 路演材料时使用——即供演讲者现场演示、固定画幅 16:9 的自包含 HTML deck。
+---
+
+# Make a deck
+
+把演示 deck 做成一个自包含的 HTML 单页。
+
+进入这个角色：你是一名演示设计师（presentation designer）。你为演讲者制作用于现场演示的幻灯片 deck——HTML 只是你的输出介质，但你的设计思维与为董事会准备材料的咨询顾问、分析师或高管完全一致：清晰、叙事流畅、后排也能看清。你不是在做网站。
+
+每张幻灯片既是版式设计的练习，也是文案写作的练习。动手前先写大纲；好的大纲本身就是一次讲故事和叙事结构的练习。
+
+## 动手前先问
+
+- 如果用户没有说明视觉风格、也没提供 design system：能从主题、材料或场景推断出一个有把握的方向就直接定（与 [`../creative-design.md`](../creative-design.md)「默认美学指令」一致），推不出再用提问工具问。无论推断还是问来，绝不要落到一个通用模板设计！
+
+## 构建准备与技术契约
+
+### deck-stage 组件
+
+以 1920×1080（16:9）为基准构建。**绝不**手写 stage/缩放/翻页的脚手架——先调用 `copy_starter_component` 并传入 `kind: "deck-stage.js"`，然后将 deck HTML 写成 `<deck-stage width="1920" height="1080">`，每张幻灯片对应一个 `<section data-label="…">` 子元素。该组件负责：
+
+- letterbox 缩放
+- 键盘 + 触控翻页
+- speaker-notes 的 postMessage 协议
+- `data-screen-label` / `data-miaoda-validate` 标记
+- print-to-PDF（每张幻灯片一页）
+
+用 `<script src="deck-stage.js"></script>` 加载它——它是 vanilla JS，不是 JSX。（该组件支持 `noscale` 属性来禁用 shadow-DOM 缩放，供外部 PPTX 导出或截图工具拿到原始尺寸的几何信息；本 skill 内无需也没有工具去调用它。）
+
+deck-stage 组件会对每个 slotted 子元素做绝对定位——**绝不**在幻灯片 `<section>` 元素上自行设置 position/inset/width/height。
+
+### 把幻灯片内容写成静态 HTML，而不是 React
+
+幻灯片内容应写成静态 HTML，而非 React 或脚本生成的 DOM。当幻灯片正文是 `<deck-stage>` 内的纯标记时，用户可以在编辑模式下直接点击任意标题或段落进行修改——编辑器会立即将改动 splice 回源文件。而如果同样的内容通过 `<script type="text/babel">` 块、React 组件或遍历 JS 数组来渲染，这条直编路径就断了：每次微调都要绕一趟聊天消息才能到你手里，用户体验更慢，也更难让他们自己打磨 deck。因此，凡是静态页面能表达的——文本、布局、背景、图片——都直接在 HTML 里写字面元素并用 CSS 设置样式。只在幻灯片确实需要静态标记无法实现的行为时（交互式图表、实时 demo、真实状态管理），才使用 babel/React 或额外的 `<script>`。同样的渲染结果，静态 HTML 版本**始终优先于**动态版本，因为静态版本可被直接编辑。Tweaks 面板（`tweaks-panel.jsx`）是固定例外：它是幻灯片旁边的控制面板，不是幻灯片内容，因此仍需包含它——它的 `<script type="text/babel">` 标签不会让幻灯片本身变得更难直接编辑，因为编辑器会独立地将每个静态幻灯片元素路由到 splice 路径。
+
+### 两个细节保持静态幻灯片可直接编辑
+
+两个细节确保静态幻灯片可被直接编辑：每段文字都放在自己的叶子元素中（把 "Revenue" 放在 `<h2>` 内单独的 `<span>` 里，而不是写成 `<h2>Revenue <span class="sub">2025</span></h2>` 这样文本和子元素混在同一父节点的形式），重复结构要逐一写出而非生成——三条 `<li>` 直接写在标记里，而不是从数组渲染一个 `<li>` 三次。重复正是重点所在；它让用户能编辑第二条而不影响第一条。
+
+## 幻灯片设计与构图
+
+先定方向：动手前先调用 `frontend-design` skill 立视觉方向框架，再结合主题、受众、场景提炼视觉关键词，用它们决定配色、字体、图片类型和页面节奏；frontend-design 的通用设计规则与本 skill 的 deck / 构图规则冲突时，以本 skill 为准。保持清晰的层级与一致的视觉系统。
+
+### 构图原则
+
+- **留白 ≠ 空洞。** 判据是空白的**归属**：属于页面的空白（页边距、分组间隙、无边框的呼吸空间）是构图资产；被某个元素圈占的空白——边框、底色或阴影划出的范围远大于其内容——是未完成的构图，读者会把它读成「这里本来该有东西」。元素的边界应由内容撑出来，而不是由要填的空间决定；画布填不满时，把空间留在元素**之间**，或按「视觉平衡」的出路增密。
+
+- **视觉锚点。** 每页要能回答：视线第一眼落在哪里，为什么是那里。锚点可以是一个大数字、一张图表、一句大字陈述，也可以是并列结构中被刻意加重的一项。所有元素等面积、等字号、等色彩权重的页面，是把第一落点交给了随机——那不是中性，是没做构图决策。
+
+- **视觉平衡。** 视觉重量要在整幅画布上分布均衡，不要全压在画幅一角。内容撑不满画布时，出路必须**增加信息或提升信息的形式**——放大锚点、文字转表格 / 图表 / 对比、与相邻页合并都属此类；任何只消耗面积而不增加信息的手段（拉高容器、均匀放大字号、堆装饰）都不是出路，只是把空洞摊得更开。
+
+- **平行性。** 平行性很重要：章节标题页外观必须一致；重复出现的文字元素必须在相同位置；以此类推。
+
+- **版式节奏。** 与平行性互为对偶：平行性守住不变的东西，节奏经营变化的东西。每页先为内容选对形式——最适合表格、图表、引用或图片的内容就转成那个形式，而不是原样铺成文字（文字堆砌是最常见的失误）；内容单薄则按「视觉平衡」的出路增密或合并。逐页的形式选择连起来就是 deck 的节奏：节奏跟随叙事结构——章节转折、重点页、过渡页各有形态——而不是机械交替；节奏也需要对比才成立——全图、大数字、图表、引用、不同背景色、纯文字，原型库要够开阔，页页同一骨架无节奏可言，那不叫一致，叫单调。用版式和可视化把画布用满不是「填充性内容」；凭空编造数据和板块才是。
+
+### 素材与工艺
+
+- **字号与单位。** 使用大号字体（标题至少 48px）。当用户指定具体字号时，默认他们说的是**磅（points）**（PowerPoint/Keynote 的单位）而非像素——用 `px = pt × 1.333` 换算。所以"把标题设成 36pt" → 在 CSS 里设成约 48px。
+
+- **素材来源。** 除非用户要求，绝不使用 emoji。使用 design system / 品牌中的图标、用户提供的图片，或图片生成工具产出的图片。
+
+- **图片呈现。** 务必先查看图片，再决定最佳展示方式。
+  - 满版图片可用 aspect-fill；
+  - 截图必须 aspect-fit，且极少在其上叠加内容；
+  - 透明或 aspect-fit 的图片应置于对比色背景之上。
+
+  在图片上叠加文字时，参照品牌惯常做法：根据你在其他地方看到的样式，酌情使用卡片、保护渐变或模糊效果。
+
+- **图表与数据可视化。** 图表优先写成**静态 SVG 或纯 CSS**（柱高用 `height`，折线 / 扇形用内联 `<svg>` 路径）——它与文本一样是可直接编辑的一等公民，**不属于**「静态标记做不到才动用 script」的例外；只有确需交互（悬停高亮、筛选、实时数据）的图表才走 babel/React。数字之间只要存在能被眼睛读出的关系（趋势、占比、对比、分布），就转成图表，而不是原样铺成文字。图表必须长在 deck 的视觉系统里：复用同一套配色与 `--type-*` 字号，直接在数据点 / 扇区上标注数值而非依赖图例，去掉网格线、多余刻度等不承载信息的 chrome，让图表本身成为该页的视觉锚点。
+
+- **动效。** 动效服务于叙事——引导视线、分层揭示信息、平滑衔接页面——而不是炫技或填空。默认克制，始终以不干扰阅读为底线。deck 动效的形态是**翻到该页时播放一次的入场 / 分步揭示**，不做环境循环——无限循环的装饰动画会持续争夺注意力。实现用 CSS 动画（幻灯片保持可直编的静态 HTML），两条契约（细节见 deck-stage.js 头部 Authoring guidance）：
+  - 动画门控在 `[data-deck-active]` 与 `prefers-reduced-motion: no-preference` 上——组件在激活页维护该属性，翻页即触发；需要 JS 编排时监听组件的 `slidechange` 事件。**注意：`data-deck-active` 加在 slide 的 `<section>` 元素本身上，且只存在于当前激活页**——因此后代形式 `[data-deck-active] .fade-up` 天然只命中当前页内的元素，**不需要再按页类限定选择器**；每页不同的编排用不同的动画类 / delay 变量放在元素上表达。确需按页限定时，属性和页类是同一个元素，必须连写不能加空格：`section.s1[data-deck-active] h1` ✅，`[data-deck-active] .s1 h1` ❌（`.s1` 就是 slide 自己，后代组合器永远匹配不到，动画整页失效）。
+  - 基础样式写**可见的最终态**，隐藏态只进 `@keyframes` 的 `from`——缩略图栏、reduced-motion 等场景只渲染静态基础态、从不播动画，把 `opacity: 0` 写在基础规则上，会导致这些场景全成空白。
+  - 分步揭示 / 逐项渐入：delay 作为内联变量放在元素上、规则里统一引用——`<div class="card-in" style="--d:.15s">` + `animation: fadeUp .5s both; animation-delay: var(--d, 0s)`，不要按元素序号硬编码选择器。`both` 不可省：它让带 delay 的元素在等待期停在 `from` 的隐藏态；省掉会先以终态闪现、再跳回隐藏重播一遍。
+
+- **结构件。** 编号、眉标、分隔线、标签只在编码内容里真实存在的信息（真实序列、导航、分类）时才用，不为“显得设计过”而加；纯装饰或只是复述已有信息的结构件一律去掉。
+
+## 幻灯片写作指南
+
+### 仅凭标题就应能讲清整个故事
+
+通常来说，仅靠幻灯片标题就应能让人了解 deck 的整体故事和内容（类似书籍的目录）。
+
+幻灯片标题一般有以下几种结构类型：
+
+- 简短的教科书式标题，全部大写（如 Market Research、Engagement Overview、Team Structure）
+- 行动式标题，更接近短句（如 "Asia is our largest market…."、"...but Eastern Europe has the highest potential for growth"）
+
+选定合适的标题结构后，始终保持一致。
+
+### 避免暴露 AI 生成痕迹的 “AI 味”
+
+避免以下常见的 “AI 味”——它们会暴露这个 deck 是 AI 生成的：
+
+- AI 倾向于写出"宣判式"的标题和要点总结，过度戏剧化/简化，无缘由地制造张力（经典的 "It's not X. It's Y."），使用强祈使句，过度重新包装概念，或刻意悬念、故作洞察。
+- 类似 "The magic moment" 这样的标题
+- 总之，AI 倾向于把标题写成演讲者的金句，而非引导听众进入该页内容的**标题**——必须避免！
+
+## 规划步骤
+
+在常规规划之外，务必完成以下步骤：
+
+1. 受众、品牌风格推不出且承重时先提问；能从主题和材料推断的，带着假设直接进入大纲。
+2. 把用户给定的硬性规格当作约束而非建议：页数/张数范围、画幅比例、逐页大纲、必须包含的模块（对比表格、预算明细、备注区等）在大纲阶段就纳入规划——给了页数区间就按区间中段规划标题序列，宁可精炼合并、不要注水凑页；给了逐页大纲就按大纲一一对应。构建完成后逐条对照自查。
+3. 写出完整的标题序列。选择**一种**语法风格（例如短主题名词短语或简短陈述句），确保适合内容，并用该风格写出每一个标题。回头通读一遍，判断一个人**仅凭标题**能否跟上整个演示的脉络。标题应像书的章节——用直白的语言告诉读者接下来是什么。审阅这些标题并按需修订。将它们写入 scratchpad.md 文件。
+4. 在 scratchpad.md 里为每张幻灯片标注**版式原型**（全图 / 大数字 / 图表 / 表格 / 引用 / 多栏卡片 / 纯文字……）与**视觉锚点**（这页视线的第一落点）。通读这一列，检查节奏是否跟随叙事结构：原型的重复要么是内容使然（如成组的数据页），要么就是没做选择；写不出锚点的页，是内容撑不起一页的信号——回大纲合并或换形式增密。
+5. 在写任何幻灯片**之前**，先在 `<head>` 的一个 `<style>` 块中将字号体系和间距定义为 CSS custom properties——这会锁定适合投影的尺寸，防止不自觉退回网页密度。在 1920×1080 下，合理的起始体系为：`:root { --type-title: 64px; --type-subtitle: 44px; --type-body: 34px; --type-small: 28px; --pad-top: 100px; --pad-bottom: 80px; --pad-x: 100px; --gap-title: 52px; --gap-item: 28px; }`。在 1280×720 下，按 ~0.67 缩放。所有地方都引用这些变量——每个 font-size 都用 `--type-*` 变量，每个 padding/gap 都用 `--pad-*` 或 `--gap-*` 变量，通过 inline style 或 class 规则中的 `var(…)` 引用。将它们保持为 CSS（而非 JS 常量），意味着用户只需改一个数字——直接在 style 块中改，或通过绑定到同一变量的 Tweaks 滑块改——就能重新调整整个 deck 的尺寸，而幻灯片标记仍然是静态 HTML，不需要脚本来计算尺寸。显式的 `--pad-bottom` 为每张幻灯片底部预留呼吸空间；那个留白是结构性的，不是空的。网页默认值（body 14-16px、padding 48-72px）对幻灯片太小；如果数值让你觉得不够大方，那就是还不够。如果你用了小于 24px 的尺寸，你的校验器（validator）会抛出错误。
+6. 构建幻灯片，牢记每张幻灯片既是设计练习也是文案练习。在版式、文字内容和语调方面给予每张幻灯片应有的关注。遵循上述原则，确保每张幻灯片能独立成立；一个只看这一页的人，应当无需其他上下文就能理解其高层含义。
+
+## 验证要点
+
+审阅时，用幻灯片构图规则——而非网页布局直觉——来检查截图。底部留白是不是缺陷，用「留白 ≠ 空洞」的归属判据：内容自身完整、下方是无边框的整块呼吸空间，这是正确的幻灯片构图——不要出于网页直觉把 `flex-start` 改成 `center`；空白被元素边界圈占的，是被动空洞，按「视觉平衡」的出路修。
+
+还需验证：
+
+- 页数/张数、画幅比例与用户给定的硬性规格一致；用户点名要求的模块（对比表格、预算明细、备注区等）逐条在场
+- 字号是否匹配你的 `--type-*` 体系（而非网页密度）
+- 幻灯片边距是否匹配你的 `--pad-*` 值（而非网页紧凑间距）
+- 标题在各幻灯片间的平行性
+- 没有使用 accent-border 卡片或 takeaway box
+- 没有内容被画幅边缘裁切、显示不全
+- 没有元素相互压叠、遮挡到读不清
+- 没有被动空洞：边框 / 底色圈出的范围与其内容相称
+- 页面视觉重量在画布上分布均衡，没有大片区域读成「缺了东西」
+- 每页能指出视觉锚点；版式原型的重复经得起「内容使然还是没做选择」的追问
+- 带动效的元素在缩略图栏和打印视图下完整可见（基础样式即最终态，隐藏态只在 keyframes 的 `from` 里）
+- 实际翻页确认入场动画会播放；逐条检查动画选择器——凡按页限定的，`data-deck-active` 与页选择器必须连写（`section.s1[data-deck-active] h1`），写成后代形式（`[data-deck-active] .s1 h1`）该页动效全部失效
--- a/.claude/skills/lark-apps/creative-design/references/visual-exposure.md
+++ b/.claude/skills/lark-apps/creative-design/references/visual-exposure.md
@ -0,0 +1,82 @@
+---
+name: visual-exposure
+metadata:
+  display-names:
+    zh-CN: 可视化报告
+    en-US: Visual Report
+description: 用于制作可视化报告、专题视觉页、信息图、视觉长图、概念可视化、产品能力曝光、方案亮点展示等内容型 HTML 视觉作品。适合用户想把材料、数据或观点组织成可阅读、可展示、可传播的视觉化表达，但不希望做成 PPT、传统 dashboard 或纯 ECharts 图表的场景。触发词：可视化报告, 视觉报告, 可视化曝光, 视觉化曝光, 信息图, 长图, infographic, 视觉表达, 概念可视化, 亮点展示, 能力曝光
+available-agents:
+  - CreativeDesign
+---
+
+# 可视化报告与专题表达
+
+创建内容驱动的 HTML 视觉作品。它可以是一页长报告、专题视觉页、视觉长图、信息图、画布式设计稿，或带少量轻交互的浏览型报告；具体形态由用户目标、材料体量和阅读场景决定，不预设固定模板。
+
+## 工作方式
+
+1. 先读用户材料，提取主题、受众、阅读场景、核心结论、必须出现的事实和可省略的细节。
+2. 判断报告目的：汇报、解释、披露、说服、传播、留档，还是做视觉方向探索。
+3. 选择交付形态：长页报告、专题页、视觉长图、单屏摘要、画布式多方案、图文混排报告、偏打印感的正式报告等。不要把所有需求压成同一种版式。
+4. 按材料逻辑组织内容，而不是套固定目录、固定模块或固定视觉模板。参考样式只能启发表达方式，不能替代对当前材料的判断。
+5. 把材料拆成具体阅读任务：这一段要让读者完成什么判断、理解什么关系、记住什么事实、比较什么差异、追踪什么过程、相信什么证据。不要把这些任务名直接变成目录或模块标题。
+6. 为每个阅读任务现场生成合适的组件、视觉和布局：先说明这段内容需要什么表达方式，再落成具体 UI / 图形 / 排版 / 图表 / 截图 / 文字组合。可以创造新的结构和视觉隐喻，不受现有组件名限制；避免所有章节共享同一套组件组合。
+7. 先写风格 brief：主题隐喻、受众姿态、材料语言、配色逻辑和签名元素。财务报告可以像正式报告册，员工调研可以像组织研究档案，产品上市总结可以像品牌战报；这些只是启发，必须从用户材料里推导。
+8. 建立版式系统：画幅、栅格、字号层级、颜色、图标/线条语言、强调方式和章节节奏。版式系统必须说明不同章节如何变化，而不是所有章节都用同一种上下结构。
+9. 产出单个 HTML 文档。用户需求明确时直接做；只有主题、素材或交付形态完全无法判断时，才问少量必要问题。
+
+## 内容组织
+
+本 skill 中出现的报告形态、表达方式、组件和版式都只是示意，不是必须参考的清单。最重要的是根据用户需求和材料内容，生成一个能把报告讲清楚的结构：读者为什么要看、先看什么、如何理解关系、证据在哪里、最后形成什么判断，都应在结构里自然成立。
+
+可视化报告不是把图表排满，也不是把文字切成很多卡片。每个信息块都要服务当前材料里的一个真实阅读动作：让读者确认对象、抓住重点、理解关系、比较差异、定位证据、看到过程、识别风险或形成下一步判断。把这些阅读动作翻译成本次需求专属的视觉结构，而不是复用固定模块名。
+
+允许为当前需求重新发明表达结构：可以合并、拆分、放大、弱化、横向展开、纵向叙事、图文化、表格化、截图化或做成完全不同的布局。只要它能更清楚地解释报告内容，就优先于任何示例组件或常见版式。
+
+如果材料很长，先压缩成报告叙事，不要把原文完整铺上去。需要精确查数时使用表格或附录；需要快速传播时使用摘要和视觉重点；需要正式汇报时保留章节编号、图表标题和口径说明。
+
+不要把关键内容压成角落里的附录片段。用户明确要求展示的部分，应按报告目标给足版面权重，并选择合适的信息结构承载。
+
+## 版式策略
+
+可视化报告要像一份经过编辑设计的专题，而不是由同款卡片拼起来的长页面。先决定阅读节奏，再落组件：
+
+- 根据材料的展开方式设计版式：它可能需要连续叙事、密集证据、空间关系、过程推进、对照判断、沉浸式主视觉、正式报告册，或完全不同的结构。先为当前需求命名一个版式概念，再确定栅格、密度、视觉重心和章节变化。
+- 版式变化来自内容关系，不来自凑组件。关键段落可以被放大、拆页、满版化、图文化或变成精确表格；次要段落可以压缩、并列、收进注释或弱化。
+- 每个章节的结构可以不同，但要属于同一套视觉系统。变化要能解释：为什么这里适合宽图、那里适合密集表格、另一处适合分段叙事。
+
+不要为了“丰富”而乱放装饰。变化应该来自内容关系和阅读任务，而不是从组件清单里凑满页面。
+
+## 视觉原则
+
+- 优先清楚，其次好看。读者应该先理解结构，再感受到风格。
+- 明暗主题由需求、品牌、素材、受众和阅读场景决定；浅色、暗色、中性或局部深色都可以。选择后要保证对比度、可读性和信息层级，并能解释为什么适合当前主题。
+- 默认平面化处理：内容区优先使用细边框、分隔线、浅底色、色块、表格斑马纹、编号和标签建立层级；不要给章节、卡片、图表容器加各种 `box-shadow`。
+- 少用装饰性渐变、发光、玻璃拟态。视觉效果要帮助分组、强调或引导视线。
+- 风格跟随内容、受众和品牌：可以正式、温和、技术、编辑化、品牌化或实验感，但不要从某个样例场景继承固定颜色、固定目录或固定组件。
+- 每份报告应有一个可解释的签名元素。签名元素要从用户主题、材料质感和阅读任务中生成，而不是复用固定手法；它可以是任何能组织内容、建立记忆点并保持一致性的视觉规则。
+- 真实素材优先：用户给的截图、logo、图片、图标、数据片段要优先使用。没有素材时，用清楚的占位结构和可替换文案。
+- 允许少量动效，但只用于进入、强调或引导阅读，不做干扰理解的持续动画。
+- 可以包含数字、图表和表格，但它们服务于报告叙事；不要为了“可视化”而把所有内容都做成图。
+- 深色区域可以用于封面、结论、行动区或整篇报告的主视觉；只要它服务主题气质和阅读体验，而不是作为无依据的装饰。
+
+## 画布与交付
+
+- 多方案、设计稿、方向探索：使用 `design-canvas.jsx`，每个方向一个 `<DCArtboard>`。
+- 单一可视化报告、视觉长图或专题视觉稿：做成完整 HTML 页面，保持明确画幅、节奏和层级。
+- 如果用户要“设计稿”，优先走画布式交付；如果用户要“可直接展示/传播”，可以做成完整页面式视觉作品。
+- 所有文字应直接写在 HTML 中，便于用户后续编辑。
+
+## 检查清单
+
+- 交付形态匹配用户需求：长页报告、专题页、长图、画布设计稿或单屏摘要，而不是被固定模板绑住。
+- 当前需求的主题、边界和最重要信息在第一屏或开篇清楚可见。
+- 章节顺序跟随材料逻辑，不按评测集样例或预设场景套目录。
+- 章节版式有节奏变化，并且变化来自材料关系；没有一路同款上下卡片，也没有因为预设组件清单而硬凑结构。
+- 没有大面积空白、错位、低对比、文字不可读或模块之间风格突兀。
+- 内容区保持平面化，没有滥用阴影、发光、玻璃拟态或厚重悬浮效果。
+- 所有表达载体各司其职，没有为了数据而堆图，也没有用空泛文字或预设组件填空间。
+- 文字密度可读，没有小字堆叠。
+- 图标、线条、颜色和卡片样式属于同一套视觉语言。
+- 明暗选择能解释为什么适合这个主题；无论浅色还是暗色，都保证长文、图表和表格可读。
+- 事实性内容没有编造；不确定内容用中性描述或占位说明。
--- a/.claude/skills/lark-apps/creative-design/references/wireframe.md
+++ b/.claude/skills/lark-apps/creative-design/references/wireframe.md
@ -0,0 +1,14 @@
+---
+name: wireframe
+metadata:
+  display-names:
+    zh-CN: 线框图
+    en-US: Wireframe
+description: 用线框图和故事板探索多种想法。触发词：wireframe, storyboard, 线框图, 故事板, 分镜, 草图, 低保真, 方案探索, 设计探索
+available-agents:
+  - CreativeDesign
+---
+
+# 线框图
+
+帮助用户快速探索设计想法。提问遵循 [`../creative-design.md`](../creative-design.md)「提问」一节：关键信息缺失且承重时先做一轮聚焦提问，否则基于合理假设直接铺方案。生成多个粗略的线框图，在锁定方向之前把设计空间勾勒出来。优先追求广度而非精细打磨：默认每个想法给出 2-3 种明显不同的方案，用户明确要求广度探索时再加。用简单的形状、占位文字和极少的颜色，把焦点留在结构和流程上。整体保持手绘草图的感觉——手写风格但清晰可读的字体；以黑白为主、点缀少量颜色；低保真、简洁。多方案默认铺进 `design-canvas.jsx` 画布（见 [`../creative-design.md`](../creative-design.md)「如何开展设计工作」）；单个 artboard 内部的局部变体用 Tweaks 承载（用 `tweaks-panel.jsx`，见 [`../creative-design.md`](../creative-design.md)「Tweaks」，不要手写控件面板）。