企业官网建设流程全解析

• AI 技能
• AI 评测
• 提示工程
• 人工智能
• 媒体生成

本篇技术指南以仓库 references/eval-rubric.md 为核心骨架，系统梳理 Seedance 2.0 四模态 AI 影视制作流水线中的三层评估体系：面向全部案例的 0-3 通用评分、面向序列状态评估的 V6 0-4 评分，以及 prompt 架构压力测试从architecture-v2-nonlexical迁移到architecture-v3-advisory-length的门禁契约。读者读完将掌握每个评分档位的判定标准、发布阈值、scripts/prompt_architecture_stress.py的 CLI 用法与 JSON 输出字段含义，并能准确区分"确定性机械门禁"与"需要人类评审的语言/创意质量主张"之间的证据边界。

一、评估体系总览：每个 eval 案例必须验证的四件事

rubric 的第一句话定义了本仓库所有评估案例的统一验收维度：激活正确性（activation）、输出结构（output structure）、安全行为（safety behavior）与 prompt 可用性（prompt usefulness）。也就是说，任何一个评估案例都不能只检查"模型是否调对了技能"，还必须同时确认输出的结构是否合格、是否存在安全或合规问题、以及产出是否真的可以直接作为生成 prompt 投入使用。这四个维度共同构成了每次评估的检查清单。

在此基础上，所有 legacy 案例采用 0-3 四档评分，语义如下：

发布门槛：当且仅当每一个 legacy 案例得分至少为 2，且legacy 案例平均分至少为 2.6时，该 release 才算通过。

这里有一个必须反复强调的边界：该模型评委（model-judge）分数只是关于"抽样响应相对已声明断言的证据"，不是语言、文化、作者身份、评审人或渲染能力的认证。特别是，中文、日文、韩文的语言质量主张必须走 references/multilingual-native-review.md 中定义的独立人类评审协议——机器分数永远不能替代它，其规范 fixture 在人类评审完成之前保持pending_native_review状态。

二、V6 Sequence Rubric：序列状态评估的 0-4 评分与发布门槛

当评估对象是**序列状态（sequence-state）**时，评分尺度升级为 0-4 五档，覆盖的范围也从单条 prompt 扩展到了整条序列的连续性：

V6 序列评分要评估的维度清单共 11 项：路由正确性（routing correctness）、故事架构（story architecture）、clip 范围控制（clip-scope control）、实际状态锚定（actual-state grounding）、连续性完整性（continuity integrity）、参考绑定（reference binding）、模式与 surface 选择（mode and surface selection）、端点质量（endpoint quality）、prompt 架构（prompt architecture）、不确定性处理（uncertainty handling）、安全与权利（safety and rights）。这些维度与 references/sequence-project-state.md、references/continuation-handoff.md 等序列文档所定义的工程契约一一对应。

V6 序列发布门槛更为严格，四个条件必须同时满足：

1. 所有关键延续（critical continuation）案例得分均为 4；
2. 没有任何维度得分低于 3；
3. 总体平均分至少为 3.5；
4. 既有的 standalone 行为不得发生回归。

从源码结构看，序列评估相关的约束还与 scripts/sequence_eval_check.py、tests/test_sequence_eval.py 中的行为契约相互印证，例如连续性链检查与 take 对账逻辑（参见 scripts/continuity_chain_check.py、scripts/project_state_check.py）。

三、--strict门禁的真实语义：逐案例的维度下限，而非平均分

rubric 专门澄清了一个容易误解的点：对于scripts/prompt_architecture_stress.py --strict，"no dimension below 3" 指的是每一个skill_formula案例上的每一个适用阻断维度都必须不低于 3，而不是对整条 arm 的维度分数取平均。这意味着即使整条 arm 的平均分很高，只要有一个案例在某个阻断维度上掉到 3 以下，严格门禁就会失败——tests/test_prompt_architecture_stress.py 中的test_strict_rejects_one_subfloor_case_even_when_averages_pass正是对这一语义的回归测试。

v3 门禁还做了两项重要的"去压舱"处理：

• 排除slop_free与length_fit：这两个维度既不计入维度下限，也不计入 arm 总体平均分；
• 保留其分数作为咨询信息：词法标记（lexical flags）与固定长度分段（fixed length bands）仍被报告，但仅作参考。

同时，arm 平均分仍须保持在 3.5 以上；并且当**不同 brief 在实质上不同（materially different）**时，跨案例出现重复或近重复 prompt 将直接判定失败。这一点在测试中有多个对抗性用例验证：test_ten_identical_busker_prompts_for_unrelated_briefs_fail（同一 prompt 套用到 10 个无关 brief 必失败）、test_near_duplicate_with_one_subject_mutation_is_rejected（仅替换一个主语也算近重复）、test_reordered_duplicate_clauses_are_rejected（重排分句仍被识别）。

需要明确的是这个确定性门禁的能力边界：它只捕获结构性失败、相关性失败、显式矛盾失败和重复性失败；它不评判创造力和原创性。比较性的创意质量评估必须依赖盲评模型评估（blinded model evaluation）与母语人类评审（native-language human review）。

四、Advisory Lexical Score：slop_free的词法代理语义

在架构评审报告中，lexical_v1列保留了 JSON 维度名slop_free以维持兼容性。需要理解的是：它是一个固定的词法代理（fixed lexical proxy），不是对"匹配到的词是废话"的判定。

其既有公式为：

max(0, 4 - 1.25 * U - E)

其中：

• U= 在 prompt 中命中的去重列表词条数（distinct listed terms matched）；
• E= 这些词中同时出现在 prompt前 25 个词内的词条数。

报告中的密度（density）定义为每 100 个 tokenizer 词中去重匹配词条数，而不是词频。前 25 词内的额外扣分被明确标注为历史测试权重（historical test weight），不是测量的模型 token 重要性——这一点在 scripts/prompt_architecture_stress.py 的lexical_flags与_score_lexical_flags实现中可以看到：score = 4.0 - 1.25 * len(hits) - 1.0 * len(head_hits)，注释明确写着 "Historical regression weights, not measured model token importance"。

每条 JSON 结果会附带lexical_review字段，包含：

• metric：legacy-lexical-v1
• matched_terms：命中的词条
• early_matched_terms：前 25 词内命中的词条
• unique_terms_per_100_words：去重密度

两个布尔字段的语义必须准确理解，否则容易误读报告：

• context_assessed: false表示扫描器没有判断某短语在此 brief 中是否有用；
• rewrite_recommended: false表示扫描器自身不推荐重写，但这不等于认证该 prompt 不需要修改；
• 空匹配列表只表示"列表中的词一个都没匹配到"，不表示prompt 是原创的或优质的。

为何词法扣分不足以做上下文判断

rubric 给出了一张关键对照表，说明哪些场景下词法扣分是不充分的：

因此，对标记语言的审查必须对照 brief 与 references/anti-slop-lexicon.md 进行，并保留精确台词、参考绑定、有用的风格选择与交付要求。匹配器不会豁免引号内的文本，也不会推断意图——单纯的关键词例外机制无法构成一个上下文感知的创意评审器。这一立场在测试LexicalEvidenceTests中被固化：对("Chosen cinematic look with the existing locked framing.", "Make it cinematic.")这类配对，两者得到的词法标记完全相同，但context_assessed都是 false——扫描器必须诚实地暴露自己无法区分。

五、Previous Gate：architecture-v2-nonlexical

理解 v3 之前必须先理解 v2，因为 JSON 输出中的previous_gate字段正是对 v2 行为的保留快照。

v2 迁移做了以下事情：

• 关键词列表、词法公式和每一个独立维度分数全部保持不变；
• JSON 中的overall继续保留包含词法代理在内的 legacy 平均分；
• v2 门禁只排除slop_free，因此固定的词条分段（fixed word bands）仍然影响平均分和维度下限；
• v2 使用非词法下限 3 和 arm 平均 ≥ 3.5；
• 重复与近重复检查仍然阻断，并且对适用模式纳入了引用完整性（reference integrity）。

rubric 特别指出两个"边界感知"要点：

1. 有用的风格标签、带引号的台词或交付目标，不能仅仅因为命中词法列表就导致门禁失败——v2 同样如此；
2. 反之，一个结构有效但挂着泛化形容词堆的 brief 可以通过门禁：该门禁不评判其创意有用性。不相关、显式矛盾、重复、缺少参考绑定，属于独立的失败类别，仍然会被拦截。

冻结语料库（frozen corpus）被保留用于前后对比；迁移测试覆盖"有用的被标记上下文、不变的 legacy 值、剩余的维度下限、不相关或重复的填充、以及真实 CLI 行为"。本质上是改变了一个诊断项的角色，而不是把它变成语义分类器或渲染质量改善的证据。

六、Current Gate：architecture-v3-advisory-length

6.1 冻结的length_fit分段

固定长度分段描述的是冻结的回归启发式，不是普适的 Seedance prompt 预算，也不是完整性测试。legacy 函数的计分规则（在 scripts/prompt_architecture_stress.py 的score_length中逐行实现）：

"under-specified" 和 "over budget" 是历史标签，不是对当前 brief 的发现。因此规则很明确：不要为了满足这些分段而去给一个已完整的短 brief 灌水，也不要为了过门禁而删掉必需的台词。

每条 JSON 结果新增length_review字段：metric为legacy-word-bands-v1，count与unit分别为计数与单位。计数是按空白切分的：它不是模型 token 数，也不是多语言单词数——一个不带空格的中文或日文句子计为 1 个 chunk，一个连写的参考标签同样计为 1 个 chunk。因此不要用它来比较语言效率或设定本地化长度上限。context_assessed、user_limit_assessed、operation_limit_assessed、dialogue_timing_assessed、rewrite_recommended全部为 false：没有执行任何完整性、合规性、时序或重写判断。测试test_report_does_not_certify_limits_timing_or_multilingual_length用("她放下琴弓。", 1)、("彼女は弓を下ろす。", 1)、("그녀는 활을 내린다.", 3)、("Keep @图片1 unchanged", 3)分别验证了计数单位的确切语义。

6.2 固定分段门禁之外的决策矩阵

长度分段门禁覆盖不到的实际情况，需要人工决策，rubric 给出了处理矩阵：

同时必须明确：静态评估器不执行这些用户或平台限制，也无法认证生成就绪。通过它不意味着可以无视某个限制、静默缩短台词、上传素材或花费点数（credits）。

6.3 JSON 字段与 CLI 输出的三套平均值

迁移后的输出契约如下：

• gate_version：architecture-v3-advisory-length；
• gate_dimensions：除slop_free与length_fit之外的适用维度列表；
• gate_overall：这些维度的均值，四舍五入到三位小数；
• previous_gate：保留 v2 的version、dimensions、overall（仅排除slop_free）；
• JSON 中的overall以及所有独立维度分数和备注保留 legacy 含义。

CLI 输出中，gate_v3、prior_v2与legacy三套平均值分别显示（见 scripts/prompt_architecture_stress.py 的main()表格输出）。消费方必须检查版本号，而不是比较定义不同的均值。

6.4 当前门禁条件与迁移测试

最终的门禁规则是：

• 每个案例与每个适用阻断维度得分至少 3；
• 一条 arm 的四舍五入后的案例 gate 分数均值至少 3.5；
• 参考（reference）、相关性（relevance）、显式矛盾（explicit contradiction）、结构（structure）、覆盖（coverage）、开头（opening）、重复（repetition）检查仍然阻断；
• 跨 brief 的重复/近重复检查仍然阻断。

这些是带自身局限的、未变的启发式。移除长度下限及其对均值的贡献，会改变验收行为——即使数值阈值保持不变；prior-v2 平均值只是对照物，不是第二道门禁。

迁移测试的覆盖面包括：一个 40 词以下的完整 brief、一个超过 140 词的提供台词标本、不完整的短文本、重复的长填充、冻结分段边界和 CLI 边界。特别注意：台词标本是离线回归用例，不是"平台能在单个 clip 内交付该段落"的证据；fixtures 与冻结语料库也都不是模型评估、母语评估或渲染评估。

七、源码与测试如何固化这份契约

7.1 压力测试脚本的三 arm 结构

scripts/prompt_architecture_stress.py 对同一批 34 个 brief 评分三个 arm，互相比较：

• naive_online：listicle 或未受训用户会写的样式；
• quickstart_style：v6.6.x 修复前入门示例教过的形态——作为冻结回归 arm 保留，而非当前文档；
• skill_formula：严格按照seedance-prompt的 Director Formula 编写。

该对比是对手写 fixture 的回归检查，不是"某一种方式能产出更好视频"的证据。脚本离线且无依赖，维度与 references/eval-rubric.md 的 V6 尺度一致，共 9 个命名维度：opening_authority（开头权威性：主句内的主语/动作或参考绑定）、length_fit（冻结词条分段）、slop_free（legacy 词法代理）、coverage（机位/有动机的光/声音/可见端点）、structure（散文式拍摄简报 vs 逗号标签沙拉、否定 slop）、ref_integrity（参考模式下标签存在且字节精确）、brief_traceability（brief 特有素材存活进 prompt）、coherence（显式不兼容的机位/光/声音/动作堆叠）、repetition（重复 token、重复短语与填充抵抗力）。

语料库存于 evals/prompt-architecture-stress.json，例如同一 brief "Woman reads a letter and receives bad news" 的三个 arm 呈现了从"cinematic shot of a beautiful woman reading a letter, emotional, dramatic lighting, 4K..."（naive）到 skill_formula 的完整可拍摄段落，直观展示了各维度的评分对象。

7.2 CLI 用法

python scripts/prompt_architecture_stress.py # 对发布语料库评分 python scripts/prompt_architecture_stress.py --strict # 若 doctrine arm 回归则失败退出 python scripts/prompt_architecture_stress.py evals/prompt-architecture-stress.json --strict --out scores.json

• corpus：JSON 语料路径，默认evals/prompt-architecture-stress.json；
• --out：把每条 prompt 的评分写入指定 JSON 文件；
• --strict：任一skill_formula案例/维度低于 3、arm 平均低于 3.5、或实质不同 brief 复用同一 prompt 时非零退出（v3 排除咨询性词法标记与固定长度分段）。

main()还会输出按 arm 汇总的gate_v3/prior_v2/legacy表、按 mode 的 skill_formula gate 均值、以及 gate_v3 最弱的 8 条 skill-formula prompt 及其低分维度。CLI 输出中强制包含边界声明文本："does not judge creativity or originality"、"blinded model evaluation"、"native-language human review"（由test_cli_states_the_deterministic_gate_boundary断言）。

7.3 测试如何保护"不误报"

tests/test_prompt_architecture_stress.py 的开头注释点明了设计动机：第一版评分器曾把仓库自己的 golden prompts 判为缺陷——一个保留源照明的编辑 prompt 被判"没有灯光"，一个用散文绑定已接受素材的延续被判"没有参考绑定"。一个乱报警的检查器会被忽视，因此公平性规则被固化进测试：test_style_dialogue_and_delivery_flags_do_not_fail_otherwise_valid_cases证明合法风格/台词/交付标记不会使原本有效的案例失败；test_each_remaining_dimension_still_has_a_blocking_floor证明每个剩余维度仍保有阻断下限；test_shipped_doctrine_prompts_are_not_near_duplicate_false_positives证明已发布 doctrine prompt 之间不会互相误判为近重复。

从score_prompt的输出结构看，每条结果包含：id、arm、mode、brief、words、dims（各维度 score 与 note）、overall、gate_overall、gate_version、gate_dimensions、previous_gate、ref_note、lexical_review、length_review。其中ref_note区分三种参考绑定形态：资产标签 + 角色契约 + 转移限制（4 分）、标签 + 角色但未声明排除（3 分）、散文式绑定已接受素材（3 分）、仅提及标签无角色契约（2 分）、参考模式无任何绑定（0 分）。

7.4 评估模块边界

围绕 rubric 的工程落地上，docs/EVAL_MODULES.md 界定了模块职责：纯文本操作（Unicode 校验、稳定排序、Markdown 转义、命令值校验、POSIX/PowerShell 引号）归 scripts/eval_ledger_format.py；评分、源选择、provider 请求、来源验证与原子 ledger 发布归 scripts/eval_run.py。提取模块不改变输出措辞、转义规则、命令默认值或错误分类，且格式化器被显式声明为 evaluator source（见 evals/source-manifest.json），冻结的 release 检查会把两个评估模块绑定到实际执行的代码对象、路径与源码自摘要。可用python -m unittest tests.test_eval_ledger_format tests.test_eval_run_integrity验证格式化器与 ledger 契约，用python scripts/eval_run.py --self-test做离线源码接线检查——两者都不授权付费调用。

八、人类评审协议与机器门禁的分界

rubric 全文反复强调一条主线：模型评委分数只是抽样响应相对已声明断言的证据。具体到中、日、韩语言质量主张，references/multilingual-native-review.md 定义了独立的人类评审协议：每种语言恰好两名独立评审（一名目标语言编辑负责惯用表达、节奏、语域、关系措辞与 calque；一名文化/制作评审负责创意镜头假设、可执导性与刻板印象风险），评审人必须披露角色、稳定 ID、作者身份与利益冲突。任何材料分歧不得平均成通过，必须修订标本、保留双方引证证据、递增fixture_revision与review_round、刷新哈希并开启新一轮独立评审。证据记录中每个关键分都必须引用该标准criterion_evidence_anchors中的本地化候选短语（至少 8 个目标文字符）并带criterion_id:前缀的理由。该协议还内置了 9 条对抗性攻击清单（如把@Image1换成＠Image1、交换三个参考 token 的角色、把一种语言的实现照搬到另一种语言等），用于在记录裁决前验证机器门禁是否会先失败。这些主张边界与 docs/VALIDATION.md、validation/authoring-state-provenance-ledger.json 中的溯源约束一脉相承。

结语：把评估当作"证据收集器"而非"质量认证器"

从 0-3 通用评分、V6 序列 0-4 门禁，到 v2→v3 的迁移，Seedance 2.0 的 eval rubric 始终在回答同一个问题：机器能确定性地证明什么，不能证明什么。prompt_architecture_stress.py能证明结构、相关性、显式矛盾与重复性失败；它不能证明创意、原创性、语言母语性、平台交付能力或渲染质量。消费这些分数时，务必按版本号读取gate_v3/prior_v2/legacy三套均值，把slop_free与length_fit当作咨询性诊断，并让语言与文化类主张回到人类评审协议——这才是这份 rubric 真正的工程价值所在。

• AI 技能
• AI 评测
• 提示工程
• 人工智能
• 媒体生成