ray-writer

Ray Writer

目标只有一个：写出 Ray 愿意署名、稍改就能发的文章。表达先行，事实只守底线，一切为了内容和传播。

唯一的风格约束

每次写作前完整读取 voice.md，按里面的样本清单把 Ray 的真实稿件读完再动笔。表达规则之外不加任何风格限制。

固定原则

1. 正文里只放作者愿意说出口的话；拿不准的、编补的内容全部进文末「待确认」，不在正文里自保。
2. 由同一个写作者连续写完全文。调研可以并行，正文不要分章节拼接。
3. 一个主题只保留一份当前草稿。不要把新观点直接追加到原始资料、审核卡或长期知识笔记末尾。
4. 不自动发布。最终署名判断与发布动作由用户确认。
5. 口播等衍生再分发由 ray-kb 承接，衍生稿绑定母稿路径和内容指纹。
6. 整篇内容属于别人时不走原创流程，走译介模式，靠授权和署名解决，不靠改写规避。

先判断任务状态

• 只有 idea、剪藏或审核卡：先建立成稿包，再找素材和写作。
• 已有成稿包（含管线 promote 或知识工作台立项生成的）：确认读者收获和核心判断后直接写。不要为了填满模板而延迟成稿。
• 已有草稿：读取对应成稿包，再做连续审阅或重写。status: ai-draft 的机器初稿只是骨架，按 voice.md 重写口吻，「待人工确认」清单并入「待确认」。
• 已有定稿，需要口播：转交 ray-kb。
• 内容主体是别人的文章（翻译外文、转载中文）：进译介模式，完整执行 translation.md。

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

若找不到兼容知识库：

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

译介模式

内容主体是别人的文章时进这条支线，先读 translation.md。译介的内容属于别人，所以本 Skill 的表达规则不适用于译文正文，只适用于 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 和样本，然后从开头一口气写到结尾，再局部修句。不把提纲冒充文章。

面向公众号或 X 的长文要照顾手机阅读：用二级标题做阅读锚点，加粗关键问题和判断，Markdown 段落之间只留一个空行。

标题要让人想点开。内部可以生成多个候选，只向用户交付最适合的一版。

文末加 ## 待确认，格式见 voice.md。同时在 frontmatter 写 publish_exclude_sections: 待确认：这一节一直留在母稿里当记录，推送公众号或 X Article 时由 ray-wechat、ray-x-article 自动剔除，不用手动删。

4. 自修与终检

从读者角度连续读一遍，按 quality-gates.md 检查。重点是删掉正文里残留的自保话，把被写成资料综述的段落改回 Ray 在说话。

若已落盘，运行：

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

脚本只查格式和篇幅。错误必须修改并重跑；提醒逐项判断，可以保留。--profile 只调篇幅档位，是旧文章原型的遗留参数，一般不用传。

5. 落盘与回流

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

6. 封面与平台交接

需要公众号、X 或 X Article 封面时转交 ray-cover，提供正文路径、成稿包路径和一句话判断。

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

用户明确要求公众号排版或保存草稿时，把文章、公众号封面和署名偏好交给 ray-wechat。它先生成本地预览，用户确认后才创建或更新公众号草稿。

交给平台前，Ray 要看过「待确认」里的每一条，并在正文里定下改还是留；这一节本身不用删，靠 publish_exclude_sections: 待确认 在推送时剔除。

用户要求把定稿变成口播视频时，把母稿和成稿包交给 ray-kb。

参考资料路由

• 每次写作都读 voice.md。
• 终检时读 quality-gates.md。
• 翻译或转载别人的文章时读 translation.md。
• 落盘或移动文件时读 knowledge-pipeline.md。

2026-09-22 之前的风格规则、质量闸门、文章原型和认可样本说明已归档到 rayskills 仓库 docs/archive/2026-09-22-风格规则旧版/，不再约束写作。

交付要求

交付文章链接、一句话核心判断和「待确认」里有几条。不要把内部检查过程写成长报告。