---

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 路径，例如 ![中文说明](article-assets/<文章标识>/illustrations/V01-说明.png)。在 SOURCES.md 记录本地路径，并把交付状态写为「需要在公众号编辑器中手动上传图片」。本地模式属于完整交付，不标记为工作流失败。
• picgo：运行 scripts/upload-images-to-picgo.mjs，将一张组合封面和全部最终正文图片批量上传到本机 PicGo Server。脚本保留本地可编辑源文件，只创建临时上传副本，并以「文章标题、素材角色、时间戳」生成唯一图床文件名。用 PicGo 返回的 HTTPS 地址更新文章，front matter 的 cover 指向组合封面，正文使用 ![中文说明](https://...)。同时在 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 选择一致，没有混入另一种归藏风格。
• 图片中的中文标签、图表数据、产品名称和文章事实一致。
• 所有本地素材路径可读取，外部素材已记录来源、授权状态和引用要求。
• .mp-article-review/ 中的初稿基线只用于审读，没有嵌入公众号正文、复制到 SOURCES.md 或上传到图床。
• 图片发布方式为 local 时，文章使用有效的相对 Markdown 路径，交付报告明确提示手动上传到公众号。
• 图片发布方式为 picgo 时，组合封面和正文图片均已上传，文章只引用通过可访问性检查的 HTTPS 图片地址；上传失败时已明确列出待完成项和恢复命令。
• 交付内容中不存在 Live Photo、MOV、PVT、GIF、MP4、视频或其他平台素材。

---

中性写作基线

• 先服从文章类型、作者提供的事实和本次明确意图，不为追求风格编造经历、情绪、身份或数据。
• 语气保持清楚、自然，不默认固定的作者身份、价值观、读者画像或推广目标。
• 观点由素材中的事实、经历或可验证信息支撑；没有依据时明确标记待确认。
• 新闻和软件更新简报使用直接、克制的编辑语气；个人实践和叙事文章可以使用作者提供的第一人称经历。
• 外部作者画像可以细化当前类型的结构和声音，但不能替代类型路由或事实核查。

内容要求

段落围绕完整意思组织，并兼顾公众号移动端阅读。信息过密、关系混杂时拆分，连续碎片表达同一件事时合并；不按照固定行数切段，也不为了变化句长强行拆句或合句。一句话可以自成一段，但只在确实需要强调时使用。

谨慎使用加粗，仅用于关键观点表达或关键信息。预设读者仅通过标题和加粗的文字，也能理解全篇内容。

文档只保留一个 # 文章主标题，用于记录公众号题目。正文所有章节标题统一使用 ###，不使用 ##、#### 或更深层级，以适配公众号原生标题大小。

技术内容的深度把控：

• 涉及代码、API、配置等技术细节时，保留足够让读者复现的信息，但不贴大段代码
• 在类比准确且确实有助于理解时，用类比或可视化替代纯技术描述
• 如果技术细节对理解核心观点不重要，一句话带过

行文规范

参考 references/行文风格指南.md（少数派创作手册风格指南），作为行文排版和标点符号的权威参考。

篇幅遵循文章类型路由。新闻和软件更新简报推荐 1500-3000 字，其他类型通常推荐 4000-8000 字；结构完整、逻辑连贯优先，不硬凑字数。

避免使用以下写作方式：

markdown 格式的表格，因为不适宜在移动端展示。除非是小于三列，且每列中的文字极少。

高频套话：检查「首先...其次...最后」「综上所述」「值得注意的是」「不难发现」「让我们来看看」「接下来让我们」等表达是否承担独立信息或真实的顺序、总结、转折功能。只作空泛铺垫或重复时删除；承担明确作用且符合当前文体时保留。

工具名称精度：材料明确指向具体产品或模型时，使用其准确名称，例如 Claude Code、Codex 或 Seedance 2.0。讨论工具类别，或材料没有说明具体名称时，可以使用「AI 工具」「某个模型」等概括表达；不得为了显得具体而猜测或补造产品名。

空泛教科书开头：「在当今 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 格式（日期字段按实际创建日期填写）：

---
id:
created: YYYY-MM-DD
weekId: YYYY-ww
published:
status: draft
tags:
  - <作者确认的标签>
---

自检清单

以下清单在 Step 8 由 subagent 独立执行，不可自评。

交付规则检查

逐条核实以下交付规则，任何一条未通过都必须修改后再提交：

• 字数范围：符合文章类型路由；新闻和软件更新简报推荐 1500-3000 字，其他类型通常推荐 4000-8000 字，不为凑字数而注水
• 类型路由：已记录文章主类型，并遵守对应的开头、结构、篇幅、来源展示和终审规则
• 标题层级：文档只有一个 # 文章主标题；正文章节标题统一使用 ###，没有 ##、#### 或更深层级
• 套话作用：高频连接词和总结语只在承担真实顺序、转折或总结作用时保留；没有独立信息的铺垫和收尾已经删除
• 工具名称精度：材料指向具体产品时使用准确名称；讨论类别或名称未知时保留概括表达，没有猜测或补造产品名
• 开头有效性：开头没有缺少独立信息的时代背景或趋势铺垫；真实的时间、趋势和因果背景得到保留；各类型遵循自己的开头方式
• 表格限制：无 Markdown 表格，或仅有不超过三列且每列文字极少的表格
• 中英文间距：汉字与英文字母、数字之间有且仅有一个半角空格
• 专有名词规范：产品名、技术名拼写与官方一致（如 macOS、iOS、GitHub 等）
• 引号格式：中文引用统一使用直角引号「」，嵌套使用『』
• 结尾授权：未擅自追加账号、产品、优惠或关注引导；已添加的推广信息均来自本次输入或已加载的作者画像，并已核实
• 画像隔离：未把外部作者画像、个人路径或画像原文复制到公开 Skill、共享仓库或文章交付资料
• 公众号封面：已生成 2412×720 单张组合封面和可编辑 HTML，左侧 1692×720 与右侧 720×720 分别设计；如果 social-card 未安装，已标记为待完成并附安装命令
• 图片发布方式：已按「当前请求 → 环境变量 → 询问」确定并记录本次选择；没有未经授权的云端上传
• 本地交付：local 模式使用相对 Markdown 图片路径，并提示作者在公众号编辑器中手动上传
• PicGo 交付：picgo 模式的图片已上传并通过 HTTPS 可访问性检查；上传失败时保留本地引用并标记为待完成
• 静态交付：不存在 Live Photo、MOV、PVT、GIF、MP4、视频或其他平台素材
• front matter：符合本文档「文档格式」章节定义的格式
• 事实性：文中无编造的信源、数据或场景，所有事实性陈述可追溯到素材或公开信息
• 语义保真：修改没有遗漏独立信息，也没有改变否定、比较对象、范围、条件、时间、完成状态、归因、确定程度或作者立场
• 审读基线：Step 4 初稿基线可读取，Step 8 已收到作者素材、基线和当前工作稿；终审后的含义修改已经再次完成语义保真核对
• 新闻简报来源：新闻和软件更新简报没有在每节末尾附 commit 或 PR 地址，代码证据已记录在 SOURCES.md

风格一致性检查

• 加粗使用克制：加粗仅用于关键观点或关键信息，读者仅看标题和加粗文字即可理解全文大意
• 段落组织：段落围绕完整意思组织，信息不过密也不过度碎片化；没有为追求长短变化而机械拆句或切段
• 人称一致：全文人称视角统一，不在「我」「我们」「你」之间无故切换
• 画像适配：加载作者画像时，只应用了与当前主类型兼容的偏好；未加载时使用中性基线
• 配图风格统一：正文解释性插图使用 Step 1 确认的归藏 Skill，风格和配色统一，新增文字均为中文
• 视觉证据准确：截图、照片、图表和标签支撑明确的文章内容，没有装饰性占位图
• 素材记录完整：视觉素材的路径、来源、授权状态和引用要求已记录
• 依赖状态明确：两个归藏 Skill 的可用状态已记录，缺失依赖没有被旧版 prompt 或另一种风格静默替代
• 引用有出处：涉及数据、观点、历史事实等均标注了来源或出处
• 证据与边界：需要证据的判断由现有实例、数据、经历或可验证信息支撑；素材不足时保留限制或标记待确认，没有补造装饰性案例

内容质量检查

HKR 质检：

• H (Happy) 是否提供了准确、明确的阅读理由，而不是依赖夸张标题、制造焦虑或虚构悬念？
• K (Knowledge) 有信息量吗？看完能学到新东西吗？
• R (Resonance) 在文章类型和现有素材需要时，是否形成了真实共鸣，而不是强行抒情？

新闻和软件更新简报以 K 为主要指标。R 偏低不构成失败，不得为了提高 R 编造个人经历或强行抒情。

自然表达终审

这一层不是作者身份检测，也不保证通过任何 AI 检测器。以读者视角通读全文，判断表达是否符合当前文章类型。叙事、体验和实践类文章回答以下问题：

「作者是否在用材料支持自己的观察、选择和判断，还是只在排列正确但空泛的信息？」

新闻和软件更新简报检查「是否像一位克制的编辑在提供准确、清楚、可快速扫读的信息」；技术解析检查「是否清楚说明现象、机制和边界」。两者都不要求个人故事和情绪共鸣。

如果答案偏向后者，重点检查：

• 是否存在空泛铺垫、重复结论、意义拔高、模糊归因或不符合文章类型的语气？
• 需要个人表达的类型，是否只在堆砌信息而没有呈现材料中已有的观察和判断？
• 是否有转折生硬、缺乏内在逻辑的地方？
• 是否在没有内容需要时强凑三段式、重复段式或对称结构？
• 已经清楚的内容是否被过度修改？

自检输出格式

自检结果以如下格式输出，附在文章末尾（不计入正文字数）：

---自检报告---

📏 交付规则：✅ 全部通过 / ❌ 未通过项：[列出]
🎨 风格一致性：✅ 全部通过 / ⚠️ 需注意项：[列出]
📊 HKR 评分：H ★★★☆☆ / K ★★★★☆ / R ★★★☆☆
   - H：[一句话说明趣味性/悬念感]
   - K：[一句话说明信息增量]
   - R：[一句话说明情绪共鸣点]
👤 自然表达终审：✅ 通过 / ❌ 未通过
   - [一句话总评，说明表达是否符合当前文章类型，是否仍有空泛或模板化问题]
📝 字数统计：[正文字数]
🖼️ 配图清单：公众号组合封面 ×1 / 正文插图 ×[N] / 真实素材 ×[N]
图片发布方式：[local / picgo]
图片发布状态：[本地交付，需手动上传 / PicGo 已上传 ×N / PicGo 待上传 ×N]
📁 视觉输出目录：[绝对路径]
🎨 正文插图风格：[guizang-social-card-skill / guizang-material-illustration]

修改建议（如有）：
1. ...
2. ...

参考资料

• references/文章类型路由.md，文章类型判断和各类型专属结构
• references/行文风格指南.md，少数派创作手册风格指南，行文排版和标点符号的权威参考
• references/去模板化审读.md，Step 5、Step 7 和 Step 8 使用的语义保真与去模板化检查
• references/视觉路由.md，微信公众号静态封面、正文解释性插图、真实证据素材的选择和交付规则