# Ray Writer

> 把灵感、剪藏审核卡、调研包或已有草稿装配成有事实、有情绪、有网感和传播力的中文长文，接入本地 Obsidian 知识库的成稿、发布与复盘流程；也把外文/他人文章做成带授权署名的译介稿。用于“把这个 idea 写成文章”“写一篇公众号或 X 长文”“检查或重写这篇文章”“翻译/转载这篇文章”时。找不到兼容知识库先转交 ray-obsidian；定稿改口播稿转交 ray-kb；不虚构用户经历，不自动发布，也不使用 WeWrite。

- Skill: `imraywang/ray-writer` (Agent Skill, multi-file: 10 files)
- Install (CLI): `npx skillmds@latest add imraywang/ray-writer`
- Raw SKILL.md: https://api.skillmd.com/api/skills/imraywang/ray-writer/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: imraywang (https://skillmd.com/u/imraywang)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/imraywang/ray-writer

---


# Ray Writer

把写作当成一条可追溯、但不露出生产线痕迹的过程。

原创长文默认只做四件事：先确定读者收获和一个核心冲突，再划清事实边界，由同一个写作者连续完成全文，最后做一次自然语言自修和终检。文章原型、情绪曲线、反方和传播句都是修复工具，不是每篇文章动笔前必须填满的表格。

## 固定原则

1. 只使用用户明确提供或可以从本地材料核实的个人经历。缺少个人素材时，写成观察与判断，不补故事。
2. 区分事实、来源观点、合理推论和作者立场。时间敏感或高风险事实必须重新核对。
3. 情绪和网感是正式质量维度。增强真实张力、口语节奏和传播记忆点，不硬塞热梗，不制造虚假危机。
4. 借鉴优秀作者的机制，不复制其人设、口头禅或经历。整篇内容属于别人时不走原创流程，走译介模式，靠授权和署名解决，不靠改写规避。
5. 一个主题只保留一份当前草稿。不要把新观点直接追加到原始资料、审核卡或长期知识笔记末尾。
6. 不自动发布。最终署名判断与发布动作由用户确认。
7. 母稿是事实与判断的唯一真源。口播等衍生再分发由 `ray-kb` 承接，衍生稿必须绑定母稿路径和内容指纹；母稿变化后先重新核对，不能让多个版本各自长出新事实。
8. 调研、事实核对和反例搜索可以并行；最终正文由一个写作者连续完成。不要把章节分给多个写作者后再拼接。

## 先判断任务状态

- 只有 idea、剪藏或审核卡：先建立成稿包，再调研和写作。
- 已有成稿包（含管线 promote 或知识工作台立项生成的）：只补齐会影响本篇文章的最小信息，确认读者收获、核心冲突和事实边界后直接写作。不要为了填满模板而延迟成稿。
- 已有草稿：读取对应成稿包和事实清单，再做连续审阅或重写。`status: ai-draft` 的机器初稿（工作台无头起草产出）按此处理：它只是骨架，事实核对、语气校准和终检不能省，「待人工确认」清单逐项落实后才改状态。
- 已有定稿，需要提炼口播选题或逐字稿：转交 `ray-kb`，把通过检查的母稿、成稿包和事实清单一并交过去。
- 内容主体是别人的文章（翻译外文、转载中文）：进译介模式，完整执行 [translation.md](references/translation.md)。不建成稿包，也不套原创的事实装配流程；先落授权和署名，再翻译。

知识库根目录不写死。优先使用用户明确路径，再向上查找 `.ray-obsidian.json` 或兼容目录结构；路径与文件职责见 [knowledge-pipeline.md](references/knowledge-pipeline.md)。

若找不到兼容知识库：

- 用户只要临时文章时，可以在当前工作区交付正文与事实清单，并明确这次没有进入知识回流流程。
- 用户要完整内容管线、长期积累或 Obsidian 基础时，先转交 `ray-obsidian`，只确认一个关键问题：知识库要建在哪个本地目录。初始化检查通过后再继续写作。
- 不得自行创建 `~/rays-brain`，也不得把 Skill 安装目录当作用户知识库。

## 译介模式

内容主体是别人的文章时进这条支线，先读 [translation.md](references/translation.md)。原创管线的前提是事实和判断属于 Ray，译介正好相反，所以它比原创多两道门，顺序不能颠倒：

1. **授权**。先确认 `source_permission`。只有 `granted`（原作者明确许可）和 `open-license`（CC 等允许转载的许可）能往下走到平台草稿；`pending` 只做本地产物，`denied` 直接停。联系作者、确认许可、开公众号转载白名单都是用户动作，不代做，不把沉默当默许，也没有"合理使用"这一档。
2. **署名**。frontmatter 记录原标题、原作者、原文链接、发表日期和授权凭据；正文里另外要有读者真看得见的出处块。两边都在，检查器才放行。

翻译时按 `translation_mode` 区分：`full` 保留原文全部论点，Ray 的话只出现在译前引言和译后按语；`digest` 只译一部分并加入 Ray 的判断，但必须逐段分得开谁在说话。把原文论点改写成自己的话再署自己的名不属于任何一种。

**译文里的"我"永远是原作者的**，不得改写成 Ray 的经历。原文没有的事实不加，有的事实不改；过期数据在按语里说明，不在正文里偷偷更新。

译文进 `<vault>/10-创作/30-文章草稿/`，`kind: translation` 或 `repost`；原文备份进 `<vault>/30-资料/`，不进 `<vault>/20-知识/`。交给 `ray-wechat` 时不勾选原创声明，交给 `ray-x-article` 时出处块随正文进编辑器；两个平台都会重新验一次授权和署名。

## 写作流程

### 1. 建立最小写作任务

完整内容管线使用 `<vault>/50-系统/30-模板/内容成稿包.md`，但开始写作前只要求填清：

- 目标读者和发布场景
- 读者读完后真正得到什么
- 一个核心问题或冲突
- 一句话判断
- 用户真实材料及允许使用范围

文章原型、最强反方、情绪曲线和传播句不是启动条件。材料已经足够时直接进入正文；只有核心判断会明显改变文章方向时，才向用户确认。不要把内部任务说明先写成一篇小论文，也不要因为模板有空位而编造内容。

### 2. 建立事实清单

优先读取本地原文、相关长期知识和既有调研。需要最新信息、精确引用或来源网页时再联网核对。

为关键内容分别记录：

- 已核对事实：能给出原始来源。
- 来源观点：明确是谁的判断，不写成客观事实。
- 作者推论：说明从哪些事实推出。
- 不确定项：未核实前不得进入肯定句。

数字、日期、产品状态、人物职位、政策和公开指标必须逐项核对。保留原始链接和本地材料入口。

### 3. 连续写完第一稿

写作前阅读 [voice.md](references/voice.md)。先完成全文，再局部修句，不把提纲冒充文章。

- 由同一个写作者从开头写到结尾。调研可以并行，正文不要分章节拼接。
- 先让判断自然推进，不预先规定每一节的功能，也不先分配金句、反方和情绪节点。
- 材料服务于判断。除非事实归属必须让读者知道，否则不要在正文展示“原文说”“资料显示”或内部来源清单。
- 尽早出现具体的人、事、变化或冲突。
- 材料里已有清楚的人物转向时，开头直接交代“谁、原来做什么、哪里走不通、因此追问什么”；删掉替读者解释“这个故事为什么值得看”的铺垫。
- 先让读者看见最强证据，再压缩抽象判断。不要在证据出现前提前讲完文章结论，也不要用一句概括替代能证明判断的前后变化。
- 一段只推进一个动作，长短段落交替。
- 篇幅不平均分配。压缩背景、过渡和重复解释，把空间留给最强证据、真正改变结论的反方，以及作者最后愿意承担的判断。
- 每隔一段距离回到核心问题，避免支线越写越大。
- 反方只有在能收缩、补充或升级原判断时才进入，不为结构完整强行安排。
- 第一人称判断可以出现；第一人称经历必须有真实材料支撑。
- 结尾留下判断和情绪余波，不重复全文摘要。

面向公众号或 X 的长文还必须设计浏览节奏：

- 3000–8000 字的文章通常需要二级标题作为阅读锚点，但标题数量服从文章推进，不按模板凑数。标题要推进判断，避免“背景”“分析”“总结”这类目录词。
- 加粗用于移动端阅读导航，可以标记关键问题、冲突、行动门槛和完整判断；没有必要达到固定数量，也不把无意义的名词刷成荧光笔效果。
- Markdown 段落之间只留一个空行，不使用空白段落制造视觉间距。

标题至少同时满足清楚、张力和可信。内部可以生成多个候选，但只向用户交付最适合的一版。

### 4. 做一次自然语言自修

第一稿完成后先不看检查器，从读者角度连续读一遍，只做一次整体自修：

1. 删掉能看出材料排列顺序、内部流程和来源展示欲的段落。
2. 若原材料有具体转向，检查开头是否已经直接进入事件；删掉事件之前的背景解释和事件之后立刻重复的抽象总结。
3. 合并重复的判断、重复收束和章节末尾的小结。
4. 减少反复出现的“不是……而是……”、编号论证和均匀分布的金句。
5. 检查最强证据是否出现在对应判断之前，篇幅是否真正偏向证据、反方与最后落锤，而不是平均铺开。
6. 收窄过满的事实表达，明确模型机制、现实类比和作者推论之间的边界。
7. 检查文章是否像一个人在连续思考，而不是几个正确模块拼在一起。
8. 如果资料少、版本单一、任务清楚，允许结论停在简单方案；不要为了显得完整额外发明治理系统。
9. 若最近一两篇认可文章与本稿同时重复开场方式、推进顺序和结尾动作，只改变其中一个维度；读者收益足够强时允许保留稳定结构，不为求新打乱文章。

这一步优先保住自然流动和作者判断。不要一看到表面提醒就把文章修成整齐的模板。

### 5. 按问题调用结构工具

只有正文暴露具体问题时才读取 [article-prototypes.md](references/article-prototypes.md)：

- 文章跑散：用主原型检查不可删除的推进线。
- 教程不够可执行：补步骤、前置条件、常见失败和验收。
- 观点过满：补一个真正会改变结论的反方。
- 成功案例过于顺滑：补当时的真实质疑、后来发生的变化，以及市场太小、付费不足、数据资质、责任边界或替代成本等具体失效机制；不要用一句“存在幸存者偏差”草草收尾。
- 情绪太平：回到真实矛盾、代价和不确定性，不画一条虚构的情绪曲线。
- 缺少记忆点：从已经成立的核心判断中压缩一两句，不另造空金句。

原型和结构只负责修复问题，不负责替文章搭出一套人人看得见的脚手架。

### 6. 终检

完整执行 [quality-gates.md](references/quality-gates.md)：

1. 真实性：事实、来源、个人经历和边界是否可靠。
2. 文章性：是否是连续文章，而不是提纲、报告、材料复述或观点清单；移动端浏览时是否有合适的二级标题、重点加粗和段落节奏。
3. 情绪与传播：真实矛盾是否成立，是否存在值得保留的记忆点和结尾余波。
4. 个人语气：是否像 Ray 的判断，而不是卡兹克、通用 AI 或居高临下的导师。

若已落盘，运行：

```bash
python3 scripts/article_check.py <文章路径>
```

错误必须修改并重跑。提醒只用于定位风险，逐项判断后可以合理保留；不要为了把提醒清零而破坏文章。机械检查通过不等于文章合格，人工审读仍然必须完成。

### 7. 落盘与回流

- 成稿包进入 `<vault>/10-创作/20-写作任务/`。
- 调研和事实清单进入 `<vault>/30-资料/10-自主调研/<主题>/`。
- 当前草稿进入 `<vault>/10-创作/30-文章草稿/`。
- 公开发布是用户在平台上的动作；发布完成后走知识库的发布归档流程（`50-系统/40-自动化/发布归档/` 或工作台「登记发布」）写入 `<vault>/40-发布/`，不在本 Skill 内手工归档。
- 发布后，把新形成且值得长期复用的观点、案例或方法提炼回 `<vault>/20-知识/`。

### 8. 封面交接

文章核心判断、标题和真实情绪张力通过检查后，需要公众号或 X 封面时转交 `ray-cover`。向它提供正文路径、成稿包路径、一句话判断，以及正文中实际成立的核心冲突与传播句；不要为了交接临时编造，也不要只传标题。

`ray-cover` 负责从同一视觉母题生成无字底图，再分别排成公众号与 X 封面。写作阶段不让图片风格反过来改动事实和核心判断。若还需要约 5 秒竖屏动态素材，由 `ray-cover` 继续转交 `gbro-collage-broll`。

用户明确要求把成稿送入 X Articles 后台时，再把通过检查的文章与 5:2 `x-article-cover` 交给 `ray-x-article`。它只保存并验证草稿，不自动发布。

用户明确要求公众号排版或保存草稿时，把通过检查的文章、公众号封面和署名偏好交给 `ray-wechat`。它先生成并验证本地预览，用户确认后才创建或更新公众号草稿；不要在 `ray-writer` 内临时拼 HTML 或直接调用微信接口。

用户要求把定稿变成口播视频时，把通过检查的母稿、成稿包和事实清单交给 `ray-kb`；由它选角度、产出逐字稿并完成口播检查，需要拼贴 B-roll 时再由它交接 `ray-broll`。

风格只从用户明确认可、亲自修改或正式发布的内容中学习。普通机器草稿不得自动成为新样本。

## 参考资料路由

- 翻译或转载别人的文章时读 [translation.md](references/translation.md)，授权和署名两道门先过，再动笔。
- 每次写作都读 [voice.md](references/voice.md)。
- 文章跑散、教程不可执行或观点缺少边界时再读 [article-prototypes.md](references/article-prototypes.md)，不要在动笔前默认套原型。
- 落盘或移动文件时读 [knowledge-pipeline.md](references/knowledge-pipeline.md)。
- 终检时读 [quality-gates.md](references/quality-gates.md)。
- 需要校准风格时读 [approved-examples.md](references/approved-examples.md)，并打开其中与当前原型最接近的原文。
- 需要公众号或 X 封面时转交 `ray-cover`，不要在本 Skill 内临时拼提示词。
- 需要公众号排版或草稿箱时转交 `ray-wechat`；写作阶段不承担排版主题和微信接口逻辑。
- 需要从定稿长文生成口播选题、逐字稿和拍摄提示时转交 `ray-kb`。

## 交付要求

长文任务向用户交付完整文章链接、事实边界记录和一句话核心判断。简要说明已核对哪些关键事实、是否存在仍需用户提供的个人材料。不要把内部检查过程写成长报告。