le-wechat-article v1.0：Leroy 专属公众号写作工坊（类型路由 / 分层审读 / 排版转换 / 草稿箱同步）

skills/le-wechat-article/references/article-types.md

@@ -0,0 +1,61 @@
+# 文章类型路由
+
+在接单时选定唯一主类型，写作、大纲、审读、自检全程应用对应规则。类型由「文章要回答的核心问题」决定，日期、版本号等表面特征只作辅助。
+
+## 路由顺序
+
+1. 用户明确指定的类型优先。
+2. 回答「更新了什么」→ **新闻和软件更新简报**
+3. 回答「实际用起来怎么样、值不值得、适合谁」→ **产品体验和工具测评**（即使素材含版本号，谈体验就是测评）
+4. 回答「这件事怎么做成的、有什么可复用」→ **个人实践和工作流复盘**
+5. 回答「为什么、怎么理解、怎么复现」→ **技术解析和教程**
+6. 靠生活事件、观察、观点推进 → **生活叙事和观点文章**
+
+混合素材只选一个主类型，其他类型的写法可局部借用，但不得同时套多套开头和结尾结构。判断不了且会改变结构时，问用户一次。
+
+## 各类型规格
+
+### 新闻和软件更新简报
+
+- **回答**：更新了什么、影响哪些操作、怎么用上
+- **开头**：第一段直接说日期/版本/信息范围，紧接无序列表概括主要更新。列表只写用户可感知的变化，不罗列测试、重构、内部维护
+- **推进**：每节标题直接写功能变化；标题后第一段立即说改动点，随后 1–3 段说影响、场景、用法。会改变读者判断的限制才进正文；包管理器、内部模块等细节除非影响安装/兼容/安全否则删
+- **篇幅**：1500–3000 字，信息完整可以更短
+- **来源**：commit SHA、PR 地址等代码证据记在交付时的审读报告里，不塞进正文；确有查阅价值时文末集中列官方公告链接
+- **审读重点**：标题+首段+列表能否一分钟讲清更新范围；每节是否含改动点/影响/用法；是否把开发中的代码写成了已发布；**不要求个人故事和情绪，HKR 以 K 为主，R 低不算失败**
+
+### 产品体验和工具测评
+
+- **回答**：真实任务里表现如何、优缺点、适合谁
+- **开头**：从一次真实使用任务或最影响判断的体验结论切入，同时交代使用条件。不因出现版本号就写成更新列表
+- **推进**：按「使用任务 → 实际表现 → 体验变化 → 优势与限制 → 适用对象」。功能只在解释体验时出现，功能清单不是测评
+- **篇幅**：2500–5000 字
+- **审读重点**：每项判断是否来自真实操作或素材；使用条件/限制是否交代；是否把短期试用写成了普遍结论；是否把宣传语当成了测试结论
+
+### 个人实践和工作流复盘
+
+- **回答**：任务怎么完成的、过程怎么调整的、什么可复用
+- **开头**：从真实问题、任务目标或限制条件切入，让读者先知道当时要解决什么
+- **推进**：按「问题 → 尝试 → 调整 → 结果 → 复盘」。尝试多时围绕关键决策点组织，不必逐项记录
+- **篇幅**：2500–6000 字
+- **审读重点**：问题-尝试-结果之间因果是否清楚；是否补写了未经确认的经历、失败次数、情绪；复盘结论是否由实际过程支撑；读者能否识别可复用的方法及其适用条件；**不得加工成一次性成功故事**
+
+### 技术解析和教程
+
+- **回答**：问题为什么发生、概念怎么理解、操作怎么复现
+- **开头**：从明确问题、技术现象或待解释概念直接进入，不硬造叙事场景，也不堆时代背景
+- **推进**：按「问题 → 原理 → 验证/操作 → 边界」。教程保留环境、步骤、配置和失败处理；解析区分已验证事实、解释和推断。代码和命令只留完成任务需要的部分——保留可复现的信息，但不贴大段代码
+- **篇幅**：2500–6000 字
+- **审读重点**：问题-原理-操作是否对应、能否复现；环境与前置条件是否完整；事实/验证/推断是否分清；技术细节是否服务理解而非挤占结论；**保持术语和正式度，不为「自然」改成聊天语气**
+
+### 生活叙事和观点文章
+
+- **回答**：通过事件、观察或观点呈现经验与思考
+- **开头**：从真实事件、当下观察、具体细节或明确观点切入，可留悬念，不用空泛背景
+- **推进**：时间、人物、主题、思考变化均可作线；细节与观点相互支撑；可用回环留白，不套论证模板
+- **篇幅**：2000–5000 字
+- **审读重点**：事件与经历是否真实、外部事实可否追溯；观点是否由细节支撑；结构是否自然、有无强行升华；作者声音是否稳定、情绪是否来自素材
+
+## 篇幅的共同原则
+
+区间是参考不是配额：结构完整、逻辑连贯优先，素材不足时短于下限也可交付（在审读报告中注明），不为凑字数注水。

skills/le-wechat-article/references/author-profile.md

@@ -0,0 +1,59 @@
+# Leroy 的作者画像
+
+本文件随 skill 存放，属于个人资产：写作前加载，让每篇文章保持同一个人的声音。画像只细化偏好，不能覆盖文章类型路由、事实核查与真实性底线。
+
+## 使用方式
+
+- 首次使用时，用下方「首访问题」问 Leroy 一次，把答复写进对应小节，之后不再重复问
+- Leroy 随时可以直接口述修改本文件；改完即时生效
+- 本文件内容不复制进文章交付物或对外文件
+
+## 首访问题（未填写时问一次）
+
+1. 你的公众号叫什么、主要写给谁看？（账号定位与读者画像）
+2. 你希望读者读完记住你是一个什么样的作者？（声音与气质）
+3. 有没有你特别喜欢/不能接受的表达方式？（如：口语化程度、能否用梗、第一人称习惯）
+4. 文末固定要加什么？（关注引导/签名/往期推荐/什么都不加）
+5. 有没有偏好的排版主题色？（影响 md2wechat.py 的默认配色）
+
+## 账号与读者
+
+读者定位：**入门科普向**——没用过微调但会用 AI 工具的人。类比优先，术语首次出现必须解释；不假设编程背景。（2026-10-05 首访确认）
+
+## 声音与语气
+
+默认中性基线：清楚、自然、有取舍；观点由素材支撑。个性化偏好写在这里：
+
+（待填写）
+
+## 各类型偏好（可选，按 article-types.md 的五类型分别覆盖）
+
+- 新闻和软件更新简报：（待填写）
+- 产品体验和工具测评：（待填写）
+- 个人实践和工作流复盘：（待填写）
+- 技术解析和教程：（待填写）
+- 生活叙事和观点文章：（待填写）
+
+## 文末固定块
+
+默认追加关注引导，逐字使用：
+
+```markdown
+---
+
+觉得有用？点个关注，持续收到这类内容。
+```
+
+（2026-10-05 首访确认；改文案直接编辑此处）
+
+## 排版偏好
+
+默认排版骨架：**工程**（色条标题，适合技术文）
+默认主题色：**靛蓝 #1A5CFF**
+默认字号：16px（公众号正文标准）
+
+## 敏感词清单（可选）
+
+一行一个，审读时逐词扫描，命中即必改；留空则只按通用合规类别检查：
+
+（待填写）

skills/le-wechat-article/references/review-playbook.md

@@ -0,0 +1,96 @@
+# 审读手册
+
+供独立审读（subagent）与修改环节使用。目标：发现空泛、重复、失真和不符合文体的表达——**不是**作者身份检测，不保证通过任何 AI 检测器。没有问题时明确说「没有需要修改的问题」，不为填清单制造意见。
+
+## 判断顺序（冲突时靠前赢）
+
+1. 保留信息和确定程度
+2. 遵守本次任务范围和文章类型
+3. 保留作者素材中已有的声音与立场
+4. 处理具体表达问题
+
+模式命中只是线索，不是禁词表：单个词语、三项列表、被动句都不单独构成修改理由。
+
+## 语义保真（每次修改都要对照基线）
+
+对照 `review-baseline.md` 和作者素材，核实以下内容没有被新增、遗漏或强化：
+
+- 独立事实、数字、名称、日期、引用
+- 否定、比较对象、适用范围和条件
+- 时间、进行状态、完成状态、后续计划
+- 判断的归因对象
+- 「可能、据称、预计、仅、至少、正在、尚未」承载的确定程度
+- 作者已表达的立场、犹豫和限制
+
+红线：不把相关写成因果、可能写成确定、计划写成已完成；不为显得具体补造数据、来源、经历、情绪、冲突、引文。审读只指出问题和不改变含义的修改方向，不代改。
+
+## 平台合规（命中即必改，与 AI 味的「默认建议」不同级）
+
+公众号内容合规是发文失败与限流的实际来源。逐类扫描，命中任何一条都按🔴必改处理，不带「建议」：
+
+- **违禁内容**：政治敏感表述、暴恐、色情低俗、赌博诈骗类措辞——拿不准的具体表述列出来问 Leroy，不自行改写后放行
+- **广告法绝对化用语**：最、第一、唯一、100%、国家级、顶级、极致、史上最 X——用户素材里确有出处的数据表述（如「官方公布的 100% 兼容」须附来源）除外
+- **医疗与金融承诺**：疗效保证、稳赚、保本、收益率承诺、荐股荐基类表述
+- **未授权素材**：他人图片/大段引文无来源标注；无法确认授权的标「待作者确认」
+- **自定义敏感词**：Leroy 在 [author-profile.md](author-profile.md) 维护的清单逐词扫描，命中即必改
+- **边界**：脚本不内置词库（会过时），靠模型按类别现场判断 + 自定义清单兜底；改写合规问题时同样受语义保真约束——把「第一」改成「领先」是降级表述，不是改事实
+
+- 数字、日期、版本、事件能否在素材中找到出处
+- 描述的场景是来自真实素材还是推理补写
+- 产品名、公司名、术语拼写与官方是否一致
+- 引用的评价、讨论有无原始出处；没有的标「待作者确认」或删
+- 图位脚本中的数据、标签与素材是否一致
+
+## AI 味指纹（带防误判阈值）
+
+AI 味的本质是**太顺、太均匀、没有取舍**——不是用词高级。每条命中标注信号强度，但**一切命中默认只是建议**，不构成必须改：
+
+| # | 指纹 | 典型样子 | 强度 |
+|---|------|---------|------|
+| 1 | 万能背景开头 | 「随着 AI 技术的发展」「在当今这个时代」 | 强 |
+| 2 | 「不是 X，而是 Y」滥用 | 单次是修辞，**800 字内 ≥3 次**才算命中 | 强 |
+| 3 | 面面俱到没取舍 | 利弊前提例外全讲一遍，什么都不得罪 | 强 |
+| 4 | 空洞祝福收尾 | 「愿你…」「你值得…」谁都适用谁都记不住 | 强 |
+| 5 | 工整排比成瘾 | 单处排比是好文笔，**几乎每节都排比**才算 | 中 |
+| 6 | 反复让步两头讨好 | 「当然，这并不是说…」每个论点前都垫 | 中 |
+| 7 | 命名仪式感 | 普通做法硬安「XX 法则」再郑重解释 | 中 |
+| 8 | 情绪曲线平滑 | 全程一个温度，没有真实的激动、烦躁、犹豫 | 中 |
+| 9 | 翻译腔 | 「值得注意的是」「在某种程度上」、超长前置定语 | 中 |
+| 10 | 强行拔高 | 讲快捷键结尾升华成「生活态度」 | 中 |
+| 11 | 模板化假故事 | 「我有个朋友…」但零细节——有时间地点对话尴尬的真故事不算 | 中 |
+| 12 | 总分总八股 | 开头预告三点、中间整齐分点、「总而言之」收口 | 中 |
+| 13 | 概念名词扎堆 | 满屏赋能闭环抓手，没有一个可复现步骤或真实数字 | 中 |
+| 14 | 节奏过度规整 | 句长高度均匀，没有短促断句 | 弱 |
+| 15 | 程度词通胀 | 「极其重要」「真正意义上的」堆叠撑分量 | 弱 |
+
+**防误判**：拿不准时宁可不报；文章主题本就关于价值观时谈意义是切题；体裁本身工整（清单文）时排比是设计。诊断目的是让稿子看清自己哪里偷懒，不是凑数找毛病。
+
+## 其他审读线索
+
+- **空泛铺垫与伪深度**：只有预告作用的开场、无解释力的格言、没有真实反对者的自我辩护——删掉不损失事实/判断/逻辑的就删
+- **重复与公式化节奏**：标题后复述标题、段尾重复结论、同义堆叠、无内容需要却强凑的三段式
+- **聊天与编辑过程残留**：「下面让我们看看」、上一稿改动说明、无内容问候
+- **中文句式负担**：层叠的「的」、「进行＋动词」、连续被动、过长定语——以施事者和关系是否清楚为准，不为口语化牺牲术语
+
+## HKR 质检
+
+- **H（Happy）**：阅读理由是否准确明确——不靠夸张标题、制造焦虑或虚构悬念
+- **K（Knowledge）**：有信息量吗？读完能学到新东西吗
+- **R（Resonance）**：该有共鸣的类型（叙事/复盘）是否形成真实共鸣，而不是强行抒情
+
+新闻简报以 K 为主，R 低不构成失败，不为 R 编造经历。
+
+## 意见输出格式
+
+每条意见包含：
+
+1. 具体位置或原句
+2. 可观察的问题及对阅读的影响
+3. 修改时必须保留的信息和确定程度
+4. 建议方向（不是只贴模式标签）
+
+最后给一行 HKR 评分（★★★☆☆ 式）与一句话总评。
+
+---
+
+致谢：本手册的语义保真框架与「模式不是禁词表」原则改写自 [mp-article-writor](https://github.com/balabalabalading/huuuuuuho-skills/tree/main/skills/mp-article-writor)（MIT）；AI 味指纹与阈值化防误判改写自 [wechat-article-skills](https://github.com/aiworkskills/wechat-article-skills)（Apache-2.0）的 ai-flavor-check 方法论。仅借方法，未复制其表达与依赖。

skills/le-wechat-article/references/style-rules.md

@@ -0,0 +1,61 @@
+# 公众号排版规则与产出配额
+
+移动端阅读优先。本文分三部分：Markdown 硬规则（`check_article.py` 会核验）、标点与措辞规范、产出配额。
+
+## 一、Markdown 硬规则（机器可查）
+
+公众号编辑器对粘贴内容的支持有限，这些规则直接决定粘贴后成不成形：
+
+1. **标题层级**：全文只允许一个 `#`（文章主标题，仅作记录用，粘贴时不进正文）；正文章节一律 `###`，不用 `##`、`####`——`###` 转换后与公众号原生标题字号最接近
+2. **表格**：默认不写 Markdown 表格（移动端展示差）；确需表格时不超过 3 列且每格文字极少，否则改写成列表
+3. **图片语法**：`![中文说明](相对路径)`，独占一行，前后空行。说明写清画面内容（「淘米」「小孩钓鱼」级别的概括即可），不写「示意图」「配图」这类敷衍词。**使用他人图片须标注来源与授权状态**；无授权的素材宁可不用
+4. **摘要**：front matter `digest` 80–120 字（微信上限 120），概括核心价值而非复述开头；与正文导语不得逐字相同
+5. **代码**：行内用反引号；代码块用三反引号围栏并标注语言，不用四空格缩进。不为展示贴大段代码
+6. **加粗**：`**文字**`，不连用下划线变体；斜体中文不用（中文字形不适合倾斜）
+7. **占位残留**：交付时正文中不得残留 `placeholder`、TODO 标记
+8. **段落**：段与段之间空一行；一句话自成一段只在确需强调时用
+
+## 二、标点与措辞规范
+
+- **中英文间距**：汉字与英文字母、数字之间有且仅有一个半角空格（`用 Python 3 写了 5 个脚本`）；中文标点紧邻英文时不加空格
+- **引号**：中文引用统一直角引号「」，嵌套用『』；不用弯引号""做中文引用
+- **专有名词**：按官方写法（macOS、iOS、GitHub、ChatGPT）；有通用中文译名的优先中文，译名不通行时首次出现标注 `中文译名（Original Name）`
+- **缩略语**：首次出现括注全称（除非广为人知）
+- **省略号**：用……，不用三个句点
+- **日期**：完整句中用 `2026 年 10 月 5 日` 式汉字单位表达；提国外事件标注当地时间换算
+- **工具名精度**：素材指向具体产品时用准确名称；素材没说名称时保留「某个模型」「AI 工具」等概括表达，不猜名字装具体
+- **链接**：链接文本要能说明目标内容，不用「点击这里」「这篇」；清理短链和跟踪参数
+
+## 三、产出配额（不靠自觉，脚本核验）
+
+这些配额的原理：公众号读者在手机上扫读，**加粗和标题是他唯一稳定看到的强调手段**。语法规则模型都会照做，但没有配额就一处都不产出——实测不写配额时金句卡 0/10 篇、正文加粗 0/5 篇。
+
+- **加粗 = 划重点**
+  - 验收标准：全文加粗按顺序连读，是一篇能独立看懂的缩写版。读起来像词云（「效率/架构/落地」）或像把段落重念一遍，都是挑错了落点
+  - 密度：每 100 字左右一处（手机约 4–5 行），连续 200 字不得没有；每个 `###` 小节至少一处；结尾段也要有
+  - 每处加粗要能独立看懂：数字连着它的意思（`**省 88% Token**`），判断连着它的对象（`**打断不等于撤销**`）
+  - 不加粗整句空泛概括；不在每段首句同一位置加粗；一段最多两处
+- **摘要 ≠ 导语**：front matter `digest`（进公众号后台的摘要）与正文开头导语不得逐字相同——读者会同一句读两遍
+- **金句卡至多一处**：全文最有转发价值的那句写成 `> 金句。 —— 出处`；两处以上卡片退化成装饰条；不带出处就是普通引用
+- **枚举用列表**：三项以上并列写成 `- **标签**：说明`，不压进一个长段落
+- **`---` 分隔**：只在明显转场处用，独占一行
+- **图位密度**：大纲阶段按下表选一档（统一词汇，不各说各话），写完自查数量：
+
+  | 密度档 | 就是说 |
+  |---|---|
+  | 每节一图 | 每个 `###` 小节各配一张，不多不少（未指定时的默认档） |
+  | 按需配图 | 只在文字讲不清的地方配（流程、对比、数据），其余不配 |
+  | 少图 | 全篇只配 1–2 张最关键的 |
+  | 多图 | 每 2–3 个自然段配一张 |
+
+  信息位文字逐字取自文章，节奏位不加文字，两者都不影响的图位删掉
+
+## 标题
+
+交付时给 3 个候选，混两种以上风格（悬念 / 干货 / 数字 / 反问 / 故事），并注明各自打法。**禁用套路**（命中即重起）：浅谈、万字长文、建议收藏、震惊、不转不是中国人、UC 震惊体、过度夸张的承诺；数字型标题里的年份写当年，不照抄示例。
+
+## 起始与收尾
+
+- 开头按类型路由走（见 [article-types.md](article-types.md)）；共同底线：不用「在当今…的时代」「随着…的发展」等零信息背景铺垫——时间与趋势本身是素材事实时才保留
+- 高频连接词（首先/其次/最后/综上所述/值得注意的是/不难发现/让我们）只在承担真实顺序、转折、总结功能时保留，纯铺垫删掉
+- 结尾按文章内容自然收束；**不自动追加**关注引导、账号名、推广信息——只有 Leroy 在当次任务明确要求或作者画像明确配置时才加

skills/le-wechat-article/references/topic-facts.md

@@ -0,0 +1,33 @@
+# 常用事实卡
+
+写作涉及 Leroy 自己的项目、工具链或经历时必读本卡，取用其中事实可免于重新询问；本卡没写的事实仍按事实核查规则处理（问 Leroy 或标待确认）。与作者画像分工：**画像管风格，事实卡管事实**。
+
+## 使用方式
+
+- 写作第 2 步（校准）时与作者画像一起加载
+- 空着不影响流程；Leroy 随时口述更新，改完即时生效
+- 本卡属于个人资产，内容不复制进文章交付物（文章引用的是最终表述，不是卡片原文）
+
+## 项目与产品
+
+（每个常写的项目一条：名称、一句话定位、关键链接、当前版本/状态）
+
+- （待填写，如：MetaSkill —— Leroy 的 Agent Skill 工坊项目，…)
+
+## 工具链与环境
+
+（常在文章里出现的工具及其准确名称/版本约定，防拼写与版本张冠李戴）
+
+- （待填写，如：主力模型 GLM-5.3；编辑器 ZCode / Claude Code / Codex …）
+
+## 经历时间线
+
+（常被引用的个人经历：事件 + 绝对日期，防时间漂移）
+
+- （待填写，如：2026-09 开始运营公众号 …）
+
+## 固定表述
+
+（对同一事物统一说法，如产品名中英文、缩写约定）
+
+- （待填写）

skills/le-wechat-article/references/visual-production.md

@@ -0,0 +1,61 @@
+# 视觉生产手册
+
+封面与正文解释性插图的生产方法。核心原则：**配图是内容的一部分，不是装饰**——信息位图上的文字逐字取自文章，封面上的是这篇文章的标题，不是好看的背景。
+
+## 封面规格（硬约束）
+
+- 比例 **2.35:1**（建议 1200×509 或更大，微信信息流首图比例）
+- **标题主体放中央安全区**：微信会另裁一张 1:1 的方形分享卡（默认居中裁），主体偏左或偏右会被裁掉字——同步草稿箱时脚本会提交两个裁剪框参数，但设计上就要满足「中心裁一块 1:1 不丢主信息」
+- 图上主标题 **4–7 字**最佳，字高占画面 25–35%；缩略到 345px 宽（信息流实际尺寸）主体仍一眼可辨——这是验收标准，不满足重做
+
+## 封面七步推导
+
+不要「想一个好看的画面」，按顺序走：
+
+1. **找张力**：这篇文章里什么打破了什么 / 什么变成了什么？（「手写模板 → 自动生成」「一台机器 → 十三台」）张力即画面
+2. **定关系**：对比 / 流程 / 层级 / 汇聚 / 转折——关系的类型决定构图骨架
+3. **找隐喻**：把抽象张力翻译成具体物件。**避雷**：机器人、发光大脑、齿轮堆、赛博蓝紫渐变——这些是 AI 生图的默认值，出现即平庸
+4. **选形态**（从下表挑一个，不混搭）
+5. **布局**：左文右图 / 上题下景 / 中央大字，按形态模板走
+6. **写成 brief**：一段 150–300 字的散文描述（给 ckm-banner-design 或生图模型），含标题文案、字体感、颜色、位置
+7. **缩略图回看**：345px 下看主体可辨、标题完整；不过关回到对应步骤重做，不盲目重跑
+
+## 封面形态速查
+
+| 形态 | 适合 | 要点 |
+|---|---|---|
+| 纯色大字 | 观点、宣言 | 底色克制，字即主体 |
+| 数字冲击 | 数据结论 | 一个大数字 + 一句限定，防断章取义 |
+| 图上压字 | 叙事、体验 | 底图留白充足，压字区加暗色遮罩 |
+| 对比式 | 前后变化 | 左右分栏，箭头/裂隙点题 |
+| 扁平插画 | 方法、教程 | 元素 ≤3，不写实 |
+| 截图标注 | 产品更新 | 真实界面 + 标注，最可信 |
+| 信息表 | 评测、清单 | 封面即结论摘要 |
+| 场景实拍 | 生活叙事 | 有人的真实场景优于摆拍 |
+
+## 正文解释性插图
+
+- **信息位**（删图读者看不懂）：图上文字**逐字取自文章**，不自由发挥——让模型自由发挥会生成无关鸡汤并自带 emoji
+- **节奏位**（删图读者读不下去）：概念隐喻或场景，图上不加文字
+- **手绘媒介**：同一篇内统一一种媒介，篇与篇之间轮换，避免整个号只有一种图。媒介池：马克笔白板 / 方格笔记本 / 便签 / 黑板粉笔 / 牛皮纸手绘 / 终端等宽 / 打印稿批注 / 扁平矢量
+- **实证图**（真实截图/照片）：优先作为证据直接使用，不重绘产品界面当证据；需要标注/放大/对比时才加工
+
+## 与 ckm-banner-design 的联动协议
+
+需要直接生成封面图时，把 brief 交给 ckm-banner-design 执行，brief 必须包含：
+
+1. 比例 2.35:1 与目标像素
+2. 主标题文案（4–7 字）与短标题（1:1 分享卡用，2–4 字）
+3. 视觉张力一句话 + 形态名 + 避雷项（AI 默认视觉）
+4. 风格媒介（从媒介池指定一种）
+5. 验收点：345px 缩略可辨、标题完整、中央 1:1 安全区无关键信息丢失
+
+产出后按「缩略图回看」验收；不合格改 brief 重生，不改用其他工具绕开。
+
+## SVG 自绘路径（零依赖替代）
+
+没有生图管线时，几何类信息图（流程、对比、曲线、分层）用 SVG 手绘完全够用，且比 AI 生图**文字更可靠**（不会出缺字错字）：SVG 源文件放 `imgs/src/`，浏览器打开后按目标尺寸截屏导出 PNG。曲线/管道/卡片类图优先走这条路；只有需要插画质感时才必须用生图。封面同样可 SVG 自绘（文字型封面 = 纯色大字形态，正是最稳的封面形态之一）。
+
+---
+
+致谢：封面七步推导、形态库与媒介轮换方法改写自 [wechat-article-skills](https://github.com/aiworkskills/wechat-article-skills)（Apache-2.0）的 cover-method / image-method；组合封面安全区意识来自 [mp-article-writor](https://github.com/balabalabalading/huuuuuuho-skills/tree/main/skills/mp-article-writor)（MIT）的视觉路由。仅借方法。