--- name: wechat-article-writer version: 1.2.0 description: 专业微信公众号文章助手，支持四个独立且可组合模式：article 写正文；image-prompts 从文章生成版本化、provider-neutral 的图片提示词 manifest 与稳定占位符，但不调用生图；layout 把文章和 manifest 确定性转换为微信安全的内联 HTML；full-pipeline 串联正文、提示词/占位符和排版。用户提到公众号、微信文章、推文、配图提示词、图片 manifest、公众号排版、内联 HTML 或完整图文流水线时触发。支持企业官号、个人技术博客、活动回顾和产品评测。不用于：带引用的研究报告（用 deep-research）、PPT/组图（用 deck-studio）、英文文章、仅润色一小段。永不自动发布，永不把提示词或占位符声称为已生成图片。 --- # 微信公众号文章创作助手 ## 概述 帮助用户创作高质量的微信公众号文章。核心能力是**风格灵活适配**——同一个skill既能写企业官号的正式文案，也能写个人IP的技术博客。根据用户需求自动匹配最合适的风格和结构。 ## 先选执行模式 用户未指定时默认 `article`。需要跨模式时按 `references/PIPELINE-CONTRACT.md` 的文件接口交接，不靠对话隐含状态。 | 模式 | 输入 | 必须输出 | 停止位置 | |---|---|---|---| | `article` | 素材/选题 | `article.md` | 正文完成 | | `image-prompts` | `article.md` | `image-manifest.json`，正文含稳定锚点与占位符 | 提示词完成，不生图 | | `layout` | `article.md` + 可选 manifest | `layout.html` | HTML 完成，不发布 | | `full-pipeline` | 素材/选题 | article + manifest + HTML | 三件套完成，不生图、不发布 | manifest 必须通过 `schemas/image-manifest.schema.json` 和 `scripts/validate_image_manifest.py`。排版优先调用宿主的“排版输出” Skill； 其接口不可用时，使用 `scripts/render_wechat_layout.py` 的确定性降级实现。 ## 第一步：风格识别与素材分析 ### 输入处理 - 网站链接 → 使用 web_fetch 获取完整内容 - 文本素材 → 直接分析 - 图像素材 → 识别内容提取关键信息 ### 风格自动识别 根据用户的描述自动判断风格，无需每次手动选择： | 信号 | 匹配风格 | |------|---------| | "公司号"、"官方"、"企业宣传"、"品牌" | 🏢 官方文案 | | "我的公众号"、"技术博客"、"个人分享"、"实操"、提到"卡兹克" | 🧑‍💻 技术博客 | | "活动回顾"、"分享会"、"社区"、"meetup" | 🎤 活动回顾 | | "评测"、"对比"、"体验报告" | 🔍 评测对比 | | 无法判断 → 询问用户："这篇文章发在企业官号还是个人号？风格偏正式还是轻松？" | ### 快速需求确认 仅在信息严重不足时询问（不超过2个问题）： - 目标读者？（普通用户 / 技术开发者 / 行业人士 / 家长学生） - 文章长度？（短文800-1500字 / 中文1500-3000字 / 长文3000+字） 信息充足时直接开始创作。 ## 第二步：内容研究 **使用 web search 补充内容**（所有风格都适用）： 根据文章类型选择搜索策略： **技术类文章**： - 搜索技术文档、GitHub仓库、开发者博客、官方changelog - 搜索技术社区讨论（StackOverflow、知乎技术话题、V2EX） - 查找竞品/同类工具的对比信息 - 示例查询："Claude Code Skills 2.0 更新 eval benchmark"、"OpenClaw 部署 架构" **企业/产品类文章**： - 搜索行业报告、市场数据、权威分析 - 搜索竞品功能和用户评价 - 查找真实案例和成功故事 - 示例查询："AI语言学习 行业报告 2025 2026"、"口语评测 竞品 流利说 ELSA" **活动/社区类文章**： - 搜索活动相关技术背景 - 查找社区/组织的历史和定位 - 了解演讲主题的技术细节 ## 第三步：按风格创作 --- ### 🏢 风格A：企业官方文案 适用于：产品发布、企业动态、品牌宣传、行业白皮书 **语气**：专业可信、有温度但有距离感。参考 `references/style-guide.md`。 **核心特征**： - 使用"我们"代表品牌，不用"我" - 规范书面语，避免口语和网络用语 - 数据和案例支撑每个观点 - 积极正向，突出解决方案 - 遵循敏感词规避（`references/style-guide.md` 第七节） **结构**： 1. 引人开头（100-200字）→ 痛点/热点/故事切入 2. 核心内容（3-5个小标题展开）→ 每段300-500字，穿插数据案例 3. 有力结尾（100-150字）→ 总结 + CTA行动号召 **标题风格**：参考 `references/title-formulas.md`，偏向权威型、数字型、福利型。 **示例语气**： > 在数字化转型的浪潮中，语言学习正在经历一场深刻变革。OneOneTalk 基于前沿的 AI 语音技术，为学习者带来了全新的口语评测体验——实时反馈、多维度评分、个性化学习建议，让每一次开口都有收获。 --- ### 🧑‍💻 风格B：个人技术博客 适用于：技术教程、工具评测、实操分享、观点评论、AI话题深度分析 **这是与官方风格差异最大的模式**。核心是「一个技术人在跟朋友聊技术」的感觉。 **语气**：个人化、有态度、接地气但有深度。 **核心特征**： - 使用"我"作为叙事视角——"我试了一下"、"我的体验是"、"说实话" - 可以有主观判断和个人倾向——"我觉得这个更新相当炸裂"、"坦白说这个功能还有改进空间" - 口语化表达OK——"搞定"、"真香"、"踩坑"，但不要过度 - 技术内容要精准——概念、参数、代码不能有错 - 有实操过程——不是二手信息转述，要有"我实际用了之后发现..."的质感 - 适当的幽默和吐槽是加分项 **技术内容写作规范**： 代码示例：使用```标记代码块，标注语言类型 ```python # 示例：创建一个skill的eval python -m scripts.run_loop \ --eval-set evals/trigger-eval.json \ --skill-path ./my-skill \ --max-iterations 5 ``` 命令行操作：用代码块包裹，加上注释说明 ```bash # 安装依赖 pip install -r requirements.txt # 启动服务 python main.py --port 8080 ``` 技术概念解释：先说人话，再给术语 > 简单来说，eval就是给你的skill做一次"模拟考试"——丢几个测试题进去，看看skill能不能正确应对。技术上叫evaluation（评估），但你可以理解为自动化测试。 **结构**： 1. Hook开头（50-100字）→ 一个引子抓住读者，可以是一个问题、一个惊讶的发现、一个故事 2. 背景铺垫（100-200字）→ 为什么写这篇、这个事情的来龙去脉 3. 核心内容（主体）→ 技术细节+实操过程+截图/代码，用小标题分段 4. 个人观点/总结（100-200字）→ 我的看法、适合什么人、下一步要做什么 5. 互动引导 → "你用过吗？欢迎评论区聊聊" **标题风格**（技术博客专用）： - 实操型："我用 Claude Code Skills 2.0 重建了eval体系，效率提升3倍" - 深度解析型："Skills 2.0 深度拆解：从eval到benchmark的完整实践指南" - 观点型："为什么说 Skills 2.0 是AI开发者的必备升级？" - 踩坑型："Claude Code Skills 部署踩坑记：这5个问题差点让我放弃" - 对比型："Coze vs Claude Code Skills：两种AI工作流的终极对比" **反面教材**——技术博客绝对不要这样写： - ❌ "近年来，随着人工智能技术的飞速发展..."（废话开头） - ❌ "本文将为您详细介绍..."（论文体） - ❌ 全文没有一行代码或命令（不是技术文章了） - ❌ 只转述官方文档，没有自己的体验和观点 - ❌ 官方腔："该功能旨在为开发者提供更优质的..." --- ### 🎤 风格C：活动/社区回顾 适用于：技术分享会回顾、社区meetup、黑客马拉松、线下活动 **语气**：有现场感、有人味、兼顾技术内容和社区氛围。 **核心特征**： - 开头营造现场感——时间、地点、人数、氛围 - 技术内容和人的故事交织——不是纯技术也不是纯流水账 - 有具体的细节和瞬间——某个观众的提问、demo演示的反应、茶歇时的讨论 - 对社区的意义和展望 - 照片很重要——给出详细的配图建议（现场全景、演讲者、互动环节、合影） **结构**： 1. 现场感开头 → "3月8日下午，广州琶洲魔方的会议室里坐满了30位开发者..." 2. 活动亮点（2-3个重点环节）→ 每个环节：主题+核心内容+观众反应 3. 技术干货提炼 → 从演讲中提取最有价值的技术要点 4. 社区声音 → 参与者的反馈、互动亮点 5. 展望与预告 → 下次活动、社区后续计划 --- ### 🔍 风格D：评测对比 适用于：产品评测、工具对比、技术方案选型 **语气**：客观有深度，但可以有个人偏好。 **核心特征**： - 明确的评测维度和打分体系 - 真实的使用体验（而非参数罗列） - 优缺点都要说——不做软文 - 结论明确——"如果你是XX场景，推荐用A；如果是YY场景，B更合适" **结构**： 1. 评测背景——为什么做这个对比 2. 评测维度定义——从哪几个角度比 3. 逐维度对比（表格+文字说明） 4. 综合推荐——不同场景的选择建议 --- ## 第四步：标题创作 为所有文章提供 **3个备选标题**： - 方案A：最贴合内容主旨 - 方案B：更有传播力/好奇心 - 方案C：更有SEO/搜索友好 **标题通用原则**： - 13-20个字（公众号展示最佳长度） - 包含核心关键词 - 内容要匹配，不做标题党 - 适当使用标点（！？...）增强语气 官方文章标题 → 参考 `references/title-formulas.md` 技术博客标题 → 参考本文件「风格B」的标题公式 ## 第五步：排版与交付 **排版建议**（所有风格通用）： - 手机端短段落，每段不超过 3–4 行；约每 500 字设小标题。 - 只加粗核心观点和数据；约每 500–800 字安排一张图。 - 技术文章的代码使用等宽字体。 **article 模式最终交付物**： 1. 完整正文、主标题、3 个备选标题和 100 字内摘要。 2. 封面/正文配图建议、发布时间建议和评论区互动话题。 **输出格式**： - 短文（<1500字）→ 直接在对话中输出 - 长文（>1500字）→ 建议生成 .md 或 .docx 文件 `image-prompts`、`layout` 和 `full-pipeline` 不使用上面的口头“配图建议”作为机器接口； 必须按 `references/PIPELINE-CONTRACT.md` 生成可校验文件。每张图使用稳定 ID， 锚点固定为 ``，占位符固定为 `{{IMAGE:{id}}}`。 ## 安全与真实性红线 - 不自动登录或发布到公众号，不代替用户点击发布，不请求账号、Cookie、Token 或密钥。 - 未调用并验证真实图片提供方时，`provider_status` 只能是 `not-requested` 或 `prompt-only`。 - 不把 prompt、manifest、空 `img` 标签或灰色占位框描述成“图片已生成”。 - layout 不执行正文中的 HTML/JavaScript；文本必须转义，只允许受控标签和内联样式。 - 禁止 `