card

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

VoxFlow Skill — Card

VoxFlow 技能 — 卡片

Turn a piece of text into a set of distinctive, consistent visual card images. Each card is its own webpage; all cards share one size and style system; they render with Playwright and export as PNGs.

This is the static card-image skill. For other surfaces switch to:

Article → vertical card VIDEO (Slice) — 1080×1920 reel, 13 themes →
```
voxflow:slice
```
Short videos / AI clips / knowledge-card videos →
```
voxflow:video
```
Multi-speaker podcasts →
```
voxflow:podcast
```
TTS / voices / install / auth / quota →
```
voxflow:hub
```

<CRITICAL-AUTO-UPGRADE> If ANY `voxflow` command prints a `<voxflow-hint ... type="cli-outdated" ...>` line to stderr, IMMEDIATELY run `voxflow upgrade -y` before continuing — do not ask, do not summarize first. If `voxflow upgrade` errors with `Unknown command` (CLI predates 1.12.0), fall back to `npm i -g voxflow@latest`. </CRITICAL-AUTO-UPGRADE>

将一段文本转换为一组风格独特、视觉统一的卡片图片。每张卡片对应一个独立网页；所有卡片共享同一尺寸和样式系统；通过Playwright渲染并导出为PNG格式。

这是静态卡片图片技能。如需生成其他形式的内容，请切换至：

文章 → 竖版卡片视频（Slice） — 1080×1920 竖屏格式，13种主题 →
```
voxflow:slice
```
短视频 / AI剪辑 / 知识卡片视频 →
```
voxflow:video
```
多 speaker 播客 →
```
voxflow:podcast
```
TTS / 语音 / 安装 / 授权 / 配额 →
```
voxflow:hub
```

<CRITICAL-AUTO-UPGRADE> 如果任何`voxflow`命令向stderr输出`<voxflow-hint ... type="cli-outdated" ...>`行，请立即运行`voxflow upgrade -y`再继续——无需询问，无需先总结。如果`voxflow upgrade`报错提示`Unknown command`（CLI版本早于1.12.0），请回退使用`npm i -g voxflow@latest`。 </CRITICAL-AUTO-UPGRADE>

Step 0 · Sign-in gate (required, do this first)

步骤0 · 登录验证（必填，请首先完成）

This skill is part of VoxFlow and requires a signed-in account. Before anything else — before asking questions, before research, before design — verify login:

bash

voxflow status

Prints the account + remaining quota → signed in, continue to the workflow.
Errors / shows "not logged in" → STOP. Run
```
voxflow login
```
(opens the browser — Google or email OTP), wait for the user to finish, then re-run
```
voxflow status
```
. Do not collect parameters or generate any cards until login succeeds.

voxflow: command not found

→

npm install -g voxflow

first, then

voxflow login

Never skip this gate, never generate cards for an unauthenticated user, and never invent a token. The cached token lives at

~/.config/voxflow/token.json

; for CI,

VOXFLOW_TOKEN

is honored.

本技能属于VoxFlow，要求用户已登录账号。在进行任何操作之前——包括提问、调研、设计——请先验证登录状态：

bash

voxflow status

输出账号信息 + 剩余配额 → 已登录，继续执行工作流。
报错 / 显示"not logged in" → 停止操作。运行
```
voxflow login
```
（将打开浏览器——支持Google或邮箱OTP验证），等待用户完成登录，然后重新运行
```
voxflow status
```
。在登录成功前，请勿收集参数或生成任何卡片。

提示

voxflow: command not found

→ 先运行

npm install -g voxflow

，再执行

voxflow login

。

请勿跳过此验证步骤，请勿为未认证用户生成卡片，请勿伪造令牌。缓存的令牌存储在

~/.config/voxflow/token.json

；对于CI环境，可使用

VOXFLOW_TOKEN

环境变量。

Overview

概述

Create a set of shareable visual cards from source content. Treat each card as its own webpage, keep all cards the same size and style system, render them with Playwright, export images, and iterate on weak cards.

从源内容创建一组可分享的可视化卡片。将每张卡片视为独立网页，保持所有卡片尺寸和样式系统一致，通过Playwright渲染、导出图片，并对效果不佳的卡片进行迭代优化。

Taste Baseline

风格基准

references/taste.md

is a constraint checklist that bounds every card mold, theme, layout, and design language. Treat it as a floor that bites at design time, not an opening ritual to be recited at workflow start.

Load
```
references/taste.md
```
at two moments only, not at the start of the workflow:
- When picking the theme preset and design language (Workflow step 4), so the choice does not violate hard constraints.
- During QA scoring (Workflow step 7), as one explicit verification dimension.
Other steps (parameter collection, research, copy planning) do not need to reload
```
references/taste.md
```
; the constraints flow into them through the preset and language already chosen.
The core goal is to remove obvious AI-generated design traces.
Hard constraints include: no default Inter font, no pure black, no default centered hero, no three equal-card composition, no generic AI-copy voice, and no fake-looking data.
Taste does not mean empty. Use the density rules in
```
references/taste.md
```
so real card sets include at least one useful information card unless the user explicitly asks for a poster-only or cinematic-only set.
If a theme preset or design language conflicts with
```
references/taste.md
```
, the taste baseline wins unless the user explicitly asks for the banned style.

references/taste.md

是一份约束清单，规范了所有卡片模板、主题、布局和设计语言。将其视为设计时必须遵守的底线，而非工作流开始时的形式化流程。

仅在两个时刻加载
```
references/taste.md
```
，而非工作流启动时：
- 选择主题预设和设计语言时（工作流步骤4），确保选择的方案不违反硬性约束。
- QA评分时（工作流步骤7），作为明确的验证维度之一。
其他步骤（参数收集、调研、文案规划）无需重新加载
```
references/taste.md
```
；约束会通过已选择的预设和设计语言渗透到这些步骤中。
核心目标是消除明显的AI生成设计痕迹。
硬性约束包括：不得使用默认Inter字体、不得使用纯黑色、不得使用默认居中主视觉、不得使用三等分卡片布局、不得使用通用AI文案语气、不得使用虚假数据。
风格基准并非意味着内容空洞。请遵循
```
references/taste.md
```
中的密度规则，除非用户明确要求仅生成海报或影视风格卡片，否则实际卡片集应至少包含一张实用信息卡。
如果主题预设或设计语言与
```
references/taste.md
```
冲突，除非用户明确要求禁用的风格，否则以风格基准为准。

Inputs

输入参数

Collect or infer:

```
content
```
: source text, outline, notes, URL, topic, or brief.
```
ratio
```
: default to
```
1:1
```
unless the user requests
```
3:4
```
,
```
9:16
```
, or another ratio.
```
count
```
: default to an automatic count based on content density; accept explicit quantities.
```
style
```
: accept explicit style directions, brand constraints, audience, mood, and platform.
```
content-language
```
: zh / en / mixed. Infer from the source; ask only when ambiguous and it would change font selection. Drives the language override in
```
references/fonts.md
```
.
```
output
```
: choose a clear local folder such as
```
cards/<slug>/
```
unless the user specifies one.

If important facts may be current or disputed, search or verify before planning. Keep source attribution available for the user when research affects the content. See the Research & Fact Confirmation section for when this becomes a full deep-research pass instead of a quick check.

收集或推断以下参数：

```
content
```
：源文本、大纲、笔记、URL、主题或简要需求。
```
ratio
```
：默认使用
```
1:1
```
，除非用户要求
```
3:4
```
、
```
9:16
```
或其他比例。
```
count
```
：默认根据内容密度自动计算数量；接受用户指定的明确数量。
```
style
```
：接受明确的风格方向、品牌约束、受众、情绪和平台要求。
```
content-language
```
：zh / en / mixed。从源内容推断；仅当语言模糊且会影响字体选择时才询问用户。该参数将驱动
```
references/fonts.md
```
中的语言覆盖规则。
```
output
```
：默认选择清晰的本地文件夹，如
```
cards/<slug>/
```
，除非用户指定其他路径。

若重要事实可能时效性较强或存在争议，请在规划前进行搜索或验证。当调研影响内容时，为用户保留来源归因。请参考「调研与事实确认」部分，判断何时需要进行完整深度调研而非快速检查。

Research & Fact Confirmation

调研与事实确认

Insert this between parameter collection and design work, but only when the input cannot stand on its own as the content of the cards.

Trigger deep research when
```
content
```
is any of: a topic phrase, a single sentence brief, a URL whose body has not been read yet, a tweet-length idea, a question, or a request to "explain X / cover X / make cards about X".
Skip deep research when
```
content
```
is already a self-contained article, transcript, set of structured notes, a fully drafted outline, or any text the user clearly wants cards built from rather than about.
When triggered, produce a fact outline before any visual planning:
- Core claim or thesis.
- 3-7 supporting points with concrete numbers, names, dates, or mechanisms.
- Sources for each non-trivial fact, with URLs or document references that will land in
```
sources.md
```
  .
- Open questions or contested points the user should resolve.
Present the fact outline to the user and ask for confirmation, additions, or corrections before moving into theme/design-language selection. This is a separate confirmation from the later concept/visual confirmation.
The output of this step is the "bones" — claims and evidence — not finished card copy. Card-level hooks, explainers, and takeaways are written later during content structuring (step 5) on top of the confirmed bones.
Record sources gathered here into
```
sources.md
```
inside the output folder as soon as the fact outline is confirmed.

将此步骤插入参数收集和设计工作之间，但仅当输入内容无法直接作为卡片内容时执行。

当
```
content
```
为以下类型时，触发深度调研：主题短语、单句简要需求、尚未读取内容的URL、推文长度的想法、问题、或“解释X / 涵盖X / 制作关于X的卡片”的请求。
当
```
content
```
为以下类型时，跳过深度调研：完整的文章、转录稿、结构化笔记集、已完成的大纲、或任何用户明确要求直接基于其制作卡片而非围绕其展开的文本。
触发调研后，在进行视觉规划前生成事实大纲：
- 核心主张或论点。
- 3-7个支持点，包含具体数字、名称、日期或机制。
- 每个非 trivial 事实的来源，包含URL或文档引用，将存入
```
sources.md
```
  。
- 用户需要解决的开放性问题或争议点。
将事实大纲呈现给用户，请求确认、补充或修正，然后再进入主题/设计语言选择环节。在以确认为导向的工作流中，此确认与后续步骤6中的视觉/概念确认是分开的。在以执行为导向的工作流中，除非满足停止条件，否则将其转换为简短的进度更新而非阻塞性环节。
此步骤的输出是“骨架”——主张和证据——而非最终的卡片文案。卡片级的钩子、解释和要点将在后续内容结构化步骤（步骤5）中，基于已确认的骨架进行撰写。
一旦事实大纲得到确认，立即将收集到的来源记录到输出文件夹中的
```
sources.md
```
。

Trigger Examples

触发示例

Run deep research when:

"做一组讲 MCP 协议的卡片" — bare topic, no body.
"把这篇文章做成卡片：https://example.com/post" — URL whose contents have not been read in this conversation.
"想做一组讲 RAG 优化技巧的卡片,重点放在 chunking 上" — topic + angle, no concrete points or data.
"Cloudflare Durable Objects 适合什么场景?做几张卡片" — question or "explain X / cover X" framing.
A single tweet, headline, or one-line brief that names a subject but supplies no evidence.

Skip deep research when:

The user pastes a full article, blog post, transcript, or interview body (anything roughly 500+ words of self-contained source content).
The user provides structured notes, meeting minutes, course notes, or a finished outline where each card's title and 2-4 points are already listed.
The user provides their own finished copy and asks for visual treatment only ("把这段话排成卡片", "美化一下这段文案").
The user explicitly says "不要查资料 / 直接基于这段写 / 不要扩展", regardless of input length.

在以下情况中运行深度调研：

"做一组讲 MCP 协议的卡片" — 仅提供主题，无具体内容。
"把这篇文章做成卡片：https://example.com/post" — 未读取内容的URL。
"想做一组讲 RAG 优化技巧的卡片,重点放在 chunking 上" — 主题+角度，无具体要点或数据。
"Cloudflare Durable Objects 适合什么场景?做几张卡片" — 问题或“解释X / 涵盖X”类需求。
单条推文、标题或仅提及主题但未提供证据的单行简要需求。

在以下情况中跳过深度调研：

用户粘贴完整的文章、博客文章、转录稿或访谈内容（约500字以上的独立源内容）。
用户提供结构化笔记、会议纪要、课程笔记或已完成的大纲，其中已列出每张卡片的标题和2-4个要点。
用户提供自己撰写的最终文案，仅要求视觉处理（"把这段话排成卡片", "美化一下这段文案"）。
用户明确表示"不要查资料 / 直接基于这段写 / 不要扩展"，无论输入内容长度如何。

Borderline Inputs

边界情况输入

Short brief + ambition mismatch — e.g., 200-word summary plus "展开成 7 张卡". The brief is too thin to fill the target count, so trigger research and surface that the brief lacks evidence before expanding.
Article + "再补点最新数据 / 加点案例" — run a scoped research pass only on the requested additions; do not re-research the parts the user already wrote.
Bullet list with titles but no evidence — e.g., "1. 性能更好 2. 更便宜 3. 更安全". Trigger research to attach concrete numbers or examples; otherwise the cards will read as AI filler.
Article + the user's own opinion or take — skip research on the source, but confirm with the user whether the opinion should be preserved verbatim or restructured.
URL whose body has already been fetched and discussed earlier in this conversation — treat as pasted content, skip research, but still write the URL into
```
sources.md
```
.

When the input is ambiguous, ask one clarifying question ("这段内容是要直接做成卡片,还是希望我先查资料再展开?") instead of guessing — a wrong research decision wastes either the user's time or the model's research budget.

简短需求与目标不匹配 — 例如，200字摘要加上“展开成7张卡”。需求内容过于单薄，无法填充目标数量的卡片，因此触发调研，并告知用户需求缺乏足够证据支撑，需要补充。
文章 + "再补点最新数据 / 加点案例" — 仅针对用户要求补充的内容进行限定范围的调研；无需重新调研用户已撰写的部分。
仅有标题无证据的项目符号列表 — 例如，"1. 性能更好 2. 更便宜 3. 更安全"。触发调研以添加具体数字或示例；否则卡片将显得像AI生成的填充内容。
文章 + 用户自身观点或见解 — 跳过对源文章的调研，但需与用户确认是否应保留观点原文或进行重构。
已在对话中获取并讨论过内容的URL — 视为已粘贴的内容，跳过调研，但仍需将URL写入
```
sources.md
```
。

当输入内容模糊时，提出一个澄清问题（"这段内容是要直接做成卡片，还是希望我先查资料再展开？"）而非猜测——错误的调研决策会浪费用户时间或模型的调研预算。

Ask User Questions

向用户提问

Ask for missing generation parameters once near the start, before concept planning. Treat "Ask User Questions" as a portable decision policy, not a requirement to call a specific tool. Different coding agents expose different interaction primitives, so the skill must work when structured question tools are present, absent, or discouraged by the agent's operating mode.

First extract known values for

content

ratio

count

theme/style

platform/audience

, and

output/constraints

Ask the user to confirm generation parameters before planning whenever any meaningful choice is still missing. Do this even when the user says "帮我做 / 生成 / 制作 / 直接出图 / quickly export"; those phrases request execution, not silent parameter inference.

Ask when the answer materially changes the output. Priority order:

content/source intent

ratio

count

theme/style

platform/audience

output/constraints

Ask at most 3 concise questions by default. Use up to 5 only when the user explicitly wants configuration choices or the output is high-stakes.
Do not ask again for parameters that are already explicit in the user's original request.
Skip the question step only when the user explicitly says not to ask questions or explicitly approves default parameters. In that case, use defaults and state the assumptions briefly before or during execution.

在概念规划开始前，尽早询问缺失的生成参数。将“向用户提问”视为可灵活调整的决策策略，而非必须调用特定工具的要求。不同的编码代理提供不同的交互原语，因此本技能需适配以下场景：结构化提问工具存在、不存在或被代理的操作模式禁止。

首先从用户原始请求中提取已知的
```
content
```
、
```
ratio
```
、
```
count
```
、
```
theme/style
```
、
```
platform/audience
```
和
```
output/constraints
```
参数值。
当仍存在有意义的选择缺失时，在规划前请求用户确认生成参数。即使用户说“帮我做 / 生成 / 制作 / 直接出图 / quickly export”，这些表述是请求执行，而非默认允许静默推断参数。
仅当答案会实质性改变输出结果时才提问。优先级顺序：
```
content/source intent
```
、
```
ratio
```
、
```
count
```
、
```
theme/style
```
、
```
platform/audience
```
、
```
output/constraints
```
。
默认最多提出3个简洁的问题。仅当用户明确希望进行配置选择或输出为高风险内容时，最多可提出5个问题。
对于用户原始请求中已明确的参数，请勿再次询问。
仅当用户明确表示无需提问或明确批准默认参数时，才跳过提问步骤。在这种情况下，使用默认参数，并在执行前或执行过程中简要说明假设。

Compatibility Strategy

兼容性策略

Use the current environment's best available question mechanism:

If the environment supports
```
ask_user_question
```
,
```
ask question
```
, or an equivalent native clarification capability, use that native interaction to clarify blocking questions.
If the environment does not support a native question capability, ask directly in normal conversation.
Ask at most 2-5 questions at a time.
If missing information does not block the task, still ask once for confirmation of the parameters that affect the final output. If the user has already approved defaults or asked for no questions, make reasonable assumptions and continue.
Explicitly list important assumptions in the final response,
```
sources.md
```
, or
```
credits.md
```
.

使用当前环境中最佳的提问机制：

如果环境支持
```
ask_user_question
```
、
```
ask question
```
或等效的原生澄清功能，请使用该原生交互来澄清阻塞性问题。
如果环境不支持原生提问功能，请直接在对话中提问。
每次最多提问2-5个问题。
如果缺失的信息不会阻塞任务，仍需询问一次对最终输出有影响的参数确认。如果用户已批准默认参数或要求无需提问，请做出合理假设并继续执行。
在最终响应、
```
sources.md
```
或
```
credits.md
```
中明确列出重要假设。

Stop Conditions

停止条件

Stop and ask before generation only when one of these is true:

There is no usable
```
content
```
, topic, URL, or source material.
The source intent is ambiguous and choosing wrong would waste the work, for example "use this text as-is" versus "research and expand this topic".
The requested ratio/platform is contradictory or impossible to satisfy with a single export.
The visual direction is governed by brand, legal, accessibility, or exact-copy constraints that are missing.
Research finds contested facts that would change the core claim.

Otherwise, ask once for confirmation of meaningful generation parameters, then proceed with documented assumptions and record them in

sources.md

or the final response.

仅当满足以下任一条件时，在生成前停止并提问：

无可用的
```
content
```
、主题、URL或源材料。
源内容意图模糊，错误选择会导致工作白费，例如“直接使用此文本”与“调研并扩展此主题”。
请求的比例/平台存在矛盾，无法通过单一导出满足。
视觉方向受缺失的品牌、法律、可访问性或精确文案约束的管控。
调研发现会改变核心主张的争议性事实。

否则，询问一次有意义的生成参数确认，然后基于已记录的假设继续执行，并将假设记录在

sources.md

或最终响应中。

Ratio Question

比例问题

Use these default choices:

```
1:1
```
square card for general social sharing.
```
3:4
```
vertical graphic card for richer text/image posts.
```
9:16
```
story, reel, short-video cover, or mobile-first card.

Accept free-form ratios such as

4:5

16:9

, or exact pixel sizes when the user provides them.

使用以下默认选择：

```
1:1
```
方形卡片：适用于通用社交分享。
```
3:4
```
竖版图文卡片：适用于内容更丰富的图文帖子。
```
9:16
```
故事、短视频封面或移动端优先卡片：适用于竖屏场景。

当用户提供自定义比例（如

4:5

、

16:9

）或精确像素尺寸时，予以支持。

Count Question

数量问题

Use these default choices:

Auto-recommend based on the content.
```
3
```
cards for a compact narrative.
```
5
```
cards for a standard explainer.
```
7
```
cards for a fuller carousel.

When auto-recommending, choose the smallest set that covers the idea without crowding. Prefer 3-7 cards for explainers and 1-3 cards for announcements.

使用以下默认选择：

根据内容自动推荐数量。
```
3
```
张卡片：适用于紧凑叙事。
```
5
```
张卡片：适用于标准讲解类内容。
```
7
```
张卡片：适用于更完整的轮播内容。

自动推荐时，选择能完整覆盖主题且不拥挤的最小卡片数量。讲解类内容优先选择3-7张卡片，公告类内容优先选择1-3张卡片。

Theme Question

主题问题

Do not expose the full preset catalog directly to the user. Load

references/themes/presets.md

and, when visual direction matters,

references/design-languages.md

; then recommend 3-5 scenario-based style options based on the content, platform, audience, and sharing goal. Map the user's chosen scenario to the final theme preset and design-language combination internally.

When asking the user to choose a style, do not present only one recommendation plus a vague "or change it?" question. Give 3-5 concrete options, each with:

a short user-facing style name;
the situation where it works best;
a one-line visual description;
the internal theme preset and design-language mapping.

Use a two-layer selection logic so outputs stay appropriate without collapsing into the same few looks:

Default recommendation layer:
- Offer 3-5 high-fit styles based on content type, platform, audience, and sharing goal.
- Keep the recommended set close enough to the user's task that any option can succeed without heavy rework.
- Prefer options that differ in visible outcome, not just token names. For example: conservative report, data poster, social notebook, magazine explainer, bold opinion.
Variant perturbation layer:
- When the user has not strongly specified an exact style, rotate within the compatible family instead of always selecting the top default.
- Vary at least two of these dimensions across similar tasks: theme preset, primary design language, modifiers, layout recipes, visual anchors, surface metaphor, or title composition.
- Keep perturbations semantically compatible with the content. Do not use random novelty that fights the topic, platform, accessibility, or factual clarity.
- Record the final selected combination in the concept plan or
```
sources.md
```
  /
```
credits.md
```
  so the variation is inspectable.

Use user-facing scenario labels such as:

Engineering infographic: map to

engineering-paper

product-manual

, or

porcelain-research

Business briefing: map to

quiet-report

product-manual

, or

porcelain-research

Bold opinion: map to

bold-editorial

magazine-eink

, or

newsroom-paper

Social product note: map to

social-notebook

magazine-eink

, or

bold-editorial

Editorial / magazine: map to

magazine-eink

dune-gallery

field-notes

, or

kraft-editorial

For design-language choices, use user-facing scenario labels such as:

Technical but designed: map to

editorial-artifact + cutaway + annotation

Magazine explainer: map to

image-led-magazine + edge-crop + asymmetric-space

Bold thesis: map to

swiss-poster + scale-contrast + split-field

News incident: map to

newsroom-poster + stamp-label + big-number

Archive dossier: map to

field-notes + layered-depth + receipt-form

Product specimen: map to

product-catalog + edge-crop + annotation

Data poster: map to

data-poster + scale-contrast + big-number

After the user chooses, state the selected theme direction, final preset, design-language combination, and why it fits before moving into the concept plan.

请勿向用户直接展示完整的预设目录。加载

references/themes/presets.md

，当视觉方向重要时，同时加载

references/design-languages.md

；然后根据内容、平台、受众和分享目标，推荐3-5个基于场景的风格选项。在内部将用户选择的场景映射到最终的主题预设和设计语言组合。

当请求用户选择风格时，请勿仅提供一个推荐选项加模糊的“或更改？”问题。请提供3-5个具体选项，每个选项包含：

面向用户的简短风格名称；
最适用的场景；
一行视觉描述；
内部对应的主题预设和设计语言映射。

使用两层选择逻辑，确保输出内容合适且不会局限于少数几种风格：

默认推荐层：
- 根据内容类型、平台、受众和分享目标，提供3-5个高度匹配的风格选项。
- 确保推荐的选项与用户任务足够贴合，任何选项无需大量返工即可成功。
- 优先选择视觉效果有明显差异的选项，而非仅令牌名称不同。例如：保守报告风格、数据海报风格、社交笔记风格、杂志讲解风格、大胆观点风格。
变体调整层：
- 当用户未明确指定精确风格时，在兼容的风格家族内进行调整，而非始终选择顶级默认选项。
- 在相似任务中，至少改变以下两个维度：主题预设、主设计语言、修饰符、布局模板、视觉锚点、表面隐喻或标题组合。
- 确保调整后的风格在语义上与内容兼容。请勿使用与主题、平台、可访问性或事实清晰度冲突的随机新颖风格。
- 将最终选择的组合记录在概念规划或
```
sources.md
```
  /
```
credits.md
```
  中，以便可追溯变体。

使用面向用户的场景标签，例如：

工程信息图：映射到

engineering-paper

、

product-manual

或

porcelain-research

。

业务简报：映射到

quiet-report

、

product-manual

或

porcelain-research

。

大胆观点：映射到

bold-editorial

、

magazine-eink

或

newsroom-paper

。

社交产品笔记：映射到

social-notebook

、

magazine-eink

或

bold-editorial

。

社论/杂志风格：映射到

magazine-eink

、

dune-gallery

、

field-notes

或

kraft-editorial

。

对于设计语言选择，使用面向用户的场景标签，例如：

技术感且设计精良：映射到

editorial-artifact + cutaway + annotation

。

杂志讲解风格：映射到

image-led-magazine + edge-crop + asymmetric-space

。

大胆论点风格：映射到

swiss-poster + scale-contrast + split-field

。

新闻事件风格：映射到

newsroom-poster + stamp-label + big-number

。

档案卷宗风格：映射到

field-notes + layered-depth + receipt-form

。

产品样本风格：映射到

product-catalog + edge-crop + annotation

。

数据海报风格：映射到

data-poster + scale-contrast + big-number

。

用户选择后，说明所选的主题方向、最终预设、设计语言组合及其适配原因，然后再进入概念规划环节。

Design Context

设计上下文

Prefer existing design context over inventing a new visual system.

Always load
```
references/taste.md
```
before choosing visual direction. Carry its anti-AI-trace rules into the visual DNA summary.
Before planning the cards, look for any user-provided or local brand assets, previous card sets, screenshots, Figma/UI kit references, project design systems, existing webpages, or code styles that should influence the result.
When the user asks for an editorial, magazine, e-ink, presentation-inspired, or image-heavy card style, load
```
references/magazine-card-adaptations.md
```
and apply only the card-suitable parts: editorial shell, compact layout archetypes, restrained ink/paper palettes, and image slot workflow.
When the card set needs stronger design, or when the style is not explicitly minimal, load
```
references/layouts/card-layouts.md
```
and use it as the layout contract before writing HTML.
When the card set needs stronger design, style variation, or user-selectable visual directions, load
```
references/design-languages.md
```
and choose a primary design language plus 1-2 modifiers.
Extract a compact visual DNA summary: palette, typography feel, information density, border radius, shadow/depth, image or illustration treatment, layout rhythm, and copy tone.
If no reliable design context is available, derive the visual direction from the content, audience, platform, and requested mood, and state that assumption in the plan.

优先使用现有设计上下文，而非创建新的视觉系统。

在选择视觉方向前，始终加载
```
references/taste.md
```
。将其反AI痕迹规则融入视觉DNA总结中。
在规划卡片前，查找任何用户提供的或本地的品牌资产、之前的卡片集、截图、Figma/UI套件参考、项目设计系统、现有网页或代码风格，这些都应影响最终结果。
当用户要求社论、杂志、电子墨水、演示文稿风格或图片密集型卡片时，加载
```
references/magazine-card-adaptations.md
```
，并仅应用适用于卡片的部分：社论框架、紧凑布局原型、克制的墨水/纸张调色板和图片插槽工作流。
当卡片集需要更强的设计感，或风格未明确要求极简时，加载
```
references/layouts/card-layouts.md
```
，并在编写HTML前将其作为布局契约。
当卡片集需要更强的设计感、风格变化或用户可选的视觉方向时，加载
```
references/design-languages.md
```
，并选择一种主设计语言加1-2个修饰符。
提取紧凑的视觉DNA总结：调色板、排版风格、信息密度、边框圆角、阴影/深度、图片或插图处理方式、布局节奏和文案语气。
如果没有可靠的设计上下文，从内容、受众、平台和请求的情绪中推导视觉方向，并在规划中说明该假设。

Theme Presets

主题预设

Use theme presets as starting points, not as copied CSS. Define a fresh token block for each card set and adapt the palette to the content.

Apply
```
references/taste.md
```
before theme selection. A preset can suggest palette and mood, but it cannot reintroduce Inter, pure black, centered hero defaults, three equal cards, AI purple-blue gradients, neon glows, fake data, or AI-copy voice.
Load
```
references/themes/presets.md
```
when the user asks for style options, when the style is ambiguous, or when the card set needs a clear visual direction.
Use 3-5 scenario-based theme options before coding when appropriate. Do not list the full preset catalog to the user.
Convert the selected scenario direction into a final preset from the catalog, then adapt it with fresh local tokens.
Do not copy external theme CSS wholesale. Recreate the needed palette and behavior in the local card style.

Default recommendation rules:

Technical, API, architecture, or infrastructure content: prefer
```
engineering-paper
```
; alternatives are
```
product-manual
```
and
```
porcelain-research
```
.
News, releases, product updates, changelogs, or incidents: prefer
```
newsroom-paper
```
; alternatives are
```
quiet-report
```
and
```
engineering-paper
```
.
Business, fundraising, growth, or product narrative: prefer
```
quiet-report
```
; alternatives are
```
product-manual
```
and
```
porcelain-research
```
.
Opinion, commentary, or strong shareable hook: prefer
```
bold-editorial
```
; alternatives are
```
magazine-eink
```
and
```
newsroom-paper
```
.
Xiaohongshu, lifestyle, or consumer product content: prefer
```
social-notebook
```
; alternatives are
```
magazine-eink
```
and
```
bold-editorial
```
.
Editorial, talk-summary, longform, culture, essay, or premium carousel content: prefer
```
magazine-eink
```
; alternatives are
```
dune-gallery
```
,
```
field-notes
```
, and
```
kraft-editorial
```
based on topic.
CLI, security, or terminal tools: prefer
```
engineering-paper
```
,
```
product-manual
```
, or
```
newsroom-paper
```
; use
```
terminal-green
```
only when the user explicitly asks for a terminal look.
Do not default to neon, cyberpunk, terminal, glowing dark dashboards, or blue-purple AI gradients unless the user explicitly asks for that visual language.

将主题预设作为起点，而非直接复制的CSS。为每个卡片集定义新的令牌块，并根据内容调整调色板。

在选择主题前应用
```
references/taste.md
```
。预设可提供调色板和情绪建议，但不得重新引入Inter字体、纯黑色、默认居中主视觉、三等分卡片布局、AI紫蓝渐变、霓虹发光效果、虚假数据或AI文案语气。
当用户要求风格选项、风格模糊或卡片集需要明确的视觉方向时，加载
```
references/themes/presets.md
```
。
适当时，在编码前提供3-5个基于场景的主题选项。请勿向用户列出完整的预设目录。
将用户选择的场景方向转换为目录中的最终预设，然后使用新的本地令牌进行调整。
请勿直接复制外部主题CSS。在本地卡片样式中重新创建所需的调色板和行为。

默认推荐规则：

技术、API、架构或基础设施内容：优先选择
```
engineering-paper
```
；备选为
```
product-manual
```
和
```
porcelain-research
```
。
新闻、发布、产品更新、变更日志或事件内容：优先选择
```
newsroom-paper
```
；备选为
```
quiet-report
```
和
```
engineering-paper
```
。
业务、融资、增长或产品叙事内容：优先选择
```
quiet-report
```
；备选为
```
product-manual
```
和
```
porcelain-research
```
。
观点、评论或强分享钩子内容：优先选择
```
bold-editorial
```
；备选为
```
magazine-eink
```
和
```
newsroom-paper
```
。
小红书、生活方式或消费产品内容：优先选择
```
social-notebook
```
；备选为
```
magazine-eink
```
和
```
bold-editorial
```
。
社论、谈话总结、长篇内容、文化、随笔或高端轮播内容：优先选择
```
magazine-eink
```
；根据主题，备选为
```
dune-gallery
```
、
```
field-notes
```
和
```
kraft-editorial
```
。
CLI、安全或终端工具内容：优先选择
```
engineering-paper
```
、
```
product-manual
```
或
```
newsroom-paper
```
；仅当用户明确要求终端风格时，才使用
```
terminal-green
```
。
除非用户明确要求，否则默认不使用霓虹、赛博朋克、终端、发光深色仪表盘或蓝紫AI渐变等视觉语言。

Editorial Magazine Mode

社论杂志模式

Use

references/magazine-card-adaptations.md

when the card set should borrow from presentation or magazine design. This mode is inspired by

op7418/guizang-ppt-skill

, but adapted for static card exports.

Reuse only card-appropriate ideas: editorial chrome, footer metadata, visible page numbers, serif/display title hierarchy, monospace metadata, restrained ink/paper palettes, and compact layout archetypes.
Do not reuse slide-specific behavior: horizontal navigation, WebGL backgrounds, Motion One reveal systems,
```
vh
```
-driven slide sizing, or PPT-only class names.
Before coding, choose the archetype for each card: editorial cover, section divider, big numbers, left narrative + right visual, image proof grid, pipeline/process, question closer, big quote, before/after, or lead image + sidebar.
Treat
```
chrome
```
and
```
kicker
```
as different content roles.
```
chrome
```
is stable metadata or series navigation;
```
kicker
```
is the unique hook for that card. They must not repeat the same idea.
If images are involved, define the image slot and ratio before sourcing or generating the asset. Generated images are card assets only; they must not include titles, page numbers, watermarks, captions, or card borders.

当卡片集需要借鉴演示文稿或杂志设计时，使用

references/magazine-card-adaptations.md

。此模式灵感来自

op7418/guizang-ppt-skill

，但已适配静态卡片导出需求。

仅复用适用于卡片的创意：社论框架、页脚元数据、可见页码、衬线/展示型标题层级、等宽元数据、克制的墨水/纸张调色板和紧凑布局原型。
不复用幻灯片特定行为：横向导航、WebGL背景、Motion One Reveal系统、
```
vh
```
驱动的幻灯片尺寸或仅适用于PPT的类名。
编码前，为每张卡片选择原型：社论封面、章节分隔页、大数字、左侧叙事+右侧视觉、图片证明网格、流程/步骤、问题收尾、大金句、前后对比或主图+侧边栏。
将
```
chrome
```
和
```
kicker
```
视为不同的内容角色。
```
chrome
```
是稳定的元数据或系列导航；
```
kicker
```
是每张卡片独有的钩子。两者不得重复相同内容。
如果涉及图片，在获取或生成资产前定义图片插槽和比例。生成的图片仅作为卡片资产；不得包含标题、页码、水印、说明或卡片边框。

Layout Contract

布局契约

Use

references/layouts/card-layouts.md

whenever the output should have visible design quality, not just readable information.

Apply
```
references/taste.md
```
as the first layout filter. Reject centered hero defaults and three equal-card layouts unless the user explicitly asks for them and the choice is justified.
Before writing HTML, create a one-row-per-card layout plan with: card role, layout recipe, visual anchor, text density, asset slot, and layout risk.
Plan information density at the set level. A real explainer set should not have every card at low density; include at least one mechanism, proof, checklist, comparison, or takeaway card with 2-4 concrete points.
A visual anchor is mandatory for every card. It can be typography, a number, image, artifact, diagram, form, stamp, map, screenshot, or custom CSS object. If the anchor is "none", redesign the card concept.
For 1-3 cards, use at least 2 layout recipes. For 4-7 cards, use at least 3. For 8+ cards, use at least 4 and add reset cards every 3-4 cards.
Avoid repeating
```
headline + equal grid + footer
```
across the set. Shared style is good; repeated composition is not.
Avoid making fine lines, coordinate grids, and boxed panels the default design language. Use them only as support for a stronger visual anchor.
Prefer composition moves such as crop, overlap, diagonal placement, scale contrast, cutaway shapes, stamps, labels, tapes, large image/object anchors, and asymmetric whitespace.
During concept planning, present the layout plan when layout/design quality is a concern. During final QA, name the actual layout used for each rendered card.

当输出需要可见的设计质量而非仅可读信息时，使用

references/layouts/card-layouts.md

。

将
```
references/taste.md
```
作为第一个布局过滤器。除非用户明确要求且选择合理，否则拒绝默认居中主视觉和三等分卡片布局。
编写HTML前，创建每行对应一张卡片的布局规划：卡片角色、布局模板、视觉锚点、文本密度、资产插槽和布局风险。
在卡片集层面规划信息密度。真正的讲解类卡片集不应每张卡片都低密度；至少包含一张带有2-4个具体要点的机制、证明、清单、对比或要点卡片。
每张卡片必须有一个视觉锚点。它可以是排版、数字、图片、人工制品、图表、表单、印章、地图、截图或自定义CSS对象。如果锚点为“无”，则重新设计卡片概念。
对于1-3张卡片，使用至少2种布局模板。对于4-7张卡片，使用至少3种。对于8张及以上卡片，使用至少4种，并每3-4张卡片添加一张重置卡片。
避免在卡片集中重复使用“标题+等宽网格+页脚”布局。共享风格是好的；重复构图则不然。
避免将细线、坐标网格和框式面板作为默认设计语言。仅将它们作为更强视觉锚点的支撑元素使用。
优先使用以下构图手法：裁剪、重叠、对角线放置、比例对比、镂空形状、印章、标签、胶带、大图片/对象锚点和不对称留白。
在概念规划中，当布局/设计质量是关注点时，展示布局规划。在最终QA中，说明每张渲染卡片实际使用的布局。

Design Language System

设计语言系统

Use

references/design-languages.md

to define the card set's visual grammar independently from the theme preset.

A theme preset controls palette and type tone; a design language controls composition, focal devices, visual metaphors, texture, and pacing.
Choose 1 primary design language and optionally 1-2 modifiers. Do not combine more than 3 languages/modifiers unless the user asks for eclectic variation.
After choosing a primary design language, load its individual spec file from
```
references/design-languages/<name>.md
```
and follow its
```
Must Use
```
,
```
Must Not Use
```
, typography, layout, density, asset, and QA rules.

Supported primary languages include

editorial-artifact

swiss-poster

image-led-magazine

field-notes

newsroom-poster

product-catalog

cinematic-still

, and

data-poster

Supported modifiers include

scale-contrast

edge-crop

diagonal-tension

layered-depth

split-field

asymmetric-space

cutaway

stamp-label

receipt-form

annotation

big-number

paper-cut

, and

map-route

Users may choose a preset combination such as Technical but designed, Magazine explainer, Bold thesis, News incident, Archive dossier, Product specimen, or Data poster.
Keep the design-language combination stable across the set, but vary layout recipes and visual anchors per card.
When a card set mixes multiple primary languages, designate one primary language for the whole set and use other languages only as card-level accents.

使用

references/design-languages.md

独立于主题预设定义卡片集的视觉语法。

主题预设控制调色板和排版语气；设计语言控制构图、焦点设备、视觉隐喻、纹理和节奏。
选择1种主设计语言，可选1-2个修饰符。除非用户要求折衷变化，否则组合的语言/修饰符不超过3种。
选择主设计语言后，从
```
references/design-languages/<name>.md
```
加载其单独的规范文件，并遵循其「必须使用」「不得使用」、排版、布局、密度、资产和QA规则。

支持的主设计语言包括

editorial-artifact

、

swiss-poster

、

image-led-magazine

、

field-notes

、

newsroom-poster

、

product-catalog

、

cinematic-still

和

data-poster

。

支持的修饰符包括

scale-contrast

、

edge-crop

、

diagonal-tension

、

layered-depth

、

split-field

、

asymmetric-space

、

cutaway

、

stamp-label

、

receipt-form

、

annotation

、

big-number

、

paper-cut

和

map-route

。

用户可选择预设组合，例如“技术感且设计精良”“杂志讲解风格”“大胆论点风格”“新闻事件风格”“档案卷宗风格”“产品样本风格”或“数据海报风格”。
在卡片集中保持设计语言组合稳定，但每张卡片的布局模板和视觉锚点可不同。
当卡片集混合多种主设计语言时，为整个卡片集指定一种主设计语言，其他语言仅作为卡片级的点缀使用。

Workflow

工作流

Collect parameters and ask user questions when needed.
- Extract known parameters from the original request and do not repeat them.
- Apply the Ask User Questions policy: infer low-risk defaults, ask only for true blockers, and adapt to the current agent's interaction mode.
- Do not read
```
references/taste.md
```
  at this step; it is loaded later in step 4 (theme/language selection) and step 7 (QA).
- Skip the question step only when the user explicitly asked for no questions or explicitly approved defaults. Direct generation, quick export, or "帮我做" requests still require one early parameter confirmation when meaningful choices are missing.
Conditional deep research and fact outline confirmation.
- Apply the trigger rules in Research & Fact Confirmation: run a research pass when the input is a topic, URL, brief, question, or "make cards about X" request; skip when the input is already a full article, transcript, structured notes, or finished outline.
- When triggered, produce the fact outline (core claim, 3-7 supporting points with concrete data, sources, open questions). Present it to the user and wait when the facts, framing, or scope may change the card narrative; otherwise record clear and uncontested facts with sources after the initial parameter confirmation.
- Treat this confirmation as separate from the later visual/concept confirmation in step 6 when the workflow is confirmation-led. In execution-first workflows, turn it into a short progress update instead of a blocking gate unless Stop Conditions apply.
- Save confirmed sources into
```
sources.md
```
  in the output folder.
- Skip entirely when not triggered, or when the user explicitly asked to proceed without research.
Expand and structure the content.
- Extract the core message, audience, emotional hook, claims, and supporting points from the confirmed bones (or directly from the input if step 2 was skipped).
- If
```
count
```
  is missing, choose the smallest number of cards that covers the idea without crowding; prefer 3-7 cards for explainers and 1-3 cards for announcements.
- Decide a title, subtitle, and key visual idea for every card.
- Decide the set-level density arc before writing final copy. For 3 cards, default to
```
hook / explain / takeaway
```
  ; for 5 cards, default to
```
hook / context / mechanism / evidence / takeaway
```
  ; for 7 cards, default to
```
hook / context / mechanism / evidence / contrast / action / closer
```
  .
- Unless the user wants poster-only cards, include at least one card with a concrete claim plus 2-4 supporting points, labels, observations, steps, or callouts.
- Remove AI-copy phrases, generic placeholder brands/names, and fake-looking numbers during copy planning.
Pick the theme preset and design language, then build the layout plan.
- Load
```
references/taste.md
```
  now and read it as an active checklist; the hard constraints apply to every subsequent design decision in this step.
- Confirm or revisit the theme preset chosen in step 1 against the taste baseline; if a preset would violate a hard constraint, swap it before continuing.
- Apply the two-layer style selection logic: first choose from the high-fit recommendation set, then apply a compatible variant perturbation when the user did not specify an exact style.
- The perturbation must affect the visible result, not only metadata. Rotate layout recipes, visual anchors, surface metaphors, and composition moves alongside theme / design-language tokens.
- Assign one concrete layout recipe per card. For stronger design work, use
```
references/layouts/card-layouts.md
```
  ; for magazine/editorial cards, also use
```
references/magazine-card-adaptations.md
```
  .
- Assign a design-language combination when the style is open or the user wants more design variation. Load the individual spec file for the selected primary language from
```
references/design-languages/<name>.md
```
  .
- Load
```
references/fonts.md
```
  and run its font-selection algorithm: from the chosen preset × design-language × content-language, take the per-role candidate pools, apply hard-constraint filtering, then weighted-random pick one font per role for the whole set (seed the randomness with the output slug so a given set is reproducible but different topics vary). Record the selected display/serif/sans/mono families in
```
sources.md
```
  .
- For each card, identify the visual anchor and composition move before writing body copy. If the card is only text blocks, equal boxes, or a background grid, either choose a stronger layout or deliberately mark it as a low-design utility card.
- Respect low-density primary language limits by moving detail to another card in the set, not by overloading
```
swiss-poster
```
  ,
```
cinematic-still
```
  , quote, cover, or closer cards.
Plan concepts and request confirmation.
- Present the resolved ratio, card count, selected theme direction and preset, selected design language/modifiers, content outline, and first-card concept.
- When layout quality matters, include the layout plan: card role, layout recipe, visual anchor, composition move, text density, and asset slot.
- State which card carries the useful detail when the cover or primary language is intentionally low-density.
- Make card 1 a precise high-impact cover: it must communicate the topic instantly, create curiosity, and feel worth opening and sharing.
- Concept confirmation covers only the cover concept, content outline, and visual direction. Do not repeat questions about already-resolved ratio, count, theme, platform, or output constraints.
- When the task is high-impact or the style is ambiguous after the question step, offer 3-5 visual directions before coding. Cover distinct options such as brand-aligned/conservative, structured/information-graphic, social-friendly, magazine/editorial, and bolder/shareable.
- For each direction, describe the cover concept, overall visual language, and the situation where it works best.
- Skip concept variations when the user already specified the visual style, explicitly asked to proceed without confirmation, or needs a fast direct export.
- Ask the user to confirm before coding when Stop Conditions apply or when the concept direction may materially change the output. If the user already confirmed parameters and the concept follows those choices, state the concept briefly as a progress update and continue into implementation.
Build the card webpages.
- Create one HTML page per card, named predictably such as
```
card-01.html
```
  ,
```
card-02.html
```
  .
- Use one shared CSS file or shared design tokens so size, typography, spacing, palette, border radius, and component styling stay consistent.
- Choose fonts via the
```
references/fonts.md
```
  selection algorithm decided in step 4; embed them locally by importing
```
assets/fonts/fonts.css
```
  (or copying the used fonts into
```
cards/<slug>/assets/fonts/
```
  and referencing them with local
```
@font-face
```
  ). Never load fonts from a CDN. Choose colors that satisfy
```
references/taste.md
```
  : do not default to Inter, do not use pure black, and avoid generic AI purple-blue gradients or neon glow effects.
- Set an explicit fixed canvas size derived from the ratio. Recommended bases:
  - ```
  1:1
```
  :
```
  1080x1080
```
- ```
3:4
```
    :
```
1080x1440
```
  - ```
  9:16
```
  :
```
  1080x1920
```
- Custom
```
  a:b
```
  : use width
```
  1080
```
  and height
```
  round(1080*b/a)
```
  unless the user requests exact pixels.
- Keep every card inside a single fixed-size
```
.card
```
  root. Do not allow body scrolling.
- Use real HTML/CSS text instead of baking text into images.
- Use the same style language across cards; vary composition only enough to fit content.
- Define shared layout primitives in CSS for the selected recipes before implementing individual cards. Each card should have a recognizable layout parent class such as
```
.layout-cover
```
  ,
```
.layout-split
```
  ,
```
.layout-artifact
```
  ,
```
.layout-rail
```
  ,
```
.layout-compare
```
  ,
```
.layout-quote
```
  , or
```
.layout-checklist
```
  .
- For editorial magazine mode, build the shell with card-native classes in the local CSS. Do not paste PPT layout classes unless they are defined and adapted in the card set's CSS.
Score and regenerate each card.
- Reload
```
references/taste.md
```
  and read it as the QA acceptance checklist before scoring; do not score from memory.
- Render and screenshot every card before judging it.
- Score each card on:
  - Boundary: no obvious clipping, unintended scrollbars, text outside the canvas, or important elements touching edges.
  - Color: palette is legible, attractive, intentional, and consistent with the requested style.
  - Layout: hierarchy is clear, whitespace is balanced, and content density fits the ratio.
  - Information value: the set has at least one card with actionable or concrete detail, not only atmospheric headlines; any low-density card is justified by role or primary language.
  - Layout contract: the planned visual anchor is present and dominant enough, the recipe can be recognized from the screenshot, and the set does not repeat the same composition card after card.
  - Design expression: the card does not rely mainly on fine lines, grids, and boxed panels; those elements must be secondary to the visual anchor.
  - Design language: the selected primary language and modifiers are recognizable from the screenshot, and the relevant spec file's
```
Must Use
```
    /
```
Must Not Use
```
    rules are satisfied.
  - Taste baseline: every hard constraint in
```
references/taste.md
```
    is satisfied — no Inter default, no pure black, no default centered hero, no three equal-card main layout, no AI-copy voice, no fake-looking data, no neon/glow AI aesthetics.
  - Editorial discipline when applicable: chrome and kicker are not redundant, image frames share consistent crop rules, and generated assets do not contain their own slide/card chrome.
- If any category fails, revise that card and rerender. Limit each card to 3 repair rounds.
- If a card still fails after 3 rounds, report the remaining risk and keep the best version.
Export final images.
- Use Playwright screenshots, not browser manual screenshots.
- Export one PNG per card with stable names such as
```
card-01.png
```
  .
- Default to 2x screenshot exports for sharpness. A
```
1080x1080
```
  card should export as a
```
2160x2160
```
  PNG unless the user explicitly asks for smaller files or
```
--scale 1
```
  .
- Provide the user with the output paths and a concise summary of the final ratio, count, and style.

收集参数，必要时向用户提问。
- 从原始请求中提取已知参数，无需重复询问。
- 应用「向用户提问」策略：推断低风险默认值，仅询问真正的阻塞性问题，并适应当前代理的交互模式。
- 此步骤无需读取
```
references/taste.md
```
  ；将在步骤4（主题/语言选择）和步骤7（QA）中加载。
- 仅当用户明确要求无需提问或明确批准默认参数时，才跳过提问步骤。即使用户要求“直接生成、快速导出或帮我做”，当存在有意义的选择缺失时，仍需尽早进行一次参数确认。
条件性深度调研与事实大纲确认。
- 应用「调研与事实确认」中的触发规则：当输入为主题、URL、简要需求、问题或“制作关于X的卡片”请求时，运行调研；当输入为完整文章、转录稿、结构化笔记或已完成大纲时，跳过调研。
- 触发调研后，生成事实大纲（核心主张、3-7个带具体数据的支持点、来源、开放性问题）。当事实、框架或范围可能改变卡片叙事时，呈现给用户并等待确认；否则在初始参数确认后，记录清晰无争议的事实及来源。
- 在以确认为导向的工作流中，此确认与后续步骤6中的视觉/概念确认是分开的。在以执行为导向的工作流中，除非满足停止条件，否则将其转换为简短的进度更新而非阻塞性环节。
- 将已确认的来源保存到输出文件夹中的
```
sources.md
```
  。
- 未触发调研或用户明确要求无需调研时，完全跳过此步骤。
扩展并结构化内容。
- 从已确认的骨架（或直接从输入内容，如果步骤2被跳过）中提取核心信息、受众、情感钩子、主张和支持点。
- 如果
```
count
```
  缺失，选择能完整覆盖主题且不拥挤的最小卡片数量；讲解类内容优先选择3-7张卡片，公告类内容优先选择1-3张卡片。
- 为每张卡片确定标题、副标题和关键视觉创意。
- 在撰写最终文案前，确定卡片集层面的密度曲线。3张卡片默认采用「钩子 / 讲解 / 要点」结构；5张卡片默认采用「钩子 / 背景 / 机制 / 证据 / 要点」结构；7张卡片默认采用「钩子 / 背景 / 机制 / 证据 / 对比 / 行动 / 收尾」结构。
- 除非用户要求仅生成海报卡片，否则至少包含一张带有具体主张加2-4个支持点、标签、观察、步骤或标注的卡片。
- 在文案规划中，删除AI生成的文案短语、通用占位符品牌/名称和虚假数字。
选择主题预设和设计语言，然后制定布局规划。
- 现在加载
```
references/taste.md
```
  ，并将其作为主动检查清单；硬性约束适用于此步骤中的所有后续设计决策。
- 根据风格基准确认或重新审视步骤1中选择的主题预设；如果预设违反硬性约束，在继续前更换预设。
- 应用两层风格选择逻辑：首先从高度匹配的推荐集中选择，然后当用户未指定精确风格时，应用兼容的变体调整。
- 调整必须影响可见结果，而非仅元数据。除主题/设计语言令牌外，还需调整布局模板、视觉锚点、表面隐喻和构图手法。
- 为每张卡片分配一个具体的布局模板。对于更强的设计工作，使用
```
references/layouts/card-layouts.md
```
  ；对于杂志/社论风格卡片，同时使用
```
references/magazine-card-adaptations.md
```
  。
- 当风格开放或用户需要更多设计变化时，分配设计语言组合。从
```
references/design-languages/<name>.md
```
  加载所选主设计语言的单独规范文件。
- 加载
```
references/fonts.md
```
  并运行其字体选择算法：从所选预设×设计语言×内容语言中，获取每个角色的候选池，应用硬性约束过滤，然后为整个卡片集的每个角色加权随机选择一种字体（使用输出slug作为随机种子，确保给定卡片集可重现，但不同主题会有所不同）。将所选的展示型/衬线/无衬线/等宽字体家族记录到
```
sources.md
```
  。
- 在撰写正文文案前，为每张卡片确定视觉锚点和构图手法。如果卡片仅包含文本块、等宽框或背景网格，要么选择更强的布局，要么故意将其标记为低设计实用卡片。
- 通过将细节移至卡片集中的另一张卡片，而非过度填充
```
swiss-poster
```
  、
```
cinematic-still
```
  、引用、封面或收尾卡片，来遵守低密度主设计语言的限制。
规划概念并请求确认。
- 呈现已确定的比例、卡片数量、所选主题方向和预设、所选设计语言/修饰符、内容大纲和第一张卡片的概念。
- 当布局质量重要时，包含布局规划：卡片角色、布局模板、视觉锚点、构图手法、文本密度和资产插槽。
- 当封面或主设计语言故意低密度时，说明哪张卡片承载了实用细节。
- 将第一张卡片设计为精确的高影响力封面：必须立即传达主题、激发好奇心，并值得打开和分享。
- 概念确认仅涵盖封面概念、内容大纲和视觉方向。无需重复询问已解决的比例、数量、主题、平台或输出约束问题。
- 当任务为高风险或提问步骤后风格仍模糊时，在编码前提供3-5个视觉方向。涵盖不同的选项，例如品牌对齐/保守风格、结构化/信息图风格、社交友好风格、杂志/社论风格和更大胆/易分享风格。
- 对于每个方向，描述封面概念、整体视觉语言及其最适用的场景。
- 当用户已指定视觉风格、明确要求无需确认或需要快速直接导出时，跳过概念变体。
- 当满足停止条件或概念方向可能实质性改变输出时，请求用户确认后再编码。如果用户已确认参数且概念符合这些选择，简要说明概念作为进度更新，然后继续实施。
构建卡片网页。
- 为每张卡片创建一个HTML页面，命名规则统一，如
```
card-01.html
```
  、
```
card-02.html
```
  。
- 使用一个共享CSS文件或共享设计令牌，确保尺寸、排版、间距、调色板、边框圆角和组件样式保持一致。
- 通过步骤4中确定的
```
references/fonts.md
```
  选择算法选择字体；通过导入
```
assets/fonts/fonts.css
```
  （或复制使用的字体到
```
cards/<slug>/assets/fonts/
```
  并使用本地
```
@font-face
```
  引用）将字体本地嵌入。请勿从CDN加载字体。选择符合
```
references/taste.md
```
  的颜色：不得默认使用Inter字体，不得使用纯黑色，避免通用AI紫蓝渐变或霓虹发光效果。
- 根据比例设置明确的固定画布尺寸。推荐基准：
  - ```
  1:1
```
  ：
```
  1080x1080
```
- ```
3:4
```
    ：
```
1080x1440
```
  - ```
  9:16
```
  ：
```
  1080x1920
```
- 自定义
```
  a:b
```
  ：使用宽度
```
  1080
```
  ，高度
```
  round(1080*b/a)
```
  ，除非用户要求精确像素。
- 将每张卡片限制在一个固定尺寸的
```
.card
```
  根元素内。不允许页面滚动。
- 使用真实的HTML/CSS文本，而非将文本嵌入图片。
- 在卡片间使用相同的风格语言；仅根据内容需要调整构图。
- 在实现单个卡片前，为所选模板在CSS中定义共享布局原语。每张卡片应有一个可识别的布局父类，如
```
.layout-cover
```
  、
```
.layout-split
```
  、
```
.layout-artifact
```
  、
```
.layout-rail
```
  、
```
.layout-compare
```
  、
```
.layout-quote
```
  或
```
.layout-checklist
```
  。
- 对于社论杂志模式，在本地CSS中使用卡片原生类构建框架。除非在卡片集的CSS中已定义并适配，否则请勿粘贴PPT布局类。
评分并重新生成每张卡片。
- 在评分前重新加载
```
references/taste.md
```
  ，并将其作为QA验收检查清单；请勿凭记忆评分。
- 在判断前渲染并截取每张卡片的截图。
- 从以下维度为每张卡片评分：
  - 边界：无明显裁剪、意外滚动条、文本超出画布或重要元素触碰边缘。
  - 颜色：调色板清晰可读、美观、意图明确，且与请求的风格一致。
  - 布局：层次清晰、留白平衡，内容密度符合比例。
  - 信息价值：卡片集至少包含一张带有可操作或具体细节的卡片，而非仅氛围化标题；任何低密度卡片的角色或主设计语言均合理。
  - 布局契约：计划的视觉锚点存在且足够突出，从截图可识别模板，卡片集不会重复使用相同构图。
  - 设计表达：卡片不主要依赖细线、网格和框式面板；这些元素必须作为视觉锚点的次要元素。
  - 设计语言：从截图可识别所选的主设计语言和修饰符，且符合相关规范文件的「必须使用」「不得使用」规则。
  - 风格基准：满足
```
references/taste.md
```
    中的所有硬性约束——无默认Inter字体、无纯黑色、无默认居中主视觉、无三等分主布局、无AI文案语气、无虚假数据、无霓虹/发光AI美学。
  - 社论规范（如适用）：
```
chrome
```
    和
```
kicker
```
    不重复，图片边框共享一致的裁剪规则，生成的资产不包含自身的幻灯片/卡片框架。
- 如果任何维度不达标，修改该卡片并重新渲染。每张卡片最多修改3次。
- 如果修改3次后仍不达标，报告剩余风险并保留最佳版本。
导出最终图片。
- 使用Playwright截图，而非手动浏览器截图。
- 为每张卡片导出一个PNG文件，命名规则稳定，如
```
card-01.png
```
  。
- 默认使用2倍截图导出以保证清晰度。
```
1080x1080
```
  的卡片应导出为
```
2160x2160
```
  的PNG，除非用户明确要求更小文件或使用
```
--scale 1
```
  。
- 向用户提供输出路径，并简要总结最终的比例、数量和风格。

Asset and Source Discipline

资产与来源规范

Keep generated files contained in the requested output folder.
Place any local images, logos, screenshots, textures, icons, or other assets used by the cards in
```
cards/<slug>/assets/
```
unless the user specifies another output path.
Record research sources, external asset sources, and important factual references in
```
sources.md
```
or
```
credits.md
```
inside the output folder.
Do not rely on external hotlinked assets for final exports. External URLs may be used during research or temporary preview only.
Copy only the minimum assets actually used by the card set; do not bulk-copy unrelated asset folders.
For generated or redesigned card images, record the prompt intent, model/tool if known, and whether the asset is synthetic in
```
sources.md
```
or
```
credits.md
```
.

将生成的文件限制在请求的输出文件夹内。
将卡片使用的任何本地图片、logo、截图、纹理、图标或其他资产放入
```
cards/<slug>/assets/
```
，除非用户指定其他输出路径。
将调研来源、外部资产来源和重要事实参考记录到输出文件夹中的
```
sources.md
```
或
```
credits.md
```
。
最终导出时请勿依赖外部热链接资产。外部URL仅可用于调研或临时预览。
仅复制卡片集实际使用的最小必要资产；请勿批量复制无关的资产文件夹。
对于生成或重新设计的卡片图片，将提示意图、已知的模型/工具以及资产是否为合成内容记录到
```
sources.md
```
或
```
credits.md
```
。

Rendering Helper

渲染助手

Use

scripts/render-cards.mjs

when a project does not already have an equivalent Playwright export script.

bash

node /path/to/card/scripts/render-cards.mjs \
  --input ./cards/my-set \
  --output ./cards/my-set/exports \
  --ratio 9:16

The helper defaults to

--scale 2

for sharper PNG output. Use

--scale 1

only when file size matters more than edge sharpness.

The script:

Scans the input folder for
```
.html
```
files.
Sets the viewport from
```
--ratio
```
or
```
--size
```
.
Screenshots
```
.card
```
when present, otherwise the viewport.
Writes PNG files to the output folder.
Writes
```
audit.json
```
with DOM overflow and out-of-bounds signals.

If Playwright is missing in the target project, install or use it with the local package manager, then install Chromium as needed:

bash

npm install -D playwright
npx playwright install chromium

当项目没有等效的Playwright导出脚本时，使用

scripts/render-cards.mjs

。

bash

node /path/to/card/scripts/render-cards.mjs \
  --input ./cards/my-set \
  --output ./cards/my-set/exports \
  --ratio 9:16

助手默认使用

--scale 2

以生成更清晰的PNG输出。仅当文件大小比边缘清晰度更重要时，才使用

--scale 1

。

该脚本：

扫描输入文件夹中的
```
.html
```
文件。
根据
```
--ratio
```
或
```
--size
```
设置视口。
当存在
```
.card
```
元素时截取其截图，否则截取视口截图。
将PNG文件写入输出文件夹。
写入
```
audit.json
```
，包含DOM溢出和越界信号。

如果目标项目中缺少Playwright，请使用本地包管理器安装，然后根据需要安装Chromium：

bash

npm install -D playwright
npx playwright install chromium

Implementation Rules

实施规则

Keep all cards visually siblings: shared tokens, shared base layout, shared type scale, shared image treatment.
Apply
```
references/taste.md
```
as the binding floor during the design step (Workflow step 4) and the QA step (Workflow step 7), including tests and demos. Do not skip these two loads even on fast paths.
Prefer existing design context over inventing a new visual system.
Use concept variations before coding when style is ambiguous or the card set is high-impact.
Define theme tokens first: background, surface levels, border levels, text levels, accent trio, semantic colors, gradients, radius, shadow, and fonts.
Use tokens in component CSS. Avoid scattering literal colors outside the token block unless a one-off asset or data visualization genuinely requires it.
Do not use Inter as the default card font. Select concrete fonts via the weighted-random algorithm in
```
references/fonts.md
```
(preset × design-language × content-language → per-role pick). Do not hardcode a font list here;
```
references/fonts.md
```
is the single source of truth. Avenir Next and other paid/system fonts are disallowed because every font must be locally embeddable.
Do not use pure black. Use off-black, charcoal, zinc-like darks, or ink colors.
Do not copy external theme CSS wholesale. Recreate the needed palette and behavior in the local card style, and keep source inspiration in
```
sources.md
```
or
```
credits.md
```
when relevant.
Avoid one-note palettes unless the user explicitly asks for a monochrome look.
Fit text by editing, grouping, or changing layout before shrinking everything.
Do not make every card low-density. For real explainers, at least one card should carry structured information: 2-4 points, labels, observations, steps, callouts, or decision criteria.
Do not add density by shrinking text everywhere. Add structure first: grouping, hierarchy, labels, side notes, checklists, captions, or object-attached callouts.
Replace AI-copy voice with concrete language. Avoid "赋能", "无缝", "释放", "下一代", "智能化", "重塑", and similar filler unless quoted from source material.
Do not invent fake data. Use verified facts with sources, clearly synthetic demo values, or no numbers.
Use responsive CSS only for development preview; the export canvas must remain fixed.
Prefer semantic HTML and CSS over canvas for card content unless the visual requires custom drawing.
Keep assets and source attribution inside the output folder.
Keep letter spacing at
```
0
```
unless the file's existing design system clearly requires uppercase tracking; do not use negative letter spacing.
For technical or dense cards, keep body copy in sans-serif and reserve serif/display type for headlines, quotes, and numbers. Editorial/literary presets (
```
magazine-eink
```
,
```
field-notes
```
,
```
kraft-editorial
```
) may use serif or kai (楷体) body per
```
references/fonts.md
```
. For editorial layouts, manually control long Chinese title breaks regardless of the body typeface.
For image-heavy cards, standardize image ratios or frame heights inside each group, crop from the bottom when using
```
cover
```
, and use
```
contain
```
for diagrams or text-bearing screenshots.
Do not skip visual verification. The final answer must state whether rendering and export succeeded.

保持所有卡片视觉上的一致性：共享令牌、共享基础布局、共享排版比例、共享图片处理方式。
在设计步骤（工作流步骤4）和QA步骤（工作流步骤7）中，将
```
references/taste.md
```
作为必须遵守的底线，包括测试和演示。即使是快速路径，也请勿跳过这两次加载。
优先使用现有设计上下文，而非创建新的视觉系统。
当风格模糊或卡片集为高风险内容时，在编码前使用概念变体。
首先定义主题令牌：背景、表面层级、边框层级、文本层级、强调色三元组、语义颜色、渐变、圆角、阴影和字体。
在组件CSS中使用令牌。除非一次性资产或数据可视化确实需要，否则避免在令牌块外使用字面颜色。
请勿将Inter作为默认卡片字体。通过
```
references/fonts.md
```
中的加权随机算法选择具体字体（预设×设计语言×内容语言→按角色选择）。请勿在此处硬编码字体列表；
```
references/fonts.md
```
是唯一的事实来源。禁止使用Avenir Next等付费/系统字体，因为所有字体必须可本地嵌入。
请勿使用纯黑色。使用近黑色、炭灰色、锌灰色或墨水色。
请勿直接复制外部主题CSS。在本地卡片样式中重新创建所需的调色板和行为，相关的灵感来源记录到
```
sources.md
```
或
```
credits.md
```
。
除非用户明确要求单色外观，否则避免单一色调的调色板。
在缩小所有内容前，通过编辑、分组或更改布局来适配文本。
请勿让每张卡片都低密度。对于真正的讲解类内容，至少有一张卡片应包含结构化信息：2-4个要点、标签、观察、步骤、标注或决策标准。
请勿通过缩小所有文本来增加密度。首先添加结构：分组、层次、标签、旁注、清单、说明或附加到对象的标注。
用具体语言替换AI生成的文案语气。避免使用“赋能”“无缝”“释放”“下一代”“智能化”“重塑”等填充词，除非是引用源材料。
请勿编造虚假数据。使用带来源的已验证事实、明确的合成演示值或不使用数字。
仅在开发预览中使用响应式CSS；导出画布必须保持固定。
除非视觉需要自定义绘图，否则优先使用语义化HTML和CSS实现卡片内容。
将资产和来源归因保留在输出文件夹内。
字母间距保持为
```
0
```
，除非文件的现有设计系统明确要求大写字母间距；请勿使用负字母间距。
对于技术或密集型卡片，正文使用无衬线字体，衬线/展示型字体保留用于标题、引用和数字。社论/文学预设（
```
magazine-eink
```
、
```
field-notes
```
、
```
kraft-editorial
```
）可根据
```
references/fonts.md
```
使用衬线或楷体正文。对于社论布局，无论正文字体如何，手动控制长中文标题的换行。
对于图片密集型卡片，在每组内标准化图片比例或框高，使用
```
cover
```
时从底部裁剪，对于图表或带文本的截图使用
```
contain
```
。
请勿跳过视觉验证。最终答案必须说明渲染和导出是否成功。