菜单
微信公众号文章创作。当用户想把工作流探索、AI 工具测评、产品体验、个人实践、生活感悟等素材整理成公众号文章时使用。即使用户只是说「帮我写篇文章」「整理成推文」「发公众号」，也应当触发此技能。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
**强制性前置条件** — 每次调用 `batch_edit` 工具之前，必须先调用此技能。 未经加载此技能，绝不能直接调用 `batch_edit`。 当用户想要在 Ardot 设计文件中创建、更新、移动或删除节点时触发 — 例如插入框架、文本、形状、组件；将变量绑定到填充/描边； 构建屏幕、组件或设计库。当涉及 batch_edit DSL 操作时也加载 （I/U/M/D/C/G 操作符）。
**强制性前置条件** — 每次调用 `create_new_page` 工具之前，必须先调用此技能。 未经加载此技能，绝不能直接调用 `create_new_page`。 当用户想要在 Ardot 设计文件中创建新页面时触发。 关键词：在 Ardot 上下文中的"创建新页面"、"添加页面"、"新画布"。
Record and query AI conversation logs — what users asked, how it was solved, and the result. Use when users want to logging conversation, summarize recent work from sessions, or want daily/weekly project summaries from past conversations.
在 Ardot 中从头构建完整页面、屏幕或多区块 UI 布局时，将此技能与 ardot-use 配合使用。 通过 6 步工作流程编排多个 MCP 工具：初始化 → 样式系统 → 变量 → 骨架 → 逐区块构建 → 验证。 触发条件："在 Ardot 中创建落地页"、"构建登录屏幕"、 "在 Ardot 中设计仪表板"、"制作设置页面"、"创建个人资料屏幕"、 "在 Ardot 中构建此页面"、"将此设计转换为 Ardot"。
在 Ardot 中构建可复用组件库或设计系统时使用此技能。 涵盖从变量/设计令牌创建到使用正确变量绑定构建组件的完整工作流程， 直至最终验证。 触发条件："创建组件库"、"构建设计系统"、 "制作可复用按钮"、"创建 UI 组件"、"构建组件集"、 "设计系统"、"组件库"、"可复用组件"。
从头设计或为 Ardot 项目应用视觉主题时使用此技能。 涵盖 `search_style_guide` → `build_style_guide` 工作流程，用于发现和应用完整的设计系统（颜色、排版、间距、布局模式）。 触发条件："设计落地页"、"创建仪表板"、"应用深色主题"、 "设置设计系统"、"选择调色板"、"为应用选择字体"、 "样式指南"、"视觉风格"、"外观和感觉"。
| name | mp-article-writor |
| description | 微信公众号文章创作。当用户想把工作流探索、AI 工具测评、产品体验、个人实践、生活感悟等素材整理成公众号文章时使用。即使用户只是说「帮我写篇文章」「整理成推文」「发公众号」，也应当触发此技能。 |
帮助作者将素材整理为一篇可直接进入微信公众号编辑和配图流程的静态图文长文。
本 Skill 只处理微信公众号。所有交给归藏 Skill 的任务都必须显式传递「微信公众号、静态图文」；禁止生成 Live Photo、MOV、PVT、GIF、MP4、视频替代品、小红书图片或其他平台封面。
严格按以下 11 个步骤顺序执行，不可跳步、不可合并。每一步完成后再进入下一步。
先检查当前环境是否能够读取 guizang-social-card-skill 和 guizang-material-illustration。两个 Skill 都是完整静态视觉工作流的推荐前置条件，但不得自动安装、不得声明为强制依赖。
读取环境变量 MP_ARTICLE_IMAGE_MODE，只接受 local 或 picgo：
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 缺失时，明确说明安装后才能生产对应插图。local-tests 目录作为最终交付目录。local 只生成本地图片并使用相对 Markdown 路径；picgo 上传到作者已经配置的图床并替换为 HTTPS 地址。环境变量未设置时只询问一次。picgo，或环境变量明确设置为 picgo 时，才包含云端上传授权。正文解释性插图风格只询问一次。同一篇文章默认只使用一种归藏插图风格，作者明确要求混用时除外。真实截图和照片不计入风格混用。
推荐篇幅 4000-8000 字，但优先保证文章结构完整、前后逻辑连贯，无需为凑字数而注水。如果素材不足以支撑该篇幅，短一些也无妨，在此步骤主动告知作者需要补充哪些内容，而不是自行编造。作者的可信度建立在真实性之上，编造细节或数据是不可接受的。
阅读以下两份参考文件：
基于 Step 1 确认的意图和 Step 2 校准的语感，设计文章大纲。大纲应包含：
references/视觉路由.md使用 ask_user 工具将大纲呈现给作者，等待确认后再进入 Step 4。
根据确认后的大纲编写完整初稿。写作过程中遵守本文档中「作者声音」「内容要求」「行文规范」的全部规则。
初稿保存到 projects/自媒体运营/mp-高效人生指北 文件夹中。
调用 subagent 对初稿进行独立审读。审读重点：
调用 subagent 对初稿中涉及的事实性内容进行核查。核查范围：
核查标准：文中每一个事实性陈述都必须能追溯到作者提供的素材、公开可验证的信息、或作者明确声明的个人经历。无法追溯的内容必须标记为「待作者确认」或删除。
根据 Step 5 和 Step 6 返回的反馈修改初稿：
调用 subagent 对修改后的稿件和视觉脚本执行完整自检，检查范围包括本文档「自检清单」中的全部项目。subagent 独立评分，不受前序步骤影响。
根据 Step 8 的自检结果完成最终修改。将终稿更新到文件中，附上自检报告，提供三个标题推荐，并确定用于组合封面左侧主封面区的标题和右侧方形分享区的短标题。
按 references/视觉路由.md 执行视觉生产：
guizang-social-card-skill 直接生成一张 3.35:1 公众号组合封面，固定输出 2412×720。左侧 1692×720 为主封面区，右侧 720×720 为方形分享区；两区分别设计，在同一 HTML 画布中直接渲染为一张 PNG，不先生成两张图片再拼接。PROMPTS.md。视觉生产前无需再次确认授权。完成首轮渲染后自动检查尺寸、裁切、文字、数据、文件路径和移动端可读性；发现问题后修复并重新渲染。
静态检查通过后，根据 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 对应的视觉生产，保留已经完成的文章和其他视觉素材，并把缺失项、安装命令和恢复入口写入交付检查。不得静默切换到另一种插图风格。
逐项确认：
2412×720。左侧主封面区为 1692×720，右侧方形分享区为 720×720，两区分别设计并位于同一张 PNG 中。local 时，文章使用有效的相对 Markdown 路径，交付报告明确提示手动上传到公众号。picgo 时，组合封面和正文图片均已上传，文章只引用通过可访问性检查的 HTTPS 图片地址；上传失败时已明确列出待完成项和恢复命令。这是一个计划写一辈子的公众号，持续分享对工作和生活的反思和总结，以文会友，结识有趣的同好。
目标读者是对生活保持好奇和热爱的人群，职场人士、自媒体创作者、泛科技爱好者、效率爱好者、AI 爱好者。他们不一定是技术从业者，但对新事物有开放心态，愿意为有信息量的内容花时间。
写作时始终假设读者是「聪明但不专业」的成年人，不需要手把手教，但技术细节需要用生活化的方式解释。
用产品经理的逻辑拆解问题，用独立开发者的方式验证答案，用普通人的口吻把过程写出来。
关键调性特征：
关于作者声音的具体表现，参阅 references/范文风格分析.md，其中从作者的历史文章中提炼了可复用的写作模式和语言特征。
以下是一些可选的写作技巧，仅供参考，不是穷举。具体文章使用哪些技巧、采用什么结构，由作者在 prompt 中指定。如果作者未指定，根据素材自然选择，宁可不用也不要生硬套用。
回环呼应（契诃夫之枪）：前面埋的每一个细节后面都得响。文章内部要有 callback 结构，前面提到的一个意象、句子或小钩子，在后面以变体形式再次出现。这种前后因果的闭合感，是让文章从「信息流」变成「作品」的关键。
层层剥开的修辞：不是直接讲结论，而是用「现象→表面解释→更深的追问→核心洞察」的方式展开。让读者参与到思考过程中，感受到推理过程，而不是被动接收结论。
英雄之旅叙事弧：先说遇到了什么问题或好奇心，再说怎么一步步去做、踩了什么坑，最后秀出让人「卧槽」的结果。起点必须是一个具体的、读者能代入的困境或好奇，而不是一个抽象的命题。
减少长段落，使用长短句交错的方式增加可读性。可以使用一句话自成一段来制造重点，但慎用。
谨慎使用加粗，仅用于关键观点表达或关键信息。预设读者仅通过标题和加粗的文字，也能理解全篇内容。
技术内容的深度把控：
参考 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 独立执行，不可自评。
逐条核实以下禁令，任何一条未通过都必须修改后再提交：
MP_ARTICLE_IMAGE_MODE 未设置时默认使用 local；已记录本次选择，没有未经授权的云端上传local 模式使用相对 Markdown 图片路径，并提示作者在公众号编辑器中手动上传picgo 模式的图片已上传并通过 HTTPS 可访问性检查；上传失败时保留本地引用并标记为待完成HKR 质检：
这是最重要也是最主观的一层。这一层不是逐项检查，而是以读者的视角通读全文，回答一个核心问题：
「读完这篇文章，我感觉是一个有见识的普通人在认真跟我聊一件打动他的事，还是一个 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. ...