| name | ray-writer |
| description | 把灵感、剪藏审核卡、调研包、长期知识或已有草稿装配成有事实、有情绪、有网感和传播力的中文长文，并接入用户本地 Obsidian 知识库的成稿包、调研、草稿、发布与复盘流程。用于用户说“把这个 idea 写成文章”“从这条资料发展成长文”“写一篇公众号或 X 长文”“检查或重写这篇文章”“把内容生产流水化”时；找不到兼容知识库时先转交 ray-obsidian 建立或适配。不得虚构用户经历、数据、现场或情绪，不自动发布，也不使用 WeWrite。 |
Ray Writer
把写作当成一条可追溯的生产线。先装配事实、判断和情绪，再写文章；先验证，再交付。
固定原则
- 只使用用户明确提供或可以从本地材料核实的个人经历。缺少个人素材时，写成观察与判断，不补故事。
- 区分事实、来源观点、合理推论和作者立场。时间敏感或高风险事实必须重新核对。
- 情绪和网感是正式质量维度。增强真实张力、口语节奏和传播记忆点，不硬塞热梗，不制造虚假危机。
- 借鉴优秀作者的机制，不复制其人设、口头禅或经历。
- 一个主题只保留一份当前草稿。不要把新观点直接追加到原始资料、审核卡或长期知识笔记末尾。
- 不自动发布。最终署名判断与发布动作由用户确认。
先判断任务状态
- 只有 idea、剪藏或审核卡：先建立成稿包，再调研和写作。
- 已有成稿包：补齐缺失项，确认核心判断后写作。
- 已有草稿：读取对应成稿包和事实清单，再做审阅或重写。
- 只有发布稿需要改编：保留事实与判断，按目标平台重新组织，不做机械缩写。
知识库根目录不写死。优先使用用户明确路径，再向上查找 .ray-obsidian.json 或兼容目录结构；路径与文件职责见 knowledge-pipeline.md。
若找不到兼容知识库：
- 用户只要临时文章时，可以在当前工作区交付正文与事实清单，并明确这次没有进入知识回流流程。
- 用户要完整内容管线、长期积累或 Obsidian 基础时，先转交
ray-obsidian，只确认一个关键问题：知识库要建在哪个本地目录。初始化检查通过后再继续写作。
- 不得自行创建
~/rays-brain，也不得把 Skill 安装目录当作用户知识库。
写作流程
1. 建立成稿包
使用 <vault>/50-系统/30-模板/内容成稿包.md。至少填清：
- 目标读者、平台与文章原型
- 核心问题和一句话判断
- 已核对事实、待核对项和明确边界
- 用户真实材料及允许使用范围
- 最强反方
- 读者原有情绪、文章情绪核、情绪曲线
- 核心冲突句和两到三句传播句候选
不要因为模板有空位而编造内容。核心判断不清时，先从材料中提出一个最有张力的候选并明确标注待用户确认。
2. 建立事实清单
优先读取本地原文、相关长期知识和既有调研。需要最新信息、精确引用或来源网页时再联网核对。
为关键内容分别记录：
- 已核对事实：能给出原始来源。
- 来源观点：明确是谁的判断，不写成客观事实。
- 作者推论：说明从哪些事实推出。
- 不确定项：未核实前不得进入肯定句。
数字、日期、产品状态、人物职位、政策和公开指标必须逐项核对。保留原始链接和本地材料入口。
3. 选择文章原型
阅读 article-prototypes.md，只选择一个主原型。其他原型只能作为局部手法。
原型决定结构自由度：观点和现象解读可以连续推进；个人实践依赖真实过程；案例拆解需要机制与边界；教程必须保留清楚的小标题和可执行步骤。
4. 设计情绪与传播
写作前明确：
- 读者进入文章时已经在焦虑、兴奋、愤怒、好奇还是困惑什么。
- 作者真正被哪一处矛盾刺中。
- 情绪如何从开头的张力，经过中段的反转或加深，走到结尾的余波。
- 哪一句负责让人停下来，哪两三句值得截图或转发。
传播句必须承担观点，不做脱离正文的空金句。网感来自当下语境、自然口语、反问、对比和节奏，不来自流行词堆砌。
5. 写完整文章
写作前阅读 voice.md。先完成全文，再局部修句，不把提纲冒充文章。
- 尽早出现具体的人、事、变化或冲突。
- 一段只推进一个动作，长短段落交替。
- 每隔一段距离回到核心问题，避免支线越写越大。
- 主动提出最强反方并真正回应。
- 第一人称判断可以出现；第一人称经历必须有真实材料支撑。
- 结尾留下判断和情绪余波，不重复全文摘要。
面向公众号或 X 的长文还必须设计浏览节奏：
- 3000–8000 字的文章通常放 4–9 个二级标题；标题要推进判断，避免“背景”“分析”“总结”这类目录词。
- 每隔约 400–700 字给读者一个新的阅读锚点。开头可以连续推进，但不能让正文长时间没有结构提示。
- 只加粗完整的关键判断、反转句或结论句，通常 6–16 处；不把零散关键词刷成荧光笔效果。
- Markdown 段落之间只留一个空行，不使用空白段落制造视觉间距。
标题至少同时满足清楚、张力和可信。内部可以生成多个候选，但只向用户交付最适合的一版。
6. 四层检查
完整执行 quality-gates.md：
- 真实性：事实、来源、个人经历和边界是否可靠。
- 文章性：是否是连续文章，而不是提纲、报告或观点清单；移动端浏览时是否有合适的二级标题、重点加粗和段落节奏。
- 情绪与传播：是否有张力、反转、传播句和结尾余波。
- 个人语气：是否像 Ray 的判断，而不是卡兹克、通用 AI 或居高临下的导师。
若已落盘，运行：
python3 scripts/article_check.py <文章路径>
检查失败就修改并重跑。机械检查通过不等于文章合格，四层人工审读仍然必须完成。
7. 落盘与回流
- 成稿包进入
<vault>/10-创作/10-灵感/20-成稿包/。
- 调研和事实清单进入
<vault>/30-资料/10-自主调研/<主题>/。
- 当前草稿进入
<vault>/10-创作/20-草稿/。
- 只有用户确认发布后，才进入
<vault>/40-发布/ 对应目录。
- 发布后，把新形成且值得长期复用的观点、案例或方法提炼回
<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 或直接调用微信接口。
风格只从用户明确认可、亲自修改或正式发布的内容中学习。普通机器草稿不得自动成为新样本。
参考资料路由
交付要求
向用户交付完整文章链接、事实清单链接和一句话核心判断。简要说明已核对哪些关键事实、是否存在仍需用户提供的个人材料。不要把内部检查过程写成长报告。
