内容工厂

高质量内容创作标准（2026-04-17 更新）

爆款文章核心公式

标题 + 开头 = 80%的阅读量

流量权重公式（来自饼干哥哥200+篇文章数据验证）：

• 选题占 50%
• 标题占 20%
• 正文占 20%
• 开头占 10%

⚠️ 90%的人第一步就错了——第一步不是写提示词，是选题。

选题不对，内容再好也是从零开始。同一个工具，换个选题角度，数据天差地别。

核心原则

文章必须给用户带来真正价值：

1. 学到具体的方法论 - 不是泛泛而谈，有可操作的方法
2. 能实操的指南 - 照着做就能成，给提示词、给代码、给步骤
3. 开拓视野提升认知 - 看到以前没想过的东西，认知升级

标题写法

• 争议/对比词：「手撕Sora，脚踢Veo」「黑奴」「智商税」
• 数字吸睛：「13个行业实战案例」
• 疑问句引发好奇：「真的值吗？」
• 颠覆认知：挑战传统观点

开头写法

Hook 是必须的：开头必须有一个 Hook，不能直接进入正文。

Hook 的结构：承认一个普遍痛点 + 今天这期的独特发现

Jeff 给的示范：

「大家使用 OpenClaw，其实并没有特别好的找到商业应用场景。今天通过地图 API 的结合，让我们看到了更多商业落地应用的可能性。」

其他 Hook 示例：

• 「很多人装了 OpenClaw，但不知道它还能这样用……」
• 「你以为 OpenClaw 只能聊天？实际上它能干这个……」
• 「大多数人用 AI 工具只用到了一成功能……」

一句话总结：开头先承认用户的困惑或局限，再抛出今天的发现，让读者觉得『这正是我需要的』。

开头/结尾类型框架（来自饼干哥哥）

四种高转化开头类型：

• 嘴替共鸣型：说出读者心里话
• 反常识型：违反常识的事实
• 个人故事型：真实场景代入
• 数据冲击型：意外数据制造好奇

禁止开头用：「你知道吗」「很多人不知道」「今天分享」「值得注意的是」

提示词模板（让AI批量生成开头）：

给我这个主题写10个开头：
前5个用不同情绪触发（好奇/恐惧/惊喜/共鸣/挑衅）
后5个用不同结构（数字/问句/故事/反常识/悬念）
每个不超过15字
禁止「你知道吗」「很多人不知道」「今天分享」
主题：[填你的主题]

三种强力结尾类型：

• 首尾呼应：呼应开头场景形成闭环
• 个人表态：加入你的判断和偏见
• 数据收尾：一个反直觉数据留下认知冲击

禁止结尾用：总结全文、展望未来趋势、以「总之/综上/希望」开头

提示词模板（让AI按类型写结尾）：

为这篇文章写3个不同风格的结尾，禁止：
x 总结全文
x 提到「AI门槛/人工介入/未来趋势」
x 以「总之/综上/希望」开头

要求：
A：首尾呼应，呼应开头的 [填你的开头场景]
B：以作者个人的反常识判断收尾
C：以一个反直觉数据收尾

正文结构

2-3个具体案例，层层递进：

每个案例包含：

• 具体场景（扔给AI什么任务）
• 真实过程（提示词、报错、改Bug）
• 结果展示（截图、链接、数据）
• 优缺点分析（不藏着掖着）

干货要求

• 给可直接抄作业的提示词
• 完整代码示例
• 真实项目名和案例
• 工作流拆解

好内容的六条黄金标准

来自饼干哥哥对比200+篇文章数据后提炼——阅读量和完读率双高的文章，基本都符合这六条：

这六条标准就是给AI下指令的核心约束条件。

真诚原则

• 报错经历也分享
• 槽点大方承认
• 效果对比（Before/After）
• 提供测试链接和在线Demo

结尾升华

• 方法论总结
• 未来趋势展望
• Agent自动化想象空间

三篇文章对照学习

概述

八、高阅读量文章共同点（来自饼干哥哥、藏师傅分析）

1. 选题精准

• 蹭热点 + 独特视角
• 解决具体问题
• 目标人群明确

2. 结构清晰

• 层层递进
• 案例丰富
• 重点突出

3. 语言生动

• 有情绪（有态度）
• 有细节（不说正确的废话）
• 有对话感（像在跟朋友聊天）

4. 利他思维

• 读者能得到什么？
• 看完能做什么？
• 为什么转发？

5. 平台友好

• 关键词布局
• 开头有关键词
• 结尾引导互动

使用此技能时，根据提供的主题或标题，结合 YouTube 研究、用户确认与专业写作，并通过自我迭代生成完整的微信公众号“爆款风格”文章，输出 Markdown 与 HTML 两种格式。

重要：工具依赖检查（必须首先执行）

在开始任何研究之前，强制进行工具检查：

步骤 1：检查 yt-dlp 是否安装

yt-dlp --version

如果未安装或命令失败：

• 立即停止
• 告知用户：“yt-dlp 工具是用于 YouTube 内容提取的必需工具”
• 提供安装命令：pip install yt-dlp
• 等待用户安装完成后方可继续
• 未经检查不得跳过至替代方法

步骤 2：验证脚本文件是否存在

ls scripts/yt_dlp_search.py
ls scripts/yt_dlp_captions.py

如果脚本缺失：

• 检查技能基础目录：~/.claude/skills\content-factory\scripts\
• 若文件不存在，请告知用户
• 未经验证脚本可用性前不得继续

步骤 3：验证网络搜索工具

# 测试 Tavily（主用）——先检查凭证
python3 -c "import json; print(json.load(open('/root/.openclaw/credentials/tavily.json'))['api_key'])" && echo "Tavily: OK"

# 测试 Brave（备用）——检查凭证
python3 -c "import json; print(json.load(open('/root/.openclaw/credentials/brave.json'))['api_key'])" && echo "Brave: OK"

# 测试 smart_search 脚本
python3 /root/.openclaw/workspace/scripts/smart_search.py "test" --max-results 1 2>&1 | head -5

如果 Tavily / Brave 凭证存在：

• ✅ “Web search tools verified: Tavily API ✓, Brave API ✓”
• 使用 smart_search.py 进行网络研究（优先 Tavily，次选 Brave）

如果凭证缺失：

• ⚠️ “Web search credentials not found in credentials/ — check Tavily/Brave setup”
• 降级为：YouTube 搜索结果 + X/Nitter + 官方页面（仍可有效使用）

步骤 4：工具状态通报

始终向用户通报工具状态：

• ✅ “yt-dlp 已安装（版本 X.X.X），继续进行 YouTube 内容提取”
• ✅ “Web search：Tavily ✓，Brave ✓”
• ❌ “yt-dlp 未找到，请使用：pip install yt-dlp”
• ⚠️ “脚本已找到但 yt-dlp 缺失，需安装”
• ⚠️ “Web search 不可用 — 使用 YouTube 搜索 + X/Nitter + 官方页面”

重要原则：

• 工具检查是前置条件，不可省略
• “可选运行脚本”意为“如有则用”，并非“不便时跳过”
• 本地脚本为主方法，WebFetch 为备选
• 未经检查不得假设工具不可用
• **网络搜索：始终优先使用 smart_search.py 执行（Tavily → Brave 备用）**

- 测试命令：python3 /root/.openclaw/workspace/scripts/smart_search.py "test" --max-results 1

- 不得将 OpenClaw 内置的 web_search 工具作为主要手段（其使用独立的 Brave key 配置）

工作流程

1）信息收集与澄清

• 必须获取用户提供的标题或主题。
• 询问缺失的关键信息：目标受众、所属行业/地区、语气风格（严肃 vs. 强劲）、期望长度、发布时间范围限制。
• 确认语言偏好；默认输出中文，除非用户另有要求。

2）多源网络调研

重要：研究应来自多样化网络来源——YouTube 是关键来源之一，但非唯一来源。

主要研究来源（按优先级排序）：

Skill: 内容工厂

Version: 1.0.2

Chunk: 2/11

1. YouTube 视频（案例研究与专家洞察的主要来源）

关键：YouTube 内容提取优先级顺序

首选方法（优先尝试）：

• 运行 scripts/yt_dlp_search.py 搜索并收集视频元数据

python scripts/yt_dlp_search.py "你的搜索关键词" --max-results 10

• 使用 scripts/yt_dlp_captions.py 下载字幕/逐字稿

python scripts/yt_dlp_captions.py VIDEO_URL --whisper-if-missing

• 此类脚本可提供：标题、频道、播放量、上传日期、时长、URL、完整逐字稿

备选方法（若脚本失败时使用）：

• 尝试在 YouTube 视频页面使用 WebFetch 工具
• 若 WebFetch 被拦截，请求用户提供视频链接
• 通过 exec 调用 smart_search.py 查找 YouTube 视频链接，再提取元数据

最后手段（所有 YouTube 访问均失败时）：

• 转向其他来源（文章、报告、博客）
• 在文章中明确标注 YouTube 内容不可用
• 以更多行业报告和专家博客作为补充

内容提取指南：

• 加载 references/youtube_research_checklist.md 获取详细提取步骤
• 选取 2–4 个高播放量、高度相关的视频（优先选择播放量前 20% 的）
• 从逐字稿、描述、视频章节中提取可验证的数据
• 记录信息包括：标题、频道、播放量、上传日期、时长、URL、逐字稿节选、相关性说明

2. 官方文档与公告

• 公司博客（如 anthropic.com/news、openai.com/blog）
• 官方产品文档
• 新闻稿与官方声明
• GitHub 仓库（README、发布说明）

3. 行业分析与报告

• Gartner、Forrester、McKinsey 报告
• TechCrunch、VentureBeat、The Verge 新闻文章
• 行业特定出版物
• 研究论文与白皮书

4. 专家博客与技术内容

• Medium、Dev.to、Hacker News 讨论
• 行业专家个人博客
• 思想领袖的 LinkedIn 文章
• 技术教程与真实案例研究

5. 社区讨论与评价

• Reddit 帖子（如 r/MachineLearning、r/artificial）
• Stack Overflow 技术讨论
• Product Hunt 评价
• Twitter/X 上认证专家的长文分享

研究策略：

• 构建 5–10 个多样化搜索查询，覆盖以下维度：

- 核心主题关键词（如：“Claude Cowork 企业部署”）

- 使用场景（如：“AI 代理工作流自动化案例”）

- 问题/解决方案组合（如：“减少报告生成时间 AI”）

- 行业趋势（如：“2026 年 AI 代理采用预测”）

- 对比类查询（如：“Claude Cowork vs Copilot”）

• 使用 WebSearch 和 WebFetch 工具 从多个来源获取内容
• 多样化来源类型：混合视频、文章、报告、讨论
• 优先近期内容：聚焦过去 3–6 个月的内容，除非主题需要历史背景

内容提取指南：

• 仅基于可验证来源进行总结 —— 提取实际内容，不包含推测
• 每条数据点必须明确标注来源类型与 URL：

- “根据 Anthropic 官方博客 (anthropic.com/news/...)”

- “YouTube 视频《...》中提到 (youtube.com/watch?v=...)”

- “Gartner 2026 年报告指出 (...)”

- “TechCrunch 报道称 (techcrunch.com/...)”

• 关键数据尽可能交叉验证 来自多个来源
• 记录发布时间 以确保信息时效性
• 注明可信度指标：作者资质、媒体声誉、引用数据来源

当无法访问网络时：

• 请求用户提供链接或内容摘录
• 请求授权启用网络搜索工具
• 使用已有参考文献与文档完成研究

3）提炼多源视角

• 提取 3–7 项跨来源洞察：重复出现的痛点、反常识数据、普遍错误、可操作策略（来自视频、文章、报告、讨论等）
• 识别共识模式：多个可信来源是否达成一致？
• 发现独特洞察：是否有单一高可信来源揭示了他人未提及的信息？
• 记录观点冲突：不同来源是否存在分歧？（可作为文章角度）
• 将洞察转化为适合微信传播的表达形式：

- 零基础入门指南

- 破除常见误解内容

- 可执行清单

- 趋势分析 + 未来预测

- 基于真实数据的案例研究

4）生成选题并确认用户意见

• 加载 references/wechat_viral_frameworks.md 以丰富角度与钩子
• 基于多源网络调研（YouTube、博客、报告、讨论），生成 3–5 个潜在文章选题

4.5）将研究内容写入共享记忆（强制要求）

关键：在向用户展示选项前，必须将完整研究上下文写入共享内存。

原因：定时任务在独立会话中运行。向飞书展示选项后，会话结束。当用户在主会话中回复“选X”时，Chief Agent 必须能检索到完整研究上下文。

写入文件路径：

/root/.openclaw/workspace/memory/daily/research-YYYY-MM-DD.md

文件内容必须包含：

• 所有候选选题（含标题、目标读者、核心承诺）
• 每一个 YouTube/视频链接（这是最常遗漏的部分）
• 每个选题的完整大纲
• 所有参考资料的 URL
• 推荐的首选项（Option 1）及推荐理由

格式示例：

# Research - YYYY-MM-DD

## Candidate 1 (Recommended)
**Title:** ...
**Target:** ...
**Source URLs:** https://youtube.com/... (关键——必须全部包含)
**Outline:** ...

## Candidate 2
...

完成内存写入后，再进入下一步（第 5 步）向用户展示选项。

🚨 关键提醒：选题方向 —— 应用导向（2026-03-17 更新）

⚠️ 禁止生成纯技术类选题！以下方向严禁出现：

• ❌ 模型对比（如：DeepSeek vs GPT-4）
• ❌ API 更新（如：OpenAI 新 API 发布）
• ❌ 纯技术解读（如：MoE 架构解析）
• ❌ 论文解读（如：最新 AI 论文分析）

✅ 必须生成应用导向选题！优先方向：

内容工厂

1. 技能 - Agent 技能使用技巧

• 如何利用 AI Agent 提升工作效率

掌握核心指令设计与任务分解方法，实现复杂任务的自动化执行。

• 特定技能的使用秘笈与最佳实践

针对内容生成、数据分析、会议纪要等高频场景，提供可复用的操作模板。

• 自动化工作流的搭建经验

从需求分析到流程编排，分享真实项目中的搭建路径与避坑指南。

2. 应用场景 - AI Agent 实际案例

• AI 在具体工作中的落地案例

展示在营销策划、客户服务、研发支持等岗位的实际应用效果。

• 行业场景的 AI 解决方案

覆盖电商、教育、金融等行业，提供定制化解决方案思路。

• 真实用户的使用体验分享

收集一线从业者反馈，呈现工具带来的效率变化与使用痛点。

3. 商业模式分析 - AI 创业与盈利

• AI 产品/服务如何实现盈利

分析订阅制、SaaS、API调用、企业定制等主流变现路径。

• 成功的 AI 商业案例分析

深入拆解如 Notion AI、Jasper、Copy.ai 等产品的增长逻辑。

• AI 创业机会与赛道分析

识别当前高潜力方向，包括垂直领域助手、智能客服、内容合规检测等。

4. 工具评测 - 真实体验对比

• 多款 AI 工具的实际使用对比

对比 ChatGPT、Claude、通义千问、DeepSeek 等主流模型在不同任务中的表现。

• 优缺点分析与使用建议

从响应速度、上下文理解、成本控制等方面给出客观评价。

• 适合不同场景的工具推荐

根据内容创作、代码生成、多语言处理等需求，提供精准匹配建议。

5. 案例分享 - AI 落地实录

• 企业/个人 AI 部署的真实案例

包括初创公司、自由职业者、中大型组织的部署过程与成果。

• 部署成本、效果与经验教训

详细说明投入资源、周期、实际收益及关键失败原因。

• 可复制的 AI 实施方法论

总结“评估-试点-迭代-推广”的标准化实施框架。

6. OpenClaw 专题 - Agent 编排实战

OpenClaw 技巧教程

• OpenClaw 实际使用技巧

掌握任务链配置、状态管理与异常处理机制。

• 多个 Chat App 的配置方法

教程涵盖飞书、微信、Telegram 等平台接入流程。

• Agent 编排最佳实践

通过模块化设计提升系统可维护性与扩展性。

OpenClaw 应用场景

• 使用 OpenClaw 构建自动化工作流

实现从信息收集到报告输出的端到端流程自动化。

• OpenClaw + 飞书/微信/Telegram 集成

详解消息触发、权限控制与跨平台数据同步方案。

• 自定义 Agent 开发

提供开发环境搭建、接口规范与调试工具使用指南。

OpenClaw 商业模式

• 基于 OpenClaw 的 SaaS 服务

分析面向中小企业的低代码 AI 平台构建路径。

• OpenClaw 企业部署案例

展示某制造企业在生产调度优化中的实际部署成效。

选题评估标准：

• 是否对读者具有实际帮助？
• 读者能否立即应用于日常工作？
• 是否具备具体案例与数据支撑？

🚨 重要提示：话题新鲜度要求（2026-03-09）

• 仅可选择过去 24-48 小时内的热点话题
• 涉及 AI/科技类话题，必须核实发布时间，禁止使用过时资讯
• 使用搜索时启用时间筛选：after:2026-03-08 或类似条件
• 若研究 DeepSeek、OpenAI、Anthropic 等机构，请确认最新动态
• 任何发布超过 48 小时的信息均需拒绝

8d2abf78b8490403831aae82052e8e107054b856

• 每个选题需提供：

- 标题（默认中文）

- 目标读者

- 核心承诺/价值

- 大纲（含 3-5 个章节，每章配 1-2 个要点）

- 开篇钩子（1-2 句话吸引注意力）

5）用户确认 - 必须执行

关键步骤：在撰写完整文章前，必须完成以下操作：

• 清晰展示拟选主题与大纲结构
• 使用 AskUserQuestion 工具提问：“您希望我将哪个主题发展为完整文章？”或“该大纲是否批准用于撰写全文？”
• 等待用户明确确认后方可继续
• 允许用户提出大纲修改意见

6）撰写完整文章并自我迭代

确认主题与大纲后进入写作阶段：

第一阶段：初稿撰写

• 严格依据已批准的大纲完成文章撰写
• 字数目标：2000–4000 中文字
• 强制要求包含真实案例与可操作实践：

- 至少 2–3 个真实企业案例，注明公司名称、具体指标与成果

- 提供分步实施指南，确保读者可照做

- 输出可直接使用的检查清单或方法论框架

- 使用带数字、时间范围和结果的具体示例

• 关键要求：数据真实性保障：

- ❌ 严禁虚构或捏造具体数据、百分比、统计结果

- ❌ 不得杜撰公司名称、日期或案例细节

- ✅ 仅使用来自 YouTube 研究（视频字幕、描述、公开报道）的可验证信息

- ✅ 当精确数据不可得时，采用专业限定表达：

- “预计可达...”

- “通常情况下可提升...”

- “根据行业经验，一般...”

- “类似案例显示约...”

- “预期节省...”

- ✅ 使用具体数字时必须标注来源：“根据 Gartner 报告”、“McKinsey 研究显示”

- ✅ 使用区间而非精确虚假数值：“提升 30–50%”而非“提升 47.3%”

- ✅ 无量化数据时聚焦定性描述：“显著提升效率”而非虚构“93%效率提升”

- 错误示例：“我见证了北京某公司效率提升 93%”（若该数据未经证实）

- 正确示例：“类似部署预计可提升 30–50% 的效率，具体取决于现有流程复杂度”

• 重要提醒：专业版本禁止使用表情符号

正式 Markdown/HTML 文章内容中不得出现任何 emoji，仅限小红书版本允许使用。

• 重要提醒：采用第一人称叙述

全文以“我”（I/me）视角展开：

- 体现个人观察与实践经验

- 使用句式如：“我发现...”、“我观察到...”、“让我分享...”、“我建议...”

- 增强互动感：“你可能会问...”、“这让我想起...”

- 保持专业但亲切的语气——不过于随意，也不刻板生硬

- 杜绝无效表达：避免“我认为”、“我觉得”、“我相信”等无实质信息的陈述，直接陈述观点

• 重要提醒：精炼写作原则：

- 每句话必须传递新信息，不重复已有内容

- 删除所有冗余修饰词与过渡句

- 若删去某句话不影响理解，则必须删除

- 用事实与数据说话，避免主观判断词汇

• 遵循 references/reference.html 中的专业风格：

- 使用结构化标题（h1, h2, h3, h4）

- 关键语句使用 blockquote 强调

- 保持清晰的段落划分与合理间距

阶段 2：自我迭代

• 审查初稿时关注以下方面：

- 语气一致性：专业、自信，避免傲慢；避免使用复杂术语

- 第一人称视角：确保全程使用“我”的视角，语气温暖且真实

- 结构流畅性：从问题 → 洞察 → 解决方案的逻辑推进清晰

- 开头吸引力：前3秒内必须抓住读者注意力

- 核心要点：每个部分都传递明确价值

- 行动号召：结尾自然且具有说服力

- 案例质量：所有案例需包含具体数据，具备可信度

- 可执行性：行动步骤清晰、可操作

- 精炼检查 ⚠️ 必须完成：

- 删除所有“我认为”、“我觉得”、“我相信”等冗余表达

- 检查是否存在重复表达相同意思的句子，合并或删除

- 确保每段都有新信息，不重复前文内容

- 删除所有不影响理解的冗余句子

- 去AI味检查 ⚠️ 必须完成（全文通过8项检查）：

- 是否存在“值得注意的是”、“总的来说”、“此外”等套话？→ 直接删除

- 每段是否均为整齐的“开头-展开-总结”三段式？→ 打破结构

- 连续数字列表超过2个？→ 改为叙述性表达

- 结尾是否为泛泛而谈的总结或展望？→ 更换为具体结论

- 是否缺乏“我”的视角？→ 补充真实个人经历

- 所有观点是否保持中立平衡？→ 大胆表明立场

- 数据完整性验证 ⚠️ 关键要求：

- 检查文中所有数字、百分比和指标

- 确保每项数据均可追溯至 YouTube 研究或引用来源

- 将虚构数据替换为限定性表述（如“预计…”、“通常…”、“约…”）

- 确保公司名称和案例细节可验证，或进行适当限定

- 删除过于精确的虚假统计数据（如“47.3%” → “约45-50%”或“显著提升”）

- 严禁杜撰案例：所有案例必须来自研究阶段的真实来源

• 进行2-3轮自我优化，聚焦清晰度与影响力
• 确保段落间过渡自然流畅

阶段 3：质量审查与评分（强制执行）

完成 Markdown 初稿后，进行结构化质量审查与评分：

评分标准（满分100分）：

评分流程：

1. 完成 Markdown 文章初稿
2. 逐项对照评分标准进行自审
3. 计算总分（0-100）
4. 输出评分报告，格式如下：

📊 文章质量评分报告
━━━━━━━━━━━━━━━━━━━━━
精炼度:      XX/20  [具体问题说明]
数据真实性:  XX/20  [具体问题说明]
结构清晰度:  XX/15  [具体问题说明]
标题吸引力:  XX/15  [具体问题说明]
可执行性:    XX/15  [具体问题说明]
去AI味:      XX/15  [具体问题说明]
━━━━━━━━━━━━━━━━━━━━━
总分: XX/100

⚠️ 去AI味8项检查清单（质量审查强制执行）：

□ 有没有「值得注意的是」「总的来说」「此外」等套话？→ 删
□ 每段是否都整齐「开头-展开-总结」三段式？→ 打破结构
□ 连续数字列表超过2个？→ 改成叙述
□ 结尾是泛泛总结或展望？→ 换掉
□ 缺少「我」的视角？→ 加真实故事
□ 所有观点都平衡中立？→ 大胆表态
□ 读出声，哪里走神了？→ 那里要改
□ 删掉最后一段，文章更好？→ 直接删

💡 快速检验法：直接删除最后一个总结段，若文章反而更有力，说明原结尾为AI味废话。

决策逻辑：

• 得分 < 85：自动修复扣分项，修改后重新评分，循环直至 ≥85
• 得分 ≥ 85：进入“飞书文档确认”流程

🚨 关键补充：当 Jeff 回复“选X”后的工作流程（2026-04-14 新增）

Jeff 确认选题后，必须按以下步骤执行：

第一步：撰写母版至飞书云文档

• 调用 feishu_doc 工具，创建新文档，标题格式：[待确认] {文章标题}
• 将完整母版文章内容（Phase 1-3 完成的全文）写入飞书文档
• 写入后使用 read 验证内容完整性

第二步：通知 Jeff 确认

• 发送消息给 Jeff，包含：飞书文档链接 + "请确认内容是否OK，回复确认后生成4种格式"

第三步：等待 Jeff 明确确认

• Jeff 回复“确认”、“OK”、“可以”等 → 进入 Step 3 生成4种格式
• Jeff 提出修改意见 → 根据意见修改后重新写入飞书，循环确认流程

⚠️ 绝对禁止：Jeff 确认选题后直接生成4种格式和发布！必须先完成飞书母版确认流程！

得分低于85时的自动修复优先级：

1. 删除所有“我认为/我觉得/我相信”
2. 合并或删除重复表达
3. 核实并修正可疑数据
4. 强化开头吸引力
5. 补充具体可执行建议

⏸️ 飞书文档确认流程（关键 - 2026-03-20 新增）

在生成4种格式前，必须先将内容写入飞书云文档并等待确认！

步骤 1：创建飞书云文档

• 使用 feishu_doc 工具创建新文档
• 文档标题格式：[待确认] {文章标题}
• 内容为 Markdown 格式
• 写入后使用 read 验证内容

步骤 2：通知用户确认

• 发送消息给用户，包含：

- 文档链接

- "请确认内容是否OK，回复确认后生成4种格式"

• 等待用户明确确认（用户回复“确认”、“OK”、“可以”等）

步骤 3：用户确认后

• 用户确认 → 进入 Phase 4 生成4种格式
• 用户提出修改意见 → 根据意见修改后重新写入飞书，循环确认流程

⚠️ 重要提示：禁止跳过此步骤直接生成4种格式！

阶段 4：最终润色

• 检查所有示例与数据点的准确性
• 验证中文语法与标点使用
• 确保移动端阅读时视觉层级清晰
• 使用 加粗 突出关键洞察
• 删除所有表情符号 —— 正式发表文章必须无表情符号
• 添加商业转化结尾 —— 将“参考来源”替换为促进互动与咨询的行动号召（见下文）
• 禁止在 HTML 中使用水平线 —— 不得在段落间使用 <hr/> 标签（Markdown 中的 --- 可接受）
• ⚠️ 验证小红书字符数 —— 在定稿 Format 3 前，统计字符数（不含标签），确保在 800–1000 字之间。若不足 800，补充细节；若超过 1000，应大幅删减，同时保留核心信息

阶段 5：生成关键数据信息图（仅限 HTML 版本）

关键提醒：若文章包含核心数据可视化内容，必须使用 NotebookLM 生成信息图

何时生成信息图：

• 文章包含 2 个及以上关键统计数据或对比
• 带具体数值的市场增长趋势
• 有前后对比且附带指标的数据
• 多维度数据，适合通过图形呈现

信息图生成流程：

1. 识别文章中的可视化机会：

- 市场规模/增长数据（如：“$315B → $1.1T”）

- 百分比趋势（如：“36.3% 的企业”）

- 前后对比（如：“传统模式：$25k/月 vs 个人独立：$500/月”）

- 多指标对比（如：“3个关键因素”）

1. 使用 notebooklm-api 技能生成信息图：

   # 针对每个关键数据点，生成一张信息图
   notebooklm generate infographic "Create a professional infographic showing [数据描述].
   Use blue color scheme (#1a5490, #2980b9, #3498db) to match article theme.
   Modern, clean design with clear data visualization. Include: [具体指标]"

1. 配色要求（必须匹配 HTML 主题）：

- 主蓝色：#1a5490

- 强调蓝：#2980b9

- 浅蓝色：#3498db

- 背景色：#ebf5fb（浅蓝）

- 文字色：#2c3e50（深灰）

- 使用蓝色渐变与专业商务风格设计

1. 等待生成并下载：

   # 等待信息图生成完成
   notebooklm artifact wait <artifact_id> --timeout 900

   # 下载到输出目录
   notebooklm download infographic "YYYY-MM-DD-[slug]-[data-name].png"

1. 关键操作：压缩图片以适配微信上传：

   # NotebookLM 生成的 PNG 文件体积较大（5-10MB），在微信上传时会超时
   # 上传前必须压缩为 JPEG 格式
   python scripts/compress_image.py "YYYY-MM-DD-[slug]-[data-name].png"

   # 生成文件：YYYY-MM-DD-[slug]-[data-name]-compressed.jpg（通常小于 1MB）
   # 压缩效果：PNG 5.93MB → JPEG 0.68MB（减少 88%，质量设置为 85）

1. 插入 HTML 输出内容：

- 使用压缩后的图片文件名（而非原始 PNG）

- 将基于 CSS 的可视化图表替换为实际的信息图图片

- 使用正确的 <figure> 结构，包含标题和来源说明

- 示例：

   <figure style="margin: 40px 0;">
     <img src="2026-01-18-article-slug-market-growth-compressed.jpg"
          alt="Market Growth Visualization"
          class="article-image">
     <figcaption class="image-caption">
       SaaS市场增长趋势 (2025-2032)
     </figcaption>
     <p class="image-source">
       数据来源：<a href="[source_url]" target="_blank">[Source Name]</a>
     </p>
   </figure>

1. 常见需生成的信息图类型（每篇文章生成 2-4 张）：

- 市场增长图表（若文章涉及市场趋势）

- 对比型信息图（传统方式 vs 新方法）

- 数据统计可视化（关键百分比/数值）

- 流程或工作流图（若解释步骤）

常见数据类型的示例提示词：

• 市场增长：

  "创建一张专业信息图，展示 SaaS 市场从 2025 年的 3150 亿美元增长至 2032 年的 1.13 万亿美元。
  使用上升柱状图或折线图。主色调为蓝色（#1a5490, #2980b9, #3498db）。
  突出显示年复合增长率超过 20%。采用现代商务风格设计。"

• 百分比趋势：

  "创建一张专业信息图，展示 2026 年有 36.3% 的新公司由个人独立创立，
  相较于 2025 年不足 10%。体现三倍以上的显著增长。使用与企业主题一致的蓝色调。
  推荐使用饼图或对比柱状图呈现。"

• 成本对比：

  "创建一张左右并列的对比信息图：传统模式（5 人团队，月成本 2.5 万元，
  需要超过 5 万元月收入才能盈亏平衡）vs 个人+AI 模式（月成本 500 元，5 千元月收入即可盈利）。
  蓝色调设计，视觉对比清晰明确。"

重要注意事项：

• 在完成全文撰写后再生成信息图
• 仅对 Format 2（HTML）格式生成信息图 —— 不适用于 MD、小红书或推文格式
• 信息图应增强而非替代文字内容
• 必须包含完整出处和来源链接
• 文件命名规范：YYYY-MM-DD-[article-slug]-[data-description].png

7) 输出格式要求：必须生成四类格式

⚠️ 仅在用户确认飞书文档后方可生成！

强制要求：始终生成全部四种格式

格式 1：Markdown (.md) - 完整专业版

• 保存路径：/root/.openclaw/workspace/output/YYYY-MM-DD-[article-title-slug].md
• 清理后的 Markdown，具备正确的标题层级结构
• 禁止包含元数据/frontmatter —— 直接以 # 文章标题 开始
• 不得添加 YAML 头部、版本信息或日期标题

格式 2：HTML (.html) - 完整专业版（公众号发布专用）

• 保存路径：/root/.openclaw/workspace/output/YYYY-MM-DD-[article-title-slug].html
• 🚨 关键提醒：微信排版规则：所有样式必须使用内联 style=""，禁止使用 <style> 块或 CSS class！微信会强制移除所有 class 和 style 块，导致样式失效。详见下方「微信公众号排版规范」章节。
• ⚠️ 信息图生成必需：若文章包含核心数据（如市场趋势、统计数据、对比分析），请在最终定稿前通过 Phase 4 工作流，使用 notebooklm-api skill 生成信息图。
• 颜色系统（必须使用内联 style）：

- 墨绿（主色）：#556b2f，用于文字、竖线、背景

- 砖红（强调色）：#b74134，用于重点字词背景

- 奶黄背景：#fff8e7，用于重点字词

- Hook 背景：#e8f5e0

• 内联样式示例：

- 二级标题：<div style="font-size:17px;color:#556b2f;font-weight:bold;margin:28px 15px 14px;padding-left:12px;border-left:3px solid #556b2f;">

- 正文段落：<div style="margin:0 0 12px;padding:0 15px;line-height:1.8;font-size:15px;color:#444;">

- 加粗强调：<span style="color:#556b2f;font-weight:bold;">

- 重点字词：<span style="background:#fff8e7;padding:2px 6px;border-radius:3px;color:#b74134;font-weight:600;text-decoration:underline dotted #b74134;">

- 重点句下划线：<span style="border-bottom:2px dotted #556b2f;padding-bottom:2px;color:#556b2f;">

- CTA 结尾：<p style="margin:0;padding:20px 15px;text-align:center;color:#333;line-height:1.8;font-size:15px;"><strong>如果你觉得文章对你有所帮助，请关注公众号。</strong></p>

• 包含完整的 HTML 结构（DOCTYPE、head、body）
• **重要：禁止使用 <hr/> 标签分隔段落** —— 应通过间距和标题实现视觉分隔
• 禁止包含元数据 —— HTML 输出中不得出现日期、版本信息或作者信息

🚨 微信公众号排版规范（关键必守）

**⚠️ 权威依据文件：references/wechat-format-rules.md（以该文件为准，不可冲突）**

🚨 2026-04-09 重大更新（经验教训）：

核心问题：微信安全过滤机制会强制覆盖 <h1>/<h2>/<h3>/<p>/<strong> 等 HTML 默认标签的样式（变为蓝色），所有 CSS class 和 <style> 块均会被剥离。

唯一安全方案：所有样式必须通过 <div> 和 <span> 标签的 style="" 内联属性实现，禁止使用任何可能被微信强制覆盖的标签。

排版规范核心要点（完整内容见 references/wechat-format-rules.md）：

文章标题（H1 - 供脚本提取）

<!-- 供 wechat_publish.py 提取标题，必须保留且 display:none -->
<h1 style="display:none;">从张雪峰.skill到金谷园饺子馆.skill，给我们带来的思考</h1>

二级标题（Section Title）

<!-- 禁止使用 <h2>，微信会强制覆盖为蓝色！必须使用 div 内联 -->
<div style="font-size:17px;color:#556b2f;font-weight:bold;margin:28px 15px 14px;padding-left:12px;border-left:4px solid #556b2f;">一、章节标题</div>

• 字体大小：17px，颜色：墨绿色 #556b2f，加粗
• 左侧墨绿竖线：4px solid #556b2f
• 左侧留白：padding-left:12px
• 上下间距：margin:28px 15px 14px

正文段落（Body Paragraph）

<!-- 禁止使用 <p>，微信会覆盖样式！必须使用 div 内联 -->
<div style="margin:0 0 12px;padding:0 15px;line-height:1.8;">正文内容</div>

• 段间距：margin:0 0 12px（下一段前留 12px）
• 左右留白：padding:0 15px
• 行高：line-height:1.8

重点字词（Highlighted Key Terms）

<!-- 砖红字体 + 奶黄背景，不是红色！ -->
<span style="background:#fff8e7;padding:2px 6px;border-radius:3px;color:#b74134;font-weight:600;">重点字词</span>

重点句（Important Sentences - 点下划线）

<!-- 墨绿色点状下划线，不是红色！ -->
<span style="border-bottom:2px dotted #556b2f;padding-bottom:2px;color:#556b2f;">重点句子</span>

数字强调（Key Numbers）

<span style="color:#556b2f;font-weight:bold;">12天</span>

Hook区域（开篇摘要框）

<div style="background:#e8f5e0;border-left:3px solid #556b2f;box-shadow:2px 2px 8px rgba(0,0,0,0.08);padding:18px 20px;border-radius:0 10px 10px 0;margin:0 0 24px 0;font-size:15px;line-height:1.9;">
    <span style="color:#556b2f;font-weight:bold;">2026年4月</span>，短短两天内...
</div>

CTA结尾（必须添加）

<p style="margin:0;padding:20px 15px;text-align:center;color:#333;line-height:1.8;font-size:15px;">
    <strong>如果你觉得文章对你有所帮助，请关注公众号。</strong>
</p>

完整HTML结构规则

颜色系统（Jeff品牌色）

发布命令（必须使用 -X utf8）

cd /root/.openclaw/workspace/skills/content-factory && python3 -X utf8 scripts/wechat_publish.py --html "/root/.openclaw/workspace/output/YYYY-MM-DD-article-slug.html" --cover "/root/.openclaw/workspace/output/YYYY-MM-DD-article-slug-cover.png"

• **必须加 -X utf8**：否则中文会变成 \uXXXX 转义序列
• **必须加 --cover**：否则封面图使用默认图片
• 禁止元信息：禁止日期、版本号、版权声明

• 内容结构优化建议：

- 减少项目符号列表，转为流畅的叙述性段落

- 增加第一人称叙述（如“我发现…”、“我观察到…”、“在我看来…”）

- 仅在工具清单或步骤说明中使用项目符号

- 将数据列表转化为带内联高亮的叙述性文字

• 微信列表格式要求（发布关键）：

- 移除所有 <li> 元素之间的空行，防止微信自动添加多余项目符号

- 列表格式需紧凑：<ul><li>项目1</li><li>项目2</li><li>项目3</li></ul>（元素间无换行）

- 对 <ul> 和 <ol> 均适用

- 微信解析器将空行视为新列表项，导致视觉混乱

- 此规则由 wechat_publish.py 脚本在上传时自动处理

• 视觉化数据呈现：

- 优先使用 NotebookLM 生成的图表作为关键数据可视化（参见第四阶段）

- 若图表生成失败，再使用基于 CSS 的可视化方案作为备选

- 使用 CSS 渐变和 flexbox 实现内联数据可视化

- 创建前后对比卡片展示变化效果

- 为关键数据点设计彩色信息卡

- 所有数据可视化均需标注来源链接

- 示例：使用渐变色块展示市场增长趋势

- 示例：采用左右并列卡片对比成本结构

- 示例：设计大数字+上下文的信息卡片

• 信息来源图片：

- 从原始资料中搜索图表/图形（如 Fortune Business Insights、Scalable.news 等）

- 若无法获取图片，使用 CSS 构建数据可视化

- 所有图片必须包含 <figure> 标签及 <figcaption> 说明，并附上来源链接

- 使用 <p class="image-source"> 包裹可点击的引用链接

格式3：Markdown (.md) - 小红书版（Xiaohongshu Style）

• 保存路径：/root/.openclaw/workspace/output/YYYY-MM-DD-[article-title-slug]-小红书.md
• 🚨 严格字符数控制（至关重要）：

- 目标范围：800–1000个字符（中文字符 + 英文单词）

- 必须使用 Python 脚本验证后才能发送给用户

- 验证命令：

    python3 -c "import re; c=re.sub(r'#+\s*|---+|^-\s+|#+\s*$|\n\n+','',open('file.md').read()); print(len(re.findall(r'[\u4e00-\u9fa5]',c))+len(re.findall(r'[a-zA-Z]+',c)))"

• 若字数 < 800：增加内容或扩展细节

- 若字数 > 1000：大幅精简，但保留核心信息

- **切勿依赖 wc -c** —— 它统计的是字节，而非可显示字符

• 风格：轻松、生动、带表情符号（与正式版本相反）
• 严格字符限制：800–1000 中文字符（不含标签）

- ⚠️ 关键提醒：定稿前务必检查字数 —— 必须 ≥800 且 ≤1000

- 使用 Python 验证：800 <= len(content_without_hashtags) <= 1000

- 若不足 800，补充案例细节或实用建议

- 若超过 1000，强力删减内容，但保留核心信息

- 优先级：案例 + 关键数据 + 可操作建议

• 必须包含至少一个完整案例，附具体数据指标
• 内容结构：

- 带表情符号的吸睛开头（2–3 句）

- 1–2 个核心洞察或问题

- 1 个完整真实案例，含具体数字/成果

- 3–5 条可执行建议（带表情符号的项目符号）

- 富有感染力的结尾 + 行动号召

- 末尾添加标签（5–10 个相关标签）

• 语气：口语化、兴奋感、有共鸣 —— 就像和朋友分享一个新发现
• 表情符号使用：战略性使用，增强重点与视觉吸引力（✨💡🚀📊💪 等）
• 标签格式示例：

  #ClaudeCowork #AI工具 #企业效率 #人工智能 #职场提升 #AI代理 #效率翻倍 #科技趋势

• 不包含商业转化内容 —— 保持简洁聚焦，适配小红书平台
• 字数验证（强制要求）：

  # 写完后立即验证字数
  content = """[你的小红书内容]"""
  lines = content.split('\n')
  hashtag_line = [l for l in lines if l.startswith('#')]
  if hashtag_line:
      content_without_hashtags = content.replace(hashtag_line[0], '').strip()
  else:
      content_without_hashtags = content.strip()

  char_count = len(content_without_hashtags)
  assert 800 <= char_count <= 1000, f"字符数 {char_count} 必须在 800–1000 之间！"

格式 4：文本 (.txt) - X/Twitter 英文长推文版 (X Pro)

• 保存路径：/root/.openclaw/workspace/output/YYYY-MM-DD-[article-title-slug]-tweet.txt
• 仅限英文 —— 专业、数据驱动的长推文风格
• 最大长度：1000 字符（优化可读性与互动性）
• 必须包含 2–3 个完整案例，附具体数据结果
• 内容结构：

- 强力钩子（2–3 句，阐明核心转变/洞察）

- 案例 1：问题 → 解决方案 → 成果（3–5 个带具体数字的要点）

- 案例 2：问题 → 解决方案 → 成果（3–5 个带具体数字的要点）

- 可选案例 3 或安全/挑战经验（若空间允许）

- 范式转变总结（3–5 个转变点，使用 → 表示）

- 行业预测或趋势（引用 Gartner 数据、市场预测）

- 简要可操作框架或下一步建议（可选，2–3 点）

- 有力行动号召（提问或陈述句）

- 末尾添加 5–8 个相关标签

• 语气：专业但吸引人，权威又易懂，符合 Twitter 风格的简洁
• 视觉结构：使用分隔线（━━━）、项目符号（•）、箭头（→）提升清晰度
• 表情符号使用：极简 —— 仅在能提升可读性时使用（最多 2–3 个）
• 数据密度：包含 6–9 个具体指标（百分比、时间减少量、投资回报率等）
• 标签格式：5–8 个标签，覆盖技术、行业与应用场景

  #AI #ClaudeCowork #EnterpriseAI #Automation #AIAgents #DigitalTransformation #Productivity #FutureOfWork

• 重点：提取 2–3 个最具说服力的案例，附具体成果，保持 Twitter 的可扫描性，同时提供深度内容

文件命名规范：

• 使用 ISO 日期格式：YYYY-MM-DD（如 2026-01-14）
• 后接文章标题小写短链接，用连字符连接
• 小红书版本在扩展名前加 -小红书
• 推文版本在扩展名前加 -tweet
• 示例：

- 2026-01-14-claude-cowork-enterprise-guide.md（专业 Markdown）

- 2026-01-14-claude-cowork-enterprise-guide.html（专业 HTML）

- 2026-01-14-claude-cowork-enterprise-guide-小红书.md（小红书 Markdown）

- 2026-01-14-claude-cowork-enterprise-guide-tweet.txt（Twitter/X 英文）

输出目录结构：

├── 2026-01-14-[article-title-slug].md
├── 2026-01-14-[article-title-slug].html
├── 2026-01-14-[article-title-slug]-小红书.md
└── 2026-01-14-[article-title-slug]-tweet.txt

如目录不存在，请自动创建。

8) 微信公众号封面图（固定图片）

⚠️ 微信公众号封面使用固定图片，不调用生图 API。

固定封面图片路径：

/root/.openclaw/workspace/skills/content-factory/assets/wechat-cover-default.png

规格： 900×386 像素（21:9），PNG 格式

使用方式：

1. 直接复制固定封面图片至输出目录，或上传至微信公众号获取 media_id
2. 如需压缩：

   python scripts/compress_image.py "/root/.openclaw/workspace/skills/content-factory/assets/wechat-cover-default.png"

如需更换封面： 替换 assets/wechat-cover-default.png 文件即可全局生效。

封面图提示词工程指南：

核心原则：

• 标题优先：图形应辅助标题，而非喧宾夺主
• 极简风格：少即是多 —— 避免杂乱设计
• 专业质感：杂志级审美
• 白色背景：纯白色 (#ffffff) —— 所有封面必须使用
• 深蓝色为主色：藏青色 (#1a3a52 或 #1a5490)，用于文字与主要图形
• 点缀色：浅蓝 (#3498db)、灰 (#7f8c8d)，仅用于细微元素
• 21:9 超宽比例：按 21:9 比例设计（900×386 像素）

不同文章类型示例提示词：

配色方案（统一文章主题风格）

• 背景：纯白色 (#ffffff) - 所有封面必须使用
• 主色调：深蓝色 / 藏青色 #1a3a52 或 #1a5490 - 用于标题和主要图形
• 强调色 1：浅蓝色 #3498db 或 #2980b9 - 仅用于高光与视觉亮点
• 强调色 2：灰色 #7f8c8d - 仅用于细微辅助元素
• 文字：标题使用深蓝色，副标题使用深灰色 #2c3e50

质量检查清单

• [ ] 背景为纯白色 (#ffffff)
• [ ] 标题与图形使用深蓝色（藏青色）
• [ ] 标题在移动端清晰可读
• [ ] 背景图形不喧宾夺主
• [ ] 配色方案符合文章主题（以深蓝为主）
• [ ] 图片尺寸为 900x386 像素（21:9 比例）
• [ ] 文件大小 < 1MB（必要时压缩）
• [ ] 整体呈现专业杂志质感
• [ ] 适合商业及专业读者群体

与发布工作流集成

• 在文章内容最终定稿后生成封面图
• 若文件大小超过 1MB，使用 scripts/compress_image.py 进行压缩
• 将封面图路径包含在微信发布 API 请求中
• 确保封面图符合微信平台规范（尺寸、格式、内容）

错误处理机制

• 若 GLM 生成失败，尝试使用简化后的提示词重试
• 若生成耗时过长，检查 API 使用配额
• 若文件大小 > 1MB，压缩为 JPEG 格式，质量设为 85
• 若封面生成被跳过，通知用户

9）微信公众号自动发布功能

重要提示：在生成 Format 2（HTML）和封面图后，自动将内容发布至微信公众号进行预览。

微信公众号凭证配置

• 凭证信息存储于 .env 文件中（详见下方配置章节）
• AppID：在 .env 中设置 WECHAT_APP_ID
• AppSecret：在 .env 中设置 WECHAT_APP_SECRET
• 获取方式：登录 https://mp.weixin.qq.com → 设置与开发 → 基本配置

发布流程

1. 生成全部 4 种格式内容（MD、HTML、小红书、推文）
2. 使用 Seedream 5.0 API 生成微信封面图（参见第 8 节）
3. 若封面图或信息图文件大于 1MB，进行压缩
4. 从 HTML 文件中提取正文内容用于微信 API
5. 使用 UTF-8 模式调用发布脚本（Windows 平台关键）
6. 验证编码与图片在微信草稿预览中的显示情况
7. 返回预览链接给用户

发布脚本使用说明（Windows 平台必须启用 UTF-8 模式）

# 在 Windows 上必须添加 -X utf8 参数，防止中文乱码
python -X utf8 scripts/wechat_publish.py --html "/root/.openclaw/workspace/output/YYYY-MM-DD-[article-title-slug].html"

# 不加 -X utf8 会导致中文字符显示为 \uXXXX 转义序列
# 此问题源于 Windows 默认 GBK 编码，需通过 UTF-8 模式解决

预期输出结果

✓ 访问令牌获取成功
✓ 内容图片上传成功：[filename] -> http://mmbiz.qpic.cn/...
✓ 草稿文章创建完成
✓ 媒体 ID: WOr7ZIAYNpv...

验证检查清单

• [ ] 日志中确认出现 "Content image uploaded"（表明图片上传成功）
• [ ] 中文字符显示正常（未出现 \uXXXX 序列）
• [ ] 打开微信草稿预览，确认图片正确加载
• [ ] 记录媒体 ID 以备后续引用

使用的 API 接口

• 获取访问令牌：https://api.weixin.qq.com/cgi-bin/token
• 创建草稿：https://api.weixin.qq.com/cgi-bin/draft/add
• 提交预览：https://api.weixin.qq.com/cgi-bin/freepublish/submit

错误处理：

• 若 API 调用失败，应将 HTML 本地保存并通知用户
• 错误详情记录至 publish_errors.log
• 提供手动发布操作说明

安全提示：

• AppSecret 为敏感信息，生产环境建议移至环境变量
• 访问令牌 2 小时后过期，脚本会自动处理刷新
• 预览链接有效期为 24 小时

文章结尾 - 商业转化（格式 1 和 2 必须包含）：

在格式 1（Markdown）和格式 2（HTML）的专业文章中，不得列出“参考来源”或“References”，而必须以商业转化部分结尾，引导读者关注并联系 AI 咨询服务。

注意：格式 3（小红书）不包含此部分，该格式应仅以标签结尾。

Markdown 格式（适用于格式 1）：

---

如果觉得这篇文章对您有帮助，欢迎关注公众号。

**HTML 格式（适用于格式 2，在 </body> 前添加）：**

<p>如果觉得这篇文章对您有帮助，欢迎关注公众号。</p>

重要说明：

• 所有文章中均不得包含“参考来源”或“References”部分
• 商业转化部分对每篇文章均为强制要求
• 根据用户需求自定义联系方式占位符
• 保持语气与第一人称叙述一致：专业、实用且亲切
• 此部分作为商业转化漏斗，将读者转化为咨询客户
• **请勿在商业转化部分前使用 <hr/>** —— h2 标题已提供足够的视觉分隔

内容质量标准与安全规范

• 避免对视频内容做出无法验证的声明；仅总结字幕或描述中可获取的信息
• 保持摘要简洁，并明确标注信息来源
• 避免直接复制长段落的字幕内容
• 文章撰写标准：

- 保持专业自信的语气，避免傲慢

- 使用具体案例和数据支撑观点

- 确保逻辑清晰，价值主张明确

- 优先考虑移动端阅读体验（短段落、清晰层级）

- 引用任何内容时均需正确标注来源

• 写作质量规则（强制执行）：

- 精炼表达：避免重复相同含义的表述，每句话必须传递新信息

- 禁止废话：不得使用“我认为”、“我觉得”、“我相信”等无意义表达，直接陈述观点

- 禁止杜撰：所有案例与数据必须来自研究阶段的真实来源，不得虚构

- 直接有力：使用“是”而非“我认为是”，使用“数据显示”而非“我觉得数据可能显示”

- 删除冗余：若删除某句话不影响理解，则应将其删除

常见错误与经验教训

❌ 错误 1：跳过工具依赖检查

发生情况：

• 未检查 yt-dlp 是否可用，便假设其不可用
• 直接进入 WebFetch/WebSearch 的备用方法
• 错失从 YouTube 提取丰富内容的机会

错误原因：

• 工具检查为强制步骤，非可选操作
• “可选运行脚本”意为“条件满足时应使用”，而非“不便时可跳过”
• 本地脚本为主力方法，WebFetch 为备用方案

正确做法：

# 始终先进行检查
yt-dlp --version
ls scripts/yt_dlp_search.py
ls scripts/yt_dlp_captions.py

# 根据结果决定执行路径

❌ 错误 2：误解文档中的“可选”含义

发生情况：

• 观察到“可选运行脚本”，理解为“可以跳过”
• 未意识到本地脚本是主要的 YouTube 内容提取方式

错误原因：

• “可选”表示“在条件允许时应使用”
• 关注点在于工具是否可用，而非执行优先级
• WebFetch 是备选方案，而非首选方法

正确理解：

• 若 yt-dlp 已安装 → 必须使用脚本（主方法）
• 若 yt-dlp 缺失 → 通知用户并请求安装
• 仅当用户拒绝 → 才启用备用方法

❌ 错误 3：未阅读参考文档

发生情况：

• 未加载 references/youtube_research_checklist.md
• 错过关于 YouTube 内容提取的详细说明

错误原因：

• 参考文档包含关键工作流程细节
• 提供复杂任务的逐步指导
• 跳过会导致执行不完整

正确做法：

# 每当提及参考文档时，务必加载
Read("references/youtube_research_checklist.md")

❌ 错误 4：过早切换至替代来源

发生情况：

• WebFetch 失败后 → 立即转为 WebSearch 获取文章
• 未尝试所有 YouTube 提取方法

错误原因：

• YouTube 内容具有独特价值（案例研究、个人故事、演示视频）
• 文章或报告无法完全替代视频内容的丰富性
• 应穷尽所有方法后再放弃主源

正确决策流程：

需要 YouTube 内容？
    ↓
检查 yt-dlp 是否安装？
    ↓ 是                           ↓ 否
尝试脚本                    → 通知用户并安装
    ↓ 成功    ↓ 失败              ↓
继续      → 尝试 WebFetch    → 重试脚本
                    ↓ 失败              ↓ 失败
              请求用户提供 URL   → 使用备用来源
                    ↓ 失败         （记录限制）
              使用备用来源
              （记录限制）

❌ 错误 5：微信发布编码错误（Windows 系统）

发生情况：

• 发布文章至微信后，中文字符显示为 Unicode 转义序列
• 例如：\u6211\u752872\u5c0f\u65f6 而非 “我用72小时”
• 草稿创建成功，但内容无法阅读

错误原因：

• Windows 默认编码为 GBK，非 UTF-8
• BeautifulSoup 解析 HTML 时继承系统编码
• 单独使用 ensure_ascii=False 进行 JSON 序列化不足以解决问题
• 问题影响整个 Python 进程，不仅限于文件 I/O

根本原因：

• Windows 控制台默认使用 GBK 编码
• Python 默认编码遵循系统区域设置
• HTML 解析与字符串操作使用默认编码
• WeChat API 接收到的是编码错误的内容

正确做法：

# 在 Windows 上发布微信内容时，始终使用 Python UTF-8 模式
python -X utf8 scripts/wechat_publish.py --html "/root/.openclaw/workspace/output/article.html"

# 仅设置 PYTHONIOENCODING（不充分）：
# PYTHONIOENCODING=utf-8 python scripts/wechat_publish.py  # ❌ 仅修复 I/O 编码问题

# -X utf8 标志强制启用 UTF-8 编码，适用于：
# - 文件读写操作
# - 字符串编码/解码
# - HTML 解析（BeautifulSoup）
# - JSON 序列化
# - HTTP 请求体

验证方法：

• 发布后立即检查微信草稿预览
• 确认中文字符显示正常
• 若出现 \uXXXX 序列，说明编码失败
• 使用 -X utf8 标志重新运行

预防检查清单：

• [ ] 在 Windows 上发布微信内容时，始终使用 python -X utf8
• [ ] 先用短篇文章测试编码是否正常
• [ ] 发布前检查草稿预览
• [ ] 记录媒体 ID 以备参考

❌ 错误 6：NotebookLM 生成的插图过大，无法上传至微信

发生了什么：

• 使用 NotebookLM API 生成了 6.0MB 的 PNG 插图
• 微信图片上传超时：TimeoutError('The write operation timed out')
• 文章虽成功发布，但缺少插图
• 用户反馈：“图片没有加载进去”（images not loaded）

为何错误：

• NotebookLM 生成的图片分辨率高（通常为 5–10MB）
• 微信 API 有 10MB 的大小限制，但大文件常因超时失败
• 网络上传超时发生在达到大小限制之前
• PNG 格式无压缩，不适合网页传输

根本原因：

• NotebookLM 优先考虑画质而非文件大小
• PNG 格式保留所有像素数据，无压缩
• 微信上传接口有严格的超时限制（60 秒）
• 大文件会静默失败——草稿创建成功，但图片缺失

正确做法：

# 步骤 1：正常生成插图（使用 NotebookLM）
notebooklm generate infographic "prompt..." --json
notebooklm artifact wait <artifact_id> --timeout 600
notebooklm download infographic ./output.png

# 步骤 2：上传前必须压缩
python -c "
from PIL import Image
import os

# 将 PNG 转换为 JPEG 并优化质量
img = Image.open('output.png').convert('RGB')
img.save('output-compressed.jpg', 'JPEG', quality=85, optimize=True)

# 验证文件大小缩减
original_mb = os.path.getsize('output.png') / 1024 / 1024
compressed_mb = os.path.getsize('output-compressed.jpg') / 1024 / 1024
print(f'原始文件: {original_mb:.2f}MB → 压缩后: {compressed_mb:.2f}MB')
"

# 步骤 3：更新 HTML 中的图片引用
# 将：`<img src="output.png" ...>`
# 替换为：`<img src="output-compressed.jpg" ...>`

# 步骤 4：使用压缩后的图片发布
python -X utf8 scripts/wechat_publish.py --html "/root/.openclaw/workspace/output/article.html"

压缩效果：

• 原始 PNG：5.93MB → 压缩后 JPEG：0.68MB（减少 88%）
• 上传时间：超时 → 21 秒（成功）
• 视觉质量：在 85% JPEG 质量下几乎无明显损失

预防检查清单：

• [ ] 上传微信前，始终压缩 NotebookLM 生成的插图
• [ ] 目标文件大小：< 1MB 以确保可靠上传
• [ ] 使用 JPEG 格式，质量设为 85，兼顾清晰度与体积
• [ ] 检查日志确认上传成功：Content image uploaded: ... -> http://mmbiz.qpic.cn/...
• [ ] 检查微信草稿预览，确认图片正常显示
• [ ] 若上传失败，可降低 JPEG 质量至 75 或缩小图片尺寸

图像压缩脚本（可复用）：

# 保存为 scripts/compress_image.py
from PIL import Image
import sys
import os

def compress_for_wechat(input_path, output_path=None, quality=85):
    """将图片压缩为适合微信上传的格式（目标 < 1MB）"""
    if output_path is None:
        base, ext = os.path.splitext(input_path)
        output_path = f"{base}-compressed.jpg"

    img = Image.open(input_path)
    if img.mode in ('RGBA', 'LA', 'P'):
        img = img.convert('RGB')

    img.save(output_path, 'JPEG', quality=quality, optimize=True)

    original_mb = os.path.getsize(input_path) / 1024 / 1024
    compressed_mb = os.path.getsize(output_path) / 1024 / 1024

    print(f"原始文件: {original_mb:.2f}MB")
    print(f"压缩后: {compressed_mb:.2f}MB ({100*(1-compressed_mb/original_mb):.1f}% 减少)")
    print(f"输出文件: {output_path}")

    return output_path

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("用法: python compress_image.py <输入图片> [输出图片] [质量]")
        sys.exit(1)

    input_path = sys.argv[1]
    output_path = sys.argv[2] if len(sys.argv) > 2 else None
    quality = int(sys.argv[3]) if len(sys.argv) > 3 else 85

    compress_for_wechat(input_path, output_path, quality)

使用示例：

# 使用默认设置（质量=85）压缩
python scripts/compress_image.py infographic.png

# 使用自定义质量压缩
python scripts/compress_image.py infographic.png output.jpg 75

# 指定输出路径压缩
python scripts/compress_image.py infographic.png compressed.jpg

✅ 最佳实践

1. 始终先检查工具状态

- 开始研究前运行依赖项检查

- 向用户告知工具可用性

- 不假设工具不可用

1. 严格遵循优先级顺序

- 主要方法 → 备用方法 → 最后手段

- 不跳过决策树中的步骤

- 记录每种方法失败的原因

1. 对用户保持透明

- 告知用户当前可用的工具

- 说明正在使用的处理方式

- 若因工具限制导致内容质量下降，需明确告知

1. 仔细阅读所有参考文档

- 提及检查清单文件时应加载

- 严格遵循参考文档中的详细流程

- 有明确指引时不要自行发挥

1. 系统化排查问题

- 若 A 方法失败，先查明原因再尝试 B

- 不应跳过 B 和 C 直接尝试 D

- 记录失败原因，用于后续优化

1. 微信发布（Windows 环境，关键）

- 微信发布时始终使用 python -X utf8 标志

- 立即检查草稿预览中的编码情况

- 检查是否存在 \uXXXX 序列，这表示编码失败

- 若中文字符无法显示，请重新以 UTF-8 模式运行

1. NotebookLM 图文内容工作流

- 正常使用 NotebookLM 生成图文内容

- 在上传微信前，务必先将 PNG 图片压缩为 JPEG

- 目标文件大小：小于 1MB，以确保上传稳定

- 使用 scripts/compress_image.py 脚本进行一致压缩

- 更新 HTML 文件，引用压缩后的图片文件名

- 在宣布完成前，确认日志中图片上传成功

1. 微信图片压缩规范

- 将 PNG 转换为 JPEG，质量设置为 85

- 检查压缩后文件大小（应小于 1MB）

- 若仍过大，可降低质量至 75 或调整图像尺寸

- 在微信草稿预览中验证图片是否正确显示

- 保留原始 PNG 文件用于归档

配置

环境设置

所有 API 密钥和凭证均存储在 .env 文件中，以保障安全并便于管理。

配置步骤：

1. 复制示例文件：

   cd ~/.claude/skills\content-factory
   copy .env.example .env

1. 编辑 .env 文件并添加您的凭证：

   # 微信公众号（自动发布必需）
   WECHAT_APP_ID=your-wechat-app-id
   WECHAT_APP_SECRET=your-wechat-app-secret

1. 获取凭证：

- 微信凭证：前往 https://mp.weixin.qq.com/ → 设置与开发 → 基本配置

- NotebookLM：通过 notebooklm login 进行认证（用于封面图生成）

1. 验证配置：

   python scripts/check_env.py

重要提示：

• 切勿将 .env 文件提交至 Git（已在 .gitignore 中忽略）
• 保留 .env.example 作为模板（可安全提交）

- 详见 API_KEY_SETUP.md 获取详细配置说明

- 详见 CONFIGURATION.md 了解配置管理详情

资源

研究工具：

• scripts/yt_dlp_captions.py - 下载 YouTube 字幕/字幕文本
• scripts/yt_dlp_search.py - 搜索并收集 YouTube 元数据
• scripts/compress_image.py - 为微信上传压缩图片
• scripts/wechat_publish.py - 自动发布至微信公众号
• notebooklm-api skill - 生成图文内容及封面图
• WebSearch 工具 - 跨全网资源搜索
• WebFetch 工具 - 从 URL 提取并抓取内容

参考指南：

• references/youtube_research_checklist.md - YouTube 专项研究流程
• references/web_research_guide.md - 多源网络研究最佳实践
• references/wechat_viral_frameworks.md - 文章结构与吸引点框架
• references/wechat_publishing_guide.md - 微信发布操作文档
• references/reference.html - 输出用的 HTML 模板与样式参考

模板文件：

• assets/wechat_outline_template.md - 内容大纲模板（可选）

输出目录：

• /root/.openclaw/workspace/output/ - 生成的 MD、HTML、小红书、推文文件及封面图的目标存放路径

如果觉得这篇文章对您有帮助，欢迎关注公众号。