mp-article-writor · git:20260921.005d779 · 2026-09-21 · sha256 6352cec948f8e032
mp-article-writor git:20260921.005d779B
Immutable. This exact content is served forever at /api/v1/blob/6352cec948f8e032.
--- 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 都是完整静态视觉工作流的推荐前置条件，但不得自动安装、不得声明为强制依赖。 读取环境变量 `MP_ARTICLE_IMAGE_MODE`，只接受 `local` 或 `picgo`： - 未设置时，使用 ask_user 工具询问一次图片发布方式，推荐并默认选择 `local`。 - 设置为 `local` 时，只生成本地图片，不探测 PicGo，不产生云端写入。 - 设置为 `picgo` 时，视为作者已经持久授权本工作流通过 PicGo 上传最终图片，再检查本机 PicGo Server 是否可访问。 - 值不合法时停止图片发布分支，提示改为 `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`，或环境变量明确设置为 `picgo` 时，才包含云端上传授权。 正文解释性插图风格只询问一次。同一篇文章默认只使用一种归藏插图风格，作者明确要求混用时除外。真实截图和照片不计入风格混用。 篇幅按文章类型确定。新闻和软件更新简报推荐 1500-3000 字，其他类型通常推荐 4000-8000 字。优先保证文章结构完整、前后逻辑连贯，无需为凑字数而注水。如果素材不足，主动说明需要补充的内容，不自行编造。**作者的可信度建立在真实性之上，编造细节或数据是不可接受的。** ### Step 2：阅读参考资料，校准语感 必须阅读 **references/行文风格指南.md**，以校准通用的行文、排版和标点规则。 如果作者明确提供范文、风格说明，或当前环境已经安装作者自行维护的私有风格 Skill，则同时读取该资料。私有资料只用于本次作者的文章，不得复制到公开 Skill、共享仓库、交付附件或事实来源中。没有私有风格资料时，使用本文档的中性写作基线，不要猜测作者身份、价值观、读者画像或固定结尾。 ### Step 3：设计大纲和风格 基于 Step 1 确认的意图和 Step 2 校准的语感，设计文章大纲。大纲应包含： - 符合文章类型的开头。新闻和软件更新简报直接说明日期、版本或信息范围，并用无序列表概括更新；产品体验、工作流复盘和生活叙事根据类型从真实任务、问题、体验、事件或观察切入；技术解析和教程可以从明确问题、技术现象或待解释概念直接进入。 - 各章节的核心论点和承载的叙事功能 - 计划使用的写作技巧（从「写作技巧工具箱」中选择，或不用） - 结尾收束方式 - 视觉素材清单和页面视觉脚本，字段与路由规则见 `references/视觉路由.md` 使用 ask_user 工具将大纲呈现给作者，等待确认后再进入 Step 4。 ### Step 4：编写初稿 根据确认后的大纲编写完整初稿。写作过程中遵守本文档中「默认写作基线」「内容要求」「行文规范」的全部规则；已加载私有风格资料时，再应用其中与本次文章类型相容的偏好。 初稿保存到 Step 1 已确认的输出目录中。 ### Step 5：独立审读（subagent） 调用 subagent 对初稿进行独立审读。审读重点： - **AI 味检测**：哪些段落读起来像 AI 在输出信息而非人在聊天？具体到句子级别指出。 - **逻辑连贯性**：段落之间的转折是否自然？是否有硬拼接的痕迹？ - **结构对称性**：是否有过于整齐、对仗的结构让文章显得「被设计过」？ - **信息密度 vs 叙事节奏**：是否有段落在堆砌信息，或使用了不符合文章类型的个人表达？新闻和软件更新简报不强制加入个人视角或情绪。 - **类型一致性**：文章是否遵守所选类型的开头、结构、篇幅和来源展示规则？新闻和软件更新简报重点检查标题是否直给、术语是否过多、每节是否说明改动点、影响和应用方式。 ### Step 6：事实核查（subagent） 调用 subagent 对初稿中涉及的事实性内容进行核查。核查范围： - 文中引用的数据、数字是否能在素材中找到来源？ - 文中描述的事件、场景是否来自真实素材，还是 AI 自行编造或合成的？ - 文中提及的产品名称、公司名称、技术术语拼写是否与官方一致？ - 文中引用的用户评价、社区讨论是否有原始出处？ - 视觉脚本中的截图、数据、图表、产品界面和标签是否与素材一致？ - 每项外部素材是否记录来源、授权状态和引用要求？ **核查标准**：文中每一个事实性陈述都必须能追溯到作者提供的素材、公开可验证的信息、或作者明确声明的个人经历。无法追溯的内容必须标记为「待作者确认」或删除。 事实核查和正文链接分别处理。新闻和软件更新简报中的 commit SHA、commit 地址、PR 地址和代码证据统一记录在 `SOURCES.md`，默认不放在每节末尾。需要面向读者展示来源时，在文末集中列出官方公告、Release Notes 或产品文档。 ### Step 7：修改初稿 根据 Step 5 和 Step 6 返回的反馈修改初稿： - 逐条处理审读意见，对每条反馈做出「采纳」或「不采纳（附理由）」的判断 - 删除或改写被标记为编造的内容 - 修复 AI 味段落。需要个人表达的类型增加真实视角、情绪或具体细节；新闻和软件更新简报保持直接、克制，不强行加入个人经历 ### Step 8：终审自检（subagent） 调用 subagent 对修改后的稿件和视觉脚本执行完整自检，检查范围包括本文档「自检清单」中的全部项目。subagent 独立评分，不受前序步骤影响。 终审必须同时检查 `references/文章类型路由.md` 中所选类型的专属规则。 ### Step 9：完成终稿 根据 Step 8 的自检结果完成最终修改。将终稿更新到文件中，附上自检报告，提供三个标题推荐，并确定用于组合封面左侧主封面区的标题和右侧方形分享区的短标题。 ### 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 路径，例如 ``。在 `SOURCES.md` 记录本地路径，并把交付状态写为「需要在公众号编辑器中手动上传图片」。本地模式属于完整交付，不标记为工作流失败。 - `picgo`：运行 `scripts/upload-images-to-picgo.mjs`，将一张组合封面和全部最终正文图片批量上传到本机 PicGo Server。脚本保留本地可编辑源文件，只创建临时上传副本，并以「文章标题、素材角色、时间戳」生成唯一图床文件名。用 PicGo 返回的 HTTPS 地址更新文章，front matter 的 `cover` 指向组合封面，正文使用 ``。同时在 `SOURCES.md` 记录本地文件与远程地址的映射。 PicGo 上传前执行 `POST /heartbeat`，旧版本返回 `404` 或 `405` 时继续尝试 `/upload`。上传后逐个验证远程地址返回 `2xx` 且内容类型为图片。不得读取、输出或写入腾讯云、GitHub、阿里云等图床凭据；上传配置完全交给作者已经配置的 PicGo。PicGo Server 默认地址为 `http://127.0.0.1:36677`，可用 `--endpoint` 或 `PICGO_SERVER_URL` 覆盖，基础地址和完整 `/upload` 地址都可使用。服务启用鉴权时只从 `PICGO_SERVER_SECRET` 环境变量取得 shared secret，不读取 PicGo 图床配置文件。 PicGo 连接失败、超时、鉴权失败或返回异常时，不修改文章中的本地图片引用，不删除本地成品。将交付状态写为「图片发布待完成」，记录失败信息和可重新执行的命令。 如果所需归藏 Skill 未安装，跳过该 Skill 对应的视觉生产，保留已经完成的文章和其他视觉素材，并把缺失项、安装命令和恢复入口写入交付检查。不得静默切换到另一种插图风格。 ### Step 11：交付检查 逐项确认： - 终稿、一张组合封面、正文插图、真实素材、可编辑文件和来源记录均存在于明确输出目录；因归藏 Skill 缺失而未生成的项目已明确列入待完成清单。 - 公众号组合封面为 `2412×720`。左侧主封面区为 `1692×720`，右侧方形分享区为 `720×720`，两区分别设计并位于同一张 PNG 中。 - 正文解释性插图与 Step 1 选择一致，没有混入另一种归藏风格。 - 图片中的中文标签、图表数据、产品名称和文章事实一致。 - 所有本地素材路径可读取，外部素材已记录来源、授权状态和引用要求。 - 图片发布方式为 `local` 时，文章使用有效的相对 Markdown 路径，交付报告明确提示手动上传到公众号。 - 图片发布方式为 `picgo` 时，组合封面和正文图片均已上传，文章只引用通过可访问性检查的 HTTPS 图片地址；上传失败时已明确列出待完成项和恢复命令。 - 交付内容中不存在 Live Photo、MOV、PVT、GIF、MP4、视频或其他平台素材。 --- ## 默认写作基线 - 先服从文章类型、作者提供的事实和本次明确意图，不为追求风格编造经历、情绪、身份或数据。 - 用具体场景、证据和可验证细节承载判断；没有依据时明确标记待确认。 - 语气清楚、克制、自然，避免居高临下、空泛升华和模板化的价值观输出。 - 面向非专业读者时解释必要术语，但不默认任何固定读者画像。 - 新闻和软件更新简报使用直接的编辑语气；个人实践和叙事文章可以使用作者提供的第一人称经历。 - 作者提供的私有风格资料可以细化声音、结构和结尾，但不能覆盖事实核查、文章类型路由与平台规则。 ## 写作技巧工具箱 以下是一些可选的写作技巧，仅供参考，不是穷举。具体文章使用哪些技巧、采用什么结构，由作者在 prompt 中指定。如果作者未指定，根据素材自然选择，宁可不用也不要生硬套用。 **回环呼应（契诃夫之枪）**：前面埋的每一个细节后面都得响。文章内部要有 callback 结构，前面提到的一个意象、句子或小钩子，在后面以变体形式再次出现。这种前后因果的闭合感，是让文章从「信息流」变成「作品」的关键。 **层层剥开的修辞**：不是直接讲结论，而是用「现象→表面解释→更深的追问→核心洞察」的方式展开。让读者参与到思考过程中，感受到推理过程，而不是被动接收结论。 **英雄之旅叙事弧**：先说遇到了什么问题或好奇心，再说怎么一步步去做、踩了什么坑，最后秀出让人「卧槽」的结果。起点必须是一个具体的、读者能代入的困境或好奇，而不是一个抽象的命题。 ## 内容要求 减少长段落，使用长短句交错的方式增加可读性。可以使用一句话自成一段来制造重点，但慎用。 谨慎使用加粗，仅用于关键观点表达或关键信息。预设读者仅通过标题和加粗的文字，也能理解全篇内容。 文档只保留一个 `#` 文章主标题，用于记录公众号题目。正文所有章节标题统一使用 `###`，不使用 `##`、`####` 或更深层级，以适配公众号原生标题大小。 技术内容的深度把控： - 涉及代码、API、配置等技术细节时，保留足够让读者复现的信息，但不贴大段代码 - 用类比和可视化替代纯技术描述（参考范文中「短跑运动员 vs 马拉松选手」解释 5GHz/2.4GHz 的方式） - 如果技术细节对理解核心观点不重要，一句话带过 ## 行文规范 参考 references/行文风格指南.md（少数派创作手册风格指南），作为行文排版和标点符号的权威参考。 篇幅遵循文章类型路由。新闻和软件更新简报推荐 1500-3000 字，其他类型通常推荐 4000-8000 字；结构完整、逻辑连贯优先，不硬凑字数。 避免使用以下写作方式： markdown 格式的表格，因为不适宜在移动端展示。除非是小于三列，且每列中的文字极少。 套话：禁用「首先...其次...最后」「综上所述」「值得注意的是」「不难发现」「让我们来看看」「接下来让我们」 **空泛工具名**：不说「AI 工具」「某个模型」，要说具体名字，比如 Claude Code、Codex、Seedance 2.0、Deepresearch、Clawbot **教科书开头**：禁止「在当今 AI 快速发展的时代」「随着技术的不断进步」这类空话开头。开头方式必须遵循文章类型路由：新闻和软件更新简报直接说明日期、版本或信息范围，并紧接更新概览；技术解析和教程可以从明确问题、技术现象或待解释概念进入；其他类型根据需要从真实任务、问题、体验、事件或观察切入 **标点禁令**： - 不使用冒号「：」，用逗号代替 - 不使用破折号「——」 - 不使用任何双引号（""和""都不用），需要引用或强调时用「」或者直接不加引号 ### 结尾与推广信息 默认根据文章内容自然收束，不自动追加账号名称、产品推广、关注引导或固定 CTA。只有作者在本次任务中明确提供，或已加载的私有风格资料明确规定时才添加；涉及价格、优惠、上线状态和链接时仍需事实核查。 ## 题图与插图 题图与插图默认交付实际静态图片；只有图片生成能力不可用或作者明确只要提示词时，才退化为 prompt 交付。 公众号封面固定使用 `guizang-social-card-skill`，直接生成一张 `3.35:1` 组合封面。左侧主封面区与右侧方形分享区分别设计，最终只交付一张封面 PNG。正文解释性插图由作者在 Step 1 选择 `guizang-social-card-skill` 或 `guizang-material-illustration`。两个 Skill 都适合解释复杂逻辑和概念，区别在视觉语言与成品形态，具体选择规则见 `references/视觉路由.md`。 真实截图、照片、原始图表和操作结果优先作为视觉证据。所有图片中的新增文字使用中文；同一组生成插图保持统一风格和配色。正文图片不再强制使用 `4:3`，按归藏 Skill 的推荐比例和素材原始比例确定。 ## 文档格式 生成的文档保存在 Step 1 已确认的输出目录中。 视觉素材保存在 `<输出目录>/article-assets/<文章标识>/`。目录规范见 `references/视觉路由.md`。 文档开头使用以下 front matter 格式（日期字段按实际创建日期填写）： ```yaml --- id: created: YYYY-MM-DD weekId: YYYY-ww published: status: draft tags: - <作者确认的标签> --- ``` ## 自检清单 以下清单在 Step 8 由 subagent 独立执行，不可自评。 ### 硬性规则检查 逐条核实以下禁令，任何一条未通过都必须修改后再提交： - [ ] **字数范围**：符合文章类型路由；新闻和软件更新简报推荐 1500-3000 字，其他类型通常推荐 4000-8000 字，不为凑字数而注水 - [ ] **类型路由**：已记录文章主类型，并遵守对应的开头、结构、篇幅、来源展示和终审规则 - [ ] **标题层级**：文档只有一个 `#` 文章主标题；正文章节标题统一使用 `###`，没有 `##`、`####` 或更深层级 - [ ] **标点禁令**：全文无冒号「：」（用逗号替代）、无破折号「——」、无双引号（用「」替代） - [ ] **套话禁令**：全文无「首先…其次…最后」「综上所述」「值得注意的是」「不难发现」「让我们来看看」「接下来让我们」 - [ ] **空泛工具名禁令**：未出现「AI 工具」「某个模型」等笼统称呼，所有工具均使用具体名称 - [ ] **教科书开头禁令**：开头没有「在当今…的时代」「随着…的不断进步」类空话；新闻和软件更新简报以日期、版本或信息范围直接开头并紧接更新概览；其他类型遵循各自的开头方式 - [ ] **表格限制**：无 Markdown 表格，或仅有不超过三列且每列文字极少的表格 - [ ] **中英文间距**：汉字与英文字母、数字之间有且仅有一个半角空格 - [ ] **专有名词规范**：产品名、技术名拼写与官方一致（如 macOS、iOS、GitHub 等） - [ ] **引号格式**：中文引用统一使用直角引号「」，嵌套使用『』 - [ ] **结尾授权**：未擅自追加账号、产品、优惠或关注引导；已添加的推广信息均来自作者本次输入或已加载的私有资料，并已核实 - [ ] **隐私隔离**：未把作者私有风格资料、历史范文、个人路径或身份信息复制到公开 Skill、共享仓库或交付附件 - [ ] **公众号封面**：已生成 2412×720 单张组合封面和可编辑 HTML，左侧 1692×720 与右侧 720×720 分别设计；如果 social-card 未安装，已标记为待完成并附安装命令 - [ ] **图片发布方式**：`MP_ARTICLE_IMAGE_MODE` 未设置时默认使用 `local`；已记录本次选择，没有未经授权的云端上传 - [ ] **本地交付**：`local` 模式使用相对 Markdown 图片路径，并提示作者在公众号编辑器中手动上传 - [ ] **PicGo 交付**：`picgo` 模式的图片已上传并通过 HTTPS 可访问性检查；上传失败时保留本地引用并标记为待完成 - [ ] **静态交付**：不存在 Live Photo、MOV、PVT、GIF、MP4、视频或其他平台素材 - [ ] **front matter**：符合本文档「文档格式」章节定义的格式 - [ ] **事实性**：文中无编造的信源、数据或场景，所有事实性陈述可追溯到素材或公开信息 - [ ] **新闻简报来源**：新闻和软件更新简报没有在每节末尾附 commit 或 PR 地址，代码证据已记录在 `SOURCES.md` ### 风格一致性检查 - [ ] **加粗使用克制**：加粗仅用于关键观点或关键信息，读者仅看标题和加粗文字即可理解全文大意 - [ ] **段落节奏**：无连续超过 5 行的长段落，长短句交错，偶尔用一句话成段制造重点但不滥用 - [ ] **人称一致**：全文人称视角统一，不在「我」「我们」「你」之间无故切换 - [ ] **配图风格统一**：正文解释性插图使用 Step 1 确认的归藏 Skill，风格和配色统一，新增文字均为中文 - [ ] **视觉证据准确**：截图、照片、图表和标签支撑明确的文章内容，没有装饰性占位图 - [ ] **素材记录完整**：视觉素材的路径、来源、授权状态和引用要求已记录 - [ ] **依赖状态明确**：两个归藏 Skill 的可用状态已记录，缺失依赖没有被旧版 prompt 或另一种风格静默替代 - [ ] **引用有出处**：涉及数据、观点、历史事实等均标注了来源或出处 - [ ] **具体而非抽象**：观点后有实例、数据、类比或故事支撑，无空洞论断 - [ ] **回环呼应**：开头埋下的钩子在后文有回扣，无悬空的叙事线索 ### 内容质量检查 HKR 质检： - **H (Happy)** 足够有趣、有悬念吗？标题和开头能让人好奇想点开吗？ - **K (Knowledge)** 有信息量吗？看完能学到新东西吗？ - **R (Resonance)** 能戳中情绪吗？让人「对对对我也这么想」？ 新闻和软件更新简报以 K 为主要指标。R 偏低不构成失败，不得为了提高 R 编造个人经历或强行抒情。 ### 活人感终审 这是最重要也是最主观的一层。这一层不是逐项检查，而是以读者的视角通读全文。叙事、体验和实践类文章回答以下问题： **「读完这篇文章，我感觉是一个有见识的普通人在认真跟我聊一件打动他的事，还是一个 AI 在给我输出信息？」** 新闻和软件更新简报改为检查「是否像一位克制的编辑在提供准确、清楚、可快速扫读的信息」，不要求个人故事和情绪共鸣。 如果答案偏向后者，重点检查： - 需要个人表达的类型，是否有段落只在堆砌信息而缺乏真实视角或情绪？新闻和软件更新简报改为检查信息是否准确、清楚、便于扫读。 - 是否有转折生硬、缺乏内在逻辑的地方？ - 是否有过于整齐、对称的结构让文章显得「被设计过」？ ### 自检输出格式 自检结果以如下格式输出，附在文章末尾（不计入正文字数）： ``` ---自检报告--- 📏 硬性规则：✅ 全部通过 / ❌ 未通过项：[列出] 🎨 风格一致性：✅ 全部通过 / ⚠️ 需注意项：[列出] 📊 HKR 评分：H ★★★☆☆ / K ★★★★☆ / R ★★★☆☆ - H：[一句话说明趣味性/悬念感] - K：[一句话说明信息增量] - R：[一句话说明情绪共鸣点] 👤 活人感终审：✅ 通过 / ❌ 未通过 - [一句话总评，说明读感是「朋友在聊天」还是「AI在输出」] 📝 字数统计：[正文字数] 🖼️ 配图清单：公众号组合封面 ×1 / 正文插图 ×[N] / 真实素材 ×[N] 图片发布方式：[local / picgo] 图片发布状态：[本地交付，需手动上传 / PicGo 已上传 ×N / PicGo 待上传 ×N] 📁 视觉输出目录：[绝对路径] 🎨 正文插图风格：[guizang-social-card-skill / guizang-material-illustration] 修改建议（如有）： 1. ... 2. ... ``` ## 参考资料 - references/文章类型路由.md，文章类型判断和各类型专属结构 - references/行文风格指南.md，少数派创作手册风格指南，行文排版和标点符号的权威参考 - references/视觉路由.md，微信公众号静态封面、正文解释性插图、真实证据素材的选择和交付规则