---
name: general-article-writer
description: 撰写通用长文（技术分析/产品思考/对外分享/个人随笔），区别于微信公众号文章（公众号请用 wechat-article-writer）。读取写作习惯手册后起草，支持大纲确认、正文撰写、挑战者自检、审稿闭环。当用户说「写一篇技术文章」「写一篇对外分享」「写一篇产品分析/产品思考」「帮我写一篇通用文章/长文」「写一篇个人随笔」时使用。
---

# 通用文章写作 Skill（general-article-writer）

> 关联知识库：`_内部总控/认知结构/L1_系统性文档/待建维度/写作习惯与风格手册.md`（以下简称 WG）
> 与 `wechat-article-writer` 的区别：本 Skill 不做微信 HTML 排版，产出纯 Markdown 草稿

---

## 知识导航表（执行前必须理解的概念根）

| 层级 | 文档 | 需要理解的概念 |
|---|---|---|
| **D0 认知根（必读）** | `_内部总控/认知结构/L1_系统性文档/待建维度/写作习惯与风格手册.md`（暂用 `_内部总控/AI思维碎片/写作习惯与风格手册.md`）| 郑总的写作风格：文章结构偏好/语言风格/禁用表达/标题原则/结语要求 |
| **D3 规范参考** | `.cursor/skills/article-proofreading/SKILL.md`（参考审稿标准，非触发执行）| 五轮审稿标准（写稿时对照，不等到最后才审）|
| **D4 运行时数据** | — | 若用户提供了初稿，直接作为输入；无初稿则从研究/大纲开始 |

**核心概念速查**：
① 先大纲确认再写正文：大纲确认后才能开始写，避免方向偏差导致大量返工
② 挑战者自检 = 写完后以陌生读者视角批判性阅读（「这段话写了什么？论据充分吗？」）
③ 通用长文 = Markdown产出，不做HTML排版（区别于wechat-article-writer）

---

## 触发判断（先执行，不可跳过）

```
IF 用户输入包含「写一篇/帮我写」+ 文章类型关键词（技术/产品/分析/分享/随笔/长文/通用文章）
AND 不含「公众号/推文/他山文章/微信/WeChat」
→ 触发本 Skill

IF 用户说「继续写/补完/下一章」且当前上下文有本 Skill 已生成的草稿
→ 触发本 Skill（进入补全模式，Step 1 识别现有内容，Step 3 直接补全）

IF 不确定是否发公众号（用户提到「分享/对外分享」但未说渠道）
→ 先问「这篇文章是要发到公众号吗？」
  - 是 → 切换 wechat-article-writer，不继续本 Skill
  - 否 → 继续本 Skill

IF 含「SI/补充材料/LaTeX/推导」→ academic-si-writer 优先，不触发本 Skill
```

---

## ⚡ thin wrapper 转发（优先执行）

> 本 Skill 已升级为 document-pipeline 的入口。触发后立即转发，不独立执行。

```
触发后立即执行：
  设置 target_format = md
  设置 mode = article
  转发到 document-pipeline（加载其 SKILL.md，从 Stage 0 开始执行）
```

---

## Step 0：读取 WG（写作习惯与风格手册）— 写稿前必做，不可跳过

```
Read: _内部总控/认知结构/L1_系统性文档/待建维度/写作习惯与风格手册.md

提取以下4类约束（按章节标题找，不是猜测）：
① 核心写作哲学——换位思考（从读者决策链倒推结构）/ 结论先行 / 信息密度
② 语言风格禁忌——AI腔清单 / 防守修饰语 / 套话 / 绝对表达
③ 标题写法规范——结论型/问题型（合法）vs 话题描述型（违规），4种错误类型
④ 段落/结构原则——每段有实质内容，信息密度要求

文件不存在或读取失败时：
  → 告知用户「WG 文件未找到，使用默认约束写作（质量可能下降）」
  → 使用以下默认约束继续执行：
    - 结论前置（每章节结论放在开头）
    - 禁止 AI 腔（不写「核心推论只有一句话」「以下是 N 个要点」等元评论）
    - 禁止绝对表达（避免「一定/必须/完全/最」等）
    - 读者视角（先问读者是谁、关心什么，再决定结构）
```

---

## Step 1：确认文章类型、读者与长度

若用户在触发消息中已明确提供这3项信息 → 直接确认并进入 Step 2，不重复询问。
否则，一次性询问（不分多轮）：

**文章类型（影响结构）：**

| 类型 | 典型场景 |
|---|---|
| A. 技术分析 | 框架对比/系统设计/方案评估/工具调研 |
| B. 产品思考 | 产品设计/商业分析/战略判断/洞察记录 |
| C. 对外分享 | 演讲稿/培训文档/向不了解背景的读者解释某事 |
| D. 个人随笔 | 思考记录/反思/实验性写作（结构自由）|

**同时确认**：
- 目标读者（知识背景、关心的问题）
- 预期长度（500字以内 / 1000字 / 2000字 / 3000字以上）

---

## Step 2：生成大纲（⚠️ 必须等用户确认后才能写正文）

基于 WG（写作习惯与风格手册）「换位思考：从读者决策链倒推结构」生成：

**产出：**
- 文章标题（遵循 WG 标题规范：结论型或问题型，不能是纯话题描述）
- 3-6 个章节标题 + 每章核心论点一句话

**大纲确认逻辑：**
```
用户确认大纲 → 进 Step 3
用户要求调整 → 修改大纲，再次等待确认（最多3轮）
用户否定整体方向 → 返回 Step 1 重新确认类型和目标
超过3轮仍无法对齐 → 请用户用一句话说明「文章的核心主张是什么」，基于此重新生成
```

---

## Step 3：写正文

遵循 Step 0 从 WG 提取的4类约束，同时按文章类型套用结构：

**字数与结构决策（在写之前，基于 Step 1 确认的预期长度）：**

```
预期 ≥ 3000字 → 正文开头先写摘要（2-3句话概括核心主张）
预期 ≥ 1500字 → 正文末尾必须有结语（覆盖全文主题，不只是"总结以上"）
个人随笔 → 结构自由，可无标题章节
对外分享 → 必须有摘要（读者可能只看摘要决定是否继续阅读）
```

**素材缺乏时：**
若用户仅提供主题/标题，无具体素材 → 告知「缺乏具体素材，文章将基于通用认知写作，如需加入具体案例/数据请提供」，等用户确认后继续。需要具体信息时明确告知，不编造。

---

## Step 4：挑战者反思（对应 `.cursor/rules/full-node-audit.mdc` F-022 规则）

以「第一次读这篇文章的陌生读者」视角执行3条挑战：

1. **理解障碍**：哪一段读者在没有背景知识时会卡住？
2. **标题-正文一致性**：标题承诺的核心信息，正文是否确实兑现？
3. **最弱段落**：哪一段信息密度最低？删掉后文章是否更好？

**修复责任：**
```
AI 可自行修复的问题（措辞/结构/逻辑顺序）→ 修复后告知用户改了什么 → 进 Step 5
需要用户提供素材才能修复的问题（缺失数据/案例）→ 列出问题 → 等用户补充 → 进 Step 5
无重大问题 → 输出「内容自检：[轻微问题/可接受弱点]」→ 进 Step 5
```

---

## Step 5：触发 article-proofreading 审稿

```
Read: .cursor/skills/article-proofreading/SKILL.md
按该 Skill 的审稿流程，以 Step 3 输出的完整正文为审稿对象，执行审稿。

检查范围（article-proofreading 负责）：
- AI腔（元评论、防守修饰语、套话）
- 标题是否为结论型（而非话题型）
- 绝对表达是否需要软化
- 结语是否涵盖全文
```

---

## 边界情况处理

| 情况 | 处理方式 |
|---|---|
| 用户提供半成品草稿 | 识别现有类型和结构 → Step 1 确认缺失部分 → Step 3 补全缺失章节 |
| 用户打断写作 | 保留已写内容，重新激活时从中断处继续 |
| 需要配图 | 可单独调用 `article-image-angles`（本 Skill 不生成配图）|
| WG 文件找不到 | Step 0 使用默认约束，告知用户 |

---

## 变更记录

### v1.0 — 2026-03-19 — 初始创建

**根因**：写作体系只有 wechat-article-writer（强绑定微信模板），郑总写通用长文时缺乏结构化入口和 WG 风格约束。

**内容**：
- 触发判断含补全模式触发条件
- Step 0 强制读 WG，定义4类提取约束，含默认 fallback
- Step 2 大纲确认门（含3轮循环 + 否定后返回逻辑）
- Step 3 按字数预判结构（摘要/结语阈值）
- Step 4 挑战者反思（来自 F-022 规则），含修复责任分工
- Step 5 明确读取 article-proofreading SKILL 并执行

**关卡A结论**：4条🔴严重歧义已修复（约束定义/F-022引用/fallback默认值/触发机制）
**关卡C结论**：✅ 通过（7个场景全通过，WG文件存在已确认）
**验证状态**：✅ 已验证


### v1.0 → v1.1 — 2026-03-19 — thin wrapper 化（document-pipeline 统一入口）

**根因**：创建了 document-pipeline 统一写作流水线。general-article-writer 变为入口路由层。
**修改内容**：新增 thin wrapper 转发块。原有步骤保留为历史参考。
**验证状态**：🔵 待验证