---

name: lov-mobile-infographic description: > 把结论或材料整理成手机竖屏阅读的证据型信息图：输出永远是一张 1080 宽的 long 自适应卡片，内容多就把图加长、不拆卡；只有明确要求多张才做系列。交付可编辑 HTML 与 2× PNG。Use when the user says “把这个内容做成手机能读的信息图”“出一张竖版信息图”，or asks to "turn this into a mobile infographic". license: MIT compatibility: > Portable Agent Skills format. Python 3.8+; PNG rendering requires Playwright for Python with Chromium or Google Chrome. Generated HTML is portable and embeds the resolved brand logo as a data URL. depends_on:

• lov-branding-consistency metadata: author: skill-publisher version: "0.18.0" card_standard: lovstudio/skill-card/v1 content_class: microcopy tags:
  • mobile
  • infographic
  • card-series
  • readability
  • html
  • png

---

手机信息图 · Mobile Infographic

把一段已经有结论的内容，重排成手机上真的读得下去的证据型信息卡：单列阅读路径、 明确的字号下限、可核查的口径与来源，以及能从一张扩展到一组的系列结构。

这不是把咨询 Exhibit 缩小，也不是把整卡交给生图模型。文字、证据和排版全部由 DOM 生成， PNG 由浏览器精确栅格化，交付时同时给出可编辑 card.html 与 2× PNG。

Triggers

Activate when

• 用户说“把上面这段做成手机能看的卡片”“做一组适合手机阅读的竖版信息图”“这段总结发朋友圈或小红书”。
• 用户要一张或一组竖屏信息卡，用于手机信息流、朋友圈、微信图文、小红书笔记或课程补充材料。
• The user asks to "turn this into a mobile infographic", "make a vertical infographic for phones", or "export a readable card series as PNG".

Do not activate when

• 用户要的是 16:9 桌面阅读的咨询 Exhibit、指标矩阵或投资阶梯；交给 lov-professional-infographic。
• 用户要的是带独立插图的图鉴或收藏卡，或需要可复制生图 Prompt 的系列卡；交给 lov-gen-card。
• 用户要的是营销种草视觉图卡（多种卡通风格、生图渲染）；交给 baoyu-xhs-images。
• 用户要的是产品宣发海报或一页产品故事；交给 lov-product-onepage。
• 用户只要文字总结、幻灯片或文档排版；本 Skill 不替代写作、演示与文档能力。

User Profile (cross-session)

Every generated Skill is connected to the shared user-profile/v1 contract in skill.yaml. Read the shared user, brand, workspace, preferences, and this Skill's skills.<skill_id> namespace at the start of every run. Keep the source portable: resolved personal values belong in the shared profile, never here.

When the user directly states a durable preference or brand fact, persist it through scripts/profile_store.py and report the saved profile path. Put Skill-specific values under records.<field>; use brand.<field> or user.<field> for shared values. Do not persist inferred secrets or credentials. See references/user-profile.md for the complete contract.

品牌解析顺序见 references/user-config.md。

Skill Group Composition

Read references/skill-composition.md before deciding whether to invoke or extend any adjacent capability. The record distinguishes optional upstream and downstream handoffs from embedded Kit modules. Do not silently depend on a sibling Skill that is not shipped with this source.

输出形态（只有一张图）

交付永远是一张卡：宽度恒为 1080，高度由内容决定（下限 1.2× 宽，不设上限）。 内容多的时候不加张数，把这一张加长——「一图读懂」本身就是长图形态。长卡用小节组织： 先给主排位（总览），再按领域分小节，每节一个小标题加一条细分割线，让读者在一张长图里 仍然有段落感；全卡仍然只有一个判断。矮内容不会被硬撑成固定比例。只有用户明确要求多张时， 才改用系列形态——系列是用户显式指定的例外，不是内容超长时的默认出口。固定比例（3:4/4:5/ 9:16/1:1）是给渠道适配用的可选参数，不是默认值。

观点、图形与文案红线

一张信息图是来源信息的重排，不是作者评论：读者先看到事实、数字与口径。排版前先固定这几件事：

1. 标题只说明这张图是什么：作用或主题，二选一，不写判断句，也不写废话。
   • 主题式（默认）：直接写这张图讲的主题，例如「十座未来城市的市政构想」。
   • 作用式：只在能给出真实信息时用——写清给谁看、回答什么问题、覆盖什么范围，例如 「给新成员的 90 天上手地图」；「要点」「速览」「全览」「一图读完」「一图看懂」这类 放在任何信息图上都成立的话是废话，audit 的 title_filler 会拦截。
   • 标题里不放「最／才／才是／其实／真正」这类论断词，不写「44 起案例里…」这种统计开头。
   • 标题里不要只有数字或符号；audit 的 title_is_subject 会拦截没有主题信息的标题。
   • 标题、眉标与副标题都不要再加前缀或提示词：机构名/调研名不必层层重复，不要写「结论：」。
   • 眉标（eyebrow）只放最少的定位信息，不要塞生造缩写（「71 人可表态」这类没人看得懂）； 样本量、分母、周期这类备注一律放到卡片末尾的口径行。副标题写不出一句人话时就删掉，不要凑。
2. 主关系必须图形化，且按数值倒序。 三个以上同类项要比大小，用 bar-ranking 的条形长度编码， 顺序从大到小（audit 的 bar_order 会拦截乱序）；构成关系用色块，流程用 step-strip。 纯文字罗列（一行一个城市、一人一行）属于流水账，不构成信息图。
3. 排位项要展开“它是什么”。 图表条目可能只有内部人认识时，必须给每条加一句它是什么、 为什么值得选（例如每座城的一句话设定），再放名单。该展开的展开，不要只堆名字。
4. 不要用 bullet 复述图上的数字。 「前三类合计 41 人、占 58%」「第二类 21 人」这类句子 已经由条形长度和数值表达，重复成文字条目只是噪音；结论句里说一次即可。
5. 人名优先用对方自己公开的昵称（群昵称、账号昵称），这类昵称本身就是可展示身份，不需要打码； 只有在昵称缺失、昵称就是真实姓名、或材料涉及隐私时才退回轻打码（刘＊畅）或「群友 N」。 不要使用内部备注（备注是给作者看的，不是给读者的）。
6. 口径要解释“这个数字怎么来的”，不要用生造词。「71 人可表态」这种写法无效；正确写法是 「依据过去一段时间的群聊记录自动分析，推断出每座城可能对应的成员，共 71 人」。
7. 长卡可以长，但只能有一个判断。 全卡保留唯一的 data-claim，小节标题、分组条形与口径行 都只给这个判断补证据。长卡允许放多个条形组（例如总览 + 分领域小节），每组在自己的 .chart 容器内按数值倒序；不同分母不要混进同一组。
8. 长卡要还原来源的信息骨架。 按来源自身的章节组织小节，每节给出它的要点、关键数字与代表 案例（谁、做了什么、规模），不能只给总排行和一句结论；来源里每个章节都要落到卡上， 内容放不下就继续加长这张图，不要靠删减细节收口。
9. 长卡优先用编码，不堆段落。 先找更高密度的可视化：名单行、矩阵、小倍数、关键数字块、 流程条带；案例级信息用一行一个名字的紧凑名单，只有章级要点才写句子。同样信息量尽量压进 更短的图——把每个案例写成一段是最后手段，不是默认写法。 需要真正的图表库（D3 等）时读 references/charts.md： 库要内联、文字留在 HTML 层、颜色与角度要有 data-encoding。 长卡的默认顺序：关键数字 → 构成与名单 → 时间线 → 手法/流程 → 专题；同一个信息不要拆成 两节（例如构成图与全名单合成一节），图表要带引线标注而不是留一列图例。
10. 不写作者总结与个人观点。 正文只放来源的事实、数字与口径；data-claim 行是可选的 （最多一条），只有来源本身有一句必须原样呈现的结论时才用，否则不写。小节副标题不要复述 标题，不写「报告称／报告显示」这类来源提示，也不写「最该记住／值得关注」这类元话术—— 要么给事实，要么给编码说明（如「角度 = 案例数」）。

对外可见红线（强制）

• 来源与工具放进页脚上方的附录区块（.appendix），用一条分割线起头，再用 bullets 写清 「谁提供数据、谁做的呈现」。不要写 Appendix、使用工具 这类标题词——分割线本身就够， 多一行标题只会抢主内容的注意力：

  <div class="appendix" data-source-ref="S1">
    <div class="appendix-rule"></div>
    <ul class="appendix-list">
      <li class="appendix-item" data-role="source" data-source-ref="S1">
        <span class="appendix-key">数据来源</span>：Universal WeChat Key，https://lovstudio.ai/skills/wdb-cli
      </li>
      <li class="appendix-item" data-role="source" data-source-ref="S1">
        <span class="appendix-key">信息图呈现</span>：Mobile Infographic，https://lovstudio.ai/skills/mobile-infographic
      </li>
    </ul>
  </div>
  

  行内标签用「数据来源」「信息图呈现」这类说明性词。每条写成 「网址对应页面的实际标题，完整网址」： 标题必须先去抓那个页面的 <title>／<h1>，不要自己起缩写或简称（把 Universal WeChat Key 写成 「WDBK」这种就是错的）。网址一律印成可读文本： 交付物是 PNG，超链接栅格化后不存在，禁止「点我」或只有能点才读得懂的锚文本。

• 页脚只放品牌，不放来源：单卡居中放 Logo，不显示页码（data-series-size="1" 已内置居中与隐藏页码）； 系列卡才保留左 Logo + 右 n/N。需要带品牌 Tagline 时用左 Logo + 右 Tagline 的变体。

• 仍然禁止本机绝对路径、数据库文件名、表名与账号标识（以 .db 结尾的文件名、数据库目录名、加密库名、 wxid_ 账号、Msg_ 开头的表名）。audit 以 source_hygiene 拦截这些内部痕迹。

Required references

Read before authoring:

1. references/mobile-reading-standard.md — 字号下限、行宽、对比度、安全区、比例与一屏信息量。
2. references/template-grammar.md — 六个语义模板的适用关系与选择规则。
3. references/spec-schema.md — HTML data-* 契约与 audit 字段。

Read references/series-and-export.md when the output is a series, a long image, or platform-specific delivery.

Workflow (MANDATORY)

You MUST follow these steps in order.

Step 0: Resolve skill root, dependencies, and runtime context

• Use SKILL_DIR if the environment provides it.
• Otherwise infer the installed skill directory from the current skill context.
• Verify scripts/infographic_cli.py, assets/card-base.css, assets/templates/, and the required references exist before work.
• Resolve context.profile on every invocation. The precedence is current request, project context, Skill-specific profile records, shared preferences, shared brand/user profile, then safe defaults.

export SKILL_DIR="/path/to/lov-mobile-infographic"
python3 "$SKILL_DIR/scripts/infographic_cli.py" --help

Step 1: Preserve and scope the source

• If the user says “以上内容”“刚才那段”“this result”, use the current conversation result. Do not ask them to paste it again.
• Keep the exact input in source.md under an Exact input section. Append normalized notes and calculations below it; never replace the supplied material.
• Decide the reader and the use moment: 信息流预览、朋友圈九宫格、微信图文内嵌、课程补充。
• Write the thesis first: one sentence the reader could disagree with, plus the evidence that backs it. If the material only yields a fact (“351 人里 2 人投票”), find the judgement behind it (「真正的信号不是票数，而是 88 个人的发言」) before drawing anything.
• Decide the visual encoding of the main relationship (bar length, colour block, order). A flat list of rows is not an infographic.
• Always deliver one card: when the material grows, keep extending the same card instead of adding cards. Keep one argument per card; only switch to a series when the user explicitly asks for several cards (see references/series-and-export.md).

Step 2: Build the evidence table before the visual

Write brief.md from the scaffold, then fill the evidence table:

ID	论点 / 判据	精确证据	编码方式	直接标注

For every visible mark record the source and location, unit, denominator, period, and whether it is fact, estimate, assumption, or interpretation. Never invent a proxy value or a score.

Step 3: Choose one template and the ratio

Pick exactly one template from references/template-grammar.md; when three or more comparable items have to be rank-ordered, use bar-ranking so the ordering is read as length, not as prose. Default ratio is long: one card at 1080 width whose height follows the content (at least 1.2× width, no ceiling). Switch to a fixed ratio only when the delivery surface demands it — 3:4 for WeChat article embeds, 4:5 for feeds, 9:16 for full-screen story, 1:1 for grid tiles — and say which surface forced it.

Step 4: Scaffold

python3 "$SKILL_DIR/scripts/infographic_cli.py" scaffold \
  --template single-claim \
  --ratio long \
  --filename card-01.html \
  --series-index 1 --series-size 1 \
  --eyebrow "运营手册 · 01" \
  --title "优化 harness 的三步" \
  --claim "模型是自变量，harness 是因变量" \
  --source "来源：…" \
  --output-dir "<project directory>"

The template is a semantic skeleton. Every element carrying data-skeleton still holds placeholder copy.

Step 5: Author the card

• Replace every data-skeleton element and remove the attribute once the copy is final.
• Keep exactly one data-claim element per card: the single conclusion this card argues.
• Attach evidence with data-source-ref; declare visual variables with data-encoding; mark decision-changing evidence with data-annotation.
• Write units next to values, put the caveat next to the number it qualifies, and keep the source line readable but subordinate.
• Do not add a second conclusion, a wall of similar boxes, or decorative imagery.
• Keep the brand footer: logo, attribution, and n/N page mark.

Step 6: Render

python3 "$SKILL_DIR/scripts/infographic_cli.py" render \
  --input "<project>/card-01.html" \
  --output "<project>/card-01.png" \
  --scale 2

The renderer captures the [data-card] element at an exact pixel size and fails when the PNG dimensions do not match the canvas.

Step 7: Audit and review

python3 "$SKILL_DIR/scripts/infographic_cli.py" audit \
  --input "<project>/card-01.html" \
  --image "<project>/card-01.png" \
  --report "<project>/card-01.audit.json" \
  --ratio 3:4

The audit measures the rendered page in a real browser: font floors, characters per line, contrast, overflow, out-of-canvas elements, safe area, single claim, evidence linkage, brand footer, series page mark, remaining skeleton copy, and truncation. It writes a 100-point proxy with an 85 threshold and critical-dimension floors.

Then inspect the PNG at original detail and at thumbnail size (a 320px-wide downscale is enough). Answer:

1. 5 秒内能否说出这张卡在讲什么？
2. 阅读顺序是否从标题到结论再到依据与来源？
3. 有没有被省略号截断、被裁切或压线的文字？
4. 每个数字是否带单位与口径？
5. 有没有大片空白或被撑满到窒息的区块？
6. 标题是可被反驳的观点吗？主关系是用图形（长度/颜色/顺序）表达的吗？
7. 卡面上有没有出现内部来源、数据库路径、表名或不该露出的真名？

Record the reviewed image and the concrete finding, then run the release gate:

python3 "$SKILL_DIR/scripts/infographic_cli.py" audit \
  --input "<project>/card-01.html" \
  --image "<project>/card-01.png" \
  --report "<project>/card-01.audit.json" \
  --ratio 3:4 \
  --human-review passed \
  --review-note "<what was verified at full size and thumbnail size>" \
  --strict

passed without both --image and a specific review note is invalid. Do not report success because audit.json shows zero machine errors — the machine proxy is not proof of readability.

Step 8: Series and export

A single card needs no manifest. Only when the user explicitly asks for several cards do you scaffold a series with the same --series-size, write manifest.json from the case template, and verify that every card keeps the same width, safe area, and footer position. See references/series-and-export.md.

Step 9: Deliver

Return clickable paths to the PNG, the editable HTML, brief.md, source.md and audit.json — plus manifest.json only for a series (a single card never needs one). State the template, ratio, evidence mode, proxy score, and human-review result. Disclose assumptions, omitted material, and any card that is still machine-only verified.

Dependencies

• Python 3.8+ standard library.
• Playwright for Python plus Chromium or Google Chrome for render and audit:

python3 -m pip install "playwright>=1.45,<2"
python3 -m playwright install chromium

• scaffold and init-brand need no browser and no network.
• Brand assets stay user-configurable; the packaged default is a placeholder profile, not a claim about the user's brand.

CLI

python3 "$SKILL_DIR/scripts/infographic_cli.py" --help
python3 "$SKILL_DIR/scripts/infographic_cli.py" init-brand --help
python3 "$SKILL_DIR/scripts/infographic_cli.py" scaffold --help
python3 "$SKILL_DIR/scripts/infographic_cli.py" render --help
python3 "$SKILL_DIR/scripts/infographic_cli.py" audit --help
python3 "$SKILL_DIR/scripts/test_infographic_cli.py"

通用反馈闭环

用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：

1. 先判断意见是 task-specific（仅本次）还是 reusable（可跨任务复用）。
2. task-specific 只修改当前任务，不改 Skill。
3. reusable 先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。
4. 完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
5. reusable 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。