RE-03 · 漫画分镜脚本与原著一致性核查

① 场景引入

表面看是编剧不够细心 · 实际上原著动辄百万字，分镜脚本跨越几十集连载，靠人脑记住人物设定和道具前后一致，本身不现实

一、这件事现在是什么样

责任编辑（追更运营） · 真实业务触发

墟光工作室这周要交付《长夜捕光》漫画版第14-16集的分镜脚本，编剧要在主笔开始画之前把脚本和214万字原著逐项核对一遍。

二、痛点 · 每条都有来源

1漫画改编流程中编剧要独自每天看上千章、大概率并不好看的网文，然后整理成适用于变成漫画分镜的文字依据 ·漫画改编流程中，编剧要独自每天看上千章、大概率并不好看的网文，然后整理成适用于变成漫画分镜的文字2原著动辄百万字，分镜脚本跨越几十集连载，人物设定、道具、时间线前后是否矛盾，全靠编剧个人记忆力，没有系统性核对机制依据 · 原著动辄百万字，分镜脚本跨越几十集连载，人物设定/道具/时间线前后是否矛盾，全靠编剧个人记忆力，没有系统性核对机制3漫画编辑JD原文写的是'热爱漫画……会做文字脚本分镜优先'，说明这个岗位本身就承担着内容一致性把关的职责依据 · 漫画编辑JD原文：'热爱漫画，有一定阅读量，熟悉市场现状，有较强文字基础，有策划选题活动的能力……会做文字脚本分镜优先'

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

• 漫画改编流程中编剧要独自每天看上千章、大概率并不好看的网文，然后整理成适用于变成漫画分镜的文字原著动辄百万字，分镜脚本跨越几十集连载，人物设定、道具、时间线前后是否矛盾，全靠编剧个人记忆力，没有系统性核对机制漫画编辑JD原文写的是'热爱漫画……会做文字脚本分镜优先'，说明这个岗位本身就承担着内容一致性把关的职责

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

1. 触发 · 待核查脚本批次校验确认第14-16集脚本文档是否完整，涉及的原著章节范围是否明确
2. 人物设定核对 · 外貌/能力/称谓与原著及此前已交付集数是否一致重点核对与已交付集数台账的延续性，不只是与原著本身核对
3. 关键道具核对 · 该出现的道具是否遗漏、不该出现的是否误增标注道具在原著中的具体出处章节
4. 时间线核对 · 分镜脚本内的事件顺序是否与原著矛盾跨集数的时间线核对，标注可能的顺序错位
5. 留证 · 一致性核查报告生成矛盾点逐条列出并标注原著出处，是否需要改脚本由主笔和编剧决定

要准备什么：《长夜捕光》原著全本.txt214万字，已完结，格式为纯文本第14-16集分镜脚本.docx编剧手写脚本，含分镜描述与对白已交付集数人物设定台账.xlsx此前1-13集已核对过的设定记录，用于延续性核查

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 4 ÷ 落地难度 3 = 5.9

最大差异点：不要求先把原著和脚本都转成统一格式，原著正文（214万字）与分镜脚本文档直接比对，核对范围聚焦人物设定、关键道具、时间线三类最容易出错的项目。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

• 正式件本体：分镜一致性核查报告.xlsx 矛盾点逐条标注原著出处 · 含签批栏
• 可派发清单：待确认疑似矛盾清单.xlsx 可派发 · 需编剧进一步确认的项

这套东西不承诺什么：不做什么：不生成或修改分镜脚本本身，只做一致性核查；不判断'这样改编是否好看'，那是主笔与编剧的创作判断；发现的矛盾点只标注具体位置，不给出应该怎么改的建议。

② Live Demo（演示逐步）

表面看是编剧不够细心 · 实际上原著动辄百万字，分镜脚本跨越几十集连载，靠人脑记住人物设定和道具前后一致，本身不现实

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据， 不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：枫墟文化传媒（上海）有限公司（虚构）· 上海 · 员工74人 · 漫画工作室「墟光工作室」，网文改编漫画为主，编辑+主笔团队9人。主线储备IP《长夜捕光》（奇幻悬疑网文，作者"沉水"，2023-11签约，全本214万字已完结）。本次触发：墟光工作室这周要交付《长夜捕光》漫画版第14-16集的分镜脚本，编剧要在主笔开始画之前把脚本和214万字原著逐项核对一遍。

本轮核查集数第14-16集（3集）涉及核对项合计37 处与原著及台账一致34 处待编剧确认疑似矛盾3 处

输入网文平台与IP运营手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

• 01_原著相关章节摘录_第158-172章.txt 214万字原著中与第14-16集分镜脚本对应的章节摘录，用于逐项核对人物设定与道具描述按分镜脚本涉及的原著章节范围手动截取 · 未覆盖全书，如涉及跨章节前情引用可能出现遗漏
• 02_第14-16集分镜脚本.docx 编剧手写的第14-16集分镜脚本，含分镜编号、画面描述与人物对白编剧手写Word文档直接导出 · 分镜编号+画面描述+对白混排，未做结构化拆分
• 03_已交付集数人物设定台账.xlsx 此前1-13集已核对过的设定记录，用于本轮延续性核查墟光工作室编剧组维护 · 逐集核对后更新，13集以来记录格式基本统一
• 04_关键道具出场时间线索引.xlsx 原著中主要道具首次出场对应章节索引，用于核对分镜脚本中道具是否提前出现编剧部内部整理 · 根据原著章节目录人工摘录，非系统自动生成
• 05_第9集历史坑复盘记录.docx 第9集分镜脚本道具矛盾返工事件的复盘记录编剧部内部复盘· 事后根据读者反馈与返工记录整理，非实时监测记录

注意标橙色那一份 —— 03_已交付集数人物设定台账.xlsx。它墟光工作室编剧组维护 · 逐集核对后更新，13集以来记录格式基本统一，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

帮我把第14-16集的分镜脚本和原著核对一下， 重点看人物设定、关键道具、时间线这三类， 也要和1-13集已交付的设定台账对一下延续性。 矛盾的地方标出来对应原著哪一章，改不改脚本我们编剧和主笔决定。

短是因为核对范围和边界都写在能力包里了。

触发待核查脚本批次校验 · 确认第14-16集脚本文档是否完整

确认脚本文档是否完整齐全，涉及的原著章节范围是否明确，缺项不阻塞后续核对

墟光工作室这周要交付《长夜捕光》漫画版第14-16集的分镜脚本，编剧要在主笔开始画之前把脚本和214万字原著逐项核对一遍。现有材料是编剧手写的分镜脚本文档 —— 能看出这一批要核对多少处，但看不出核对范围对应原著哪些章节。检查项本批次结果涉及处数处理方式脚本文档完整性（分镜编号+对白齐全）完整第14-16集共3集全部提交进入人物/道具/时间线逐项核对涉及原著章节范围是否明确明确对应原著第158章至第172章锁定本轮核对范围核对项拆分统计（人物/道具/时间线三类）—37处进入下一步分类核对合计 37 处核对项———脚本文档与章节范围确认齐全后，37处核对项才能逐一展开，不是笼统地说“核对一下”就能开始。从历史里想起了公司踩过的坑第9集分镜脚本里主角的佩剑被误画成了在原著里第120章才出现的“寒霄”新剑，而当时的剧情进度对应原著只到第45章——这个矛盾直到读者在评论区指出才被发现，返工重画耗费了额外一周的主笔工时。这条不靠当年负责第9集的编剧是否在职，靠的是道具核对本身要成为固定流程，不能靠编剧个人记忆判断进度对应关系——这正是本轮批次校验先锁定核对范围的理由。

第 1 步 · 人物设定核对 · 外貌/能力/称谓与原著及此前已交付集数是否一致

重点核对与已交付集数台账的延续性，不只是与原著本身核对

第 2 步 · 关键道具核对 · 该出现的道具是否遗漏、不该出现的是否误增

标注道具在原著中的具体出处章节，逐项核对不靠记忆判断

第 3 步 · 时间线核对 · 分镜脚本内的事件顺序是否与原著矛盾

跨集数的时间线核对，标注可能的顺序错位

之后留证 · 一致性核查报告生成

不讲省了多久 · 讲少了几个隐患、沉淀了什么

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

表面看是编剧不够细心 · 实际上原著动辄百万字，分镜脚本跨越几十集连载，靠人脑记住人物设定和道具前后一致，本身不现实

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

漫画分镜脚本与原著一致性核查 —— 百万字原著全靠编剧记忆比对不现实 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

manga-panel-consistency.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

• SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
• references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
• references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是网文平台与IP运营手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁RE-03 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

• 01_原著相关章节摘录_第158-172章.txt 214万字原著中与第14-16集分镜脚本对应的章节摘录，用于逐项核对人物设定与道具描述
• 02_第14-16集分镜脚本.docx 编剧手写的第14-16集分镜脚本，含分镜编号、画面描述与人物对白
• 03_已交付集数人物设定台账.xlsx 此前1-13集已核对过的设定记录，用于本轮延续性核查
• 04_关键道具出场时间线索引.xlsx 原著中主要道具首次出场对应章节索引，用于核对分镜脚本中道具是否提前出现下载
• ↓DOC05_第9集历史坑复盘记录.docx 第9集分镜脚本道具矛盾返工事件的复盘记录

怎么用

• 把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
• 粘贴下方提示词发送
• 拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

帮我把第14-16集的分镜脚本和原著核对一下， 重点看人物设定、关键道具、时间线这三类， 也要和1-13集已交付的设定台账对一下延续性。 矛盾的地方标出来对应原著哪一章，改不改脚本我们编剧和主笔决定。

为什么这么短就够了：短是因为核对范围和边界都写在能力包里了。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

• 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
• 调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
• 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 2 份

• RE-03_分镜一致性核查报告.xlsx 正式件本体 · 矛盾点逐条标注原著出处 · 含签批栏
• RE-03_待确认疑似矛盾清单.xlsx 可派发 · 需编剧进一步确认的项

Skill 里固化了什么：从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：《长夜捕光》原著全本.txt214万字，已完结，格式为纯文本第14-16集分镜脚本.docx编剧手写脚本，含分镜描述与对白已交付集数人物设定台账.xlsx此前1-13集已核对过的设定记录，用于延续性核查

人工边界：不做什么：不生成或修改分镜脚本本身，只做一致性核查；不判断'这样改编是否好看'，那是主笔与编剧的创作判断；发现的矛盾点只标注具体位置，不给出应该怎么改的建议。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

责任编辑（追更运营） · 产出即下一步输入

• RE-01 · 腰部作者流失预警清单：从1247个作者里找出谁需要重点跟进
• RE-02 · 三审三校流程留痕报告：监管抽查时能立刻调出来的合规记录

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。