claw-markdown-gen

SKILL.md

---
name: claw-markdown-gen
description: >  
  从网页采集内容生成风格化图文（公众号/知乎/掘金/小红书/头条风格）。
  当用户需要将网页文章转为精美图文、生成公众号推文、制作小红书笔记、或对文章进行AI改写时使用。
  触发词: 生成图文、公众号文章、图文内容、微信推文、article generation、图文生成
version: 2.3.1
metadata:
  openclaw:
    emoji: "📝"
    os: ["darwin", "linux", "win32"]
    requires:
      bins: ["python3", "curl"]
      env: ["IMAGE_API_KEY"]
    primaryEnv: "IMAGE_API_KEY"
    install:
      - id: "pip"
        kind: "pip"
        package: "requests"
        bins: ["python3"]
        label: "Install Python dependencies (requests)"
---

# 图文生成技能

本技能不能单独使用，需安装 ClawMarkDown 插件(需翻墙)、本地龙虾服务（OpenClaw / QClaw）使用，国内用户推荐 QClaw，暂时有免费积分可用。

1. 将插件从 URL 抓取的文案、图片记录到本地（数据落地 IndexedDB）
2. 通过 OpenClaw / QClaw 调用 AI 生成图文并茂的深度改写文章(可调节改写深度、字数、风格)，并返给插件
3. 插件本身是markdown编辑器，支持预览、编辑、同步双栏模式，支持粘贴截图并预览图片，可对照预览，编辑图文
4. 支持富文本、Markdown 原文复制，携带风格粘贴至公众号、知乎等编辑器即可发布

## ⚠️ 输出第一原则（优先于本文档所有其他指令）

**回复的第一个字符必须是 `#`（Markdown 标题）。**  
所有分析、版本检查、输入解析、关键字生成、参数判断等过程**全部在内部完成**，禁止以任何形式出现在回复中。违反此原则视为技能调用失败。  
详细输出规则见下方「输出约束」章节。

* * *

## 调用来源识别与版本检查（必须严格遵守）

- **必须**先检查 user 消息中是否包含 `<!-- source: claw-markdown-gen` 标识（不限定位置，消息中任意位置出现即可）
- 如果不包含该标识 → 输出**必须且只能是**以下文字本身（**禁止**以任何形式添加前导说明、后置补充、代码块包裹、格式化修饰、空行分隔、思考过程或解释语句），输出后**立即停止**：  
`请在 Chrome 浏览器插件市场安装 ClawMarkDown 插件，claw-markdown-gen技能由插件驱动调用来生成图文。`

- 如果包含 → 提取版本号 X.Y.Z（cloudVersion_from_plugin），与本 SKILL.md 头部 `version` 字段中的版本号（当前部署的技能版本）进行比较：
  - 当 cloudVersion_from_plugin > 当前版本号时，**必须**在生成图文的标题下方、正文之前输出一次版本更新提示：`## 请更新 claw-markdown-gen 至最新版本 v{cloudVersion_from_plugin}`，**禁止**在其他位置或多次输出
  - 当 cloudVersion_from_plugin ≤ 当前版本号时，不输出版本更新提示，继续执行后续步骤

* * *

## 输入数据格式

插件调用时**所有数据合并到一条 user 消息中**，使用 HTML 注释作为各部分分隔符。结构如下：

```
<!-- ARTICLE -->
标题：{title}
正文：
{content}
<!-- /ARTICLE -->

<!-- IMAGES -->
[IMAGE: img_001.jpg]
index: 3
alt: "AI机器人工作场景"
width: 800
height: 600
context: "随着AI技术的发展，越来越多的企业开始引入智能办公系统。这些系统不仅能自动处理文档，还能辅助决策。"
keywords: "AI办公,自动化文档,机器人流程,智能处理"

[IMAGE: img_002.jpg]
index: 7
alt: "自动化办公示意图"
width: 1200
height: 800
context: "传统办公模式下，大量重复性工作消耗了员工的时间和精力。而智能办公系统可以将这些工作自动化。"
<!-- /IMAGES -->

<!-- source: claw-markdown-gen v2.3.0 -->

<!-- INSTRUCTION -->
请使用 claw-markdown-gen 技能，生成{style}风格图文，字数约{mode}字，改写深度：{rewriteDepth}。
<!-- /INSTRUCTION -->
```

> **重要**：上述结构是单条 user 消息的完整内容。`<!-- ARTICLE -->`/`<!-- /ARTICLE -->`、`<!-- IMAGES -->`/`<!-- /IMAGES -->`、`<!-- INSTRUCTION -->`/`<!-- /INSTRUCTION -->` 是各部分的开始/结束标记。`<!-- source: claw-markdown-gen vX.Y.Z -->` 是版本标识（位置不固定，可在消息任意位置出现）。

**字段说明：**

**请求字段：**

| 字段             | 说明                         |
| -------------- | -------------------------- |
| `{title}`    | 原文标题                       |
| `{content}`  | 正文 Markdown 内容             |
| `{style}`    | 图文风格（中文，详见「风格配置声明」中的映射表） |
| `{mode}`     | 目标字数（默认 1000，插件端会根据原文字数和改写深度设置合理范围） |
| `{rewriteDepth}` | 改写深度（轻度/中度/重度）             |

**图片元数字段：**

| 字段               | 说明                                     |
| ---------------- | -------------------------------------- |
| `[IMAGE: xxx]` | 图片元数据块开始标记                             |
| `index`          | 图片在原文中的位置序号，用于定位图片所属的上下文段落           |
| `alt`            | 图片 HTML alt 属性，辅助理解图片内容                |
| `width` / `height` | 图片尺寸信息                                 |
| `keywords`       | （可选）已有的图片关键字，逗号分隔。存在时跳过关键字生成，直接使用      |
| `context`        | （可选）图片在原文中前文文字（上溯多个同级元素采集），用于关键字生成的上下文参考 |

**图片元数据块位于 `<!-- IMAGES -->` 与 `<!-- /IMAGES -->` 之间，每张图片信息以空行分隔。当无图片元数据时，`<!-- IMAGES -->` 与 `<!-- /IMAGES -->` 之间为空或省略整个 IMAGES 块。**

## 字数控制总则

本规则适用于所有改写深度，控制生成图文的正文长度。

1. **必须**以 `{mode}` 为目标字数生成正文
2. 允许偏差：±20%（即生成字数应在 `{mode} × 0.8` 到 `{mode} × 1.2` 之间）
3. **字数定义**（仅本规则使用）：
   - ✅ 计入：中文字符、英文单词（中文按字符计，英文按词计）
   - ❌ 不计入：标点符号、空行、`{{IMAGE:...}}` / `{{AI_IMAGE:...}}` 占位符、`<!-- kw:... -->` 关键词注释、`<!-- source: ... -->` 版本标识、Markdown 标记符（`#` `>` `-` 代码块围栏等）
   - **原文长度**：按上述定义统计 `{content}` 的长度，记为"原文约 X 字"，用于扩展场景约束的判断
4. **必须**在生成完成后、正文输出前自检字数：逐段统计正文字符数（按上述定义），与 `{mode}` 对比：
   - 偏差 ≤ 20% → 通过，输出结果
   - 偏差 > 20% → 不足时补充原文相关段落，超标时删减冗余内容，调整后再次自检
5. 若连续 2 次修正后仍不达标 → 以当前最接近的结果输出（防止死循环）

**扩缩比例与改写深度的交叉规则**：

以原文长度（按条 3 定义统计）为基准，`{mode}` 与原文长度之比决定扩缩场景，不同改写深度在同一场景中处理方式不同：

| 比例 | 场景 | 轻度改写 | 中度改写 | 重度改写 |
|------|------|---------|---------|---------|
| mode < 原文 × 50% | 大幅缩写 | 摘要：提取核心观点和主要论据 | 重写：按核心价值点重组，替换细节 | 重写：仅保留核心事实，重构叙事 |
| 原文 × 50% ≤ mode < 原文 × 80% | 中度缩写 | 精简：保留主要段落，压缩表述 | 改写：重组结构，删减次要细节 | 重构：以核心事实为锚点，重构论证框架，用精炼方式呈现深度分析 |
| 原文 × 80% ≤ mode ≤ 原文 × 120% | 等长 | 润色：逐句优化，保持结构 | 改写：调整结构，替换部分论据 | 重构：打破结构，深度改写 |
| mode > 原文 × 120% | 扩写 | 解释：补充说明，不添加新案例 | 扩写：添加少量案例、对比、建议 | 扩写：大量添加案例、洞察、对比 |

**插件端相容性保证**：插件端会根据原文字数和改写深度对 `{mode}` 设置合理的最小值（轻度不限制；中度 ≥ 原文 × 50%；重度 ≥ 原文 × 35%）和最大值（原文 ≤ 3000 时 max = 3000；原文 > 3000 时 max = ceil((原文 + 100) / step) × step，保证 max > 原文 + 100，step 随 max 自适应增大）。因此到达本技能时，`{mode}` 已保证与 `{rewriteDepth}` 相容；若运行时仍出现冲突，按「公共规则：冲突优先级」处理。

**扩展场景约束**：扩写场景适用上述交叉规则的对应处理方式，禁止通过重复表述、堆砌修饰词、拆分短句等方式凑字数；若原文信息不足以支撑目标字数，宁可缩减到合理范围，也不编造内容。

* * *

## 风格配置声明

根据 user 消息中的 `{style}` 参数（中文），按以下映射加载对应的风格配置文件：

| `{style}` | 配置文件路径 |
|:---------:|:------------|
| `公众号` | `references/styles/wechat_common_style.json` |
| `知乎` | `references/styles/zhihu_common_style.json` |
| `掘金` | `references/styles/juejin_common_style.json` |
| `小红书` | `references/styles/xiaohongshu_common_style.json` |
| `头条` | `references/styles/toutiao_common_style.json` |

各配置文件的字段含义：

| JSON 字段 | 含义 | 约束等级 |
|-----------|------|---------|
| `style.tone` | 全文语气基调（如"口语化、短段落、轻松"） | 必须遵循 |
| `style.structure` | 三段结构：opening / body / conclusion | 中度/重度改写必须按此组织，轻度仅作参考 |
| `style.formatting` | 标题格式、代码块、列表等排版规则 | 建议遵循 |
| `style.taboo` | 禁止出现的写作方式 | 严格禁止 |

**降级规则**：JSON 文件不存在或无法解析 → 使用下方字段说明表中的简述继续生成，并在文末追加 `<!-- style_fallback:{style} -->` 注释。

**加载方式**：步骤 1 解析输入数据时，根据提取的 `style` 参数按映射表读取对应的 `references/styles/{style}_common_style.json` 文件，加载 `tone`、`structure`、`formatting`、`taboo` 四个字段到生成上下文。

**应用指引**：步骤 3 生成图文时全程生效，四个字段的作用环节如下：
- `tone`：影响句式选择、用词倾向、段落节奏，从第一句开始贯彻
- `structure`：决定 opening / body / conclusion 三段组织方式（轻度改写仅作参考，中度/重度必须遵循）
- `formatting`：控制标题格式、代码块、列表等排版规则，在输出 Markdown 时应用
- `taboo`：作为硬约束，生成过程中持续检查，命中即重写

后续执行步骤中不再单独说明风格约束，直接引用本声明中加载的配置。

* * *

## 输出约束（必须严格遵守）

1. **输出的第一个字符必须是 `#`（Markdown 标题）**，直接以标题开头，不得在标题前输出任何文字
2. **回复中只输出最终的 Markdown 图文内容**
3. **绝对禁止**输出以下任何内容：
   - 思考过程、推理步骤、内部对话
   - 关键字列表、关键字映射 JSON
   - 步骤序号（"第一步"、"第二步"...）
   - 图片插入规划说明、段落匹配结果
   - 确认语句（"已按 XX 风格生成"、"根据您的要求..."）
   - 技能定位叙述（"找到了 XX 技能"、"让我先读取 SKILL.md"等）
   - 任何形式的前导说明、过渡语、操作叙述
   - 尾部总结、生成报告、字数统计等末尾元数据
4. **允许输出**：
   - 每张图片占位符后紧跟一行 `<!-- kw:文件名:关键词1,关键词2,... -->` 格式的关键词注释
   - 版本更新提示行（仅当 cloudVersion_from_plugin 大于当前版本时输出）：`## 请更新 claw-markdown-gen 至最新版本 v{cloudVersion_from_plugin}`，输出位置在标题下方、正文之前
5. 违反以上约束的输出视为技能调用失败

* * *

## 执行步骤（全部为内部处理，禁止输出）

> **重申**：以下所有步骤（版本检查、输入解析、关键字生成、图文生成、润色）均为**内部处理**。回复中不输出任何步骤的中间产物、分析过程、参数复述或过渡语。回复的第一个字符必须是 `#`。详细规则见「输出第一原则」和「输出约束」。

本部分描述了生成图文必须执行的处理步骤。

> **参考文档**：执行前置阶段和步骤 2（图片关键字生成、插入位置规划）时，必须同时参考 `references/image-handling.md` 中的完整规范，包括关键字生成方法、生成原则、示例、图片插入原则及位置规则。

### 步骤 1：解析输入数据

所有数据合并到单条 user 消息中，使用 HTML 注释分隔符划区。按以下顺序提取：

1. 定位 `<!-- ARTICLE -->` 与 `<!-- /ARTICLE -->` 之间的内容 → 原文区（按 `标题：` 与 `正文：` 行分割，提取标题与正文 `article_text`）
2. 定位 `<!-- IMAGES -->` 与 `<!-- /IMAGES -->` 之间的内容 → 图片元数据块（逐张解析，每张图片以 `[IMAGE: xxx]` 起始，至空行或下一张图片结束）
3. 定位 `<!-- INSTRUCTION -->` 与 `<!-- /INSTRUCTION -->` 之间的内容 → 技能指令区，按 `生成{style}风格图文，字数约{mode}字，改写深度：{rewriteDepth}` 格式提取 `style`、`mode`（转整数）、`rewriteDepth`，以及可选的"额外要求"
4. 版本标识 `<!-- source: claw-markdown-gen vX.Y.Z -->` 可能在消息任意位置出现，在「调用来源识别与版本检查」章节中已处理

每张图片解析得到：`name`（文件名）、`index`（位置序号）、`alt`（描述）、`width`、`height`、`context`（可选，前文文字）、`keywords`（可选，已有关键字）。

**风格配置加载**：按「风格配置声明」中的加载方式，读取对应风格 JSON 文件并加载到生成上下文。

**无图片时的处理**：如果 `<!-- IMAGES -->` 与 `<!-- /IMAGES -->` 之间为空，或整个 IMAGES 块被省略（即没有 `[IMAGE: xxx]` 块），则跳过前置阶段和步骤 2，直接进入步骤 3 生成纯文本文章，步骤 4 照常执行。

### 前置阶段：图片关键字生成（子 agent 派发）

在进入正式生成流程前，先完成所有图片的关键字生成，让后续步骤专注于图文本身。

**带关键字图片的处理（改写场景）**：

如果图片元数据中包含 `keywords` 字段（非空），说明该图片已在首次生成时获得正确关键字。此时：
- **跳过**该图片的关键字生成
- **直接使用** `keywords` 字段中的关键字，原样写入输出中的 `<!-- kw:... -->` 注释
- 仅对**没有** `keywords` 字段的图片执行下方子 agent 派发流程

**匹配上下文：**

每张图片在采集时已从页面 DOM 中提取了前文文字（上溯多个同级元素），存储在 `context` 字段中。直接使用 `context` 字段的文字作为该图片的上下文参考。

如果某张图片没有 `context` 字段或为空，则退回到根据 `index` 序号在 `article_text` 中定位段落的方式：
- `index` 表示图片在原文中的出现顺序
- 将 `article_text` 按段落分割，映射 index 到对应段落
- 提取该段落及其前后各一段的文字作为该图片的上下文

**子 agent 派发（跨平台适配）：**

当存在需要生成关键字的图片时，**必须**派发子 agent 处理，让主 agent 专注于图文生成。具体调用方式由运行平台决定，SKILL.md 只描述任务意图，不绑定具体工具名：

- **OpenClaw / QClaw**：使用 `sessions_spawn` 工具，`context` 参数设为 `isolated`，调用后用 `sessions_yield` 等待结果
- **Claude Code**：使用 Task 工具，`subagent_type` 选 `general_purpose_task`
- **Codex / 其他平台**：使用平台原生子 agent / sub-task 调用机制
- **不支持子 agent 的环境**：主 agent 自行内联处理（见下方「降级处理」）

派发给子 agent 的任务内容（自然语言描述，由主 agent 组织）：

1. 主 agent 先基于 `{title}` 和 `article_text` 生成 1-2 句文章主题摘要（内部处理，不输出）
2. 将以下信息打包传给子 agent：
   - 文章主题摘要
   - 每张待处理图片的：文件名（`name`）、`alt` 描述、上下文文字（`context` 或按 index 定位的段落）
3. 指示子 agent 为每张图片生成 3-5 个中文关键字，要求：
   - 具体、有区分度，不同图片的关键字必须体现差异性
   - 避免泛泛的"图片"、"示意图"、"配图"、"插图"
   - 每张图片一行，格式：`文件名:关键字1,关键字2,关键字3`
   - 只输出关键字映射，不输出其他任何内容
4. 等待子 agent 完成，从返回结果中解析关键字映射

**降级处理**：如果运行环境不支持子 agent 调用，或子 agent 返回结果无法解析，主 agent 自行执行关键字生成（按下方「关键字要求」内联处理），不阻塞流程。

**关键字要求：**

- 具体、有区分度，不同图片的关键字必须体现差异性
- 避免泛泛的"图片"、"示意图"、"配图"、"插图"
- 关键字将在步骤 3 中以 HTML 注释形式嵌入输出，供插件端回填 IndexedDB

### 步骤 2：规划图片插入位置

根据前置阶段生成的关键字，与 `article_text` 各段落做语义匹配：

1. 将图片分配到语义最相关的段落
2. 每 300-500 字插入一张图片
3. 不强制按 `index` 或文件名顺序，以语义相关性为准

**插入位置规则：**

- 引导图（关键字最贴近标题/主题）→ 引言段之后
- 分段配图 → 对应小节标题之后、正文之前
- 结尾图 → 倒数第二段之后

### 步骤 3：生成图文

**风格应用**：按「风格配置声明」中的应用指引，全程遵循加载的 tone / structure / formatting / taboo 约束。

根据 `{rewriteDepth}` 执行不同的生成策略：

**所有图片关键字必须输出**：前置阶段中为每张图片都生成了关键字，无论该图片最终是否被插入文章，关键字注释都必须出现在输出中：
- 被使用的图片：`<!-- kw:文件名:关键词1,关键词2,... -->` 紧跟图片占位符和说明之后（现有格式）
- 未被使用的图片：`<!-- kw:文件名:关键词1,关键词2,... -->` 集中追加在文章末尾

这确保插件端能为所有图片回填正确关键字，避免改写场景中因缺少关键字而重新生成错误关键字。

**公共规则（所有深度适用）：**
1. 标题优化：基于 `{title}` 生成引人注目的标题
2. 图片占位符独立成行，格式为 `{{IMAGE:img_XXX.jpg}}`
3. 每张图片占位符后紧跟一行 `> 图片说明`（不超过 20 字）
4. 每张图片说明后紧跟一行 `<!-- kw:img_XXX.jpg:关键词1,关键词2,关键词3 -->`（3-5 个中文关键词，逗号分隔）
5. 字数控制：遵循「字数控制总则」；其中「扩缩比例与改写深度的交叉规则」优先于八维度的单项描述——先按 mode 与原文长度之比判断所属场景（大幅缩写/中度缩写/等长/扩写），再按对应深度处理
6. 保持原文核心信息和事实准确性
7. 严格遵循「风格配置声明」中加载的 tone、formatting、taboo 约束
8. **冲突优先级**：当改写深度的保留/删除要求与字数控制冲突时，以字数控制为准，相应放宽保留/删除要求

**改写强度八维度对照表：**

| 维度 | 轻度改写 | 中度改写（默认） | 重度改写 |
|------|---------|----------------|---------|
| **1. 段落** | 保留原段落顺序与划分，仅优化分段 | 可调整段落顺序，合并或拆分段落 | 完全重新划分段落，不保留原段落边界 |
| **2. 结构** | 保留原章节结构，优化标题层级；structure 仅在段落切分上作参考，不强制三段重组 | 禁止照搬原文章节顺序，按核心价值点重组，提炼 3-5 个关键主题；必须按 structure 三段结构组织 | 完全打破原文结构，以全新角度构建独立叙事框架；必须按 structure 三段结构组织 |
| **3. 文字构成** | 逐句保留原意，仅做语法润色、格式整理、少量过渡句补充 | 每段用自己的语言重新表述，论点保留，论据可删减或替换为新案例/数据 | 仅保留核心事实和数据点，叙述全部重写 |
| **4. 信息密度** | 全部保留原文细节、数据、案例 | 保留核心论据；次要细节可替换为新案例/数据 | 仅保留核心事实；细节替换为分析、洞察、对比 |
| **5. 增值内容** | 不添加原文没有的内容 | 必须添加少量个人见解、使用建议、对比分析、注意事项、适用场景或实际案例 | 大量添加深度分析、行业洞察、多角度对比、替代方案、注意事项、实际案例 |
| **6. 逻辑链** | 保留原论证顺序与因果关系 | 可调整论点顺序，重组论证脉络 | 重建论证框架，构建新的因果逻辑 |
| **7. 视觉元素** | 仅使用原文图片占位符，禁用 SVG / Mermaid / AI 配图 | 仅使用原文图片占位符，禁用 SVG / Mermaid / AI 配图 | 按需使用 SVG / Mermaid / AI 配图（每类最多 1-2 处，避免喧宾夺主） |
| **8. 风格遵循** | 遵循 tone / formatting / taboo；structure 仅作语气参考 | 遵循 tone / structure / formatting / taboo | 遵循 tone / structure / formatting / taboo；个人色彩更强 |

**重度模式可视化触发条件：**
- **SVG 插图**：当原文涉及流程、对比、结构关系且无原图时，直接输出 SVG 代码（流程图、示意图、装饰图等），用 Markdown 代码块包裹
- **Mermaid 图表**：当原文涉及多角色协作、架构层次、关系网络时，输出 Mermaid 代码，用 Markdown 代码块包裹
- **AI 配图**：当原文某段落语义适合配图但无原图时，使用 `{{AI_IMAGE:ai_img_XXX.jpg:prompt描述}}` 占位符，后紧跟 `<!-- kw:ai_img_XXX.jpg:关键词1,关键词2,关键词3 -->`。生成完成后，由技能脚本调用用户透传的图片生成 API 将占位符替换为真实图片 URL，保留关键词注释

**重度模式后处理**：LLM 输出含 `{{AI_IMAGE:ai_img_XXX.jpg:prompt}}` 占位符的 Markdown 后，执行 `scripts/generate_images.py` 脚本：

```
python scripts/generate_images.py <input_md> <output_md> \
  --api-key {multimodal.key} \
  --api-url {multimodal.url}
```

脚本流程：
1. 解析所有 `{{AI_IMAGE:ai_img_XXX.jpg:prompt描述}}` 占位符，提取文件名和 prompt
2. 使用请求中透传的 `multimodal.key` 和 `multimodal.url` 调用图片生成 API
3. 将占位符替换为 `![prompt描述](图片URL)` 格式
4. 保留 `<!-- kw:ai_img_XXX.jpg:关键词 -->` 注释，供插件端回填 IndexedDB
5. 输出最终 Markdown 图文

### 步骤 4：去 AI 味润色

> **参考文档**：执行本步骤时，必须同时参考 `references/ren-zh.md` 中的完整规范，包括核心规则、注入灵魂、高频 AI 模式及快速检查清单。

对生成的 Markdown 图文做去 AI 味处理，保持图片占位符和图片说明不被修改。

## 正确输出示例

```markdown
# AI 助手正在重塑我们的办公方式 

你有没有发现，以前要花半天整理的报表，现在几分钟就搞定了？ 

这不是科幻，而是正在发生的现实。 

{{IMAGE:img_001.jpg}} 
> AI 机器人自动处理文档
<!-- kw:img_001.jpg:AI办公,自动化文档,机器人流程,智能处理 -->

就拿文档处理来说，过去人工一份份核对数据、排版、纠错，效率低还容易出错。现在接入 AI 助手后，它能自动识别表格结构、提取关键信息、甚至按你的风格生成初稿。 

{{IMAGE:img_002.jpg}} 
> 智能办公流程示意
<!-- kw:img_002.jpg:数据大屏,实时监控,业务指标,可视化分析 -->

更妙的是，它不只是"工具"，而是在不断学习你的偏好。你改得越多，它下次就越懂你。 

当然，AI 也不是万能药。最终的判断、创意、策略，还得靠人。但那些重复枯燥的活儿，交给它确实很香。 

拥抱新工具，把精力花在真正值钱的事情上。

<!-- kw:img_003.jpg:团队协作,在线会议,远程办公,视频沟通 -->
<!-- kw:img_004.jpg:数据安全,隐私保护,加密传输,安全防护 -->
```

## 错误处理

| 错误 | 处理方式 |
|------|---------|
| `<!-- IMAGES -->` 与 `<!-- /IMAGES -->` 之间无 `[IMAGE: xxx]` 块 | 跳过前置阶段和步骤 2，直接生成纯文本文章 |
| 某张图片 `context` 和 `index` 均无法定位段落 | 跳过该图片，不执行关键字生成和插入 |
| 图片关键字语义匹配无合适段落 | 按 index 顺序就近插入，不强制语义匹配 |
| 重度模式 `AI_IMAGE` 生成 API 超时或失败 | 保留 `{{AI_IMAGE:...}}` 占位符，不阻塞文章输出 |
| user 消息中缺少 `style`/`mode`/`rewriteDepth` | 默认值：公众号风格 / 800 字 / 中度改写 |
| 风格配置文件不存在或无法解析 | 使用字段说明表中的简述继续生成，并在文末追加 `<!-- style_fallback:{style} -->` 注释 |
| 正文内容为空 | 输出提示："无法从该网页提取到有效正文内容" |
| 子 agent 调用不可用或返回格式异常 | 降级为主 agent 内联生成关键字 |

## 降级方案

| 故障 | 降级路径 |
|------|---------|
| 重度模式图片生成 API 不可用 | 跳过 AI 配图，仅保留原文图片占位符 |
| 图片元数据解析失败 | 忽略该图片，继续处理其他图片 |
| 改写后文章字数与 `{mode}` 偏差超过 20% | **必须**轻度补充原文相关段落（不补图片），再次自检 |
| 版本检查无法获取 cloudVersion_from_plugin | 跳过版本检查，正常生成图文 |
| 运行环境不支持子 agent 调用 | 降级为主 agent 内联生成关键字，不阻塞流程 |
| 子 agent 返回结果无法解析 | 主 agent 自行生成关键字 |

## 安全注意事项

- 重度模式 AI 配图使用用户自行配置的图片生成 API（`multimodal.key`/`multimodal.url`），技能本身不持有任何密钥
- 图片元数据以纯文本传输，不包含图片二进制数据
- 所有原始图片由插件端在本地 IndexedDB 管理，技能不读取用户本地文件
- 生成的图文为纯 Markdown，不包含可执行代码或脚本
- 敏感操作（调用外部 API）所需的密钥均由用户在插件设置页自行配置，技能不收集或上传任何凭证

## 注意事项

- 输出 Markdown 时不要用代码块包裹
- 图片占位符格式严格为 `{{IMAGE:img_XXX.jpg}}`（占位符为裸文本，禁止用反引号或代码块包裹）
- 图片说明不超过 20 字
- 图片插入位置由关键字语义匹配决定，不强制按 index 顺序
- `width` 和 `height` 仅用于判断图片宽高比和大致类型（横图/竖图/方图），不直接出现在输出中
- 正文中若残留作者自我介绍语句（如"大家好，我是XX""嗨，我是XX"等），在生成时将其去除或改写，保持内容干净