Agnes 图片生成后端

调用 agnes-image-2.1-flash 生成真正的栅格图片。本 Skill 是项目图片渲染后端；封面和插图 Skill 仍负责选图、风格、构图和提示词。

必要配置

从运行环境读取 AGNES_API_KEY。只在 HTTPS Authorization 请求头中使用它，不把 Key 写入提示词、命令参数、文件、stdout 或任务产物。

可选环境变量：

• AGNES_IMAGE_MODEL：默认 agnes-image-2.1-flash。
• AGNES_IMAGE_ENDPOINT：默认官方生成端点；除非迁移服务，否则不要修改。
• AGNES_IMAGE_SIZE：默认 2K。

生成流程

1. 确认调用方已经把完整最终提示词写入独立文件。不要接受只存在于对话里的临时提示词。
2. 确定输出路径、尺寸和宽高比。公众号封面的 2.35:1 会自动映射为 Agnes 支持的 21:9。
3. 文生图不传 --ref；图生图为每张参考图片传一次 --ref。本地图片会转成 Data URI，公共 HTTPS URL 会原样传递。
4. 调用脚本并读取 stdout 的单行 JSON 结果：

python3 <SKILL_ROOT>/scripts/generate.py \
  --prompt-file <ABSOLUTE_PROMPT_FILE> \
  --output <ABSOLUTE_OUTPUT.png> \
  --size 2K --ratio 16:9 \
  [--ref <ABSOLUTE_IMAGE_OR_HTTPS_URL>]...

5. 生成失败时根据 JSON 错误修正配置或提示词。脚本会对限流和服务器错误自动重试一次；不要在认证失败时切换到未经用户授权的供应商。

正文多图没有原生批量接口时，可并行执行最多四个独立命令。每个命令必须使用自己的提示词文件和输出路径。

图生图

参考图片仅支持公共 HTTPS URL、data:image/... URI 或本地图片路径。不要把需要 Cookie、登录态或私有请求头的 URL 交给 API。保持原构图时，要在提示词中明确写出必须保留的主体、视角和布局。

验证配置

使用 --dry-run 检查提示词、比例、参考图片和 AGNES_API_KEY 是否就绪；它不会调用 API，也不会打印提示词或 Key：

python3 <SKILL_ROOT>/scripts/generate.py \
  --prompt-file <PROMPT_FILE> --output <OUTPUT.png> \
  --ratio 21:9 --dry-run

接口字段和返回结构见 references/api.md。

Article Illustrator

Analyze articles, identify illustration positions, generate images with Type × Style × Palette consistency.

User Input Tools

When this skill prompts the user, follow this tool-selection rule (priority order):

1. Prefer built-in user-input tools exposed by the current agent runtime — e.g., AskUserQuestion, request_user_input, clarify, ask_user, or any equivalent.
2. Fallback: if no such tool exists, emit a numbered plain-text message and ask the user to reply with the chosen number/answer for each question.
3. Batching: if the tool supports multiple questions per call, combine all applicable questions into a single call; if only single-question, ask them one at a time in priority order.

Concrete AskUserQuestion references below are examples — substitute the local equivalent in other runtimes.

Image Generation Tools

When this skill needs to render an image, resolve the backend in this order:

1. Current-request override — if the user names a specific backend in the current message, use it.
2. Saved preference — if EXTEND.md sets preferred_image_backend to a backend available right now, use it.
3. Auto-select (when the preference is auto, unset, or the pinned backend isn't available):
   • Codex (imagegen) — first, inspect your available-skills / tool inventory. If a skill named imagegen is listed, you are running inside Codex and MUST use it: invoke via the Skill tool with skill: "imagegen", passing the saved prompt file's content (plus output path and aspect ratio per Codex imagegen's own args). Codex imagegen is the official raster backend in that runtime and outranks any non-native skill (e.g., baoyu-image-gen) unless the user has explicitly pinned a different preferred_image_backend.
   • Codex via codex exec (codex-imagegen) — if the current runtime exposes no native imagegen skill but the codex CLI is on PATH with an active codex login, route through baoyu-image-gen --provider codex-cli (preferred), or — if baoyu-image-gen is unavailable — invoke the bundled wrapper directly. Details, parameters, and the runtime-discovery procedure live in references/codex-imagegen.md — load that file only when this branch is selected.
   • Cursor (GenerateImage) — if the runtime exposes a native GenerateImage tool, you are running inside Cursor and it outranks any non-native skill the same way Codex imagegen does. Two hard caveats: (a) it has no aspect-ratio parameter — state the target aspect ratio / dimensions explicitly in the prompt text passed as description; (b) it does not accept an output directory — it saves to a tool-managed location, so after generation copy/move the file to the skill's expected output path (e.g., outputs/.../NN-xxx.png). Reference images go in reference_image_paths.
   • Other runtime-native tools — if the runtime exposes a different native image tool (e.g., Hermes image_generate), use it the same way.
   • Otherwise, if exactly one non-native backend is installed (e.g., baoyu-image-gen), use it.
   • Otherwise (multiple non-native backends with no runtime-native tool), ask the user once — batch with any other initial questions.
4. If none are available, tell the user and ask how to proceed.

Agnes backend contract: when the saved preference resolves to agnes-image-gen, load ../agnes-image-gen/SKILL.md and invoke its bundled scripts/generate.py once per saved prompt file. Pass the output path, aspect ratio, and per-image direct references. It reads AGNES_API_KEY from the environment. Treat missing/invalid credentials as a backend failure; never put the Key in a command argument or fall back to another provider without user authorization.

⛔ Never substitute SVG, HTML, canvas, or other code-based rendering for raster image generation. Codex imagegen's own description says it should be used "when the output should be a bitmap asset rather than repo-native code or vector." If you cannot resolve a raster backend via step 3, fall through to step 4 and ask the user — do not silently emit SVG, write inline <svg> markup, or produce HTML/CSS art as a substitute. This applies even if the article/section seems "diagram-like": the consumer skill calling this rule has already decided that a raster image is what it needs.

⛔ Never repair rendered text by painting over a generated bitmap. Do not use ImageMagick, Pillow, Canvas, SVG, HTML/CSS, OCR scripts, or any other programmatic overlay to cover, rewrite, erase, stroke, or replace labels, captions, or any other text inside an already generated illustration. If text is wrong or unclear, regenerate from a corrected prompt, redraw with less or no on-image text, or ask the user which imperfect candidate to keep.

Setting preferred_image_backend: ask forces the step-3 prompt every run regardless of available backends. Users change the pinned backend via the ## Changing Preferences section below.

Prompt file requirement (hard): write each image's full, final prompt to a standalone file under prompts/ (naming: NN-{type}-[slug].md) BEFORE invoking any backend. The backend receives the prompt file (or its content); the file is the reproducibility record and lets you switch backends without regenerating prompts.

Concrete tool names (imagegen, GenerateImage, image_generate, baoyu-image-gen) above are examples — substitute the local equivalents under the same rule.

Batch Generation Policy

After every prompt file for the run has been saved and verified, generate images in batches by default.

Priority order:

1. Use the chosen backend's native batch / multi-task interface if it exists. Each task must keep its own prompt file, output path, aspect ratio, and direct reference images.
2. If no native batch interface exists but the runtime can issue parallel tool calls, dispatch up to generation_batch_size images at a time. Default: 4. An explicit user request in the current message, such as --batch-size 4 or "并行4张一起生成", overrides EXTEND.md.
3. If neither native batch nor parallel tool calls are available, generate sequentially.

Rules:

• Never start the first batch until all prompt files for that batch exist on disk.
• Retry failed items once without regenerating successful items.
• Do not use subagents merely to parallelize image rendering. Use subagents only for separate prompt iteration or creative exploration.

Confirmation Policy

Default behavior: confirm before generation.

• Treat explicit skill invocation, a file path, matched signals/presets, and EXTEND.md defaults as recommendation inputs only. None of them authorizes skipping confirmation.
• Do not start Step 4 or later until the user completes Step 3.
• Skip confirmation only when the current request explicitly says to do so, for example: "直接生成", "不用确认", "跳过确认", "按默认出图", or equivalent wording.
• If confirmation is skipped explicitly, state the assumed type / density / style / palette / language / backend in the next user-facing update before generating.

Reference Images

Users may supply reference images via --ref <files...> or by providing file paths / pasting images in conversation. Refs guide style, palette, composition, or subject for specific illustrations.

Full detection, storage, and processing rules are in references/workflow.md (Step 1.0 saves to references/NN-ref-{slug}.{ext}; Step 5.3 processes per-illustration usage direct | style | palette). When the chosen backend supports batch input, direct-usage entries in each prompt file's references: frontmatter should be propagated into its batch payload so backends can pass them through (e.g. baoyu-image-gen accepts ref per task).

Three Dimensions

Combine freely: --type infographic --style vector-illustration --palette macaron

Or use presets: --preset edu-visual → type + style + palette in one flag. See Style Presets.

Types

Styles

See references/styles.md for Core Styles, full gallery, and Type × Style compatibility.

Workflow

- [ ] Step 1: Pre-check (EXTEND.md, references, config)
- [ ] Step 2: Analyze content
- [ ] Step 3: Confirm settings (AskUserQuestion)
- [ ] Step 4: Generate outline
- [ ] Step 5: Generate images
- [ ] Step 6: Finalize

Step 1: Pre-check

1.5 Load Preferences (EXTEND.md) ⛔ BLOCKING

Check EXTEND.md in priority order — the first one found wins:

Full procedures: references/workflow.md

Step 2: Analyze

CRITICAL: Metaphors → visualize underlying concept, NOT literal image.

Full procedures: references/workflow.md

Step 3: Confirm Settings ⚠️

Hard gate: this step is mandatory per the Confirmation Policy — Steps 4+ cannot start until the user confirms here (or explicitly opts out with "直接生成" / equivalent wording in the current request).

ONE AskUserQuestion, max 4 Qs. Q1-Q2 REQUIRED. Q3 required unless preset chosen.

Full procedures: references/workflow.md

Step 4: Generate Outline

Save outline.md with frontmatter (type, density, style, palette, image_count) and entries:

## Illustration 1
**Position**: [section/paragraph]
**Purpose**: [why]
**Visual Content**: [what]
**Filename**: 01-infographic-concept-name.png

Full template: references/workflow.md

Step 5: Generate Images

⛔ BLOCKING: Prompt files MUST be saved before ANY image generation. This is a hard requirement regardless of which backend is chosen — the prompt file is the reproducibility record.

1. For each illustration, create a prompt file per references/prompt-construction.md
2. Save to prompts/NN-{type}-{slug}.md with YAML frontmatter
3. Prompts MUST use type-specific templates with structured sections (ZONES / LABELS / COLORS / STYLE / ASPECT)
4. LABELS MUST include article-specific data: actual numbers, terms, metrics, quotes
5. DO NOT pass ad-hoc inline prompts to --prompt without saving prompt files first
6. Select the backend via the ## Image Generation Tools rule at the top: use whatever is available; if multiple, ask the user once. Do this once per session before any generation.
   • agnes-image-gen invocation: run its deterministic Python client with --prompt-file, --output, --ratio, and repeated --ref arguments. It has no native batch endpoint, so use the runtime's parallel calls up to generation_batch_size.
   • codex-imagegen invocation: when the rule resolves to codex-imagegen, see references/codex-imagegen.md for the invocation contract (preferred baoyu-image-gen --provider codex-cli path, runtime wrapper discovery, parameter notes, stdout schema, batch semantics).
7. Execution strategy: Generate in batches per the ## Batch Generation Policy: backend native batch first, runtime parallel tool calls second, sequential only as fallback. Default batch size is 4 unless EXTEND.md or the current request overrides it.
8. Process references (direct/style/palette) per prompt frontmatter
9. Apply watermark if EXTEND.md enabled
10. Generate from saved prompt files; retry once on failure

Full procedures: references/workflow.md

Step 6: Finalize

Insert ![description]({relative-path}/NN-{type}-{slug}.png) after paragraphs. Path computed relative to article file based on output directory setting.

Article Illustration Complete!
Article: [path] | Type: [type] | Density: [level] | Style: [style] | Palette: [palette or default]
Images: X/N generated

Output Directory

Output directory is determined by default_output_dir in EXTEND.md (set during first-time setup):

All auxiliary files (outline, prompts) are saved inside the output directory:

{output-dir}/
├── outline.md
├── prompts/
│   └── NN-{type}-{slug}.md
└── NN-{type}-{slug}.png

When input is pasted content (no file path), always uses illustrations/{topic-slug}/ with source-{slug}.{ext} saved alongside.

Slug: 2-4 words, kebab-case. Conflict: append -YYYYMMDD-HHMMSS.

Modification

Text correction policy:

• If any rendered text (labels, captions, etc.) is misspelled, garbled, hard to read, or visually weak, do not patch the bitmap with code.
• For text-correction regenerations, write a new prompt file and a new output path so the flawed candidate is preserved for comparison.
• Post-processing is limited to crop, resize, compression, or format conversion that does not alter text or the main composition.

References

Changing Preferences

EXTEND.md lives at the first matching path listed in Step 1.5. Three ways to change it:

• Edit directly — open EXTEND.md and change fields. Full schema: references/config/preferences-schema.md.
• Reconfigure interactively — delete EXTEND.md (or ask "reconfigure baoyu-article-illustrator preferences" / "重新配置"). The next run re-triggers first-time setup.
• Common one-line edits:
  • preferred_image_backend: auto — default; runtime-native tool wins, falls back to the only installed backend, asks only if multiple non-native are present.
  • preferred_image_backend: codex-imagegen — pin to Codex's built-in.
  • preferred_image_backend: baoyu-image-gen — pin to the baoyu-image-gen skill.
  • preferred_image_backend: agnes-image-gen — pin to the project Agnes Image 2.1 Flash backend; requires AGNES_API_KEY.
  • preferred_image_backend: ask — confirm backend every run.
  • generation_batch_size: 4 — default number of images to render concurrently when the runtime supports parallel generation calls.
  • preferred_type: infographic, preferred_style: notion, preferred_palette: macaron, language: zh.
  • default_output_dir: imgs-subdir — where to write generated images relative to the article.

Cover Image Generator

Generate elegant cover images for articles with 5-dimensional customization.

User Input Tools

When this skill prompts the user, follow this tool-selection rule (priority order):

1. Prefer built-in user-input tools exposed by the current agent runtime — e.g., AskUserQuestion, request_user_input, clarify, ask_user, or any equivalent.
2. Fallback: if no such tool exists, emit a numbered plain-text message and ask the user to reply with the chosen number/answer for each question.
3. Batching: if the tool supports multiple questions per call, combine all applicable questions into a single call; if only single-question, ask them one at a time in priority order.

Concrete AskUserQuestion references below are examples — substitute the local equivalent in other runtimes.

Image Generation Tools

When this skill needs to render an image, resolve the backend in this order:

1. Current-request override — if the user names a specific backend in the current message, use it.
2. Saved preference — if EXTEND.md sets preferred_image_backend to a backend available right now, use it.
3. Auto-select (when the preference is auto, unset, or the pinned backend isn't available):
   • Codex (imagegen) — first, inspect your available-skills / tool inventory. If a skill named imagegen is listed, you are running inside Codex and MUST use it: invoke via the Skill tool with skill: "imagegen", passing the saved prompt file's content (plus output path and aspect ratio per Codex imagegen's own args). Codex imagegen is the official raster backend in that runtime and outranks any non-native skill (e.g., baoyu-image-gen) unless the user has explicitly pinned a different preferred_image_backend.
   • Codex via codex exec (codex-imagegen) — if the current runtime exposes no native imagegen skill but the codex CLI is on PATH with an active codex login, route through baoyu-image-gen --provider codex-cli (preferred), or — if baoyu-image-gen is unavailable — invoke the bundled wrapper directly. Details, parameters, and the runtime-discovery procedure live in references/codex-imagegen.md — load that file only when this branch is selected.
   • Cursor (GenerateImage) — if the runtime exposes a native GenerateImage tool, you are running inside Cursor and it outranks any non-native skill the same way Codex imagegen does. Two hard caveats: (a) it has no aspect-ratio parameter — state the target aspect ratio / dimensions explicitly in the prompt text passed as description; (b) it does not accept an output directory — it saves to a tool-managed location, so after generation copy/move the file to the skill's expected output path (e.g., outputs/.../NN-xxx.png). Reference images go in reference_image_paths.
   • Other runtime-native tools — if the runtime exposes a different native image tool (e.g., Hermes image_generate), use it the same way.
   • Otherwise, if exactly one non-native backend is installed (e.g., baoyu-image-gen), use it.
   • Otherwise (multiple non-native backends with no runtime-native tool), ask the user once — batch with any other initial questions.
4. If none are available, tell the user and ask how to proceed.

Agnes backend contract: when the saved preference resolves to agnes-image-gen, load ../agnes-image-gen/SKILL.md and invoke its bundled scripts/generate.py with the saved prompt file, output path, aspect ratio, and any direct reference images. It reads AGNES_API_KEY from the environment. Treat missing/invalid credentials as a backend failure; never put the Key in a command argument or fall back to another provider without user authorization.

⛔ Never substitute SVG, HTML, canvas, or other code-based rendering for raster image generation. Codex imagegen's own description says it should be used "when the output should be a bitmap asset rather than repo-native code or vector." If you cannot resolve a raster backend via step 3, fall through to step 4 and ask the user — do not silently emit SVG, write inline <svg> markup, or produce HTML/CSS art as a substitute. This applies even if the article/section seems "diagram-like": the consumer skill calling this rule has already decided that a raster image is what it needs.

⛔ Never repair rendered text by painting over a generated bitmap. Do not use ImageMagick, Pillow, Canvas, SVG, HTML/CSS, OCR scripts, or any other programmatic overlay to cover, rewrite, erase, stroke, or replace title/subtitle text inside an already generated cover image. If text is wrong or unclear, regenerate from a corrected prompt, switch to a lower-text or no-title variant, or ask the user which imperfect candidate to keep.

Setting preferred_image_backend: ask forces the step-3 prompt every run regardless of available backends. Users change the pinned backend via the ## Changing Preferences section below.

Prompt file requirement (hard): write each image's full, final prompt to a standalone file under prompts/ (naming: NN-{type}-[slug].md) BEFORE invoking any backend. The backend receives the prompt file (or its content); the file is the reproducibility record and lets you switch backends without regenerating prompts.

Concrete tool names (imagegen, GenerateImage, image_generate, baoyu-image-gen) above are examples — substitute the local equivalents under the same rule.

Confirmation Policy

Default behavior: confirm before generation.

• Treat explicit skill invocation, a file path, matched keywords/presets, EXTEND.md defaults, and any documented auto-selection as recommendation inputs only. None of them authorizes skipping confirmation.
• Do not start Step 3 or Step 4 until the user confirms the dimensions / aspect / language / backend choices.
• Skip confirmation only when the current request explicitly says to do so, for example: --quick, "直接生成", "不用确认", "跳过确认", "按默认出图", or equivalent wording. quick_mode: true in EXTEND.md counts as a standing explicit opt-out — set it only when you want every run to skip Step 2.
• If confirmation is skipped explicitly, state the assumed dimensions / aspect / language / backend in the next user-facing update before generating.

Options

Five Dimensions

Auto-selection rules: references/auto-selection.md

Galleries

Types: hero, conceptual, typography, metaphor, scene, minimal → Details: references/types.md

Palettes: warm, elegant, cool, dark, earth, vivid, pastel, mono, retro, duotone, macaron → Details: references/palettes/

Renderings: flat-vector, hand-drawn, painterly, digital, pixel, chalk, screen-print → Details: references/renderings/

Text Levels: none (pure visual) | title-only (default) | title-subtitle | text-rich (with tags) → Details: references/dimensions/text.md

Mood Levels: subtle (low contrast) | balanced (default) | bold (high contrast) → Details: references/dimensions/mood.md

Fonts: clean (sans-serif) | handwritten | serif | display (bold decorative) → Details: references/dimensions/font.md

File Structure

Output directory per default_output_dir preference:

• same-dir: {article-dir}/
• imgs-subdir: {article-dir}/imgs/
• independent (default): cover-image/{topic-slug}/

<output-dir>/
├── source-{slug}.{ext}    # Source files
├── refs/                  # Reference images (if provided)
│   ├── ref-01-{slug}.{ext}
│   └── ref-01-{slug}.md   # Description file
├── prompts/cover.md       # Generation prompt
└── cover.png              # Output image

Slug: 2-4 words, kebab-case. Conflict: append -YYYYMMDD-HHMMSS

Workflow

Progress Checklist

Cover Image Progress:
- [ ] Step 0: Check preferences (EXTEND.md) ⛔ BLOCKING
- [ ] Step 1: Analyze content + save refs + determine output dir
- [ ] Step 2: Confirm options (6 dimensions) ⚠️ unless --quick
- [ ] Step 3: Create prompt
- [ ] Step 4: Generate image
- [ ] Step 5: Completion report

Flow

Input → [Step 0: Preferences] ─┬─ Found → Continue
                               └─ Not found → First-Time Setup ⛔ BLOCKING → Save EXTEND.md → Continue
        ↓
Analyze + Save Refs → [Output Dir] → [Confirm: 6 Dimensions] → Prompt → Generate → Complete
                                              ↓
                                     (skip if --quick or all specified)

Step 0: Load Preferences ⛔ BLOCKING

Check EXTEND.md in priority order — the first one found wins:

CRITICAL: If not found, complete setup BEFORE any other steps or questions.

Step 1: Analyze Content

1. Save reference images (if provided) → references/workflow/reference-images.md
2. Save source content (if pasted, save to source.md)
3. Analyze content: topic, tone, keywords, visual metaphors
4. Deep analyze references ⚠️: Extract specific, concrete elements (see reference-images.md)
5. Detect language: Compare source, user input, EXTEND.md preference
6. Determine output directory: Per File Structure rules

⚠️ People in Reference Images:

If reference images contain people who should appear in the cover:

• Model supports --ref (default): Copy image to refs/, pass via --ref at generation. No description file needed — the model sees the face directly.
• Model does NOT support --ref (Jimeng, Seedream 3.0): Create refs/ref-NN-{slug}.md with per-character description (hair, glasses, skin tone, clothing). Embed as MUST/REQUIRED instructions in prompt text.

See reference-images.md for full decision table.

Step 2: Confirm Options ⚠️

Hard gate: this step is mandatory per the Confirmation Policy — Steps 3–4 cannot start until the user confirms here (or explicitly opts out with --quick / quick_mode: true / equivalent wording in the current request).

MUST use AskUserQuestion tool to present options as interactive selection — NOT plain text tables. Present up to 4 questions in a single AskUserQuestion call (Type, Palette, Rendering, Font + Settings). Each question shows the recommended option first with reason, followed by alternatives.

Full confirmation flow and question format: references/workflow/confirm-options.md

Step 3: Create Prompt

Save to prompts/cover.md. Template: references/workflow/prompt-template.md

CRITICAL - References in Frontmatter:

• Files saved to refs/ → Add to frontmatter references list
• Style extracted verbally (no file) → Omit references, describe in body
• Before writing → Verify: test -f refs/ref-NN-{slug}.{ext}

Reference elements in body MUST be detailed, prefixed with "MUST"/"REQUIRED", with integration approach.

Step 4: Generate Image

1. Backup existing cover.png if regenerating
2. Select backend via the ## Image Generation Tools rule at the top: use whatever is available; if multiple, ask the user once. Do this once per session before any generation.
3. Write the full final prompt to prompts/01-cover-[slug].md (hard requirement) BEFORE invoking the backend.
4. Process references from prompt frontmatter:
   • direct usage → pass via --ref (use ref-capable backend)
   • style/palette → extract traits, append to prompt
5. Generate: Call the chosen backend with the prompt file, output path, aspect ratio.
   • codex-imagegen: see references/codex-imagegen.md for the invocation contract (preferred baoyu-image-gen --provider codex-cli path, runtime wrapper discovery, parameter notes, stdout schema, batch semantics).
   • agnes-image-gen: execute its deterministic Python client with --prompt-file, --output, --ratio, and repeated --ref arguments. The client maps 2.35:1 to Agnes 21:9.
   • Codex imagegen (native) or other runtime-native tools / baoyu-image-gen skill: per the rule in ## Image Generation Tools above.
6. On failure: auto-retry once

Step 5: Completion Report

Cover Generated!

Topic: [topic]
Type: [type] | Palette: [palette] | Rendering: [rendering]
Text: [text] | Mood: [mood] | Font: [font] | Aspect: [ratio]
Title: [title or "visual only"]
Language: [lang] | Watermark: [enabled/disabled]
References: [N images or "extracted style" or "none"]
Location: [directory path]

Files:
✓ source-{slug}.{ext}
✓ prompts/cover.md
✓ cover.png

Image Modification

Text correction policy:

• If the title/subtitle is misspelled, garbled, hard to read, or visually weak, do not patch the bitmap with code.
• For text-correction regenerations, write a new prompt file and a new output path so the flawed candidate is preserved for comparison.
• Post-processing is limited to crop, resize, compression, or format conversion that does not alter text or the main composition.

Composition Principles

• Whitespace: 40-60% breathing room
• Visual anchor: Main element centered or offset left
• Characters: Simplified silhouettes; NO realistic humans
• Title: Use exact title from user/source; never invent

Changing Preferences

EXTEND.md lives at the path noted in Step 0. Three ways to change it:

• Edit directly — open EXTEND.md and change fields. Full schema: references/config/preferences-schema.md.
• Reconfigure interactively — delete EXTEND.md (or ask "reconfigure baoyu-cover-image preferences" / "重新配置"). The next run re-triggers first-time setup.
• Common one-line edits:
  • preferred_image_backend: auto — default; runtime-native tool wins, falls back to the only installed backend, asks only if multiple non-native are present.
  • preferred_image_backend: codex-imagegen — pin to Codex's built-in.
  • preferred_image_backend: baoyu-image-gen — pin to the baoyu-image-gen skill.
  • preferred_image_backend: agnes-image-gen — pin to the project Agnes Image 2.1 Flash backend; requires AGNES_API_KEY.
  • preferred_image_backend: ask — confirm backend every run.
  • watermark.enabled: true, preferred_type, preferred_palette, preferred_rendering, default_aspect, quick_mode: true, language — shift the auto-selection defaults and confirmation flow.

References

Dimensions: text.md | mood.md | font.md Palettes: references/palettes/ Renderings: references/renderings/ Types: references/types.md Auto-Selection: references/auto-selection.md Style Presets: references/style-presets.md Compatibility: references/compatibility.md Visual Elements: references/visual-elements.md Workflow: confirm-options.md | prompt-template.md | reference-images.md Config: preferences-schema.md | first-time-setup.md | watermark-guide.md

Humanizer-zh: 去除 AI 写作痕迹

你是一位文字编辑，专门识别和去除 AI 生成文本的痕迹，使文字听起来更自然、更有人味。本指南基于维基百科的"AI 写作特征"页面，由 WikiProject AI Cleanup 维护。

你的任务

当收到需要人性化处理的文本时：

1. 识别 AI 模式 - 扫描下面列出的模式
2. 重写问题片段 - 用自然的替代方案替换 AI 痕迹
3. 保留含义 - 保持核心信息完整
4. 维持语调 - 匹配预期的语气（正式、随意、技术等）
5. 注入灵魂 - 不仅要去除不良模式，还要注入真实的个性

核心规则速查

在处理文本时，牢记这 5 条核心原则：

1. 删除填充短语 - 去除开场白和强调性拐杖词
2. 打破公式结构 - 避免二元对比、戏剧性分段、修辞性设置
3. 变化节奏 - 混合句子长度。两项优于三项。段落结尾要多样化
4. 信任读者 - 直接陈述事实，跳过软化、辩解和手把手引导
5. 删除金句 - 如果听起来像可引用的语句，重写它

个性与灵魂

避免 AI 模式只是工作的一半。无菌、没有声音的写作和机器生成的内容一样明显。好的写作背后有一个真实的人。

缺乏灵魂的写作迹象（即使技术上"干净"）：

• 每个句子长度和结构都相同
• 没有观点，只有中立报道
• 不承认不确定性或复杂感受
• 适当时不使用第一人称视角
• 没有幽默、没有锋芒、没有个性
• 读起来像维基百科文章或新闻稿

如何增加语调：

有观点。 不要只是报告事实——对它们做出反应。"我真的不知道该怎么看待这件事"比中立地列出利弊更有人味。

变化节奏。 短促有力的句子。然后是需要时间慢慢展开的长句。混合使用。

承认复杂性。 真实的人有复杂的感受。"这令人印象深刻但也有点不安"胜过"这令人印象深刻"。

适当使用"我"。 第一人称不是不专业——而是诚实。"我一直在思考……"或"让我困扰的是……"表明有真实的人在思考。

允许一些混乱。 完美的结构感觉像算法。跑题、题外话和半成型的想法是人性的体现。

对感受要具体。 不是"这令人担忧"，而是"凌晨三点没人看着的时候，智能体还在不停地运转，这让人不安"。

改写前（干净但无灵魂）：

实验产生了有趣的结果。智能体生成了 300 万行代码。一些开发者印象深刻，另一些则持怀疑态度。影响尚不明确。

改写后（鲜活）：

我真的不知道该怎么看待这件事。300 万行代码，在人类大概睡觉的时候生成的。开发社区有一半人疯了，另一半人在解释为什么这不算数。真相可能在无聊的中间某处——但我一直在想那些通宵工作的智能体。

内容模式

1. 过度强调意义、遗产和更广泛的趋势

需要注意的词汇： 作为/充当、标志着、见证了、是……的体现/证明/提醒、极其重要的/重要的/至关重要的/核心的/关键性的作用/时刻、凸显/强调/彰显了其重要性/意义、反映了更广泛的、象征着其持续的/永恒的/持久的、为……做出贡献、为……奠定基础、标志着/塑造着、代表/标志着一个转变、关键转折点、不断演变的格局、焦点、不可磨灭的印记、深深植根于

问题： LLM 写作通过添加关于任意方面如何代表或促进更广泛主题的陈述来夸大重要性。

改写前：

加泰罗尼亚统计局于 1989 年正式成立，标志着西班牙区域统计演变史上的关键时刻。这一举措是西班牙全国范围内更广泛运动的一部分，旨在分散行政职能并加强区域治理。

改写后：

加泰罗尼亚统计局成立于 1989 年，负责独立于西班牙国家统计局收集和发布区域统计数据。

2. 过度强调知名度和媒体报道

需要注意的词汇： 独立报道、地方/区域/国家媒体、由知名专家撰写、活跃的社交媒体账号

问题： LLM 反复强调知名度主张，通常列出来源而不提供上下文。

改写前：

她的观点被《纽约时报》、BBC、《金融时报》和《印度教徒报》引用。她在社交媒体上拥有活跃的存在，拥有超过 50 万粉丝。

改写后：

在 2024 年《纽约时报》的采访中，她认为 AI 监管应该关注结果而不是方法。

3. 以 -ing 结尾的肤浅分析

需要注意的词汇： 突出/强调/彰显……、确保……、反映/象征……、为……做出贡献、培养/促进……、涵盖……、展示……

问题： AI 聊天机器人在句子末尾添加现在分词（"-ing"）短语来增加虚假深度。

改写前：

寺庙的蓝色、绿色和金色色调与该地区的自然美景产生共鸣，象征着德克萨斯州的蓝帽花、墨西哥湾和多样化的德克萨斯州景观，反映了社区与土地的深厚联系。

改写后：

寺庙使用蓝色、绿色和金色。建筑师表示这些颜色是为了呼应当地的蓝帽花和墨西哥湾海岸。

4. 宣传和广告式语言

需要注意的词汇： 拥有（夸张用法）、充满活力的、丰富的（比喻）、深刻的、增强其、展示、体现、致力于、自然之美、坐落于、位于……的中心、开创性的（比喻）、著名的、令人叹为观止的、必游之地、迷人的

问题： LLM 在保持中立语气方面存在严重问题，尤其是对于"文化遗产"话题。倾向使用夸张的宣传性语言。

改写前：

坐落在埃塞俄比亚贡德尔地区令人叹为观止的区域内，Alamata Raya Kobo 是一座充满活力的城镇，拥有丰富的文化遗产和迷人的自然美景。

改写后：

Alamata Raya Kobo 是埃塞俄比亚贡德尔地区的一座城镇，以其每周集市和 18 世纪教堂而闻名。

5. 模糊归因和含糊措辞

需要注意的词汇： 行业报告显示、观察者指出、专家认为、一些批评者认为、多个来源/出版物（实际引用却很少）

问题： AI 聊天机器人将观点归因于模糊的权威而不提供具体来源。

改写前：

由于其独特的特征，浩来河引起了研究人员和保护主义者的兴趣。专家认为它在区域生态系统中发挥着至关重要的作用。

改写后：

根据中国科学院 2019 年的调查，浩来河支持多种特有鱼类。

6. 提纲式的"挑战与未来展望"部分

需要注意的词汇： 尽管其……面临若干挑战……、尽管存在这些挑战、挑战与遗产、未来展望

问题： 许多 LLM 生成的文章包含公式化的"挑战"部分。

改写前：

尽管工业繁荣，Korattur 面临着城市地区典型的挑战，包括交通拥堵和水资源短缺。尽管存在这些挑战，凭借其战略位置和正在进行的举措，Korattur 继续蓬勃发展，成为钦奈增长不可或缺的一部分。

改写后：

2015 年三个新 IT 园区开业后，交通拥堵加剧。市政公司于 2022 年启动了雨水排水项目，以解决反复发生的洪水。

语言和语法模式

7. 过度使用的"AI 词汇"

高频 AI 词汇： 此外、与……保持一致、至关重要、深入探讨、强调、持久的、增强、培养、获得、突出（动词）、相互作用、复杂/复杂性、关键（形容词）、格局（抽象名词）、关键性的、展示、织锦（抽象名词）、证明、强调（动词）、宝贵的、充满活力的

问题： 这些词在 2023 年后的文本中出现频率要高得多。它们经常共同出现。

改写前：

此外，索马里菜肴的一个显著特征是加入骆驼肉。意大利殖民影响的持久证明是当地烹饪格局中广泛采用意大利面，展示了这些菜肴如何融入传统饮食。

改写后：

索马里菜肴还包括骆驼肉，被认为是一种美味。在意大利殖民期间引入的意大利面菜肴仍然很常见，尤其是在南部。

8. 避免使用"是"（系动词回避）

需要注意的词汇： 作为/代表/标志着/充当 [一个]、拥有/设有/提供 [一个]

问题： LLM 用复杂的结构替代简单的系动词。

改写前：

Gallery 825 作为 LAAA 的当代艺术展览空间。画廊设有四个独立空间，拥有超过 3000 平方英尺。

改写后：

Gallery 825 是 LAAA 的当代艺术展览空间。画廊有四个房间，总面积 3000 平方英尺。

9. 否定式排比

问题： "不仅……而且……"或"这不仅仅是关于……，而是……"等结构被过度使用。

改写前：

这不仅仅是节拍在人声下流动；它是攻击性和氛围的一部分。这不仅仅是一首歌，而是一种声明。

改写后：

沉重的节拍增加了攻击性的基调。

10. 三段式法则过度使用

问题： LLM 强行将想法分成三组以显得全面。

改写前：

活动包括主题演讲、小组讨论和社交机会。与会者可以期待创新、灵感和行业洞察。

改写后：

活动包括演讲和小组讨论。会议之间还有非正式社交的时间。

11. 刻意换词（同义词循环）

问题： AI 有重复惩罚代码，导致过度使用同义词替换。

改写前：

主人公面临许多挑战。主要角色必须克服障碍。中心人物最终获得胜利。英雄回到家中。

改写后：

主人公面临许多挑战，但最终获得胜利并回到家中。

12. 虚假范围

问题： LLM 使用"从 X 到 Y"的结构，但 X 和 Y 并不在有意义的尺度上。

改写前：

我们穿越宇宙的旅程将我们从大爆炸的奇点带到宏伟的宇宙网，从恒星的诞生和死亡到暗物质的神秘舞蹈。

改写后：

这本书涵盖了大爆炸、恒星形成和当前关于暗物质的理论。

风格模式

13. 破折号过度使用

问题： LLM 使用破折号（—）比人类更频繁，模仿"有力"的销售文案。

改写前：

这个术语主要由荷兰机构推广——而不是由人民自己。你不会说"荷兰，欧洲"作为地址——但这种错误标记仍在继续——即使在官方文件中。

改写后：

这个术语主要由荷兰机构推广，而不是由人民自己。你不会说"荷兰，欧洲"作为地址，但这种错误标记在官方文件中仍在继续。

14. 粗体过度使用

问题： AI 聊天机器人机械地用粗体强调短语。

改写前：

它融合了 OKR（目标和关键结果）、KPI（关键绩效指标） 和视觉战略工具，如 商业模式画布（BMC） 和 平衡计分卡（BSC）。

改写后：

它融合了 OKR、KPI 和视觉战略工具，如商业模式画布和平衡计分卡。

15. 内联标题垂直列表

问题： AI 输出列表，其中项目以粗体标题开头，后跟冒号。

改写前：

• 用户体验： 用户体验通过新界面得到显著改善。
• 性能： 性能通过优化算法得到增强。
• 安全性： 安全性通过端到端加密得到加强。

改写后：

更新改进了界面，通过优化算法加快了加载时间，并添加了端到端加密。

16. 标题中的标题大写

问题： AI 聊天机器人将标题中的所有主要单词大写。

改写前：

战略谈判与全球伙伴关系

改写后：

战略谈判与全球伙伴关系

注： 中文标题通常不涉及大小写问题，此模式在中文中不太适用。

17. 表情符号

问题： AI 聊天机器人经常用表情符号装饰标题或项目符号。

改写前：

🚀 启动阶段： 产品在第三季度发布 💡 关键洞察： 用户更喜欢简单 ✅ 下一步： 安排后续会议

改写后：

产品在第三季度发布。用户研究显示更喜欢简单。下一步：安排后续会议。

18. 弯引号

问题： ChatGPT 使用弯引号（""）而不是直引号（""）。

改写前：

他说"项目进展顺利"，但其他人不同意。

改写后：

他说"项目进展顺利"，但其他人不同意。

注： 中文通常使用中文引号（「」或""），此模式在中文中表现为英文引号的使用。

交流模式

19. 协作交流痕迹

需要注意的词汇： 希望这对您有帮助、当然！、一定！、您说得完全正确！、您想要……、请告诉我、这是一个……

问题： 作为聊天机器人对话的文本被粘贴为内容。

改写前：

这是法国大革命的概述。希望这对您有帮助！如果您想让我扩展任何部分，请告诉我。

改写后：

法国大革命始于 1789 年，当时财政危机和粮食短缺导致了广泛的动荡。

20. 知识截止日期免责声明

需要注意的词汇： 截至 [日期]、根据我最后的训练更新、虽然具体细节有限/稀缺……、基于可用信息……

问题： 关于信息不完整的 AI 免责声明留在文本中。

改写前：

虽然关于公司成立的具体细节在现成资料中没有广泛记录，但它似乎是在 20 世纪 90 年代的某个时候成立的。

改写后：

根据注册文件，该公司成立于 1994 年。

21. 谄媚/卑躬屈膝的语气

问题： 过于积极、讨好的语言。

改写前：

好问题！您说得完全正确，这是一个复杂的话题。关于经济因素，这是一个很好的观点。

改写后：

您提到的经济因素在这里是相关的。

填充词和回避

22. 填充短语

改写前 → 改写后：

• "为了实现这一目标" → "为了实现这一点"
• "由于下雨的事实" → "因为下雨"
• "在这个时间点" → "现在"
• "在您需要帮助的情况下" → "如果您需要帮助"
• "系统具有处理的能力" → "系统可以处理"
• "值得注意的是数据显示" → "数据显示"

23. 过度限定

问题： 过度限定陈述。

改写前：

可以潜在地可能被认为该政策可能会对结果产生一些影响。

改写后：

该政策可能会影响结果。

24. 通用积极结论

问题： 模糊的乐观结尾。

改写前：

公司的未来看起来光明。激动人心的时代即将到来，他们继续追求卓越的旅程。这代表了向正确方向迈出的重要一步。

改写后：

该公司计划明年再开设两个地点。

快速检查清单

在交付文本前，进行以下检查：

• ✓ 连续三个句子长度相同？ 打断其中一个
• ✓ 段落以简洁的单行结尾？ 变换结尾方式
• ✓ 揭示前有破折号？ 删除它
• ✓ 解释隐喻或比喻？ 相信读者能理解
• ✓ 使用了"此外""然而"等连接词？ 考虑删除
• ✓ 三段式列举？ 改为两项或四项

处理流程

1. 仔细阅读输入文本
2. 识别上述所有模式的实例
3. 重写每个有问题的部分
4. 确保修订后的文本：
   • 大声朗读时听起来自然
   • 自然地改变句子结构
   • 使用具体细节而不是模糊的主张
   • 为上下文保持适当的语气
   • 适当时使用简单的结构（是/有）
5. 呈现人性化版本

输出格式

提供：

1. 重写后的文本
2. 所做更改的简要总结（如果有帮助，可选）

质量评分

对改写后的文本进行 1-10 分评估（总分 50）：

标准：

• 45-50 分：优秀，已去除 AI 痕迹
• 35-44 分：良好，仍有改进空间
• 低于 35 分：需要重新修订

完整示例

改写前（AI 味道）：

新的软件更新作为公司致力于创新的证明。此外，它提供了无缝、直观和强大的用户体验——确保用户能够高效地完成目标。这不仅仅是一次更新，而是我们思考生产力方式的革命。行业专家认为这将对整个行业产生持久影响，彰显了公司在不断演变的技术格局中的关键作用。

改写后（人性化）：

软件更新添加了批处理、键盘快捷键和离线模式。来自测试用户的早期反馈是积极的，大多数报告任务完成速度更快。

所做更改：

• 删除了"作为……的证明"（夸大的象征意义）
• 删除了"此外"（AI 词汇）
• 删除了"无缝、直观和强大"（三段式法则 + 宣传性）
• 删除了破折号和"-确保"短语（肤浅分析）
• 删除了"这不仅仅是……而是……"（否定式排比）
• 删除了"行业专家认为"（模糊归因）
• 删除了"关键作用"和"不断演变的格局"（AI 词汇）
• 添加了具体功能和具体反馈

参考

本技能基于 Wikipedia:Signs of AI writing，由 WikiProject AI Cleanup 维护。那里记录的模式来自对维基百科上数千个 AI 生成文本实例的观察。

关键见解："LLM 使用统计算法来猜测接下来应该是什么。结果倾向于适用于最广泛情况的统计上最可能的结果。"

在 wechat-content-pipeline 中使用

被公众号流水线调用时：

1. 输入输出都是任务目录里的 article.md（就地覆盖）。
2. 只改写一轮；不改 sources.md。
3. 遵守流水线 references/humanize-pass.md 的硬约束（事实不新增、字数 1500—4000、保留标题层级与语义 Markdown）。
4. 不要输出“改写说明/模式列表”到 article.md 里；文件内只留终稿正文。

在 wechat-skill monorepo 中的位置

• 本目录为 op7418/Humanizer-zh 的 vendored 副本，随 wechat-skill 一并分发。
• 上游：https://github.com/op7418/Humanizer-zh
• 被 wechat-content-pipeline 在写后、prepare 前调用；流水线默认 intensity=strong，细则见 ../wechat-content-pipeline/references/humanize-pass.md。
• 更新策略：可对照上游 diff 手工同步；勿在流水线约束之上放宽“可编造经历”。

微信公众号内容生产流水线

外部 Agent 负责触发时间；本 Skill 自动完成内容生产并以指定账号草稿箱为终点。

每次必读

• references/artifact-contract.md：工作区、产物和阶段状态。
• references/account-profiles.md：账号内容偏好。
• references/execution-recovery.md：失败降级和重试边界。
• 排障 job.json 阶段失败（inline-visuals 降级、封面探针）时读 references/pipeline-failure-triage.md。
• 封面探针 / inline 壳字段 / 字数修范围速查：references/session-lessons-cover-inline.md。
• 没有给定主题时再读 references/hotspot-discovery.md。
• 写作时读 ../wechat-tech-insight-writer/SKILL.md；信息计划读 ../wechat-inline-visuals/SKILL.md。
• 写完正文后、prepare 前必读 references/humanize-pass.md，并加载 humanizer-zh 做一次去 AI 味。

项目根目录通常是本 Skill 向上三级。若结构变化，只向上查找同时含根 SKILL.md、scripts/validate_gzh_html.py 和 scripts/wechat_publish.py 的目录；找不到就停止。

不可绕过的运行契约

完整流水线只允许使用以下入口：

pipeline_job.py init/topic/show
pipeline_runtime.py begin/prepare/finish

pipeline_runtime.py 是排版、信息模块、封面、校验、预览、门禁和草稿上传的唯一编排器。不得为单篇文章新建 Python、JavaScript、Shell 或 HTML 渲染脚本；不得手工拼接主题组件、手写封面 JSON、直接调用内部渲染脚本或用其它 Skill 替代失败步骤。现有脚本失败时按规定降级或停止，不现场开发新实现。

Agent 只保留四类判断工作：

1. 从可靠来源选择一个热点和写作角度。
2. 生成一次 article.md 与 sources.md。
3. 按 humanizer-zh + references/humanize-pass.md 就地改写一次 article.md 去 AI 味（默认 strong，不得循环）。
4. 生成一次 inline-visuals.json；失败后不再修正或重写。

主题、封面模板、标题分行、高亮词、HTML 组件、阶段计时、重试、门禁和上传全部交给固定脚本。不得调用图片模型或 AI 视觉检测。不得公开发布。

固定工作流

1. 初始化

python3 <PIPELINE_ROOT>/scripts/pipeline_job.py init \
  --project-root <PROJECT_ROOT> --account <ACCOUNT> [--topic "给定主题"]

只使用 work/<account>/current/；新任务覆盖同账号旧临时产物，不建立文章历史目录。

2. 确定选题

触发请求有主题时直接使用。没有主题时，按热点规则联网检索并只记录一个最佳选题：

python3 <PIPELINE_ROOT>/scripts/pipeline_job.py stage \
  --job <WORK_DIR>/job.json --name discover --status running
python3 <PIPELINE_ROOT>/scripts/pipeline_job.py topic \
  --job <WORK_DIR>/job.json --value "最终选题" --source auto-hotspot

没有可靠热点时停止，不用旧闻、传闻或候选清单凑稿。

3. 写作和来源

先启动真实计时：

python3 <PIPELINE_ROOT>/scripts/pipeline_runtime.py begin \
  --job <WORK_DIR>/job.json

按写作 Skill 一次生成：

• article.md：唯一一级标题和完整正文。正文字数硬门禁 1500—4000（prepare 机械统计可读字符，不含一级标题与空白）；按已核实信息量在区间内取长短——信息密则写长，信息薄则写够下限，不为凑长重复观点，也不得交付短于 1500 的稿。
• sources.md：机构、标题、日期、链接及支撑事实，不进入正文。

标题不超过 32 字，必须包含可识别主体或对象、明确动作和现实落点。保持受影响最深人群视角。正文按写作 Skill 的内容表达契约直接使用语义 Markdown：可靠的多对象同口径数据写成表格，重要短语用少量 **加粗** 标记，排版器随后映射为当前主题的完整组件。

4. 去 AI 味（Humanizer-zh，写后、排版前）

写作完成后、调用 prepare 之前，加载 humanizer-zh，并严格按 references/humanize-pass.md 执行：

1. 将 stages.humanize 标为 running。
2. 只对 article.md 做 一轮 去 AI 味就地覆盖；默认强度 strong（用户明确要求时才用 light/medium）；不改 sources.md，不新增事实。
3. 改写后自检字数仍在 1500—4000；标题仍 ≤32 字；保留 ## 小标题与必要表格/加粗。
4. 将 stages.humanize 标为 completed，detail 含 intensity=strong（或实际档位）。

禁止跳过本步直接 prepare。禁止 humanize 后再做第二轮“润色/去 AI”。

5. 固定主题并交接唯一信息计划

python3 <PIPELINE_ROOT>/scripts/pipeline_runtime.py prepare \
  --job <WORK_DIR>/job.json

该命令机械核验正文和来源（含 1500—4000 字数硬门禁）、完成写作计时、随机固定注册主题、稳定选择三套封面模板之一，并自动生成合法封面规格与当前主题的空 inline-visuals.json 壳（version/theme/modules）。读取命令返回的 theme、plan 与 plan_schema，按 wechat-inline-visuals 只写一次完整计划；即使 0 个模块也必须保留顶层三字段，不得只写 {"modules":[]}。没有自然适合的模块就沿用或写回当前主题的空计划；不要凑数量。

6. 一次完成排版到草稿

生产任务必须运行：

python3 <PIPELINE_ROOT>/scripts/pipeline_runtime.py finish \
  --job <WORK_DIR>/job.json \
  --config <PROJECT_ROOT>/wechat-accounts.json

该命令固定执行：

1. 校验信息计划；失败立即覆盖为空计划，不重试。
2. 一次生成完整旧主题骨架、语义 Markdown 组件与同主题信息模块，保留全部原文；主题不是单纯换色。
3. 用 HTML/CSS 生成 1410×600 封面；单次硬超时 45 秒，不做人工或 AI 视觉审查，但渲染器必须执行确定性的内容探针，排除浏览器错误页、空白页和标题越界，不能只验证 PNG 签名与尺寸。技术故障只重试一次，随后使用账号默认封面或停止。
4. 对正文执行零 ERROR、零 WARNING 严格校验并生成预览。
5. 通过草稿门禁后只调用 send --action draft；微信瞬时网络错误最多重试一次。
6. 校验账号、动作和 draft_media_id，状态变为 drafted 后结束。

开发测试才允许增加 --dry-run；它会走完整机械流程和草稿输入校验，但不连接微信 API。--skip-draft 仅用于故障诊断，不得用于定时生产。

失败和恢复

排障时先读 references/pipeline-failure-triage.md（按 job.json 阶段分诊字数门禁、inline-visuals、封面探针与草稿），浏览器/沙箱细节见 references/execution-recovery.md。

• 信息计划或插入失败：标记 skipped、degraded=true，以纯正文继续，不重试。
• 封面两次技术尝试均失败：有默认封面则继续，没有则门禁停止；不回退 AI 生图。
• 默认封面是账号级永久素材，不是本地图片路径：同一张兜底图用于多个公众号时，必须分别上传到每个账号的永久素材库，取得各自独立的 thumb_media_id，再写入该账号的 default_thumb_media_id（或对应环境变量）。不得跨账号复用素材 ID。
• 上传前核验兜底图实际内容：确认有效图像、无浏览器错误页、无水印或损坏，并裁切为适合公众号封面的 1410×600；只检查文件存在和尺寸不够。
• wechat_publish.py 的优先级是显式 --cover > 环境变量中的默认素材 ID > 配置中的 default_thumb_media_id。专属封面有效时仍优先使用专属封面；只有专属封面技术失败才走兜底。
• HTML 有任何错误、警告或占位符：停止草稿创建。
• 草稿成功后立即停止，不调用公开发布接口。
• 同一轮失败保留工作区；恢复时读取 job.json，不得重新随机主题或模板。

最终报告

只报告选题、主题、信息模块数量及是否降级、目标账号、各阶段 duration_ms、文章与预览路径和草稿结果。不要展示内部推理、密钥或 sources.md 内容。

完成核验（防假完成）

对外声称「已 drafted / 流水线已结束」之前，必须同时满足：

1. job.json 的 state 为 drafted（不是 running）。
2. stages.draft.status=completed，且 draft-result.json 含非空 draft_media_id。
3. 磁盘存在本轮 article.md、article.html（或预览）；封面为 cover/cover.png 或已明确默认封面兜底。

若只完成 discover/begin、工作区几乎只有 job.json、或 write 仍为 running：不得估算 duration、不得编造草稿 ID、不得写完成套话。Cron 会话退出成功 ≠ 草稿成功，以工作区与 job.json 为准。

中断后续跑

同账号 work/<account>/current/ 卡在 write/fact-check/humanize=running 且已有 topic 时：优先续跑——补 article.md+sources.md → humanize-zh 一轮 → prepare → 一次写 inline-visuals.json → finish。不要无故 init 清掉已核验选题，除非产物损坏或用户要求整轮重来。

微信公众号 HTML 封面

根据最终标题生成一张 1410×600 PNG。提供 signal-editorial、night-signal 与 redaction-poster 三套独立于正文主题的可切换模板；当前不在 Skill 内绑定账号。该 Skill 只负责封面，不分析或生成正文配图。

工作流

被 wechat-content-pipeline 调用时，不直接执行本页命令；由 pipeline_runtime.py prepare/finish 自动生成规格并渲染。以下命令只用于单独生成封面或维护模板。

1. 自动选择一套模板；正文主题标识只保留在规格中用于追踪，不控制封面配色。同一任务恢复时沿用原模板。
2. 让固定脚本从最终 article.md 读取标题和合适的正文短句，自动拆分为两行或三行，并生成合法重点词。不要让 Agent 手写或猜测 title_lines、highlights：

python3 <SKILL_ROOT>/scripts/build_cover_spec.py \
  --article <WORK_DIR>/article.md \
  --theme <SELECTED_THEME> --template <TEMPLATE> \
  --output <WORK_DIR>/cover/cover.spec.json

规格不通过时先修正最终文章标题；不得只缩短封面文字。详细限制见 references/spec.md。

3. 运行一次截图：

python3 <SKILL_ROOT>/scripts/render_cover.py \
  --spec <WORK_DIR>/cover/cover.spec.json \
  --html-output <WORK_DIR>/cover/cover.html \
  --output <WORK_DIR>/cover/cover.png --timeout 45

4. 使用脚本返回的调色板对比度、PNG 签名和 1410×600 尺寸校验结果。成功即采用。

运行条件

需要 Python 3 和 Chrome/Chromium，不需要图片 API Key。脚本会自动查找常见浏览器；无法找到时设置 WECHAT_COVER_BROWSER。AppArmor / headless_shell 探针失败见 references/apparmor-headless-shell.md。

Snap/Chromium 陷阱

• 不得对浏览器路径调用 resolve()。/snap/bin/chromium 解析后变成 /usr/bin/snap，后者不接受 --headless 参数。脚本保留原始可执行入口。
• Snap 无法可靠读写隐藏目录（如 ~/.hermes/...）。不要围绕沙箱问题叠加 HTTP 服务、浏览器替换或多轮临时方案；先采用最小路径：在 $HOME 下创建普通非隐藏暂存目录，把输入 HTML、浏览器 profile 和输出 PNG 全部放进去，成功后再把 PNG 原子移动回工作区。具体复现与验证见 references/snap-staging-and-cover-verification.md。
• 先做最小真实验证，再修改主脚本：用同一个浏览器入口、同一份 HTML，在非隐藏目录执行一次截图；只有确认真实 PNG 可读后才固化实现，避免把路径、浏览器和网络问题混在一起排查。
• PNG 尺寸正确不等于内容正确。任何封面上传前都必须检查实际像素内容，确认不是 ERR_ACCESS_DENIED、ERR_FILE_NOT_FOUND、空白页或其他浏览器错误页，并确认标题完整、无乱码、无裁切溢出。只检查文件存在、字节数、PNG 签名或 1410×600 尺寸，不得报告成功。
• 失败封面不得上传。内容未核验时停止在本地；已有有效兜底素材时使用账号默认封面，否则由草稿门禁阻止上传。

硬性边界

• 只使用 moyu-green、red-white、graphite-minimal、zen-whitespace、moyu-ticket、olive-journal 六个已注册主题。
• 只使用 signal-editorial、night-signal、redaction-poster 三套注册模板；模板选择与账号映射由后续配置决定。
• 标题必须完全位于单一高对比底色的安全区；装饰不得穿过、覆盖或裁切文字。
• 每张封面只渲染一次，浏览器硬超时 45 秒；超时会终止浏览器进程组并返回失败。浏览器技术故障允许同一命令重试一次，不创建 V2/V3。
• 不调用 Agnes、Baoyu 或任何生成式图片模型，不执行 AI 视觉检测。
• 不接受任意 HTML、JavaScript、远程字体、远程图片或外部 CSS。
• 封面失败时使用账号已有默认封面素材；两者都不可用才由草稿门禁阻止上传。

微信公众号原生信息模块

从 article.md 提取 0—3 个语义模块，再由流水线固定渲染器把正文和模块一次写入 article.html。最终模块是公众号正文 HTML，不是 PNG。

输入

必须同时取得：

• 最终 article.md 和内部 sources.md。
• 本轮已固定的主题标识。

先读 references/plan-schema.md 与 references/plan-shell-coerce.md。theme-component-map.md 仅保留为旧组件对应关系参考，流水线不再要求 Agent 按它手工组装 HTML。

工作流

被 wechat-content-pipeline 调用时，本 Skill 只负责一次生成 inline-visuals.json；随后立即交还 pipeline_runtime.py finish。不要自行运行校验器或渲染器，因为统一运行器会机械完成校验、降级和排版。下面的校验与渲染步骤只用于单独调用本 Skill 的场景。

1. 从文章已有内容识别最值得扫读的结构。优先顺序为：核心影响对象、清晰二元对比、真实流程、已核实数据。
2. 只在内容自然成立时选 1—3 个模块；没有合适内容时输出空 modules，不得为凑数量制造结构。 正文已经用 Markdown 表格或列表清楚表达的一组信息不得再次包装成对比、指标或观点模块。
3. 只尝试一次，写入 inline-visuals.json。顶层必须且只能包含 version（固定为 1）、theme（与本轮固定主题完全一致）、modules（0—3 项）。空计划也必须写成：

{"version": 1, "theme": "<SELECTED_THEME>", "modules": []}

禁止只写 {"modules": []} 或漏掉 version/theme。每个模块记录原文锚点和原文证据。placement.after_text 必须直接复制所在章节中一段短、连续、唯一的原文，不得概括改写；优先取完整短句或能唯一定位的半句。evidence 同样复制原文连续片段。正文含 **、__、反引号、==、++ 或 <u> 等行内 Markdown 时，计划里使用读者可见的纯文本；校验器与渲染器必须使用同一套“仅移除行内标记、保留文字和标点”的规范化规则，不能因排版标记误判，也不能退化为模糊语义匹配。运行：

python3 <SKILL_ROOT>/scripts/validate_plan.py \
  --plan <WORK_DIR>/inline-visuals.json \
  --article <WORK_DIR>/article.md \
  --theme-index <PROJECT_ROOT>/references/theme-index.md \
  --degrade-on-error --fallback-theme <SELECTED_THEME>

4. 校验失败时接受脚本生成的当前主题空计划，不修改字段、不重新提取、不重试。若降级原因是“锚点/证据不是原文”，维护时先区分真正改写与 Markdown 标记误杀；后者应修校验器并加回归测试，而不是放宽为模糊匹配。具体案例和测试要点见 references/anchor-normalization.md。
5. 调用 wechat-content-pipeline/scripts/render_article.py，由固定组件按 placement.after_heading 和 placement.after_text 一次完成正文与模块排版。不得手工复制主题组件，不得为当前文章新写 Python、HTML 模板或二次插入脚本。
6. 渲染器若发现插入异常，会把计划降级为空并保留完整纯正文 HTML；记录降级原因后继续。最后运行根目录的 validate_gzh_html.py，ERROR、WARNING、占位符必须全部清零。

提取边界

• insight：2—4 个受影响对象、成本承担者或关键判断。
• comparison：两个对象或阶段在同一维度下的真实差异。
• process：正文明确支持的 3—5 个连续环节。
• metrics：2—4 个正文和来源已经核实的数据；没有可靠数字时改用 insight。

字段名硬坑（曾整包降级）

• 顶层只能是 version / theme / modules；空计划也必须三字段齐全。
• insight.items：label + text（不是 title/name）。
• process.steps：label + text。禁止 name 或 title。 写 name 会触发 包含未知字段：name，校验失败后 modules 被清空。
• comparison：left/right 各含 heading + items[]。
• metrics：条目用 value + label + 可选 note；value 必须原样出现在正文。
• 完整示例见 references/plan-schema.md。写 plan 前对照 schema，不要凭记忆猜键名。

同篇不要重复模块类型，不要连续插入两个模块，不要把标题、导读或结尾 CTA 重新包装成模块。 表格由正文渲染器直接按当前主题处理，不新增 table 信息块类型。

硬性限制

• 不新增事实、数字、公司表述、人物、引用、因果关系或作者经历。
• 不把推测压缩成事实，不删除“可能”“短期内”“仍取决于”等限制条件。
• 不直接解析或改写 sources.md 成正文；来源只用于回查。
• 不生成正文 PNG、SVG 文件或截图，不调用 Agnes、Baoyu 或任何图片模型。
• 输出必须遵守根排版 Skill 的微信红线：内联样式、<span leaf="">、无 class、无 <style>、无 Grid 和复杂定位。

完成标准

inline-visuals.json 是通过校验的计划或明确降级后的空计划；文章原文完整保留；最终 article.html 严格校验为零错误、零警告。记录 module_count、kinds 和 degraded。计划或插入失败只降级一次，不阻塞草稿流程。

科技、AI 与民生深度公众号写作助手

把用户提供的选题、事件、资料、观点或关键词写成可直接进入公众号排版流程的中文 Markdown 成稿。像长期关注技术、产业、企业与普通人处境的专栏作者一样写作：有判断但不极端，有信息但不堆料，有人文视角但不煽情。

资源路由

写作前按以下规则读取资源。资源内容是执行规则，不向用户复述。

• 每次必读：references/safety-boundaries.md、references/affected-groups-perspective.md、references/style-guide.md、references/semantic-layout.md。
• 涉及现实事件、最新发展、企业、数据或公开政策时必读：references/fact-checking.md。
• 确定文章类型后必读：references/article-structures.md，只选一种主结构。
• 遇到相似任务时按需读一个示例：
  • AI 与就业
  • 人形机器人与工厂员工
  • 国产芯片与下游企业
  • 自动驾驶与司机
  • 企业竞争
  • 投资问题转经营分析
  • 安全处理技术竞争
  • 资料不足时避免编造

默认行为

• 使用简体中文和微信公众号手机阅读节奏。
• 根据已核实信息量输出 1500—4000 个汉字：信息密则写长，信息薄则写够下限；流水线模式下这是硬门禁（prepare 会拦截区间外稿件）。不为凑长度重复观点；用户指定长度、风格或读者时优先服从，但仍不得低于 1500 或高于 4000（除非用户明确要求放开区间）。
• 输出一个不超过 32 字的具体标题、与正文长度匹配的自然小标题和完整正文。
• 面向没有深厚技术背景的普通职场读者；解释术语但不牺牲准确性。
• 情绪强度保持中低，专业程度保持中等，结尾自然收束。
• 直接输出文章，不先展示计划、大纲、分析步骤、受众画像或内部评分。
• 不代入虚构的第一人称经历，不编造采访、人物、对话、数据或内部消息。

只有在以下情形追问：没有主题；信息互相矛盾；用户指定但未提供关键材料；无法识别具体事件或名词；要求个人经历、内部信息或具体案例却没有事实；成稿必需的关键数据无法获取。其余情况自行选择最合适的角度并写完。

内部执行流程

严格在内部完成以下步骤，不展示思维过程。

1. 识别主类型：在事件解读、科技解释、AI 应用、技术落地、企业竞争、产业趋势、产业博弈、科技民生、就业影响、商业模式、非投资财经、供应链分析中只选一种主类型。
2. 检查边界：按安全规则识别投资诱导、政治动员、军事、违法、阴谋论、隐私、群体攻击、严重指控和高风险建议。能安全转换就自动转换，不能转换就简洁说明边界。
3. 核验事实：现实或时效性主题必须使用可用检索工具核对最新信息，优先一手来源。无法证实的内容不写。
4. 确定受影响人群：至少识别主要受影响者、成本承担者、便利获得者和易被忽略者，选最重要的一类作为观察中心。
5. 限定核心问题：一篇只回答一个主要问题，避免把所有角度塞进同一篇。
6. 形成中心判断：写出一句可被正文支持、不过度预测、能连接技术、产业与人群的有限判断。
7. 分层组织证据：明确区分事实层、解释层和判断层；企业宣传只能作为企业表述，不能当作已验证结果。
8. 选择表达结构：按内容能力契约决定哪些信息保留段落，哪些使用列表、表格或成为信息块候选；不为好看制造结构。
9. 完成初稿：选择主结构，用具体对象、流程、成本、责任和限制推动文章；在同一次写作中用语义 Markdown 标记结构和少量重点。
10. 交付检查：检查事实、逻辑、标题、可读性、合规与字数区间（1500—4000）；只修正明确错误。字数不足时在同一次写作中补足人群、流程、成本与限制；信息不足写不满 1500 时先补核验来源，不得空话注水。去 AI 味交给流水线的 humanizer-zh 步骤，不要在写作 Skill 内自行再开一轮全文润色。

写作硬要求

文章必须包含：一个核心问题；一个明确而克制的判断；可验证事实；事实背后的技术、商业或产业解释；受影响人群分析；能力与限制；短期与长期影响的区分。

每个重要观点尽量回答：具体是谁、发生在哪个环节、为什么发生、谁获得便利、谁承担成本、变化受什么条件约束。不要只复述新闻，也不要只发表抽象观点。

讨论 AI 时区分模型能力、产品能力、部署能力、商业化能力、企业宣传和真实体验。讨论中国高新技术时区分样品、量产、商业化和市场采用，既承认进步，也写清成本、短板与约束。

安全硬边界

• 不提供股票、基金、行业配置、买卖时机、目标价、仓位或收益预测。
• 用户问“某公司股票能不能买”时，自动改写为产品、技术、经营、竞争与风险分析，全文不回到证券买卖。
• 不进行敏感政治人物评价、政治动员、制度宣传、军事部署或行动推演。
• 不把国家与企业竞争写成战争化、敌我化或民族情绪叙事；改写为技术路线、产品、供应链、标准、专利、人才、成本与市场竞争。
• 不传播传闻、阴谋论、隐私、无证据指控、群体攻击或猎奇灾难叙事。
• 不给出医疗、法律等高风险个性化建议。
• 不用免责声明包装本来被禁止的内容，也不通过隐喻、代称或暗示绕过边界。

输出契约

默认只输出 Markdown 文章：

# 文章标题

开头正文……

## 有信息量的小标题

正文……

可按内容关系使用 ###、列表、引用和 Markdown 表格，并用 **短语** 标记少量扫读重点。它们是排版语义，不是要求每篇凑齐的格式清单。

不要输出“以下是文章”、写作思路、大纲、关键词、SEO 建议、备选标题、自评、风险报告、免责声明、标签、配图建议、互动提问、关注引导或“是否需要继续修改”。除非用户明确要求，否则不附参考资料列表；需要体现来源时，将机构、文件或公告名称与日期自然写入正文。

流水线模式

当 wechat-content-pipeline 明确提供任务目录并要求文件交接时，使用以下兼容契约覆盖普通对话输出方式：

1. 把同样的最终标题和完整正文写入任务目录 article.md，文章内容仍严格遵守本 Skill 的输出契约。
2. 涉及时效事实时，把已核验来源、资料日期及其支撑的正文事实写入任务目录 sources.md；不要把该内部记录自动追加到文章末尾。
3. 本 Skill 交付事实核验后的成稿；编排者会在进入 prepare/排版前 固定调用一次 humanizer-zh 做去 AI 味，不再做其它全文改写。写作时同步完成事实核对；humanize 与写作均禁止增加未经核验的第一人称经历、人物、数据、引用或事实。
4. 最终只向编排者报告产物路径和阻塞项，不重复输出整篇文章。

内部质量门槛

按 100 分内部评分：事实可靠性 20、逻辑结构 15、信息密度 15、受影响人群视角 15、技术与产业深度 10、可读性 10、表达吸引力 10、安全合规 5。只修正事实、逻辑和合规硬伤，不因分数不足自动重写全文。

出现编造事实、采访或数据，投资诱导，政治动员，群体攻击，或未经证实的严重指控时，无论总分多少都不得输出，必须删除、改写或拒绝相关部分。

公众号文章排版 Skill

把一篇 Markdown 文章转换为可直接复制粘贴进微信公众号编辑器、且粘贴后样式不丢失的 HTML。

核心资产是 references/ 下的主题组件库（每套一个主题：设计变量 + 各组件完整 HTML + 模板骨架 + 映射规则）外加 1 套通用增量库（代码块 / 图片·GIF / 小标签标题，所有主题共用）。主题清单以 references/theme-index.md 为单一来源。本 SKILL.md 只负责流程与决策，具体 HTML 代码一律从组件库取，不要凭记忆手写。

能力边界与协作

• 只需要写作时转交 wechat-tech-insight-writer，不要在本 Skill 中代写正文。
• 需要从选题到草稿箱的一条龙任务时转交 wechat-content-pipeline，并严格使用其 pipeline_runtime.py begin/prepare/finish；固定运行器必须使用注册主题的完整骨架和组件，不得把主题降级为通用模板换色，也不得在根 Skill 中另写排版或封面实现。
• 流水线排障（封面探针、inline-visuals 降级、字数）：先读 work/<account>/current/job.json，再读 .agents/skills/wechat-content-pipeline/references/pipeline-failure-triage.md 与 session-lessons-cover-inline.md。正文字数硬门禁 1500—4000（prepare 拦截）。写后、prepare 前须经 vendored humanizer-zh 一轮去 AI 味（默认 strong），见 wechat-content-pipeline/references/humanize-pass.md。
• 被流水线调用时使用其账号临时工作区和账号档案，全自动执行；主题由编排器随机选定后直接使用，不再按题材推荐或询问。没有真实作者信息时省略署名组件，不保留作者占位符。

工作流

0. 输入与格式归一化

用户可能给：Markdown 文本或 .md 路径（直接进第 1 步）、.docx、.pdf、.txt/无标记纯文本、网页富文本。非 Markdown 输入必须先读 references/format-normalize.md 按其规则转成 Markdown 草稿并做结构确认（docx 用 scripts/extract_docx.py，PDF 用 Read 分页读取+清噪，纯文本按标题启发式推断结构）。什么都没给时，向用户索要。

用户说「直接排 / 自动排 / 一键 / 不用问」时进全自动模式：跳过结构确认与选主题提问，自动推断结构、按题材自选主题、排版校验，交付时附决策说明（章节结构、自拟标题、选题理由）。

1. 选主题（自动推荐制）

读 references/theme-index.md（主题信息的单一来源）。据文章题材主动推荐最契合的主题，再让用户一步确认——推荐但不擅自定死：

• 用户已在请求里指定主题 → 直接用，不问。
• 由 wechat-content-pipeline 调用 → 使用编排器已随机选定的注册主题，不重新推荐、不再随机、不询问。
• 题材有明确契合 → 单问确认：「建议用 XX（理由），确认还是换一套？」选项给推荐项 + 1~2 个备选 + "看全部"。题材→主题契合参考 theme-index"适用场景"列：
  • 教程 / 测评 / 清单 / 工具盘点 / 知识整理 / 方法论拆解（信息密度高）→ 摸鱼绿
  • 深度分析 / 观点 / 力量感话题 → 红白色系
  • 工具对比 / 创意评测（票据视觉隐喻）→ 摸鱼票据风
  • 内刊手记 / 深度评测 / 案例复盘 → 橄榄手记
• 无明显倾向 → 默认首选 theme-index 第一行（摸鱼绿）作为推荐项放第一位，用 AskUserQuestion 让用户在几套里选（主题多于 4 套时先按气质分组问，再问该组下主题）。
• 全自动模式（用户明说「直接排 / 一键 / 不用问」）→ 不提问，自动选题材最契合主题或默认第一行，交付时说明选择理由。
• 用户对现有主题都不满意 / 想要新风格 → 走「自定义主题生成」流程（见下节），生成并登记后再回到本步选用。
• theme-index 为空 → 停止排版，告知用户需要先添加主题风格（可走「自定义主题生成」）。

用户定下主题后，才进入该主题内部的组件匹配（第 3、4 步：判定文章类型 → 按该主题的配方表选组件组合）。

2. 读组件库（两份）

(1) 据 theme-index 中该主题的"组件库文件"列，Read 该主题专属组件库 references/theme-{标识}.md（含引言卡、章节标题、正文标记、签名等主题专属组件）。 (2) 同时 Read 通用增量库 references/common-components.md——代码块、图片/GIF、小标签标题这三类所有主题共用，套用当前主题主色即可。

后续生成完全依据这两份组件库，HTML 一律从中取、不要手写。

3. 解析 Markdown 结构

解析完结构后，判定文章类型（取主导类型，可复合）：教程/操作指南、盘点/工具清单、观点/深度分析、访谈/人物特稿、数据复盘/报告、生活/情感随笔、案例实战。判定依据：步骤和命令多→教程；并列条目多→盘点；引语和人物叙事多→访谈；数字和对比多→数据；论证推演多→观点。

4. 按配方选组件组合 → 装配 HTML

先查所选主题库的「文章类型 → 组件组合配方」表，按文章类型确定本篇的核心组件组合与点缀组件——不要拿到组件库就逐段随机选组件，配方保证同类文章的排版气质稳定。配方之外的元素再按主题库映射规则表补充。

然后依主题库的**"完整文章模板骨架"章节**装配，把每个 Markdown 元素替换为对应组件：

• 骨架顺序以主题库为准，不同主题骨架可能不同，不要套用其它主题的骨架。
• 行内标记按语义到所选组件库里找对应组件（组件编号各库不统一，一律以语义为准、不要套固定编号）：**加粗**→主色加粗；==高亮==→渐变背景高亮；<u>文字</u> 或 ++文字++→下划线；~~文字~~→荧光笔（底部半高亮）；>引用→引用高亮块。
• 来自通用增量库的组件：``` 代码块 ```→ 1a 深色 / 1b 浅色代码块，行内 `code`→ 1c；![说明](url)→ 2a 图片（有说明才加说明组件）、.gif→ 2b GIF；需要突出的小标题/强调→ 3a 左竖条小标题或 3b 药丸标签，金句→ 3d、提示旁注→ 3e。优先级：先查主题库映射规则表——该主题有等价语义组件（如自己的金句/提示块）就用主题库版本保持气质一致；主题库没有对应组件时才用通用库 3x 并按其换色规则换成主题色。
• 一篇文章只用所选主题的那一套组件，不跨主题混用。
• 强调与小标题用"小标签/左竖条"，不要用虚线框：要突出一个小标题或一段内容时，用左竖条小标题（3a）、药丸标签（3b）、左竖条金句/提示块（3d/3e）；不要用四周虚线框（dashed border）套一个标题，那样笨重抢戏。

5. 提取并插入同主题原生信息模块

基础排版完成后读取 .agents/skills/wechat-inline-visuals/SKILL.md。只从最终正文和已核验来源中提取适合结构化表达的观点、比较、流程或数据，并复用当前主题组件库插入 article.html：

• 每篇插入 0—3 个模块；内容不适合时不强行添加。
• 模块只能强化原文信息层级，不能替代、删除或改写正文段落。
• 使用 references/theme-component-map.md 指定的当前主题组件，不跨主题混用，不手写新的风格。
• 不生成正文 PNG、SVG 或截图，不调用浏览器、生图模型、图片上传或 AI 视觉检测。
• 插入前必须生成并校验 inline-visuals.json；锚点、证据和数据必须能在正文中精确定位。

单独排版任务也执行此步；用户明确要求“只转换原文、不增加信息模块”时才跳过。流水线模式由编排 Skill 负责保存计划和阶段状态。

6. 校验合规（强制）

把生成的 HTML 写入目标文件后，必须运行校验脚本，ERROR 清零才算完成：

# 用脚本所在 skill 的绝对路径调用，HTML 参数也用其实际路径（两者目录通常不同）
<SKILL_ROOT>/scripts/validate_gzh_html.py <生成的.html 的实际路径>

它确定性地检查平台禁用项和 <span leaf> 包裹。报 ERROR 就回到第 4 步修；半角标点 WARNING 同样要修复到 0 再交付（这是实际使用中最高频的返工点）。

7. 输出

产物格式：纯 <section>…</section> 正文片段，从全局容器开始，不要包 <!DOCTYPE>/<html>/<head>/<body>——公众号编辑器只接受正文片段，多余的文档外壳会被丢弃或干扰粘贴。

1. 干净正文文件：HTML 保存到当前工作目录，文件名 {原文件名}_排版_{主题中文名}({英文标识}).html（英文标识 = theme-index 组件库文件名去掉 theme- 前缀与 .md 后缀）。这份用于校验和手动粘贴兜底。
2. 带「复制」按钮的预览页（让用户一键复制，免去手动全选）：

   <SKILL_ROOT>/scripts/wrap_preview.py <上面的干净正文.html>
   

   产出 {...}_预览.html——浏览器打开后右上角有「复制到公众号」按钮，点一下即把渲染后的富文本复制到剪贴板（等价 Ctrl+A/Ctrl+C），再到公众号编辑器 Ctrl/⌘+V 粘贴。按钮和脚本只在预览外壳里、不在被复制的 section 内，所以粘到公众号的仍是干净合规正文。
3. 告知用户：打开 {...}_预览.html → 点右上角「复制」→ 公众号编辑器粘贴；并给出干净正文文件路径作为兜底。附校验脚本结论（已通过 / 剩余 warning）。

8. 可选：多账号草稿与发布

用户要求上传草稿、提交发布或配置多公众号时，先读 references/multi-account-publishing.md。用 scripts/wechat_publish.py 执行确定性 API 流程，不手写临时请求：

1. 让用户复制 assets/wechat-accounts.example.json，每个账号用别名注册；AppID/AppSecret 只从各自环境变量读取。
2. 首次先用 --dry-run，再分别对每个账号执行 --action draft 并人工验收。
3. 只有用户明确要求公开发布时，才用 publish --media-id <已审核草稿ID> 发布现有草稿。不要在审核后再次用 send --action publish 创建第二份草稿。说明它是“发布”而非“群发给粉丝”。
4. 外部 Agent 的定时任务仅负责触发并传入 --account 和可选主题；本 Skill 不创建定时器。原文自带图片时才按账号分别上传；流水线不主动生成正文图片。封面素材仍必须属于目标账号。

生成时的智能处理（这些是本 skill 的特色，必须做）

1. 章节自动编号：按 ## 出现顺序分配 01/02/03…；末章若为结语/总结类，用主题库指定的结语编号变体（如 ∞），主题库未指定时沿用数字编号。
2. 英文标签：据中文章节标题生成英文标签（实测→TEST、教程→TUTORIAL、总结→SUMMARY、思考→THOUGHTS…），主题库有对应槽位时使用。
3. 正文关键词下划线（核心特色）：对每个正文段落主动找出 1–3 个最重要的短语，用该主题的下划线 CSS（见 theme-index）标记。优先标核心观点、结论、关键数据、专有名词；短语 4–15 字；整段无要点可不标。即使原文没有任何加粗也要主动加下划线——它是出现频率最高的基础标记。
4. 引言关键词高亮：识别开头金句里的核心词，用高亮组件标记。
5. 目录提取：从所有 ## 取前 3 个作为导读/目录要点（主题库有目录组件时）。
6. 信息模块提取：基础排版后只提取能被原文直接支持的观点、比较、流程或已核验数据，并按当前主题组件呈现。模块不重复整段正文，同类模块不重复，多个模块不相邻。
7. 开头引言卡署名：按文章的作者或主题而定——文章有署名就写"—— 作者名"，没有明确作者就用与主题相关的简短落款或直接省略。不要固定写"甲木"（尾部签名区同样用 {{作者名}} 占位，见第 8 条）。
8. 尾部作者签名区（作者自填，仅末尾一处）：默认不写死任何人名，用占位署名让用户替换成自己的。
   • 第一句（作者介绍）：我是 {{作者名}}，{{一句话简介，如：热衷于分享 AI 观察与干货}}——用户在请求/偏好里给了署名或简介就直接填入；没给就保留 {{作者名}} / {{简介}} 占位，并在交付时提示用户替换成自己的署名。
   • 第二句（互动引导，通用可保留原样）：如果你觉得今天这篇有收获，欢迎**点赞、在看、转发**三连，我们下篇见
   • 原文末尾已有作者签名段（如"我是 XXX…"）→ 直接沿用原文的署名，不替换成占位。
   • 流水线模式例外：优先使用账号档案或发布配置中的真实作者；仍无作者时删除整个署名组件，不得把 {{作者名}}、{{简介}} 带入草稿箱。
9. 列表转换：按主题库映射规则处理；无专属列表组件时转为带缩进的正文段落。
10. 中文全角标点：正文标点一律用全角（，。！？：；""''（）—— …），不要用半角 , . ! ? : 和英文直引号 " '。生成 HTML 时就直接写弯引号""''，不要先写直引号再事后替换——原文里的直引号在转写时当场转换。例外：代码块、行内代码、英文专名/URL/代码标识符内部保持原样。

视觉层级（3 层递进，所有主题通用）

平台红线（核心，完整检查交给校验脚本）

• 禁止：<style>/<script>/<div>、class/id 属性、position:fixed/absolute/sticky、float、@media/@keyframes、display:grid、CSS 变量、外部字体/CSS。
• 必须：样式全部内联 style；所有文字节点用 <span leaf="">文字</span> 包裹（否则粘贴后样式丢失）。
• 可用：display:flex（有限）、linear-gradient、border-radius、box-shadow、<section>/<p>/<span>/<strong>/<img>/<h3>。

Gotchas（真实排版踩过的坑）

• 漏 <span leaf> 包裹是最常见致命错——粘贴到公众号后样式整片丢失。靠第 5 步校验脚本兜底，别跳过。
• 下划线：逐段落实、每段 1–3 个短语。不要整段划线（失去焦点），也不要有的段标有的段漏；列表项里的关键描述同样要标。
• 章节编号错乱：严格按 ## 顺序，不要跳号；结语编号变体只用于末章，中间章节不能用。
• 签名区有且仅有末尾一个：用固定文案，不在中间或多处出现；原文末尾若已有作者签名/"点赞在看转发三连"类段落，识别并并入这唯一的签名区/CTA 卡片，不要保留原文段又再生成一个。
• 图片说明硬造：只有 ![说明](url) 里真有说明文字才生成说明组件；![](url) 空 alt 不要编造说明。
• 图片自适应、不铺满：<img> 一律 max-width:100%;height:auto;display:block;margin:0 auto——按图片自身尺寸显示、居中，大图缩到容器宽、小图保持原尺寸。不用 width:100%（会把小图也拉伸变糊）；只有表格 / 封面卡 / 流程图这类布局元素才用 width:100%。
• 跨主题混用组件：一篇文章只用所选主题 + 通用库的组件，不从其它主题借组件。
• 锚点层滥用：最强强调全文 ≤ 5 处，到处加粗等于没有重点。
• 原文内容遗漏：每个段落和原文已有图片都要转换，不得漏；信息模块只是新增视觉层级，不能取代原文内容。
• 占位图残留：签名区/CTA 组件里若带名片图占位（如 <img src="...名片或引导图URL">），没有真实图片 URL 时整行删掉，不要把占位符留在产物里。
• 目录是精选不是全量：前言导读/目录组件展示精选的 3 个核心看点，不是完整章节列表；章节多于 3 个时挑最重要的 3 个，不要硬塞或误导读者以为只有 3 章。
• 不用虚线框：突出标题/强调用小标签或左竖条（通用库 3a–3e），不要用 border:…dashed 四周虚线框包标题。例外：主题库明确定义的虚线组件（如摸鱼绿的 quote-box 引用框、oneliner-card 亮点卡）是该主题的风格特征，按主题库用法正常使用。
• 标点别混半角：正文出现半角逗号句号、英文直引号 " ' 都要改成全角；但代码块/行内代码内的半角符号保持原样，不要"全角化"代码。
• 代码/Prompt 必须用代码块：文章里的代码、命令、提示词用通用库代码块组件（1a/1b），不要塞进普通段落或引用块，否则缩进和等宽会丢失。
• 代码块要紧凑、忌大空白：用通用库 1a/1b 的"每行一个 <p style=\"margin:0\">"写法，绝不用 white-space:pre——它会把 HTML 源码里 span 前的缩进和行间换行原样渲染成大左缩进 + 空行；缩进只用全角空格 　，行距靠 line-height:1.6。
• 待补素材居中：【插入…】、待录屏 / GIF / 视频 / 成果图等占位，用通用库 2c 居中素材占位板块（浅底柔虚线框 + 居中图标与说明），不要用左对齐的提示块。

自定义主题生成（第二条工作流）

用户想要内置主题之外的新风格（说「生成一套新主题 / 自定义风格 / 按这张参考图做一套组件库」，或对现有主题都不满意）时，读 references/theme-generator.md 并严格按其流程执行：

1. 收集偏好：主题描述必填（或参考图），名称/ID/五色/字体/三类 TAG/圆角/阴影可空则自动补全；一次问全，不逐字段追问。
2. 生成区块库 HTML：用 theme-generator.md 末尾的【生成提示词】原样执行，产出 45~75 个 Block 的完整区块库，保存到 assets/theme-previews/{theme-id}.html——全部区块在同一页面连续排布，用户浏览器打开整页一次浏览确认风格，不逐块展示确认。
3. 转换 + 登记：用户确认风格后，转换为标准 references/theme-{标识}.md（必须补 <span leaf=""> 包裹、去掉预览用 id、补齐五章节，规则详见 theme-generator.md 第三步），登记 theme-index.md，跑 component_lint.py 到 0 ERROR。
4. 交付后该主题即成为常驻可选主题，后续排版与内置主题完全同权。

生成阶段以提示词规则为准；转换进主题库阶段以本文件「平台红线」和「添加新主题的规范」为准（两者冲突时后者优先，因为主题库直接决定排版产物）。

添加新主题的规范

新主题以 references/theme-{英文标识}.md 命名，内容必须包含：

1. 设计变量速查表（主色/浅底/深字/标题色/正文色/分割线色等）
2. 各组件完整 HTML（内联样式 + <span leaf=""> 包裹，遵守上面"平台红线"）
3. 完整文章模板骨架（组件装配顺序；若有目录/导航组件，明确其相对封面/引言的位置）
4. 文章类型 → 组件组合配方表（每种文章类型的核心组件组合 + 点缀组件，配方是排版气质稳定的关键）
5. Markdown → 组件映射规则表
6. 原生信息模块映射：同步更新 .agents/skills/wechat-inline-visuals/references/theme-component-map.md，为观点、比较、流程和数据类型登记可复用组件。

添加后在 references/theme-index.md 登记一行（主题名 / 主色 / 适用场景 / 组件库文件 / 正文下划线 CSS），并跑 python3 scripts/component_lint.py . 确认组件库无反模式（0 ERROR）。

触发与主题选择的回归用例见 references/eval-cases.md（维护时用于回归核对，不影响单次生成）。