general-article-writer

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 转发块。原有步骤保留为历史参考。 验证状态：🔵 待验证