| 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条挑战：
- 理解障碍：哪一段读者在没有背景知识时会卡住？
- 标题-正文一致性：标题承诺的核心信息，正文是否确实兑现？
- 最弱段落：哪一段信息密度最低？删掉后文章是否更好？
修复责任：
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 转发块。原有步骤保留为历史参考。
验证状态：🔵 待验证
