writing-pipeline（写入管道）

Writing Pipeline

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

Stage 1: Draft（生成初稿）

步骤

1. 创建文章目录

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

1. 保存参考材料（含 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。用法：

   from deepreader_skill import run
   result = run("https://x.com/user/status/123456")

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

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

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

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

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

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

匹配矩阵：

路由分析流程：

   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 匹配度接近，列出两个选项让用户选择

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

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

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

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

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

1. 生成初稿（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 已存在且非空，不覆盖；仅在缺失或空文件时执行复制

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

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

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

1. 写入元数据

创建 README.md：

   ---
   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.yaml        # 观点提取结果（viewpoint-extractor skill 生成）
  output/                # 多平台输出（Stage 3）
    infographics/        # 信息图（infographic-gen skill 生成）
      {slug-1}.jpg
      {slug-2}.jpg
    blog/
      article.md
    wechat/
      article.md
      cover.jpg           # 微信封面（wechat-cover skill 生成）
    xiaohongshu/
      text.md             # 发帖文本（编辑推荐语）
      cards/              # 文转图卡片（xiaohongshu-cards skill 生成）
        01.jpg, 02.jpg, ...
    jike/
      article.md
    twitter/
      article.md

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

前置条件

用户已将改稿保存为 final.md

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

步骤

1. 执行 Diff-and-Learn

详见 references/diff-learn.md

1. 生成差异分析

将分析结果保存为 diff-analysis.md

1. 提议 Skill 更新

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

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

1. 更新元数据

将 README.md 中 status 改为 reviewed

文件约定（重要）

• 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）

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

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

1. 选择目标平台

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

1. 加载 Formatter 并生成

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

1. 保存输出

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

1. 插入信息图到全平台文章（如 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 的小红书卡片生成流程（信息图嵌入卡片图片中）

1. 微信图片链接替换（当目标平台包含 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

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

- 微信封面（必做）：用 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 样式，会自动渲染内嵌图片

1. 更新元数据

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

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

自动路由详解

Style Skill 的 Routing Metadata

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

routing:
  content_types: [...]     # 擅长的内容类型
  domains: [...]           # 擅长的领域
  tone: [...]              # 语气特征
  best_for: "..."          # 一句话描述最佳场景

路由算法

输入：参考材料文本
输出：推荐的 style skill 名称

1. 分析材料特征
   - domain: 从关键词、主题、术语判断领域
   - content_type: 从结构、目的判断内容类型
   - tone: 从语气、目标读者判断期望语调

2. 计算匹配度
   对每个 style skill:
     domain_match = 材料 domain ∩ skill routing.domains
     type_match = 材料 content_type ∩ skill routing.content_types
     tone_match = 材料期望 tone ∩ skill routing.tone
     score = domain_match * 2 + type_match * 2 + tone_match * 1

3. 选择 score 最高的 skill
   - 如果最高分 skill 唯一 → 推荐该 skill
   - 如果两个 skill 分数接近（差距 < 20%）→ 列出两个让用户选
   - 如果所有 skill 分数都很低 → 提示用户手动选择

当前可用 Style Skills

快速命令

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