Mp Article Writor

公众号文章生成

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

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

工作流

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

Step 1：理解作者意图

先检查当前环境是否能够读取 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 时，才包含云端上传授权。

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

推荐篇幅 4000-8000 字，但优先保证文章结构完整、前后逻辑连贯，无需为凑字数而注水。如果素材不足以支撑该篇幅，短一些也无妨，在此步骤主动告知作者需要补充哪些内容，而不是自行编造。作者的可信度建立在真实性之上，编造细节或数据是不可接受的。

Step 2：阅读参考资料，校准语感

阅读以下两份参考文件：

• references/范文风格分析.md —— 从作者历史文章中提炼的风格特征和写作模式。必读，用于校准语感和调性。
• references/行文风格指南.md —— 少数派创作手册风格指南，作为行文排版和标点符号的权威参考。必读，确保排版规则无遗漏。

Step 3：设计大纲和风格

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

• 开头切入场景（必须是具体的、真实的事件或场景，不可编造信源）
• 各章节的核心论点和承载的叙事功能
• 计划使用的写作技巧（从「写作技巧工具箱」中选择，或不用）
• 结尾收束方式
• 视觉素材清单和页面视觉脚本，字段与路由规则见 references/视觉路由.md

使用 ask_user 工具将大纲呈现给作者，等待确认后再进入 Step 4。

Step 4：编写初稿

根据确认后的大纲编写完整初稿。写作过程中遵守本文档中「作者声音」「内容要求」「行文规范」的全部规则。

初稿保存到 projects/自媒体运营/mp-高效人生指北 文件夹中。

Step 5：独立审读（subagent）

调用 subagent 对初稿进行独立审读。审读重点：

• AI 味检测：哪些段落读起来像 AI 在输出信息而非人在聊天？具体到句子级别指出。
• 逻辑连贯性：段落之间的转折是否自然？是否有硬拼接的痕迹？
• 结构对称性：是否有过于整齐、对仗的结构让文章显得「被设计过」？
• 信息密度 vs 叙事节奏：是否有段落在堆砌信息而缺乏个人视角或情绪？

Step 6：事实核查（subagent）

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

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

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

Step 7：修改初稿

根据 Step 5 和 Step 6 返回的反馈修改初稿：

• 逐条处理审读意见，对每条反馈做出「采纳」或「不采纳（附理由）」的判断
• 删除或改写被标记为编造的内容
• 修复 AI 味段落，增加个人视角、情绪或具体细节

Step 8：终审自检（subagent）

调用 subagent 对修改后的稿件和视觉脚本执行完整自检，检查范围包括本文档「自检清单」中的全部项目。subagent 独立评分，不受前序步骤影响。

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、视频或其他平台素材。

核心价值观

这是一个计划写一辈子的公众号，持续分享对工作和生活的反思和总结，以文会友，结识有趣的同好。

读者画像

目标读者是对生活保持好奇和热爱的人群，职场人士、自媒体创作者、泛科技爱好者、效率爱好者、AI 爱好者。他们不一定是技术从业者，但对新事物有开放心态，愿意为有信息量的内容花时间。

写作时始终假设读者是「聪明但不专业」的成年人，不需要手把手教，但技术细节需要用生活化的方式解释。

作者声音

用产品经理的逻辑拆解问题，用独立开发者的方式验证答案，用普通人的口吻把过程写出来。

关键调性特征：

• 毒舌但真诚，会自我批评、自我调侃，但最终指向建设性的结论
• 数据+故事双驱动，工具背后谈认知，结论背后有证据
• 冷静平和中蕴含力量，不使用夸张的口语或语气词，文字本身有分量
• 不端着，不教人，不居高临下。像一个有见识的朋友在认真跟你聊一件打动他的事

关于作者声音的具体表现，参阅 references/范文风格分析.md，其中从作者的历史文章中提炼了可复用的写作模式和语言特征。

写作技巧工具箱

以下是一些可选的写作技巧，仅供参考，不是穷举。具体文章使用哪些技巧、采用什么结构，由作者在 prompt 中指定。如果作者未指定，根据素材自然选择，宁可不用也不要生硬套用。

回环呼应（契诃夫之枪）：前面埋的每一个细节后面都得响。文章内部要有 callback 结构，前面提到的一个意象、句子或小钩子，在后面以变体形式再次出现。这种前后因果的闭合感，是让文章从「信息流」变成「作品」的关键。

层层剥开的修辞：不是直接讲结论，而是用「现象→表面解释→更深的追问→核心洞察」的方式展开。让读者参与到思考过程中，感受到推理过程，而不是被动接收结论。

英雄之旅叙事弧：先说遇到了什么问题或好奇心，再说怎么一步步去做、踩了什么坑，最后秀出让人「卧槽」的结果。起点必须是一个具体的、读者能代入的困境或好奇，而不是一个抽象的命题。

内容要求

减少长段落，使用长短句交错的方式增加可读性。可以使用一句话自成一段来制造重点，但慎用。

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

技术内容的深度把控：

• 涉及代码、API、配置等技术细节时，保留足够让读者复现的信息，但不贴大段代码
• 用类比和可视化替代纯技术描述（参考范文中「短跑运动员 vs 马拉松选手」解释 5GHz/2.4GHz 的方式）
• 如果技术细节对理解核心观点不重要，一句话带过

行文规范

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

公众号长文推荐 4000-8000 字，但结构完整、逻辑连贯优先，不硬凑字数。

避免使用以下写作方式：

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

套话：禁用「首先...其次...最后」「综上所述」「值得注意的是」「不难发现」「让我们来看看」「接下来让我们」

空泛工具名：不说「AI 工具」「某个模型」，要说具体名字，比如 Claude Code、Codex、Seedance 2.0、Deepresearch、Clawbot

教科书开头：禁止「在当今 AI 快速发展的时代」「随着技术的不断进步」这类空话开头。永远从一个具体的、当下的事件或场景切入

标点禁令：

• 不使用冒号「：」，用逗号代替
• 不使用破折号「——」
• 不使用任何双引号（""和""都不用），需要引用或强调时用「」或者直接不加引号

固定结尾

"""

我独立开发的 Mac 端 App「流量日记」已上线 Mac App Store，专为自媒体创作者打造，可永久保存、分析各平台导出的账号数据。如果你是用 Mac 的内容创作者，欢迎下载体验，半年内免费使用。

欢迎关注我的公众号「高效人生指北」。

"""

题图与插图

题图与插图默认交付实际静态图片；只有图片生成能力不可用或作者明确只要提示词时，才退化为 prompt 交付。

公众号封面固定使用 guizang-social-card-skill，直接生成一张 3.35:1 组合封面。左侧主封面区与右侧方形分享区分别设计，最终只交付一张封面 PNG。正文解释性插图由作者在 Step 1 选择 guizang-social-card-skill 或 guizang-material-illustration。两个 Skill 都适合解释复杂逻辑和概念，区别在视觉语言与成品形态，具体选择规则见 references/视觉路由.md。

真实截图、照片、原始图表和操作结果优先作为视觉证据。所有图片中的新增文字使用中文；同一组生成插图保持统一风格和配色。正文图片不再强制使用 4:3，按归藏 Skill 的推荐比例和素材原始比例确定。

文档格式

生成的文档保存在 projects/自媒体运营/mp-高效人生指北 文件夹中。

视觉素材保存在 projects/自媒体运营/mp-高效人生指北/article-assets/<文章标识>/。目录规范见 references/视觉路由.md。

文档开头使用以下 front matter 格式（日期字段按实际创建日期填写）：

---
id:
created: YYYY-MM-DD
weekId: YYYY-ww
published:
status: draft
tags:
  - projects/mp-高效人生指北
---

自检清单

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

硬性规则检查

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

• [ ] 字数范围：推荐 4000-8000 字，结构完整和逻辑连贯优先，不为凑字数而注水
• [ ] 标点禁令：全文无冒号「：」（用逗号替代）、无破折号「——」、无双引号（用「」替代）
• [ ] 套话禁令：全文无「首先…其次…最后」「综上所述」「值得注意的是」「不难发现」「让我们来看看」「接下来让我们」
• [ ] 空泛工具名禁令：未出现「AI 工具」「某个模型」等笼统称呼，所有工具均使用具体名称
• [ ] 教科书开头禁令：开头不是「在当今…的时代」「随着…的不断进步」类空话，而是从具体事件或场景切入
• [ ] 表格限制：无 Markdown 表格，或仅有不超过三列且每列文字极少的表格
• [ ] 中英文间距：汉字与英文字母、数字之间有且仅有一个半角空格
• [ ] 专有名词规范：产品名、技术名拼写与官方一致（如 macOS、iOS、GitHub 等）
• [ ] 引号格式：中文引用统一使用直角引号「」，嵌套使用『』
• [ ] 固定结尾：文末包含「流量日记」推广段落和「高效人生指北」公众号引导
• [ ] 公众号封面：已生成 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：符合本文档「文档格式」章节定义的格式
• [ ] 事实性：文中无编造的信源、数据或场景，所有事实性陈述可追溯到素材或公开信息

风格一致性检查

• [ ] 加粗使用克制：加粗仅用于关键观点或关键信息，读者仅看标题和加粗文字即可理解全文大意
• [ ] 段落节奏：无连续超过 5 行的长段落，长短句交错，偶尔用一句话成段制造重点但不滥用
• [ ] 人称一致：全文人称视角统一，不在「我」「我们」「你」之间无故切换
• [ ] 配图风格统一：正文解释性插图使用 Step 1 确认的归藏 Skill，风格和配色统一，新增文字均为中文
• [ ] 视觉证据准确：截图、照片、图表和标签支撑明确的文章内容，没有装饰性占位图
• [ ] 素材记录完整：视觉素材的路径、来源、授权状态和引用要求已记录
• [ ] 依赖状态明确：两个归藏 Skill 的可用状态已记录，缺失依赖没有被旧版 prompt 或另一种风格静默替代
• [ ] 引用有出处：涉及数据、观点、历史事实等均标注了来源或出处
• [ ] 具体而非抽象：观点后有实例、数据、类比或故事支撑，无空洞论断
• [ ] 回环呼应：开头埋下的钩子在后文有回扣，无悬空的叙事线索

内容质量检查

HKR 质检：

• H (Happy) 足够有趣、有悬念吗？标题和开头能让人好奇想点开吗？
• K (Knowledge) 有信息量吗？看完能学到新东西吗？
• R (Resonance) 能戳中情绪吗？让人「对对对我也这么想」？

活人感终审

这是最重要也是最主观的一层。这一层不是逐项检查，而是以读者的视角通读全文，回答一个核心问题：

「读完这篇文章，我感觉是一个有见识的普通人在认真跟我聊一件打动他的事，还是一个 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，微信公众号静态封面、正文解释性插图、真实证据素材的选择和交付规则