创建英雄与事务官单位

创建时间：2026年9月4日最后更新：2026年9月4日

创建英雄不是在agent_subtypes_tables里新建一行就结束。一名能够正常使用的英雄同时有两个身份：在战役地图上，它是可招募、可升级、可执行英雄行动或随军行动的人物；进入战斗后，它又是一个只有一名成员的陆战单位。两条数据链必须通过associated_unit_override正确连在一起。

《全面战争：战锤 III》的简体中文界面称这类人物为“英雄”；英雄在战役地图上独立行动时，旧教程和模组社区也常称其为“事务官”。数据库中的agent只是内部名称。本文面向玩家时统一使用“英雄”，仅在表名、字段和 Key 中保留agent。

先确定要做哪种英雄

不同英雄可能属于完全不同的内部人物大类。例如，震旦的丹鼎师能够施放法术，但原版faction_agent_permitted_subtypes_tables.Agent使用的却是engineer；司天丞使用wizard，门下督使用champion。这些 Key 是引擎内部分类，不是游戏中的职业名称，更不能按英文字面翻译。

选择模板时至少比较：

要比较的内容	为什么重要
相同派系或亚文化	决定招募权限、姓名、战役模型、语音和部分机制。
相同内部人物大类（`agent`）	决定英雄行动、英雄招募容量、加成和部分招募规则使用哪类内部 Key。
相同战斗形态	步行、骑乘、飞行、怪兽、战车或战争机器使用的实体、挂点和动作链不同。
相同性别与随机外观方式	影响姓名池、`Art Set`（战役外观配置）和招募池生成。
相同战斗职能	近战英雄、远程英雄和施法者需要不同的武器、技能和 AI 定位。
相同招募方式	建筑解锁、特殊招募池、任务奖励和脚本生成不能套用同一套步骤。

本文使用震旦的丹鼎师wh3_main_cth_alchemist演示“现有派系、建筑解锁、可以重复招募的普通英雄”。这个案例不适合直接照搬给传奇英雄、以巨兽形态参战的英雄、拥有多种形态的英雄，或不通过建筑解锁的特殊英雄。

完整数据链

战役人物身份
agent_subtypes_tables
    ├─ associated_unit_override ─→ main_units_tables
    ├─ faction_agent_permitted_subtypes_tables
    ├─ character_skill_node_sets_tables
    └─ campaign_character_art_sets_tables
            └─ campaign_character_arts_tables
                    └─ agent_uniforms_tables

战斗单位
main_units_tables
    └─ land_units_tables
            ├─ battle_entities_tables
            ├─ melee_weapons_tables / missile_weapons_tables
            ├─ unit_variants_tables → variants_tables
            └─ 护甲、盾牌、属性、技能与按需分支

招募入口（建筑解锁案例）
building_effects_junction_tables
    └─ effects_tables
            ├─ effect_bonus_value_agent_junction_tables
            └─ effect_bonus_value_agent_subtype_junctions_tables

需要哪些表单

普通英雄的核心表单

表单	负责什么
`agent_subtypes_tables`	定义具体英雄类型、关联的战斗单位、是否可招募、招募成本和姓名生成方式。
`faction_agent_permitted_subtypes_tables`	把英雄类型交给指定派系，并声明它使用哪个`agent`大类。
`main_units_tables`	定义英雄进入战斗后的主单位记录和战役属性。
`land_units_tables`	定义英雄的战斗数值、动作、实体、武器、防护和属性。
`unit_variants_tables`	连接主单位和战斗模型变体。
`campaign_character_art_sets_tables`	把`Art Set`（战役外观配置）分配给具体英雄类型。
`campaign_character_arts_tables`	为每套`Art Set`配置战役模型、陆地状态动作、海上状态模型以及等级或季节变体。
`character_skill_node_sets_tables`	声明哪棵技能树属于这个英雄类型。
`character_skill_node_set_items_tables`	把具体技能节点放入技能树。

只在对应目标下添加

表单或文件	什么时候需要
`agents_tables`	几乎不需要。只有真正新建一种引擎内部人物大类时才考虑，普通新英雄应复用原版大类。
`agent_culture_details_tables`	目标文化尚未配置该`agent`大类的显示名称、默认单位或小图标时才需要。
`agent_recruitment_categories_tables`	需要独立招募分类或模板本来使用该表时添加。很多普通英雄的`recruitment_category`为空。
`agent_uniforms_tables`	使用新战役模型、单独指定战斗模型或更换战役骨骼时需要。复用原版`Uniform`时不要重复复制原记录。
`agent_subtype_ownership_content_pack_junctions_tables`	确实需要官方 DLC 或内容包拥有条件时添加。自制英雄不要无意复制模板的 DLC 限制。
`names_groups_tables`、`names_tables`	要为普通英雄建立独立随机姓名池时添加。
`effects_tables`及相关`Bonus Value`连接表	要通过建筑、科技或其他来源解锁招募、增加英雄招募容量或提高新募英雄等级时添加。
`campaign_character_art_set_porthole_overrides_tables`	使用特殊动态头像场景时添加。
`portrait_settings.bin`	新的`Art Set`ID需要独立头像构图时编辑。
`campaign_to_agent_subtypes_tables`	只在原版同类英雄确实按战役过滤时添加；不是所有普通英雄的必需表。

先规划一套唯一 Key

不要边复制边临时改名。先写好同一套前缀，再依次创建记录。以yourmod_cth_alchemist为例：

英雄类型：yourmod_cth_alchemist
主单位：yourmod_cth_cha_alchemist_0
陆战单位：yourmod_cth_cha_alchemist_0
战斗模型变体：yourmod_cth_cha_alchemist
战役外观配置：yourmod_art_set_cth_alchemist_01
技能树节点集合：yourmod_skill_node_set_cth_alchemist
招募效果：yourmod_effect_agent_enable_recruitment_cth_alchemist

yourmod必须替换为你自己的独特前缀。不要使用wh3_main、wh3_dlc或原版 Key，也不要在不同表中一会儿使用空格、一会儿使用连字符。

在 Pack 中准备表单

可以使用两种方式：

在依赖项中搜索原版表单或模板 Key，只复制要使用的记录到新 Pack。
将原版整张表导入 Pack，先把导入后的data__重命名为自己的表名，然后仅保留模板记录。

导入的 DB 文件不得继续叫data__。这是原版数据库的默认表名，保留该名称可能让 Mod 整表覆盖原版数据。导入后应立即改名，选中需要的模板行，反选后删除其余记录，最后再复制和改 Key。

不论用哪种方式，都只保留本 Mod 真正修改或新建的记录。不要因为“可能会用到”就把整棵原版技能树、全部姓名或整张派系权限表留在 Pack 中。

创建英雄的战斗单位

如果新英雄要完全沿用原英雄的战斗数值、模型和技能，associated_unit_override可以暂时指向原版main_units_tables.Unit。这适合快速检查战役部分，但不是制作独立英雄的最终做法：以后修改共享单位会同时影响原英雄。

要建立可独立调整的英雄，复制模板的：

main_units_tables。
land_units_tables。
unit_variants_tables。
确实要独立修改的battle_entities_tables、武器、护甲、盾牌、属性组或部队技能连接。

不需要改的实体、武器和模型可以继续引用原版记录。“创建新英雄”不等于“复制它引用的所有数据”。

`main_units_tables`的英雄关键项

字段	普通英雄应如何处理
`unit`	新主单位唯一 Key。
`land_unit`	指向新建的`land_units_tables.Key`。
`num_men`	常规英雄为 1。拥有多个实体的英雄必须另找真正同类的原版模板。
`caste`	普通英雄通常使用`hero`。不要仅为了改 UI 文字而填成`lord`。
`use_hitpoints_in_campaign`	保留同类英雄模板的值，使战斗中的伤势与战役状态正确衔接。
`restrict_xp_gain_in_campaign`	人物经验与普通部队经验是两套系统，应沿用英雄模板，不要把普通兵种值搬过来。
`porthole_camera`	动态头像和战前镜头使用的相机模板。必须与英雄身高、坐骑和模型类型匹配。
`audio_voiceover_culture`、`audio_voiceover_actor_group`	英雄语音。没有自制语音时可复用兼容模板，但不要填一个不存在的 Key。
`ui_unit_group_land`	战斗和部分界面使用的单位分类。应参考战斗定位相同的英雄。
`can_siege`	是否具备独立攻城能力。不是“英雄能否参加攻城战”。

`land_units_tables`的英雄关键项

Num Men并不存在于land_units_tables；单位人数由main_units_tables.num_men控制。在land_units_tables中需要核对：

man_entity：单人英雄使用的战斗实体。
man_animation：战斗动作表。
bonus_hit_points：在实体基础上追加的生命值。
primary_melee_weapon、primary_missile_weapon、护甲与盾牌：战斗武器与防护。
attribute_group：英雄使用的单位属性组。
ai_usage_group：战斗 AI 对该英雄的定位。
spell_mastery：法术精通。它不会自动授予任何法术。
mount、num_mounts：战斗中直接使用坐骑的单位链。英雄通过技能解锁多种坐骑时，每种坐骑形态通常都有独立的主单位记录。

其余战斗字段请按《陆战单位详解》、《远程武器详解》和《部队技能详解》的数据链检查。

建立`agent_subtypes_tables`记录

复制wh3_main_cth_alchemist，把key改为自己的英雄类型 Key，然后逐列检查：

字段	作用与处理方式
`auto_generate`	是否生成可以反复招募的普通英雄。普通英雄通常沿用模板的开启值；唯一人物不能照搬。
`onscreen_name_override`	英雄职业名称。最终简体中文由本地化文本（`Loc`）提供，不要只依赖表内英文。
`is_caster`	标记施法者身份。它不会授予法术，法术仍来自技能树、部队技能、物品或脚本。
`associated_unit_override`	指向该英雄进入战斗时使用的`main_units_tables.Unit`。
`audio_voiceover_actor_group`	战役地图上的英雄语音组。与主单位的语音字段一并检查。
`show_in_ui`	该英雄类型是否允许在相关界面中显示。
`cap`	英雄类型自身的限制值。大量原版记录为`-1`；英雄招募容量通常还受效果和`contributes_to_agent_cap`影响，不要只改这一列。
`has_female_name`	姓名生成相关标记。复用同性别和同姓名结构模板，并用实际招募池验证。
`can_gain_xp`	英雄是否能获得人物经验。
`loyalty_is_applicable`	是否参与忠诚度系统。只在目标派系真正使用该机制时沿用。
`contributes_to_agent_cap`	该英雄是否计入相应的英雄招募容量。
`names_group`	可选的随机姓名组覆盖。留空时可能继承派系或文化的姓名来源，应按模板验证。
`recruitment_category`	招募界面分类。丹鼎师的原版记录为空，所以普通英雄不能被强制填入一个领主分类。
`magic_lore`	魔法之风或施法分类引用。它不会自动把整套法术放进技能树。
`can_be_loaned`	是否参与内部的英雄借调流程。游戏没有统一显示这一字段的名称，应沿用同派系、同招募方式的模板。
`recruitable`	是否允许被招募。开启它不会自动创建派系权限和解锁来源。
`saving_settings`	人物生成与存档读取方式。该值不能按英文字面猜测，必须复制同类可招募英雄的已验证值。
`can_equip_ancillaries`	是否能装备物品。
`cost`	英雄招募成本的基础值。实际成本还可能受效果和派系机制影响。
`small_icon`、`recruitment_button_*`	可选的英雄类型图标和招募按钮图片覆盖。原版大量记录留空，并从其他外观数据中取值。

在 agent_subtypes_tables 中查看丹鼎师的战斗单位连接、语音组和人物设置

把英雄交给派系

在faction_agent_permitted_subtypes_tables中复制模板派系的对应记录，修改：

Faction = 目标派系 Key
Agent   = 模板英雄实际使用的 agent 大类
Subtype = 新英雄类型 Key

本例的丹鼎师必须沿用Agent = engineer。不要因为它会施法就改成wizard，否则英雄行动、英雄招募容量、战役界面和其他以内部人物大类为条件的系统可能一起改变。

要让多个派系使用新英雄，应为每个目标派系添加记录。不要复制搜索结果中所有原版派系；叛军、任务战派系、序章派系和特殊战役派系不一定属于你的目标。

在 faction_agent_permitted_subtypes_tables 中查看丹鼎师使用的内部人物大类和派系权限

配置战役模型与动作

`Art Set`与战役外观记录

campaign_character_art_sets_tables负责“哪套Art Set属于哪个人物类型”，campaign_character_arts_tables负责“这套外观配置在什么条件下使用哪个模型和动作”。Art Set是数据库内部名称，不是游戏界面中的职业或外观分类。

丹鼎师原版使用 5 个Art Set，对应 5 套可随机出现的战役外观。要完整保留这种随机性，应复制 5 条Art Set记录和对应的campaign_character_arts_tables记录；如果新英雄只需要一种外观，可以只创建 1 套，不需要为了追求“数量一样”而复制全部变体。

在 campaign_character_art_sets_tables 中查看丹鼎师的五套战役外观配置

每条campaign_character_art_sets_tables需检查：

字段	作用
`art_set_id`	`Art Set`的唯一 Key。新英雄类型不能与原版继续共用同一主键行。
`agent_type`	该`Art Set`适用的内部人物大类，应与派系权限中的`Agent`一致。
`faction`、`culture`、`subculture`	可选的适用范围。只在你确实要限制战役外观选择时填写。
`agent_subtype`	指向新建的英雄类型 Key。
`is_male`	用于选择战役外观的性别条件。原版唯一人物中存在与外观看起来的性别不一致的数据，不要把它当作玩家所见性别的唯一依据。
`campaign_map_scale`	战役地图模型缩放。
`prebattle_separation_offset`	战前界面中的模型间距偏移，应参考体型和坐骑相同的英雄。

campaign_character_arts_tables中最容易出错的字段是：

art_set_id：必须指向新的Art Set。
level、season、age：决定条件变体。不需要条件变化时沿用模板的基础值。
uniform：指向agent_uniforms_tables.uniform_name。
land_animation：人物在陆地状态下使用的战役地图动作。它不是land_units_tables.man_animation。
sea_uniform、navy_uniform、sea_animation、navy_animation：海上或运输状态。应保留同文化模板的合法记录。
id：数值主键，每条新记录都必须唯一。不要只改art_set_id却保留模板 ID。

复用还是新建`Uniform`

如果你只想让新英雄使用原版丹鼎师的战役模型，新建Art Set和对应外观记录后，uniform可以继续指向原版wh3_main_uniform_cth_alchemist_01等记录。这时不要把agent_uniforms_tables的原版行重复塞进 Mod。

只有下列情况才创建新Uniform：

使用新的战役地图模型文件。
战斗和战役需要不同的模型文件。
campaign_porthole_filename或campaign_politician_filename需要使用另一套模型。
需要覆盖战役骨骼。

agent_uniforms_tables中的filename、battle_filename、campaign_porthole_filename、campaign_politician_filename和campaign_override_skeleton必须与实际资产一致。RPFM 能保存路径，但不会自动创建缺失的模型、骨骼或动作。

配置头像与招募图片

英雄在不同界面可能使用不同图片来源：

agent_culture_details_tables.small_icon：文化和内部人物大类层面的小图标。
agent_subtypes_tables.small_icon与recruitment_button_*：英雄类型层面的覆盖。
unit_variants_tables.unit_card：战斗单位兵牌引用。许多英雄模板使用placeholder，不代表战役头像也使用这张图片。
campaign_character_arts_tables.portrait、card和info：旧或特定界面的直接图片入口。
*portrait_settings*.bin：当前大量人物头像使用的构图、相机和贴图变体。

使用新的Art SetID时，应在原版 Pack 中搜索该模板的portrait_settings文件，将需要的文件加入 Mod，然后在 RPFM 的Portrait Settings编辑器中克隆模板条目，把art_set_id改为新 ID。如果引用新贴图，再逐项修改diffuse和mask路径。

仅在 DB 中新建Art Set，却没有在Portrait Settings中添加新 ID，常见结果是模型正常而头像缺失。运行 RPFM 诊断可以检查无效的Art SetID、战斗模型变体和缺失贴图。

为英雄配置技能树

新英雄类型不会自动继承模板技能树。如果想完整复用原技能树，不需要复制所有character_skills_tables和节点，可以：

复制模板的character_skill_node_sets_tables记录。
改成新的技能树节点集合 Key。
把agent_subtype_key改成新英雄类型 Key。
保留与模板一致的agent_key，并核对派系、亚文化和战役限制。
复制该节点集合在character_skill_node_set_items_tables中的所有成员行，只把set改成新的节点集合 Key。

这种做法是“新英雄共用原技能节点”。只要不修改共享节点和技能记录，它就不会覆盖原英雄。

要制作独立技能树，再按《角色技能详解》复制节点、技能、连线和等级奖励。如果英雄是施法者，还要按《法术详解》确认法术解锁节点。is_caster = true只是身份标记，不是法术清单。

让英雄出现在招募界面

faction_agent_permitted_subtypes_tables只是“允许派系使用该英雄”，不等于已经有招募入口。本例采用原版丹鼎师的建筑解锁路径。

独立解锁还是共享解锁

有两种合理做法：

共享原招募条件：让新英雄也受原版丹鼎师招募效果影响。这适合两者本来就应一起解锁的情况，但会把新英雄类型和原效果绑定在一起。
创建独立招募效果：复制原效果及其Bonus Value连接，改成新的效果 Key，再由目标建筑提供。这适合需要独立控制解锁来源的新英雄。

本文推荐第二种，因为以后更换建筑或调整条件时不会意外改变原版英雄。

复制招募效果的数据链

以wh3_main_effect_agent_enable_recruitment_cth_alchemist为模板，完整搜索它的引用，而不是只复制effects_tables一行。新的招募效果至少需要：

effects_tables.Effect
    = yourmod_effect_agent_enable_recruitment_cth_alchemist

effect_bonus_value_agent_junction_tables
    Effect         = 新效果 Key
    Bonus Value ID = availability
    Agent          = engineer

effect_bonus_value_agent_subtype_junctions_tables
    Effect         = 新效果 Key
    Bonus Value ID = availability
    Subtype        = yourmod_cth_alchemist

原版数据可能同时包含“内部人物大类”和“具体英雄类型”两种连接。复制时应保留模板结构，只替换效果 Key 和人物类型 Key；不要因为两行都写着availability就随意删掉其中一条。

然后在building_effects_junction_tables中让目标建筑等级提供新效果：

Building     = 目标 building_levels Key
Effect       = 新招募效果 Key
Value        = 1
Effect Scope = 沿用同类原版记录

这里的建筑只是一种实现路径。如果你的设计是科技解锁、任务奖励、特殊招募池或脚本生成，应从同类原版英雄反查真实入口，不要为它强行加一个兵营或者随便一座建筑。

英雄招募容量和新募英雄等级

常见的Bonus Value如下。Bonus Value是数据库内部用于决定效果实际作用的类型，不是游戏界面术语：

`Bonus Value`	作用
`availability`	允许招募某个内部人物大类或具体英雄类型。
`cap`	增加英雄招募容量。
`recruitment_level`	提高新募英雄等级。

英雄招募容量在原版中经常按内部人物大类计算，而不是按具体人物类型分开。如果新英雄与丹鼎师同属engineer，两者可能共用容量。不要看到效果 Key 里写着alchemist就认定它只影响丹鼎师；必须打开Bonus Value连接，查看实际指向的Agent或Subtype。

姓名、职业名和说明

这三类文字不是同一个数据：

职业名：通常来自agent_subtypes_tables.onscreen_name_override或agent_culture_details_tables.onscreen_name。
具体人名：普通英雄从派系或names_group对应的names_tables中抽取。
英雄职业说明：可来自agent_subtypes_tables.description_text_override、agent_culture_details_tables.description_text或关联单位说明，具体以目标界面为准。

不要只写一条“丹鼎师”本地化文本，就假定所有界面都会同时更新。按《本地化详解》使用 RPFM 的“生成缺失本地化文本”（Generate Missing Loc Data）检查英雄类型、单位、技能和效果文本，再到招募英雄界面、人物详情界面和战斗中分别核对。

英雄行动和默认属性

英雄可以执行哪些英雄行动，通常与内部人物大类及以下数据有关：

agent_to_agent_abilities_tables
agent_to_agent_attributes_tables
agent_actions_tables
agent_conditions_tables
人物技能提供的英雄行动效果

本文复用丹鼎师已有的engineer内部人物大类，因此不另外新建人物大类或英雄行动。但“同属engineer”也意味着它可能继承该大类的默认行动和加成。如果你想让新英雄拥有不同的英雄行动，应先查找一个真正使用同类行动的原版英雄，再按后续的英雄行动教程单独处理，不要在创建英雄时猜测行动 Key。

内容包权限和特殊机制

原版英雄常在agent_subtype_ownership_content_pack_junctions_tables中设置官方内容包拥有条件。将这行原样复制给新英雄，可能导致玩家未拥有相应 DLC 时无法使用它。

处理原则是：

复用官方 DLC 独有资产和规则时，保留必要的所有权约束。
完全自制且不应要求某个 DLC 时，不要因为复制模板就自动保留内容包拥有条件记录。
无法确定资产授权范围时，先保留必需的 DLC 条件并在文档中说明，不要把“未拥有 DLC 因而无法使用”误写成 RPFM 故障。

宁和、骑士誓言、职位、吸血鬼伯爵的血裔、冰雪王廷训练等都是额外机制。看到模板人物类型 Key 在某个专用表或 Lua 中出现，不代表新英雄必须照搬；只有设计目标确实需要该机制时才添加。

怎样自行查找需要的数据

在游戏中选一名招募方式和功能最接近的原版英雄。
在agent_subtypes_tables搜索它的人物类型 Key，记下associated_unit_override。
全局搜索人物类型 Key，按派系权限、战役外观、技能树、内容包拥有条件和特殊机制分类结果。
全局搜索associated_unit_override，追踪主单位、陆战单位、战斗模型变体和部队技能。
在faction_agent_permitted_subtypes_tables查看模板实际使用的内部人物大类和全部派系记录。
搜索招募效果，从Bonus Value连接反查真正的建筑、科技或其他来源。
用Art SetID搜索 DB 和portrait_settings文件，确认战役模型、头像和动作是否完整。
用技能树节点集合 Key 导出成员节点，检查默认技能、法术、英雄行动加成和坐骑分支。

一次全局搜索出现几十张表很正常。不要把“搜索命中”直接等同于“本 Mod 必须复制”；先按核心身份、战斗、战役外观、技能、招募和可选机制分类。

完整制作顺序

选择同文化、同内部人物大类、同战斗形态和同招募方式的原版模板。
规划全部新 Key，创建或导入本文需要的表单。
复制主单位、陆战单位和战斗模型变体，先让英雄成为可用的单人战斗单位。
新建agent_subtypes_tables记录，将associated_unit_override指向新主单位。
在faction_agent_permitted_subtypes_tables中为真正的目标派系添加权限。
建立Art Set和对应的外观记录，复用或新建Uniform，并处理Portrait Settings。
新建技能树节点集合，把共享或独立技能节点放入新技能树。
按设计选择建筑、科技、特殊池或其他招募入口。
处理本地化文本、图标、姓名、语音和必要的内容包拥有条件。
运行 RPFM 诊断，按数据链从人物类型向战斗单位、战役外观、技能树和招募效果逐项检查。
新开战役存档进行验收。旧存档可能已经缓存招募池、容量和技能树。

常见错误

新建了agents_tables却没有英雄：你只建了内部人物大类，没有具体人物类型。普通情况下根本不应新建人物大类。
英雄在招募列表中消失：检查recruitable、show_in_ui、派系权限、招募效果和英雄招募容量。
可以招募但进入战斗崩溃：检查associated_unit_override、主单位、陆战单位、战斗模型变体、实体、动作和武器引用。
战役地图上隐形或红白模：检查Art Set、战役外观记录、Uniform和实际模型文件。
有模型但没有头像：搜索新的Art SetID是否存在于Portrait Settings，并检查贴图路径。
技能界面为空：缺少指向新人物类型的技能树节点集合，或该集合没有成员。
会施法但没有法术：is_caster已开启，但没有技能或其他系统授予法术。
建筑出现英雄图标却无法招募：检查效果是否通过Bonus Value连接到正确的Agent或Subtype，并核对数值与Scope（作用对象），不要只看建筑说明。
容量加给了其他英雄：该容量效果可能指向内部人物大类，而不是具体人物类型。
满足内容包拥有条件但没有英雄：内容包拥有条件不是招募入口。
只在旧存档失败：使用新开战役测试，再单独判断存档兼容。

RPFM 检查

运行诊断，清理缺失引用、重复 Key、错误的资源路径和缺失的本地化文本。
用全局搜索检查新人物类型 Key，确认至少命中派系权限、Art Set和技能树节点集合。
用全局搜索检查新主单位 Key，确认人物类型、陆战单位和战斗模型变体都指向正确。
搜索新效果，确认它有正确的Bonus Value目标，并且真正由建筑或其他来源提供。
搜索新的Art SetID，确认 DB 记录和Portrait Settings内部条目一致。
确认 Pack 中没有留下未改名的data__整表。

游戏内验收

建筑、科技或目标机制在正确条件下解锁英雄。
英雄只出现在预期派系，英雄招募容量和新募英雄等级正确。
招募英雄界面中各候选英雄的职业名、随机姓名、说明、图标和招募成本正确。
英雄能加入军队，能离开军队，能升级并打开完整技能树。
英雄在战役地图上的模型、步行、转身、待机和海上状态正常。
人物头像、人物信息界面、战斗兵牌和战前镜头均正常。
英雄能进入手动战斗，且模型、动作、武器、技能、法术和生命值正常，受伤状态也能被正确保存。
英雄完成一次战役行动，成功、失败、受伤和动画都没有异常。
保存后重新读取，英雄、技能、物品、等级和伤势状态保留正确。

RPFM 诊断只能确认部分引用、资源和格式问题，不能证明招募池生成、战役动作、技能树布局和战斗动作完全正常。这些都必须使用新开战役和手动战斗验收。