他山学科交叉 公众号文章写作 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条挑战：

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。

验证状态：🔵 待验证