infocard（infocard 搜索）

Infocard Generator

Quick Start: Analyze content (density × structure × mood) → Auto-sense tone for color palette → Pick a layout skeleton → Embed HTML directly in Markdown with <style scoped>.

Critical Rules

Rule 1: Direct HTML Embedding

IMPORTANT: Write info cards as direct HTML in Markdown. NEVER use code blocks (``` `html ```). The HTML should be embedded directly in the document without any fencing.

Rule 2: No Empty Lines in HTML Structure

CRITICAL: Do NOT add any empty lines within the HTML info card structure. Keep the entire HTML block continuous to prevent parsing errors.

Rule 3: Content Analysis Before Layout

REQUIRED: Analyze content along three dimensions before designing:

Density (determines breathing rhythm):

Structure (determines layout geometry):

Mood (determines color temperature):

Rule 4: Tone Sensing

REQUIRED: Auto-select color palette based on content topic. Scan content keywords and match the closest tone:

When a style template is explicitly chosen, its colors take precedence over tone sensing. Use tone sensing as the default when no style is specified.

Rule 5: Title Protection

If the user provides a title explicitly, use it as-is for the main headline. Put editorial interpretation into subtitle, summary, or side modules. Do not silently rewrite the user's title.

Rule 6: Typography Hierarchy

Maintain a clear type scale and use it consistently:

• Hero title: 32px–48px, weight 700–900, tight letter-spacing (-0.02em)
• Subtitle / summary: 16px–20px, weight 400–500
• Body text: 14px–16px, weight 400, line-height 1.6–1.7
• Meta / tags / captions: 11px–13px, weight 500–700, uppercase with letter-spacing
• Body text color: never pure black — use #1a1a1a, #333, or #4a4a4a

Rule 7: Visual Weight Distribution

At least one module should feel visually heavier than the others. Avoid making every panel use the exact same treatment. Differentiate through scale, background tone, typographic weight, or accent rules.

Rule 8: Taste Rules (Anti-AI Checklist)

Before finalizing any card, check against these common AI-generated visual patterns:

Layout:

• No centered hero — Do not default-center titles. Prefer left-aligned or asymmetric
• No equal-width tiles — Three equal columns side by side is the #1 AI signature. Use 2fr 1fr, asymmetric grids, or staggered layouts
• No uniform panels — At least one panel must differ in scale, weight, or treatment

Typography:

• No pure black #000000 — Use off-black (#1a1a1a, #2d2a26) or warm/cool dark
• No oversized-only hierarchy — Build hierarchy with weight and color, not just font-size scaling

Color:

• Max 1 accent color, saturation < 80%
• No neon gradients — No purple-blue AI glow, no gradient-filled headlines
• Consistent temperature — Do not mix warm gray and cool gray in one card

Content:

• No filler data — Avoid 99.99%, 50%, 1234567. Use organic numbers (47.2%, 3.8M)
• No AI phrasing — Avoid "empower", "seamless", "unleash", "next-generation"

Spacing:

• Padding and margins must be mathematically precise, no awkward gaps
• Adjacent elements must be visually aligned

Style Examples

Choose a visual family first, then pick the specific template inside that family. This keeps the library broad without forcing a flat 29-style scan every time.

Style Families

Warm Editorial and Storytelling

Use when the card should feel reflective, human, narrative, or culturally textured.

Soft Lifestyle and Teaching

Use when the card should feel calm, approachable, and low-pressure.

Paper, Research, and Governance

Use when the card should read like a memo, report, brief, or evidence summary.

Business, Finance, and Trust

Use when the card should look operational, executive, or commercially credible.

Technical and Operational

Use when precision, systems language, or implementation detail needs to dominate.

Broadcast, Statement, and High-Contrast

Use when the card should announce, signal urgency, or land a strong visual punch.

Signature Visual Identities

Use when the visual identity itself is part of the message.

Layout Skeletons

Choose the content structure family first, then select the specific wireframe. Layouts remain style-agnostic.

Layout Families

Core Single-Topic Cards

Use when one thesis should dominate and supporting content should stay secondary.

Metrics and Operational Readouts

Use when numbers, status, or operating signals need to be scanned quickly.

Sequence, Roadmap, and Progression

Use when the reader needs stages, steps, or directional movement.

Comparison and Decision

Use when the card needs explicit trade-offs, prioritization, or side-by-side framing.

Grid and Inventory

Use when the card needs repeated modules, mixed-size tiles, or scan-friendly inventories.

System and Relationship Mapping

Use when structure, adjacency, or network relationships matter more than sequence.

Document and Memo Logic

Use when the card should read like a structured brief with explicit sections.

Governance, Risk, and Audit

Use when ownership, control status, and mitigation detail must be explicit.

Narrative and Stakeholder Updates

Use when the content is about people, teams, customers, or partner motion.

Primitive note: org-update, customer-story, and partner-brief now share a lightweight card-brief-* outer rhythm. Keep news-bulletin separate unless the structure is actually about relationship or stakeholder motion rather than headline cadence.

Family Alignment Notes

• Prefer existing family primitives before inventing new class names. Current aligned layout families include card-doc-*, card-kpi-*, card-sequence-*, card-tile-*, card-map-*, card-compare-*, card-review-*, card-topic-*, and card-brief-*.
• When a new layout clearly belongs to one of those families, vary geometry and modifiers first. Do not create a parallel primitive vocabulary for the same role.
• Explicit special cases remain intentionally separate: quote-card, terminal-window, news-bulletin, and the strongest identity-driven style themes such as deep-night and glassmorphism.
• If a layout or style only shares mood and not structure, document the family relationship in prose rather than forcing additional primitive convergence.

Design Principles

Space and Breathing Room

• Card padding: 32px–48px from edges
• Module gaps: 16px–24px
• Title area must have generous line-height (1.1–1.3) and clear separation from body
• Never crowd content against card edges

Visual Accents

• Use 4px–6px thick rules as section dividers or accent borders
• Use subtle tinted backgrounds (rgba(0,0,0,0.03) or style-specific tints) for secondary panels
• Accent colors should be restrained: one highlight color used for rules, tags, or key numbers
• Optional: 4% noise overlay for paper texture (see style templates)

Content Rhythm

• High-density cards: group into overview → core judgment → supporting modules → conclusion
• Ranking content: asymmetric hero + structured list (avoid equal tiles)
• Tutorial/analysis content: overview → core insight → detail blocks → boundary/caveats → summary

Styling Reference

Common Classes (shared across all styles)

• .card-frame — outer container with max-width and padding
• .card — main card surface with background, padding, and optional noise overlay
• .card-meta — meta line (category, date, version) in small uppercase
• .card-title — main headline
• .card-subtitle — secondary headline or summary
• .card-bar — thick accent rule divider
• .card-body — body text paragraph
• .card-body.dropcap — first paragraph with drop cap initial letter (editorial opening)
• .card-highlight — standalone short sentence (< 25 chars) with left accent border for key insights
• .card-grid — grid container; .card-grid-2 for two columns
• .card-panel — content panel with border-top accent
• .card-panel.heavy — heavier panel with more padding
• .card-panel.light — lighter panel with thinner border
• .card-panel-title — panel heading in small uppercase
• .card-panel-text — panel body text
• .card-item — titled content block (label + description pair)
• .card-item-label — item title/label
• .card-tag — inline tag/badge
• .card-stat — oversized number/metric display
• .card-stat-label — label beneath a stat
• .card-divider — thin horizontal rule between sections
• .card-footer — bottom strip for source, attribution, or notes
• .card-endmark — end-of-content mark (∎) for editorial closure

Rich Text Elements

Drop cap (first paragraph only — creates editorial opening ceremony):

<p class="card-body dropcap">First paragraph text...</p>

Highlight quote (standalone insight, < 25 chars, with accent left border):

<p class="card-highlight">Key insight phrase</p>

Titled item (label + description pairs, for structured lists):

<div class="card-item">
  <p class="card-item-label">Item Title</p>
  <p class="card-panel-text">Item description text.</p>
</div>

Section divider:

<div class="card-divider"></div>

End mark (editorial closure, placed at content end):

<span class="card-endmark">∎</span>

Best Practices

Content Guidelines

1. Direct embedding only — Always embed HTML directly in Markdown, never use ``` `html ``` code blocks
2. No empty lines in structure — Keep the entire HTML block continuous
3. Judge density first — Decide low/medium/high before picking layout
4. Protect user titles — Never silently rewrite a user-provided headline
5. Balance visual weight — At least one heavy block, one medium, one light
6. Use type scale consistently — Follow the size hierarchy defined above
7. Accent with restraint — One accent color, used sparingly for rules and highlights
8. Fill space intentionally — If a section looks empty, restructure hierarchy before adding filler content