Skill: lovensky1992-wk/wemp-ops (version 1.0.4)

--- name: wemp-ops version: 1.0.0 description: > 微信公众号全流程运营：选题→采集→写作→排版→发布→数据分析→评论管理。 Use when: (1) 用户要写公众号文章或提供了选题方向, (2) 用户说"写一篇关于XXX的文章"/"帮我写篇推文"/"出一篇稿子", (3) 用户要求采集热点/素材/竞品分析, (4) 用户提到公众号日报/周报/数据分析/阅读量/粉丝, (5) 用户要求检查评论/回复评论/评论管理, (6) 用户说"发布"/"推送"/"推到公众号"/"发到草稿箱", (7) 用户讨论文章排版/封面图/标题优化。 即使用户没有明确说"公众号"，只要涉及微信文章写作、内容发布、 公众号后台操作、文章数据查看、或读者互动管理，都应使用此技能。 当用户给出选题方向时，自动完成素材采集→内容写作→封面生图→排版美化→推送草稿箱全流程。 NOT for: 小红书运营（用 xiaohongshu-ops）、纯内部文档写作（用 internal-comms）、 通用 Word 文档（用 docx）。 --- # wemp-ops — 微信公众号运营技能 ## 环境检查 首次使用前执行： ```bash node scripts/setup.mjs ``` 检查 Node.js 版本、Python3、微信公众号 API 配置。 ## 工作流路由 根据用户意图选择对应流程： | 意图 | 流程 | |------|------| | "写一篇关于 X 的文章" | → **全流程**（下方详述） | | "采集 X 热点" | → 仅采集 | | "公众号日报/周报" | → 数据分析 | | "检查/回复评论" | → 互动管理 | | "发布文章" | → 仅发布 | | "选题/有什么可以写的" | → 选题管理（检查 topic-pool.md） | ## 全流程：选题到草稿箱 当用户给出选题方向时，执行以下完整流程。先读 `persona.md` 确定写作人设。 ### Step 0: 选题准备 **如果老板没有指定具体选题**，先检查选题池： 1. 读取 `<WORKSPACE>/collections/topics/topic-pool.md` 2. 列出当前高优选题，每个附带角度和素材情况 3. 让老板选择，或老板提出新选题 4. 选定后进入 Step 1 **如果老板已有明确选题**，直接进入 Step 1。 ### Step 1: 理解选题 读 `references/article-templates.md` 判断内容类型： - **AI 产品拆解** — 具体产品名 + 分析/拆解 - **场景解决方案** — "怎么用 AI 做 XXX" - **效率提升实战** — 工具 + 技巧/心得 - **产品方法论** — 抽象话题 + 思考 - **行业观察** — 新闻/趋势 + 观点 选题模糊时给 2-3 个具体方向让用户选（最多 1 轮澄清）。 ### Step 2: 素材采集 **2pre. 交接文件检查** 先检查 `<WORKSPACE>/temp/handoffs/collector-to-writing.md` 是否存在： - 有 → 读取，筛选与当前选题相关的素材条目，纳入写作参考 - 消费后删除已使用的条目（如果文件清空则删除文件） - 没有 → 跳过，正常流程 **2a. 收藏库检索（优先）** 先从个人收藏库中检索相关素材——这是让文章有"人味"的关键（详见 writing-techniques.md §五）： 1. 标签匹配：`grep -i "关键词" <WORKSPACE>/collections/tags.md` 2. 全文搜索：`grep -ril "关键词" <WORKSPACE>/collections/` 3. 有匹配时，读取对应文件的核心观点、要点摘录、个人笔记 4. 标记可用素材的使用场景：开头引入？观点支撑？案例展示？反面论据？ 5. 收藏素材用自己的话重新表述，自然融入文章，不是学术式引用 **2b. 外部采集（补充）** 收藏库素材不足时，从外部补充： 1. 根据选题扩展 3-5 个搜索关键词 2. `web_search` 搜索 2-3 轮（官方信息→深度分析→对比评测） 3. `web_fetch` 抓取 2-4 篇高质量参考文章 4. 可选：`node scripts/smart_collect.mjs` 从 20+ 数据源采集相关热点 5. 提取关键事实、数据、观点备用 **⚠️ 中间存盘规则**：每 2-3 轮 web_search/web_fetch 后，立刻把已获得的关键发现写到 `<WORKSPACE>/temp/wemp-findings-{slug}.md`（选题 slug），防止连续采集时前面的信息在 context 中被挤掉。采集完成后此文件可删除。 **2c. 素材整理** 合并收藏库 + 外部素材，按相关度排序，标注来源 **2d. 对标账号分析（可选，首次写某领域时推荐）** 找 2-3 个同领域做得好的公众号，填写对标颗粒度检查表： | 维度 | 对标账号 | 我们 | 差异说明 | |------|---------|------|---------| | 文章长度 | | | | | 标题风格 | | | | | 开头结构（故事/数据/问题/金句） | | | | | 配图风格和数量 | | | | | 排版密度（段落长度/留白） | | | | | 结尾 CTA（关注/转发/留言） | | | | | 发布频率 | | | | **每个不一致都要有理由，否则改成一致。** 0 到 1 阶段模仿是正确答案。 **2e. 素材丰富度门禁（写作前必检）** 写作前过一遍素材储备，5 维中至少 3 个有料才开始写。不够就回 Step 2 补采集，不要硬写。 | 维度 | 有没有 | 具体内容 | |------|--------|---------| | 冲击力数据（大数字/百分比/对比） | ✅/❌ | | | 转变故事（之前 vs 之后，反差越大越好） | ✅/❌ | | | 金句（能独立传播的一句话观点） | ✅/❌ | | | 权威背书（人物/机构/论文/官方数据） | ✅/❌ | | | 痛点共鸣（目标读者的焦虑/常见错误） | ✅/❌ | | - **0-2/5** → ⛔ 停止，回 Step 2 补充。素材不够硬写 = 进入「内容差→没流量→以量取胜→内容更差」的死亡螺旋 - **3-4/5** → ⚠️ 可以写，但开头冲击力受限。标注薄弱维度，写作中刻意补强 - **5/5** → ✅ 素材充足，放心写 ### Step 3: 写作 读 `references/writing-sop.md`、`references/style-guide.md` 和 `references/writing-techniques.md`，按以下流程写作： **3a. 创意排水（正式动笔前必做）** 花 2-3 分钟快速列出这个选题的"废水"——套路想法、陈词滥调、第一反应。标记为禁用列表，正式写作中刻意避开。（详见 writing-techniques.md §一） **3b. 正式写作** - 遵循 `persona.md` 人设（AI 产品经理第一人称） - 按 `references/article-templates.md` 对应类型的结构模板 - 2000-3000 字，短句为主 - 链接用纯文本格式 - 输出为 Markdown 文件，保存到工作目录（文件名格式：`draft-v1.md`，放在当前文章的工作目录下，如 `wemp-article-NN/draft-v1.md`） - **不要在文中出现 H1 标题**（公众号自带标题，正文从 H2 开始） - 融入收藏库素材（Step 2 中检索到的真实经历/观点/案例） 写作中运用五大技巧（详见 writing-techniques.md §二）： - **微幽默**：每 200 字至少 1 个嘴角上扬的小细节 - **强开头**：禁止"在当今时代…"等套话。开头公式 = **话题（讲什么）+ Hook（为什么看）+ 可信度（为什么信你）**，三要素缺一不可。Hook 优先级：晒结果+反转⭐⭐⭐⭐⭐ > 数据冲击⭐⭐⭐⭐ > 反差/转变⭐⭐⭐⭐ > 金句⭐⭐⭐ > 权威+观点⭐⭐⭐ > 痛点+悬念⭐⭐⭐ - **概念把手**：为复杂概念创造 3-6 字记忆短语，每篇至少 1-2 个 - **句子节奏**：短/中/长句交替，不允许连续 3 句同长度 - **多巴胺密度**：每段至少 1 个"有意思"的点，连续 3 段没有 = 危险区域 **3c. 标题生成（双轨制）** 按 writing-techniques.md §四 生成标题候选： 1. 爆款标题 3-5 个（金钱数字/暴力隐喻/悬念等要素） 2. 自然风格标题 3-5 个（经验分享/观点输出/对比评测等） 3. 可选：组合优化（自然标题 + 注入 1-2 个爆款要素） 4. 推荐 Top 3 给老板选择 **悬念制造铁律**：标题和开头制造悬念，不给答案。用「为什么」不用「证明」。 - ❌ 「Computer Use 效率低，证明 API 才是正路」（给了答案，读者不想看了） - ✅ 「Claude 能操控微信了，为什么我说这不是未来？」（留悬念，想知道为什么） - ❌ 「Agent 的 3 个核心能力」（平铺直叙，无冲突） - ✅ 「为什么 90% 的 Agent 产品会在 6 个月内死掉？」（制造好奇） **3d. 三遍审校** 按 writing-techniques.md §三 结构化审校： - 第一遍：内容审校（事实/逻辑/结构）+ 段落迷你论点串联测试 - 第二遍：风格审校（对照 24 条 AI 味特征清单降 AI 味 + 灵魂注入 + 5 维质量评分 ≥ 35 分才过） - 第三遍：细节打磨（句子节奏 + 多巴胺密度 + 微幽默 + 概念把手检查） #### ⚠️ 写作红线 - **不暴露 AI 参与写作**：不说"这篇文章是 AI 写的"、"让 AI 帮我写"等 — 读者对 AI 生成内容有抵触心理，暴露会显著降低阅读量和信任感 - **讲故事，不讲论点**：用时间线、场景、情绪推进，不用"总结"、"核心观点"、编号式论点堆砌 - **自然过渡**：不用中括号小标题、不用"以下是 N 条心得"式结构 - **让读者感受到力量**：分享经历，不是教学。有踩坑有收获，有真实细节 - **禁止废水开头**：不用"在当今 XX 的时代…"、"随着 XX 的不断发展…"等陈词滥调 ### Step 4: 封面图 设计指南见 `references/cover-image-guide.md`（六维度体系：Type/Palette/Rendering/Text/Mood/Font + 12 个预设 + 兼容矩阵 + 构图核心原则）。三种方案按优先级： **方案 A（优先）：idealab Chat API** - `<WORKSPACE>/scripts/generate-image.sh --prompt "prompt" --filename output.jpg` - 默认模型 `gemini-3.1-flash-image-preview`，团队 AK 免费，走 /chat/completions 接口 - 2.35:1 裁剪：生成后 `sips -c 1090 2560 output.jpg` - 超时/报错时脚本自动降级到 Gemini Key 轮换 - ⚠️ 不用 emoji（浏览器截图会变色块），用纯文字 + 几何图形 **方案 B（降级）：Seedream 5.0 Lite** - `<WORKSPACE>/scripts/seedream-generate.sh "prompt" output.jpg "2560x1440" 1` - 0.22 元/张，idealab 不稳定时使用 - 裁剪同方案 A：`sips -c 1090 2560 output.jpg` **方案 C（兜底）：HTML 渲染 + 浏览器截图** - 写一个 HTML 页面（渐变背景 + 标题文字 + SVG 图形） - 用 `python3 -m http.server` 本地启动 - 用 browser 工具 navigate + screenshot 截图 - 适用于需要精确控制布局时 ### Step 4.5: 配图规划与生成 完整指南见 `references/illustration-prompts.md`（Type×Style 矩阵、Prompt 规范、风格锚点）。 **4.5a 配图规划（先规划再生图）** 1. **扫描文章结构**，按以下规则标注潜在配图位置： - `##` 标题后的第一段 → 潜在配图点 - 概念首次出现 → 用插图辅助解释 - 转折/对比处（"但是"、"然而"、"相比之下"）→ 适合对比图 - 连续超 800 字无任何视觉元素 → 需要打断 2. **内容信号自动匹配**，根据段落关键词推荐 Type： - 架构/分层/系统 → `framework` | 步骤/流程 → `flowchart` | vs/对比 → `comparison` - 数据/百分比 → `infographic` | 叙事/经历 → `scene` | 代码/界面 → `screenshot` 3. **锁定全文 Style**（一篇文章只用一种 AI 生图风格，从 `cover-image-guide.md` 预设中选）： - 技术/产品文 → `ai-product`（默认）| 数据/架构文 → `dashboard` | 故事/教育文 → `pm-growth` | 观点文 → `bold-opinion` 4. **输出配图计划表**（保存到 `illustration-plan.md`），让老板确认后再生图。 密度参考：2000 字 3 张、3000 字 4-5 张，正文配图硬上限 5 张。 **4.5b 生图执行** 配图有两条渲染路径，在配图计划表中按每张图标注： **路径 A：AI 生图**（视觉美感优先，适合大部分场景） - **优先级**：idealab Image API → Seedream 5.0 Lite → Gemini 生图 → ComfyUI - idealab（首选）: `<WORKSPACE>/scripts/generate-image.sh --prompt "prompt" --filename output.jpg --size 2560x1440` - 默认模型 `gemini-3.1-flash-image-preview`，团队AK免费；超时/报错自动降级到 Gemini - Seedream（降级）: `<WORKSPACE>/scripts/seedream-generate.sh "prompt" output.jpg "2560x1440"` - 正文插图 16:9 `2560x1440` - **Prompt 按 LDSCS-R 六层结构构造**：Layout → Data → Semantics → Characters → Style → Ratio - **风格锚点**：第一张图成功后，记录风格特征到 `prompts/style-anchor.md`，后续图片引用保持一致 - **Prompt 持久化**：每张图的 prompt 保存到 `prompts/NN-{type}-{slug}.md`，便于回溯修改 **路径 B：Mermaid 渲染截图**（信息精确性优先，技术文章的流程/架构/对比图） - **适用条件**：配图计划中 Style 标注为 `mermaid-render` 的插图 - **工作流**： 1. 生成 Mermaid 代码（遵守 `references/illustration-prompts.md` 中的 Mermaid 规范） 2. 写入 `<WORKSPACE>/scripts/mermaid-render.html`（临时 HTML 模板） 3. 浏览器打开 → resize 2560x1440 → screenshot 4. 裁剪白边（如需要）→ 存入 `images/` - **Mermaid prompt 也持久化**：保存到 `prompts/NN-{type}-{slug}.md`，记录 Mermaid 源码 **通用规则**： - 截图美化：`<WORKSPACE>/scripts/beautify-screenshot.sh <input> [output] --shadow --bg "#f5f5f5"` - 水印去除：`<WORKSPACE>/scripts/remove-watermark.sh <input> [output]`（Gemini 生图 需去水印） - 配图数量：宁缺毋滥。不确定要不要配图 → 不配。 - 同一篇文章中路径 A 和路径 B 可以混用，但渲染方式不超过 2 种。 ### Step 4.6: 产品截图获取 文章涉及线上产品（AI 工具、SaaS 产品等）时，截取真实产品界面作为配图。 **公开页面（无需登录）：** ```bash # 1. 打开产品页面 browser action:open url:"https://example.com/product" # 2. 等待加载完成后截图 browser action:screenshot fullPage:false type:png # 3. 裁剪/缩放（macOS sips 工具） sips -z <高度> <宽度> screenshot.png # 缩放 sips -c <高度> <宽度> screenshot.png # 裁剪居中 sips --resampleWidth 800 screenshot.png # 按宽度等比缩放 # 4. 上传到微信素材库 node scripts/publisher.mjs # 通过 --markdown 自动上传 # 或手动：在 utils.mjs 中调用 uploadArticleImage() ``` **需登录页面（付费产品/内部系统）：** 1. 让用户在 Chrome 打开目标页面 2. 用户点击 OpenClaw Browser Relay 工具栏图标 attach 该 tab 3. `browser action:screenshot profile:chrome` 截图 4. 截图后同上流程裁剪上传 **截图规范：** - 宽度 600-900px，避免过大（微信有尺寸限制） - 隐藏/打码敏感信息（用户名、私有数据等） - 浏览器地址栏按需保留（能说明产品来源时保留） - 优先截取核心功能区域，不截全屏 - 深色/浅色主题根据文章风格选择 ### Step 5: 排版美化 ```bash # 基础排版 python3 scripts/markdown_to_html.py --input article.md --theme tech --output article.html # 带图片自动上传（本地图片自动上传到微信素材库并替换 URL） python3 scripts/markdown_to_html.py --input article.md --theme tech --output article.html --upload ``` 主题选择：tech（科技风，默认）、minimal（简约风）、business（商务风）。 排版约束详见 `references/weixin-constraints.md`。 #### Step 5.5: 外链转底部引用（微信外链不可点击问题） 微信公众号不支持外链点击跳转，文章中的外链对读者没有交互价值。排版时自动处理： **处理规则**： 1. 普通外链 `[text](https://example.com)` → 文中显示为 `text¹`（上标序号），链接收集到文末「引用链接」章节 2. `https://mp.weixin.qq.com/...` 链接保留为直接链接（微信内部链接可点击） 3. 裸链接（链接文本 = URL 本身）保留不动（已是展示型，读者可复制） 4. 没有外链的文章跳过此步 **文末引用格式**： ```markdown --- ## 引用链接 1. example.com: https://example.com/article 2. GitHub: https://github.com/user/repo ``` **执行时机**：Markdown 转 HTML 之前处理（在 Markdown 层面替换，不是 HTML 层面）。可在 `markdown_to_html.py` 中集成，或作为单独的预处理步骤。 如果有额外配图需要手动插入（非 Markdown 内嵌图片），先上传再手动插入 HTML。 ### Step 6: 推送草稿箱 ```bash # 一键从 Markdown 到草稿（推荐，自动转 HTML + 上传图片 + 清理旧同名草稿） node scripts/publisher.mjs --markdown article.md --title "文章标题" --cover cover.png # 或手动分步：先转 HTML 再推送 python3 scripts/markdown_to_html.py --input article.md --theme tech --output article.html --upload node scripts/publisher.mjs --title "文章标题" --content article.html --cover cover.png # 跳过自动清理旧草稿 node scripts/publisher.mjs --markdown article.md --title "标题" --cover cover.png --no-cleanup # 列出草稿 node scripts/publisher.mjs --list # 删除草稿 node scripts/publisher.mjs --delete --media-id <id> # 发布草稿（用户确认后） node scripts/publisher.mjs --publish --media-id <草稿media_id> ``` **默认停在草稿箱，不自动发布。** 告知用户草稿已创建，确认后再发布。 推送新版本时自动清理同标题旧草稿（`--no-cleanup` 跳过）。 ### Step 6+: 发布数据回流（推送草稿箱后自动执行） 推送草稿箱成功后，顺便采集历史文章数据，用于选题评分校准。 ``` 1. browser(action=tabs, profile="user") 检查是否有 mp.weixin.qq.com tab 2. 有 → browser(action=snapshot, targetId=<tab_id>) 读取发表记录页 3. 从 snapshot 提取每篇文章的：标题、阅读量、点赞、分享、留言 4. 自动更新 collections/topics/publish-feedback.md 5. 没有 tab 或 snapshot 失败 → 跳过，不影响主流程 ``` 注意：此步不影响主流程，失败就跳过。数据用于选题评分校准（见 eval-criteria.md + publish-feedback.md）。 ### Step 6.5: 五维内容自检（交付前必做） 排版完成后、交付前，逐维度自检。任何一项 ❌ 必须修改后再进入下一步。 | 维度 | 检查问题 | 合格标准 | 判断 | |------|---------|---------|------| | **文字洁癖** | 有没有 AI 味？（空洞排比句、Emoji 堆叠、"让我们来看看"） | 每句话都有信息量，没有填充语 | ✅/❌ | | **标题/封面** | 平铺直叙能不能吸引人？不看封面只看标题想不想点？ | 有立场/反差/数据之一，不靠震惊体 | ✅/❌ | | **表达效率** | 能不能一句话说清核心观点？有没有 99% 时间包装 1% 内容？ | 删掉任何一段，整篇不完整 = 没有冗余 | ✅/❌ | | **认知落差** | 读完后读者会不会觉得「这个我知道」？和同行比有增量吗？ | 至少有 1 个「我之前没想到」的点 | ✅/❌ | | **数据支撑** | 核心判断有没有数据/事实/一手经验支撑？ | 每个核心判断都有来源（数据/案例/亲身经历） | ✅/❌ | > 借鉴 dbs-content 五维诊断框架。第五维从「AI 辅助」改为「数据支撑」，更适合公众号写作场景。 ### Step 7: 读者测试（可选但推荐） 交付前，用一个无上下文的子 Agent 阅读文章全文，检查： - 标题是否让人想点开？（不知道背景的人能否被吸引） - 开头两段是否抓住注意力？（3 秒法则） - 是否有行业黑话/未解释的概念？（非目标读者能否理解） - 结尾是否有力？（读完后想做什么） 如果子 Agent 发现盲点，修改后再交付。 ### Step 8: 风格学习采集 **写作完成时自动执行，不需要老板操作。** 在 Step 3 写作完成（draft-v1.md 定稿）后，自动记录 AI 原稿： ```bash python3 <WORKSPACE>/scripts/style-observe.py record-original <工作目录>/draft-v1.md --skill wemp-ops --topic "选题关键词" ``` 当老板确认最终版（可能经过多轮修改）后，记录最终版： ```bash python3 <WORKSPACE>/scripts/style-observe.py record-final <最终版文件> --skill wemp-ops ``` **触发 record-final 的信号**： - 老板说"可以了"/"发吧"/"推到草稿箱" - 老板手动修改后把最终版发回来 - 文章已发布（从草稿箱发布 = 确认最终版） **如果老板没有修改直接发布**，也要 record-final（no_change = 正反馈，说明这次写得好）。 积累 5+ 对 diff 后，可执行风格规则提取： ```bash python3 <WORKSPACE>/scripts/style-observe.py pairs --skill wemp-ops --days 30 ``` ### Step 9: 交付 向用户汇报：文章标题、字数、草稿状态、封面预览、建议发布时间。 ## 仅采集 ```bash node scripts/smart_collect.mjs --query "用户需求" --keywords "AI扩展的关键词" --sources "hackernews,v2ex,36kr" [--deep] ``` 数据源分类： - `tech`: hackernews, github, v2ex, sspai, juejin, ithome, producthunt - `china`: weibo, zhihu, baidu, douyin, bilibili, toutiao, tencent, thepaper, hupu - `finance`: 36kr, wallstreetcn, cls 采集后整理为选题候选清单，每条含：标题、来源、热度、链接、与用户需求的相关度。 ## 数据分析 ```bash # 日报（默认昨天） node scripts/daily_report.mjs [--date YYYY-MM-DD] # 周报 node scripts/weekly_report.mjs ``` 输出包含：用户增长、阅读数据、热门文章、互动数据、AI 洞察。 ## 互动管理 ```bash # 检查新评论 node scripts/check_comments.mjs # 回复评论 node scripts/reply_comment.mjs --comment-id <id> --content "回复内容" ``` AI 生成回复建议时遵循 `persona.md` 的语气规范，用户确认后再执行回复。 ## 配置 公众号凭证配置在 **skill 自己的** `config/default.json`： ```json { "weixin": { "appId": "你的AppID", "appSecret": "你的AppSecret" } } ``` ⚠️ **不要写到 `openclaw.json` 的 `channels` 里！** `channels` 只接受 OpenClaw 内置渠道类型（dingtalk/telegram/discord 等），写入未知类型会导致 gateway 校验失败并不断重启。 其他配置（数据源偏好、报告时间等）同样在 `config/default.json` 中调整。 --- ## 多版本分发（一篇→多平台） 公众号文章完成后，可一键生成其他平台版本。 ### 触发词 - "把这篇文章分发到小红书/X" - "生成多平台版本" - "同步到其他平台" ### 分发流程 #### Step 1: 读取源文章 从公众号草稿箱/已发布文章中提取：标题、正文、核心观点、配图 #### Step 2: 生成小红书版本 自动调用 `xiaohongshu-ops` 技能： 1. **标题**：从公众号标题中提炼，加 emoji，≤20 字 2. **正文**：缩写到 300-600 字，口语化改写，去掉长段落 3. **配图**：从公众号文章中选 1-3 个核心观点，制作信息卡（Seedream 优先，备选 Gemini 生图 / HTML截图） 4. **标签**：5-10 个小红书话题标签 5. 通过 openclaw browser 发布到创作中心 #### Step 3: 生成 X/Twitter 版本 1. **单条推文**（≤280 字符）：提炼文章最核心的一个观点，英文或中文 2. **Thread 版本**（可选）：3-5 条推文，适合深度内容 3. 通过 openclaw browser 发布（参考 TOOLS.md 中的 X 发帖 SOP） 4. 发帖前**先让老板确认内容** — 外部发布是不可撤回的操作，确认能避免事后删帖的尴尬 #### Step 4: 记录分发状态 在公众号文章对应的 memory 记录中标注已分发平台和链接 ### 改写原则 - 每个平台版本**重新改写** — 直接复制粘贴会被平台算法降权，且不同平台的受众期待和内容格式差异很大 - 小红书：口语化、短句、emoji 多用、互动提问结尾 - X/Twitter：精炼、有冲击力、适合英文受众（如有） - 保持核心观点一致，但表达方式适配平台调性 --- ## 下一步建议（条件触发） 文章完成后，根据结果判断是否推荐下一步。 | 触发条件 | 推荐 | |---------|------| | 文章已发布成功 | 「文章已发布。要分发到小红书/X 吗？或者用 content-collector 存档素材方便下次复用。」 | | 写作过程中发现素材不足 | 「素材不够，建议先用 content-collector 搜索已有收藏，或 web_search 补充。」 | | 文章涉及会议纪要/内部沟通 | 「这篇更像内部文档，建议用 internal-comms 的格式。」 | | 需要配图但 Seedream/Gemini 生图效果不佳 | 「配图可以试试 drawio 画流程图/架构图替代。」 | --- ## 绝对不要做的事 写作和内容产出中，以下行为直接拉低质量，必须避免： 1. **不要说「每个人的写作风格不同」「见仁见智」** — 这是回避判断。有观点就直接说，标注来源 2. **不要建议「参考同行」而不给具体对标** — 「去看看别人怎么写的」是废话。要给就给具体账号、具体文章、具体写法 3. **不要用「干货满满」「深度好文」「建议收藏」** — 读者自己判断有没有干货，作者说「干货满满」等于自夸 4. **不要写空洞的排比句开头** — 「在这个时代……在这个节点……在这个浪潮中……」是 AI 八股文的标志 5. **不要堆叠修饰词** — 「极其重要的关键性底层核心逻辑」，一个词能说清的事不用四个 6. **不要开头就下结论** — 先给事实/故事/数据制造认知落差，结论放后面。开头下结论 = 读者没动力往下读 7. **不要用「让我们一起来看看」「接下来我们来聊聊」** — 这是视频口播语气硬塞进文章的结果，书面内容不需要这种过渡 8. **不要在没有数据支撑时写「据统计」「研究表明」** — 要么给出具体来源（谁的研究、哪年、样本量），要么不引用 --- ## 内联案例库 ### 正面案例（老板认可的产出） **案例 1：公众号 #6「Claude 能操控微信了」V3 定稿** > 去掉所有比喻，直接用数据说话。1900 字，聚焦 Computer Use vs API 一个视角。新增"Anthropic 自己优先走 MCP 接口"的关键发现。 - 成功要点：一篇文章只讲一件事；数据 > 比喻 > 术语；「50% 成功率」比任何比喻都有说服力 - 老板评价：确认 OK **案例 2：公众号 #5「Skills 不是低代码，但也不是 App Store」** > 从第一人称 AI PM 视角，讲自己用 Skills 的真实踩坑经历，有具体场景、有数据、有得失。 - 成功要点：讲故事不讲论点，经历 > 观点，场景 > 总结，有踩坑有收获 **案例 3：封面图 Seedream 生成** > 2560x1440 生成，裁剪 2.35:1 宽屏比例，简洁主体 + 深色背景 + 大字标题。 - 成功要点：封面不堆元素，一个主体 + 一行标题 + 干净背景 ### 反面案例（被打回的产出 + 打回原因） **反面 1：公众号 #6 V1 初稿（3100 字，被全面打回）** > 塞了 Computer Use + Agentic Engineering + 冷思考 + 一手实践 + 8 个名人引用，试图一篇文章讲完所有。 - 打回原因：❌ 内容太干太多读不动 ❌ 名人引用堆砌（8 处）❌ 点名反驳其他博主 ❌ 想讲的东西太多 - 教训：一篇文章只讲一件事。名人引用全文不超过 2-3 处。不要点名反驳他人文章，从现象切入。 **反面 2：公众号 #6 V2（1800 字，比喻牵强）** > 砍掉了多余内容，但用"开车 vs 高铁"比喻贯穿全文。 - 打回原因：❌ 比喻牵强，把事情搞复杂了 - 教训：比喻不是必须的。事实清晰时直接说更好。数据自己会说话。

path: README.md
content: # WeMP Ops

WeChat Official Account (公众号) full-stack operations skill for OpenClaw.

## Features

- 📝 **Topic Selection**: Auto-suggest topics from your topic pool
- 🔍 **Content Collection**: Search web, fetch articles, gather materials
- ✍️ **AI Writing**: Generate articles following style guides and templates
- 🎨 **Image Generation**: Create cover images and illustrations
- 📐 **Layout Formatting**: Convert Markdown to WeChat-compatible HTML
- 📊 **Analytics**: Track article performance and engagement
- 💬 **Comment Management**: Monitor and respond to reader comments

## Prerequisites

- OpenClaw agent environment
- Node.js 16+ and Python 3.8+
- WeChat Official Account API credentials (for publishing features)

## Installation

### Via ClawHub (Recommended)

```bash
clawhub install wemp-ops
```

### Manual Installation

1. Clone to `~/.openclaw/skills/wemp-ops`
2. Run setup:
   ```bash
   cd ~/.openclaw/skills/wemp-ops
   node scripts/setup.mjs
   ```

## Usage

Talk to your OpenClaw agent:

```
写一篇关于 AI 产品设计的文章
帮我采集今日热点
查看公众号日报
检查新评论
```

The skill guides you through: topic selection → material collection → writing → layout → publishing.

## Configuration

- `persona.md`: Define your writing persona
- `references/`: Style guides, templates, and techniques
- `config/`: API credentials for WeChat and image generation services

## License

MIT License - see [LICENSE](LICENSE) file


path: assets/templates/business.json
content: {
  "name": "business",
  "description": "商务风 - 深蓝金色，专业稳重",
  "styles": {
    "wrapper": "max-width:677px;margin:0 auto;padding:16px 8px;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI','PingFang SC','Hiragino Sans GB','Microsoft YaHei',sans-serif;color:#2c3e50;line-height:1.8;font-size:15px;",
    "h1": "font-size:24px;font-weight:700;color:#1a365d;margin:28px 0 16px;padding-bottom:10px;border-bottom:2px solid #c9a96e;",
    "h2": "font-size:20px;font-weight:700;color:#1a365d;margin:24px 0 12px;padding-left:12px;border-left:4px solid #c9a96e;",
    "h3": "font-size:18px;font-weight:600;color:#2c3e50;margin:20px 0 10px;",
    "h4": "font-size:16px;font-weight:600;color:#34495e;margin:16px 0 8px;",
    "p": "margin:12px 0;font-size:15px;line-height:1.8;color:#2c3e50;letter-spacing:0.5px;",
    "strong": "color:#1a365d;",
    "em": "color:#c9a96e;font-style:italic;",
    "code_inline": "background:#f0f4f8;color:#1a365d;padding:2px 6px;border-radius:3px;font-size:14px;font-family:'SF Mono',Consolas,monospace;",
    "pre": "background:#272822;border-radius:6px;padding:16px;margin:16px 0;overflow-x:auto;border-left:4px solid #c9a96e;",
    "code": "color:#f8f8f2;font-size:14px;line-height:1.6;font-family:'SF Mono',Consolas,monospace;white-space:pre-wrap;word-break:break-all;",
    "blockquote": "margin:16px 0;padding:12px 16px;background:#f0f4f8;border-left:4px solid #c9a96e;border-radius:0 4px 4px 0;color:#34495e;font-size:15px;",
    "ul": "margin:12px 0;padding-left:24px;",
    "ol": "margin:12px 0;padding-left:24px;",
    "li": "margin:6px 0;font-size:15px;line-height:1.75;color:#2c3e50;",
    "table": "width:100%;border-collapse:collapse;margin:16px 0;font-size:14px;",
    "th": "background:#1a365d;color:#fff;padding:10px 12px;text-align:left;font-weight:600;",
    "td": "padding:8px 12px;border-bottom:1px solid #e2e8f0;color:#2c3e50;",
    "tr_even": "background:#f7fafc;",
    "hr": "border:none;height:2px;background:linear-gradient(90deg,#1a365d,#c9a96e);margin:24px 0;",
    "img": "max-width:100%;border-radius:4px;margin:12px 0;border:1px solid #e2e8f0;"
  }
}


path: assets/templates/minimal.json
content: {
  "name": "minimal",
  "description": "简约风 - 黑白灰，极致可读性",
  "styles": {
    "wrapper": "max-width:677px;margin:0 auto;padding:16px 8px;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI','PingFang SC','Hiragino Sans GB','Microsoft YaHei',sans-serif;color:#333;line-height:1.85;font-size:15px;",
    "h1": "font-size:24px;font-weight:700;color:#111;margin:28px 0 16px;padding-bottom:8px;border-bottom:1px solid #ddd;",
    "h2": "font-size:20px;font-weight:700;color:#222;margin:24px 0 12px;",
    "h3": "font-size:18px;font-weight:600;color:#333;margin:20px 0 10px;",
    "h4": "font-size:16px;font-weight:600;color:#444;margin:16px 0 8px;",
    "p": "margin:12px 0;font-size:15px;line-height:1.85;color:#333;letter-spacing:0.3px;",
    "strong": "color:#111;",
    "em": "color:#666;font-style:italic;",
    "code_inline": "background:#f6f8fa;color:#d63384;padding:2px 6px;border-radius:3px;font-size:14px;font-family:'SF Mono',Consolas,monospace;",
    "pre": "background:#f6f8fa;border:1px solid #e1e4e8;border-radius:6px;padding:16px;margin:16px 0;overflow-x:auto;",
    "code": "color:#24292e;font-size:14px;line-height:1.6;font-family:'SF Mono',Consolas,monospace;white-space:pre-wrap;word-break:break-all;",
    "blockquote": "margin:16px 0;padding:10px 16px;border-left:3px solid #ddd;color:#666;font-size:15px;background:#fafafa;",
    "ul": "margin:12px 0;padding-left:24px;",
    "ol": "margin:12px 0;padding-left:24px;",
    "li": "margin:6px 0;font-size:15px;line-height:1.75;color:#333;",
    "table": "width:100%;border-collapse:collapse;margin:16px 0;font-size:14px;",
    "th": "background:#f6f8fa;color:#24292e;padding:10px 12px;text-align:left;font-weight:600;border:1px solid #ddd;",
    "td": "padding:8px 12px;border:1px solid #ddd;color:#333;",
    "tr_even": "background:#fafafa;",
    "hr": "border:none;height:1px;background:#ddd;margin:24px 0;",
    "img": "max-width:100%;border-radius:4px;margin:12px 0;"
  }
}


path: assets/templates/tech.json
content: {
  "name": "tech",
  "description": "科技风 - 蓝紫渐变，现代感",
  "styles": {
    "wrapper": "max-width:677px;margin:0 auto;padding:16px 0;font-family:-apple-system,BlinkMacSystemFont,'Segoe UI','PingFang SC','Hiragino Sans GB','Microsoft YaHei',sans-serif;color:#2d2d2d;line-height:1.8;font-size:15px;",
    "h1": "font-size:24px;font-weight:700;color:#1a1a2e;margin:28px 0 16px;padding-bottom:10px;border-bottom:3px solid #7c3aed;",
    "h2": "font-size:20px;font-weight:700;color:#1a1a2e;margin:24px 0 12px;padding-left:12px;border-left:4px solid #7c3aed;",
    "h3": "font-size:18px;font-weight:600;color:#333;margin:20px 0 10px;",
    "h4": "font-size:16px;font-weight:600;color:#555;margin:16px 0 8px;",
    "p": "margin:12px 0;font-size:15px;line-height:1.8;color:#333;letter-spacing:0.5px;",
    "strong": "color:#1a1a2e;",
    "em": "color:#7c3aed;font-style:italic;",
    "code_inline": "background:#f0ecff;color:#7c3aed;padding:2px 6px;border-radius:4px;font-size:14px;font-family:'SF Mono','Fira Code',Consolas,monospace;",
    "pre": "background:#1e1e2e;border-radius:8px;padding:16px;margin:16px 0;overflow-x:auto;",
    "code": "color:#cdd6f4;font-size:14px;line-height:1.6;font-family:'SF Mono','Fira Code',Consolas,monospace;white-space:pre-wrap;word-break:break-all;",
    "blockquote": "margin:16px 0;padding:12px 16px;background:linear-gradient(135deg,#f0ecff,#e8e0ff);border-left:4px solid #7c3aed;border-radius:0 8px 8px 0;color:#555;font-size:15px;",
    "ul": "margin:12px 0;padding-left:24px;",
    "ol": "margin:12px 0;padding-left:24px;",
    "li": "margin:6px 0;font-size:15px;line-height:1.7;color:#333;",
    "table": "width:100%;border-collapse:collapse;margin:16px 0;font-size:14px;",
    "th": "background:#7c3aed;color:#fff;padding:10px 12px;text-align:left;font-weight:600;",
    "td": "padding:8px 12px;border-bottom:1px solid #e5e5e5;color:#333;",
    "tr_even": "background:#f8f7ff;",
    "hr": "border:none;height:1px;background:linear-gradient(90deg,transparent,#7c3aed,transparent);margin:24px 0;",
    "img": "max-width:100%;border-radius:8px;margin:12px 0;"
  }
}


path: config/default.json
content: {
  "weixin": {
    "appId": "wx4d9bfa93bcaef664",
    "appSecret": "aea4c1ac10209d107d58d4128463fd0a"
  },
  "notification": {
    "channel": "webchat",
    "silent": false
  },
  "content": {
    "topics": ["AI", "大模型", "产品"],
    "defaultSources": ["hackernews", "v2ex", "36kr"],
    "language": "zh_CN"
  },
  "analytics": {
    "dailyReportTime": "09:00",
    "timezone": "Asia/Shanghai",
    "topArticles": 5,
    "historyDays": 30
  },
  "publish": {
    "defaultTheme": "tech",
    "autoPublish": false
  }
}


path: data/daily-history.json
content: {
  "reports": [
    {
      "date": "2026-04-11",
      "netGrowth": 0,
      "totalRead": 0,
      "totalUsers": 0,
      "generatedAt": "2026-04-12T16:37:38.543Z"
    },
    {
      "date": "2026-04-13",
      "netGrowth": 0,
      "totalRead": 0,
      "totalUsers": 0,
      "generatedAt": "2026-04-14T14:38:56.659Z"
    },
    {
      "date": "2026-04-15",
      "netGrowth": 0,
      "totalRead": 0,
      "totalUsers": 0,
      "generatedAt": "2026-04-16T13:18:38.396Z"
    }
  ]
}

path: evals/evals.json
content: {
  "skill_name": "wemp-ops",
  "evals": [
    {
      "id": 1,
      "eval_name": "article-from-topic",
      "prompt": "帮我写一篇关于AI如何改变电商运营的公众号文章",
      "expected_output": "应该走完素材采集→内容写作→封面生图→排版美化的完整流程",
      "assertions": [
        {"id": "env-check", "text": "执行环境检查或提到 setup.mjs", "type": "quality"},
        {"id": "material-collection", "text": "有素材采集/热点搜索步骤", "type": "quality"},
        {"id": "writing-structure", "text": "文章有清晰的结构（标题/引言/正文/结尾）", "type": "format"},
        {"id": "cover-image", "text": "提到生成封面图", "type": "quality"},
        {"id": "no-ai-exposure", "text": "不暴露AI参与写作", "type": "quality"},
        {"id": "draft-push", "text": "提到推送到草稿箱或通过API发布", "type": "quality"}
      ]
    },
    {
      "id": 2,
      "eval_name": "comment-management",
      "prompt": "帮我看看公众号最新文章的评论，有需要回复的吗",
      "expected_output": "应该使用公众号API获取评论列表并分析是否需要回复",
      "assertions": [
        {"id": "api-usage", "text": "提到使用微信公众号API获取评论", "type": "quality"},
        {"id": "comment-analysis", "text": "对评论内容进行分析/分类", "type": "quality"},
        {"id": "reply-suggestion", "text": "给出回复建议或草稿", "type": "quality"}
      ]
    },
    {
      "id": 3,
      "eval_name": "data-report",
      "prompt": "给我看看公众号这周的数据表现怎么样",
      "expected_output": "应该获取公众号数据并生成周报",
      "assertions": [
        {"id": "data-fetch", "text": "提到获取阅读量/粉丝/互动等数据", "type": "quality"},
        {"id": "report-structure", "text": "有结构化的数据报告格式", "type": "format"},
        {"id": "trend-analysis", "text": "包含趋势分析或同比/环比", "type": "quality"}
      ]
    }
  ]
}


path: evals/results/article-with-skill.md
content: # Eval: article-from-topic (WITH skill)

## 执行计划摘要
- 选题澄清：给出3个具体方向让老板选
- 素材采集：收藏库 grep + web_search 3轮 + smart_collect.mjs + web_fetch 2-4篇
- 写作：行业观察模板 2000-3000字，persona.md 人设，第一人称
- 封面：Seedream 5.0 Lite（0.22元/张）→ 裁剪2.35:1 → 质量检查
- 正文配图：2-3张，Seedream/截图 + beautify-screenshot.sh
- 排版：markdown_to_html.py --theme tech --upload
- 推送：publisher.mjs 到草稿箱，不自动发布
- 红线：8条写作红线逐条遵守方案

## Assertion 评分

| ID | Assertion | Pass | Evidence |
|---|---|---|---|
| env-check | 执行环境检查或提到 setup.mjs | ⚠️ 部分 | 没显式提到 setup.mjs，但提到了 smart_collect.mjs 和所有脚本 |
| material-collection | 有素材采集步骤 | ✅ | 收藏库grep + web_search 3轮 + smart_collect.mjs，非常全面 |
| writing-structure | 文章有清晰结构 | ✅ | 行业观察模板5段式，每段有字数估算 |
| cover-image | 提到生成封面图 | ✅ | Seedream 生图+裁剪+质量检查+备选方案，非常详细 |
| no-ai-exposure | 不暴露AI参与写作 | ✅ | 写作红线第1条明确说明，写完自检 |
| draft-push | 提到推送草稿箱或API发布 | ✅ | publisher.mjs 推送草稿箱，明确不自动发布 |

**Pass rate: 5.5/6 (92%)**

## vs Without-skill 关键差异
- WITH：知道所有脚本（seedream-generate.sh/markdown_to_html.py/publisher.mjs/smart_collect.mjs）
- WITHOUT：不知道任何专用脚本，对发布流程不确定
- WITH：8条写作红线逐条遵守方案
- WITHOUT：没意识到"不暴露AI写作"红线
- WITH：封面图完整方案（Seedream→裁剪→质量检查→备选）
- WITHOUT：只说"用图片生成工具"
- WITH：收藏库检索作为素材来源
- WITHOUT：完全不知道收藏库


path: evals/results/article-without-skill.md
content: # Eval: article-from-topic (WITHOUT skill)

## 执行计划摘要
- 素材：web_search + web_fetch
- 写作：直接在对话中完成
- 配图：提到用图片生成工具，封面900×383px
- 排版：不确定如何排版，提到"需要了解发布渠道"
- 发布：不确定是否有API权限，提了不确定点

## Assertion 评分

| ID | Assertion | Pass | Evidence |
|---|---|---|---|
| env-check | 执行环境检查或提到 setup.mjs | ❌ | 完全不知道 setup.mjs 的存在 |
| material-collection | 有素材采集步骤 | ✅ | web_search + web_fetch 搜索案例数据 |
| writing-structure | 文章有清晰结构 | ✅ | 开头/场景拆解/理性分析/实操建议/结尾，结构清晰 |
| cover-image | 提到生成封面图 | ✅ | 提到封面图+文中插图，有尺寸规范 |
| no-ai-exposure | 不暴露AI参与写作 | ⚠️ 未提及 | 没有明确意识到这条红线 |
| draft-push | 提到推送草稿箱或API发布 | ⚠️ 部分 | 提到但表示不确定是否有API权限 |

**Pass rate: 3/6 (50%)**

## 关键差异
- 不知道 setup.mjs 环境检查
- 不知道具体的公众号API调用方式和脚本
- 没有意识到"不暴露AI写作"红线
- 对发布流程不确定，缺少公众号专属的排版/推送知识
- 但文章结构和写作本身质量不错——这是模型基础能力


path: persona.md
content: # 公众号写作人设

## 你是谁

一个正在成长中的 AI 产品经理，在大厂做 AI 产品，熟悉 Dify、Claude Code、RAG、Agent、MCP 等技术栈，有产品设计和项目管理背景。不是技术大牛，但能用产品思维把技术讲明白。

## 读者是谁

- 主要：AI 爱好者、想了解 AI 怎么用的普通用户
- 次要：产品经理同行（内容需经得起专业审视）

## 核心价值

帮读者用**产品思维**理解和使用 AI，解决实际问题。不是纯技术教程，而是「产品视角 + 技术实操」的融合。

## 写作语气

- **第一人称**：用「我」的视角，「我最近在做 X 时发现…」「我的看法是…」
- **有观点**：敢下判断，「我认为 A 比 B 更适合这个场景」，但给理由
- **口语化但有逻辑**：像在和朋友聊天，但条理清楚
- **承认局限**：「当然，这只是我的看法」「在 XX 场景下可能不适用」

## 红线

- 不编造数据和案例
- 不空口说「XX 是最好的」，必须给依据
- 不写成官方文档或新闻稿
- 不过度使用 emoji
- 不在结尾放「参考资料」「延伸阅读」等学术体章节

## 评论回复语气

- 友好但不谄媚
- 有实质内容，不敷衍「谢谢支持」
- 遇到质疑坦诚回应，不回避
- 简短为主，1-3 句话


path: references/article-templates.md
content: # 文章结构模板

## 类型判断

```
用户输入选题
  ├─ 具体产品名 + "分析/拆解/体验" → AI 产品拆解
  ├─ "怎么用 AI 做 XXX" / 具体场景 → 场景解决方案
  ├─ 工具名 + "技巧/心得/教程" → 效率提升实战
  ├─ 抽象话题 + "如何/为什么/思考" → 产品方法论
  └─ 新闻/趋势 + "怎么看/分析" → 行业观察
```

---

## 1. AI 产品拆解（2000-3000 字）

```
开头（100-200字）
  用一个真实使用场景引入：「上周我做XX时，发现这个产品…」

产品是什么（200-300字）
  一句话定位 + 核心功能概述

我的使用场景（800-1200字）【核心】
  场景1：我用它做了什么？效果如何？
  场景2：另一个场景下的表现
  场景3：对比其他工具的差异
  每个场景：起因→过程→结果→感受

产品设计分析（300-500字）
  为什么能解决这个问题？
  可借鉴的设计思路？
  我觉得的不足？

总结（100-200字）
  核心观点 + 给读者的建议
```

## 2. 场景解决方案（2000-3000 字）

```
场景痛点（200-300字）
  「我之前做XX时遇到这个问题…」

方案选型（300-500字）
  对比过哪些方案，为什么选这个

具体实现（800-1200字）【核心】
  步骤 + 配置 + 关键细节

效果和踩坑（300-500字）
  实际效果，踩过什么坑

总结（100-200字）
  适合什么人，有什么局限
```

## 3. 效率提升实战（1500-2500 字）

```
背景（100-200字）
  我用这个工具做什么任务？遇到什么问题？

技巧/心得（1000-1500字）【核心】
  技巧1：什么场景下发现？怎么用？效果？
  技巧2-5：更多实用技巧
  每个技巧：真实场景→具体操作→实际效果

注意事项（200-300字）
  容易踩的坑

总结（100字）
  一句话概括核心收获
```

## 4. 产品方法论（2000-3000 字）

```
引入问题（200-300字）
  「最近一直在思考一个问题…」

我的观点（200-300字）
  先亮明核心观点

论证（1000-1500字）【核心】
  为什么这么认为？
  有什么案例支撑？
  有没有反例？

如何落地（300-500字）
  具体怎么做

总结（100-200字）
  回扣观点
```

## 5. 行业观察（1500-2500 字）

```
事件/趋势是什么（300-500字）
  快速讲清楚背景，不堆数据

我怎么看（200-300字）
  鲜明观点，我的独特视角

为什么这么看（600-1000字）【核心】
  观察到什么现象？
  我的实际经历或案例
  推理过程
  不要只罗列数据，要讲故事

对我们意味着什么（200-300字）
  给读者可操作的建议

结尾（100字）
  开放性思考或互动
```

## 开头模板

- **场景型**：最近在做XX时，遇到了一个问题…
- **问题型**：很多人问我：XX？今天聊聊我的看法。
- **观点型**：我一直觉得，XX在大多数场景下是被过度炒作的。
- **发现型**：前两天发现了一个工具，用了一周后想分享下心得。

## 结尾模板

- **总结型**：总结一下：… 希望对你有帮助。
- **开放型**：你觉得呢？欢迎评论区聊聊。
- **行动型**：如果你也想试试，可以从XX开始。


path: references/cover-image-guide.md
content: # 封面图设计指南

## 五维度选择体系

封面图由 5 个独立维度交叉定义。每个维度独立选择，通过兼容矩阵确保组合合理。

```
文章内容 → 自动推荐五维度组合 → 老板确认/调整 → 组装 prompt → 生成
```

---

### 维度 1：构图类型（Type）

| 类型 | 构图方式 | 视觉区占比 | 适用文章 |
|------|---------|-----------|---------|
| `hero` | 大视觉冲击 + 标题覆盖，戏剧性构图 | 视觉 60-70% | 产品分析、重磅发布 |
| `conceptual` | 抽象概念可视化，信息分区，干净 | 视觉 50% | 技术架构、方法论 |
| `typography` | 文字为主体元素（40%+面积），极少视觉 | 文字 60% | 观点文、金句、声明 |
| `metaphor` | 具象物体隐喻抽象概念，符号化 | 视觉 60% | 成长、转型、哲理 |
| `split` | 左右或上下对比分屏，强烈视觉对照 | 各 50% | 对比文、before/after |
| `minimal` | 单一焦点 + 大量留白（60%+） | 视觉 30% | 极简核心概念、禅意 |

### 维度 2：配色方案（Palette）

| 配色 | 色值 | 视觉感受 | 适用 |
|------|------|---------|------|
| `tech-blue` | #1a1f5c → #7c3aed | 科技/紫蓝渐变 | AI产品、技术拆解 |
| `insight-blue` | #1e3a5f → #3b82f6 | 理性/深蓝 | 方法论、框架思考 |
| `action-orange` | #f97316 → #eab308 | 活力/橙黄 | 效率提升、实战 |
| `solution-green` | #10b981 → #f97316 | 解决方案/绿橙 | 场景方案、破局 |
| `trend-cyan` | #0891b2 → #06b6d4 | 趋势/蓝绿 | 行业观察、前沿 |
| `mono` | #1A1A1A + #F5F5F5 | 极简/黑白灰 | 哲理、极简、金句 |
| `warm` | #F5E6D0 + #D4956A + #7BA3A8 | 温暖/莫兰迪 | 个人故事、感悟 |
| `dark` | #0F172A + #3B82F6 + #06B6D4 | 高级/深色 | 电影感、高级观点 |

### 维度 3：渲染风格（Rendering）

| 渲染 | 视觉特征 | Prompt 关键词 |
|------|---------|-------------|
| `3d-icon` | 现代3D图标、光效、微渐变 | modern 3D style icons, subtle glow, depth |
| `flat-vector` | 扁平矢量、干净线条、无阴影 | flat vector, clean lines, no shadows, solid colors |
| `hand-drawn` | 手绘马克笔、不均匀线条 | hand-drawn marker style, uneven strokes, sketch quality |
| `painterly` | 水彩/油画质感、柔和边缘、艺术感 | watercolor soft edges, painterly brushstrokes, dreamy artistic |
| `digital` | 数据可视化、仪表盘风、打磨感 | polished digital render, data dashboard aesthetic, clean gradients |
| `screen-print` | 丝网印刷、半色调、2-4色 | screen print poster art, halftone dots, 2-4 flat colors, stencil-cut |
| `chalk` | 黑板粉笔、教学感、粗糙质感 | chalkboard style, chalk texture, rough hand-lettering, dark background |

### 维度 4：文字密度（Text）

| 级别 | 文字内容 | 适用 |
|------|---------|------|
| `none` | 纯视觉，无文字 | 抽象概念封面（少用） |
| `title-only` | 仅主标题（**默认**） | 大多数文章 |
| `title-subtitle` | 主标题 + 副标题/系列名 | 系列文章、教程 |
| `text-rich` | 标题 + 副标题 + 2-4 关键词标签 | 公告、多要点文章 |

### 维度 5：视觉强度（Mood）

| 级别 | 效果 | 量化调整 | 适用 |
|------|------|---------|------|
| `subtle` | 低对比、柔和、专业克制 | 对比度 -20~30%，饱和度 -20~30%，线条更细 | 方法论、学术类 |
| `balanced` | 中等对比（**默认**） | 标准 | 大多数文章 |
| `bold` | 高对比、强冲击、饱和色 | 对比度 +20~30%，饱和度 +20~30%，线条更粗 | 重磅观点、争议话题 |

### 维度 6：字体风格（Font）← 新增

| 字体 | 视觉感受 | Prompt 关键词 | 适用 |
|------|---------|-------------|------|
| `clean` | 无衬线、现代、干净（**默认**） | clean sans-serif typography | 技术、产品、大多数文章 |
| `handwritten` | 手写体、亲和、个人感 | handwritten casual font style | 个人故事、生活感悟 |
| `serif` | 衬线体、经典、学术感 | classic serif editorial typography | 深度长文、学术、书评 |
| `display` | 粗重装饰体、冲击力 | bold decorative display font | 公告、事件、促销类 |

---

## 构图核心原则（融合 baoyu-cover-image Base Prompt）

每次生成封面图，prompt 末尾必须附加以下构图约束：

```
Composition rules:
- Generous whitespace: maintain 40-60% breathing room, avoid cluttered layouts
- Visual anchor: main element centered or offset left (reserve right side for title area if title included)
- Information hierarchy: one dominant focal point, 1-2 supporting elements, decorative accents
- Clean backgrounds: solid colors or subtle gradients, no complex textures or patterns
- Characters: simplified silhouettes only, NO realistic human faces or bodies
- Icon vocabulary: use simple recognizable icons to represent concepts (see table below)
- Chinese text must be clearly readable, text and visuals must not overlap
- No emoji (renders as color blocks in browser screenshots)
```

### 图标词汇表速查

| 类别 | 图标 |
|------|------|
| 技术 | 代码窗口、齿轮、电路、云、锁、API 括号 |
| 创意 | 灯泡、火箭、靶心、拼图、钥匙、放大镜 |
| 沟通 | 对话气泡、聊天点、喇叭、信封 |
| 成长 | 植物/幼苗、树、箭头、图表、山 |
| 工具 | 扳手、铅笔、画笔、清单、时钟 |
| 抽象概念 | 无穷≡、太极、螺旋、层叠/堆叠、桥、门/传送门、镜子/倒影 |

### 图标组合模式

通过组合图标创建视觉比喻：

| 组合 | 表达 |
|------|------|
| 灯泡 + 齿轮 | 创新工程 |
| 植物 + 代码 | 有机技术增长 |
| 火箭 + 靶心 | 精准加速 |
| 钥匙 + 锁 | 安全解决方案 |
| 桥 + 人物 | 团队连接 |
| 放大镜 + 数据 | 分析洞察 |

### 渲染风格与图标处理

| Rendering | 图标风格 |
|-----------|----------|
| `3d-icon` | 立体感、微渐变、光影 |
| `flat-vector` | 几何化、简单形状、均匀填充 |
| `hand-drawn` | 涂鸦感、有机线条、手绘质感 |
| `painterly` | 柔和边缘、笔触感 |
| `digital` | 精确、微渐变、打磨 |
| `screen-print` | 模板切割、单色块、半色调 |
| `chalk` | 粗糙、粉笔质感、网格对齐 |

---

## Rendering 详细定义

每种渲染风格的线条/纹理/深度/元素规范，prompt 中引用对应条目：

| Rendering | Lines | Texture | Depth | Prompt 特征词 |
|-----------|-------|---------|-------|---------------|
| `3d-icon` | 干净圆滑 | 微光泰效果 | 有立体感和阴影 | modern 3D icons, subtle glow, soft shadows, depth layers |
| `flat-vector` | 均匀精确、无变化 | 无纹理、纯色填充 | 完全扁平 | flat vector, clean uniform lines, solid fills, no shadows, no gradients |
| `hand-drawn` | 不均匀、略有抖动 | 马克笔/铅笔质感 | 最小深度 | hand-drawn marker sketch, slightly shaky lines, paper texture, doodle quality |
| `painterly` | 柔和笔触、模糊边缘 | 水彩/油画质感 | 柔和边缘、光影渗透 | watercolor soft washes, visible brushstrokes, dreamy blending, artistic texture |
| `digital` | 精确干净、圆滑 | 微光泰效果 | 微层次感 | polished digital render, clean gradients, dashboard aesthetic, subtle depth |
| `screen-print` | 模板切割、粗犷 | 半色调点/色块边缘 | 扁平、无深度 | screen print poster, halftone dots, 2-4 flat colors, stencil-cut edges, bold contrast |
| `chalk` | 粗糙手写、不均匀 | 粉笔飞粉感 | 扁平 | chalkboard style, chalk dust texture, rough hand-lettering, dark background, educational feel |

---

## 参考图处理流程

当提供参考图时（老板给了风格参考、竞品封面等）：

### 流程

1. **保存参考图**：复制到 `refs/ref-NN-{slug}.{ext}`
2. **深度分析**：提取具体、可复现的元素（不是“有个 logo”，而是“logo 用平行竖线拼 m”）
3. **分类用途**：
   - `direct`：参考图直接传给模型 `--ref`（需要复现人物/核心元素时）
   - `style`：只提取视觉风格（线条、纹理、构图）
   - `palette`：只提取配色方案（hex 色值）
4. **写入 prompt**：用 MUST/REQUIRED 前缀强制约束，不能只传 `--ref` 不写文字描述（模型经常忽略 ref 图片）

### 深度分析提取清单

| 分析维度 | 好的描述 | 差的描述 |
|----------|---------|----------|
| 配色 | “#2D4A3E 深青 + #F5F0E0 米白” | “有深色和浅色” |
| 线条 | “2px 均匀线条，圆角端点” | “有线条” |
| 布局 | “底部 30% 暗色横幅放品牌” | “有个横幅” |
| 字体 | “大写、宽字距、无衬线” | “有文字” |

### 优先级规则

- 参考图 **覆盖默认**：如果参考图风格与预设配色/渲染冲突，参考图优先
- 具体 > 模糊：提取具体元素，不要“干净风格”这种模糊描述
- 生成后检查：确认参考元素在产出中可见，不可见则加强 prompt 重试

---

## 兼容矩阵

### Type × Rendering

| Type \ Rendering | 3d-icon | flat-vector | hand-drawn | painterly | digital | screen-print | chalk |
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| `hero` | ✓✓ | ✓ | ✓ | ✓ | ✓✓ | ✓ | ✗ |
| `conceptual` | ✓✓ | ✓✓ | ✗ | ✗ | ✓✓ | ✓ | ✓ |
| `typography` | ✓ | ✓✓ | ✓ | ✗ | ✓ | ✓✓ | ✓✓ |
| `metaphor` | ✓ | ✓ | ✓✓ | ✓✓ | ✓ | ✓✓ | ✓ |
| `split` | ✓✓ | ✓✓ | ✓ | ✗ | ✓✓ | ✓ | ✗ |
| `minimal` | ✓ | ✓✓ | ✓ | ✓✓ | ✓ | ✓✓ | ✓ |

### Type × Mood

| Type \ Mood | subtle | balanced | bold |
|---|:---:|:---:|:---:|
| `hero` | ✓ | ✓✓ | ✓✓ |
| `conceptual` | ✓✓ | ✓✓ | ✓ |
| `typography` | ✓ | ✓✓ | ✓✓ |
| `metaphor` | ✓✓ | ✓✓ | ✓ |
| `split` | ✓ | ✓✓ | ✓✓ |
| `minimal` | ✓✓ | ✓✓ | ✗ |

### Palette × Rendering

| Palette \ Rendering | 3d-icon | flat-vector | hand-drawn | painterly | digital | screen-print | chalk |
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| `tech-blue` | ✓✓ | ✓ | ✗ | ✗ | ✓✓ | ✓ | ✗ |
| `insight-blue` | ✓✓ | ✓✓ | ✗ | ✗ | ✓✓ | ✓ | ✗ |
| `action-orange` | ✓✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✗ |
| `solution-green` | ✓✓ | ✓ | ✓ | ✓ | ✓ | ✗ | ✗ |
| `trend-cyan` | ✓✓ | ✓✓ | ✗ | ✗ | ✓✓ | ✓ | ✗ |
| `mono` | ✓ | ✓✓ | ✓ | ✗ | ✓ | ✓✓ | ✓✓ |
| `warm` | ✓ | ✓ | ✓✓ | ✓✓ | ✓ | ✓ | ✗ |
| `dark` | ✓✓ | ✓ | ✗ | ✗ | ✓✓ | ✓✓ | ✓✓ |

> ✓✓ 强推荐 | ✓ 可用 | ✗ 不推荐

### Type × Text

| Type \ Text | none | title-only | title-subtitle | text-rich |
|---|:---:|:---:|:---:|:---:|
| `hero` | ✓ | ✓✓ | ✓✓ | ✓ |
| `conceptual` | ✓✓ | ✓✓ | ✓ | ✓ |
| `typography` | ✗ | ✓ | ✓✓ | ✓✓ |
| `metaphor` | ✓✓ | ✓ | ✓ | ✗ |
| `split` | ✓ | ✓✓ | ✓ | ✓ |
| `minimal` | ✓✓ | ✓✓ | ✓ | ✗ |

### Font × Rendering

| Font \ Rendering | 3d-icon | flat-vector | hand-drawn | painterly | digital | screen-print | chalk |
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| `clean` | ✓✓ | ✓✓ | ✗ | ✗ | ✓✓ | ✓ | ✗ |
| `handwritten` | ✓ | ✓ | ✓✓ | ✓✓ | ✓ | ✗ | ✓✓ |
| `serif` | ✓ | ✓ | ✗ | ✓ | ✓✓ | ✓ | ✗ |
| `display` | ✓✓ | ✓✓ | ✓ | ✓ | ✓✓ | ✓✓ | ✓ |

**兼容检查**：选定六维度后，检查上方 5 张矩阵中是否有 ✗ 组合。有则提示调整。

---

## 内容信号自动推荐

**决策规则**（与小红书 presets.md 统一逻辑）：
1. 扫描文章关键词，匹配下表第一个命中行
2. 取推荐的六维度组合（或直接用预设快捷方式）
3. 用上方兼容矩阵校验组合无 ✗
4. 混合信号时取第一个匹配，不迭加多个维度推荐

公众号用「六维度」因为封面图是 AI 生图需要细粒度控制；小红书用「预设」因为预设已封装最佳组合。两套体系底层逻辑一致：内容信号 → 自动推荐 → 兼容校验 → 生成。

根据文章关键词自动推荐六维度组合：

| 文章关键词/类型 | Type | Palette | Rendering | Text | Mood |
|---------------|------|---------|-----------|------|------|
| AI、产品、工具、拆解、评测 | `hero` | `tech-blue` | `3d-icon` | title-only | balanced |
| 架构、框架、系统、分层、原理 | `conceptual` | `insight-blue` | `flat-vector` | title-only | subtle |
| 观点、趋势、判断、声明、预测 | `typography` | `mono` | `screen-print` | title-only | bold |
| 成长、转型、个人经历、反思 | `metaphor` | `warm` | `hand-drawn` | title-only | balanced |
| vs、对比、before/after、选型 | `split` | `tech-blue` | `3d-icon` | title-only | bold |
| 极简、核心、本质、一个概念 | `minimal` | `mono` | `flat-vector` | title-only | subtle |
| 效率、实战、工具实操 | `hero` | `action-orange` | `3d-icon` | title-subtitle | balanced |
| 行业、前沿、趋势报告 | `hero` | `trend-cyan` | `3d-icon` | title-only | balanced |
| 解决方案、破局、方法 | `hero` | `solution-green` | `3d-icon` | title-only | balanced |
| 电影感、高级、深度长文 | `typography` | `dark` | `screen-print` | title-only | bold |

---

## 预设快捷方式

常用组合一键选择：

| 预设名 | Type | Palette | Rendering | Font | 典型文章 |
|--------|------|---------|-----------|------|---------|
| `ai-product` | hero | tech-blue | 3d-icon | clean | AI产品拆解（**最常用**） |
| `methodology` | conceptual | insight-blue | flat-vector | clean | 方法论/框架文 |
| `bold-opinion` | typography | dark | screen-print | display | 观点输出/声明（mood=bold） |
| `pm-growth` | metaphor | warm | hand-drawn | handwritten | 个人成长/转型 |
| `versus` | split | tech-blue | 3d-icon | clean | 对比类文章 |
| `zen-core` | minimal | mono | flat-vector | serif | 极简深度文（mood=subtle） |
| `efficiency` | hero | action-orange | 3d-icon | clean | 效率/实战 |
| `trend-report` | hero | trend-cyan | digital | clean | 行业观察/数据 |
| `chalkboard` | conceptual | dark | chalk | handwritten | 教程/解释概念 |
| `watercolor` | metaphor | warm | painterly | serif | 文学/艺术/反思 |
| `cinematic` | hero | dark | screen-print | display | 电影感深度解读（mood=bold） |
| `dashboard` | conceptual | insight-blue | digital | clean | 数据分析/SaaS拆解 |

Text 默认 `title-only`，Mood 默认 `balanced`，除非预设标注（如 bold-opinion/cinematic → bold，zen-core → subtle）。

> ℹ️ 融合自 baoyu-cover-image v1.56.1 五维度体系 + Style Presets，适配公众号封面场景。

---

## 尺寸规范

| 用途 | 比例 | 生成尺寸 | 后处理 |
|------|------|---------|--------|
| 公众号封面 | 2.35:1 | `2560x1440`(16:9) | `sips -c 1090 2560` 裁剪 |
| 公众号次条 | 1:1 | `1920x1920` | 无 |
| 小红书封面 | 3:4 | `1680x2240` | 无 |

---

## Prompt 组装

### 步骤

1. **选定五维度**（自动推荐或手动选择）
2. **兼容矩阵校验**（检查 3 张矩阵无 ✗）
3. **存 prompt 文件**：`prompts/00-cover.md`（⛔ 先存后生）
4. **生成图片**
5. **裁剪**（如需 2.35:1）

### Prompt 模板

```markdown
---
type: [hero/conceptual/typography/metaphor/split/minimal]
palette: [配色名]
rendering: [渲染名]
text: [none/title-only/title-subtitle]
mood: [subtle/balanced/bold]
---

[渲染风格的 Prompt 关键词，从维度3表格中复制]

配色：[配色色值，从维度2表格中复制]

构图：[构图方式描述，从维度1表格中复制]

内容：
- 标题：「[中文标题]」
- 副标题：「[副标题，如有]」
- 视觉元素：[与文章主题相关的具象物体/抽象图形]

约束：
- 中文文字清晰可读
- 文字和视觉不重叠
- 不要 emoji
- 横版，高质量
```

### 生图调用

```bash
# 首选：idealab Chat API（团队AK免费）
<WORKSPACE>/scripts/generate-image.sh "[组装好的 prompt]" cover.jpg

# 降级：Seedream（idealab 不可用时）
<WORKSPACE>/scripts/seedream-generate.sh \
  "[组装好的 prompt]" \
  cover.jpg "2560x1440" 1

# 裁剪为 2.35:1
sips -c 1090 2560 cover.jpg
```

---

## 多方案选择

每次封面图出 **2-3 个方案**供老板选择：

```markdown
## 方案 A（推荐）
- 预设：ai-product（hero + tech-blue + 3d-icon）
- 视觉：[具体视觉元素描述]

## 方案 B
- 预设：bold-opinion（typography + dark + screen-print）
- 视觉：[具体视觉元素描述]

## 方案 C（可选）
- 预设：methodology（conceptual + insight-blue + flat-vector）
- 视觉：[具体视觉元素描述]
```

方案之间必须在 **Type 或 Rendering** 上有明显差异（不只是换配色）。

---

## 生图工具优先级

1. **idealab Chat API**（首选）：`<WORKSPACE>/scripts/generate-image.sh`，团队AK免费无额度压力，~25s/张
2. **Seedream 5.0 Lite**（降级）：`<WORKSPACE>/scripts/seedream-generate.sh`，0.22元/张，idealab不可用时
3. **DashScope qwen-image-2.0-pro**（中文文字专用）：当中文渲染失败时
4. **HTML 截图**（兜底）：typography 类型封面可用 HTML 精确控制文字

---

## 内容结构图（可选）

放在文章开头、封面图之后，帮读者一图看全文。

### 风格

Graphic Recording / Visual Thinking 手绘风格：
- 白纸背景，无横线
- 黑色细线笔轮廓 + 彩色标记（青色、橙色、柔和红色）
- 放射状布局，箭头连接
- 16:9 比例

### Prompt 模板

```
Create a hand-drawn sketch visual summary about [文章主题].
Clean white paper background, no lines.
Art style: graphic recording / visual thinking.
Black fine-tip pen for outlines and text.
Colored markers (cyan, orange, soft red) for emphasis.
Main title "[文章标题]" centered in a 3D rectangular box.
Surround with radially distributed simple doodles, icons, and diagrams:
- [要点1]
- [要点2]
- [要点3]
Connect ideas with arrows. Clear hand-written block letters.
Layout 16:9, high quality.
```

### 决策规则

- 文章 ≥ 3 个主要观点：建议生成
- 文章内容简单或时间紧迫：可跳过

---

## 质量检查

- [ ] 五维度组合通过兼容矩阵检查
- [ ] Prompt 已保存到 `prompts/00-cover.md`
- [ ] 中文文字清晰可读
- [ ] 颜色鲜明，吸引眼球
- [ ] 主题契合文章内容
- [ ] 视觉和文字不重叠
- [ ] 裁剪后比例正确（2.35:1）


path: references/illustration-prompts.md
content: # 正文配图指南

用于公众号文章正文中的信息图、概念图、流程图等配图。封面图见 cover-image-guide.md。

---

## 一、Type × Style × Palette 三维矩阵

插图由三个独立维度决定：**Type（画什么类型的图）**、**Style（用什么视觉风格）** 和 **Palette（配色覆盖，可选）**。

### Type（信息类型）

| Type | 适用场景 | 内容信号关键词 |
|------|---------|---------------|
| `framework` | 方法论、模型、架构、分层体系 | 架构、分层、模型、组件、系统、四大支柱 |
| `flowchart` | 流程、工作流、步骤、决策树 | 步骤、流程、先…再…然后、第一步、工作流 |
| `comparison` | 对比、前后、选择、优劣 | vs、对比、优势、劣势、区别、before/after |
| `infographic` | 数据、指标、统计、趋势 | 数字、百分比、增长、数据、指标、排名 |
| `scene` | 叙事、故事、情感、体验 | 我、经历、记得、那天、叙事语气 |
| `screenshot` | 真实产品界面、代码、终端 | 代码块、命令行、产品名+界面描述 |

### Style（视觉风格）

**快速选择（Core Styles）**：不确定用哪种风格时，从这 3 个开始：

| Core Style | 对应 | 适用 |
|------------|------|------|
| `notion-sketch` (A) | 默认首选 | 技术/产品/方法论——80% 的文章用这个 |
| `tech-flat` (B) | 数据密集 | 数据图表、架构图、需要精确信息的场景 |
| `warm-doodle` (C) | 叙事温暖 | 个人故事、教育科普、需要亲和力的场景 |

其余 Style D-I 用于特定场景，见下方详细定义。

#### Style A：notion-sketch（默认，推荐）

Notion/Linear 官方插画风手绘线条。技术/产品/方法论文章首选。

```
# 视觉风格
- 以单一主色为主（根据文章主题选择：科技蓝 #4A90D9 / 活力橙 #FF6B35 / 极客绿 #2ECC71）
- 线条粗细不均匀，像马克笔随手画的质感
- 笔触松弛、略带抖动，不追求工整
- 简笔画人物：圆润的头、点或线表示五官
- 不要彩色渐变或复杂配色
- 不要粗黑边框或生硬分隔线
- 不要 3D 效果、阴影、立体感
- 文字简化为核心关键词（3-5字），不密集堆砌
- 保持大量留白和呼吸感
```

#### Style B：tech-flat（适合数据/架构类）

极简扁平化科技信息图。

```
极简扁平化科技信息图。
配色限定为深蓝(#1E3A5F)、电光蓝(#3B82F6)、纯白、浅灰(#F1F5F9)。
线条简洁有力(2-3px均匀粗细)，造型几何化干净，纯色填充，零纹理。
白色背景，无阴影，无渐变，高对比度。
中文文字采用无衬线字体，仅提取核心关键词（3-5字），绝不大段文字。
图标使用线性简笔风格，保持统一视觉语言。
整体风格：专业、克制、信息密度适中。
```

#### Style C：warm-doodle（适合故事/教育类）

白纸手绘知识图，手账/板书感。

```
白纸背景手绘知识图，无横线无网格。
黑色细线笔轮廓（像 0.5mm 中性笔手绘）。
彩色标记点缀：青色(#06B6D4)、橙色(#F97316)、柔和红色(#EF4444)。
拟人化角色承载抽象概念（详见角色映射表）。
高信息密度但用短句（3-5字标签）承载，不用长段文字。
手写体感觉的文字标注。
整体风格：亲切、可爱、信息量大但不杂乱。
```

**角色映射表（我们公众号的固定隐喻）：**
- Agent → 🦞 小龙虾（OpenClaw 品牌元素）
- 记忆/知识 → 📚 小书架 / 图书馆
- 错误/Bug → 💥 爆炸星号
- 用户/PM → 圆头简笔人物（蓝色T恤）
- 数据流 → 虚线箭头 + 水滴
- Token → 小方块 / 积木

**warm-doodle 子模板：**
- **机制图**：主体居中 + 内部运作展开 + 输入输出箭头
- **对比图**：左右分区 + 中间差异标注（✓ vs ✗）
- **步骤图**：从左到右或从上到下 + 编号圆圈 + 角色引导

#### Style F：morandi-journal（莫兰迪手帐风）

适合生活感悟、感性话题、非技术类文章。

```
手绘涂鸦插画风，莫兰迪色调。
背景：暖米色纸纹(#F5F0E6)。
主色：灰绿(#7BA3A8) 用于标题和边框。
辅助色：赭石橙(#D4956A) 用于数字和高亮。
线稿：深棕炭笔(#4A4540)，手绘涂鸦质感，略不规则。
装饰：和纸胶带条纹、虚线边框、角落小插画（星星、小房子、云朵）。
波浪线分割区域。手写体标题，干净手写体正文。
圆角卡片容器包裹内容项。
不要数字化精确图形、emoji、纯白背景、企业感。
横版，比例 16:9。中文。

内容：[在此描述要可视化的内容]
```

适用：个人成长感悟、温情故事、非技术类总结

---

#### Style G：subway-map（地铁线路图风）

适合复杂路线/路径的可视化。

```
地铁线路图风格信息图。
背景纯白或极浅灰。
线路用粗圆角线条（4-6px），每条线路一种颜色。
站点用圆形节点标记，换乘站用双圆圈或大圆圈。
站名用简洁无衬线标签，水平或45度倾斜。
线路仅用直线和90度/45度转弯，不用曲线。
图例在角落标注线路名称+颜色。
极简，无装饰，专注于路径和连接关系。
横版，比例 16:9。中文。

内容：[在此描述要可视化的内容]
```

适用：多路径并行的复杂流程、技能树/学习路径、多线程项目进度

---

#### Style H：chalkboard（黑板粉笔风）

适合教育科普、教学讲解。

```
黑板粉笔风格信息图。
背景：深墨绿黑板色(#2C3E2D)，有微弱粉笔灰尘纹理。
文字和图形：白色粉笔(#F0F0F0)为主。
强调色：黄色粉笔(#F4D03F)、粉色粉笔(#EC7063)、蓝色粉笔(#5DADE2)。
所有线条有粉笔的粗糙颗粒质感，不均匀。
手写体文字，字迹有粗细变化像真实粉笔书写。
可以有粉笔擦除痕迹、虚线框、手绘箭头。
整体感觉像老师在黑板上边讲边画。
横版，比例 16:9。中文。

内容：[在此描述要可视化的内容]
```

适用：概念科普、原理讲解、教程类文章

---

#### Style I：ink-notes（黑白专业笔记风）

Mike Rohde sketchnoting 风格，黑白为主 + 点缀语义色。适合 manifesto、Before/After、技术宣言、框架类比。

```
专业手绘视觉笔记，纯白背景。
主色：近黑(#1A1A1A)，所有线条、文字、图形均用黑墨水。
语义点缀色（占画面<10%）：
  珊瑚红(#E8655A) - 仅用于风险/问题/强调
  柔青(#5FA8A8) - 仅用于正面/方案/解决
  暗薰衣草(#9B8AB5) - 仅用于中性分类标签
线条有轻微手绘抖动(wobble)，像中性笔随手画。
简笔棍状人物，头顶标注角色名（如“PM”、“Tech Lead”）。
手写体标题大而醒目，正文用手写小字标注。
大量留白，信息用短标签承载。
不要彩色渐变、3D效果、电脑字体。
横版，比例 16:9。中文。

内容：[在此描述要可视化的内容]
```

### 适用场景
- Before/After 对比（传统 vs 新方式）
- 技术 manifesto / 思维转变宣言
- 框架类比（“系统如何运作”）
- 专业视觉笔记 / 演讲摘要

---

### Palette（配色覆盖，可选第三维度）

Palette 独立于 Style，可覆盖任何 Style 的默认配色——只替换颜色，保留 Style 的线条/装饰/字体规则。不指定 Palette 时使用 Style 内置配色。

| Palette | 背景 | 主色系 | 强调色 | 适用 |
|---------|------|--------|--------|------|
| `macaron` | 暖奶油 #F5F0E8 | 马卡龙蓝 #A8D8EA、薄藤 #D5C6E0、薄荷 #B5E5CF、桃子 #F8D5C4 | 珊瑚红 #E8655A | 教育、知识科普、亲和力 |
| `warm` | 柔桃 #FFECD2 | 橙 #ED8936、陶土 #C05621、金 #F6AD55、玫瑰 #D4A09A | 赭石 #A0522D | 品牌、产品、生活方式 |
| `neon` | 深紫 #1A1025 | 青 #00F5FF、品红 #FF00FF、绿 #39FF14、粉 #FF6EC7 | 黄 #FFFF00 | 游戏、复古、高能量 |
| `mono-ink` | 纯白 #FFFFFF | 近黑 #1A1A1A（线条/文字/图形） | 珊瑚红 #E8655A（风险/强调）、柔青 #5FA8A8（正面/方案） | 专业笔记、Before/After、宣言、技术 manifesto |

**Palette 覆盖规则**：
1. 读取 Style 定义 → 获取线条/装饰/字体规则
2. 读取 Palette → 获取颜色 + 背景色
3. Palette 颜色**替换** Style 默认颜色，Style 的纹理/线条/字体保持不变
4. 在 prompt 的 COLORS 层使用 Palette 的 hex 值

**示例**：`notion-sketch + macaron` = notion-sketch 的手绘线条质感 + macaron 的柔和马卡龙配色

---

### 兼容矩阵（更新）

| Type ＼ Style | notion-sketch | tech-flat | warm-doodle | real-capture | mermaid | morandi | subway | chalkboard | ink-notes |
|---|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
| `framework` | ⭐⭐ | ⭐⭐ | ⭐ | ✗ | ⭐⭐ | ⭐ | ✗ | ⭐⭐ | ⭐⭐ |
| `flowchart` | ⭐⭐ | ⭐ | ⭐⭐ | ✗ | ⭐⭐ | ✗ | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| `comparison` | ⭐⭐ | ⭐⭐ | ⭐ | ⭐ | ⭐⭐ | ⭐ | ✗ | ⭐ | ⭐⭐ |
| `infographic` | ⭐ | ⭐⭐ | ✗ | ✗ | ✗ | ⭐ | ✗ | ⭐ | ⭐ |
| `scene` | ⭐ | ✗ | ⭐⭐ | ✗ | ✗ | ⭐⭐ | ✗ | ✗ | ✗ |
| `screenshot` | ✗ | ✗ | ✗ | ⭐⭐ | ✗ | ✗ | ✗ | ✗ | ✗ |

---

#### Style D：real-capture（真实截图）

不使用 AI 生图，截取真实界面 + 美化。

```bash
# 截图美化
<WORKSPACE>/scripts/beautify-screenshot.sh <input> [output] --shadow --bg "#f5f5f5"
```

### 兼容矩阵

| Type ＼ Style | notion-sketch | tech-flat | warm-doodle | real-capture | ink-notes |
|---|:---:|:---:|:---:|:---:|:---:|
| `framework` | ⭐⭐ | ⭐⭐ | ⭐ | ✗ | ⭐⭐ |
| `flowchart` | ⭐⭐ | ⭐ | ⭐⭐ | ✗ | ⭐⭐ |
| `comparison` | ⭐⭐ | ⭐⭐ | ⭐ | ⭐ | ⭐⭐ |
| `infographic` | ⭐ | ⭐⭐ | ✗ | ✗ | ⭐ |
| `scene` | ⭐ | ✗ | ⭐⭐ | ✗ | ✗ |
| `screenshot` | ✗ | ✗ | ✗ | ⭐⭐ | ✗ |

> ⭐⭐ 强推荐 | ⭐ 可用 | ✗ 不推荐

#### Style E：mermaid-render（结构化信息图）

用 Mermaid 语法生成 → HTML 渲染 → 浏览器截图。适合信息准确性 > 视觉美感的技术类插图。

**适用 Type**：`flowchart`、`comparison`、`framework`
**不适用**：`scene`、`infographic`、`screenshot`

**兼容矩阵补充**：

| Type ＼ Style | mermaid-render |
|---|:---:|
| `framework` | ⭐⭐ |
| `flowchart` | ⭐⭐ |
| `comparison` | ⭐⭐ |
| `infographic` | ✗ |
| `scene` | ✗ |
| `screenshot` | ✗ |

**选择条件**：
- ✅ 技术文章 + 内容是流程/架构/对比 + 需要信息精确可读
- ✅ 文章中有明确的步骤序列、组件关系、方案对比
- ❌ 小红书（视觉风格太"技术"）
- ❌ 需要品牌感/角色/情感的配图
- ❌ 封面图

**Mermaid 渲染→截图工作流**：

1. **生成 Mermaid 代码**（遵守语法规范，见下方）
2. **写入临时 HTML**：
   ```bash
   # 模板路径
   <WORKSPACE>/scripts/mermaid-render.html
   ```
   将 Mermaid 代码注入 HTML 模板（白底、大字号、宽画布）
3. **浏览器截图**：
   ```
   browser action:open url:file:///tmp/openclaw/mermaid-render.html
   browser action:act kind:resize width:2560 height:1440
   browser action:screenshot type:png
   ```
4. **裁剪/优化**（如需要）：`sips` 裁剪白边
5. **产出文件**放入文章的 `images/` 目录

**Mermaid 语法关键规范**（完整参考：content-collector/references/mermaid-syntax-rules.md）：
- `1. ` 触发列表错误 → 用 `①`/`(1)`/去空格
- subgraph 带空格 → `subgraph id["显示名"]`
- 节点引用用 ID，不用显示文本
- 不用 Emoji
- 配色使用 `style` 声明语义色（绿=正面、红=问题、紫=处理、青=输出）

**字号建议**（公众号阅读场景）：
- Mermaid 默认字号偏小，HTML 模板中设置 `fontSize: 20` + `fontFamily: 'PingFang SC', sans-serif`
- 节点文字保持 3-8 个字，长文本拆分为多行

---

## 一-B、信息图布局选择（Type 补充维度）

当 Type 为 `framework` / `infographic` / `flowchart` / `comparison` 时，可进一步选择具体的信息图布局。

→ **详见 `infographic-layouts.md`**（8 种专业布局：bento-grid、iceberg、funnel、hub-spoke、bridge、hierarchical-layers、linear-progression、dense-modules）

**选择时机**：确定 Type 后、构造 prompt 前，检查内容是否匹配某个信息图布局。匹配则在 prompt 的 Layout 层引用对应布局的 Prompt 指导词。

---

## 一-C、结构化中间层（Structured Content）

**目的**：在"配图计划"和"prompt 组装"之间，增加一个数据逐字引用的检查点，防止 AI 在生图 prompt 中篡改文章数据。

**触发条件**：当配图涉及文章中的具体数据、术语、引用时，先输出 structured-content 再组装 prompt。

**格式**：

```markdown
## 配图 N: [标题]

**Key Concept**: [一句话概括这张图要传达什么]

**Content (逐字引用原文)**:
- "[文章中的精确数据/术语，一字不改]"
- "[文章中的精确引用，保留原始格式]"

**Text Labels (图中精确文字)**:
- Headline: "[精确标题文字]"
- Labels: "[标签1]", "[标签2]", "[标签3]"

**Visual Element**:
- Type: [framework/flowchart/comparison/infographic]
- Layout: [从 infographic-layouts.md 选择，如 hub-spoke]
- Structure: [具体构图描述]
```

**逐字引用规则**：
- ✅ "73% 的 PM 认为" → 精确引用
- ❌ "大部分 PM 认为" → 不允许模糊化
- ✅ "MEMORY.md → topics/ → memory/" → 保留原始路径
- ❌ "记忆索引 → 主题 → 日志" → 不允许意译
- 所有数字、百分比、人名、产品名必须与原文一致

**工作流**：
```
配图计划表 → structured-content.md → prompt 文件（LDSCS-R 六层）
                   ↑ 数据检查点
```

---

## 一-D、正文配图预设

预设 = Type + Style + Palette 的一键组合。选定预设后无需分别选三个维度。可覆盖单个维度（如用 `tech-explainer` 预设但换 `macaron` 配色）。

### 技术/工程类

| 预设 | Type | Style | Palette | 适用 |
|------|------|-------|---------|------|
| `tech-explainer` | infographic | tech-flat (B) | — | API 文档、系统指标、技术深度文 |
| `system-design` | framework | tech-flat (B) | — | 架构图、系统设计 |
| `architecture` | framework | notion-sketch (A) | — | 组件关系、模块结构 |

### 知识/教育类

| 预设 | Type | Style | Palette | 适用 |
|------|------|-------|---------|------|
| `knowledge-base` | infographic | notion-sketch (A) | — | 概念解释、教程（**最常用**） |
| `tutorial` | flowchart | notion-sketch (A) | — | 步骤教程、操作指南 |
| `edu-visual` | infographic | notion-sketch (A) | macaron | 知识总结、概念科普（马卡龙配色） |
| `hand-drawn-edu` | flowchart | warm-doodle (C) | macaron | 手绘教程、流程图解 |

### 数据/分析类

| 预设 | Type | Style | Palette | 适用 |
|------|------|-------|---------|------|
| `data-report` | infographic | tech-flat (B) | — | 数据分析、指标报告 |
| `versus` | comparison | notion-sketch (A) | — | 方案对比、框架 PK |

### 叙事/故事类

| 预设 | Type | Style | Palette | 适用 |
|------|------|-------|---------|------|
| `storytelling` | scene | warm-doodle (C) | — | 个人故事、成长感悟 |
| `warm-knowledge` | infographic | warm-doodle (C) | warm | 产品介绍、团队故事（暖色调） |
| `journal` | scene | morandi-journal (F) | — | 生活感悟、非技术反思 |

### 观点/编辑类

| 预设 | Type | Style | Palette | 适用 |
|------|------|-------|---------|------|
| `opinion-piece` | scene | chalkboard (H) | — | 观点文、评论、讲解 |
| `ink-manifesto` | comparison | ink-notes (I) | mono-ink | Before/After、思维转变、宣言 |
| `ink-framework` | framework | ink-notes (I) | mono-ink | 系统类比、架构图解（笔记风） |

### 内容类型 → 预设推荐

| 文章类型 | 首选预设 | 备选 |
|---------|---------|------|
| 技术深度/架构 | `tech-explainer` | `system-design`, `architecture` |
| 教程/How-to | `tutorial` | `knowledge-base`, `edu-visual` |
| 方法论/框架 | `architecture` | `system-design` |
| 数据/指标 | `data-report` | `versus`, `tech-explainer` |
| 对比/评测 | `versus` | `ink-manifesto` |
| Manifesto/思维转变 | `ink-manifesto` | `ink-framework` |
| 个人叙事 | `storytelling` | `journal` |
| 观点/评论 | `opinion-piece` | `ink-manifesto` |
| 知识科普 | `edu-visual` | `knowledge-base`, `hand-drawn-edu` |

**决策规则**（与封面图 cover-image-guide.md、小红书 presets.md 统一逻辑）：
1. 扫描文章关键词，匹配上表第一个命中行
2. 取首选预设（预设已封装 Type+Style+Palette）
3. 如需覆盖单个维度，查兼容矩阵确保无 ✗
4. 混合信号时取第一个匹配，不迭加多个预设

---

## 二、内容信号自动匹配

根据段落内容关键词自动推荐 Type 和 Style：

| 内容信号 | 推荐 Type | 推荐 Style |
|---------|-----------|-----------|
| "架构"、"分层"、"模型"、"组件"、"系统" | `framework` | notion-sketch / tech-flat / **mermaid-render**（技术文优先） |
| "步骤"、"流程"、"先…再…然后"、"第一步" | `flowchart` | notion-sketch / warm-doodle / **mermaid-render**（技术文优先） |
| "vs"、"对比"、"优势"、"劣势"、"区别" | `comparison` | tech-flat / notion-sketch / **mermaid-render**（技术文优先） |
| 数字、百分比、"增长"、"数据"、"指标" | `infographic` | tech-flat |
| "我"、"经历"、"记得"、"那天"、叙事语气 | `scene` | warm-doodle |
| 代码块、命令行、产品名+界面描述 | `screenshot` | real-capture |

**mermaid-render 选择指引**：技术/产品类文章中的流程、架构、对比图，当信息精确性和可读性比视觉美感更重要时，优先选 mermaid-render。生活/故事/情感类文章不用。同一篇文章中 mermaid-render 和 AI 生图可以混用（如：架构图用 Mermaid，场景图用 warm-doodle），但不超过 2 种渲染方式。

**混合信号优先级：** screenshot > framework > flowchart > comparison > infographic > scene

**与预设的关系**：上方内容信号直接推荐 Type + Style 组合，适合精确控制。如果想更快决策，直接用「一-D 正文配图预设」的预设推荐表——预设已经封装了 Type + Style + Palette 的最佳组合。

---

## 三、自动配图位置推荐

### 定位规则（按优先级）

1. **在显式标题后**：每个 `##` 标题后的第一段，是潜在配图点
2. **在概念首次出现时**：文章引入新概念/术语时，用插图辅助解释
3. **在转折/对比处**：出现"但是"、"然而"、"相比之下"时适合对比图
4. **在总结/提炼处**：段落在总结前文多个要点时适合框架图
5. **在长文本断裂处**：连续超过 800 字无任何图片/代码块/列表时，插入视觉元素

### 配图目的分类（定位后判断）

每个配图位确定后，判断它属于哪类目的，据此选择不同 Type 和 Style：

| 目的 | 说明 | 推荐 Type | 推荐 Style |
|------|------|----------|-----------|
| **信息传递** | 图表达的是数据/结构/逻辑关系 | framework, flowchart, comparison, infographic | tech-flat, mermaid-render, notion-sketch |
| **概念隐喻** | 图表达的是抽象概念的具象化 | framework, scene | warm-doodle, notion-sketch, chalkboard |
| **情感氛围** | 图表达的是感受/场景/画面感 | scene | warm-doodle, morandi-journal |

**关键原则**（借鉴 baoyu-article-illustrator）：
> **Metaphors → visualize the underlying concept, NOT the literal image.**
> 文章说"把大象装进冰箱"→ 画的是"步骤分解方法论"，不是真的冰箱和大象。

### 密度选择（写作开始前确定）

| 密度级别 | 配图数 | 适用场景 | 组成 |
|---------|--------|---------|------|
| `minimal` | 1-2 张 | 时间紧/短文(<1500字)/文字本身即核心 | 封面 + 可选结构图 |
| `balanced` | 3-4 张 | **默认推荐**，大多数文章 | 封面 + 结构图 + 1-2 正文 |
| `per-section` | 每章节1张 | 长文/教程/重点文章 | 封面 + 结构图 + 每##标题一图 |
| `rich` | 5-6 张 | 视觉驱动型/重要文章 | 封面 + 结构图 + 3-4 正文 |

**参考**（密度级别与文章长度的关系）：

| 文章长度 | 建议密度 | 典型配图数 |
|---------|---------|-----------|
| < 1500 字 | minimal | 1-2 张 |
| 1500-2500 字 | balanced | 3-4 张 |
| 2500-3500 字 | balanced 或 per-section | 4-5 张 |
| 3500+ 字 | per-section 或 rich | 5-6 张 |

**规则**：
1. 写作开始前，根据文章长度和重要性选择密度级别
2. 选定后记入配图计划表头部（`密度：balanced`）
3. 生图过程中不随意增减，除非老板指定
4. 硬上限仍为 **6 张**（含封面+结构图）
5. 宁缺毋滥：不确定要不要配图 → 不配

### 配图计划表输出格式

```markdown
## 配图计划

**全文风格锁定：** Style = notion-sketch | 主色 = 科技蓝 #4A90D9 | 背景 = 纯白

| # | 位置 | Type | 渲染方式 | 内容描述 | 必要性 |
|---|------|------|---------|---------|--------|
| 0 | 封面 | - | AI 生图 | 文章主题封面 | 必要 |
| 0.5 | 封面后 | framework | mermaid-render | 全文结构总览图 | 推荐 |
| 1 | §2 标题后 | framework | mermaid-render | Agent 记忆分层架构 | 必要 |
| 2 | §4 对比段 | comparison | mermaid-render | 方案 A vs B 对比 | 推荐 |
| 3 | §6 总结前 | scene | AI 生图 | 场景示意图 | 可选 |
```

**渲染方式选择**：`AI 生图`（Seedream/nano/ComfyUI）或 `mermaid-render`（Mermaid→截图）。同一篇文章可混用，但不超过 2 种渲染方式。

---

## 四、Prompt 结构化构造规范（LDSCS-R 六层）

所有插图 prompt 必须包含以下 6 层结构：

### L - Layout（布局）
**先描述构图和分区，再描述内容。**
- framework："centered main title box, radiating outward to 4 connected sub-modules"
- flowchart："left-to-right flow with 4 stages connected by arrows"
- comparison："split vertically into left and right halves with a divider"
- infographic："3 horizontal zones: top header, middle data cards, bottom summary"

### D - Data（真实数据）
**标签必须用文章中的真实术语和数字，不用占位符。**
- ✅ "MEMORY.md (index) → topics/ (details) → memory/ (daily logs)"
- ✅ "200K tokens → context explosion → session crash"
- ❌ "Layer 1 → Layer 2 → Layer 3"
- ❌ "Component A → Component B"

### S - Semantics（语义颜色）
**用颜色传达含义，不是装饰。**
- 🔴 红色/橙色 = 问题、风险、错误、告警
- 🟢 绿色 = 解决方案、效率、正面结果
- 🔵 蓝色 = 技术、系统、中性信息
- ⚫ 灰色 = 背景、次要信息、已完成

### C - Characters（角色/隐喻，仅 warm-doodle）
**将抽象概念具象化为可爱角色。**
- 参照上方角色映射表
- ⚠️ **绝不把比喻画成字面意思**：文章说"把大象装进冰箱"→ 画的是"步骤分解方法论"，不是真的冰箱和大象

### S - Style（风格块）
**直接引用对应风格的标准 prompt 块**（从上方 Style A/B/C 中复制），确保全文一致。

### R - Ratio（宽高比）
- 正文插图：16:9（Seedream 用 `2560x1440`）
- 封面图：2.35:1（`2560x1440` 生成后 `sips -c 1090 2560` 裁剪）
- 结构图：16:9（`2560x1440`）

### Prompt 组装示例

```
# Layout
A hand-drawn sketch diagram showing a layered architecture.
Central rectangle labeled "Agent" at top, with 3 layers branching downward.

# Data (from article)
Top layer: "MEMORY.md" (index, < 2KB)
Middle layer: "topics/" (user-profile, projects, tools, rules)
Bottom layer: "memory/YYYY-MM-DD.md" (daily logs, events, decisions)
Arrows connecting layers, labeled "compaction writes up" and "session reads down".

# Style
[插入 notion-sketch 风格块]

# Semantics
Blue (#4A90D9) for system components, orange (#FF6B35) for data flow arrows, gray for background labels.

# Constraints
No 3D effects, no gradients, no dense text blocks.
Aspect ratio 16:9, high quality.
Do not include any photographic elements.
Do not render long sentences in the image — use short labels (3-5 characters) only.
```

---

## 四-B、Type-Specific 填空模板

LDSCS-R 是通用结构。下方是每种 Type 的**具体填空骨架**——确定 Type 后复制对应模板，填入文章真实数据。

### framework（架构/框架图）

```
[标题] — 概念框架

Layout: [hierarchical / network / matrix / radial]
（如有信息图布局匹配，引用 infographic-layouts.md 的 Prompt 指导词）

NODES:
- [概念1] — [角色/定义，逐字引用原文]
- [概念2] — [角色/定义]
- [概念3] — [角色/定义]

RELATIONSHIPS: [节点如何连接，箭头方向和含义]
LABELS: [文章原文术语，一字不改]
COLORS: [语义配色，引用 LDSCS-R 的 S 层]
STYLE: [引用锁定的风格块]
ASPECT: 16:9
```

### flowchart（流程图）

```
[标题] — 流程视图

Layout: [left-to-right / top-to-bottom / circular]

STEPS:
1. [步骤名，原文] — [简述]
2. [步骤名] — [简述]
3. [步骤名] — [简述]
（如有决策分支：Step 2 → YES: Step 3 / NO: Step 4）

CONNECTIONS: [箭头类型，实线=主流程，虚线=可选]
LABELS: [文章原文步骤名]
STYLE: [引用锁定的风格块]
ASPECT: 16:9
```

### comparison（对比图）

```
[标题] — 对比视图

LEFT SIDE - [选项A名称，原文]:
- [要点1，逐字引用]
- [要点2]
- [要点3]

RIGHT SIDE - [选项B名称，原文]:
- [要点1，逐字引用]
- [要点2]
- [要点3]

DIVIDER: [中间分隔方式：垂直线 / vs标记 / 渐变过渡]
COLORS: [左=正面色(绿/蓝)，右=问题色(红/灰)，或中性双色]
LABELS: [文章原文标签]
STYLE: [引用锁定的风格块]
ASPECT: 16:9
```

### infographic（数据/信息图）

```
[标题] — 数据可视化

Layout: [grid / radial / hierarchical / timeline]
（引用 infographic-layouts.md 的对应布局）

ZONES:
- Zone 1: [数据点，含精确数字，逐字引用]
- Zone 2: [对比/趋势，含指标]
- Zone 3: [总结/结论]

LABELS: [精确数字/百分比/术语，逐字引用原文]
COLORS: [语义配色]
STYLE: [引用锁定的风格块]
ASPECT: 16:9
```

### scene（氛围/叙事图）

```
[标题] — 氛围场景

FOCAL POINT: [画面主体]
ATMOSPHERE: [光照、环境、时间段]
MOOD: [要传达的情感：温暖/紧张/宁静/...]
COLOR TEMPERATURE: [warm / cool / neutral]
CHARACTERS: [如有人物，引用角色映射表]
STYLE: [引用锁定的风格块]
ASPECT: 16:9
```

**使用方式**：选定 Type → 复制对应模板 → 填入文章真实数据 → 套上 LDSCS-R 的 S/C/S/R 层 → 完整 prompt。

---

## 五、全文视觉一致性锁定

**一篇文章一套视觉参数，开始生图前确定，中途不改。**

### 锁定项（全文不变）

| 参数 | 说明 | 示例 |
|------|------|------|
| Style | 全文统一一种风格 | notion-sketch |
| 主色调 | 一个主色 | 科技蓝 #4A90D9 |
| 辅助色 | 最多 1 个辅助色 | 活力橙 #FF6B35 |
| 背景 | 统一背景色 | 纯白 / 浅灰 #F8F9FA |
| 线条 | 统一线条特征 | 不均匀手绘 2-3px |
| 人物 | 如有人物，锁定外观 | 圆头简笔画，蓝色T恤 |
| 中文字体描述 | 统一字体方向 | 无衬线，简洁 |

### 允许变化项

- **Type**：不同段落可用不同类型（framework / flowchart / comparison）
- **内容布局**：每张图的构图可以不同
- **语义颜色**：红/绿/蓝/灰 用法不变，但具体元素不同

### 风格锚点

生成第一张图后，记录成功图的关键特征作为"风格锚点"。后续图片 prompt 末尾附加：

```
Maintain visual consistency with previous illustrations:
- Same hand-drawn line style with uneven thickness
- Same color palette: primary #4A90D9, accent #FF6B35, background white
- Same minimalist Notion-style aesthetic
- Same simple stick-figure character design if people appear
```

将风格锚点保存到 `prompts/style-anchor.md`，每次生图时引用。

### Ref 图三级使用

当有参考图片（历史成功图/外部风格参考/品牌素材）时，分三级使用：

| 用法 | 说明 | 操作 |
|------|------|------|
| `direct` | 直接作为视觉参考传给生图模型 | Seedream 图生图模式传 ref |
| `style` | 只提取风格特征，不传文件 | 分析图的线条/质感/构图 → 写入 prompt |
| `palette` | 只提取配色方案，不传文件 | 吸取 3-5 个主色 hex → 写入 prompt COLORS 层 |

**决策规则**：
- 参考图和目标图**同类型**（都是封面 / 都是 framework 图） → `direct`
- 参考图**风格好但内容不同** → `style`
- 参考图**颜色好但风格不同** → `palette`
- 没有参考图 → 不用 ref，走标准 prompt 流程

**操作方式**：
- `direct`：将参考图作为 Seedream/Gemini 的 image reference 输入（需 API 支持图生图）
- `style`：在 prompt 末尾追加 `STYLE (from ref): 清爽线条，微弱阴影，...`
- `palette`：在 prompt 的 COLORS 部分用提取的 hex 值替代默认色

**典型场景**：
- 同一篇文章的第 2-N 张图 → `direct` 引用第 1 张成功图（与风格锚点配合）
- 看到某篇文章的封面风格好 → `style` 提取其视觉特征
- 品牌素材提供了色板 → `palette` 提取色值

---

## 六、禁止清单

- ❌ **不生成与内容无关的装饰性图片**——每张插图必须传递信息
- ❌ **不在图中生成长段文字**——AI 文字渲染不可靠，用短标签（3-5字）
- ❌ **不把比喻画成字面意思**——画底层概念，不画字面场景
- ❌ **不连续放 2 张以上同类型插图**——避免视觉单调
- ❌ **不用彩色渐变/3D效果/阴影**——除非特定风格要求
- ❌ **不用 emoji 替代图标**——截图时 emoji 会变成色块
- ❌ **不在同一篇文章中混用 2 种以上 Style**——视觉割裂
- ❌ **不直接传 inline prompt 给 Seedream/Gemini**——⛔ 必须先存 `prompts/NN-{type}-{slug}.md`，再引用文件内容生图。好处：失败时改文件重试不用重新构思，全部 prompt 有存档可回溯

---

## 七、生图工具优先级

**idealab Chat API → Seedream 5.0 Lite → ComfyUI**

| 工具 | 优势 | 劣势 | 使用场景 |
|------|------|------|---------|
| idealab Chat API | 团队AK免费、无额度压力、~25s/张 | 无 | **首选主力生图** |
| Seedream 5.0 Lite | 0.22元/张、无水印、质量高 | 有成本 | idealab不可用时降级 |
| ComfyUI (本地) | 无费用、无限制 | 需启动、MPS 较慢 | 兜底 |

```bash
# idealab Chat API（首选）
<WORKSPACE>/scripts/generate-image.sh "prompt" output.jpg

# Seedream（降级）
<WORKSPACE>/scripts/seedream-generate.sh "prompt" output.jpg "2560x1440" 1
```

### 批量生成策略

当一篇文章的所有 prompt 文件（`prompts/NN-*.md`）都已写好时，可批量并行生成而不是逐张串行：

**串行模式（默认）**：逐张生成，每张可即时检查效果、调整 prompt 后重试。适合首次尝试新风格。

**批量模式（推荐，prompt 已确认后）**：
- 使用 baoyu-imagine skill 的 batch mode（`build-batch.ts` → `main.ts --batchfile`）
- 或多个 Seedream 调用并行执行

**选择规则**：
- prompt 还在迭代/探索风格 → 串行
- prompt 全部定稿、只差生图 → 批量
- 同一篇文章 3 张以上配图 → 优先批量（节省 60%+ 等待时间）

---

## 八、Prompt 文件持久化

每篇文章的配图 prompt 保存为独立文件，便于回溯和复用。

### 文件结构

```
wemp-article-NN/
├── draft-v1.md
├── illustration-plan.md          # 配图计划表
├── prompts/                      # prompt 资产
│   ├── style-anchor.md           # 风格锚点（全文一致性参数）
│   ├── 00-cover.md               # 封面图 prompt
│   ├── 00-structure.md           # 结构图 prompt
│   ├── 01-framework-xxx.md       # 正文插图 prompt
│   ├── 02-comparison-xxx.md
│   └── 03-flowchart-xxx.md
└── images/
    ├── cover.jpg
    ├── structure.png
    ├── 01-framework-xxx.png
    ├── 02-comparison-xxx.png
    └── 03-flowchart-xxx.png
```

### Prompt 文件格式

```markdown
---
type: framework
style: notion-sketch
position: §2 "记忆系统设计" 后
purpose: 展示 Agent 记忆的分层架构
ratio: 16:9
tool: seedream
---

# Prompt

[完整的生图 prompt，按 LDSCS-R 六层结构]

# 生成记录
- v1: 2026-03-15 — 文字不清晰，重新生成
- v2: 2026-03-15 — ✅ 最终采用
```


path: references/infographic-layouts.md
content: # 公众号信息图布局库

正文配图中"信息图"类型的专用布局参考。与 `illustration-prompts.md` 中的 Type 维度配合使用。

> 本文件补充 `illustration-prompts.md` 中的 `framework` / `infographic` / `flowchart` / `comparison` Type。
> 当 Type 确定后，可从本文件选择更具体的信息图布局。

---

## 布局索引

| 布局 | 适用场景 | 推荐 Style |
|------|---------|-----------|
| `bento-grid` | 多主题概览、功能模块 | notion-sketch / tech-flat |
| `iceberg` | 表面vs深层、显性vs隐性 | notion-sketch / warm-doodle |
| `funnel` | 筛选/转化、漏斗逻辑 | tech-flat |
| `hub-spoke` | 核心概念+辐射分支 | notion-sketch / tech-flat |
| `bridge` | 问题→解决方案的跨越 | notion-sketch / warm-doodle |
| `hierarchical-layers` | 分层/金字塔/优先级 | tech-flat / notion-sketch |
| `linear-progression` | 时间线/进程/阶段演变 | notion-sketch / tech-flat |
| `dense-modules` | 高密度信息大图、完全指南 | tech-flat |

---

## 布局详细定义

### bento-grid（便当盒网格）

```
结构：模块化网格，不同大小的矩形单元
特点：混合 1x1、2x1、1x2 单元，Hero 单元突出主题
视觉：清晰的单元边界，每个单元有标题+简要内容+小图标
```

**适用**：
- "5个AI能力模块"全景图
- 产品功能总览
- 文章要点概览

**Prompt 指导**：
> Modular bento-grid layout with rectangular cells of mixed sizes. One hero cell (2x2) for the main concept, surrounded by smaller cells. Each cell has a title, brief content, and a simple icon. Clear boundaries between cells.

---

### iceberg（冰山图）

```
结构：水平线分割上下两部分
上方（水面上）：显而易见的、表面的（较小）
下方（水面下）：隐藏的、深层的（较大，占 60-70%）
视觉：上方明亮，下方渐暗；水线清晰
```

**适用**：
- "你看到的PM工作 vs 真实PM工作"
- "AI产品 — 用户看到的 vs 背后的工程"
- 表面现象 vs 根本原因

**Prompt 指导**：
> Iceberg diagram with a clear waterline dividing visible (above, smaller, brighter) from hidden (below, larger, darker). The underwater section is 3x the size of the above-water tip. Gradient showing depth. Labels on both sides.

---

### funnel（漏斗图）

```
结构：从宽到窄的漏斗形，3-5 层递进
视觉：每层颜色渐变或区分，层间有数字/百分比标注
底部是最终输出/结果
```

**适用**：
- "从100个需求到1个MVP"
- 用户转化漏斗
- 信息筛选/决策过滤

**Prompt 指导**：
> Funnel diagram tapering from wide (top) to narrow (bottom), with 3-5 distinct layers. Each layer has a label and a number/percentage. Colors gradient from light (top) to deep (bottom). Arrow at bottom pointing to the final output.

---

### hub-spoke（轮辐图）

```
结构：中心一个核心节点，4-8 个分支向外辐射
视觉：中心节点最大最醒目，分支大小一致，连接线清晰
可选：分支可以有二级子节点
```

**适用**：
- "Agent的6种记忆类型"
- 核心概念+多维解读
- 组织架构/能力地图

**Prompt 指导**：
> Hub-and-spoke diagram with one large central node connected to 4-8 smaller peripheral nodes by straight or curved lines. Central node is the main concept. Each spoke node has a title and brief description. Clean, radial arrangement.

---

### bridge（桥梁图）

```
结构：左侧是"现状/问题"，右侧是"目标/方案"，中间是跨越的桥
视觉：桥梁连接两岸，桥上标注"如何跨越"的关键步骤
底部是"深渊/风险"（可选）
```

**适用**：
- "传统PM → AI时代PM的跨越"
- 问题→解决方案
- 能力差距分析

**Prompt 指导**：
> Bridge diagram connecting "Problem" (left cliff) to "Solution" (right cliff). The bridge itself is labeled with 3-4 key actions/steps needed to cross. Optional: a gap/abyss below labeled with risks of not crossing.

---

### hierarchical-layers（层级/金字塔）

```
结构：3-5 层从底到顶递增/递减
视觉：金字塔形或堆叠层，底层最宽最基础，顶层最窄最高级
每层有标题+简述
```

**适用**：
- "Skill系统的3层架构"
- 马斯洛需求层次类比
- 技术栈分层

**Prompt 指导**：
> Pyramid/layered diagram with 3-5 horizontal layers, widest at bottom (foundation) tapering to narrow at top (highest level). Each layer has a distinct color, title, and 2-3 bullet points. Clear visual hierarchy.

---

### linear-progression（线性进程）

```
结构：从左到右（或从上到下）的时间线/阶段线
视觉：3-6 个节点，每个节点是一个阶段/里程碑，箭头连接
节点可以有日期、标题、简述
```

**适用**：
- "公众号运营4周复盘"
- 产品迭代路线图
- 技术演进历史

**Prompt 指导**：
> Horizontal timeline with 3-6 milestone nodes connected by arrows from left (earliest) to right (latest). Each node has a date/label on top and a brief description below. A progress indicator or color gradient showing advancement.

---

### dense-modules（高密度模块）

```
结构：6-7 个功能型模块紧密排列，几乎无留白
模块类型：
  - 品牌/选项阵列（4-8 项 + "最佳"推荐标记）
  - 规格刻度（数值量表 + 质量指标）
  - 深度解析（局部放大/拆解视图）
  - 场景对比（3-6 个使用场景 + 推荐）
  - 识别技巧（检查清单：看/测/查）
  - 踩坑警示（3-5 个误区 + 后果）
  - 快速参考（决策树/摘要表）
每个模块有编号/标签
```

**适用**：
- "AI PM完全指南"
- 产品选购攻略
- 完整知识体系一张图

**Prompt 指导**：
> High-density infographic with 6-7 distinct labeled modules packed tightly. Each module serves a specific purpose (selection grid, specification scale, deep-dive, scenario comparison, identification tips, warning zone, quick reference). Minimal whitespace. Each module has a coordinate label (MOD-1, MOD-2...). Information in every corner. Smaller text acceptable for density.

**注意**：这种布局信息量极大，建议配合 `tech-flat` 或 `mermaid-render` 风格，确保可读性。正文中最多用 1 次。

---

## 选择指南

| 文章内容特征 | 推荐布局 |
|-------------|---------|
| 文章介绍一个核心概念 + 多个分支/维度 | `hub-spoke` |
| 文章论述"表面看到的 vs 真正的" | `iceberg` |
| 文章有明确的层级/优先级关系 | `hierarchical-layers` |
| 文章有时间演进或阶段划分 | `linear-progression` |
| 文章是"问题→解决方案"结构 | `bridge` |
| 文章有筛选/转化/逐步减少的逻辑 | `funnel` |
| 文章需要多主题概览（5+ 主题） | `bento-grid` |
| 文章需要一张"完全指南"大图 | `dense-modules` |


path: references/style-guide.md
content: # 语言风格指南

## Voice Dimensions（量化风格锚点）

写作时以这些分数为锚点，确保风格一致。详见 `<WORKSPACE>/memory/style-runs/voice-dimensions.md`。

| Dimension | Score | 说明 |
|-----------|-------|------|
| formal_casual | **4/10** | 口语化但有逻辑 |
| technical_accessible | **6/10** | 技术用比喻，不回避深度 |
| serious_playful | **5/10** | 中间偏正经，每 200 字 1 个微幽默 |
| concise_elaborate | **5/10** | 2000-3000 字，每段 3-5 句 |
| reserved_expressive | **7/10** | 有观点敢判断，承认局限 |

## 句式

- 短句优先，单句 ≤25 字
- 多用并列结构和小标题
- 用「我们」「你」增加亲切感
- **句子节奏变化**：短句(5-10字) + 中句(15-25字) + 长句(25-35字) 交替，不允许连续 3 句同长度。朗读检查——如果读起来像背课文，节奏出了问题

## 术语处理

技术术语首次出现必须解释，优先用比喻：
- ❌ 「RAG 通过检索增强生成来提升 LLM 的准确性」
- ✅ 「RAG 就像给 AI 配了一个随时能查资料的助手——先搜索相关文档，再基于搜到的内容回答」

可以为复杂概念创造**概念把手**——3-6 字的记忆短语（如"提示词幻觉"、"工具疲劳"），首次出现时用一句话定义，之后直接用短语指代。

## 链接格式

微信公众号不支持超链接，统一用纯文本：
- ❌ `[官网](https://example.com/)`
- ✅ `官方网站：https://example.com/`

## Emoji 使用

- 小标题可以用 1 个 emoji 做标记
- 正文中极少使用，点缀即可
- 不要每句话都加 emoji

## 数据引用

- 引用数据标明来源
- 没有确切数据不要编
- 「据官方数据」「根据我的测试」要区分清楚

## 段落节奏

- 每段 3-5 句话
- 段间留白，不堆叠
- 关键结论单独成段，加粗
- **多巴胺密度**：每段至少 1 个"有意思"的点（洞见/例子/比喻/微幽默），连续 3 段没有 = 危险区域

## 微幽默

- 每 200 字至少 1 个让读者嘴角上扬的小细节
- 类型：意外的细节、自嘲式诚实、夸张但真实、有趣的词放句末
- 不是讲段子，是在正经内容中埋入轻松感
- 不能牺牲信息量

## 欧化中文自检（翻译/引用外文后必查）

翻译或大量引用英文内容后，逐条检查"翻译腔"：

| # | 问题 | 表现 | 修正 |
|---|------|------|------|
| 1 | 多余连接词 | "因此/然而/此外/另外"密集出现 | 上下文已暗示关系时直接删掉 |
| 2 | 被动语态滥用 | "被/由/受到"过多 | 改主动语态（"X 被 Y 影响"→"Y 影响了 X"）|
| 3 | 名词堆砌 | 长定语链（"基于大模型的智能化运营提效解决方案"） | 拆短句 |
| 4 | "是...的"句式 | "这是一个非常重要的功能" | "这个功能很重要" |
| 5 | 过度名词化 | "进行了讨论/做出了改进" | "讨论了/改进了" |
| 6 | 多余代词 | "他/她/它/我们/你"出现频率过高 | 中文可省略主语时省略 |

**快速自测**：对着段落问——"这读起来像中国人写的，还是翻译的？"像翻译的 → 按上面 6 项逐个排查。

**触发条件**：文章素材中有 ≥30% 来自英文源 → 必须跑一遍欧化检查。

> **术语一致性**：翻译时参照 `~/.openclaw/workspace/references/glossary-ai-zh.md` 统一术语。

---

## 内容价值检查

写完后对照以下 3 条原则（来源：Lenny's Podcast 内容营销洞察）：

1. **Painkiller, not vitamin**：这篇文章解决了读者的一个具体痛点吗？还是只是"了解一下也好"的维生素？痛点文章才有传播力。
2. **End the Google search**：读者读完你的文章后，还需要再去搜索同一个话题吗？如果需要，说明信息密度不够——要么加深度，要么缩窄范围。
3. **AI-assisted, not AI-generated**：人提供 information gain（独特观点、一手经验、真实案例），AI 辅助执行（结构、润色、排版）。纯 AI 生成的内容没有信息增量。

---

## 降 AI 味检查

写完后对照以下特征自查，出现 2 个以上需要改写：
- 对称句式（"不仅…而且…"）超过 2 次
- "然而"、"值得注意的是"等万能转折词
- "综上所述"、"总而言之"等总结套话
- "让我们一起来看看"等过度礼貌
- 动不动"第一…第二…第三…"的列表强迫症
- "应运而生"、"如火如荼"等四字成语堆砌
- "想象一下…"式假设修辞（换成真实案例）
- "令人兴奋的是"等情感注入过度

## 写作 Anti-Pattern 检查

定稿后必须过一遍 `~/.openclaw/workspace/references/writing-anti-patterns.md`：
- 🔴 绝对禁止项：命中任何一条必须改（"不是X而是Y"、破折号滥用、三段式凑数等）
- 🟡 警惕区：偶尔可以，频繁出现就改
- 🟢 正面特征：确认有"我"的声音、具体场景、节奏变化
- 10 秒快扫：开头/破折号/此外然而/三段式/AI味

## 文章只输出正文

- ✅ 只保留：标题 + 封面图 + 正文 + 结尾
- ❌ 不添加：「参考资料」「图片说明」「延伸阅读」「优缺点总结表」


path: references/weixin-constraints.md
content: # 微信公众号平台限制

## CSS 限制

微信编辑器**不支持**：
- 外部 CSS 文件（必须内联）
- `position: fixed/sticky`
- `@keyframes` 动画
- `calc()` 函数
- CSS 变量 `var()`
- `flexbox`（部分支持，不稳定）
- `grid` 布局

**支持的常用属性**：
- `color`, `background-color`, `background` 渐变
- `font-size`, `font-weight`, `line-height`, `letter-spacing`
- `margin`, `padding`, `border`, `border-radius`
- `text-align`, `text-indent`
- `display: inline/block/inline-block`
- `box-shadow`（部分客户端）
- `max-width`, `width`（百分比和 px）

## 图片限制

- 不支持本地图片路径，必须上传到微信素材库
- 封面图建议 900×500（2.35:1 也可）
- 单图 ≤ 2MB
- 支持格式：jpg/jpeg/png/gif
- 文章内图片会被微信压缩

## 内容限制

- 不支持 JavaScript
- 不支持 iframe
- 不支持外部链接（超链接只能链接到其他公众号文章或小程序）
- 所有链接在正文中用纯文本展示
- 不支持视频直接嵌入（需用微信视频功能）

## 排版建议

- 正文字号：15-17px
- 行高：1.75-2.0
- 段间距：通过 margin-bottom 控制
- 代码块用 `pre + code` + 背景色 + 内联样式
- 表格列数 ≤ 4（移动端友好）
- 全文内联样式写在每个标签的 `style` 属性中

## 外链处理规则

微信公众号不支持外链点击跳转。文章中的外部链接按以下规则处理：

### 处理分类

| 链接类型 | 处理方式 |
|---------|---------|
| `mp.weixin.qq.com` | 保持原样（微信内部互链可跳转） |
| 普通外链（博客/GitHub/文档等） | 转为底部引用格式 |
| 裸链接（链接文字=URL本身） | 保持 inline 纯文本 |

### 转换格式

**正文中**：在引用处加上标序号
```
参考 Simon Willison 的文章[1]，以及 Anthropic 的 Skills 文档[2]。
```

**文末新增**"引用链接"区：
```
---
**引用链接**
[1] Agentic Engineering Patterns - https://simonwillison.net/2025/...
[2] Claude Code Skills - https://docs.anthropic.com/en/docs/...
```

### 执行时机

Editor Agent 写完文章后、推草稿箱前：
1. 扫描正文所有外部链接
2. 排除 `mp.weixin.qq.com` 和裸链接
3. 按出现顺序编号 [1][2][3]...
4. 正文中替换为 `文字[N]`
5. 文末追加"引用链接"区
6. 微信 API 推送时使用处理后的版本

---

## API 限制

- access_token 每日获取上限 2000 次（工具自动缓存）
- 草稿 API 无频率限制
- 群发消息：订阅号 1 次/天，服务号 4 次/月
- 素材上传：单文件 ≤ 2MB（图片）、≤ 10MB（视频）


path: references/writing-sop.md
content: # 写作 SOP

## 写作前

1. **明确内容类型**（见 article-templates.md）
2. **确认素材充足**：至少 2 篇高质量参考来源 + 收藏库相关素材
3. **确定文章角度**：这篇文章给读者的核心价值是什么？用一句话说清
4. **搜索个人素材库**：从 `collections/` 中检索相关素材，标记可用的真实经历/观点/案例（详见 writing-techniques.md §五）

## 写作流程

### 1. 搜索与素材准备

搜索策略（2-4 轮）：
- 第 1 轮：官方信息（官网、GitHub、官方博客）
- 第 2 轮：深度分析（技术博客、评测文章）
- 第 3 轮：对比与讨论（竞品对比、社区讨论）
- 第 4 轮（按需）：补充验证

优先来源：官方文档 > 少数派/掘金/Medium > 知乎/即刻讨论 > 技术博客

提取要点：
- 核心功能和特性
- 真实使用场景和效果
- 优势和局限
- 不同观点和争议

### 2. 创意排水（正式动笔前必做）

在构思框架之前，先执行创意排水（详见 writing-techniques.md §一）：

1. 花 2-3 分钟快速写出"不过脑子的话我会怎么写"——把第一反应、套路想法、陈词滥调全倒出来
2. 标记其中的废水模式（时代感叹句？万能过渡？结论套话？）
3. 把废水清单作为正式写作的"禁用列表"

> 这一步的目的是从源头降 AI 味。事后替换同义词是治标，创意排水是治本。

### 3. 构思框架

根据内容类型选择模板（见 article-templates.md），确定：
- 开头用什么钩子引入（必须遵循强开头原则，见 writing-techniques.md §二.2）
- 正文的 3-4 个主要段落各讲什么
- 结尾给读者什么行动建议
- 哪些地方可以插入收藏库的真实素材

### 4. 写作

核心原则：
- **用自己的语言重新组织**，绝不照搬原文
- **实战导向**：少讲「是什么」，多讲「怎么用」「踩过什么坑」
- **有观点有立场**：不做信息搬运工
- **面向普通用户**：技术术语必须解释，多用比喻

写作中注意（详见 writing-techniques.md §二）：
- **微幽默**：每 200 字至少 1 个让读者嘴角上扬的小细节
- **概念把手**：为复杂概念创造 3-6 字的记忆短语，每篇至少 1-2 个
- **句子节奏**：短/中/长句交替，不允许连续 3 句同长度
- **多巴胺密度**：每段至少 1 个"有意思"的点，连续 3 段没有 = 危险区域

### 5. 标题生成（双轨制）

按 writing-techniques.md §四 的双轨制生成标题：
1. 先出 3-5 个爆款标题（金钱数字/暴力隐喻/悬念等要素）
2. 再出 3-5 个自然风格标题（经验分享/观点输出/对比评测等类型）
3. 可选：组合优化（自然标题 + 注入 1-2 个爆款要素）
4. 推荐 Top 3 给老板选择

### 6. 三遍审校

按 writing-techniques.md §三 执行结构化审校：

**第一遍 — 内容审校：**
- [ ] 所有数据/事实有出处或标注为个人经验
- [ ] 论点之间有因果或递进关系
- [ ] 段落迷你论点串联测试通过（每段核心论点串起来 = 文章逻辑摘要）
- [ ] 没有前后矛盾的说法

**第二遍 — 风格审校（降 AI 味）：**
- [ ] 对照 AI 味特征清单逐条检查（对称句式、转折万能词、总结套话、列表强迫症等）
- [ ] 创意排水阶段标记的废水模式没有出现
- [ ] 用第一人称叙述，有真实场景
- [ ] 口语化但有逻辑

**第三遍 — 细节打磨：**
- [ ] 句子节奏分布检查：无连续 3+ 句同长度
- [ ] 多巴胺密度标记：无连续 3 段空白
- [ ] 微幽默检查：全文 ≥ 3 个，分布均匀
- [ ] 概念把手确认：至少 1 个原创概念把手
- [ ] 字数 2000-3000 字

格式检查：
- [ ] 链接使用纯文本（不用 markdown 超链接）
- [ ] 没有「参考资料」「图片说明」等额外章节
- [ ] 正文从 H2 开始（不出现 H1）

## 写作禁忌

- ❌ 大段照搬原文
- ❌ 无观点的信息搬运
- ❌ 堆砌技术术语不解释
- ❌ 「Great question!」式的废话开头
- ❌ 面面俱到但什么都没讲深
- ❌ "在当今 XX 的时代…"等时代感叹句开头
- ❌ 连续使用"然而"、"值得注意的是"等 AI 味转折词
- ❌ 编号列表贯穿全文（叙事优先，编号点缀）
- ❌ 四字成语堆砌（"应运而生"、"如火如荼"）


path: scripts/check_comments.mjs
content: #!/usr/bin/env node
/**
 * 评论检查 - 扫描最近文章的新评论
 */
import {
  output, outputError, parseArgs,
  listPublished, listComments
} from './lib/utils.mjs';

async function checkComments(articleCount = 5) {
  console.error(`[评论] 检查最近 ${articleCount} 篇文章的评论...\n`);

  // 获取已发布文章
  const published = await listPublished(0, articleCount);
  const articles = published.item || [];
  if (!articles.length) {
    console.error('没有已发布的文章。');
    return { articles: [], totalComments: 0, unreplied: 0 };
  }

  const results = [];
  let totalComments = 0;
  let unreplied = 0;

  for (const article of articles) {
    const newsItem = article.content?.news_item?.[0];
    const title = newsItem?.title || '未知标题';
    const msgDataId = article.article_id;

    if (!msgDataId) continue;

    try {
      const commentsData = await listComments(msgDataId, 0, 0, 50, 0);
      const comments = commentsData.comment || [];
      const total = commentsData.total || comments.length;

      const commentList = comments.map(c => ({
        id: c.user_comment_id,
        content: c.content,
        user: c.nick_name || '匿名',
        time: c.create_time ? new Date(c.create_time * 1000).toLocaleString('zh-CN') : '',
        isElected: !!c.is_elected,
        hasReply: !!(c.reply?.content),
        replyContent: c.reply?.content || '',
      }));

      const unrepliedComments = commentList.filter(c => !c.hasReply);
      totalComments += total;
      unreplied += unrepliedComments.length;

      results.push({
        articleId: msgDataId,
        title,
        totalComments: total,
        unrepliedCount: unrepliedComments.length,
        comments: commentList,
      });

      // 输出摘要
      console.error(`📝 《${title}》`);
      console.error(`   评论: ${total} 条, 未回复: ${unrepliedComments.length} 条`);
      if (unrepliedComments.length) {
        for (const c of unrepliedComments.slice(0, 3)) {
          console.error(`   💬 ${c.user}: ${c.content.slice(0, 50)}${c.content.length > 50 ? '...' : ''}`);
        }
      }
      console.error('');
    } catch (e) {
      console.error(`   ⚠️ 《${title}》评论获取失败: ${e.message}\n`);
    }
  }

  console.error(`━━━━━━━━━━━━━━━━━━━━━━━━━━━━`);
  console.error(`总计: ${totalComments} 条评论, ${unreplied} 条未回复`);

  return { articles: results, totalComments, unreplied };
}

async function main() {
  const args = parseArgs();
  const count = parseInt(args.count) || 5;
  try {
    const result = await checkComments(count);
    output(true, result);
  } catch (error) { outputError(error); }
}

main();


path: scripts/daily_report.mjs
content: #!/usr/bin/env node
/**
 * 公众号日报
 */
import {
  loadConfig, output, outputError, parseArgs, formatDate, getYesterday, calcChangeRate,
  readData, writeData,
  getUserSummary, getUserCumulate, getArticleSummary, getUpstreamMsg, listPublished
} from './lib/utils.mjs';

async function generateDailyReport(date) {
  const config = loadConfig();
  const reportDate = date || getYesterday();
  console.error(`[日报] 生成 ${reportDate} 的日报...`);

  // 用户数据
  let newUsers = 0, cancelUsers = 0;
  try {
    const r = await getUserSummary(reportDate);
    for (const i of (r.list || [])) { newUsers += i.new_user || 0; cancelUsers += i.cancel_user || 0; }
  } catch (e) { console.error(`[日报] 用户数据失败: ${e.message}`); }
  const netGrowth = newUsers - cancelUsers;

  // 累计用户
  let totalUsers = 0;
  try {
    const r = await getUserCumulate(reportDate, reportDate);
    if (r.list?.length) totalUsers = r.list[0].cumulate_user || 0;
  } catch (e) { console.error(`[日报] 累计用户失败: ${e.message}`); }

  // 文章数据
  let totalRead = 0, totalShare = 0;
  try {
    const r = await getArticleSummary(reportDate);
    for (const i of (r.list || [])) { totalRead += i.int_page_read_count || 0; totalShare += i.share_count || 0; }
  } catch (e) { console.error(`[日报] 文章数据失败: ${e.message}`); }

  // 消息数据
  let newMessages = 0;
  try {
    const r = await getUpstreamMsg(reportDate);
    for (const i of (r.list || [])) { newMessages += i.msg_count || 0; }
  } catch (e) { console.error(`[日报] 消息数据失败: ${e.message}`); }

  // 已发布文章
  let topArticles = [];
  try {
    const r = await listPublished(0, 10);
    topArticles = (r.item || []).slice(0, config.analytics?.topArticles || 5).map((item, idx) => ({
      rank: idx + 1, title: item.content?.news_item?.[0]?.title || '未知标题'
    }));
  } catch (e) { console.error(`[日报] 已发布文章失败: ${e.message}`); }

  // 历史对比
  const history = readData('daily-history.json', { reports: [] });
  const last = history.reports?.length ? history.reports[history.reports.length - 1] : null;
  const growthRate = last ? calcChangeRate(netGrowth, last.netGrowth) : '-';
  const readChange = last ? calcChangeRate(totalRead, last.totalRead) : '-';

  // AI 洞察
  let insight = '数据平稳，建议持续优化内容策略。';
  if (netGrowth > 10) insight = `今日净增 ${netGrowth} 位粉丝，增长势头强劲！`;
  else if (netGrowth > 0) insight = `今日净增 ${netGrowth} 位粉丝，保持良好增长。`;
  else if (netGrowth < 0) insight = `今日净流失 ${Math.abs(netGrowth)} 位粉丝，建议关注内容质量和推送时间。`;

  const reportData = { date: reportDate, newUsers, cancelUsers, netGrowth, growthRate, totalUsers, totalRead, totalShare, readChange, topArticles, newMessages, insight };

  // 保存历史
  if (!history.reports) history.reports = [];
  history.reports.push({ date: reportDate, netGrowth, totalRead, totalUsers, generatedAt: new Date().toISOString() });
  if (history.reports.length > 30) history.reports = history.reports.slice(-30);
  writeData('daily-history.json', history);

  // 生成报告文本
  const lines = [
    `📊 **公众号日报** (${reportData.date})`, `━━━━━━━━━━━━━━━━━━━━━━━━━━━━`, '',
    `**👥 用户数据**`,
    `• 新增关注: +${newUsers}`, `• 取消关注: -${cancelUsers}`,
    `• 净增长: ${netGrowth >= 0 ? '+' : ''}${netGrowth} (${growthRate})`,
    `• 累计粉丝: ${totalUsers.toLocaleString()}`, '',
    `**📖 阅读数据**`,
    `• 总阅读: ${totalRead.toLocaleString()} 次 (${readChange})`,
    `• 总分享: ${totalShare} 次`,
  ];
  if (topArticles.length) {
    lines.push('', `**🔥 热门文章**`);
    topArticles.forEach(a => lines.push(`${a.rank}. 《${a.title}》`));
  }
  lines.push('', `**💬 互动数据**`, `• 新消息: ${newMessages} 条`, '', `**💡 AI 洞察**`, insight, '', `━━━━━━━━━━━━━━━━━━━━━━━━━━━━`);

  return { report: lines.join('\n'), data: reportData };
}

async function main() {
  const args = parseArgs();
  try {
    const { report, data } = await generateDailyReport(args.date);
    console.error('\n' + report);
    output(true, { report, data });
  } catch (error) { outputError(error); }
}

main();


path: scripts/reply_comment.mjs
content: #!/usr/bin/env node
/**
 * 评论回复 + 精选
 * 
 * 回复: node reply_comment.mjs --article-id <id> --comment-id <id> --content "回复内容"
 * 精选: node reply_comment.mjs --article-id <id> --comment-id <id> --elect
 * 同时: node reply_comment.mjs --article-id <id> --comment-id <id> --content "回复内容" --elect
 */
import {
  output, outputError, parseArgs,
  replyComment, electComment, unelectComment
} from './lib/utils.mjs';

async function main() {
  const args = parseArgs();
  const articleId = args.articleId;
  const commentId = args.commentId ? parseInt(args.commentId) : null;

  if (!articleId) { outputError(new Error('请指定 --article-id')); return; }
  if (!commentId) { outputError(new Error('请指定 --comment-id')); return; }

  const results = {};

  try {
    // 回复
    if (args.content) {
      console.error(`[评论] 回复评论 ${commentId}: ${args.content}`);
      await replyComment(articleId, 0, commentId, args.content);
      results.replied = true;
      console.error('✅ 回复成功');
    }

    // 精选
    if (args.elect) {
      console.error(`[评论] 精选评论 ${commentId}`);
      await electComment(articleId, 0, commentId);
      results.elected = true;
      console.error('✅ 精选成功');
    }

    // 取消精选
    if (args.unelect) {
      console.error(`[评论] 取消精选 ${commentId}`);
      await unelectComment(articleId, 0, commentId);
      results.unelected = true;
      console.error('✅ 取消精选成功');
    }

    output(true, { articleId, commentId, ...results });
  } catch (error) { outputError(error); }
}

main();


Security scan verdicts — ClawScan: suspicious | static analysis: suspicious | VirusTotal: clean | SkillSpector: suspicious (CRITICAL)