AI短剧Agent在 0.0.1 版本阶段要验证的，往往不是“能不能写出爆款剧本”，而是“从一句题材描述到一份可编辑的剧本框架，这条 Agent 链路到底能不能稳定跑通”。这篇博客围绕一次以“72小时的反击，看姐重夺公司控制权”为测试题材的 AI 短剧 Agent 效果测试，拆解 0.0.1 版本的目标范围、系统设计、评测指标、执行结果、问题排查和改进方向。适合正在做 Agent 应用开发、短剧剧本工具、大模型内容生成产品，或者准备搭建内容生成评测体系的开发者参考。

1. 先界定一个问题：AI短剧Agent到底要解决什么

1.1 短剧创作流程中哪些环节值得Agent化

短剧剧本生产有一个明显特征：环节多、重复度高、对结构的要求很强。一部女频逆袭短剧从题材到可拍剧本，通常要经过题材定位、人物设定、主线设计、分集大纲、场景拆分、单集台词、冲突点布置、钩子设计、质检修改这些步骤。传统做法里，这些步骤由编剧和策划人工串联，效率瓶颈往往不在单点写作能力，而在“把想法转成符合结构要求的剧本框架”这个重复性工作上。

AI Agent 在这里的价值不是替代编剧，而是把“从想法到结构化剧本框架”的链路自动化。和单纯用大模型对话生成剧本相比，Agent 的差异在于：它可以拆任务、调工具、维护中间状态、按结构化格式输出。比如先理解题材类型，再生成人物关系，再按短剧的“开头三集铺垫、中段冲突升级、结尾反转”结构拆分集数，最后输出一份可以被后续人工编辑的 JSON 剧本骨架。

0.0.1 版本做技术选型时，要避免两个极端。一个极端是只用一个几百字的 Prompt 让模型直接输出完整剧本，结果看起来热闹，但结构松散、人物行为前后矛盾、分集节奏不可控。另一个极端是过早引入复杂框架，比如多智能体协作、全流程自动编排、复杂记忆数据库，结果链路还没跑通先被工程复杂度拖垮。0.0.1 版本的核心任务，是找到一个中间点：用最小可运行的编排结构，验证“输入题材 -> 拆解任务 -> 分步生成 -> 结构化输出 -> 基础质检”这一条主链路。

1.2 0.0.1版本应该限定在哪个范围

版本号的 0.0.1 意味着什么？在内容生成类 Agent 项目里，它通常表示：功能链路已经能跑通，但稳定性、内容质量、边界条件都还没有经过充分验证。这个阶段不适合追求“完美剧本”，更适合追求“可复现的生成链路”。

本次测试把范围明确为以下几项：

功能模块	0.0.1版本是否包含	说明
题材理解	包含	从一两句题材描述中提取类型、主角、目标、冲突
人物设定生成	包含	生成主角、对立角色、关键配角的背景与动机
剧情主线设计	包含	设计 72 小时倒计时结构、核心冲突、反转点
分集大纲生成	包含	生成 6 集到 10 集的剧情拆分
单集台词生成	部分包含	只生成关键场景台词，不逐句补全
剧本格式输出	包含	输出约定 JSON 结构
自动质检	基础版	检查字段完整性、人物一致性、集数连续性
人工修改工具	不包含	0.0.1 版本交给人工线下编辑

这个范围的意义在于：先把“从题材到分集大纲”这条主干道修通。台词生成、人工协同编辑、多版本对比这些问题，留到 0.0.2 或 0.1.0 再处理。如果 0.0.1 版本就试图覆盖从题材到逐字剧本，测试短板会分散到各个环节，最后很难判断 Agent 链路本身是否可靠。

1.3 0.0.1版本的测试目标不是“生成得好”而是“稳定可用”

内容生成类项目最容易犯的错误，是把“生成效果好不好”当成第一优先级。但效果是有主观性的，同一个剧本给三个编剧看会有三种评价。0.0.1 版本测试必须先把客观标准立住。

测试目标可以拆成三层：

第一层是链路可用性。从输入题材文本开始，Agent 能不能稳定完成所有步骤，并在规定时间内返回结构化结果。如果十次测试有三次超时或报错，效果再好也无法进入产品化。

第二层是结果稳定性。同一个题材、同一组参数，多次运行后，生成结果在结构上应该基本一致，字段齐全，集数合理，人物不“跳变”。

第三层才是基础质量。生成的大纲是否有明确冲突、是否匹配“女频逆袭”题材、72 小时倒计时压力是否得到体现、结尾是否有反转。

所以 0.0.1 版本测试报告里，需要同时记录功能成功率、超时率、结构化解析失败率、内容评分四类数据。只看内容评分不看链路稳定性，会高估系统成熟度。

2. 0.0.1版本Agent的架构设计与关键实现

2.1 用最小编排结构串联剧本生成链路

本次测试的 Agent 没有设计复杂的多智能体协作，而是采用了一个“主控编排 + 多步骤生成 + 基础质检”的结构。主控负责拆解任务、管理上下文、控制输出，各个生成步骤可以理解为一段独立的 Prompt + 结构化输出约定。

整体数据流如下：

输入题材文本
-> 步骤1：题材解析，输出类型、主角、冲突关键词
-> 步骤2：人物设定，输出人物信息 JSON
-> 步骤3：主线与结构设计，输出剧情线 JSON
-> 步骤4：分集大纲生成，输出每集摘要 JSON
-> 步骤5：质检组件检查 JSON 结构、集数、人物一致性
-> 最终输出完整剧本框架 JSON

这种设计有几个好处。第一，每个步骤的 Prompt 职责单一，出现问题容易定位。第二，步骤之间通过 JSON 传递中间结果，方便人工检查“是哪一步开始跑偏的”。第三，主控可以随时插入日志、重试、兜底逻辑。

2.2 主控代码：一个极简 Agent 运行器

下面是一个用于演示思路的极简 Python 实现，重点不是完整产品代码，而是展示主控如何串联多步生成任务。实际项目中需要接入具体模型 SDK、配置密钥、日志系统和错误处理。

import json
import time

from llm_client import chat_completion  # 假设的模型调用封装

class ShortDramaAgent:
    def __init__(self, model_name: str, max_retries: int = 2):
        self.model_name = model_name
        self.max_retries = max_retries
        self.workspace = {}

    def run_step(self, step_name: str, prompt: str, parse_json: bool = True):
        for attempt in range(self.max_retries + 1):
            try:
                raw = chat_completion(prompt, model=self.model_name)
                if parse_json:
                    return json.loads(raw)
                return raw
            except json.JSONDecodeError:
                log.warning("%s 解析JSON失败，第 %s 次重试", step_name, attempt + 1)
            except Exception as exc:
                log.error("%s 调用异常: %s", step_name, exc)
        raise RuntimeError(f"步骤 {step_name} 连续失败")

    def generate(self, topic: str) -> dict:
        parse_prompt = build_topic_prompt(topic)
        topic_info = self.run_step("题材解析", parse_prompt)

        character_prompt = build_character_prompt(topic_info)
        characters = self.run_step("人物设定", character_prompt)

        plot_prompt = build_plot_prompt(topic_info, characters)
        plot_line = self.run_step("主线设计", plot_prompt)

        episode_prompt = build_episode_prompt(topic_info, characters, plot_line)
        episodes = self.run_step("分集大纲", episode_prompt)

        result = {
            "topic_info": topic_info,
            "characters": characters,
            "plot_line": plot_line,
            "episodes": episodes,
            "created_at": time.time(),
        }
        self.workspace = result
        return result

agent = ShortDramaAgent(model_name="gpt-4o-mini")
result = agent.generate("女频逆袭：72小时的反击，看姐重夺公司控制权")

关键点在于 run_step 方法中的重试逻辑。内容生成类 Agent 最常见的失败不是模型调用崩溃，而是模型返回文本无法被 JSON 解析。0.0.1 版本必须把“JSON 解析失败自动重试”作为基础能力。如果连续两次失败，宁可让整个任务失败，也不要把脏数据继续传给下一个步骤，否则错误会一路传染。

2.3 提示词与模型参数：效果测试必须固定的变量

0.0.1 版本效果测试的一个重要原则是：控制变量。同一个测试题材，如果每天修改 Prompt 或模型参数，得到的测试结果没有可比性。因此，测试前要把 Prompt 模板和模型参数固定下来，并记录在测试报告中。

以“分集大纲生成”步骤为例，Prompt 模板需要包含以下信息：

你是一名短剧编剧助手。请根据以下人物设定和剧情主线，生成一部女频逆袭短剧的分集大纲。

题材类型：女频逆袭
倒计时设定：72小时
主角目标：夺回公司控制权
人物设定：{characters_json}
剧情主线：{plot_line_json}
生成要求：
1. 输出集数：8集
2. 每集包含：集数、时间点、核心冲突、主角行动、钩子
3. 第1集必须建立主角困境
4. 第3集到第5集必须出现至少一次冲突升级
5. 最后一集必须完成反转和阶段性胜利
6. 输出严格符合以下JSON结构：{episode_schema}

请直接输出JSON，不要输出额外说明。

这里的关键不只是写清需求，还要给模型一个明确的 JSON Schema 约束。

{
  "episode_count": 8,
  "episodes": [
    {
      "episode": 1,
      "time_point": "第1小时",
      "core_conflict": "描述该集核心冲突",
      "protagonist_action": "主角在本集采取的行动",
      "hook": "本集结尾钩子"
    }
  ]
}

模型参数方面，推荐固定使用低温度。原因在于：短剧剧本需要情节具有一定的可预期稳定性，温度过高会导致同一题材每次生成的人设、冲突差异过大；温度过低又容易让剧情变得平淡。0.0.1 版本测试建议使用 0.4 到 0.6 之间的温度，并在测试报告中记录实际值。

参数	推荐值	调高的影响	调低的影响	使用场景
temperature	0.4 - 0.6	情节更发散，但结构容易不稳定	结构更稳定，但可能缺乏亮点	0.0.1 版本测试
max_tokens	4096 或以上	可以生成更长内容，但成本增加	可能截断，导致 JSON 不完整	分集大纲步骤
top_p	0.8 - 0.9	词汇多样性更高	更保守，重复词可能增加	台词生成
response_format	json_object 或 json_schema	保证输出可结构化解析	无法使用时不保证格式	全链路

还需要注意：不同模型对 JSON 指令的遵守程度差异很大。有的模型在普通聊天模式下不稳定输出 JSON，但用了 json_object 模式后明显改善。测试 0.0.1 版本前，建议先做一个 5 次到 10 次的“JSON 输出稳定性小实验”，确认当前模型在目标 Prompt 下能稳定输出可解析 JSON，再进入正式测试。

2.4 记忆与上下文：0.0.1版本不追求复杂记忆库

热搜词里经常出现“Agent 记忆”，很多项目一上来就接入向量数据库做长期记忆。0.0.1 版本不建议这么做。短剧生成任务的特点是一次性生成、上下文长度有限，主控把前序步骤的 JSON 结果拼进后续 Prompt 就能满足需求。这个阶段引入向量记忆库，反而会引入检索不准、内容串味、调试复杂等问题。

真正要注意的是步骤间上下文传递。比如人物设定步骤生成了“女主角林晚，32岁，曾是创始人，被亲弟弟联合投资人夺权”，那么在生成分集大纲时，人物信息必须完整传给下一步。如果某个步骤的 Prompt 只传了“女主角”三个字，模型很可能重新发明一个人设，导致前后不一致。

因此，0.0.1 版本的“记忆”实际上就是 workspace 里的中间 JSON。只要主控代码保证每个步骤的 Prompt 都带上了必要的上下文，并且质检组件检查前后人物姓名、动机、目标是否一致，就不需要复杂记忆库。

3. 效果测试方案：指标、样本与评分方法

3.1 测试题材：为什么选择“72小时的反击，看姐重夺公司控制权”

本次测试选取的题材是典型的“女频逆袭”类型，并且自带一个强约束：72小时倒计时。这个约束非常适合测试 Agent 的结构控制能力。

如果题材没有时间压力，模型在生成剧情时容易写成流水账，今天不行明天再来，冲突缺乏紧迫感。而“72小时”这个设定要求 Agent 在生成分集大纲时，必须把时间压力和每一步行动绑定起来。比如第 1 集开场就必须让主角发现被夺权的事实，并决定在 72 小时内反击；中间每一集都要有一个明确的时间节点，不能出现“两周后”这种破坏设定的描述。

同时，“重夺公司控制权”是一个具体、可量化的目标，这为人物行为设计提供了明确方向。Agent 判断每一步行动是否合理时，核心标准就是：它是否推进了“重夺控制权”这个目标。

输入题材可以精确定义为：

女频逆袭短剧，主角林晚被亲弟弟林峰联合投资人顾城夺走公司控制权，
她从 72 小时内发起反击，最终重新掌控公司。要求突出女性独立、
逆袭爽感、家庭背叛、商业博弈和强反转。

这段输入包含人物关系、核心冲突、时间限制、情绪需求四个要素，足以支撑 0.0.1 版本的多轮生成测试。

3.2 评测指标：从结构和内容两个维度打分

内容生成类 Agent 的评分不能只靠“感觉”。本次测试把指标拆成两部分：自动化检查指标和人工评分指标。

自动化检查指标用于判断 Agent 链路是否稳定：

指标	计算方式	0.0.1版本达标线
任务成功率	成功返回完整 JSON 的任务占比	90%
平均耗时	从输入到输出完整结果的耗时	单任务不超过 90 秒
JSON 解析成功率	第一步生成的中间结果可被 json.loads 解析	95%
集数正确率	生成的集数等于设定的 8 集	95%
人物一致性通过率	各集中主要人物姓名与人物设定一致	90%

人工评分指标用于衡量内容质量。采用百分制，按权重加权：

1. 结构完整度（30 分）：是否有明确的开端、冲突升级、反转、阶段性胜利。
2. 剧情逻辑（25 分）：人物行为是否符合动机，时间线是否符合 72 小时设定，是否出现明显逻辑瑕疵。
3. 台词质量（15 分）：关键场景台词是否体现人物立场和情感，避免书面化、口号化。
4. 题材符合度（15 分）：是否符合“女频逆袭”爽感逻辑，是否突出重夺公司控制权的核心冲突。
5. 可拍性（15 分）：大纲是否清晰到能直接转成拍摄脚本，场景、对话、动作是否具体。

3.3 评分方式：人工评审加多轮采样

人工评分的最大风险是主观性。为了降低单次评分波动，建议采用“双人独立评分 + 取平均”的方式。每个测试样本至少由两位对短剧结构有基本了解的人评分，分差超过 15 分时重新讨论。0.0.1 版本是小规模测试，可以允许这种重评机制存在；进入更大规模测试后，需要先做评分一致性校准。

采样策略也需要固定。每个测试题材至少执行 5 次生成，不能只取一次结果。原因是语言模型存在随机性，一次生成效果好可能是偶然，5 次结果才能反映稳定性。评分时统计平均值、最低分、最高分和标准差。

注意：0.0.1 版本的测试数据量少，不要用单次结果下结论。测试报告的结论应该表述为“在 5 次采样内，该 Agent 在结构完整度上表现稳定”，而不是“该 Agent 能生成高质量剧本”。

4. 执行测试：一次完整生成与评分过程

4.1 测试环境与固定参数

执行测试前，先把环境固定下来。本次测试使用 Python 3.10 编写的极简 Agent 运行器，模型通过 OpenAI 兼容接口调用，模型名为固定版本。测试期间不修改 Prompt 模板，不调整 temperature、max_tokens 等参数。

python -m venv venv
source venv/bin/activate
pip install openai python-dotenv

python run_test.py --topic "72小时的反击，看姐重夺公司控制权" --episodes 8 --times 5

run_test.py 中需要记录每次任务的中间步骤耗时、最终输出 JSON、错误日志，并输出一个 CSV 文件供评分使用。生产级测试环境还需要记录模型调用 token 数、单步延迟、失败重试次数，这些数据在优化成本时非常关键。

4.2 一次生成结果示例

下面是一次生成的中间结果，经过格式化展示。这里仅展示关键内容，用于还原测试过程中实际看到的数据形态。

人物设定部分：

{
  "characters": [
    {
      "name": "林晚",
      "role": "主角",
      "age": 32,
      "identity": "原公司创始人兼CEO",
      "motivation": "被亲弟和投资方联合夺权，要夺回公司控制权",
      "weakness": "过于信任亲人，在公司话语权被逐步架空"
    },
    {
      "name": "林峰",
      "role": "对立角色",
      "age": 28,
      "identity": "林晚亲弟弟，现任临时CEO",
      "motivation": "证明自己比姐姐强，获得投资人认可",
      "weakness": "能力不足，依赖顾城资金和资源"
    },
    {
      "name": "顾城",
      "role": "关键盟友/潜在对立",
      "age": 35,
      "identity": "投资人，持有公司股份",
      "motivation": "获取公司核心业务的控制权",
      "weakness": "低估林晚在团队中的影响力"
    }
  ]
}

分集大纲部分：

第1集：林晚在公司董事会现场发现股权被转移，弟弟林峰联合顾城宣布她出局。
第2集：林晚复盘公司核心客户资源，发现关键几位高管还站在自己这边。
第3集：顾城向董事会提交新业务方案，林晚通过旧部获取方案中的致命漏洞。
第4集：林峰试图在媒体上抹黑林晚，林晚晒出多年经营数据反击。
第5集：顾城压住供应商账期，林晚利用个人担保稳住供应链。
第6集：林晚召开线上董事会，公布股权代持协议的关键证据。
第7集：顾城最后反扑，试图冻结林晚账号，林晚提前完成资产隔离。
第8集：72小时倒计时结束，林晚重新掌握公司控制权，并给了林峰一个重新选择的机会。

这个结果从结构上看是成立的，因为它满足了 72 小时倒计时、逐集冲突升级、最后一集反转的基本要求。但注意，这个结果是在理想情况下模型给出的，测试中也会出现结构残缺或内容跑偏的情况。

4.3 自动化检查结果与人工评分统计

以 5 次生成为例，运行数据可能呈现如下形态：

样本编号	任务是否成功	耗时(秒)	JSON可解析	输出集数	人物一致性	结构完整度	剧情逻辑	题材符合度
1	是	42	是	8	通过	26	22	13
2	是	38	是	8	通过	28	21	14
3	是	55	是	8	不通过	24	18	12
4	否	78	否	-	-	-	-	-
5	是	39	是	8	通过	25	20	13

这份模拟数据说明，链路整体能跑通，但第 4 次出现失败，第 3 次出现人物一致性不通过。把这些数据放进测试报告，比单纯输出一句“效果不错”有价值得多。

注意：上面表格是用于演示统计方法的模拟数据，不代表任何真实模型的固定表现。不同模型版本、不同 Prompt 模板、不同随机种子下，结果会有明显差异。实际上线前必须用当次测试执行的真实数据替换。

5. 测试中出现的典型问题与排查路径

5.1 问题现象、根因与解决方案对照

0.0.1 版本测试中比较典型的问题集中在下面几类。整理成表格方便对照处理。

问题现象	可能根因	定位方式	解决方案
中间步骤返回内容无法 JSON 解析	模型输出附带解释性文本，或 JSON 被截断	打印原始返回内容，检查结尾是否完整	开启 json_object 模式，增加 max_tokens，加入解析失败重试
后一集人物姓名与人物设定不一致	人物设定没有完整传递到后置步骤	比较各集 JSON 中的人物字段	在分集大纲 Prompt 中强制加入人物设定原文
72小时设定被破坏	Prompt 只写了“72小时”，没有要求每集标出时间点	检查生成大纲中是否出现“两周后”	在 JSON Schema 中增加 time_point 必填字段
剧情冲突平淡，变成流水账	主线设计步骤没有明确“最大阻力”和“关键转折”	查看主线设计 JSON 是否包含反派阻挠点	在主线 Prompt 中强制生成“阻力事件”列表
部分任务超时	模型响应慢、重试次数多、单次生成 token 数过高	查看单步耗时和重试日志	降低 max_tokens，或对生成步骤启用流式输出
总让人物“口头胜利”	缺少对具体动作的要求	检查剧情事件是否缺少信息、资源、人脉层面的动作	在 Prompt 中要求每集至少有一个可执行行动

5.2 三个容易忽略的坑

第一个坑：把所有希望压在“更长的 Prompt”上。0.0.1 版本测试中，如果发现模型生成结果不符合预期，第一反应往往是继续增加规则。但 Prompt 过长会稀释关键信息，模型很容易忽略中间部分的约束。更合理的做法是把核心约束前置，并把结构化要求写进 JSON Schema。例如要求每集必须包含 time_point，可以让模型在输出时自行校验时间点是否符合 72 小时设定。

第二个坑：忽略失败任务的数据价值。测试中有一个任务失败了，如果把它直接丢掉，只统计成功样本，会高估系统可用性。失败任务的错误日志、卡在哪个步骤、重试几次后失败，都是 0.0.1 版本最有价值的改进依据。每次失败都应该沉淀为一条问题记录。

第三个坑：用“看起来像剧本”来替代结构校验。模型生成的文本如果文笔流畅，很容易让人忽略它实际缺少关键结构。比如人物设置完整，但每集没有钩子；又比如主线明确，但时间点含糊。这种问题靠人读很难全量发现，所以 0.0.1 版本必须配置自动化检查脚本，至少校验 JSON 字段是否齐全、集数是否符合预期、每个字段是否为空。

5.3 从输入到输出的排查链路

当一次生成结果不符合预期时，建议按以下顺序排查，不要直接修改 Prompt：

1. 检查输入与参数。题材文本是否包含了足够的信息？temperature 是否被误改？max_tokens 是否导致输出截断？
2. 检查中间结果。题材解析输出是否准确？人物设定是否存在自相矛盾？主线设计是否完整？这一步是整个链路最容易出问题的位置。
3. 检查 Prompt 模板。当前步骤的 Prompt 是否引入了上一步的正确数据？JSON Schema 是否被完整传入？
4. 检查原始模型返回。直接查看模型原生返回内容，判断是内容错误还是解析错误。如果是解析错误，调整 JSON 输出模式；如果是内容错误，调整对应步骤的 Prompt。
5. 检查随机性影响。同一输入多跑几次，判断问题是偶发还是稳定复现。偶发问题优先加强重试和兜底，稳定问题优先修改模板和参数。

这套排查顺序的核心逻辑是：先确认链路正确，再怀疑单点输出。不要一上来就重写 Prompt，否则可能修好一个点，又把另一个点弄坏。

6. 0.0.1版本结论与下一步迭代方向

6.1 本次效果测试的结论

回到最初的目标，0.0.1 版本需要回答的问题是：AI 短剧 Agent 的编排链路是否能稳定跑通。从测试结果看，答案是“基本可以，但仍需要加固”。

优点集中在架构层面。步骤拆分、JSON 传递、主控重试这套设计能够保证大部分情况下生成出结构完整的剧本框架。用户只需要输入一句含题材、人物关系、目标、时间限制的描述，Agent 就可以输出一份可供编剧修改的 8 集分集大纲。

短板主要集中在内容质量和稳定性两个方向。内容上，剧情冲突密度不够，台词质量偏弱，模型生成的爽感更多来自设定而不是具体情节；稳定性上，失败任务和人物一致性跨越任务时的波动还没有完全消除。0.0.1 版本距离把“大纲直接转成可拍摄剧本”仍有明显差距。

6.2 0.0.2版本应该优先做什么

下一版本建议按优先级推进三件事。

第一，结构化输出全面升级。从“让模型尽量输出 JSON”升级为“使用 JSON Schema 严格限制每一步的输出字段”，从源头减少解析失败和数据缺失。

第二，人物一致性检查组件化。独立出一个质检步骤，专门对比各分集中的人物姓名、角色关系、动机是否与人物设定一致，发现不一致时自动触发重新生成该步骤。

第三，引入冲突密度指标。在评分指标中增加“每集有效冲突数量”和“冲突升级路径”检查，推动模型在生成时主动设计阻力事件，而不是让主角一路顺风。

更长远的方向可以包括：多版本对比生成、人工修改痕迹回灌、素材库检索增强，以及与 MCP 工具的结合。但进入这些方向前，需要先让 0.0.1 版本暴露出来的链路问题全部收敛。

6.3 学习环境与生产环境的差异

本次测试是在学习验证环境里完成的。如果要把 AI 短剧 Agent 推上生产环境，还需要补齐大量工程能力。

能力	学习验证环境	生产环境要求
模型调用	直连单模型，失败重试 2 次	多模型路由、熔断、降级、成本统计
密钥管理	本地环境变量	密钥管理服务，禁止写入代码仓库
中间结果存储	内存字典	持久化到数据库或对象存储，支持回溯
日志	打印到控制台	结构化日志、链路追踪、耗时上报
评分	人工填表	在线标注平台、评分一致性校验、自动化审核
内容安全	未重点处理	必须叠加内容审核、敏感词过滤、人工抽检
回归测试	手动执行	自动化测试集，每次修改 Prompt 后全量回归

内容安全是生产环境绝对不能跳过的一环。AI 生成剧本涉及人物关系、商业冲突、家庭矛盾等题材，在正式上线前必须叠加合规审核。自动化生成内容不能直接发布，需要人工编辑和审核流程兜底。

6.4 可复用的Agent效果测试清单

最后整理一份可直接复用的测试清单，方便其他团队做 0.0.1 版本效果测试时参考。

1. 版本范围清单：明确当前版本做什么、不做什么，避免测试口径混乱。
2. 控制变量清单：固定模型版本、Prompt 模板、模型参数、测试题材。
3. 链路数据清单：记录每个步骤的耗时、重试次数、token 数、原始输出。
4. 自动化检查清单：JSON 是否可解析、字段是否完整、集数是否正确、人物是否一致。
5. 人工评分清单：结构完整度、剧情逻辑、台词质量、题材符合度、可拍性。
6. 失败记录清单：保留失败样本、失败步骤、错误日志、重试次数、修复动作。
7. 回归测试清单：每次改动 Prompt 或参数后，至少用同一题材跑 5 次采样。

0.0.1 版本的定位是验证链路，不是交付成品。只要链路稳定、数据可追溯、问题可复现，这个版本就已经完成了它的使命。真正的内容质量提升，会在后续版本通过更精细的结构控制、更完善的质检组件和更丰富的剧本数据积累逐步实现。