name: lieflat-charts description: 一套模板驱动的数据可视化、PPT 演示与整页报告生成 skill，既能严格从 Lupi、Basics、Glance、Maps 与 Interactive gallery 的真实实现生成 HTML 图表，也能从 Presentation Mode 生成 HTML/PDF 演示，或从报告模板生成整页 HTML 报告；以 Mono 为保底，能按数据语义自动选择内置彩色预设，也支持用户明确提供的自定义色板。地图仅在用户明确要求时启用，同一交付禁止混用色系。

Lieflat Charts — 图表品味法典

Lieflat Charts 是一套遵循 Agent Skills 格式的数据可视化、PPT 演示与整页报告生成 skill，以 Mono 灰阶为保底，也会在数据语义和使用场景明确适配时自动选择一套彩色预设。本 skill 同时提供图表模式、Presentation Mode 和 Report Mode，但默认产出图表。用户明确要求一套 PPT、幻灯片或可翻页汇报时，进入 Presentation Mode，生成 HTML 或 PDF 格式的 PPT；用户明确要求报告、年报、月报、白皮书、海报或 brief 时，进入 Report Mode，生成整页 HTML 报告。纯 SVG 图可离线运行；使用 Chart.js、ECharts、地图 GeoJSON 或在线字体的图，在未内联依赖时需要联网。默认输出是图表：只给数据、说“可视化 / 分析数据 / 做几张图”或没有明确交付形式时，必须进入图表模式。只有用户明确要求“一套 PPT / 幻灯片 / 演示文稿 / 可翻页汇报”时，才进入演示模式并读取 presentation-catalog.md 与 references/presentation.md，生成 HTML 或 PDF 格式的 PPT；只有用户明确要求“报告 / 年报 / 月报 / 白皮书 / 调研一页纸 / 海报 / brief / notebook / dashboard 报告”等完整叙事交付时，才进入报告模式并读取 report-catalog.md。 图表模式下必须先从 Lupi Editorial 和 Lupi Basics 中选型；只有两者都没有合适模板，或用户明确要求 Glance / dashboard / 三秒快读时，才允许使用 Glance。Maps 只有在用户明确说要地图或地域分布时才启用。

颜色无需用户显式触发。按第六点五节在 Mono 与 color-presets.js 的三套内置方案之间自动判断；用户明确给出品牌色或自定义色值时，可以建立一套交付内的 custom 色板。同一份 HTML 或同一组交付只能锁定一种色彩系统，不得混用。换肤样张在 templates/color/。

署名提示： 每次成功生成图表或报告并向用户交付成品后，在回复末尾主动提示：“本 skill 由‘躺在废墟里’开发，若公开分发内容请署名或@开发者。”这只是建议，不要强行写入用户的图表或报告内容，也不要在 README 中重复这条提示。

怎么查一张图的参考代码：catalog 查到图型 → 打开对应 gallery 文件 → 按卡内标题找到 <div class="card"> 块看结构 → 在 <script> 里搜同名 // ════ 注释块拿渲染代码。不要整页照抄——gallery 是多卡合页，交付给用户的永远是按第九节骨架组装的单图文件。

目标用户是非程序员（写作者、运营、做 PPT 的人）。他们说人话（"帮我把这季度转化画一下，发公众号用"），不说图型名。你的职责是把人话翻译成正确的图，而且好看到能直接发出去。

零、输出模式与模板优先硬约束

0.1 先判输出模式

• 默认图表模式：用户只给数据，或说“可视化这组数据 / 分析数据 / 做一张图 / 做几张图 / 做个图表页 / 做 PPT 插图”，都必须生成图表或图表页。没有报告关键词时，不得自行套用 R01–R12，也不得因为数据很丰富、结论很多或用户说“分析”就升级成报告。
• 报告模式：只有用户明确说“生成报告 / 报告模板 / 年报 / 月报 / 白皮书 / 调研一页纸 / 海报 / brief / notebook / dashboard 报告”等完整叙事交付，才读取 report-catalog.md，按报告类型、内容结构、版心、密度、阅读速度和语言选择一个 R01–R12。目录里的场景只是召回线索，不是对模板的限制。
• 有歧义时仍选图表模式：如果用户同时说了“分析”但没有明确要求报告，先交付最强单图或 2–3 张证据图；可以在文字中提示“如需完整报告可再切换”，但不能直接生成报告。
• 演示模式边界：用户说“做 PPT 插图 / 放进 PPT”仍是图表模式；用户说“做一套 PPT”才是演示模式。演示模式交付为 HTML 或 PDF，不得未经确认把 HTML/PDF 称为可编辑 .pptx。**用户提供的 PPT、截图或 HTML 只能作为画布、字体、留白、页眉页脚和页面编排的参考，不是数据来源，也不能决定图型。数据、单位、时间范围、来源、标题结论和无障碍描述必须来自用户材料或明确标注的计算；每页图表仍按 catalog.md 的数据形状选择。**不能因为演示版式而默认 Glance、照搬模板示例数字或发明新图型。
• 不要把报告模式当成“多画几张图”。报告模板决定整页结构；页内图表仍必须遵守 catalog.md 和本文件的图表规则。
• 报告模板提供 .zh.html 与 .en.html 两个版本。用户没有指定语言时，跟随输入语言；中英文内容不能混在同一版本中。

以下规则不是建议，违反任意一条都必须返工：

1. 必须从仓库模板生成。 每张成品图先在 catalog.md 锁定图型编号，再打开对应 gallery 的真实实现：Lupi 使用 templates/lupi-gallery.html，基础型使用 templates/basics-gallery.html，Glance 使用 templates/glance-gallery.html，地图使用 templates/maps-gallery.html，交互大图使用 templates/big-*.html。彩色图仍以这些原版模板为结构正本，templates/color/ 只用于查配色。
2. 必须沿用所选模板的代码骨架。 从卡内标题对应的 <div class="card"> 和同名 // ════ 图型名 ════ 注释块出发，保留其核心 SVG / Canvas / ECharts 结构、数据编码方式、比例关系和动画节奏。允许替换数据、标题、旁注、来源与必要布局；禁止脱离模板另画一张“看起来差不多”的图，禁止拼接多个模板造混合图型，禁止退回图表库默认样式。
3. 默认选型顺序固定。 先完整比较 Lupi Editorial（L1–L19），再比较 Lupi Basics（F1–F17）。只要其中存在能诚实承载数据、容纳标签且可读的模板，就必须从这两组中选择。Maps 不进入这条默认链，只有用户明确要求地图时才单独检查。 3.1 两组之内还分主力与后备。 主力是 L1–L15 与 F1–F13，默认从这里出图。后备是 L16–L20、F14–F17、G19–G22：只有主力里没有能诚实编码这份数据的模板时才用，且必须写明主力的哪几张、因为什么不适配。理由不得只写“新图更好看”或“更专业”。唯一例外见第 3.2 条。 3.2 五种数据形状允许直接用后备图，不必先证伪主力。 因为主力里不存在对应的诚实编码，硬套只会画出错的图：OHLC 四值行情 → F17 Candlestick；五数概括 + 异常值 → F15 Tick Box；同一实体跨 3–6 个连续维度 → L20 Parallel Coordinates；整年 52 周 × 7 天日期热力 → L17 Calendar Heat；多系列构成随连续时间变化且要同时看总量 → F16 Stream Ribbon。除这五种，后备图一律走 3.1 条。
4. Glance 是默认降级方案，不是并列首选。 只有 Lupi Editorial 与 Lupi Basics 都不适配，或用户明确要求 Glance、dashboard、监控、周报、三秒快读时，才使用 Glance。降级前必须写明 Lupi / Basics 不适配的具体原因。
5. 库外新造是最后手段。 Lupi、Basics、Glance 和交互模板都无法承载时，才能走第六节翻译流程；新图仍必须继承最接近 gallery 模板的视觉语法和代码结构。

一、工作流程（每次请求都走这六步）

1. 判数据形状。 别问用户要什么图，看他的数据长什么样：几个类目的比较？带时间的序列？占比？带正负？多对一归属？网络？逐条记录的分布？形状是选图的主键。
2. 先审计主力，再考虑后备。 按数据形状先扫描主力 L1–L15 与 F1–F13 的候选，至少比较 3 个；不足 3 个就列出全部。比较语义契合、单位诚实、标签容纳、阅读速度、叙事张力和本批次是否重复。主力全部不适配时，才扫描后备 L16–L20 / F14–F17，并写明主力哪几张为什么不行（第零节 3.1）。数据形状命中第零节 3.2 那五种时，直接用对应后备图。
3. 必要时才检查 Glance。 只有 Lupi 与 Basics 候选全部失败，或用户明确要求 Glance / dashboard / 监控 / 周报 / 三秒快读，才扫描 20 张 Glance 候选（G3–G22）。选择 Glance 时记录为什么 Lupi 与 Basics 无法承载，不得只写“Glance 更直观”。用户明确要求地图时跳到 Maps（M1–M2），不把地图混入普通候选。
4. 锁定真实模板，再组织整页。 每张图必须记录体系、图型编号、gallery 文件和卡内标题，并以该卡的真实结构与渲染代码为骨架。禁止先想好“这一页要讲六件事”，再临时发明图型；整页叙事只能在模板锁定之后组织。
5. 按图数规则组成批次。 一张图只承担一个独立结论；去掉重复结论后，再按第 1.2 节的默认区间决定数量。模板需要全局分配：不重复、不堆同一种轮廓、不为了凑数硬加图。
6. 按模板渲染并自检（第零、二、三、八节）。逐项核对成品是否仍能对应到所选 gallery 实现；不能因为改数据而换掉模板的核心几何、编码或动效。按第六点五节为整份交付选择 Mono 或一套彩色预设；库外图型走翻译流程（第六节）。

1.1 报告模式工作流

1. 读取 report-catalog.md，至少比较 3 个报告候选并记录淘汰理由。按内容结构、信息密度、版心和阅读速度选模板，不把模板名称当成行业限制；例如“旅行手记”也可以承载运动或个人生活数据，“月度运营”也可以承载财报或业务数据报告。
2. 锁定一个语言版本和一个报告模板文件；不得拼接两个报告模板的版式。
3. 先提炼整页的主结论、证据结论、上下文说明和来源，再把它们分配到模板已有的标题、导语、KPI、图表、旁注和结尾槽位。
4. 每个图表槽位单独按 catalog.md 选型，优先复用 Lupi / Basics 的真实实现；报告模板的布局不能成为绕过图表数据契约的理由。
5. 复制对应报告模板的整份 HTML 作为起点，只替换数据、文案、来源、图例、语言和必要模块。不得保留演示数据、演示来源、Moxt 链接或模板原始结论。
6. 报告页的色彩系统锁定为模板当前色系；如用户明确要求改色，整页统一替换为 Mono、单一内置预设或完整 custom 色板，不得局部混搭。
7. 报告模式的交付前额外检查：版心尺寸未漂移、章节顺序仍成立、页内图表数量有证据支撑、定尺模板没有溢出、中文字体和英文 fallback 可读。

1.2 演示模式工作流

1. 先确认主题、听众、语言、用途和材料范围；明确交付为 HTML 或 PDF 格式的 PPT，若用户要求 .pptx 先确认替代格式。
2. 写逐页提纲：每页一个主要结论，记录来源、数据口径、图型编号、版式编号和待检查项。
3. 在 catalog.md 先审计 Lupi Editorial 与 Lupi Basics，再把已锁定的真实图型放进 presentation-catalog.md 的 P04–P08 页面槽位。
4. 按已锁定的全局色系选模板：Mono 复制 templates/presentations/presentation.zh.html 或 .en.html；彩色预设复制对应的 complete-porcelain / complete-palm / complete-wire（各 19 页、中英双版、带入场动效），替换所有示例内容；不拼接报告模板。
5. 验收导航、字体回退、动画生命周期、无障碍描述、打印分页和 1280×720 显示。

演示模式规则详见 references/presentation.md。

1.3 图数规则

图的数量由独立结论数决定，不由“有多少数据列”决定，也不固定要求 5 张或 6 张：

• 默认单页上限为 6 张；超过 6 张就拆成多页或按章节交付。
• 候选方案、Glance/Lupi 对照稿不计入最终图数；它们是选择过程，不是成品批次。
• 一页多图至少保留一个总览结论，其余图必须提供新的比较维度、关系、时间变化或细节证据。
• 如果两个图表达同一个结论，只保留阅读场合更合适、数据契约更诚实的一张。

二、Mono 语法 · 硬规则（违反即返工）

默认引用 mono-tokens.js（开源分发时把内容内联进 HTML）。与 token 冲突的取值一律以 token 为准。走彩色时只替换颜色 token，字体、圆角、布局和动画仍以 mono-tokens.js 为准。

颜色

• 默认只有纸灰 #F0EFEB 和炭黑 #1C1C1A 两极，中间 7 级灰阶 ladder。彩色例外按第六点五节从预设起步。
• 明度即数据：最重要 = 最黑（暗卡上反转为最亮）。多系列按重要性沿 ladder 分配，不按顺序随便拿。
• 一律实心：不透明材质、不发光、不渐变滤镜、无阴影。质感全靠明度对比和形状。唯一例外：叠加型图（Radial Patchwork）里透明度本身编码密度——那是数据，不是装饰。
• 暗卡（.card.dark）只给两种图：必须暗底衬托的形（花瓣、发光感丝线/网络）。默认浅卡；每屏（4 卡）最多 1 张暗卡。

排版

• Inter 全家。标题 700 / 图内数值 800 / 轴标签 600。卡片结构固定四件套：结论式标题（h2）+ 副标题（图例和时间范围写在这里，用 · 分隔）+ 图 + 来源行（全大写、加字距）。
• 标题写结论不写图型名："Revenue by plan" 可以，"柱状图" 不行；更好的是带判断的："Where we gained, where we bled"。
• SVG 最小字号：半宽卡 6.5px、通栏 5.5px。装不下的信息改 hover 出，不许缩小字号硬塞。

形状

• 卡片圆角 24px，无边框无阴影，靠留白分卡。柱端胶囊圆角（竖柱圆上端、横柱圆外端）。
• 柱状图不断轴。 柱的契约是长度∝数值，断轴毁契约。极端值场景的正确做法：①让极端值冲天（最诚实）②主图+放大镜小图 ③撕柱不撕轴（明说画不下）。
• 花瓣皮（粗黑缝+圆角扇瓣）只适用等分或近似等分的径向图。宽窄悬殊的扇区会相互遮蔽，降低可读性。

动画

• 入场动画默认开，quarticOut 快进快停，不弹跳（波浪入场可用 elasticOut）。点阵 stagger 8–15ms/个，条形 80–130ms/根。
• 统一 reveal 机制：滚入视野才播 + 点击重播（用 token 里的 obsReveal，带 timer 清理）。
• 必须带 prefers-reduced-motion 降级（token 的 CSS 已含）。
• 动画不可优于结构：一个效果如果需要发明新布局才能安放，不配存在（effectScatter 教训）。

数据

• 演示数据用 token 的 rnd(i,k) 确定性伪随机，禁用 Math.random()——刷新必须长一样。
• 数值和视觉严格成正比。面积编码用 Math.sqrt(v) 换算半径，不许拿数值直接当半径。

三、两个风格系的分工

同一份 mono 色板下有两种世界观，选哪个看场合和读者愿意花几秒：

默认策略：Lupi Editorial → Lupi Basics → Glance。 没有明确场合时，禁止默认 Glance。放年报、公众号长文、海报、开源 README、作品集时先选 Lupi Editorial；数据较少或适合熟悉图型时再选 Lupi Basics。只有前两组都没有合适模板，或用户明确要 dashboard、监控、周报、三秒快读时，才进入 Glance 候选池。

全量候选审计不是“把所有图都做一遍”。 先用数据形状筛出能编码同一本体的候选，再把候选分成：

• 语义合适：每个点、线、面、串珠背后都有真实单位或明确聚合口径。
• 视觉合适：标签装得下，密度足够，读者能按预期时间读完。
• 叙事合适：图形本身能承载这批数据要讲的判断，而不只是把数字摆出来。

最终选择是三项的交集，不是“哪个模板文件最容易复制”。默认审计先在 Lupi Editorial 与 Lupi Basics 内完成；只有两组都失败才扩展到 Glance。若同一批要做多张图，再对候选做一次全局分配：模板不重复，形状轮换，最多一张暗卡，避免整页变成六张相似的环或横条。

数据少（只有几个百分比）不等于只能 Glance。 Lupi 化的正道是单位分解：把聚合数摊回可数单位（1 点 = 1 人 / 1 百分点），密度来自单位而不是记录数。单位含义写进副标题，只摊诚实单位（占比加总 100 → 100 个点），不编造不存在的个体记录。取整时如果加总不足 100（如 49.0+27.4+13.9+5.0+3.2 → 98），在底注写明「另外 N 人被四舍五入吃掉了」，不凑假单位。

小数据走 Lupi 的路径优先级（经多轮案例验证）：

1. 先全量扫描，再选代码骨架——基础型组 F1–F13（templates/basics-gallery.html）是稀疏数据的 Lupi 词汇：柱/折线/面积/环形/横条/分组/堆叠/散点/瀑布/热力/进度/哑铃/矩形树图；编辑型 L1–L15 则提供逐记录、单位分解、关系与旁注语法。这两组是主力，小数据几乎总能在这里落地。F14–F17 与 L16–L20 是后备，按第零节 3.1 / 3.2 判断。不要因为 basics-gallery.html 里有现成代码就直接选 F 图。
2. 用最接近本体的模板起步——多选题百分比优先比较 L15、F5、L2；100% 构成优先比较 L14、L5、F4、G4；漏斗优先比较 L13、F1/F5 的降级表达。选择依据是数据编码方式，不是文件顺序。
3. 库里真没有对应形状才新造，且新造必须从 gallery 现有语法延伸（发丝 tick、确定性 rnd 抖动、paint-order 光晕、全大写注记），不引入库外参照——“Lupi 风”指 gallery 那批图的视觉语法，不是 Giorgia Lupi 本人的手绘风。
4. 新造的小数据图要配满环境结构层：gallery 好看有一半靠无数据的家具（账本纸横线、虚线导轨、rim 刻度、每 10 单位的立柱网格、旁注引线）。数据层诚实稀疏，密度预算花在家具上。只画数据 + 一根底线的小数据图必然寒酸。

同一批产出（一页多图）里模板不重复。 19 张 Lupi 系够轮换；同一数据能被多个模板承接时，选这一批里还没用过的。

四、图型决策树（数据形状 → 候选）

编号对应 catalog.md。这些只是候选召回表，箭头和书写顺序不代表优先级。实际选择必须遵守：先检查全部 Lupi Editorial 与 Lupi Basics 候选，确认无合适模板后，才允许采用 Glance 候选。

• 少类目比较（≤8） → G3 Chunky Bars ⇄ 竖排 F1 Rung Bars / 横排 F5 Tick Rows ⇄ L2 Dot Cascade（⚠️ cascade 类目名竖排，仅当名称 ≤4 字或短缩写时可用；中文长类目换 F5/L5/L12）
• 多选题百分比（各项独立 0–100，加总可超 100） → G3 Chunky Bars ⇄ L15 Ballot Tally
• 多类目分布（30–60 根） → G12 Stagger Wave
• 带正负的分类数值 → G10 Diverging Bar
• 占比 / 100% 构成 → G4 Dot Waffle ⇄ L14 Hundred Field ⇄ F4 Tick Donut（饼图的默认替代）；占比×强度双编码 → G13 Big Slice；按类堆叠 → F7 Stacked Rungs
• 两时点对比（前后 / 今昔） → 类目级（≤6 类）→ F12 Dumbbell Queue（横向，串珠 = 真单位）⇄ F6 Paired Rungs（并肩双梯）；只有 2–4 条序列要画趋势线 → Glance chunky slope（粗线、大数、结论进标题）。交叉过多的斜率图会显著降低可读性，不要为了 Lupi 化增加装饰结构。
• 日序列（≤30 天，逐日读数） → F2 Hairline Line ⇄（90 天级、要肌理）L3 Barcode Lollipop；30–60 天看形态 → F3 Hairline Area
• 累计增长 → G18 Draw-in + Counter
• 双序列因果（投入 vs 产出） → G8 Rainfall
• 实时数据 → G17 Dynamic Stream
• 排名随时间变 → 需要动态演示用 G16 Bar Race；静态见下方「排名随离散时间变化」一条
• 星期×小时×量 → G14 Single Axis ⇄ F10 Dot Heat
• 瀑布 / 增减分解（≤6 级） → F9 Rung Waterfall
• 单值进度（0–100%） → F11 Tick Gauge ⇄ G18 Draw-in + Counter
• 二维散点（≤20 点） → F8 Plumb Scatter；几百点分布 → G15 Jitter Strip
• 单变量分箱频数 → 先看 F1 Rung Bars 能不能直接承接（bin 当类目）；确实需要分箱语义时用 F14 Rung Histogram。bin 边界必须有业务含义；不要为了好看任意切箱。
• 分组连续分布 → 五数概括 + 异常值直接用 F15 Tick Box（主力无对应编码）。只看密度轮廓时先比较 G15 Jitter Strip；G19 Violin 与 L19 Ridgeline 属后备，要写明为什么 Jitter / F15 不够。
• 逐条记录分布 → G15 Jitter Strip。
• 分类×分类+量（矩阵） → 主力优先：轻量 L4 Arc Matrix，跨年份带旁注 L9 Bubble Almanac。两者都撑不住（格子多到气泡互相挤、必须靠明度读）才用 L16 Matrix Heat；要快读且每格直接标数才用 G20。
• 全年日期×数量 → 整年 52 周 × 7 天直接用 L17 Calendar Heat（主力无对应编码，L3 只到 90 天级）。星期×小时的重复周期仍用 F10 / G14。
• 多对一归属 → 造型强 L5 Radial Convergence ⇄ 带名单 L12 Type Colonnade
• 漏斗 / 分阶段递减 → L13 Hourglass Stream
• 层级结构 → G7 Tree LR
• 层级 + 份额 / 权重（两层、值为正数） → F13 Nested Treemap；只看谁属于谁、不比较大小 → G7 Tree LR
• 多系列构成随连续时间变化 → 静态类目构成先用 F7 Stacked Rungs；要同时看总量与构成的连续时间流，直接用 F16 Stream Ribbon（主力无对应编码）。只有单序列总量用 F3 / G17。
• 同一实体跨 3–6 个连续维度 → 直接用 L20 Parallel Coordinates（主力无对应编码）。维度超过 6 个先筛选或拆图。
• OHLC 行情 → 直接用 F17 Candlestick（主力无对应编码）。只有 min–max 区间而无开收盘值时用 G1。
• 两端聚合流量 → 先看 L5 Radial Convergence / L12 Type Colonnade 能否承接归属关系；确实要看流量宽度才用 G22 Aggregate Sankey。要查每条真实路径用 B3 Threads。
• 排名随离散时间变化（静态） → 先比较 L11 Trend Lineage / L2 Dot Cascade；确实要逐期格子对位才用 G21 Rank Strip。
• 事件序列生命史 → L11 Trend Lineage
• 多实体出生时间+现状 → L1 Launch Fan
• 逐事件时刻分布（一天内） → L10 Radial Patchwork
• 双极量表（两端都合法） → L7 Brand Spectrum。注意和单极打分（雷达）区分：单极用 ECharts 原生雷达
• 网络 → ≤15 节点 G6/G11 小图；>15 或要查数 → B1 环形 / B2 力导向；多段路径流向 → B3 Threads
• 多组×网格（要装饰感） → L8 Dotty Matrix；要读数 → 摊平用 G14
• 同一实体集多维度轮播（演示） → G9 Scatter Morph

地图显式触发规则

• 只有用户明确说“地图”“地域分布”“按国家/州着色”或点名 choropleth，才检查 Maps。数据表里仅出现地区字段不得自动触发。
• 美国州级区域数值用 M1 US Choropleth；世界国家级区域数值用 M2 World Choropleth。地图面积是地理面积，不代表数值，副标题必须说明 shade = value。
• M1/M2 依赖 ECharts 与在线 GeoJSON；交付时说明需要联网，或在用户明确要求离线时再内联合法来源的地图数据。
• 中国地图不从 M1/M2 改名套用。只有拿到符合当前地图合规要求的完整数据源和审图信息后才制作。

F13 Nested Treemap 硬规则

• 只接收层级数据和非负权重；父级值由子级求和，禁止父子总数互相矛盾。面积直接交给 ECharts treemap 布局，不再对值开方。
• 默认展示两层（父组 + 叶子）。超过两层且读者需要逐层查询时才开启 drill-down；普通静态交付保持 nodeClick:false，避免误触改变视图。
• Mono 的灰度只表示层级，不给每个叶子随机分配深浅；父组靠标题带、组间留白和边界区分。去掉颜色后仍能看清分组。
• porcelain 用单色相明度表示有序的父组份额或层级；palm 用色相对应不超过 4 个顶层类目；wire 保持灰阶，只允许一个明确主角使用 HERO。
• 面积已经表达数值时，颜色不得再次无说明地重复同一数值。副标题必须写清 area = ...，使用彩色时再写清 color = ...。
• 叶子超过 30 个、标签大面积省略，或最小矩形小到无法形成稳定热区时，先合并长尾为 Other、拆成多张，或改用 G7 / L12 / B 系关系图。
• Tooltip 至少显示完整层级路径、原始值和总量占比；卡内标签放不下就隐藏，不缩到低于最小字号。

五、交互三问（决定静态还是可交互）

按顺序问：

1. 这根线/点背后有没有一条真实记录？ 没有（纯肌理装饰，如 Cluster Field 的辐条、Hourglass 的淌线）→ 禁止加交互，给没有内容的元素加 hover 是欺骗。
2. 有记录 → 不点能不能读出来？ 元素 <50 且两端有标注（如 Colonnade）→ 静态够用，hover 是锦上添花。
3. 元素 >50 根或多段路径（如 Threads）→ 必须 hover/pin，否则只是氛围图。交互实现参考 templates/big-threads.html：可见线下垫 9px 透明孪生线当热区，hover 单线亮整条路径、hover 标签拉整束、点击钉住。

六、库外图型 · 翻译流程

用户要的图不在 63 张里（或发来一张参考图）时，不是做不了，是现场造句。流程四步，第一步不许跳：

1. 先回答本体：这个图型编码了什么？每个视觉通道（位置/长度/角度/面积/明度/密度）分别对应哪个数据维度？答不出来就问用户拿数据结构。抄形不抄魂 = 白做（pictorial bar 曾把"符号计数"错做成"树长高"，返工）。
2. 找最近的亲戚：在 catalog 里找数据形状最像的一张当起点，继承它的布局骨架和动画节奏。
3. 用 token 造句：色板、字体、圆角、动画参数全部从 mono-tokens.js 拿，不许发明新颜色新字号。产出必须和库里的图"一眼一家人"。走彩色时颜色改从 color-presets.js 的单一预设中取，其他 token 仍以 mono-tokens.js 为准。
4. 过第二节硬规则和第八节自检，和库内图同一标准。

参考图翻译的附加规则：识别参考图属于哪个流派（Glance or 编辑部），编辑部风格的密度、旁注、手绘感（blob）是本体的一部分，别做收敛了——almanac 曾因"不敢挤"返工。

六点五、彩色（按场景自动选择，单一色系）

Mono 是保底方案，不是未触发彩色时的强制答案。 用户没有提颜色时也要根据数据语义、类目数量、阅读场景和内容气质评估是否适合彩色；适配关系不明确，或颜色没有带来真实信息价值时，回到 Mono。

彩色初稿从三套预设中选择一套，色值在 color-presets.js，样张在 templates/color/。预设用于快速得到稳定、统一的第一版，不是锁死的色板。用户要求"这个蓝再深一点"时，在当前色系内继续调整；用户明确给出品牌色、色值或完整色板时，按下方规则建立 custom 色板。调整后必须重新检查对比度、视觉主次和数据语义。

同一份 HTML 或同一组交付必须先锁定一个全局色彩系统：Mono、porcelain、palm、wire 或一套 custom。 所有图共享该选择。若其中某张图不支持已选系统，不得单独换色；改选一套全局兼容的系统，或整组退回 Mono。

结构正本永远是原版 gallery。 查渲染代码去 templates/ 根目录的 gallery，templates/color/ 只查配色。先按第零节选定结构，再决定是否换肤。

用不用彩色

按以下优先级判断：

1. 用户明确指定。 用户要求某种颜色、气质或预设时优先服从，但仍要通过容量、对比度和数据语义检查。
2. Agent 自动选择。 即使用户没提颜色，只要数据形状和场景与某套预设有清楚的对应关系，就可以自动使用：有序单序列适合 porcelain；少量无序类目适合 palm；需要一个受控视线落点适合 wire。
3. 关系不明确就用 Mono。 类目过多、高密度记录、颜色没有稳定含义，或整组图无法共享同一预设时，使用 Mono。

彩色不是升级版，而是 Agent 可以主动选择的语义工具。交付时用一句话说明所选色系及其承担的数据含义。

自定义色板（只在用户明确要求时启用）

Agent 不得自行发明第五套默认审美。只有用户给出明确色值、品牌色、品牌规范或"沿用这张参考图的配色"时，才建立 custom 色板；仅说"好看一点"仍从三套内置预设选择。

1. 先确定颜色逻辑，再分配色值。 有序数据用单色相明度梯；无序类目用分类色；需要聚焦时用中性色 + 一个强调色。禁止先拿到五个颜色，再平均撒到所有元素上。
2. 建立完整角色，不直接散落 hex。 custom 至少定义 BG、TXT、MUT、GRID、DATA；需要重点时再定义 HERO，有序数据定义 RAMP，分类数据定义 CAT。成品内联一个 CUSTOM 对象，所有图从角色取色。
3. 按输入数量解释。 1 个颜色生成同色相明度梯；2 个颜色默认分为主数据色 + 强调色，不自动当作两个平等类目；3–6 个颜色只有在数据确有对应类目时才进入 CAT。超过 6 个先合并类目、改用位置/标签，或退回 Mono。
4. 允许派生明暗，不允许偷渡新色相。 浅色由用户色与 BG 混合，深色由用户色与 TXT 混合；不得借用 porcelain、palm、wire 的色值补齐 custom。
5. 对比度是硬门。 正文和小标签相对背景至少 4.5:1，大字至少 3:1；关键边界、数据形状和交互状态相对相邻颜色至少 3:1。不达标时优先调整明度，不擅自改变用户指定的主色相。
6. 颜色不能成为唯一线索。 分类仍带标签，序数仍保留位置/长度/面积，强调仍有标题或旁注说明。色觉异常用户去掉颜色后，图的结构仍应读得懂。
7. 一次只锁定这一套 custom。 custom 不与任何内置预设混用；多图交付共享同一个 CUSTOM。除非用户明确要求把品牌色固化为项目级预设，否则 custom 只内联在当前成品，不回写 color-presets.js。

用户后续要求"再深一点"、"背景暖一点"或替换某个色值时，修改对应角色并重新检查整套对比度和语义映射，不只改被点名的那一个元素。

选哪套：先看数据形状，再看气质

彩色硬规则

• 同一交付只用一种色彩系统。 一张图、同一份 HTML 或同一组姊妹图只能使用 Mono、color-presets.js 的一套预设，或一套用户明确要求的 custom。禁止预设彼此混用，也禁止 custom 借用内置预设补色。
• 线宽 ×1.8、透明度地板 .85。 灰阶下的发丝线换成淡色后容易消失；dot heat 除外。
• 每张图至少 3 个色阶或色位。 只用 1–2 个颜色时退回灰阶。
• 颜色必须连接真实维度。 序数梯接数值，分段色接月份或区段，分类色接类目；底注写清颜色在编码什么。
• 强调色只给一个主角。 第二个主角会消解强调。
• 暗卡数据色必须亮于卡底。 暗底大图使用 preset 的 DARK 块。big-circular / big-force / big-threads 只有 porcelain 和 palm；wire 使用原版 Mono 大图。
• palm 中 DATA 和 HERO 必须不同。 琥珀和橄榄明度接近，不要把两者当作平等类目色。

七、什么时候说不

敢拒绝比什么都接更可信。以下情况不做，并给替代：

• 断轴柱状图 → 拒绝，给三个诚实方案（冲天 / 放大镜 / 撕柱不撕轴）。
• 发光 / 玻璃拟态 / 3D → 拒绝，保持现有视觉语法。自定义色值按 custom 规则映射；跨色彩系统混用拒绝。
• 拿多色相画单序列 → 拒绝。给 porcelain、wire 或退回 Mono。
• 类目 >6 还要彩色 → 拒绝，退回 Mono 灰阶。
• 用户未明确要求地图 → 不因数据里有地区字段自动使用 M1/M2；继续按普通比较、排名或构成选图。
• 地图范围超出 M1/M2（中国省级、城市点位、轨迹图等）→ 不套用错误边界；确认数据源、投影、合规和交互要求后再现场制作。
• 给纯装饰元素加交互（第五节第 1 问）→ 拒绝并解释。
• 雷达图重构 → 不重构，用 ECharts 原生雷达 + Mono token 换肤（实测过：展示场景里"认得出的图型"有价值）。
• 数据太少撑不起所选图型（如 3 个节点要力导向）→ 降级到更简单的图并说明。

八、交付前自检清单

1. 数值和视觉成正比？（面积用了 sqrt？柱没断轴？）
2. 色板是否受控？整份 HTML 或同一组交付是否只使用 Mono、单一内置预设或单一 custom？Mono 中出现任何非 ladder 颜色即返工；内置彩色出现另一套预设颜色即返工；custom 是否只从 CUSTOM 角色取色并通过对比度检查？
3. 标签会不会重叠？（barcode 教训：邻近峰值标签要强制最小间距）
4. 最小字号踩线没有？（半宽 6.5 / 通栏 5.5）
5. 演示数据是 rnd 确定性的？刷新两次长得一样？
6. reveal 正常？（滚入播、点击重播、timer 不叠加、reduced-motion 降级在）
7. node --check 过语法（把 <script> 内容抽出来查）。
8. 卡片四件套齐全？标题是结论不是图型名？
9. 副标题把图例说清了？（读者不看代码只看这一行）
10. 是否完成全量候选审计？至少写下 3 个候选和淘汰理由，而不是只记录“采用了哪个模板”。
11. 如果是一页多图，模板是否全局分配过？有没有相似轮廓重复、暗卡过量、所有图都变成同一种径向图？
12. 每张图是否记录了图型编号、gallery 文件和卡内标题？成品的核心结构是否确实来自该模板，而不是重新发明？
13. 如果使用 Glance，是否写明 Lupi Editorial 与 Lupi Basics 为什么都不适配？如果没有，返工回到 Lupi / Basics。
14. 最后一问：这张图放回所选 gallery 的对应卡片旁边，是不是同一个模板家族，而不只是“风格有点像”？

九、单文件模板骨架

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width,initial-scale=1" />
<title>Mono — {图名}</title>
<!-- 需要 ECharts 时： -->
<script src="https://cdn.jsdelivr.net/npm/echarts@6/dist/echarts.min.js"></script>
<!-- 需要 Chart.js 时（G1 / G3）： -->
<!-- <script src="https://cdn.jsdelivr.net/npm/chart.js@4/dist/chart.umd.min.js"></script> -->
<link rel="preconnect" href="https://fonts.googleapis.com">
<link href="{MONO.FONT.link}" rel="stylesheet">
<style>/* 内联 MONO.CARD_CSS */</style>
</head>
<body>
<div class="grid2">
  <div class="card"><!-- 或 card dark / card wide -->
    <h2>{结论式标题}</h2>
    <div class="sub">{说明} · {图例} · {时间范围}</div>
    <!-- 图容器按引擎三选一： -->
    <div class="ch" id="ch"></div><!-- ECharts -->
    <!-- 手写 SVG： <svg id="ch" viewBox="0 0 400 320"></svg> -->
    <!-- Chart.js（G1/G3）： <div class="wrap"><canvas id="ch"></canvas></div>，配 .wrap{position:relative;height:320px} -->
    <!-- ⚠️ Chart.js 必须挂 <canvas>，套 <div class="ch"> 会报 can't acquire context -->
    <div class="src">{图型名} · {系列} · {数据来源}</div>
  </div>
</div>
<script>
// 内联 mono-tokens.js 全文
// ── 数据（用户只需要改这里）──
const DATA = [ /* ... */ ];
// ── 渲染 ──
MONO.obsReveal('ch', el => { /* ... */ });
</script>
</body>
</html>

十、报告与演示模式骨架

report-catalog.md                # 先按场景选 R01–R12
presentation-catalog.md            # 演示模式 P01–P10
references/presentation.md          # 演示模式完整规则
templates/presentations/index.html # 演示模板索引
templates/presentations/presentation.zh.html # 中文 16:9 演示正本（Mono）
templates/presentations/presentation.en.html # English 16:9 deck source (Mono)
templates/presentations/complete-{porcelain,palm,wire}{,-zh}.html # 彩色完整版，19 页中英双版
templates/reports/report-NN.zh.html  # 中文整页正本
templates/reports/report-NN.en.html  # English full-page source
templates/reports/index.html         # 本地可打开的模板索引
docs/assets/reports/report-NN.png    # 中文版静态预览

报告交付仍然是单文件 HTML；templates/reports/ 中的文件是可复制的起始骨架，不是需要逐字照抄的内容样例。模板内的演示数据只用于展示结构，生成最终报告时必须全部替换。

Lieflat Charts

中文 | English

Lieflat Charts 是一套遵循 Agent Skills 格式的数据可视化、PPT 演示与整页报告生成 skill，可供 moxt、Claude Code、Codex 及其他兼容 SKILL.md 的 AI agent 使用。本 skill 在 moxt.ai 制作，同时提供 PPT 模式和报告模式，但默认产出图表；用户明确要求一套 PPT、幻灯片或可翻页汇报时，才进入 PPT 模式，生成 HTML 或 PDF 格式的 PPT；用户明确要求报告、年报、月报、白皮书、海报或 brief 时，才生成整页 HTML 报告。

演示模式在用户明确要求做图表 PPT 后触发：Agent 选择合适的图表类型与色彩（Mono 或三套彩色预设），自动生成带入场动效、支持左右翻页的 HTML 格式 PPT；数据与图型仍根据用户材料确定。

它以统一的字体、留白、线条和动效建立自己的视觉语法，包括以下几种视觉风格：

• Lupi（编辑叙事型）：用细线、点阵、逐条记录和大量留白展开数据，强调真实单位、细节和旁注，适合论文、长文、年报与需要慢慢阅读的数据故事。
• Glance（快速判断型）：用粗柱、大数字、色块和清晰排序提前聚合信息，让读者几秒内看懂高低、变化和异常，适合周报、汇报与 dashboard。
• Basics（基础编辑型）：保留柱状图、折线图、环形图等熟悉轮廓，再用可数刻度、发丝线和编辑排版增加质感，适合结构简单或数据量较少的内容。

此外还提供网络、路径和多段流向等独立交互大图。每张图都尽量保留数据的真实单位，同时让标题、旁注、来源和页面结构参与表达。

Mono 黑白灰是稳定的保底方案，同时也有彩色模式，目前支持青瓷蓝、椰林绿和编辑部红三种彩色色系，方便适配各种场景的数据可视化。Agent 会根据数据结构和使用场景，在 Mono、青瓷蓝、椰林绿或编辑部红之间自动选择；适配关系不明确时使用 Mono。用户明确提供品牌色或色值时，也可以建立一套 custom 色板。同一份 HTML 或同一组图只使用一种色彩系统，生成后仍可继续调色，同时保持图型结构、比例、对比度和数据契约。

Preview

以下是几类模板的实际预览。

Lupi Editorial

细读、逐记录、编辑感。精选 19 张编辑叙事型模板中的代表图型。

Glance

快读、聚合、结论先行。精选 20 张快速判断型模板中的代表图型。

动态预览：

更多动态预览：

Lupi Basics

常见图型与可数单位的结合。17 张模板覆盖柱、线、面积、环形、散点、矩形树图、直方图、箱线图、K 线等基础数据形状。

Interactive

用于网络、路径与高密度关系数据。

动态预览：

打开 Force Graph 模板体验拖拽与缩放

增加了彩色模式

图表可以根据数据结构和使用场景自动选择 Mono 或一套彩色预设，不要求用户先说“要彩色”。有序单序列可使用青瓷蓝，少量无序类目可使用椰林绿，需要一个受控视线落点时可使用编辑部红；适配关系不明确时回到 Mono。用户明确给出品牌色或色值时，可以建立一套 custom 色板。同一份 HTML 或同一组图只使用一种色彩系统；调整时需重新检查对比度、视觉主次和颜色所表达的数据含义。

Porcelain · 青瓷蓝

单色相明度阶，适合有序数据和单序列。

Palm · 椰林绿

低饱和绿黄色系，用色相区分少量无序类目。

Wire · 编辑部红

黑灰阶加一个荧光橙视线落点。

最新更新

增加了演示模式

16:9 横向单文件 HTML 演示，支持左右方向键翻页、总览视图和逐页打印。用户明确要求做图表 PPT 后，Agent 会根据数据形状从 catalog.md 选择合适的图表类型，并按数据语义在 Mono 和三套彩色预设（青瓷蓝 porcelain、椰林绿 palm、编辑部红 wire）中锁定一套全局色系，自动生成带有入场动效（弹出、淡入、描线，尊重 prefers-reduced-motion）的 HTML 格式 PPT。

每套色系提供中文、英文双版完整模板（19 页：封面、目录、章节页、图表页、大数字结论、阅读说明等）。模板负责画布、字体、留白、翻页和打印；下面的截图只展示排版参考，示例数据不会自动带入真实成品。

模板入口：templates/presentations/index.html · presentation-catalog.md

完整版彩色模板（每色系中英双版，19 页）：

• complete-porcelain.html / complete-porcelain-zh.html — 青瓷蓝
• complete-palm.html / complete-palm-zh.html — 椰林绿
• complete-wire.html / complete-wire-zh.html — 编辑部红

另有 Mono 基础版：presentation.zh.html / presentation.en.html。

增加了报告模式

现在可以在单张图表之外，直接从 12 套整页报告模板生成 HTML 报告。每套模板都提供中文版和英文版，覆盖调研报告、研究简报、业务数据报告、财报与金融经济分析、产品记录、dashboard、海报，以及运动、旅行和年度生活数据记录等从工作到个人的需求。模板名称代表版式性格，不是使用场景的限制；同一套模板可以根据数据结构迁移到不同类型的报告。

报告模式的图表槽位仍按 catalog.md 选择真实图型；报告模板索引见 report-catalog.md 和 templates/reports/index.html。

零门槛快速使用

推荐在 Moxt 中使用

Lieflat Charts 在 Moxt 中完成设计、测试和持续迭代。它的设计规则、模板结构与文件工作流，都是围绕 Moxt 的 Agent 协作方式反复打磨的。

因此，在 Moxt 中使用时，Agent 能更顺畅地读取完整的设计规范、理解 Lieflat Charts 的视觉语言、调用对应模板，并在同一个工作区中持续预览和修改结果，更稳定地执行这套设计。

Lieflat Charts 仍然可以安装到其他支持 Agent Skills 的工具中；Moxt 是它的原生制作环境，也是目前更完整、步骤更短的推荐使用方式。

安装到其他 Agent

一条命令安装：

npx skills add https://github.com/larashero3-dotcom/lieflat-charts --skill lieflat-charts

也可以直接把这段话发给有 shell 权限的 AI Agent：

帮我安装 lieflat-charts。请把 https://github.com/larashero3-dotcom/lieflat-charts
克隆到 ~/.claude/skills/lieflat-charts，安装完成后检查 SKILL.md、templates/、
catalog.md 和 mono-tokens.js 是否存在。

使用 Codex 时，将安装路径换成 ~/.codex/skills/lieflat-charts。

已经安装过的话，用这段话更新：

帮我更新 lieflat-charts。请进入 ~/.claude/skills/lieflat-charts 执行 git pull，
然后告诉我当前最新 commit。

安装后直接对 Agent 说：

把这份调研数据做成适合公众号长文的 5 张中文版图表。
默认先比较 Lupi Editorial 和 Lupi Basics 候选；两组都不适配时，再使用 Glance。

也可以试这些请求：

帮我用 lieflat charts 给这些数据做个彩色风格的图表。

读这篇论文，找出最值得讲的几个数据结论，做成一页完整的 HTML 图表。

这是一份周报数据，要求 10 秒内看懂排名、变化和异常。

把这个 CSV 做成一张适合放进汇报里的 Glance 图表。

用 Lupi 风格重新设计这组数据，保留每条真实记录，并加入必要的旁注。

用青瓷蓝预设重做这张图，用明度深浅表示数值大小，不改变原图的结构。

图数由独立结论决定：单个问题通常 1 张，两个到三个结论 2–3 张，完整文章或论文 4–6 张，单页默认最多 6 张。用户明确指定数量时会遵守，但不会为了凑数重复表达同一个结论。

关注躺在废墟里

欢迎在小红书、抖音、Bilibili、公众号、视频号和 X 关注我：躺在废墟里。

Templates

Lupi Editorial

把一个点、一根线或一条旁注尽量对应到真实数据单位。它不急着把数据聚合成一个结论，而是把原材料摊开，让读者看到结构、分布和例外。视觉上使用发丝线、留白、账本式导轨、旁注和低对比灰阶，阅读时间通常在 30 秒以上。

Lupi Basics

保留常见图表的剪影，但把它们放进 Lupi 的编辑语法里：一格可以是一个百分点，一根 tick 可以是一个人，一条 hairline 可以是一天，Treema