这件事值得拆开看，不是因为"又一个 AI 写剧本的工具"，而是它解决问题的工程思路，对所有想用 Agent 处理长文档、复杂流程的人都有参考价值。

核心矛盾：长文本 vs 上下文窗口

早期版本用单个 Skill 做转写，处理中短篇小说效果不错，但碰到 50 万字以上的长篇就崩了——角色搞混、剧情遗忘、风格漂移。原因很直接：模型上下文窗口是硬限制，一次塞入太多内容必然丢失信息。

当时的解决方案是让用户手动分章喂入，但这等于把标准化工作甩给了用户。更合理的思路是让 AI 自行判断截断位置，全程接管业务流程。

这个认知转变其实是做 Agent 的关键分水岭：不要让用户适应 AI 的限制，让 AI 自己绕开限制。

四层协同架构

重构后的系统基于 Claude Agent + Skill 搭建，采用四层架构：

知识层（技能包）——改编方法论、视觉化写作风格、格式模板、实战示例全部打包成知识文件。每个改编阶段自动加载对应资源，AI 按专业标准执行，不是随意发挥。

流程层（主控配置）——三阶段工作流、八条指令集、文件管理规则的总调度中枢。控制什么时候读什么文件、什么时候触发质检、文件存在哪里。

执行层（改编引擎）——真正干活的部分。按流程层指令读取知识层资源，阅读小说原文，执行剧情拆解和剧本创作——拆剧情、写台词、标景别、控节奏。

质检层（双重质检）——source-checker 检查剧情拆解质量（5 个维度），script-checker 检查剧本质量（6 个维度）。格式问题直接自动修复，核心问题必须修改后重检，最多 3 轮闭环。

这个架构设计有一个值得注意的点：它不是一个"聊天助手"，而是一套工程化流水线。有标准、有流程、有质检、有文件管理。

四个关键设计决策

文档驱动，而非对话驱动。 所有上下文通过文件传递。对话断了、浏览器关了，只要文件还在，随时恢复工作。输入 ~status 查看进度，~next 继续工作。这解决了 Agent 任务中断后无法恢复的通病。

批次推进，绕开上下文限制。 剧情拆解每批处理 6 章，剧本逐集生成。不一次性塞入所有内容，从工程层面彻底规避上下文窗口的硬限制。

自动质检闭环。 每个环节完成后自动触发质检 Agent，检查→修改→再检查，形成闭环。这比让用户人工审核再反馈效率高一个量级。

知识注入代替提示词调教。 改编方法论、写作规范、格式模板全部结构化打包，而不是靠一段长提示词硬撑。这个做法的好处是可维护、可迭代，换个项目改知识文件就行。

输出质量的几个细节

剧本输出带完整的景别标注、视觉符号、音乐提示、台词指导，可以直接交付给分镜师使用。

集数不预设固定值，根据小说内容密度和冲突频率自然生成——冲突密集多拆，铺垫段落大胆合并。

台词方面做了五类禁忌检测、角色语言分层、情绪烈度匹配，目标是消灭"小说味台词"。情绪曲线内置节奏规则：压力→爽点→平息→更大压力→更强爽点，连续 3 集不允许相同情绪类型。

系统还引入了"剧情地图"概念，所有改编蓝图服务于剧本走向，让输出内容更适合制作成动态漫剧。

使用方式

操作流程三步：~start → ~map → ~write，从小说到剧本。

将 Agent 压缩包解压后放到项目文件夹，其中包含一个隐藏的 .claude 文件夹（macOS 按 ⌘ + Shift + . 显示隐藏文件，Windows 在文件夹设置中开启显示隐藏文件）。确认文件结构完整后，在当前目录打开终端，输入 claude 启动 Agent 流程。

这件事的结构性意义

从产品角度看，网文转漫剧剧本是一个典型的"AI 可以吃掉大量人工但需要工程化封装"的场景。单靠模型能力不够，必须在流程设计、质量控制、上下文管理上做工程投入。

从 Agent 搭建的方法论角度看，这套系统的设计思路——文档驱动、批次处理、自动质检闭环、知识与流程分离——几乎可以迁移到任何需要处理长文档、多步骤、高质量输出的业务场景。不管你做的是小说改编还是技术文档生成，底层逻辑是一样的：把复杂任务拆成 Agent 能可靠执行的最小单元，然后用工程手段串起来。

这条赛道目前还没看到真正的壁垒——壁垒不在模型能力，在于谁先把特定行业的改编知识和质量标准结构化沉淀下来。