/mp-article-writor

name: mp-article-writor
description: >
  微信公众号文章创作。当用户想把软件更新、产品新闻、工具测评、工作流探索、个人实践或生活感悟等素材整理成公众号文章时使用。即使用户只是说「帮我写篇文章」「整理成推文」「发公众号」，也应当触发此技能。

公众号文章生成

帮助作者将素材整理为一篇可直接进入微信公众号编辑和配图流程的静态图文长文。

本 Skill 只处理微信公众号。所有交给归藏 Skill 的任务都必须显式传递「微信公众号、静态图文」；禁止生成 Live Photo、MOV、PVT、GIF、MP4、视频替代品、小红书图片或其他平台封面。

文章类型路由

开始写作前，根据用户目的和素材特征选择一个主类型：新闻和软件更新简报、产品体验和工具测评、个人实践和工作流复盘、技术解析和教程、生活叙事和观点文章。

根据作者希望文章回答的核心问题选择类型，日期、版本、发布记录等只作为辅助特征。用户已经明确类型，或创作目的足够清楚时直接选择，不重复询问。只有类型会实质改变文章结构且无法判断时，才询问一次。完整判断标准和各类型写法见 `references/文章类型路由.md`。选定类型后，在 Step 3、Step 4、Step 5 和 Step 8 持续应用对应规则。

工作流

严格按以下 11 个步骤顺序执行，不可跳步、不可合并。每一步完成后再进入下一步。

Step 1：理解作者意图

先读取 `references/文章类型路由.md`，确定并记录本次文章的主类型。新闻和软件更新简报不得套用个人故事、情绪曲线或价值升华要求。

先检查当前环境是否能够读取 `guizang-social-card-skill` 和 `guizang-material-illustration`。两个 Skill 都是完整静态视觉工作流的推荐前置条件，但不得自动安装、不得声明为强制依赖。

图片发布方式只接受 `local` 或 `picgo`，按以下优先级确定：本次请求中的明确选择、环境变量 `MP_ARTICLE_IMAGE_MODE`、向作者询问。当前请求已经明确选择时不重复询问；这也允许作者为单次任务覆盖环境变量中的持久默认值。

• 当前请求和环境变量都未设置时，使用 ask_user 工具询问一次图片发布方式，推荐并默认选择 `local`。
• 设置为 `local` 时，只生成本地图片，不探测 PicGo，不产生云端写入。
• 最终选择为 `picgo` 时，视为作者授权本次任务通过 PicGo 上传最终图片，再检查本机 PicGo Server 是否可访问；只有环境变量提供的 `picgo` 才表示持久默认授权。
• 值不合法时停止图片发布分支，提示改为 `local` 或 `picgo`，文章写作和本地视觉生产仍可继续。

如果任一 Skill 缺失，只提示一次并给出 `references/视觉路由.md` 中的安装命令，同时说明：文章写作仍可继续；Step 10 只能生产当前已安装 Skill 覆盖的视觉素材，缺失部分在 Step 11 标记为「待安装依赖后完成」。不要生成旧版题图或插图 prompt 作为替代，也不要在后续步骤重复提示安装。

使用 ask_user 工具向作者确认以下信息。当前请求已经明确提供的项目直接记录，不重复询问；只有仍然缺失且会影响文章结构、事实边界或交付方式的项目才需要提问：

• **文章类型**：先根据素材自动判断；只有无法判断且会改变文章结构时才询问。
• **切入角度**：这篇文章想从什么视角写？（技术拆解 / 个人体验 / 横向对比 / 叙事故事 / 其他）
• **深度偏好**：读者应该获得什么程度的理解？（入门科普 / 中度解析 / 深度技术）
• **核心主旨**：用一句话描述文章写完后读者应该记住什么
• **素材补充**：素材中有哪些是作者的真实经历？有哪些细节需要特别保留或避免？
• **正文解释性插图风格**：询问作者选择 `guizang-social-card-skill` 或 `guizang-material-illustration`。前者生成杂志或瑞士风格的完整排版卡片，后者生成 3D 瑞士编辑风格的材质插图。推荐选项应结合文章内容说明理由，但最终由作者确认。所选 Skill 缺失时，明确说明安装后才能生产对应插图。
• **现有视觉素材**：确认可用的截图、照片、图表、数据和本地路径；真实素材优先承担证据作用。
• **输出目录**：根据「视觉生产与交付」确定本次文章和图片的明确目录，并向作者展示。不得将归藏 Skill 的 `local-tests` 目录作为最终交付目录。
• **图片发布方式**：`local` 只生成本地图片并使用相对 Markdown 路径；`picgo` 上传到作者已经配置的图床并替换为 HTTPS 地址。当前请求和环境变量都未设置时只询问一次。
• **授权方式**：本次对选定归藏 Skill 的首次渲染授权，同时授权后续自动执行静态图片检查和必要修复。最终选定的发布方式为 `picgo` 时，才包含云端上传授权。

正文解释性插图风格只询问一次。同一篇文章默认只使用一种归藏插图风格，作者明确要求混用时除外。真实截图和照片不计入风格混用。

篇幅按文章类型确定。新闻和软件更新简报推荐 1500-3000 字，其他类型通常推荐 4000-8000 字。优先保证文章结构完整、前后逻辑连贯，无需为凑字数而注水。如果素材不足，主动说明需要补充的内容，不自行编造。**作者的可信度建立在真实性之上，编造细节或数据是不可接受的。**

Step 2：加载通用规范和可选作者画像

必须阅读 **references/行文风格指南.md**，以校准通用的行文、排版和标点规则。

然后按以下顺序查找可选的外部作者画像，只加载第一个可读取的文件：

1. 作者在本次任务中明确提供的画像路径。 2. 环境变量 `MP_ARTICLE_AUTHOR_PROFILE` 指向的文件。 3. `$HOME/.config/mp-article-writor/author-profile.md`。

默认路径不存在时直接使用本文档的中性写作基线，不为此打断作者。作者明确提供的路径或环境变量不可读取时，提示一次；除非作者要求必须加载画像，否则继续使用中性基线。

作者画像可以按现有文章主类型分别定义结构、分析方式和声音偏好，但不能新增文章类型，也不能覆盖本次明确要求、事实核查、类型路由和平台规则。画像文件属于本地私有资料，不得复制到公开 Skill、文章交付目录、`SOURCES.md`、审读记录或自检报告中，也不得在未获要求时复述其内容。

Step 3：设计大纲和风格

基于 Step 1 确认的意图和 Step 2 校准的语感，设计文章大纲。大纲应包含：

• 符合文章类型的开头。新闻和软件更新简报直接说明日期、版本或信息范围，并用无序列表概括更新；产品体验、工作流复盘和生活叙事根据类型从真实任务、问题、体验、事件或观察切入；技术解析和教程可以从明确问题、技术现象或待解释概念直接进入。
• 各章节的核心论点和承载的叙事功能
• 结尾收束方式
• 视觉素材清单和页面视觉脚本，字段与路由规则见 `references/视觉路由.md`

使用 ask_user 工具将大纲呈现给作者，等待确认后再进入 Step 4。作者在当前请求中已经提供并明确确认大纲时，核对它覆盖本节要求后直接进入 Step 4，不重复请求确认。

Step 4：编写初稿

根据确认后的大纲编写完整初稿。写作过程中遵守本文档中的中性写作基线、内容要求和行文规范；已加载作者画像时，只应用其中与当前主类型兼容的偏好。

初稿保存到 Step 1 已确认的输出目录中。随后在输出目录的 `.mp-article-review/` 下保存一份内容完整、未经筛选的只读初稿副本，并记录其准确路径；该基线不得包含凭据，Step 7 修改工作稿时不得覆盖它。后续审读必须能够同时读取作者素材、这份初稿基线和当前工作稿。

Step 5：独立审读（subagent）

先读取 `references/去模板化审读.md`，再把初稿、文章主类型、已确认素材边界和该参考文件交给 subagent 独立审读。审读不是作者身份检测，也不要求每次都找出问题；已经清楚、自然且符合文体的内容可以原样保留。每条意见应指出具体位置、可观察的问题、对阅读的影响、修改时必须保留的信息，以及建议方向。

• **去模板化审读**：检查空泛铺垫、信息重复、公式化节奏、意义拔高、宣传语、模糊权威、聊天或编辑过程残留，以及妨碍理解的中文句式；模式命中本身不是修改理由。
• **语义保真风险**：拟议修改是否会改变事实、否定、比较对象、范围、条件、时间、完成状态、归因、确定程度或作者立场？
• **逻辑连贯性**：段落之间的转折是否自然？是否有硬拼接的痕迹？
• **结构与节奏**：是否出现没有内容需要却强凑的三段式、重复段式或过度对称结构？真实的并列信息和有意排比应当保留。
• **信息密度 vs 叙事节奏**：是否有段落在堆砌信息，或使用了不符合文章类型的个人表达？新闻和软件更新简报不强制加入个人视角或情绪。
• **类型一致性**：文章是否遵守所选类型的开头、结构、篇幅和来源展示规则？新闻和软件更新简报重点检查标题是否直给、术语是否过多、每节是否说明改动点、影响和应用方式。

Step 6：事实核查（subagent）

调用 subagent 对初稿中涉及的事实性内容进行核查。核查范围：

• 文中引用的数据、数字是否能在素材中找到来源？
• 文中描述的事件、场景是否来自真实素材，还是 AI 自行编造或合成的？
• 文中提及的产品名称、公司名称、技术术语拼写是否与官方一致？
• 文中引用的用户评价、社区讨论是否有原始出处？
• 视觉脚本中的截图、数据、图表、产品界面和标签是否与素材一致？
• 每项外部素材是否记录来源、授权状态和引用要求？

**核查标准**：文中每一个事实性陈述都必须能追溯到作者提供的素材、公开可验证的信息、或作者明确声明的个人经历。无法追溯的内容必须标记为「待作者确认」或删除。

事实核查和正文链接分别处理。新闻和软件更新简报中的 commit SHA、commit 地址、PR 地址和代码证据统一记录在 `SOURCES.md`，默认不放在每节末尾。需要面向读者展示来源时，在文末集中列出官方公告、Release Notes 或产品文档。

Step 7：修改初稿

主 Agent 读取 `references/去模板化审读.md`，再根据 Step 5 和 Step 6 返回的反馈修改初稿：

• 逐条处理审读意见，对每条反馈做出「采纳」或「不采纳（附理由）」的判断
• 删除或改写被标记为编造的内容
• 只修改确实空泛、重复、歧义或不符合当前文体的表达；不为了展示修改量而重写已经清楚的内容
• 修改前后逐项核对独立信息、否定、比较对象、范围、条件、时间、完成状态、归因、确定程度和作者立场；不得把相关写成因果、可能写成确定、计划写成已完成
• 需要个人表达的类型只能使用作者材料中已有的视角、情绪和细节；不得为了制造「活人感」补写经历、冲突、失败、感受、数据或引文
• 新闻和软件更新简报保持直接、克制；技术解析保留必要术语和正式程度，不统一改成聊天语气

Step 8：终审自检（subagent）

调用 subagent 对修改后的稿件和视觉脚本执行完整自检，检查范围包括本文档「自检清单」中的全部项目。向 subagent 提供作者素材、Step 4 记录的初稿基线路径、当前工作稿和 `references/去模板化审读.md`；缺少任一项时不得声称完成语义保真核对。subagent 对照这些材料检查有没有新增、遗漏或强化主张，独立评分，不受前序步骤影响；没有实质问题时可以明确给出「无需修改」。

终审必须同时检查 `references/文章类型路由.md` 中所选类型的专属规则。

Step 9：完成终稿

根据 Step 8 的自检结果完成最终修改。只要终审后又修改了标题或正文含义，就再次调用 subagent 做一次限定范围的语义保真核对，对照作者素材、Step 4 初稿基线和候选终稿；通过后才能交付。纯排版、图片路径或 front matter 状态更新不需要重复语义核对。随后将终稿更新到文件中，附上自检报告，提供三个标题推荐，并确定用于组合封面左侧主封面区的标题和右侧方形分享区的短标题。

Step 10：生产静态视觉素材

按 `references/视觉路由.md` 执行视觉生产：

• 使用 `guizang-social-card-skill` 直接生成一张 `3.35:1` 公众号组合封面，固定输出 `2412×720`。左侧 `1692×720` 为主封面区，右侧 `720×720` 为方形分享区；两区分别设计，在同一 HTML 画布中直接渲染为一张 PNG，不先生成两张图片再拼接。
• 正文解释性插图严格使用 Step 1 已确认的归藏 Skill。选择 social-card 时输出静态排版卡片 PNG 和可编辑 HTML；选择 material-illustration 时输出静态栅格插图和 `PROMPTS.md`。
• 真实截图、照片和图表保留为证据素材；只有在需要重点标注、对比或重新排版时才交给选定的归藏 Skill。
• 所有调用显式传递「目标平台：微信公众号」「交付形式：静态图文」「禁止 Live Photo、视频及其他平台输出」「最终输出目录：<明确路径>」。

视觉生产前无需再次确认授权。完成首轮渲染后自动检查尺寸、裁切、文字、数据、文件路径和移动端可读性；发现问题后修复并重新渲染。

静态检查通过后，根据 Step 1 确定的图片发布方式处理文章引用：

• `local`：保留全部本地成品，正文使用相对于文章文件的标准 Markdown 路径，例如 ``。在