---
name: jcm-article-writing
description: 文章写作前的素材整理、大纲协作与金尘马式 AI 干货写作规则加载。用户说“我要写一篇文章”“帮我做这个选题”“先搜素材”“全网搜攻略/教程/资料并保存”“写文章前先整理资料”“调整大纲”“我们讨论一下文章结构”，或提到“AI 干货”“面向小白讲清楚”“写得实用能收藏”“不要太技术要讲人话”时，必须使用本 skill。这个 skill 负责确认选题、明确素材来源、整理素材卡、建立素材索引、把讨论收敛成结果态大纲，并在 AI 干货写作场景下读取公开文风参考；如果用户没有提供保存目录，默认在用户当前项目目录下创建写作工作区，不要把用户生成内容写入 skill 安装目录。
---

# JCM Article Writing

这个 skill 用于把文章写作前的素材、规则和写作方向整理清楚，尤其适合“金尘马式 AI 干货写作”：面向小白、讲人话、解决具体问题，最后交付能收藏、能照着做的文章素材和结构。

核心原则：

- 素材来源必须明确。
- 写作规则必须匹配文章类型。
- 资料整理只保留当前有效结果，不记录讨论过程。
- 大纲协作只保留当前有效结构和约束，不记录来回讨论过程。
- 没有用户明确给出的素材地址时，先问地址，不自作主张。
- 没有用户明确给出的保存目录时，默认使用用户当前项目目录下的 `jcm-article-writing-workspace/articles/`。
- 公开版默认读取本 skill 内的公开参考文件；如果用户有自己的风格文档，可以使用用户当前项目目录下的 `jcm-article-writing-workspace/style/` 保存和读取。
- 不要把用户生成的素材、索引、大纲、初稿、改稿或个人风格文档写入 skill 安装目录。

## 能力边界

本 skill 当前负责：

- 确认文章选题和写作目标。
- 明确本次写作使用的素材来源。
- 根据用户提供的素材地址读取本地资料。
- 按需要进行联网检索并整理资料。
- 生成素材卡和素材索引。
- 基于素材和用户反馈协作生成或更新结果态大纲。
- 在 AI 干货写作场景下读取公开文风参考。
- 为后续大纲、初稿、改稿提供干净素材基础。
- 初稿完成后，在用户确认下做一次基于公开文风参考的独立审稿。

本 skill 不默认完成：

- 直接生成完整成稿。
- 自动进入改稿。
- 自动发布到任何平台。
- 自动选择某个本地目录作为素材来源。
- 在用户未确认前自动启动审稿。
- 做社交媒体传播标注。

如果用户要求大纲、初稿、改稿、配图或发布，可以继续协助，但必须先确认素材来源和输出目标。

## 适用场景

使用本 skill 处理这些任务：

- 用户有一个文章选题，想先整理素材。
- 用户要求搜索攻略、教程、案例或资料并保存。
- 用户提供了一篇笔记、一个目录、一个素材索引或一组链接，希望整理成写作素材。
- 用户已经有素材，想讨论标题、结构、章节取舍、写作角度或大纲。
- 用户要写 AI 干货文章，尤其强调面向小白、讲人话、能实操、有收藏价值。
- 用户正在为 AI 干货文寻找文风、结构、低 AI 味或写作约束资料。

不要用本 skill 处理这些任务：

- 把素材转成社交媒体短内容候选池。
- 发布到 X、公众号、Substack、LinkedIn。
- 整理日记、笔记或任务清单。

## 素材来源规则

进入素材整理、大纲、初稿或改稿前，必须先确认本次使用哪份素材。

素材来源可以是：

- 单篇笔记路径。
- 目录路径。
- 素材索引路径。
- 用户粘贴的原始文本。
- 用户提供的一组链接。
- 用户要求联网检索得到的来源。

如果用户要求基于已有素材写作，但没有明确给出素材地址，必须先问：

```text
这次写作要基于哪份素材？请给我笔记路径、目录路径、素材索引路径，或者直接粘贴原始素材。
```

如果用户要求“全网检索”“先搜素材”“找资料”，这本身就是素材来源，不需要再追问本地素材地址，直接进入检索。

不要自行猜测已有素材来源。

不要默认读取任何本地私人目录。

不要因为标题相似就自动选择已有文件。

## 默认项目工作区

公开版提供默认项目工作区，用来降低普通用户的使用门槛。

默认工作区位置在用户当前项目目录下：

```text
./jcm-article-writing-workspace/
```

这里的 `./` 指用户当前正在工作的项目目录，不是本 skill 的安装目录。如果无法判断当前项目目录，先询问用户希望把写作项目保存到哪里。

默认结构：

```text
jcm-article-writing-workspace/
  articles/
    {选题目录}/
      素材/
        00-素材索引.md
        01-{来源或主题简名}.md
      01-文章大纲.md
      02-文章初稿.md
  style/
    user-writing-style.md
```

使用规则：

- 如果用户提供了保存目录，优先使用用户提供的目录。
- 如果用户没有提供保存目录，默认在用户当前项目目录下创建 `jcm-article-writing-workspace/articles/{选题目录}/`。
- `{选题目录}` 使用选题标题生成，去掉不适合作为文件名的符号，保持简短可读。
- 素材卡默认保存到 `jcm-article-writing-workspace/articles/{选题目录}/素材/`。
- 素材索引默认保存为 `jcm-article-writing-workspace/articles/{选题目录}/素材/00-素材索引.md`。
- 大纲默认保存为 `jcm-article-writing-workspace/articles/{选题目录}/01-文章大纲.md`。
- 初稿默认保存为 `jcm-article-writing-workspace/articles/{选题目录}/02-文章初稿.md`。
- 如果用户想加入自己的文风规则但没有现成路径，默认让用户把规则写入或粘贴到 `jcm-article-writing-workspace/style/user-writing-style.md`。
- 如果默认工作区或子目录不存在，可以直接创建，不需要再次询问。
- 不要在 `skills/jcm-article-writing/` 下创建用户文章项目。

## 执行流程

### 1. 确认写作目标

先确认这次要写什么，以及写给谁。

如果用户已经说清楚选题和目标读者，直接进入下一步。

如果选题不清楚，只问一个问题：

```text
这篇文章的选题标题你想暂定为什么？
```

### 2. 确认素材来源

检查用户是否已经提供素材地址、原始文本或链接。

如果没有，先询问素材来源。

如果用户要求全网检索，先把选题拆成 2-5 个检索方向，再搜索。

常见检索方向：

- 官方功能和产品规则。
- 实操教程和小白步骤。
- 案例、模板、提示词。
- 风险、限制、隐私和常见误区。
- 研究论文或行业背景。

### 3. 读取或检索素材

本地素材按用户给出的路径读取。

联网检索采用“先 Web Search，后 XCrawl”的分层策略：

1. 先用自身 Web Search / 普通网页打开能力检索和读取来源。
2. 如果 Web Search 能搜到结果，也能打开并获得足够正文，就直接基于 Web Search 整理素材，不额外调用 XCrawl。
3. 如果 Web Search 只能看到搜索摘要、打不开正文、正文为空、遇到动态渲染页面、反爬/验证页、脚本片段、登录墙、地区限制，或无法确认关键事实，则升级使用 `xcrawl`。
4. 使用 `xcrawl` 时，优先抓取具体 URL，而不是重新泛搜；输出格式优先用 `markdown`、`summary`、`links`，必要时再用 `json` 抽取结构化信息。
5. 如果 `xcrawl` 仍无法获取正文，要在素材卡或素材索引的「写作注意」里说明：普通 Web Search / XCrawl 分别卡在哪里，当前判断来自搜索摘要、其他交叉来源，还是仍需人工浏览器验证。

联网检索时遵守这些优先级：

1. 官方文档、帮助中心、开发者文档、产品公告。
2. 权威媒体、研究论文、可信行业报告。
3. 高质量个人教程、实践案例、工具指南。
4. 社区讨论只作为补充，不能作为唯一依据。

对会变化的产品功能、价格、入口、模型能力，必须核验最新来源。

不要保存低质量 SEO 拼贴文章。

不要大段复制受版权保护的网页内容。

### 4. 确认或创建保存位置

保存素材卡或索引前，检查用户是否提供保存目录。

如果用户已经提供保存目录，使用用户指定的位置。

如果用户没有提供保存目录，默认创建并使用：

```text
./jcm-article-writing-workspace/articles/{选题目录}/素材/
```

不要因为用户没给保存目录就卡住流程。

### 5. 保存素材卡

每个有效来源保存为一篇 Markdown 素材卡。

文件命名：

```text
NN-{来源或主题简名}.md
```

素材卡 Front Matter：

```yaml
---
created: YYYY-MM-DD HH:mm:ss
title: {素材卡标题}
categories: []
tags: []
source: {来源方}
source_url: {来源链接}
---
```

如果来源是用户粘贴文本或本地文件，`source_url` 可以省略，正文要注明来源类型。

素材卡正文结构：

```markdown
# {素材卡标题}

## 来源信息

- 来源：{来源方}
- 链接：{URL}
- 适用章节：{这条素材适合支撑文章哪个部分}

## 核心信息

用自己的话概括来源内容。不要整段复制网页原文。

## 对选题有用的点

列出这条素材能支撑的判断、步骤、例子或反面提醒。

## 可转化成文章段落

写 1-3 段可直接启发后续写作的中文表达。可以给示例说法，但不要冒充最终成稿。

## 小白操作提示

如果来源适合教程化，整理成步骤、模板或 checklist。不适合教程化时可以省略本节。

## 写作注意

记录来源限制、版本差异、隐私风险、需要二次核验的信息。
```

### 6. 保存素材索引

素材索引用于快速判断后续怎么写，不记录中间讨论过程。

索引文件命名：

```text
00-素材索引.md
```

Front Matter：

```yaml
---
created: YYYY-MM-DD HH:mm:ss
title: {选题}：素材索引
categories: []
tags: []
content_role:
  - 选题
---
```

正文结构：

```markdown
# {选题}：素材索引

## 选题定位

用 2-5 句话说明这篇文章面向谁、解决什么问题、核心切入点是什么。

## 核心写作判断

只保留当前有效判断，不保留被否决的候选。

## 建议行文逻辑

给出适合当前选题的阅读路径。不要写成资料目录。

## 已整理素材

- [[01-...]]
- [[02-...]]

## 可直接复用的模板或清单

如果本选题适合干货写作，整理可收藏、可照抄、可执行的内容。

## 后续动作

说明下一步可以进入大纲、初稿、改稿、配图或发布适配。
```

### 7. 大纲协作阶段

当用户开始讨论标题、结构、章节取舍、写作角度、读者定位或大纲时，进入大纲协作阶段。

大纲协作的目标不是一次性生成完美大纲，而是把素材和用户反馈持续收敛成一份结果态大纲。

执行原则：

- 先读取用户指定的素材索引、素材卡和已加载的写作规则。
- 如果用户已经给出明确方向，直接更新大纲，不要重复追问。
- 每轮用户反馈都要吸收进同一份当前大纲。
- 只保留当前有效标题、定位、结构、写作约束和后续动作。
- 被否决的标题、章节、角度和判断不要留在正文里。
- 不要把讨论过程、修改历史、分歧过程写进大纲，除非用户明确要求。

大纲文件建议命名：

```text
01-文章大纲.md
```

大纲 Front Matter：

```yaml
---
created: YYYY-MM-DD HH:mm:ss
title: {选题或标题}：文章大纲
categories: []
tags: []
content_role:
  - 大纲
---
```

大纲正文至少包含：

```markdown
# {选题或标题}：文章大纲

## 文章定位

说明目标读者、核心问题、文章承诺和不展开的范围。

## 标题

保留当前确认的标题。如果用户明确确认了标题，不要擅自改动。

## 素材双链索引

按用途列出本大纲实际参考的素材卡，方便后续 AI 或人工写作回溯来源。

- {用途}：[[素材卡 1]]、[[素材卡 2]]

## 核心主张

只保留当前有效判断。

## 正文结构

按阅读路径列出章节，每节写清楚要解决的问题、要保留的判断和可用素材。

## 文章可复用组件

只列真正能降低读者行动成本的模板、清单、提示词或流程。不要为了显得“干货”机械堆工具。

## 写作注意

记录用户明确确认或纠正过的标题偏好、语气、表达边界、读者假设和章节取舍原则。

## 后续动作

说明下一步可以进入初稿、继续补素材、改标题或改结构。
```

大纲协作检查：

- 目标读者检查：每一节是否服务目标读者和文章主线。
- 读者负担检查：是否加入了会让目标读者觉得复杂、偏题或暂时用不上的内容。
- 可复用组件检查：模板、清单、提示词是否真的降低行动成本。
- 约束继承检查：用户明确纠正过的标题、格式、语气和结构偏好是否已经写进「写作注意」。
- 素材回溯检查：大纲中的素材双链是否能对应到真实素材卡。

标题协作规则：

- 当用户讨论标题时，不只评价准确性，还要识别用户想要的标题功能：吸引点击、制造利益感、降低门槛、建立身份认同、突出结果承诺等。
- 用户明确确认标题后，不要擅自改字、加空格、改标点或替换表达。
- 主标题（H1 + Front Matter 的 title 字段）默认不在中英文、中文和数字、中文和英文单词之间加空格。例：写「沉淀为skill，让AI替你打工」，不要写「沉淀为 skill，让 AI 替你打工」。正文段落、小标题、代码块仍按一般排版规范加空格。这条偏好的理由是主标题更像标语和传播文本，节奏紧凑、视觉连贯比规范化排版更重要。

暂停点：

大纲确认后先停止，询问是否进入初稿。不要自动从大纲跳到成稿。

### 8. 质量检查

完成后检查：

- 用户指定的素材来源都已处理。
- 用户指定的保存位置已遵守。
- 所有 Markdown 都有合法 Front Matter。
- 素材卡都有来源说明。
- 素材索引中的双链文件名和真实文件名一致。
- 大纲中的素材双链文件名和真实素材卡一致。
- 大纲只保留当前有效结构和判断，没有记录被否决的候选或讨论过程。
- 大纲中的写作注意已吸收用户明确纠正过的偏好和约束。
- 没有大段复制受版权保护的网页内容。
- 明确区分“来源确认的信息”和“从资料中推导出的写作判断”。

## AI 干货写作规则加载

当用户要写 AI 干货文章，尤其出现以下信号时，先加载写作规则：

- 面向非技术小白、AI 小白、普通人。
- 要求讲人话、接地气、不堆术语。
- 要求不拖泥带水、一针见血。
- 要求实用、扎实、能照着上手。
- 要求让读者有收藏欲。
- 要求降低 AI 味、保留真人判断。

优先读取本 skill 内的公开文风参考：

```text
references/writing-style.md
```

如果用户有自己的风格文档、平台规范或写作样本，可以让用户额外提供路径；只有用户明确提供时才读取。

如果用户没有现成风格文档，但希望沉淀自己的文风，默认使用：

```text
./jcm-article-writing-workspace/style/user-writing-style.md
```

当这个文件不存在时，可以在用户当前项目目录下创建一个空模板，让用户后续补充。不要临时猜测私人目录，也不要默认读取本仓库外的任何本地资料。

加载后按“干货小白文”标准判断：

- 不追求大而全，只讲清楚一个细点。
- 每篇解决一个具体问题。
- 优先提供模板、清单、提示词、流程、避坑标准等可收藏内容。
- 术语第一次出现时必须翻译成人话。
- 结构服务理解和行动，不写成百科、说明书或培训课件。
- 改稿时用低 AI 味规则做质检，避免光滑、套路化、虚构读者误解和过度完整。

## 初稿审稿（用户确认后触发）

初稿完成后，主 agent 必须主动问一次用户是否需要审稿。

可以照抄这句问法：

```text
初稿已经写完。要不要让另一个 agent 独立审一稿，按照公开文风规则做一次质检？
```

只有用户明确确认后才进入审稿流程。用户没确认或拒绝，跳过本节。

### 审稿依据

审稿只基于这些材料：

- 当前 skill 的 `references/writing-style.md`。
- 用户提供的素材、素材索引或链接。
- 当前确认的大纲。
- 当前初稿。
- 用户额外提供的风格文档、平台要求，或用户当前项目目录下 `jcm-article-writing-workspace/style/user-writing-style.md` 中已经填写的规则。

不要读取未由用户提供的本地目录。不要把私人知识库、私有样本或其他未公开文件当作默认审稿依据。

### 审稿方式

如果环境支持 sub-agent，可以让另一个 agent 做独立审稿；如果不支持，就由当前 agent 按同一套依据自查，但要明确说明审稿依据来自公开文风参考和用户材料。

审稿 prompt 可按下面结构写：

```text
你是一个独立审稿 agent，不参与本文写作过程。请按下面流程做一次审稿：

1. 读当前初稿：{初稿文件路径或用户粘贴的初稿}
2. 读当前 skill 的公开文风参考：references/writing-style.md
3. 读用户提供的素材、素材索引、大纲和额外风格要求。
4. 按公开文风参考自行判断要审查哪些方向。如果遇到具体路径、产品功能、价格、入口、模型能力等需要核验的信息，要么读用户提供的来源核实，要么在报告里标“待核实”，不要凭推测下结论。
5. 关注但不限于这些大方向：
   - 信息取舍与一篇只讲一件事。
   - 小白可执行性、减负原则、操作准确性。
   - 标题、小标题、开头、结尾是否服务读者行动。
   - 低 AI 味信号：空泛、套路、过度完整、假装共情、虚构读者误解。
   - 排版规范：短段落、清晰列表、术语翻译、中文标点统一。
   - 真人判断、取舍理由和真实限制。
6. 返回结构化报告，格式如下：

   ## 审稿结论
   一句话总体评价。

   ## 必改（命中硬规则）
   - 位置：{小节/段落/句子定位}
   - 命中规则：{公开文风参考中的规则}
   - 建议改法：{具体改法}

   ## 建议改（可商榷）
   - 位置：{...}
   - 问题：{...}
   - 建议：{...}

   ## 可保留的判断点
   如果发现有的地方表面上像问题但实际服务表达，列出来说明，避免主 agent 误改。

报告必须具体到段落或句子，不要泛泛说“风格有问题”。每条问题都要给改法建议，不要只指出问题。
```

### 收到审稿报告后

主 agent 把报告整理成简洁列表给用户看，按“必改 / 建议改”两类区分。

由用户决定哪些落地，不要在用户没确认前就自己改稿。

如果“可保留的判断点”里有内容，主 agent 要复述给用户看，避免误改用户原本的判断。

## 输出给用户

最终回复保持简洁，说明：

- 使用了哪些素材来源。
- 保存到了哪个目录。
- 素材卡数量。
- 覆盖了哪些资料类型。
- 是否有未能核验或需要后续补查的点。

不要在最终回复里粘贴全部素材正文。