Writing Pipeline

内容再创作管线。三个阶段：Draft → Review → Publish。

Stage 1: Draft（生成初稿）

步骤

CODEBLOCK0

2. 保存参考材料（含 comment/highlight）

将用户提供的参考资料保存到 references/ 子目录。

comment 机制（新增，必做）：
- 若参考资料存在行内评论 sidecar（如 references/*.comments.json），必须一并保存，不可丢失。
- 评论中带有 highlight 的片段视为“强信号素材”，在 Stage 1 写初稿时必须优先吸收。
- 先生成一份素材提炼清单 references/reference-notes.md，按如下结构整理：
- must-include：被 highlight 的原句/要点（后文必须落入初稿）
- angle：评论给出的写作角度、争议点、可展开问题
- evidence：可直接引用的数据、案例、事实
- avoid：评论中明确标注不建议采用的表达

X/Twitter 链接处理： 如果参考材料中包含 x.com 或 twitter.com 链接，使用 deepreader skill 抓取推文内容（FxTwitter API，无需 API key），保存为 references/tweet-{id}.md。用法：
CODEBLOCK1

3. X 搜索：查询相关事实与事件

用 x_search 搜索与参考材料相关的关键词、人物、事件，获取最新信息： - 从参考材料中提取 2-3 个核心关键词 - 调用 x_search 查询，收集近期相关讨论、事实、数据 - 将搜索结果摘要保存到 references/x-search-results.md - 生成初稿时将搜索结果作为补充上下文，确保内容基于最新事实

4. 自动路由：匹配写作风格

分析输入材料的特征，匹配最合适的 writing-style skill：

CODEBLOCK2

路由规则（按优先级）：
1. 用户明确指定 style → 直接使用
2. 未指定 → AI 分析材料特征，与每个 style skill 的 routing metadata 匹配
3. 选择匹配度最高的 skill，向用户确认后加载

匹配矩阵：

| 输入特征 | → 推荐风格 |
|----------|-----------|
| 技术论文、产品发布、AI 模型 | writing-style-huasheng |
| 创业故事、人物传记 | writing-style-huasheng |
| 方法论、工具教程、how-to | writing-style-baoyu |
| AI 工具评测、写作技巧 | writing-style-baoyu |
| 哲学思辨、人生设计、意义探讨 | writing-style-dankoe |
| 跨领域框架、自我提升、身份探讨 | writing-style-dankoe |
| 长文摘要、知识提取、结构化转述 | writing-style-zhengliu |
| 表达欲过强的文章、信息提取困难 | writing-style-zhengliu |

路由分析流程：
CODEBLOCK3

5. 选题讨论（必做，不可跳过）

提供 3-4 个选题方向，每个包含：

CODEBLOCK4

标题原则——共鸣式标题：
标题的目标不是概括内容，而是说出读者心里那句没说出口的话。
找到目标读者普遍存在但很少被说清楚的困惑/痛点/感受，用一句话替他们问出来。
读者看到标题的反应应该是"对！我也是这样！"→ 然后点进来。

其他规则：
- 每个选题的角度必须明显不同，不能是同一个思路换个说法
- 等用户选择后再进入下一步，不要自行决定
- 用户可以选某个选题、混合多个选题、或提出全新方向

6. 生成初稿（reference + comment 联合驱动）

用户确认选题后，加载匹配的 writing-style skill，基于 references/ 与 references/reference-notes.md 联合生成初稿，保存为 draft-v1.md。 - 硬约束：所有 must-include（highlight 片段）必须在初稿中被明确吸收（可改写措辞，但核心信息不能丢） - 若某个 highlight 与其他证据冲突，必须在文中给出说明，且在草稿末尾加“冲突说明”小节 - 如有多轮风格迭代，按 draft-v0.md、draft-v1.md、draft-v2.md 递增保留各版本 - 初稿完成后，必须立刻复制最新 draft 为 final.md，供用户直接在终稿编辑器中改稿（cp draft-vN.md final.md） - 若 final.md 已存在且非空，不覆盖；仅在缺失或空文件时执行复制

7. 提取观点与生成信息图（可选，也可在 Stage 2 后执行）

a. 加载 viewpoint-extractor skill，从初稿中提取 3-5 个核心观点 b. 保存 viewpoints.yaml 到文章目录 c. 加载 infographic-gen skill，为每个观点生成信息图 d. 输出到 INLINECODE36

> 此步骤可推迟到 final.md 完成后再执行，用终稿提取的观点更准确。

8. 写入元数据

创建 README.md： CODEBLOCK5

状态字段约束（必须遵守）
- 仅允许：draft / reviewed / ready / published / deprecated
- 禁止写自定义状态（例如 draft-generated），前端状态徽章不会识别

参考资料 comment 文件约定（新增）

- references/*.comments.json 视为参考资料的 sidecar 评论文件，存储高亮与讨论线程。
执行 Stage 1/2/3 时，不要删除或覆盖这些 sidecar 文件。
写初稿时必须优先读取 sidecar 中的 highlight 与 comment，再结合原文 reference 生成内容。
若缺失 sidecar 但用户明确说“我做了高亮/评论”，先在 references/reference-notes.md 记录该缺口并提示补充。

文章目录结构

CODEBLOCK6

Stage 2: Review（人工改稿 + 学习）

前置条件

用户已将改稿保存为 INLINECODE47

如果改稿在前端完成，目录中可能存在 final.comments.json（终稿行内评论数据）。该文件用于编辑协作，不参与平台分发。

步骤

1. 执行 Diff-and-Learn

详见 INLINECODE49

2. 生成差异分析

将分析结果保存为 INLINECODE50

3. 提议 Skill 更新

根据差异分析，提出对应 writing-style skill 的更新建议： - 新增的禁止项 - 需要调整的风格要点 - 新发现的偏好规则

必须先向用户确认后再执行更新

4. 更新元数据

将 README.md 中 status 改为 INLINECODE53

文件约定（重要）

- final.comments.json 是 final.md 的 sidecar 文件，存储 inline comment 线程。
执行 Stage 2 / Stage 3 时，不要删除或覆盖 final.comments.json。
多平台输出只读取正文（final.md），不要把评论内容写入平台文案。
复制/迁移文章目录时，建议连同 final.comments.json 一并保留，避免评论线程丢失。

Stage 3: Publish（多平台输出）

步骤

1. 读取终稿

加载 final.md（如无则用最新 draft）

2. 原文图片统一上传 R2 并回写终稿（必做）

- 扫描文章目录下图片资产（至少包含 images/，可扩展到其他本地图片目录） - 用 r2-upload skill 批量上传，生成 output/r2-image-mapping.json（相对路径 → R2 URL） - 将 final.md 里的本地图片路径统一替换为 R2 URL - 若原文图片较多（例如案例集），在 final.md 里补充“原文图集”章节，确保可直接复用

3. 选择目标平台

让用户选择输出平台（可多选）： - 微信公众号 (wechat) - 小红书 (xiaohongshu) - 即刻 (jike) - 推特 (twitter) - 博客 (blog)

4. 加载 Formatter 并生成

对每个目标平台，加载 projects/writing/formatters/{platform}.md，按规则生成格式化内容。 - 小红书：额外加载 xiaohongshu-editor-pick skill 生成编辑推荐语风格的发帖文本，并必须运行 xiaohongshu-cards skill 生成文转图卡片（小红书是图文平台，卡片是必做输出）

5. 保存输出

按平台分目录保存到 output/{platform}/： - blog/article.md - wechat/article.md - xiaohongshu/text.md（发帖文本） - jike/article.md - INLINECODE78

6. 插入信息图到全平台文章（如 output/infographics/ 存在且非空，必做）

信息图必须插入到每个平台文章的对应内容段落位置（不是堆在末尾）。
根据信息图的 slug 和 viewpoints.yaml 中的 title，找到文章中对应的章节，在该章节标题前插入。

上传：
- 用 r2-upload skill 批量上传 output/infographics/ 到 R2，获取 R2 URL
- 用 wechat-upload skill 批量上传到微信素材库，获取 mmbiz.qpic.cn URL
- 按文件名顺序记录 R2 URL 和微信 URL 的对应关系

插入（全平台，每个都要做）：
- blog：![alt](R2 URL) 插入到对应段落前
- wechat：![alt](mmbiz URL) 插入到对应段落前。微信不支持外链图片，必须用微信素材库 URL
- jike：📊 R2 URL 纯文本行，插入到对应段落前（即刻是纯文本平台）
- twitter：📊 R2 URL 纯文本行，插入到对应段落前
- xiaohongshu：见步骤 8 的小红书卡片生成流程（信息图嵌入卡片图片中）

7. 微信图片链接替换（当目标平台包含 wechat 时，必做）

- 用 wechat-upload skill 批量上传文章图片（至少包含 images/ 与 output/infographics/） - 保存映射到 output/wechat/image-mapping.json（相对路径/R2 URL → {media_id, url}） - 将 output/wechat/article.md 中所有图片链接替换为微信素材库 URL（mmbiz.qpic.cn） - 校验：output/wechat/article.md 不得残留 R2/GitHub 等外链图片 URL

8. 生成图片资产（必做）

- 微信封面（必做）：用 wechat-cover skill → output/wechat/cover.jpg - 默认风格：Claymation 3D mascot + flat UI mockup（详见 wechat-cover SKILL.md） - prompt = 默认风格前缀 + 文章主题描述 + no text - flash 模型优先，失败换 pro - 生成后必须用 wechat-upload skill 上传到微信素材库，记录 media_id 和微信 URL 到 output/wechat/image-mapping.json（key 为 cover.jpg）。微信公众号封面图必须使用微信素材库中的图片 - 小红书卡片（必做）：用 xiaohongshu-cards skill → output/xiaohongshu/cards/*.jpg - 如果 output/infographics/ 存在且非空，必须将信息图嵌入卡片： 1. cp final.md final.md.bak（备份原文） 2. 在 final.md 对应段落位置插入信息图的 markdown 图片引用（![alt](R2 URL)） 3. 运行 xiaohongshu-cards 生成脚本（脚本会渲染 markdown 中的图片到卡片中） 4. mv final.md.bak final.md（还原原文） - 卡片生成脚本的 HTML 模板已有 .card-flow img 样式，会自动渲染内嵌图片

9. 更新元数据

将 README.md 中 status 改为 ready（中文：已就绪），记录发布平台

状态约束（强制）：
- 完成全平台内容产出后，只能标记为 ready，禁止自动改为 published
- published 仅在用户明确要求“已发布/已实际发布”时才可使用

自动路由详解

Style Skill 的 Routing Metadata

每个 writing-style skill 的 YAML frontmatter 包含 routing 字段：

CODEBLOCK7

路由算法

CODEBLOCK8

当前可用 Style Skills

Skill	擅长	关键词
INLINECODE120	技术解读、人物叙事、产品评测	AI, 深度学习, 创业, 数据驱动
INLINECODE121

快速命令

- 开始新文章：提供参考材料，管线自动进入 Stage 1
提交改稿：告知 final.md 已就绪，管线进入 Stage 2
发布：指定目标平台，管线进入 Stage 3

Writing Pipeline

内容再创作管线。三个阶段：Draft → Review → Publish。

Stage 1: Draft（生成初稿）

步骤

projects/writing/articles/YYYY-MM-DD-{slug}/

2. 保存参考材料（含 comment/highlight）

将用户提供的参考资料保存到 references/ 子目录。

comment 机制（新增，必做）：
- 若参考资料存在行内评论 sidecar（如 references/*.comments.json），必须一并保存，不可丢失。
- 评论中带有 highlight 的片段视为强信号素材，在 Stage 1 写初稿时必须优先吸收。
- 先生成一份素材提炼清单 references/reference-notes.md，按如下结构整理：
- must-include：被 highlight 的原句/要点（后文必须落入初稿）
- angle：评论给出的写作角度、争议点、可展开问题
- evidence：可直接引用的数据、案例、事实
- avoid：评论中明确标注不建议采用的表达

X/Twitter 链接处理： 如果参考材料中包含 x.com 或 twitter.com 链接，使用 deepreader skill 抓取推文内容（FxTwitter API，无需 API key），保存为 references/tweet-{id}.md。用法：
python
from deepreader_skill import run
result = run(https://x.com/user/status/123456)

3. X 搜索：查询相关事实与事件

用 x_search 搜索与参考材料相关的关键词、人物、事件，获取最新信息： - 从参考材料中提取 2-3 个核心关键词 - 调用 x_search 查询，收集近期相关讨论、事实、数据 - 将搜索结果摘要保存到 references/x-search-results.md - 生成初稿时将搜索结果作为补充上下文，确保内容基于最新事实

4. 自动路由：匹配写作风格

分析输入材料的特征，匹配最合适的 writing-style skill：

输入材料 → 提取特征(domain, content_type, tone) → 匹配 style skill → 确认

路由规则（按优先级）：
1. 用户明确指定 style → 直接使用
2. 未指定 → AI 分析材料特征，与每个 style skill 的 routing metadata 匹配
3. 选择匹配度最高的 skill，向用户确认后加载

匹配矩阵：

| 输入特征 | → 推荐风格 |
|----------|-----------|
| 技术论文、产品发布、AI 模型 | writing-style-huasheng |
| 创业故事、人物传记 | writing-style-huasheng |
| 方法论、工具教程、how-to | writing-style-baoyu |
| AI 工具评测、写作技巧 | writing-style-baoyu |
| 哲学思辨、人生设计、意义探讨 | writing-style-dankoe |
| 跨领域框架、自我提升、身份探讨 | writing-style-dankoe |
| 长文摘要、知识提取、结构化转述 | writing-style-zhengliu |
| 表达欲过强的文章、信息提取困难 | writing-style-zhengliu |

路由分析流程：

1. 识别材料的主题领域(domain)
→ tech/AI/product → huasheng 候选
→ writing/productivity/tools → baoyu 候选
→ psychology/identity/meaning → dankoe 候选

2. 识别内容类型(content_type)
→ explainer/biography → huasheng 候选
→ methodology/how-to/opinion → baoyu 候选
→ essay/thought-piece/philosophical → dankoe 候选

3. 识别语气倾向(tone)
→ narrative/data-driven → huasheng
→ teaching/metaphor-driven → baoyu
→ philosophical/provocative → dankoe
→ structured/fact-driven/extractive → zhengliu

4. 检查蒸馏触发条件（优先级高于风格匹配）
→ 用户明确要求蒸馏/提取/结构化转述 → zhengliu
→ 原文篇幅长 + 信息密度低 + 表达欲强 → zhengliu 候选

5. 综合三个维度，选择匹配度最高的 skill
6. 如果两个 skill 匹配度接近，列出两个选项让用户选择

5. 选题讨论（必做，不可跳过）

提供 3-4 个选题方向，每个包含：

选题 N：标题
- 核心角度：一句话说清楚文章讲什么
- 核心比喻：（如使用宝玉风格）贯穿全文的比喻
- 结构预览：3-5 个章节标题 + 预计字数分配
- 优势：为什么这个角度好
- 风险：可能的问题或难点

标题原则——共鸣式标题：
标题的目标不是概括内容，而是说出读者心里那句没说出口的话。
找到目标读者普遍存在但很少被说清楚的困惑/痛点/感受，用一句话替他们问出来。
读者看到标题的反应应该是对！我也是这样！→ 然后点进来。

6. 生成初稿（reference + comment 联合驱动）

用户确认选题后，加载匹配的 writing-style skill，基于 references/ 与 references/reference-notes.md 联合生成初稿，保存为 draft-v1.md。 - 硬约束：所有 must-include（highlight 片段）必须在初稿中被明确吸收（可改写措辞，但核心信息不能丢） - 若某个 highlight 与其他证据冲突，必须在文中给出说明，且在草稿末尾加冲突说明小节 - 如有多轮风格迭代，按 draft-v0.md、draft-v1.md、draft-v2.md 递增保留各版本 - 初稿完成后，必须立刻复制最新 draft 为 final.md，供用户直接在终稿编辑器中改稿（cp draft-vN.md final.md） - 若 final.md 已存在且非空，不覆盖；仅在缺失或空文件时执行复制

7. 提取观点与生成信息图（可选，也可在 Stage 2 后执行）

a. 加载 viewpoint-extractor skill，从初稿中提取 3-5 个核心观点 b. 保存 viewpoints.yaml 到文章目录 c. 加载 infographic-gen skill，为每个观点生成信息图 d. 输出到 output/infographics/{slug}.jpg

> 此步骤可推迟到 final.md 完成后再执行，用终稿提取的观点更准确。

8. 写入元数据

创建 README.md： yaml

title: 文章标题 date: YYYY-MM-DD style_skill: writing-style-xxx sub_template: 子模板名（如适用） source_materials: - references/xxx.md status: draft

状态字段约束（必须遵守） - 仅允许：draft / reviewed / ready / published / deprecated - 禁止写自定义状态（例如 draft-generated），前端状态徽章不会识别

参考资料 comment 文件约定（新增）

- references/*.comments.json 视为参考资料的 sidecar 评论文件，存储高亮与讨论线程。
执行 Stage 1/2/3 时，不要删除或覆盖这些 sidecar 文件。
写初稿时必须优先读取 sidecar 中的 highlight 与 comment，再结合原文 reference 生成内容。
若缺失 sidecar 但用户明确说我做了高亮/评论，先在 references/reference-notes.md 记录该缺口并提示补充。

文章目录结构

articles/YYYY-MM-DD-{slug}/
README.md # 元数据
references/ # 参考材料
*.comments.json # 参考资料行内评论 sidecar（含 highlight）
reference-notes.md # 从 reference+comment 提炼出的素材清单
draft-v1.md # AI 初稿
final.md # 人工终稿（Stage 2）
final.comments.json # 终稿行内评论（前端编辑器 sidecar 数据）
diff-analysis.md # 差异分析（Stage 2）
viewpoints

writing-pipeline写作流水线