在完成前一阶段的公开数据适配、中文种子样本设计以及 ActionParser 基础任务定义之后，StoryVerse 项目的推进重点进一步从“任务可行性验证”转向“可用于正式微调的高质量训练数据构建”。这一阶段的核心问题不再只是“模型要做什么”，而是更具体地变成了：“我们究竟应该用什么样的数据去训练它，怎样才能让训练数据既贴合小说场景，又在工程上可控、可扩展、可持续维护”。

        围绕这个目标，本阶段我主要完成了以下几项关键工作：首先对齐并固定了 ActionParser 的输出格式；随后重新调整了 preprocess_sgd.py 和 preprocess_hermes.py 两个数据预处理脚本；接着从项目整体设定出发，确定了后续训练所依托的四部小说，并规划了训练集、验证集、测试集的来源方式；之后重点投入到原始小说文本的样本清洗工作中，初版清洗脚本一度生成了一万多条候选样本；为解决标注成本问题，我又继续设计并尝试了半自动标注和全自动标注两条路线，最终在实践中发现全自动化标注效果较差，因而重新回到半自动标注方案，同时进一步重写清洗逻辑，以优先提升候选样本质量，最终将高精度候选控制在 946 条左右，并正式进入人工半自动标注阶段。

        这一系列工作看似分散，但本质上是在解决同一个问题：如何为 StoryVerse 的ActionParser 模块构建一套真正适用于中文小说交互场景的高质量训练数据生产流程。

---

一、先固定接口，再做数据：ActionParser 输出格式的重新对齐

        在这一阶段开始时，我首先处理的并不是小说数据本身，而是 ActionParser 的输出结构。原因很直接：如果目标输出格式本身不稳定，那么后续所有预处理、清洗、标注乃至模型训练都会建立在一个不牢固的基础上，最终会导致脚本反复改、样本不断返工，整体开发成本非常高。

        因此，我先对 ActionParser 的输出格式进行了重新对齐，把模型最终需要生成的结果固定为统一的结构化 JSON 形式，使其更符合 StoryVerse 后续系统调用和多智能体联动的需求。这个过程的关键不只是“规定输出长什么样”，而是要确保这个结构既足够简洁，方便模型学习，又足够明确，能够承载小说交互中的关键语义信息。

        从项目目标来看，ActionParser 的职责不是生成长文本解释，而是把用户输入的自由文本转化为系统可消费的结构化动作描述。因此，输出格式设计上强调了三点：第一，字段尽量固定，避免训练目标过于发散；第二，动作语义必须足够明确，保证后续角色代理和剧情引擎能够直接使用；第三，格式必须容易验证，便于后续自动检查和批量标注。在这个基础上，后续无论是对 Hermes/SGD 数据做映射，还是对小说句段做人工标注，都有了一个统一的目标模板。

        这一步虽然不像训练那样直观，但实际上它相当于先把整个数据生产线的“接口协议”确定下来。只有接口稳定，后面的预处理和标注脚本才不会陷入反复推翻重来的状态。

---

二、重新调整公开数据预处理脚本：让已有资源真正服务当前任务

        在输出格式重新对齐之后，我继续回过头来调整前期已经使用过的两个预处理脚本：preprocess_sgd.py 和 preprocess_hermes.py。之所以要重写或重调，而不是沿用之前版本，是因为当时的脚本更多只是为了做任务探索与格式试验，而现在项目已经进入了更明确的数据构建阶段，脚本必须真正服务于统一的 ActionParser 输出结构，而不能只是“能处理数据”。

        对这两个脚本的调整主要围绕几个方向展开。

        首先，是字段映射逻辑的统一化。Hermes 和 SGD 原始数据的组织方式并不一致，一个更偏指令跟随与工具调用风格，一个更偏任务型对话和意图槽位结构。因此，如果不做统一处理，两类数据即便都能转成 JSON，也会在动作定义、目标对象表达、内容字段粒度上存在明显差异。为了解决这个问题，我重新梳理了两套脚本中“输入文本—动作类型—目标对象—内容载荷”的映射规则，让它们最终都朝着同一套 ActionParser 模板收敛。

        其次，是异常样本和低价值样本的过滤。在实践中我逐渐发现，公开数据集中有不少样本虽然技术上可以被转换格式，但对 StoryVerse 的目标任务并没有太大帮助。例如，一些样本过于偏向现实工具调用、事务性服务场景，或者语义中心并不在动作本身，而是在复杂背景说明、上下文依赖甚至元任务控制。这类样本如果大量混入训练集，模型可能会学到与小说交互并不一致的行为模式。因此，脚本调整中也加入了更明确的筛选逻辑，尽量保留对“自然语言转动作结构”更有帮助的部分。

        再次，是输出一致性和可检查性。新的预处理脚本不只是为了生成数据文件，更重要的是为后续人工审查、质量检查和训练调试提供稳定输入。这意味着脚本生成的每一条样本都应当尽量结构统一、字段规范，便于批量查看和后续人工修订。

        可以说，这一步的意义在于把“公开数据能不能用”这个问题，推进成“公开数据怎样才能以受控方式为本项目服务”。它不是为了扩大数据量，而是为了在项目早期建立起一套可持续的数据处理标准。

---

三、确定四部项目小说，并规划训练集、验证集、测试集来源

        在公开数据之外，本阶段一个更重要的推进是：我开始真正围绕 StoryVerse 自身的小说场景来建设训练数据来源，而不是继续停留在通用数据适配层面。

        基于项目整体设计，我最终选取了四部小说作为后续数据构建和实验的主要语料来源。这一步非常关键，因为它意味着 ActionParser 的训练目标开始真正从“通用自然语言理解”转向“小说世界中的动作理解与结构化表达”。

        选取小说作为核心训练来源时，我主要考虑了几个维度。

        第一，是作品本身是否具备较丰富的角色互动和情节推进内容，因为 ActionParser 的训练重点不是静态描写，而是人物在场景中的言语、行为、观察、接触和互动。

        第二，是文本是否适合转化为“可操作行为”的候选样本，也就是说，小说中要有足够多可以被抽取为动作表达的片段。

        第三，是多部作品之间要尽量覆盖不同风格和不同类型的叙事情境，以避免模型只适应某一类固定表达。

        在数据集划分思路上，我没有把训练、验证、测试简单理解为随机拆分文本，而是更偏向从作品和场景分布的角度考虑数据来源。这背后的想法是：如果只是句子级随机切分，那么训练集和测试集可能在表达风格、角色语气甚至具体场景模式上高度重叠，评估结果会显得过于乐观。相对而言，以小说来源、章节范围或情节段落为边界进行更有意识的划分，更能检验模型是否真正学会了“动作解析能力”，而不是只记住了某类固定表达模板。

        因此，这一阶段确定四部小说，不只是“选了几本书”这么简单，而是在为后续的训练数据质量、泛化能力评估和任务真实性打基础。

---

四、从原始小说到候选动作样本：初版清洗脚本一次产出一万多条数据

        在小说来源确定之后，我开始编写针对原始小说文本的清洗与候选样本生成脚本。这部分工作是整个阶段中最耗精力的一环之一，因为它直接决定了后续标注工作的上限和成本。

        小说原文并不是天然适合训练 ActionParser 的数据。和任务型对话或指令数据不同，小说文本中包含大量环境描写、心理活动、叙述补充、转场说明、背景铺垫和修辞性表达，而我们真正想要的，是其中那些具有明确交互意义、动作意义或可结构化表达价值的片段。因此，所谓“清洗”，本质上不是简单去掉标点和空行，而是要从一整段小说叙事中筛出更适合作为动作解析训练样本的内容。

        在初版清洗脚本中，我采用了相对偏“宽召回”的思路。也就是说，先尽可能多地保留潜在有价值的句段，让脚本优先把可能涉及说话、移动、观察、互动、使用物体、等待等行为的文本都提取出来，再在后续阶段通过标注或筛选进一步处理。这样做的好处是可以避免过早丢失有价值样本，但问题也很快显现出来：脚本最终生成了一万多条候选数据。

        从数量上看，这似乎是一个很“丰富”的结果，但真正进入人工查看后，我发现其中存在明显问题。大量候选虽然满足了形式上的筛选条件，却未必真的是高质量 ActionParser 训练样本。有些句子只是叙述性很强的旁白，不适合作为用户动作输入；有些句子动作边界模糊，很难标注为清晰的结构化输出；还有些句段语义过于依赖上下文，单独拿出来并不能形成稳定样本。也就是说，初版清洗脚本虽然提升了覆盖率，却没有很好控制精度。

        这也让项目进入了一个很现实的工程问题：如果继续沿着高召回路线走，后续标注成本会非常高，且数据质量难以保证。

---

五、先做半自动标注，再尝试全自动标注：用实践验证哪条路线可行

        面对一万多条候选样本，仅靠纯人工逐条标注显然效率太低，因此我开始设计更可落地的标注流程。最初的想法是采用半自动标注：由脚本先完成样本预整理和部分格式预填充，再由人工进行快速审核、修正和确认。这个方案的优势在于，一方面保留人工对高质量输出的把控，另一方面也能减少机械性的重复劳动。

        在半自动标注脚本的设计中，我重点考虑了几个方面。首先，脚本要能把原始句段整理成便于人工处理的统一格式，而不是让标注者面对未经整理的大段原文。其次，脚本需要尽可能提前生成一些可参考信息，例如候选动作类型、提取出的潜在目标对象或建议输出框架，帮助人工更快完成判断。再次，标注结果必须能被直接保存为后续训练可用格式，避免人工标注后还要再做二次转换。

        但由于初版候选数据实在太多，我随后也尝试过进一步推进到全自动标注。其出发点很自然：如果可以通过规则、模板匹配或模型辅助，把大批候选样本直接自动生成为带标签数据，那么数据规模就可以快速扩大，人工只需要做少量抽查和修正，整体效率会显著提高。

        从工程角度看，我当时希望全自动标注至少能解决两个问题：一是降低人工负担，二是加快训练集成型速度。因此，这条路线并不是随意尝试，而是基于“数据太多、纯人工不可持续”的现实压力做出的探索。

---

六、全自动标注效果不理想：问题不在数量，而在语义复杂度

        不过，在实际测试和结果检查之后，我很快发现全自动标注的效果并不理想。问题的根本不在于脚本“能不能输出 JSON”，而在于它输出的标签质量与小说语境之间存在明显偏差。

        首先，小说文本的动作表达往往不是标准命令句，而是混合着人物语气、上下文暗示、叙述修饰和含蓄表达。自动化规则在面对这种复杂语义时，容易出现动作类型误判、目标识别不准、内容字段泛化过度等问题。其次，很多句段虽然含有动作成分，但真正的结构化输出需要结合语境做合理抽象，而不是机械地提取动词。第三，过度自动化还容易引入“形式正确但语义错误”的伪高质量样本，这类噪声数据一旦进入训练集，会比数据量不足更危险，因为它会直接影响模型学习方向。

        换句话说，全自动标注的问题不是产出太少，而是产出不够可信。如果基于这类数据直接微调模型，最后得到的不是更强的 ActionParser，而可能是一个学会了大量错误映射关系的模型。

        经过这一轮尝试，我逐渐明确了一点：对于当前阶段的 StoryVerse 项目来说，真正重要的不是“快速制造大量标签”，而是优先保证训练数据的真实性、一致性和任务贴合度。也正因为如此，我最终调整了方案，决定回归半自动标注路线，但前提是不再保留那种“一万多条宽召回候选”的数据入口，而是从源头重构清洗脚本，先把候选质量提上来。

---

七、重新编写清洗脚本：从高召回转向高精度，最终收缩到 946 条高质量候选

        在确定不继续依赖全自动标注之后，我重新回到最上游的数据清洗阶段，对小说样本生成逻辑进行了更彻底的重写。这次的设计思路与初版明显不同：不再优先追求“尽量多抓”，而是优先追求“尽量准”。

        新的清洗脚本开始更强调以下几个原则。

        第一，只保留动作表达相对明确、适合被独立理解的句段。这意味着大量依赖上下文、动作边界不清、更多偏向纯叙述或纯心理描写的文本会被提前过滤掉。

        第二，优先保留与 ActionParser 核心动作空间高度相关的片段。也就是那些更容易映射到说话、移动、观察、互动、使用、等待等核心动作类别的文本，而不是广泛收录所有“看起来像行为”的句子。

        第三，增强规则对小说文本特点的适配性。例如在句段切分、对白识别、叙述性句子过滤、动作触发词识别、长度约束和噪声样本剔除等方面，引入更细致的判断逻辑，使候选样本更接近真实可标注单元。

        第四，控制样本量，使其落在人工半自动标注可承受的区间内。这一点很重要。高质量数据生产不是无限扩张，而是要考虑团队当前的人力和时间成本。在当前阶段，先得到一批质量高、结构稳、可验证的中等规模数据，远比堆出几万条低质量样本更有价值。

        经过重新设计和迭代后，新的清洗脚本最终产出了 946 条高质量候选数据。这个数量和初版一万多条相比大幅下降，但数据质量明显提升，也更适合进入下一步的人工半自动标注流程。从工程视角看，这实际上是一次很重要的路线纠偏：项目从“候选很多但不可控”转向“候选不算多但真正可用”。

---

八、正式进入人工半自动标注：建立可控、可持续的数据生产方式

        在高精度候选样本确定之后，我开始正式进入人工半自动标注阶段。此时，半自动标注的意义与最开始已经不太一样。此前它更多是一种“在海量低精度候选中减少人工成本”的辅助方案，而现在，它变成了一种建立高质量训练集的核心流程。

        当前的半自动标注思路，可以理解为“脚本负责整理和辅助，人工负责判断和定稿”。在具体流程上，候选样本首先由清洗脚本生成统一格式，随后标注脚本将其组织为便于审阅的结构，人工再逐条完成动作类型确认、目标对象判断以及内容字段补充或修正。这样做的优势很明显：

        一方面，人工始终掌握最终质量控制权，可以最大程度避免自动化误标带来的系统性噪声；另一方面，前置脚本已经替代了大量重复整理工作，使得人工时间更多花在真正需要判断的地方，而不是机械复制和格式转换。

        从项目长期推进的角度看，这套流程还有更大的价值。它并不只适用于当前这 946 条数据，而是可以作为 StoryVerse 后续持续扩充 ActionParser 训练集的基础模板。也就是说，这一阶段做出来的，不仅是一批标注数据，更是一套可以复用的数据生产方法：先高精度清洗，再半自动辅助，再人工定标，最后沉淀为统一训练格式。这样的流程虽然不像全自动标注那样追求速度极致，但更符合当前项目阶段对质量和可控性的要求。

---

九、这一阶段的本质收获：不是“做了多少数据”，而是建立了自己的数据构建方法论

        回顾目前的整个推进过程，本阶段最重要的成果，其实并不只是“完成了多少条样本”或“写了多少个脚本”，而是项目终于逐步建立起了面向 StoryVerse 小说场景的 ActionParser 数据构建方法论。

        这个方法论可以概括为一条清晰的技术路线：

• 先固定模型输出接口，确保所有数据都围绕同一目标结构组织；
• 再调整公开数据预处理逻辑，用已有资源服务统一任务定义；
• 接着选取真正贴合项目目标的小说语料，构建本项目自己的训练来源；
• 然后通过清洗脚本从原始叙事文本中筛出候选动作样本；
• 在自动化与人工之间反复试验，最终确定“高精度清洗 + 半自动标注”的现实可行方案；
• 最后在受控样本规模上逐步沉淀高质量训练数据。

        这条路线并不是一开始就完全确定的，而是在实践中不断修正出来的。初版脚本带来了大规模候选，全自动标注暴露了语义误差，重新清洗则推动数据质量提升，最终才形成当前更稳健的方案。也正因为经历了这些试错和调整，这一阶段的工作才真正具有工程价值。

---

十、后续计划：继续完成标注，并进入正式微调与评估阶段

        经过这一阶段的推进，StoryVerse 的 ActionParser 模块已经不再停留在“有想法、有数据源”的阶段，而是开始真正拥有一套可执行、可维护、面向小说场景的数据构建流程。接下来的重点工作，将继续围绕这批高质量候选数据展开，逐步完成人工半自动标注，并基于整理后的训练集、验证集和测试集启动正式的微调实验。

        当数据问题逐步稳定下来之后，项目关注点也会自然转向模型本身，包括微调效果是否稳定、结构化输出是否准确、动作类型划分是否合理、不同小说场景下是否具备泛化能力等。这意味着 StoryVerse 的 ActionParser 开发，正在从“数据工程阶段”正式走向“模型训练与实验验证阶段”。

        可以说，第三阶段的核心意义在于：我们不仅获得了一批更高质量的训练候选，更重要的是，为 StoryVerse 后续的 ActionParser 微调工作，真正搭建起了一条可落地的数据生产路径。