html

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

HTML artifacts

HTML工件

You produce a single, standalone
.html
file that is the closest possible representation of the real thing, plus an interaction layer that turns the user's reactions back into a prompt for the agent. The artifact is not a deliverable — it is one turn in a conversation. Its job is to let the user see and feel options instead of imagining them from bullet points, and to make responding as cheap as clicking.

你需要生成一个独立的单个
.html
文件，尽可能贴近真实效果，同时添加交互层，将用户的反馈转化为给Agent的提示。该工件并非交付物——它是对话中的一个环节。其作用是让用户能够直观查看和感受各种选项，而非通过项目符号去想象，同时让回复操作像点击一样简单。

Non-negotiables

不可妥协的要求

One file, zero build. Inline all CSS and JS. No frameworks, no CDNs unless the fidelity genuinely requires one (e.g. a font); it must open from
```
file://
```
and still work.
Closest possible representation. Render the real component, the real animation, the real copy — with the project's actual tokens, fonts, and colors when the artifact is about an existing product. Read the project's CSS/theme first and reuse it. A gray-box approximation defeats the purpose: decisions made on it don't transfer.
Always close the loop. Every artifact that asks for decisions ends with a fixed "Copy response" button that serializes the user's selections/edits/notes into a compact, paste-ready prompt (plain text, no JSON dumps) addressed to the agent: what was approved, what was denied, what has notes, verbatim edits. The user pastes that back — never the whole doc.
Real motion, not screenshots of motion. If the subject moves, the artifact animates. Add replay buttons; loop only what loops in the product.
Cheap to regenerate. Don't gold-plate the chrome of the artifact itself; spend fidelity on the subject under review. The user may ask for "four more" in the next message.
Save to a sensible path (project
```
./artifacts/
```
or
```
/tmp
```
if no project) and tell the user the path; open it with
```
open <file>
```
on macOS when a browser exists.

单文件，零构建：内联所有CSS和JS。除非为了保证真实效果确实需要（例如某种字体），否则不使用框架、不依赖CDN；文件必须能通过
```
file://
```
协议打开并正常运行。
尽可能贴近真实效果：渲染真实的组件、真实的动画、真实的文案——如果工件是针对现有产品的，要使用项目实际的设计令牌（tokens）、字体和颜色。先读取项目的CSS/主题并复用。灰色近似的实现毫无意义：基于此做出的决策无法迁移到实际项目中。
始终形成闭环：所有需要用户决策的工件末尾都要有一个固定的**“复制回复”**按钮，将用户的选择/编辑/笔记序列化为简洁、可直接粘贴的提示（纯文本，不输出JSON）发送给Agent：包括已批准、已拒绝、有备注的内容，以及逐字编辑的内容。用户只需粘贴这个提示——无需返回整个文档。
真实动效，而非动效截图：如果主题包含动态效果，工件要实现动画。添加重播按钮；仅循环产品中原本就循环的内容。
易于重新生成：不要过度打磨工件本身的装饰部分；把精力放在提升审阅主题的真实度上。用户可能在下一条消息中要求“再生成四个变体”。
将文件保存到合理路径（项目的
```
./artifacts/
```
目录，如果没有项目则保存到
```
/tmp
```
），并告知用户路径；如果有浏览器，在macOS上使用
```
open <file>
```
命令打开文件。

Pick the format from the user's need

根据用户需求选择格式

Adapt these — they are shapes, not templates. Combine them when the request spans two.

灵活调整以下格式——它们是模板框架，而非固定模板。如果请求涉及多种需求，可以组合使用。

1. Review / decision doc

1. 审阅/决策文档

For audits, proposed changes, refactors, redesign proposals — anything with a list of items the user must judge.

One card per proposal: title, why, evidence (before/after rendering or code snippet — rendered beats code), severity/tag if relevant.
Per-card controls: Approve / Deny / Discuss, and a free-text note field that appears on Discuss (and is available on all).
A sticky header or footer with running count (e.g. "8 approved · 3 denied · 2 discussing") and the Copy response button.
If the source review already exists (e.g. a critique file), transcribe it faithfully; don't invent items.

适用于审计、拟议变更、重构、重新设计提案等——任何需要用户判断的项目列表。

每个提案对应一张卡片：标题、原因、证据（前后渲染效果或代码片段——渲染效果优于代码），如有相关的严重性/标签也需包含。
每张卡片的控件：批准/拒绝/讨论，以及点击“讨论”时显示的自由文本备注字段（所有卡片都可使用该字段）。
固定的页眉或页脚，显示实时统计（例如“已批准8项 · 已拒绝3项 · 讨论中2项”）和**“复制回复”**按钮。
如果已有源审阅文档（例如评论文件），要如实转录；不要自行添加项目。

2. Variant board

2. 变体面板

For "show me this N ways" — components, layouts, effects, type treatments.

Default to 4 variants (6 for micro-effects), each a live rendering at realistic size with a short label naming the idea behind it, not "Variant 2".
Number them so the user can dictate over it: "me gusta la 2 pero…".
If the variants animate, give each its own replay control.

适用于“展示这个的N种实现方式”——组件、布局、效果、文字样式。

默认生成4个变体（微效果默认6个），每个变体以真实尺寸实时渲染，并附带简短标签，说明其背后的设计思路，而非“变体2”这类名称。
为变体编号，方便用户直接指定：“我喜欢第2个，但……”。
如果变体包含动画，为每个变体添加独立的重播控件。

3. Motion before/after

3. 动效前后对比

For animation changes: current version and proposed version side by side, both live.

Replay-both button; per-side replay.
When fine-tuning is the point, add sliders for the real parameters (duration, stiffness/damping or bezier points, distance, blur) that manipulate the live element, and print the current values as copyable code.
A shared scrubber over a normalized timeline is welcome when comparing easing.

适用于动画变更：将当前版本和拟议版本并排展示，均为实时动效。

添加“同时重播”按钮；以及每个版本的独立重播按钮。
如果需要微调参数，添加滑块控制真实参数（时长、刚度/阻尼或贝塞尔曲线点、距离、模糊度），这些参数可实时操控元素，并将当前值显示为可复制的代码。
当对比缓动效果时，可添加共享的时间轴 scrubber（擦洗器），基于标准化时间轴进行对比。

4. Visual explorer

4. 可视化探索器

For understanding a domain — an API, a dataset, a codebase area.

Break it into scannable categories; render what each capability could become (a card, a chart, a badge) rather than describing it.
Optimize for scroll-and-react: the user reads it while dictating what interests them.

适用于理解某个领域——API、数据集、代码库区域。

将内容拆分为易于浏览的类别；渲染每个功能可能的最终形态（卡片、图表、徽章），而非仅描述。
优化为滚动反馈模式：用户在浏览的同时即可口述感兴趣的内容。

5. Repackaged reading

5. 重排版阅读文档

For content the user wants to consume in a better shape: generous space, slide-sized bites, one idea per screenful. Keep the source's words; change only the container.

适用于用户希望以更优格式阅读的内容：充足的留白、幻灯片式的分段，每页展示一个观点。保留原文内容；仅调整容器格式。

6. Copy ecosystem

6. 文案生态系统

Every system string of a kind (toasts, dialogs, errors, empty states) in one doc, rendered inside a faithful mock of its real component.

Inline-editable text (
```
contenteditable
```
), visually marking edited items.
Copy response outputs only the changed strings as before → after pairs.

将同类的所有系统字符串（提示框、对话框、错误信息、空状态文本）整合到一个文档中，渲染在其真实组件的高保真模拟环境中。

支持在线编辑文本（
```
contenteditable
```
），并以视觉方式标记已编辑的内容。
“复制回复”仅输出修改后的字符串，格式为“原内容 → 修改后内容”。

Craft floor for the artifact itself

工件本身的设计准则

The chrome (headers, buttons, counts) is quiet and neutral; the subject carries the visual weight.
Comparison grids compare, so they align. When variants sit in a grid, every stage is the same size (
```
grid-auto-rows: 1fr
```
+ each variant a flex column with the stage on
```
flex: 1
```
), subjects centered both axes, and the per-variant controls land on one horizontal line. Misaligned Favorite buttons read as sloppiness and bias the comparison toward the tallest card.
Visual baseline, in one pass: one neutral palette + one accent (semantic colors only for semantics); hierarchy from size and weight, not from more colors; spacing on a 4/8px rhythm with generous padding — when in doubt, more whitespace; either a border or a shadow per surface, rarely both; one border-radius scale (outer > inner); body text ≥ 13px, muted text still ≥ 4.5:1 contrast.
Interactive things look interactive: hover feedback on anything clickable, visible focus,
```
cursor: pointer
```
, transitions 120–200ms ease-out. Nothing else moves unless motion is the subject.
Interactions need no instructions — if a control isn't self-evident, label it.
State survives a scroll but need not survive a reload; this is a disposable document. Say so in the footer if the user might assume otherwise.
Copy button must actually work from
```
file://
```
: use
```
navigator.clipboard
```
with a
```
document.execCommand('copy')
```
fallback, and confirm visually ("Copied ✓").
Respect
```
prefers-reduced-motion
```
in the chrome; the subject's animations still play on demand (replay buttons) since reviewing them is the task.
Dark/light: match the product under review; if none, follow
```
prefers-color-scheme
```
.

装饰元素（页眉、按钮、统计信息）要简洁中性；视觉重点应放在审阅主题上。
对比网格要对齐：当变体以网格布局展示时，每个变体的尺寸必须一致（使用
```
grid-auto-rows: 1fr
```
+ 每个变体为flex列，展示区域设置
```
flex: 1
```
），主题在横竖方向均居中，每个变体的控件位于同一水平线上。未对齐的“收藏”按钮会显得草率，并让用户偏向选择最高的卡片。
视觉基线，一步到位：一套中性调色板 + 一种强调色（仅在语义场景使用语义颜色）；通过字号和字重构建层级，而非依赖更多颜色；遵循4/8px的间距节奏，使用充足的内边距——拿不准时，多留空白；每个表面要么加边框要么加阴影，很少同时使用；一套圆角比例（外层 > 内层）；正文字号≥13px，次要文本的对比度仍需≥4.5:1。
交互元素要看起来可交互：任何可点击元素都要有悬停反馈、可见的焦点状态、
```
cursor: pointer
```
，过渡动画时长为120–200ms，采用ease-out曲线。除非动效是审阅主题，否则其他元素不要动。
交互无需说明——如果控件不够直观，就添加标签。
状态在滚动时保持，但无需在刷新后保留；这是一次性文档。如果用户可能会误解，可在页脚说明。
“复制”按钮必须能在
```
file://
```
协议下正常工作：使用
```
navigator.clipboard
```
，并以
```
document.execCommand('copy')
```
作为备选方案，同时提供视觉确认（“已复制 ✓”）。
装饰元素要尊重
```
prefers-reduced-motion
```
设置；但主题的动画仍需支持按需播放（通过重播按钮），因为审阅这些动画是核心任务。
深色/浅色模式：匹配所审阅产品的模式；如果没有产品参考，则遵循
```
prefers-color-scheme
```
设置。

Process

流程

Ask nothing if the request names the subject and the format is inferable; otherwise ask one question, not a questionnaire.
Gather the real material first (tokens, components, copy, findings). The artifact is only as useful as the truth it renders.
Build the full file in one pass. Open it. One batched self-check (does it render, do the controls work, does Copy response produce a sane prompt) — then stop polishing and hand it over.
When the user pastes the response prompt back, act on it in the project, not in the artifact; regenerate the artifact only if they ask for another round.

Inspired by the artifact-driven design workflows of Kyle Zantos and Michael Riddering (Ridd).

如果请求明确了主题且格式可推断，则无需提问；否则只提一个问题，不要一次性问多个。
先收集真实素材（设计令牌、组件、文案、调研结果）。工件的实用性取决于其呈现内容的真实性。
一次性构建完整文件。打开文件。进行一次批量自检（是否能正常渲染、控件是否可用、“复制回复”是否生成合理的提示）——然后停止打磨，交付给用户。
当用户粘贴回复提示时，在项目中执行相应操作，而非修改工件；仅当用户要求新一轮审阅时，才重新生成工件。

灵感来自Kyle Zantos和Michael Riddering (Ridd)的工件驱动设计工作流。