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