Skip to content

roles.md

Latest commit

 

History

History
97 lines (71 loc) · 10.2 KB

roles.md

File metadata and controls

97 lines (71 loc) · 10.2 KB
Raw

角色、权限与署名

一部片子通常经过几方之手：人定方向和把关，准备方把内容弄清、写好，制作方把它做成可理解的视听作品。分工按实际能力，前期内容与后期制作承担同样的质量责任。

1. 角色

角色 由谁担任 负责
策划 人。本仓库为 WaterRun；独立 fork 见 kit/studio.json 选题、定方向、拍板取舍、确认交付与发布、评价成片
校对 人。本仓库同为 WaterRun 逐句审定文案，给出明确确认
准备方 具备对应取证与写作能力的模型或协作者 前期：取证、实验、理解对象、整理原始材料、写文案并随校对修改、翻译稿、简报
制作方 策划者选定、具备相应制作能力的模型或协作者 成片：设计、配音、场景、声音、渲染、验收、交付记录；对内容在成片中的表达负责
维护者 策划指定的模型或人 共享的 kit/、docs/、片单与系列说明

一个模型可以同时担任几个角色；同一部片子也可以不经准备方，由制作方从头做到尾。开工时由策划指明本次会话的角色；没有指明时，按所做的事对号入座，并在本片 README 的「状态」里写明。

2. 谁说了算

发生冲突时，按下面的顺序取舍。排在前面的约束后面的；排在后面的不能推翻前面的。

  1. 事实。 research/FACTS.md 里有依据的事实。认为它错了，先补证据、改 FACTS，再改别处。
  2. 策划者的明确要求。 会话中的原话或已记录的决定，优先于任何任务书、简报、系列约定和文档里的缺省做法。采用时把原话、日期记进本片 README 的「简报」；与已有文字冲突时，在同一处写明按哪条执行。
  3. 已确认的文案。 经校对确认的稿本。实质改动须重新交审，见 文案校对。
  4. 仓库标准。 质量标准 与 经验规则 是底线，不是天花板。
  5. 制作方的判断。 以上四条之外的一切——视觉、版式、动画、镜头、配乐、音效、封面、实现方式——由制作方决定。
  6. 准备方的建议。 准备方写下的任何关于成片的想法都只是建议，制作方可以采纳，也可以推翻，不需要征得准备方同意。

自动闸门的阈值（project.json 的 check）属于第 4 条：可以按本片的设计收紧；放宽须有策划者的决定或写明理由，不能为了通过而放宽。

3. 准备方的边界

准备方交付的是可复查的理解与可读的文案。制作方应能读懂对象、证据和叙事取舍，继续制作。准备方不掌握成片的画面与声音，所以不替制作方做审美决定。

可以做 不做
取证、实验、来源整理，写 research/FACTS.md 与 research/lab/ 规定视觉风格、配色方案、版式、图形语言
收集讲解对象自己的材料：标志色值、官网字体与样式表、官方部件，各附出处，写进 research/MATERIALS.md 写 src/css/style.css、关键帧、分镜、场景代码
写文案稿，随校对意见修改，导出交审 写配乐方案或 tools/music.py，指定音色之外的声音设计
试听候选音色，把试听结果与策划者的评价记下来 填写验收结论、反馈复核结果或任何「已通过」
写本片 README 的「简报」与「交接」：受众、核心问题、逐章答案、不讲的材料、策划者原话、尚未解决的问题 替校对者确认文案，或在没有真实确认时填写 approval.json
记录可检查的硬约束：时长上限、语言、策划者明确要求的风格方向 修改 kit/、docs/、片单之外的条目或别的视频目录

判据是一句话属于材料与约束还是方案。「标志红为 #EE2B24，取自官网 SVG」是材料；「火焰代表引擎、灰框代表服务端」是方案，归制作方。策划者亲口定下的方向（例如「要电子乐」）是约束，照录原话即可，不要展开成方案。

准备方交接时，node kit/tools/check.js <视频> --handoff 核对事实表、文案确认、简报与交接说明；内容是否清楚、准备方是否越界仍须按上述边界核查。

第三方接手本项目时，沿用同一内容标准、审稿与验收流程；同时遵守开源交付要求。交接成功只表示材料与记录具备条件，不能代替接手者的内容核查。

4. 制作方的权限

制作方根据事实、已确认的文案和策划要求，独立设计成片。

  • 准备方的建议、旧的任务书、系列里其他各集的做法，都可以推翻。推翻时在 README 的「设计」里写一句理由即可。
  • 发现事实可疑：补证据、改 FACTS；证据不足的陈述，交策划者决定删改。画面需要、FACTS 里却没有的事实（年份、版本、数值），去查证、写明出处补进 FACTS 再画；不要因为 FACTS 里没有就把画面删空（P76）。
  • 文案也由制作方负责到底，不机械照搬已确认的稿（P73）。每次加句、删句、改章节之后通读整章，核对数字、列举的个数、章节卡与旁白、旁白与画面是否一致；发现错误或更好的讲法，主动改。读法、停顿、字幕断句直接改并记录；改了含义的写进 NOTES，交校对者确认后再配音。校对者在会话里指出某处问题并要求修改的，以原话作为该处修改的确认依据，记录里写明确认只覆盖那一处。
  • 工具或规范妨碍了正确的做法：先按现有规则完成本片，把问题与建议写进本片 README 的「复盘」，由维护者处理；不在制作中途改共享工具来让自己过关。
  • 能看图、能听声音的模型，就亲自看、亲自听，并写明看过听过的范围；不能的，如实写明，留给人判断。

5. 署名

署名的唯一来源是本片 project.json 的 credits。片尾名单、README 的「署名」都从这里读；check.js --final 核对片尾画面上出现的名单与它一致。

人的署名由本人选择，可以使用姓名、昵称或笔名，不要求实名。 署名应得到本人认可，并与实际贡献对应；校对记录沿用同一公开署名，便于核对确认记录。模型则记录提供方公布的准确型号与版本。

"credits": {
  "planner": "WaterRun",
  "models": [
    { "name": "Claude Opus 5.5", "roles": ["视觉设计", "场景实现", "配乐", "验收"] },
    { "name": "DeepSeek V4.1 Flash 1017", "roles": ["取证", "文案初稿"] }
  ],
  "services": [
    { "name": "MiniMax speech-2.8-hd", "roles": ["配音"] },
    { "name": "Whisper small", "roles": ["读音回听"] }
  ],
  "repository": "https://github.com/Water-Run/ft"
}
  • 模型写准确型号。 使用提供方公布的名称与版本，例如 Claude Opus 5.5、GPT-6 Astra、Gemini 4 Argon、DeepSeek V4.1 Flash 1017。不以客户端、运行框架或平台名（Codex、Claude Code、Cursor、OpenCode、ChatGPT）代替型号，也不只写含糊的系列名（GPT6、Claude）。repo-check.js 拦截这些写法。
  • 不确定就问，不猜版本。 模型名来自本次会话的实际记录或策划者的告知。制作期尚未核实时可暂写「未记录」，但交付前必须查明；check.js --final 拦截空模型表、未记录、未知、待确认等占位名和型号简称，新旧目录都适用。服务没有披露所用模型时写明服务名称与「模型未披露」，不把它当作参与制作的模型身份。
  • 按实际分工。 每个模型列出它真正做了的事；准备方与制作方都列。没有参与的不列。双语片的分工可以写成 { "zh": "配音", "en": "Narration" }。
  • 接手就登记，交付前逐一核对。 开工、换模型、准备方交接和制作方接手时，更新本片 credits 的真实型号与实际分工。最后对照会话、审稿与交接记录逐一核对参与者，再看每种语言、每个交付版本的实际片尾，记录依据和成片时刻。自动检查只能发现字段缺漏及画面文字缺失，无法发现完全未登记的参与者。全仓盘点见生成的 Credit 清单。
  • 人与服务分开。 策划是人，单独一行；配音、语音识别、检索等服务写在 services，不混进模型。
  • 配音写到具体模型和音色。 服务名写合成模型，不写客户端简称。MiniMax 写 MiniMax speech-2.8-hd，分工写音色 id，例如 配音 · Chinese (Mandarin)_Radio_Host。Microsoft 在线语音写 Microsoft neural TTS，分工写 zh-CN-YunyangNeural 这类完整音色名。不要只写 Edge TTS 或 edge-tts。双语片的分工按语言分开写。
  • 片尾必须有：「策划：WaterRun」（英文 Planning: WaterRun）、全部参与模型及分工、「开源视频」（英文 Open-source video）、GPL-3.0-or-later 与完整的仓库地址。片尾不配旁白；开源交付还须核对对应源码和第三方权利。

已发布的旧片按发布后冻结执行：片尾与 credits 保留线上对应版本。漏署名时，在 README 的反馈与复盘中补记确认后的公开署名或模型型号、实际分工和依据。只有策划者明确要求重做，才在记录授权后修改制作内容。

6. 多个会话同时工作

可能同时有几个会话各做一部片子，大家共用一个 Git 身份和工作区。

  • 一个会话只写自己负责的那个视频目录。共享文件（kit/、docs/、系列说明、片单、根目录文件）只在策划交代了维护任务时改，改动单独提交。
  • 提交只用路径限定的形式：git commit -m "…" -- videos/<系列>/<片>/。它只提交列出的路径，不会带上暂存区里别人的改动。不用 git add -A、git add .、git commit -a。
  • 开工先看 git status。别人的未提交改动不还原、不覆盖、不顺手提交。
  • 要改别人目录里的东西（例如批量改路径），先联系那个会话或告知策划，说清改哪些文件。