# 写作协作规范

这份文档用于统一 `posts` 仓库后续的写作协作方式。

目标很简单：

- 新文章怎么开始
- 草稿怎么管理
- 图片怎么放
- 成品怎么归档
- 我与 AI 后续怎么稳定协作

默认主战场：

- `wechat/`
- `wechat-writer/`

`blog/` 默认作为历史归档区，不纳入重点改造范围。

---

## 一、协作原则

### 1. 主库原则

这个仓库就是总库。

不要再额外创建新的“写作主仓库”。

新文章、方法、选题、草稿、复盘，优先沉淀在这里。

### 2. 公众号优先

后续重点内容阵地是 `wechat/`。

写作时默认考虑：

- 用户能不能看懂
- 开头能不能抓人
- 节奏顺不顺
- 内容是不是既真实又有信息量

### 3. 真实经验优先

优先写这些：

- 真实做过的事
- 真实用过的工具
- 真实踩过的坑
- 真实的学习过程
- 真实的判断变化

不为写而写。

写作是记录，是表达，也是沉淀。

### 4. 说人话原则

哪怕写技术文章，也尽量：

- 少炫技
- 少黑话
- 少只对内行人说得通的表达
- 多讲价值、感受、变化、影响

目标不是把自己写爽。

目标是让更多人愿意读下去。

### 5. 方法要服务内容

不做空心营销号。

但也不排斥这些方法：

- 看热点与微信指数
- 研究爆款结构
- 优化标题与开头
- 调整节奏与排版
- 用更利于传播的表达包装真实内容

原则：

**内容要真，方法要会。**

---

## 二、目录分工

### `wechat/`

用于存放已经成型、可视为正式文章的公众号内容。

建议：

- 一篇文章一个 Markdown 文件
- 文件名尽量直接等于文章标题
- 这里放的是成品，不放研究碎片

### `wechat-writer/drafts/`

用于存放每篇文章的写作过程资产。

建议一篇文章对应一个目录。

示例：

```text
wechat-writer/drafts/AI 写代码，我们开发的意义何在/
```

### `wechat-writer/参考文章/`

用于放风格样本与参考内容。

分三类：

- 我自己写的
- 写作助手协助我写的
- 爆款博主写的

### `images/`

用于放文章配图、证据图、封面图、截图素材。

后续按文章粒度逐步管理。

---

## 三、单篇文章的推荐工作流

建议每篇公众号文章，都按下面这套流程走。

### Step 1：确定选题

先回答 4 个问题：

- 这篇在写什么？
- 为什么现在写？
- 读者为什么会关心？
- 这篇最核心的一句话是什么？

### Step 2：建立草稿目录

在 `wechat-writer/drafts/` 下新建目录。

推荐结构：

```text
wechat-writer/drafts/文章标题/
  ├── 选题卡.md
  ├── 研究笔记.md
  ├── 提纲.md
  ├── 草稿.md
  ├── 定稿.md
  ├── 配图清单.md
  └── 发布复盘.md
```

说明：

- 不一定每篇都要把 7 个文件写满
- 但目录骨架尽量统一
- 统一之后，后续协作、回看、改稿都省事

### Step 3：研究与整理

记录这些内容：

- 事件背景
- 数据、案例、引用
- 自己的经历与观察
- 可以作为证据的截图或链接

### Step 4：提纲与起稿

优先明确：

- 开头怎么抓人
- 中段怎么推进
- 哪些地方要放真实经历
- 哪一句是核心判断
- 结尾准备落在哪个情绪点

### Step 5：人味化与排版

检查：

- 有没有 AI 味太重的段落
- 有没有过于抽象的表达
- 有没有别人看不懂的术语
- 段落是不是适合手机阅读

### Step 6：归档正式文章

当文章稳定后：

- 在 `wechat/` 中保留正式版本
- `drafts/` 中保留过程资产

这样形成：

- `wechat/` 看成品
- `drafts/` 看过程

---

## 四、命名建议

### 文章文件名

默认直接用中文标题。

例如：

```text
wechat/AI 都开始写代码了，我们这些开发，到底还有什么意义？.md
```

### 草稿目录名

默认也用文章标题。

这样最直观。

### 草稿文件名

统一使用这些常见名称：

- `选题卡.md`
- `研究笔记.md`
- `提纲.md`
- `草稿.md`
- `定稿.md`
- `配图清单.md`
- `发布复盘.md`

不要一篇文章里混用太多“终稿-final-最终版-修订版2”这种名字。

容易乱。

---

## 五、图片管理建议

目前 `images/` 还比较松散，后续建议按文章分目录。

推荐结构：

```text
images/
  ├── wechat/
  │   ├── 文章标题或slug/
  │   │   ├── cover.png
  │   │   ├── 01-chat-history.png
  │   │   ├── 02-terminal-success.png
  │   │   └── notes.md
  └── common/
```

图片分几类：

- `cover.*`：封面图
- `01-*.png`：正文配图
- `evidence-*.png`：证据截图
- `draft-*.png`：草稿阶段临时图

原则：

- 一篇文章的图尽量放在同一目录
- 图名尽量能看出用途
- 能作为“证据”的截图优先保留

---

## 六、文章质量的最低要求

后续面向公众号的文章，默认都要过这几关：

### 1. 看得懂

普通读者能跟上，不被术语劝退。

### 2. 愿意读

开头有吸引力，中段不拖，结尾有回响。

### 3. 有真东西

不是拼凑观点，不是空转抒情。

### 4. 有个人痕迹

能看出来这篇是“你写的”，不是模板机写的。

### 5. 适合手机阅读

短段落，清晰停顿，重点突出。

---

## 七、内容取向约定

后续内容重点：

- AI 使用经验
- AI 对工作与生活的影响
- 技术人与普通生活之间的连接
- 更普世、更易读的技术表达
- 个人成长、学习、思考与记录

不追求纯硬核炫技。

哪怕写技术，也尽量写成：

- 为什么值得关心
- 它改变了什么
- 你是怎么理解它的
- 普通人能从中获得什么

---

## 八、AI 协作方式

后续 AI 在这个仓库中的角色，主要是：

- 梳理选题
- 查资料和研究
- 出提纲
- 起草初稿
- 去 AI 味
- 排版优化
- 复盘已有文章
- 维护内容地图与选题池

AI 不负责替代你的真实经历。

AI 的作用，是把你的经历、判断和表达，整理得更清楚、更好读、更稳定。

---

## 九、后续持续优化方向

后面可以逐步继续补：

- 公众号文章模板
- 标题库与开头库
- 系列选题规划
- 已发文章索引
- 爆款样本拆解
- 微信指数或热点跟踪记录

先把基础结构跑顺，再慢慢加细节。

---

## 十、公众号预览 / 可访问地址交付约定

当用户要求“公众号预览”“可访问地址”“直接点击链接”“复制到公众号的页面”时，默认执行以下规则：

1. 预览产物优先放到 `posts/docs/`，并通过现有 Nginx 直接对外访问。
2. 默认同时生成：
   - `文章标题-预览.html`：正文预览页
   - `文章标题-copy.html`：公众号复制页
3. 对用户回复时，默认给当前渠道可直接点击的链接：
   - 使用公网 Nginx 地址
   - 带版本参数 `?v=<commit>` 方便强刷缓存
   - 在 Feishu 里优先使用 markdown 可点击链接
4. 如果用户没有特别说明，`/preview` 或“预览链接”默认两个都给，并把 `预览.html` 放前面；如果用户明确说要复制页，再优先给 copy 页。
5. 固定入口命令：

```bash
cd /home/claw/projects/posts
python3 scripts/preview_wechat_article.py "wechat-writer/drafts/文章标题/定稿.md"
```

默认产物：
- `docs/output/wechat-preview/文章标题-copy.html`
- `docs/output/wechat-preview/文章标题-预览.html`
- 对应 Nginx 可访问地址

这些文件只作为服务器临时访问文件，不作为仓库正式内容提交。

6. 不要把这个需求误解成：
   - 发布到公众号后台
   - 登录公众号草稿箱
   - 给 GitHub/raw 链接代替站内预览链接
6. 如果已有现成 copy 页模板，后续新文章优先复用同一套模板和交互，不再每次临时重造。

## 十一、一句话原则

**写真实的东西。**

**用更好的方法，把它写得更容易被人读进去。**