| name | wechat-article-writer |
| description | 为他山学科交叉公众号撰写微信文章，包括选择文章类型、套用排版模板、生成配图、转换HTML、添加底部模板。当用户说"写一篇公众号文章""帮我写他山文章""写公众号推文""帮我把这篇写完""补全这篇文章""继续写这篇"时使用。写完后自动触发 article-proofreading 审稿。 |
他山学科交叉 公众号文章写作 Skill
知识导航表（执行前必须理解的概念根）
| 层级 | 文档 | 需要理解的概念 |
|---|
| D0 认知根（必读） | _内部总控/认知结构/L0_大脑总地图.md → 找文章主题对应的L1文档 | 先于一切：这篇文章的核心观点在郑总的认知结构里有没有对应的理论根？从认知结构出发写作，不凭空创作 |
| D3 规范参考 | _内部总控/认知结构/L1_系统性文档/待建维度/写作习惯与风格手册.md（暂用 _内部总控/AI思维碎片/写作习惯与风格手册.md） | 他山文章写作风格：语言/标题/结构/禁用套话 |
| D4 运行时数据 | _内部总控/认知结构/L1_系统性文档/待建维度/微信公众号发布手册.md + _内部总控/产品定义/tashan_footer/ | 排版规范（§零/§4.3/§5/§6.1）+ 底部模板 |
核心概念速查：
① 认知根先行：每篇文章都应能追溯到某个L1文档或L1.5原则，否则是「漂浮写作」
② 他山风格 = 学术性洞见 × 可读性 × 有共鸣（不是科普，不是观点贩卖）
③ 审稿在发布前强制执行（article-proofreading），不可省略
详细参考资源
- 排版规范：
_内部总控/认知结构/L1_系统性文档/待建维度/微信公众号发布手册.md（⚠️ §零 核心原则、§4.3 底部模板、§5 发布前核查、§6.1 Python vs 直接编辑）
- 写作风格：
_内部总控/认知结构/L1_系统性文档/待建维度/写作习惯与风格手册.md ← Step 0 必读
- 历史文章样本：
项目群/feed-archiver/output/wechat/他山学科交叉/
- 底部模板资源：
_内部总控/产品定义/tashan_footer/
- 排版核查脚本：
C:/Temp/check_html.py（15项自动验证，完成HTML后必跑）
⚡ thin wrapper 转发（优先执行）
本 Skill 已升级为 document-pipeline 的入口。触发后立即转发，不独立执行原有 Step 1-8。
触发后立即执行：
设置 target_format = html
设置 mode = article
转发到 document-pipeline（加载其 SKILL.md，从 Stage 0 开始执行）
说明：所有写作逻辑已迁移到 document-pipeline，包括：
- 写作风格手册读取（document-pipeline Stage 1）
- 配图生成（document-pipeline Stage 5）
- HTML 转换（document-pipeline Stage 8A）
- 审稿（document-pipeline Stage 7）
本文件中 Step 0-8 保留为历史参考，不再执行。
⚙️ 文章发布后（thin wrapper 收尾步骤，CP1 修复）：
文章完成后，提示：
「📚 文章中是否包含原创洞见或新方法论（非仅梳理外部信息）？
如有，建议触发 cognitive-capture-fragment 将核心观点记录为 L2 碎片。
[记录核心洞见] [跳过，文章以信息整理为主]」
IF 用户选「记录」→ 触发 cognitive-capture-fragment
IF 用户选「跳过」→ 静默完成
Step 0：读取写作习惯与风格手册（写稿前必做）
Read: _内部总控/认知结构/L1_系统性文档/待建维度/写作习惯与风格手册.md
提取并在本次写作中执行：
1. 核心写作哲学（第一章）：换位思考 / 结论先行 / 信息密度原则
2. 语言风格禁忌（AI腔、防守修饰语、套话清单）
3. 标题写法规范（4种错误类型）
4. 与本次文章类型最相关的结构原则
⚠️ 不允许用 Step 3 中的内联摘要替代真实读取。WG 会随时间更新，
每次写作必须读最新版本。
执行模式判断（CN-004 Gap 修复）
IF 用户提供了现有草稿（粘贴了部分内容 / 说「帮我把这篇写完」「补全」「继续写」）：
→ 进入「补全模式」
→ Step 1：理解现有草稿的文章类型、核心主题、已有结构
→ Step 2：识别草稿缺失的部分（未完成的章节、缺少的结语等）
→ Step 3：以与现有内容一致的风格和语气补全缺失部分
→ Step 4-8：继续走正常流程（配图/HTML/审稿/发布）
→ 注：补全模式下不重新选择文章类型，以现有草稿的类型为准
ELSE（从零开始写新文章）：
→ 执行 Step 1 的正常流程
Step 1：确认文章类型
问用户文章属于哪种类型（影响结构模板）：
| 类型 | 触发词 | 结构特征 |
|---|
| 科教类 | 科普、技术解析、研究报告 | 摘要+字数+01/02章节+引用 |
| 活动预告类 | 预告、报名、即将举办 | 封面+摘要+日程+报名方式+单位 |
| 活动回顾类 | 回顾、收官、总结、圆满 | 封面+综述+图片+嘉宾+奖项 |
| 动态类 | 动态、招新、合作、进展 | 封面+摘要+项目介绍+图片 |
Step 2：套用结构模板
根据类型选择模板：
科教类模板
# 他山学科交叉科教｜[主题]
内容摘要
1、**关键点A**
2、**关键点B**
3、**关键点C**
**（全文约X字，阅读时间约Y分钟）**
\
**01**
[章节一标题]
\
[正文内容，关键词加粗，换行用 \ ]
**02**
[章节二标题]
...
活动预告类模板
# [栏目]｜[活动名]：[副标题]
[封面图占位]
内容摘要
"[一句话总结]"
\
**01**
活动亮点
✅ [亮点一]
✅ [亮点二]
**02**
活动详情
📅 时间：
🏫 地点/主讲：
📡 形式：线下｜[地点] + 线上｜视频号直播
🎯 内容：
**03**
[报名/参与方式]
📢 报名方式：[说明]
\
组织单位
\
指导单位：[列出]
承办方：[列出]
活动回顾/动态类模板
# [标题]
[封面图占位]
内容摘要
[1-3条要点]
\
[正文，图文穿插，图片用占位说明]
\
出品 | 他山AI宣讲团
文字 | [作者]
图片 | [作者]
美编 | [作者]
责编 | 王瑞
Step 3：写正文
遵循 Step 0 从 WG 中提取的风格约束，以及以下他山公众号专项规范：
- 读者定位：科研学生，关心AI+科研的实际应用，不是业内专家
- 图文说明：每张图下方写一行说明文字
- 字数目标：科教类 2000-4000 字；预告/回顾类 800-2000 字
- WG 约束优先：语言风格、标题写法、段落结构以 Step 0 读取的 WG 为准，本节仅补充公众号专项规范
Step 3.5：建立配图索引（写完正文后立即执行）
每篇文章在转换 HTML 之前，必须在手稿同目录下创建配图索引文件：
路径：[手稿所在目录]/配图索引_[文章名].md
模板：.cursor/skills/wechat-article-writer/templates/配图索引模板.md
索引结构（每张图一个条目）：
| 图片文件 | 对应段落（行号/小节） | 段落核心主旨 | 提示词摘要 | 状态 |
|---|
| xxx.png | §X.X 行N-M | [主旨] | [提示词] | 🔲/✅/⚠️ |
文字↔配图联动规则（必须遵守）：
改文字时：查配图索引 → 找受影响段落 → 对应图标注「⚠️ 需重绘」
发现图有问题时：查配图索引 → 找对应段落 → 检查文字是否也需调整
新增图片时：立即追加索引条目
删除图片时：条目标注「已删除」，不删行
图片选定确认时：状态改为「✅」，同步清理手稿中的 A/B 待选格式
⛔ 禁止：在没有配图索引的情况下，修改任何有配图的段落——因为你看不到"哪些图需要联动更新"。
Step 4：生成配图
调用 ai-image-generator Skill（.cursor/skills/ai-image-generator/SKILL.md），包含完整的 API、多视角流程、风格库、配图索引联动。
微信文章特有补充：
- 提示词固定前缀：
简洁专业的信息图，适合微信文章，白色背景。
- 风格统一用 S03（
图片风格库.md），保持全文一致
- ASCII 结构框图必须用图片替换，纯文字 pre 块可保留
Step 4.5：Markdown 真源原则（每次修改前必读）
Markdown 手稿是唯一真源。HTML 是它的微信排版版。
实际工作流：用户从 MD 复制内容粘贴给 AI → AI 修改 MD → AI 同步 HTML。
MD 必须始终等于用户读到的内容，否则这个工作流断裂。
每次内容修改的操作顺序：
1. 先改 Markdown 手稿（用户的真源）
2. 在手稿底部追加变更记录（格式见发布手册 §零.1）
3. 同步修改 HTML（直接 StrReplace，不重跑 Python 脚本）
4. 运行 python C:/Temp/diff_check.py → 必须 0 处不一致
5. 运行 python C:/Temp/check_html.py → 必须 15/15
⛔ 禁止：直接改 HTML 内容而不同步到 Markdown
⛔ 禁止：改完 HTML 后不运行 diff_check 验证
⛔ 禁止：格式/样式改动时修改 Python 脚本（HTML 是真源，脚本是历史工具）
Step 5：转换为微信 HTML
参照 _内部总控/AI思维碎片/微信公众号发布手册.md §2 HTML 规范：
关键样式（完整版）：
- body:
font-size: 17px; line-height: 1.9; color: #333; max-width: 677px
- H2:
color: rgb(111,167,170); border-left: 4px solid rgb(111,167,170); padding-left: 12px（品牌蓝绿色，不是 #333）
- 关键 H3（最核心的小节）:
style="color: rgb(111,167,170)"
- strong:
font-weight: bold; color: #1a1a1a（加粗但不染色，绿色只给标题）
- 协会简介:
font-weight: bold; color: rgb(111,167,170)（去掉 <strong> 标签，在 <p> 上加样式）
- 表格:
border-collapse: collapse，奇偶行交替颜色
- 图片:
base64 嵌入，max-width: 100%; border-radius: 8px
- hr:
border-top: 1px dashed #b0d4d6
- blockquote:
background: #f9f9f9; border-left: 4px solid #b0d4d6
- 摘要框（内容摘要块）:
background: #f9f9f9; border-left: 4px solid rgb(111,167,170); padding: 16px 20px; margin: 0 0 32px;，摘要框标题「内容摘要」用 color: rgb(111,167,170); font-weight: bold; font-size: 14px; letter-spacing: 1px
绿色用量控制：全文绿色（rgb(111,167,170)）不超过 15 处。仅用于：H2 标题、核心 H3、底部署名标签、协会简介、二维码提示文字。
修改方式：文字/样式改动直接 StrReplace HTML 文件。⛔ 禁止文字改动时同步改 Python 脚本（Python 脚本仅用于重新生成图片时）。
⛔ 禁止：为文字/样式改动重新运行 HTML 生成脚本（Python 脚本仅用于重新生成图片时）
→ 文字/样式改动应直接用 StrReplace 工具修改 HTML 文件
Step 6：添加底部模板
底部完整 HTML 模板见发布手册 §4.3，严格按该模板执行，包含：署名 → 分隔线 → TA SHAN logo → 协会简介 → 二维码 → 官网说明。
底部图片资源（⚠️ 文件名与用途相反，记用途不记文件名）：
| 用途 | 文件 | HTML 宽度 |
|---|
| TA SHAN 山形 logo | tashan_footer/qrcode_candidate.png | 80px |
| 他山学科交叉二维码 | tashan_footer/last.jpg | 180px |
| ❌ 不用于底部 | tashan_footer/logo_candidate.png | — |
署名格式：
个人思考类（郑博元）：署名标签用 color: rgb(111,167,170)
核心观点 | 郑博元
写作 | 他山AI分身系统
编辑 | 他山AI分身系统
团队产出类：
出品 | 他山AI宣讲团
文字 | [作者] / 图片 | [作者] / 美编 | [作者] / 责编 | 王瑞
Step 6.5：双重核查（HTML 发布前必做）
三层发布前质检说明：完整的发布前质检分三层——Layer1 内容质检（Step 6.8 + Step 7），Layer2 HTML格式核查（本步骤 Step A），Layer3 品牌规范合规（本步骤 Step B）。三层缺一不可，顺序：先 Layer2/3（格式先行），再 Layer1（内容审稿）。
Step A 运行：python C:/Temp/diff_check.py
→ 0 处不一致才继续（MD 与 HTML 内容完全对齐）
Step B 运行：python C:/Temp/check_html.py
→ 15项全部 [OK] 才可进入 Step 7
任何 FAIL/不一致 → 必须先修复，不可跳过。
核查覆盖：
- diff_check：标题/摘要/各章节关键句/措辞一致性（MD vs HTML）
- check_html：ASCII残留、图片数量、绿色用量、strong颜色、H2绿色、底部完整性、署名等
Step 6.8：【F-022 全节点挑战者反思】内容完稿后、审稿前执行
这是写作节点的内置小闭环审核，与 Step 7 article-proofreading（独立审核者大闭环）互补，不替代。
以「第一次读这篇文章的陌生读者」视角执行3条挑战：
- 理解障碍：文章中哪一段，陌生读者在没有背景知识的情况下，会停下来不知道你在说什么？
- 标题-正文一致性：文章标题承诺的核心信息，在正文中是否确实被兑现？还是标题暗示了X，但正文说的是Y？
- 最弱段落：哪一段是整篇文章信息密度最低、对读者价值最小的段落？如果删掉它，文章会更好还是更差？
若挑战发现可修复的问题 → 直接修复后再进 Step 7
若无重大问题 → 输出「内容自检：[具体轻微问题/可接受的弱点]」，继续 Step 7
Step 7：审稿
文章写完后，自动触发 article-proofreading skill，检查：
- AI腔（元评论、防守修饰、套话）
- 标题是结论还是话题描述
- 绝对表达软化
- 结语是否涵盖全文
Step 7.5：审稿意见追踪（用户反馈后立即执行）
触发条件：用户对文章内容/排版/图片提出任何修改意见时。
执行操作：
1. 在文章手稿同目录下创建审稿意见文件：
路径：[手稿所在目录]/审稿意见_[文章名].md
模板：.cursor/skills/wechat-article-writer/templates/审稿意见模板.md
2. §零「用户原始审稿意见」：逐条记录用户原话（引用格式，原封不动）
⛔ 禁止：只记录 AI 的解读/提炼，丢失原话
⛔ 禁止：把多条意见合并成一条
3. §一至§五：将每条原意见拆解对应到处理条目，标注状态
4. 每次执行修改后，回到审稿意见文件更新对应行的状态
格式要求：
- §零（原文）：逐条，引用块（
>），编号，原话不改
- §一至§五（对应条目）：表格，
对应原意见 列指向 §零 的意见编号
- 状态必须准确：✅ 已完成 / 🔲 待处理 / 🖼️ 待选图 / 🔁 待重绘 / ⚠️ 执行有偏差
⚠️ 易错点：
- R-02（图片风格）：「建立风格库」≠「生成10种风格变体」。规则要求对每张图实际生成10种风格让用户选，不是只建文档
Step 8：发布指引
输出文件存放规范（Step 8 前必须执行）：
- 先读
_内部总控/宣发/README.md，根据文章类型选择正确子目录：
- 科普/科教类（他山学科交叉科教系列）→
宣发/科普内容/
- 平台/产品推广类 →
宣发/项目推广/
- 学术类（论文/arXiv）→
宣发/学术推广/
- 社交媒体类 →
宣发/社交媒体/
- 文章 Markdown 和 HTML 存入：
_内部总控/宣发/[对应子目录]/YYYYMMDD_[文章标题简称]/
- 在
_内部总控/宣发/README.md 的对应表格里登记这篇文章（平台/主题/状态/日期）
- ⛔ 禁止：将公众号文章存入项目技术文档目录（如
项目群/XXX/docs/）
- ⛔ 禁止：未读 README 直接假设子目录名称
HTML 完成后告知用户发布步骤：
- 用浏览器打开生成的 HTML 文件
- 全选（Ctrl+A）→ 复制（Ctrl+C）
- 打开
mp.weixin.qq.com 后台编辑器
- 粘贴（Ctrl+V）
- 填写标题（与文章 H1 一致）
- 设置封面图（第一张配图）
- 发布
变更记录
v1.3 — 2026-03-19 — 强制读取 WG + 修复参考路径
根因：Step 3 内联了 WG 摘要（3行），不读取实际文件，导致 WG 更新后写作风格脱节；同时认知结构重组后 WG 路径已变更（AI思维碎片/ → 认知结构/L1_系统性文档/待建维度/），路径失效。
修改内容：
- 新增：Step 0「读取写作习惯与风格手册」——每次写稿前强制 Read WG，提取4类约束
- 修改：参考文档列表路径 → 更新 WG 和 WX 的正确认知结构路径
- 修改：Step 3 → 简化为「以 Step 0 WG 约束为准，本节仅补充公众号专项规范」
验证结果：
- 正向验证：下次写作任务触发时，AI 应在 Step 1 之前执行 Read WG（待真实场景验证）
- 负向验证：Step 4-8（配图/HTML/排版/审稿）流程不变
验证状态：🔵 待验证
v1.2 — 2026-03-19 — F-022全节点审核：加入写作节点挑战者反思（Step 6.8）
根因：F-022原则（全节点审核机制）要求每个生产节点内置挑战者视角。文章写作节点在 article-proofreading 触发前缺少内置小闭环自检。
修改内容：
- 新增：Step 6.8「F-022 全节点挑战者反思」——3条读者视角挑战（理解障碍/标题一致性/最弱段落）
验证结果：- 正向验证：下次写完文章后，Step 6.8 应输出具体的自检结果（待验证）
- 负向验证：Step 7 article-proofreading 流程不变
验证状态：🔵 待验证
v1.2 — 2026-03-20 — 新增 Step 7.5 审稿意见追踪
根因：两轮审稿后发现：第一轮记录只有 AI 解读，没有保留用户原话，第二轮用户重新发原文说「请原封不动记下来」。Skill 里完全没有「审稿意见追踪」步骤，也没有规定格式。
修改内容：
- 新增：Step 7.5「审稿意见追踪」——触发条件、文件创建、§零原话保留规则、各节格式要求
- 新增：模板文件
templates/审稿意见模板.md
- 新增：⚠️ R-02 易错点说明（建风格库 ≠ 生成10种变体）
验证结果：
- 正向验证：下次用户给审稿意见时，AI 应主动创建审稿意见文件，§零 保留原话
- 负向验证：Step 7（article-proofreading）流程不变
验证状态：🔵 待验证
v1.1 — 2026-03-19 — 五处实战踩坑修复
根因：首次完整执行 wechat 文章发布流程，发现五处 Skill 落后于实际规范：①颜色规范错误 ②图片文件名描述混淆 ③缺少 Markdown 真源原则 ④缺少 ASCII 替换规则 ⑤缺少排版核查步骤。
修改内容：
- 修改：参考文档列表 → 精确指向发布手册关键章节，新增核查脚本路径
- 新增：Step 4.5「Markdown 真源确认」——内容改动必须先改手稿
- 修改：Step 4 → 明确图片文件名、飞轮图用双侧版、ASCII 替换原则
- 修改：Step 5 → 完整颜色规范（H2/H3/strong/协会简介各自的正确颜色）、修改方式规则
- 修改：Step 6 → 图片文件名易混淆警告、完整表格、引用 §4.3 模板
- 新增：Step 6.5「排版核查」——15项核查脚本，全通过才能发布
验证结果：
- 正向验证：下次写文章时，按新 Step 4.5-6.5 执行，预期不再出现颜色错误/图片混淆/ASCII残留
- 负向验证：Step 1-3（选题/模板/写作）和 Step 7-8（审稿/发布）流程不变
验证状态：🔵 待验证（下次真实任务时验证）
v1.0.1 — 2026-03-19 — 加入补全模式 + 触发词扩充（CN-004 Gap 修复）
根因：CN-004 沙盘发现：用户提供半成品草稿说「帮我把这篇写完」时，Skill 的触发词（只有「写一篇」类）不覆盖此场景，且原有8步流程从选题开始，无法处理「已有草稿的补全」路径。
修改内容：
- 修改：description 触发词 → 新增「帮我把这篇写完」「补全这篇文章」「继续写这篇」
- 新增：「执行模式判断」章节——补全模式（识别已有草稿→补全缺失部分→走后续步骤）vs 全新写作模式
验证结果：
- 正向验证：用户粘贴半成品文章说「帮我把这篇写完」→ 进入补全模式，不从零开始选题
- 负向验证：用户说「写一篇公众号文章」→ 进入正常全新写作流程，Step 1-8 不变
验证状态：🔵 待验证
v1.4 → v1.5 — 2026-03-20 — 三处规范补全（推文项目复盘）
根因：本次 OpenClaw 推文全流程中，三处规范空白导致反复返工：
① Step 5 未禁止重跑Python，导致 StrReplace 修正被反复覆盖（H2颜色反复错误）
② Step 8 无输出路径规范，导致文章存入项目技术文档目录而非宣发目录
③ Step 5 摘要框样式未写入，导致 AI 生成时用普通
标签，无品牌色框
修改内容：
- Step 5：补充「⛔ 禁止重跑Python脚本」约束
- Step 5：补充摘要框样式规范（background+border-left品牌绿+padding）
- Step 8：前置「输出文件存放规范」，要求先读 README 按文章类型选子目录，禁止存入项目目录；禁止未读 README 直接假设子目录（原版本错误写死
科普内容/，已修正）
验证方法：下次写公众号文章时，检查：①颜色修正只用StrReplace②文章保存在宣发目录③摘要框有品牌色框
验证状态：🔵 待验证
验证记录（2026-03-20）：Step 8 输出路径规范首次真实验证通过。文章「Agent自迭代与认知透明」正确存入 宣发/科普内容/（科教类前缀），目录选择正确，上次错误未复现。验证状态：✅
| 类型 | 标题前缀 |
|---|
| 科教 | 他山学科交叉科教｜ |
| 协会动态 | 他山动态｜ 或 他山动态 （两空格） |
| 招新 | 他山招新 |
| 活动预告 | 活动预告｜ 或 课程预告 |
| 活动回顾 | 直接描述事件，无前缀 |
v1.5.1 — 2026-03-21 — 首次完整验证（thin wrapper → document-pipeline 全流程）
验证场景：2026-03-21 写作推文《认知外化之后，两个并列的核心价值》
验证结果：
- ✅ thin wrapper 转发 document-pipeline 正常（target_format=html）
- ✅ Step 0 读取写作风格手册正常（WG 提取4类约束）
- ✅ Step 6.8 F-022 挑战者反思执行（识别出标题/最弱段落问题）
- ✅ article-proofreading 触发并执行（识别4处P0，直接修复）
- ✅ 底部模板（logo + 二维码 + 协会简介）完整嵌入 HTML
- ⚠️ 发现偏差：Stage 7（审稿）先于 Stage 4-6（画图）执行，已在 document-pipeline v1.8 中修复
验证状态：✅ 已验证（含一处偏差已修复）
v1.4 → v1.5 — 2026-03-22 — Step 6.5 前补三层质检架构说明（GAP-CN008-1 修复）
根因：scenario-sandbox-builder Phase 2 验证（CN-008沙盘）发现：wechat-article-writer 的三层发布前质检（Layer1内容/Layer2HTML/Layer3品牌）虽然步骤都存在，但未在文档中明确声明三层架构和执行顺序，导致孤立看 article-proofreading 时误以为它是唯一质检层。
修改内容：
- 新增：Step 6.5 前的「三层发布前质检说明」注释块，明确 Layer1/2/3 分别对应哪个步骤，以及正确执行顺序（先 Layer2/3 格式，再 Layer1 内容）
- 备份路径：
history/SKILL_v1.4_20260322_before_cn008.md
验证方法：用户/AI 阅读 wechat-article-writer 时，应能直观看到三层质检架构
验证状态：🔵 待验证
v1.3 → v1.4 — 2026-03-19 — thin wrapper 化（document-pipeline 统一入口）
根因：创建了 document-pipeline 统一写作流水线。wechat-article-writer 变为入口路由层，触发后转发到 document-pipeline 执行，不再独立运行 Step 0-8。
修改内容：
- 新增：thin wrapper 转发块（在 Step 0 之前）
- 原有 Step 0-8 保留为历史参考
验证方法：用户说「写一篇微信文章」时，AI 加载本 Skill，读到 thin wrapper 块，转发到 document-pipeline。
验证状态：🔵 待验证
