wechat-article-writer

为他山学科交叉公众号撰写微信文章,包括选择文章类型、套用排版模板、生成配图、转换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_系统性文档/待建维度/写作习惯与风格手册.mdStep 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 山形 logotashan_footer/qrcode_candidate.png80px
他山学科交叉二维码tashan_footer/last.jpg180px
❌ 不用于底部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条挑战:

  1. 理解障碍:文章中哪一段,陌生读者在没有背景知识的情况下,会停下来不知道你在说什么?
  2. 标题-正文一致性:文章标题承诺的核心信息,在正文中是否确实被兑现?还是标题暗示了X,但正文说的是Y?
  3. 最弱段落:哪一段是整篇文章信息密度最低、对读者价值最小的段落?如果删掉它,文章会更好还是更差?

若挑战发现可修复的问题 → 直接修复后再进 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 前必须执行)

  1. 先读 _内部总控/宣发/README.md,根据文章类型选择正确子目录:
    • 科普/科教类(他山学科交叉科教系列)→ 宣发/科普内容/
    • 平台/产品推广类 → 宣发/项目推广/
    • 学术类(论文/arXiv)→ 宣发/学术推广/
    • 社交媒体类 → 宣发/社交媒体/
  2. 文章 Markdown 和 HTML 存入:_内部总控/宣发/[对应子目录]/YYYYMMDD_[文章标题简称]/
  3. _内部总控/宣发/README.md 的对应表格里登记这篇文章(平台/主题/状态/日期)
  4. ⛔ 禁止:将公众号文章存入项目技术文档目录(如 项目群/XXX/docs/
  5. ⛔ 禁止:未读 README 直接假设子目录名称

HTML 完成后告知用户发布步骤:

  1. 用浏览器打开生成的 HTML 文件
  2. 全选(Ctrl+A)→ 复制(Ctrl+C)
  3. 打开 mp.weixin.qq.com 后台编辑器
  4. 粘贴(Ctrl+V)
  5. 填写标题(与文章 H1 一致)
  6. 设置封面图(第一张配图)
  7. 发布


变更记录

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 生成时用普通<p>标签,无品牌色框

修改内容

  • 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。

验证状态:🔵 待验证