单人主导、AI 协作的游戏开发实践报告

——以《夜颂家政》为例的职能映射、联调机制与可控性体系

by 张杨苡

摘要

本报告回答三个问题：

1. 职能覆盖与责任划分：单人主导的 AI 协作如何承接商业游戏开发中的主要职能，开发者与 AI 分别承担哪些工作与决策责任？
2. 跨职能协作与迭代：面对战斗反馈、关卡表现和界面调度等相互依赖的制作环节，如何组织多个 AI 工作会话，使设计意图、数据与实现保持一致，并形成可持续的联调流程？
3. 制作可控与品质保障：如何通过可编辑的内容结构、参数工具与分层验证，将 AI 的快速产出转化为可审阅、可修订、可验收的成果，持续掌握游戏的体验与品质？

主要结论：

• 开发者主导游戏策划与体验设计，AI 协助制作与实现。 开发者的工作涵盖核心玩法、系统规则、关卡结构与交互方案的设计，并提供空间设计图、UI 设计稿及表现参考，通过试玩与评审持续修订设计和表现。AI 依据这些设计要求与约束，协助完成内容制作、工具开发、工程实现与测试。
• 可控性来源于系统化的参数体系与验证流程，而非 AI 本身。 手感、反馈、镜头、敌人、关卡节奏与经济逐步接入集中参数管理，配合游戏内调参台、约束规则与可重放的测试场景；对照条件的一致性由脚本锁定，AI 负责执行与检查。
• 联调效率取决于"唯一数据源、同一时刻对照、明确的文件所有权"。 这三点在真人团队中同样成立，在 AI 并行工作时更为关键，因为独立工作会话的上下文需要持续同步，跨职能变更也需要明确传递。
• 制作结构决定 AI 产出能否继续被设计者控制。 把源资产、导入处理、关卡场景、交互组件与运行逻辑明确分工后，AI 的批量生成才能成为可检查、可编辑、可回退的生产结果。文本场景与自动检查扩大了验证覆盖，最终体验与审美仍需人工判断。

一、参照系：商业项目的职能分工

本报告以中大型商业项目的常见组织结构作为参照。此类项目一般采用"职能线 × 内容线"的矩阵结构：职能线（策划、美术、程序、质量、音频）保证专业深度，内容线（某一关卡、某一 Boss、某一系统）保证交付闭环。

1.1 主要职能及其日常工作

二、各职能在本项目中的 AI 实现方式

2.1 制作管理与设计统筹：将人的判断转化为 AI 的执行闭环

在单人主导的 AI 协作中，制作管理与设计统筹共同解决一个问题：如何让并行生成的内容持续服务于同一个体验目标。开发者负责确定方向、优先级与验收判断；主控 AI 将这些判断转化为专项任务，协调执行并汇总证据。管理重点由追踪产出数量，转向控制目标解释、交付边界与迭代结果的一致性。

这一工作流由四个相互衔接的环节构成：

1. 建立共同语境。 开始任务前，AI 读取相关设计、历史裁决与当前实现，明确体验目标、已有能力和任务范围。设计意图与适用边界共同构成任务依据，减少会话之间重复推导和方向漂移。
2. 形成可验收的任务。 主控 AI 按依赖拆分工作，约定交付物、修改范围与验收条件。每项任务都需要回答它服务于哪项体验，以及通过何种证据判断完成；跨职能任务围绕可独立审阅的成果组织。
3. 用证据推动裁决。 专项 AI 提交实现、测试结果及必要的视觉对照，主控核查其与任务目标的一致性。开发者据此判断体验与审美是否成立，决定接受、调整或回退；尚待验证的能力不计作完成。
4. 将反馈转化为下一轮约束。 通过评审的结论连同原因、适用范围及对应版本沉淀到项目记录，供后续任务读取。被否决的方案也保留关键原因，使 AI 能够调整处理方式，而非反复生成同类偏差。

这一机制使 AI 的价值从单次内容生成延伸到任务执行、验证与知识维护。人的设计判断始终决定迭代方向，AI 则负责将判断转化为可追踪、可复核、可继续修改的制作成果。后文各职能的实践，均在这一协作闭环内展开。

2.2 系统策划：以规则结构组织持续的行动选择

在商业游戏项目中，系统策划负责设计成长、技能、经济与外循环等系统的规则及相互关系，将核心玩法组织为具有目标、取舍和持续回报的游戏过程。《夜颂家政》的系统设计围绕吸取、投掷、撞击与清扫展开：关内让玩家判断如何处理局面，一份委托内让能力与祝福改变处理方式，跨委托再以伙伴关系、图鉴与永久技能延续积累。不同系统共同回答玩家为何开始、过程中如何选择，以及完成后为何愿意再次尝试。

2.2.1 系统全景：围绕委托组织行动、成长与回报

契茶店（Contract Tea Shop）承担整套外围流程的枢纽：玩家在此理解委托、安排准备与伙伴投入，经地图确认进度并选择出勤技能，再进入关卡。分关结算反馈本次表现，祝福服务于接下来的关卡，图鉴与特调记录并兑现长期成长；终章结算将整份工作的成果带回契茶店，形成下一次准备的依据。地图与外围页面之间的往返保留委托进度，使成长决策能够发生在自然的节奏间隙。

系统策划关注的是这些环节如何互相承接。例如，收容怪物先在图鉴中留下记录，达到条件后开放特调，完成习得后才能在出勤时选用；这条链路把“处理过的对象”转化为“下一次可采用的战术”。伙伴成长与一次性补给则分别提供长期投入和当次准备，避免所有回报都收敛到单一的数值强化。

2.2.2 经济闭环：让表现、投入与后续用途保持对应

经济设计先明确资源回应哪种行为、支持哪类决策，再确定产出与消耗的节奏。三类货币的主要回路如下：

这套循环同时具有时间关系：关卡奖励要在后续选择需要它之前可用，习得资格与支付能力要分别成立，永久成长与单份委托的消耗要有清楚的持续范围。策划据此检查“有资源却没有用途”“开放了能力却无法支付”“投入后缺少使用机会”等断点，再判断需要调整产出、门槛还是流程时机。具体评分和奖励标准见经济与结算。

AI 工作流：以系统关系图组织实现，以完整流程检查一致性。 开发者先明确希望改变的玩家判断、已有规则与体验边界；AI 将方案拆解为进入条件、可选行为、结果和跨系统依赖，检查新功能能否接入委托主循环。方案确认后，再将这些关系落实到配置、服务与界面，并从三个层次复核：

• 规则对应。 按资源登记产出条件、消费用途、习得资格与持续范围，纳入补助、条款等奖励例外。调整一个入口时，追踪结算、特调、伙伴、补给与换牌的关联影响，保持投入与结果之间的解释一致。
• 数据对应。 核对配置、服务返回、界面展示与实际提交。结算展示正式奖励服务提供的金额及依据，图鉴、特调与出勤共用收容和习得状态；价格、门槛和效果各有明确来源，避免不同页面独立维护同一规则的副本。
• 流程对应。 沿领取、消费、习得、出勤和恢复检查状态变化，以“操作前余额＋收入－支出＝操作后余额”核对资源流转。重复提交、支付不足、已习得再次提交、退出恢复与特调保存失败分别接受边界检查，分关和终章奖励按所属记录核对。

这些检查维护的是规则在完整流程中的一致性。资源是否来得及时、投入是否值得、不同成长方向能否获得充分体验，则交由数值模型与实际试玩共同评估。系统策划据此保持整体结构，数值策划进一步检验这套结构的收益、成本与节奏。

2.2.3 祝福构筑：让同一套动作形成不同的处理思路

祝福通过伙伴主题介入基础动作链，使玩家在相同操作框架下形成不同的战场处理方式。各线的设计目的与决策变化概括如下。

这组设计以“玩家是否形成新的处理顺序”检验构筑价值。成长供给与收益成本由下一节的数值模型和试验进一步检验，构筑是否清楚、有趣并值得反复尝试，则继续通过实际玩法评审确认。

可控性实现案例： 技能、祝福与成长（4.7） · 经济与结算（4.8）。

2.3 数值策划：将体验目标转化为可验证的关系模型

在商业游戏项目中，数值策划围绕成长与经济建立量化模型，检验收益、成本、供给节奏和资源消耗之间的关系。系统策划定义成长与经济规则，数值策划在既定规则下进一步明确玩家需要付出多少、何时获得回报，以及这些回报能否支持后续选择。

《夜颂家政》以五关委托组织一轮成长与资源循环。祝福和技能需要为理解、练习及运用保留机会；晶体、茶券与金币的产出则需要与后续用途和消费门槛衔接。数值调整因此关注成长何时兑现、投入是否值得，以及不同选择能否持续成立。

从体验问题建立数值模型。 每轮调整先明确希望改善的成长或消费体验，再确定需要比较的收益、成本与进程关系：

AI 工作流：从明确假设到受控比较。 开发者提出成长与经济的设计目标和约束，AI 读取对应版本的正式配置、奖励服务与历史裁决，整理产出、消耗、门槛和前置关系。以五关既有规则为基线，将问题缩小为可以回答的假设，例如“各关预设的祝福供给是否提供有效选择”“某种成长在获得后是否仍有充分的使用机会”。选择策略在既定供给与资格范围内比较，伙伴的关卡安排作为明确前提保留。

随后固定初始资源、成长状态与关卡进度，比较资源收支、候选可获得性、解锁时点和奖励分布；涉及随机候选时，通过批量模拟扩大条件覆盖，再沿完整委托检查收益与支出能否自然衔接。AI 汇总典型结果、低收益情况和异常样本，开发者判断问题来自产出与消耗、候选资格还是奖励时点，再形成具有明确影响范围的调整方案。

蒙特卡洛案例：观察既定成长规则下的结果分布。 项目曾调用实际奖励服务，针对评级、选择策略、羁绊与换牌方式比较32组条件，每组模拟1,000次。这类试验用于检查给定条件下的候选资格、成长获得与奖励提交，帮助定位值得进一步核查的环节。统计含义依赖当时的规则版本、输入假设与评价指标；发牌结果还需与获得能力后的实际使用效果分别评估。

最终取值回到成长与消费体验，并进入可追溯的配置。 实际试玩继续检查成长是否来得及时、收益是否可感知、投入与回报是否相称，以及后续关卡是否提供了使用机会。AI 提供复算、分布比较与回归证据，开发者据此决定接受的成长节奏和资源取舍。确认后的参数写入相应配置，同步复核效果说明、奖励显示和受影响流程，使下一轮调整具有清楚的基线。

可控性实现案例： 技能、祝福与成长（4.7） · 经济与结算（4.8）。

2.4 战斗策划

战斗策划负责角色操作与移动、镜头、敌人行为及打击反馈，协调动作时序、目标选择、反应窗口和视听表现，是与动画、特效、镜头、程序联调最频繁的岗位。本项目逐步将 3C 与打击反馈参数化，并开发了游戏内调参台：参数实时生效，支持保存预设、方案对比、一键回退，并可将结果写回数据源。

"吸取、投掷、冲刺、收容、撞击"五类关键瞬间均配有固定的重放场景，调参时可以反复播放同一段操作，只观察参数变化带来的差异。调参台显示实际生效的读数 ，例如本次撞击值、所属档位、实际停顿时长、实际击退距离，而不仅是设定值。这一设计源于一次实际问题：开发者反馈"调整震屏后没有感觉"，排查发现是默认值过小，且重放场景固定落在最轻的档位。若没有读数，此类问题很难被发现。

图 1 为调参台的 A/B 对比模式：同一次撞击分别以 A、B 两套参数重放，下方表格并列显示两者的实测读数与差值。软档阈值由 18.0 调整为 17.1 后，同一次撞击（撞击值 17.26）由软档变为硬档，实际停顿由 34.0 毫秒增加到 59.5 毫秒。

图 1　战斗与 3C 调参台的 A/B 对比模式。右侧为参数，下方为两套参数下同一次撞击的实测读数对照，并提供重放、变速、暂停与单帧步进。

调参台内置约束规则，防止参数在调整过程中出现逻辑倒置，例如"轻档的停顿时长不得长于重档"。违反约束时，调参台立即提示（图 2）。

图 2　将硬档阈值误调为 1.0 后，该行被标记，底部状态栏显示"约束警告 1"，并提示尚有 1 项未写回数据源。

镜头参数同样需要系统化验证。图 3 为"怪物入画"参数的矩阵测试：在 4 米与 6 米两种距离、八个方位下，分别记录两轮调整后 Boss 在画面中的可见比例，用以判断镜头能否在各种站位下保持目标完整入画。

图 3　镜头"怪物入画"矩阵测试。每格标注距离、方位与目标可见比例（1.0 为完整可见），对比两轮调整的结果。

可控性实现案例： 操作与移动（4.1） · 打击反馈（4.2） · 镜头（4.3） · 怪物（4.4）。

2.5 关卡策划

2.5.1 方法论：从空间意图到可验证的度量

关卡策划在商业项目中的工作链路通常是：确定关卡在整体节奏中的定位与核心体验 → 绘制空间草图与动线 → 依据角色度量（移动速度、跳跃高度、交互距离）搭建灰盒 → 编排遭遇与节奏曲线 → 交付美术、再与美术迭代视线和可读性 → 通过试玩修正。本项目沿用这一链路，并把每一步的产出转化为可被 AI 执行与检查的数据：

2.5.2 主案例：门厅关卡的场景化编辑与制作控制

关卡可控性的核心，是使空间意图能够在工程中被持续调整，并保持外观、阻挡与玩法配置之间的一致性。门厅早期采用脚本集中装配模型、材质与环境效果，适合快速验证玩法；随着布景和交互迭代增多，固定布局与运行逻辑之间的耦合逐渐成为维护成本的主要来源。

后续制作流程将内容划分为资产组件、导入处理、关卡场景与运行行为四个层次。接待台、行李车等可复用物件以独立组件组织，关卡场景维护固定摆放，出生点、锚点、核心与遭遇区域由玩法标记管理。该划分使空间调整具有明确的维护入口，也使 AI 的批量处理受到稳定的数据边界约束。

图 4　门厅资产、关卡场景、玩法标记与运行行为的职责关系。固定配置与动态表现分别维护，碰撞及交互关联按对象核对。

这一改进将关卡策划的控制对象由最终画面扩展为可维护的场景结构。调整物件时，外观位置、实际阻挡、交互范围与相关玩法标记分别接受检查；火焰、天气、动画和行李车等状态行为继续由运行逻辑驱动。AI 负责结构转换、引用维护与一致性检查，开发者负责空间关系、视觉引导和实际通行体验的判断。

2.5.3 补充案例：场景节点与碰撞关联

沉没陈列馆进一步采用可保存的场景节点组织独立物件，并通过稳定标识关联其碰撞代理。以水族柜为例，设计者在原生检查器中维护位置、旋转与缩放，已登记的碰撞体读取对应变换。该方式降低了逐次调整外观后再次人工校正碰撞的成本。

图 5　水族柜场景节点及位置、旋转、缩放属性。历史编辑记录局部，展示独立物件的维护入口。

这类验证关注的是编辑结果能否进入实际运行，以及关联数据能否同步。项目据此将场景选择、编辑保存、加载入口和关联检查纳入同一交付流程。门厅与新章节分别体现了固定配置场景化、独立物件关联绑定两个阶段。

2.5.4 原型迭代：从规则闭环到空间决策

早期白盒承担的任务，是用较低制作成本暴露体验问题。M5 宴会厅先以几何体标记入口、通道、家具、服务与核心区域，检验基础行动能否在空间中成立。随后，即使流程可以运行，试玩反馈仍促使项目重新审视核心回报：玩家是否能够稳定抓住指定目标，主动选择碰撞位置，并从即时结果中理解自己的操作价值。规则闭环的成立与核心动作值得重复，因而被作为两个不同的设计判断。

v0.5 的迭代将基础战斗由材料选择转向可控的空间碰撞，并以独立验证场逐步建立体验。K0–K3 隔离吸取、拖拽、投掷、撞击与收容，先检查选取稳定性、操作反馈和连续行动；K4 在保留基础手感的条件下加入清扫与污染锚点，观察战斗干扰、处理顺序和空间目标是否形成自然取舍；K5 再将这些动作组织为包含阶段推进与交付的短流程。系统依次加入，使反馈能够对应到具体变化，减少同时修改多个层面带来的归因困难。

图 6　K5 单房间短流程的历史白盒留档，将核心动作、污染锚点、压力资源与阶段目标放入同一局体验。画面用于说明流程整合的验证环境，连续体验与平衡仍需实际游玩判断。

进入五关版本框架后，验证对象进一步扩展为关卡赋予动作的意义。门厅的开阔区域、行李车与侧墙提供接近、拖拽和借物撞击的机会，长廊的转角与路径组织则改变视线、站位和投掷方向。区域、出生点、撞击区和动线调试层帮助检查这些机会是否真实存在。白盒的制作价值由此体现为一组可反复提出的体验问题：玩家看见什么机会，为何选择某条路径，动作如何改变局面，完成一段目标后又如何进入下一段节奏。历史规则与图中数值只用于解释当时的设计取舍，不作为现行平衡参数。

图 7　五关版本门厅的调试总览，叠加区域、出生点、撞击区与动线，检查核心动作是否获得相应的空间机会。此为诊断视图，区别于玩家正常镜头和最终 HUD。

可控性实现案例： 遭遇与关卡节奏（4.5） · 清扫与污渍（4.6） · 镜头与信息可见性（4.3）。

2.6 文案与叙事

AI 负责起草世界观设定、委托文案、角色对白与界面文字，开发者确定整体风格：轻松的女仆店喜剧基调，主角迷糊冒失，故事带有轻度的"日常之谜"。迭代中沉淀出明确的禁区：叙述性的字幕不予采用，战斗横幅只使用"主体·事件"的简短格式；战斗字幕以直观为先（"撞墙！""命中！"），特殊事件才使用修饰性表达；世界观设定只用于解释和串联机制，不得反过来修改机制。

文案是 AI 产出最快、采纳率最低的环节，原因在于游戏文本的质量更多来自取舍而非数量。实践中最有效的做法是：先提出若干"故事前提"供开发者挑选，再展开写作；同时以禁区清单约束风格，其效果优于正面的风格描述。

可控性实现案例： HUD中目标、状态与提示的表达（4.10）。

2.7 原画与美术风格

美术风格由开发者确定：插画感，整体色调为"深色底 + 暖色光池"。AI 的职责是将风格转化为可执行、可检查的规范（色板、灯光倾向、材质约定），并在每次画面修改后输出对照图供开发者判断。

AI 曾在一次批量修改中误改已通过验收的 Boss 关卡视觉效果。此后项目规定：已通过的视觉效果必须可以原样恢复，任何批量修改之后必须重新拍摄关键画面进行确认。

2.8 场景美术：从结构还原到氛围营造

2.8.1 场景成果的四层评价

场景美术的交付需要同时服务视觉表达、玩法使用和持续维护。本项目将其划分为四个评价层次：

结构还原是场景生产的基础。随着迭代深入，评价重点进一步扩展到玩法适配和维护能力，使 AI 生成的内容能够进入持续迭代的制作流程。

2.8.2 钟塔温室：用平面与剖面共同约束空间还原

钟塔温室的空间设计围绕中央钟架组织：环形主场提供绕行与调整站位的余地，两侧花园和后侧平台建立清晰的空间层次，入口轴线保持主要地标的识别。场景还原因此需要同时保留平面的通达关系与剖面的高差关系。单一透视画面能够呈现场景气质，却不足以完整检查路线、平台和建筑构件之间的连接。

制作中，开发者先将设计参考拆解为入口、主场、钟架、花园、后平台、水池及围护结构，再由 AI 在 Blender 中搭建可修订的结构模型。平面对照用于核对主要节点、环形路线和水池边界，纵剖面对照用于检查平台层次、楼梯衔接及穹顶围合。评审由整体框架逐步推进到栏杆、步道边缘和水池分层，避免“远景相似”替代具体构件的准确组织。

第三轮与第五轮的留档记录了这类结构评审的持续修订。其价值在于把视觉要求转化为可定位、可比较的修改对象：开发者明确需要保留的空间关系，AI 完成结构调整并提供对照，再由开发者裁定还原程度及玩法适配中的取舍。结构评审之后，仍需在 Godot 中分别验证可行走面、碰撞、交互和实际镜头可读性，使美术框架真正服务于玩家的空间理解与操作体验。

结构复核也包含对约束冲突的取舍。例如，北侧楼梯在模型中延长水平展开，以改善通行坡度；平面路线、建筑比例与角色运动需求因此需要共同评审。图中的设计标高是参考约束，模型是否满足全部尺寸仍需测量，不能仅凭视觉相似判定完成。

图 8　钟塔温室纵剖面对照。左为设计参考，右为第五轮模型渲染；对照主场地、花园、后平台与穹顶围合形成的空间层次。

图 9　钟塔温室第三轮纵剖面对照。左为设计参考，右为当轮模型；与第五轮并列记录平台、楼梯与穹顶构成的阶段变化。

2.8.3 资产组件与关卡配置的分层交付

整场景导出可以快速形成视觉结果，资产组件化则为复用、局部修改和安全更新提供基础。项目按独立修改需求整理道具、建筑和功能物件，明确源资产、固定摆放、碰撞代理与交互配置的维护归属，再由导入和接入工具完成转换。

图 10　从资产组件、导入处理到关卡场景、交互接入与运行验收的制作流程。源资产更新与关卡配置维护分别管理。

这一分层同时处理表现差异与配置继承问题。Blender 中的材质、体积和发光效果进入 Godot 后，按实际渲染管线重新校准；固定布景保存在关卡场景中，天气、动画、粒子与状态反馈继续由运行时执行。AI 可以批量处理导出、材质转换和引用维护，设计者则保留对空间关系和关卡表现的直接调整能力。

2.8.4 氛围营造：光、材质与引导

氛围营造服务于两个目标：传达场景情绪，以及在不使用文字的前提下引导玩家。本项目的主要手段如下：

• 光池引导 ：整体保持"深色底 + 暖色光池"，用台灯、烛台与吊灯形成的局部暖光标出可互动区域与主路线；开发者曾否决门厅加雾与锅炉房灯光的若干方案，理由是削弱了光池的引导作用。
• 玩法元素自带光 ：锚点核心、挂锁守卫等玩法实体自带光源，使其在暗部中天然成为视觉焦点。这些光源归属于“玩法层”，由玩法系统在生成实体时同步创建，而非作为场景静态灯导入。
• 材质的状态表达 ：例如茶渍的"新鲜"与"干涸"只通过光泽度区分，并配合与锅炉同风格的粒子蒸汽；所有干涸污渍不使用裂纹，避免与碎瓷类污渍混淆。
• 地面高光保留 ：地面反光是氛围的重要组成部分，不因"减少干扰"而移除；对"漂浮火苗"类问题，只过滤缺少支撑物的火焰贴片。
• 遮挡与可读性 ：角色被前景物体遮挡时，遮挡物按规则淡出；吊灯等顶部物件在特定机位下的遮挡单独检查（后期章节的舞台灯遮挡属于专项检查对象）。

2.8.5 Blender 至 Godot 的可编辑制作流程

本项目对工作流的改进，重点在于建立源资产与引擎中的场景配置之间的稳定交接。早期流程以生成可运行原型为目标，部分固定内容与动态行为共同在启动阶段建立；后续将两者分离，使固定配置具有持久化的编辑入口，并使运行结果能够追溯到相应资源。

该流程将“高可控性”转化为具体制作能力：设计者能够独立调整，修改能够保存并进入正确运行入口，相关配置能够保持一致，资产更新具有明确的继承策略。AI 的价值由一次性生成扩展为可重复的转换、维护和验证；实现范围与验收范围按关卡分别记录。

2.9 角色美术与动画：从动作连续性到材质性格

角色与怪物的动画首先服务于动作识别和反馈判断。玩家需要在移动、吸取、投掷和碰撞的连续操作中，感知角色是否响应、物件何时受力、敌人何时恢复行动；同时，动作应保持原有角色的轮廓、体型与可爱感。本项目的迭代因此围绕三个目标展开：补足必要的运动连续性，稳定动作切换时的视觉身份，以分阶段、分物种的弹性表现传达受力与材质差异。

2.9.1 动作帧增强：提高连续性，保持操作节奏

米露既有二维动作由完整角色的视频帧加工为八方向图集。AI 承担来源整理、有效运动区间选择、采样、抠像、尺度与脚锚校正、边缘处理及图集登记；开发者提供或指定素材，确认方向、外观和动作节奏。处理保留完整身体，避免局部拼接造成姿态和画风割裂。

跑步增强由每方向8帧、20fps提升为12帧、30fps，步幅仍为0.4秒。增加有效姿态让腿部运动更连续，维持周期则使既有移速、落脚节奏和操作判断保持一致。已应用版本的96张动作帧中，77张取自原视频，19张采用运动估计补间；逐帧记录来源与采样时间，使新增内容能够被追踪、比较和回退。

待机动作采用双向光流补帧提高循环连续性，并保留原始帧；新增帧通过轮廓、透明边缘与描边检查，避免耳尖缺失或裙边残影。

移动喷射进一步解决“角色在移动，但身体仍保持固定发射姿势”的表现断层。整身动作、瞄准方向和逐帧枪口位置共同接入原有状态逻辑，停止及恢复移动时保留腿部相位，受击与冲刺仍按既有优先级响应。该动作按方向分别处理，七个方向采用完整循环，正面按素材约束保留指定固定姿态。制作目标是使持工具移动的身体动作、朝向和发射位置形成一致的视觉因果。

图 11　2026-10-12 留档。将来源动作加工为完整角色图集，并统一身体尺度、方向与脚锚；正面按素材约束保留固定姿态。图像展示制作结果，连续节奏另以动作播放检验。

2.9.2 Q弹表现：建立受力阶段与物种差异

“Q弹”的设计目的，是让玩家读出动作的蓄势、释放、撞击和恢复，同时保持角色与怪物的材质性格。项目将序列帧负责的动作姿态，与运行时负责的短促形变分层组织：动作素材保留主体表演，弹性控制器叠加有方向、可衰减的受力反馈。玩家既有的换动作形变、呼吸与相位接续在图集增强时保留；怪物则按投掷与碰撞链路专项迭代。

怪物弹性分为出手短拉伸、飞行滚转、撞击压缩、反向回弹、落地扶正和受击回位等阶段。撞击方向决定压缩方向，连续冲量承接当前形变与速度，最终回归稳定体型。灰尘兔强调柔软与圆润，茶杯以较小应变和较快收稳体现硬度，链尾鼠反应紧凑，噬袋则采用更缓慢的回收节奏。差异由幅度、阻尼和恢复时间共同形成，避免用同一种夸张缩放覆盖所有物种。

开发者的审美裁决直接影响表现取舍。侧身灰尘兔原姿态已偏扁，后续取消了蓄力时附加的宽高变化及满蓄脉冲，保留原动作、后坐位移和光效；撞击、出手和落地阶段的弹性继续使用。该调整说明，动作强化需要服从角色识别与形体特征，效果强度并非越高越好。

图 12　2026-10-16 受控表现留档，对照正面兔、侧面兔和茶杯在指定受击时刻的形态。单帧呈现压缩与轮廓差异，恢复速度和回弹节奏需结合连续动作判断；侧身兔蓄力的附加宽高变化在后续版本取消。

2.9.3 AI协作中的制作闭环

这组迭代形成“体验反馈—问题分层—候选比较—局部修正—运行复核”的协作方式。AI 负责批量处理、参数化实现、来源记录和受控对照；开发者负责动作意图、造型保真、力度和节奏的最终判断。单帧与接触表用于发现耳尖、裙边和体型问题，连续视频用于评审主弹、回弹与稳定的时间关系，固定场景进一步检查动作在真实镜头与事件中的可读性。生产效率来自可重复处理，品质控制来自明确的观察对象和持续的人工裁决。

可控性实现案例： 动作时序与反馈联调（4.9）。

2.10 特效：从题材表达、组合试验到实机接入

2.10.1 设计目标：使操作结果可感知，并形成统一的题材语言

《夜颂家政》的特效同时承担操作反馈、状态辨识与题材表达。吸取需要使玩家读出物质向吸口汇聚，投掷需要呈现明确的出手方向与释放瞬间，撞击需要区分力度和材质，清洁与收容则需要传达完成感。泡沫、茶器、花瓣、薄荷色光流与金色纹样由此形成共享的视觉语言，使不同功能能够被辨识，又保持清扫与茶会题材的一致性。

特效强度还需要服从信息层级。持续效果应维持方向与范围的可读性，短时爆发应强调关键结果；在密集交互中，角色轮廓、敌人状态和行动空间仍需保持清楚。开发者负责这些体验目标和审美取舍，并提供参考图与符合题材的特效贴图；AI 依据选定材料完成图层组织、运动实现和引擎接入。

2.10.2 组合试验：先将视觉选择转化为可比较方案

开发者建立了 HTML 预览与 Godot 特效插件两类试验入口，用于尝试贴图搭配、图层层级与动态节奏。网页将底座、主流、环绕、泡沫、气泡和闪光等元素分层呈现，可比较各层的显隐、透明度、运动和密度，并保留参数反馈。这样，讨论可以围绕具体的视觉组合展开，而不只依赖“更华丽”“更有力度”等宽泛描述。

HTML 预览承担低成本的组合与节奏评审；进入引擎后，插件按效果和图层管理配方与贴图候选。已绑定游戏字段的图层可将选择写入特效配置、刷新读取缓存并重建预览，使制作人员能够继续比较方案。两类工具共同缩短了从参考意图到可观察结果的距离，也保留了开发者对素材选择和组合关系的控制。

网页采用二维近似，Godot 仍需根据三维朝向、深度、灯光和混合方式重新校准。项目因此将“组合方案确认”与“实景表现确认”分为两个评审阶段，分别解决视觉选择和运行适配问题。

图 13　HTML 特效组合试验界面。图层开关与参数将参考意图转化为可比较的视觉组合；网页采用二维近似，选定方向仍需在 Godot 中完成空间、材质与事件校准。图中参数用于方案预览。

图 14　净化法阵的两类制作视图。A：在门厅环境中观察法阵轮廓、贴图组合及其与场景明暗的关系；B：通过滑条调整法阵透明度、自发光、泡泡边光与碎光等参数，并在独立三维视窗中即时预览。两类视图分别支持场景融合判断与表现参数试验，共用正式特效资源。图中均为插件临时预览。

2.10.3 从选定方案到游戏表现的交付链

2.10.4 实例：将搭配决策落实为明确的表现规则

终结净化的浏览器反馈记录体现了这一协作方式：开发者确认加快整体节奏、提高视觉尺度、削弱地面层，并移除泡沫层，保留光柱、气泡与闪光的层次。AI 随后将选定参数落实到引擎时序和图层预算。该版本将视觉缩放与语义范围分开处理，使表现调整保持在预定的规则边界内。这里的制作价值，是把审美选择转化为可复现的配置与实现，而不是单纯增加粒子数量。

吸收与喷流的迭代进一步说明了空间和事件语义的重要性。选定的三段喷流预览进入 Godot 后，分别保留头部和尾部形态，由中段承担长度延伸；吸收使用指向吸口的汇聚运动，释放则在出手事件中产生向外喷流。持续吸收与一次性释放采用不同的实例生命周期，挂点也从地面附近调整到工具吸口。由此，视觉方向、发生位置和触发时机共同表达了“吸入”与“释放”的区别。

特效制作中的 AI 协作因此形成了清晰分工：开发者确定体验意图、参考、素材与组合取舍，试验工具提供方案比较的环境，AI 负责将选定方案转为可运行且可维护的表现。最终评价仍回到玩家是否及时理解动作、感受到结果，并能在连续操作中保持判断。

2.11 UI / UX：HUD 的信息架构与运行时调度

2.11.1 空间信息架构与时间信息架构

本项目将 HUD 设计拆分为"空间信息架构"和"时间信息架构"两部分。

空间信息架构 依据阅读顺序与功能邻近性配置界面：角色状态与仪态位于左上，委托目标位于左侧，地点与小地图位于右上，表现评价位于右侧，技能与资源积攒状态位于右下，伙伴提示位于左下；准星、蓄力与目标反馈围绕画面中心布置。

时间信息架构 负责运行时调度：各组件根据开场、探索、瞄准、蓄力、受击、仪态变化与结算等状态，调整可见性、视觉权重与驻留时间，而非长期以相同强度并列显示。

设计首先以 1920×1080 基准稿确定主要信息区域与视觉层级（图 15），随后将组件接入实际游戏状态。布局测量以玩家可见的装饰边界、文字范围与交互热区为准，而非透明素材的画布尺寸；同时维护屏幕占用矩形，用于检查 HUD 组件、世界空间标记与临时提示之间的冲突。设计稿定义空间关系，运行时规则定义各区域在不同状态下的占用权与显示优先级。

图 15　2026 年 10 月 1 日形成的关内 HUD 排版设计稿，定义角色状态、委托、导航、表现评价、技能与伙伴提示的空间关系。图中并列展示开场委托单与常驻 HUD，用于说明完整组件体系与目标构图，不代表所有组件在运行时同时显示。

2.11.2 当前布局：原生配置与状态调度

战斗 HUD 的固定布局已由独立原生场景组织，仪态、任务、技能、风格、小地图、事件横幅及伙伴提示等共 15 个组件分别保存锚点、位置和尺寸。布局配置维护空间关系，运行逻辑维护动态内容与显示时机，使设计者能够独立调整界面，同时保留战斗反馈的时序和状态响应。

图 16　依据2026-11-01原生场景配置整理的布局示意。基础组件与条件信息分层表达，上部事件区按状态协调占用。

信息组织以玩家的即时判断为依据：仪态与委托维持任务连续性，右侧评价与技能组件反馈表现和行动资源，中央视域优先服务角色、目标和落点识别。连击牌独立保存布局，伙伴提示按内容和事件出现；Boss 与警报保留安全避让，任务栏高度随条目变化。信物飞入与资源增益等短时反馈依附相应的任务或资源组件，落点随布局关联。固定位置可编辑，状态约束继续由运行逻辑维护。

图 17　正式门厅中的战斗 HUD，展示仪态、委托、小地图、技能与伙伴提示的实际组合。2026-10-31 场景化接入留档。

2.11.3 状态驱动的视觉权重

界面显著性随交互状态动态调整。进入瞄准或蓄力状态后，左侧委托栏透明度降低至 35%，操作结束后延迟 0.35 秒恢复，以减少周边信息对中央战斗视域的竞争（图 18）。上述数值为当前版本的实装参数，并非通用设计标准。

图 18　既有版本瞄准状态的视觉优先级示例。委托栏保留原有位置以维持空间记忆，但降低显著性，使目标、准星与动作反馈成为主要视觉焦点。

各信息任务的显示区域、调度规则与验证重点如下：

2.11.4 流程验收与分工

界面流程的验收采用真实游玩的逐帧序列：从关卡开场的委托卡展开、委托清单收起为常驻面板、任务项逐条完成，到最终结算界面，完整记录界面变化（图 19）。

图 19　门厅关卡委托界面的完整流程序列：开场委托卡 → 常驻任务面板 → 任务逐项完成 → 结算评级。

HUD 验证不能以单张全量截图替代状态覆盖。验收矩阵包含开场、常态、瞄准、蓄力、委托更新、仪态变化、Boss 事件与结算等关键状态，并在相同分辨率、机位与事件时刻进行改版前后对照。自动检查用于验证占用矩形、状态接线、资源引用与包体收录；文字扫读效率、装饰显著性以及高压操作下的信息可察觉性，仍需通过真实游玩与人工评审确认。

这一案例体现的是一条完整的协作链路，而不仅是"AI 按设计稿制作 UI"：视觉设计定义信息层级与空间分区，程序实现状态驱动的显隐与优先级，UX 验证通过同状态对照识别注意力竞争与读取路径问题。AI 主要承担测量、接线、批量生成验证图与执行回归；开发者负责信息取舍、审美判断、交互优先级与最终验收。

2.11.5 可视化维护：布局与内容的编辑职责

原生编辑入口将界面空间调整从脚本修改中分离。战斗 HUD 的技能组件通过右下锚点维持屏幕关系，图像和所属文字随父组件整体移动与缩放；仪态提示、技能说明、地点标题和风格文字另设文字布局与字号。动态数值、装备贴图和状态动画继续由游戏逻辑填充。

图 20　2026-11-01 拍摄的战斗 HUD 原生编辑界面。技能组件位于右下锚点，检查器展示位置、尺寸与缩放；控件树包含所属图像与说明文字。

外围 UI 采用相同的职责划分。契茶店页面以原生控件组织人物名牌、订单区与前景构图，运行逻辑负责订单内容、动画和页面状态。设计者可以直接维护固定几何与文字层级，AI 负责结构生成和业务接入，减少重复传达布局需求的成本。

这种分工使 UI / UX 的控制范围同时覆盖空间、内容与时间：布局资源保存可持续调整的视觉关系，运行规则保证状态响应，体验评审判断信息是否可读、可察觉并支持行动决策。

可控性实现案例： HUD布局与状态控制（4.10）。

2.12 质量保障与玩法验证：从规则正确走向体验成立

质量保障检查规则、数据与实现是否一致，玩法验证检查玩家能否理解并运用机制。项目按变更风险组织测试：先通过低成本自检排除确定性错误，再进入实机与真人验证。

2.12.1 验证分层：按问题选择方法

AI 工作流。 开发者明确本轮设计问题与验收条件；AI 根据改动影响选择用例、执行测试，记录失败条件、首次偏差与复现步骤。开发者结合实机表现和试玩反馈确定修改方向，再由 AI 回归受影响流程。例如，祝福需要检查候选是否合法、品质提升是否产生实际收益，以及奖励提交后效果是否生效；HUD 则需覆盖常态、瞄准、委托更新和结算等不同状态。

2.13 音频

音频分为音效与背景音乐两条线，由 AI 结合专业工具完成。

音效 ：主策划先整理音效需求表，逐项说明每个挂点的用途、时长、情绪与参考。AI 通过 SoundDock 的 MCP 接口检索本地音效库，依据候选与需求表的匹配程度进行初筛，经开发者多轮试听确认后进入后处理。后处理统一遵循交付标准：WAV 16 位、44.1 或 48 kHz；开头无静音，加入 3 至 8 毫秒淡入以防爆音；单次音效峰值约 −1 dBFS，环境声按平均响度定级；按包络裁剪尾部；必要时进行多层混音（例如"链扫"技能音效由扫击、锈链与钥匙串三层在不同时间点叠加而成）。音效库中缺失的素材（如茶店窗外的雨声、瓷壶注茶的细流声）由 AI 生成，生成源文件与处理脚本完整留档，可重复处理。

背景音乐 ：每首曲目的需求先以文字形式详细描述，包括使用场景、时长与是否循环、情绪、速度、调性与配器，以及挑选要点，统一记录在音乐需求文档中，再交由 Suno 生成。每首生成多个候选，结合游戏画面挑选。为区分游戏状态，关卡音乐采用"宁静版 + 激烈版"的成对设计：先生成清扫阶段使用的宁静版，再在同一首曲目基础上以翻唱方式生成战斗阶段的激烈版，保留旋律与调性，使两个状态之间可以无缝交叉淡入淡出。循环曲挑选时要求中段稳定、结尾不出现大段渐弱，循环点由 AI 剪辑；整体响度统一为背景音乐 −18 LUFS，界面与战斗音效分总线管理。

音频与打击感的联动 ：撞击音效按打击档位变调（轻档、重档、完美档分别约为 1.06、1.0 与 0.92 倍）；在撞墙、震屏等最具爽快感的时间点，音频短暂减速、变调后回弹，以强化"命中瞬间"的停顿感，增加游戏的趣味性。这些参数与画面上的停顿、震屏同属打击反馈参数体系，可在调参台中统一调整。

三、跨职能联调：多 AI 并行下如何保持信息一致

商业项目中最耗费沟通成本的是联调：战斗策划调整一个停顿时长，动画、特效、镜头、音效都需要跟进；关卡修改一处地形，碰撞、灯光与遭遇点都会受到影响。多个 AI 并行工作时，这一问题更为突出，因为每个 AI 只看得到自己被分配的上下文。本项目通过七项机制管理这些问题：

3.1 唯一数据源

每个系统明确参数的权威来源、导出路径和运行覆盖；外部工具与测试读取同一配置，不在各自脚本里维护无来源常量。对于尚未统一的资源和兼容路径，保留来源表并逐项迁移。导出结果的稳定性与一次修改是否实际生效，需要分别检查。

3.2 按文件划分所有权

每条工作线明确可写文件与扩展挂点。例如资产库维护模型与材质，导入工具维护转换规则，关卡场景维护固定摆放，玩法组件维护交互和状态行为。共享文件只做局部修改，修改前重新读取最新版本。接口或资源发生变化时，同步更新引用方及验证记录。

3.3 共享台账与工作线之间的直接通信

玩法与美术之间维护一份对接台账，记录每个待对接事项的需求方、负责方、当前状态与相关截图。各 AI 工作会话之间可以直接发送消息，用于申请共享资源、通知规则变化与报告阻塞。

例如，碰撞交付说明应区分可行走面与实体阻挡，玩法接入说明应列出机关节点、脚本参数、触发范围和目标引用。交接不能只写“已导出”或“已挂脚本”，还需明确哪些配置由关卡场景维护、哪些由运行逻辑读取，以及用哪个入口验证。

3.4 同一时刻、同一机位的对照

对照需控制与问题有关的条件。比较新旧美术时固定机位、照明和显示状态；比较动作表现时使用相同输入与时间点；比较编辑结果时同时记录关卡场景与实际启动入口。差异仍需结合配置和日志归因，不能仅凭两张截图断言所有变化都来自单一修改。

3.5 调参台作为联调的公共工作台

战斗联调的核心流程（吸取—拖拽—投掷—撞击）可以在调参台中一键重放；停顿、震屏、镜头推近、物体形变、特效、字幕与音频变调集中在同一界面，配有实际读数与约束检查。方案可以保存为预设并现场切换比较。

3.6 合并前的回归检查

合并验收要求按变更范围执行回归：固定输入回放、各系统测试，以及模型、碰撞与交互配置的一致性检查。回归结果写入版本提交说明；每条工作线只提交自己修改的文件，不提交他人尚未完成的修改。

3.7 共享资源的排队与审批

大型编译与开窗渲染等高负载操作统一排队，同一时间只允许执行一项；开窗渲染需经开发者批准，并设有时长与分辨率上限。这一规定来自实际事故：开发机曾在多个渲染任务同时启动时发生硬重启。另一条规定是：修改共享工程前，先在隔离的副本中验证能正常编译。项目中曾有一次未经验证的代码进入共享工程，导致另一条工作线的编辑器无法启动，此后该规则固化为强制流程。

四、可控性体系：让设计意图贯穿每一次迭代

《夜颂家政》希望玩家在清扫与战斗之间形成连续、主动的行动节奏：看清目标，判断可利用的物件，通过吸取、拖拽和投掷改变局面，再从命中、收容和环境恢复中获得明确反馈。这个体验同时依赖操作响应、空间尺度、敌人行为、镜头取景和信息提示。任何一项单独成立，都不足以保证整个过程自然流畅。

因此，可控性的设计目标是维持这些关系：角色的行动符合玩家意图，反馈能够解释行动结果，关卡压力为判断和发挥留下空间，成长与奖励回应玩家实际采用的策略。AI 可以快速完成实现和批量修改，制作人仍需要掌握决定体验的变量，并能够比较修改前后的结果。调参工具由此承担设计意图与工程执行之间的共同工作界面，使每次调整具有明确的体验问题、观察条件和保留依据。

项目以“参数配置、可操作界面、关系约束、可复现验证”作为统一方法。参数描述设计关系，界面提供持续调整的入口，约束维护反馈层级和历史裁决，固定输入及状态对照帮助判断因果。在已接入的战斗切面中，预设、A/B、实测读数、撤销和写回构成较完整的试验流程；遭遇、成长、经济及 HUD 则分别通过时间线、数据资源或原生布局场景维护。共同的方法允许工具形态有所差异，同时使各职能围绕同一个体验目标协作。

4.1 操作与移动：让行动意图稳定转化为角色行为

预期体验。 玩家需要在识别目标、接近物件、拖拽走位和选择投掷方向之间快速切换。角色既要保持响应，也要让持物和移动的重量差异可被感知。过强的惯性会削弱精确操作，过度即时的转向又会使牵引与负重失去质感；移动调优因此是在准确性、节奏和重量感之间建立稳定关系。

控制方法。 五关版本基线主要围绕探索／动作节奏档、奔跑与拖拽速度、冲刺距离与持续时间、冷却、目标选择、瞄准稳定、牵引响应和蓄力倍率组织参数。门厅参数示例中的奔跑与拖拽速度为 3.0／2.7 米每秒，其意义是让持物保留行动能力，同时表达一定负担。冲刺距离需要与走廊宽度、目标间距及危险区相匹配；方向保持与输入容错服务于稳定选取，避免玩家的意图被细小输入扰动打断。

观察与裁决。 固定冲刺、吸取和投掷场景用于比较相同站位与输入下的位移、耗时和目标结果，再回到门厅等实际空间评估行动节奏。AI 执行重复输入并记录差异，策划判断操作是否符合预期、重量表达是否清楚，以及连续行动能否顺畅接续。这里的角色能力与关卡度量共同维护，避免通过单方面提高速度掩盖空间或选取问题。

图 21　正式门厅运行中的冲刺切面，将方向输入、冷却、探索与行动冲刺距离、持续时间集中呈现。字段同时标明生效条件，使能力度量、输入响应与实际空间能够在同一语境下讨论。

4.2 打击反馈：让力度、材质与行动收益能够被读懂

预期体验。 投掷命中应成为明确的行动回报。玩家需要感知轻重差异，辨认撞墙、撞怪与撞杂物的不同结果，并理解一次连锁或完美命中的价值。反馈还需要为下一次判断保留可读性：镜头、闪光和粒子持续过强，会使命中更醒目，却削弱目标、落点和后续机会的识别。

控制方法。 项目将反馈分为撞击分档、来源修正、受击表现与特殊事件四层。分档决定基础顿帧、震屏、镜头冲击、形变与视觉峰值；来源系数赋予对象差异；击退、失衡和晕眩决定命中后的行动窗口；连锁、撞钟和技能爆发再获得特定的慢动作及取景。门厅示例的分档线为 18 与 21，轻／重／完美档的名义顿帧为 0.04／0.07／0.11 秒。策划控制的是反馈梯度及组合关系，而非将各层强度同步放大。

观察与裁决。 调参台把一次撞击涉及的字段与实际结果并列显示。历史 A/B 案例中，同一次约 17.26 的撞击在软档阈值由 18.0 改为 17.1 后进入另一档，实际顿帧由 34.0 毫秒变为 59.5 毫秒。固定输入使策划可以判断变化来自分档，而非出手差异。阈值顺序和轻重反馈关系由约束提示维护；最终仍需结合画面、音效及下一次可操作时刻，判断反馈是否清楚、利落且符合题材。

战斗切面的完整界面与同次撞击读数见图 1；约束反馈见图 2。

图 22　正式门厅运行中的撞击切面。分档阈值、不同力度的震屏与后续反馈字段在同一页维护，下方保留实际读数与重放控制；同次撞击的A/B量化案例见图 1。

4.3 镜头：让重要信息在需要时进入视野

预期体验。 玩家应能够同时理解自身位置、目标状态和可用空间。镜头既要保留庄园场景的氛围与尺度，也要在抓取、蓄力和撞击时服务于操作。镜头变化的价值体现在帮助判断，并以稳定的视觉节奏引导注意力。

控制方法。 基础距离、俯角与视场决定常态信息容量；战斗拉远、注视点前移与抓取推镜突出行动关系；目标入画、贴墙抬升与遮挡淡出保护角色和敌人的可见性；缓入缓出决定焦点转移是否自然。不同镜头语境分别维护参数，动作强调与空间观察在同一框架中协调。

观察与裁决。 镜头资源与相应战斗切面提供编辑入口，固定距离、方位与输入用于检查目标可见比例、镜头位移及遮挡。已有怪物入画矩阵将站位问题转化为可比较的构图结果。策划据此判断目标是否持续可辨、取景是否解释行动关系，以及镜头强调是否干扰瞄准。场景氛围工具补充曝光、雾和局部表现的观察，保证画面风格与玩法信息共同成立。

图 23　门厅参数编辑界面。检查器将距离、视角及相关镜头响应纳入可维护资源；构图是否支持目标判断，仍需结合入画测试与实际操作评价。

目标在不同站位与方位下的可见性比较见图 3。

运行时取景与表现评审。 录制模式提供游玩、宣传片与自定义三种镜头语境，将距离倍率、俯角、FOV、跟随平滑、前瞻、震屏、景深及遮挡放在真实关卡中观察。FOV影响可见范围与目标辨识，距离与俯角影响角色尺度、地面信息及前景遮挡，平滑与前瞻则影响信息出现的时机。策划可以围绕同一段动作比较这些关系，判断取景是否支持目标选择、落点确认与反馈识别。

图 24　正式门厅中的录制镜头面板，展示FOV、距离、俯角、跟随、景深与遮挡等控制。录制预设按关卡独立管理；确认要纳入正式游玩镜头的方案，仍需同步到相应镜头资源并接受操作评审。

展示语境与信息层级。 同一入口的HUD页提供纯净、实机、全关预设，以及任务、地图、仪态、技能、瞄准、战斗字等12项独立开关。它使制作评审能够分别观察画面主体、完整玩法信息及指定反馈，减少无关元素对判断的干扰。该页维护录制时的显示选择；HUD位置、尺寸与文字布局仍通过原生编辑场景维护。

图 25　同一门厅中的录制HUD面板。预设与分项开关用于建立不同展示条件，完整玩法信息的可读性仍需在实机状态下评估。

AI负责读取配置、执行固定条件采集并整理差异，开发者判断视野容量、动态稳定性与展示重点。录制配置独立保存，使取景试验能够持续比较，也使正式玩法镜头与展示方案具有明确的维护边界。

4.4 怪物：使行为压力与物种性格保持一致

预期体验。 不同怪物应要求玩家作出不同判断，同时保留易于识别的性格。灰尘兔的柔软、茶杯的硬脆、链鼠的灵巧和噬袋的重量，需要通过行为与反应共同表达。战斗压力来自行动方式和时机，材质感来自受力与回弹，两者分别控制后再联合评估。

控制方法。 独立怪物资源维护移动、游荡、逃跑、受惊、引诱、挣扎和产尘等行为参数；撞击与动画配置维护弹性、失衡、晕眩及恢复表现。这样可以调整受击的清晰度和重量感，同时保持原有速度、攻击与状态规则。连锁传递和连续受击还需要维护上限与恢复关系，防止强反馈使物种轮廓和状态识别失真。

观察与裁决。 资源检查器用于维护行为与物种参数，撞击切面用于比较同次受力，实际遭遇用于观察追逐、逃跑、牵引、命中和恢复的连续关系。AI 负责批量覆盖状态与记录异常，策划判断怪物的可预期性、反制机会及物种辨识度。素材与弹性表现的具体迭代见角色美术与动画章节；本节关注它们如何共同服务于战斗判断。

图 26　门厅参数编辑界面。物种行为参数以独立资源维护，用于形成可辨认的行动压力与反制机会；受击弹性另与表现配置联合评审。

4.5 遭遇与关卡节奏：把压力组织成可学习的过程

预期体验。 清扫与战斗需要形成起伏，玩家能够发现威胁、选择处理顺序，并在解决一段压力后得到恢复与观察空间。持续堆叠敌人会消耗注意力，过长空档则削弱行动目标；遭遇设计需要控制压力的来源、持续时间和转折条件。

控制方法。 区域唤醒、波次延迟、怪物种类与配额、出生位置、预警、阶段上限及兜底条件，共同构成遭遇曲线。编辑器时间线按区域呈现波次，将时间调整与结构调整区分管理。例如门厅编辑界面显示普通／峰值／核心阶段上限为 4／5／4，核心激增具有独立配额和预警。其用途是明确某段压力由什么事件触发、哪些敌人同时存在，以及玩家获得多少反应时间。

观察与裁决。 以固定种子从关卡起点运行，结合波次触发、预警与出生事件核对压力的形成过程。策划重点观察同一路线上的威胁是否可被提前辨识、场景物件是否支持不同处理顺序，以及清扫与战斗之间是否保留合理的决策余量。AI 负责维护波次、库存与引用的一致性，执行重复测试并整理差异；关卡策划据此判断节拍、反应机会与行动选择是否符合预期。现有工作台覆盖门厅、长廊、宴会厅和锅炉房，温室按其独立阶段组织验证。

图 27　Godot 编辑器中的遭遇工作台，使用门厅现有配置展示区域波次与触发关系。波次、触发条件、出生点引用及关卡节奏在同一工作流程中维护，使压力来源、出现顺序和反应窗口能够被持续比较与调整。

4.6 清扫与污渍：让环境变化形成行动策略

预期体验。 玩家应从污渍状态和环境变化判断下一步行动，并感知战斗如何改变清扫负担。不同污渍提供处理顺序、工具使用和空间后果，使清扫成为可规划的过程，也使场景恢复成为可见的阶段成果。

控制方法。 类型资源分别管理软化、维持、干燥、扩散、碎裂与喷雾等规则。软化持续时间影响操作衔接，轨迹密度与质量影响移动中产生的清扫负担，喷雾范围和作用时间影响覆盖效率。现有资源示例中，默认软化维持时间为 8.0 秒、重新干燥参数为 1.0 秒。这些时间关系决定玩家是否具有识别状态、切换行动并完成处理的合理窗口。

观察与裁决。 原生资源检查器提供类型和状态参数的维护入口，验证围绕“软化—处理—恢复”及“撞击—扩散—二次清扫”展开。数值检查确认状态迁移，实景观察判断变化是否可察觉、处理顺序是否可理解、清洁成果是否足够明确。策划保留污渍的策略定位，AI 维护参数、状态接线和覆盖验证。

图 28　门厅参数编辑界面。软化维持与重新干燥等参数共同定义行动窗口，使识别状态、切换工具和完成处理之间的时间关系可以持续调整。

4.7 技能与成长：让获得的新能力改变行动选择

预期体验。 技能释放应提供可感知的战术机会，成长则需要让玩家理解何种经历带来了新能力，以及能力如何回到吸取、投掷和清扫的核心循环。即时爆发、局内组合与局外习得分别承担不同节奏：前者处理当前局面，后两者建立持续探索与尝试的动机。

控制方法。 技能资源维护作用范围、吸力、持续时间、资源消耗及表现说明；成长数据维护习得与精通门槛；祝福表维护前置、适用动作、状态条件和组合参数。净化涡流资源中的 100 压力消耗，表达的是释放机会的积累与使用成本，需与聚怪收益、目标数量和后续处理能力一并评估。祝福的意义则在于强化具体行动倾向，使组合差异进入玩家可感知的操作结果。

观察与裁决。 技能需要在不同目标数量与位置下比较收益；成长需要覆盖门槛达成、资源不足、习得与精通的完整流程；祝福筛选与合法性检查支持批量维护。能力获得延续既有的局外特调流程，局内提示维持行动连续性。AI 可以检查依赖和参数组合，系统策划决定每条成长线强化何种玩法，以及玩家何时能够感知差异。

图 29　门厅参数编辑界面。技能成本、作用与内容说明通过资源维护，系统策划据此联合评估释放机会、局面收益与玩家理解。

祝福构筑的可视化维护。 C10祝福工作台将现有43张卡的伙伴、动作位、状态条件、前置与效果参数集中维护，使策划能够围绕某条打法检查其入口、收益和衔接。筛选用于聚焦同一类设计问题，效果预览将草稿转换为游戏实际使用的说明与品质变化，批量修改则先呈现差异，再确认应用。配置保存与撤销保留可比较的基线，使AI辅助维护能够进入可审阅、可回退的迭代流程。

“优雅回旋”的界面示例显示3只环绕茶杯、1.05的作用半径与3秒持续时间。数量、范围和持续时间共同定义冲刺后能够保护的空间、影响敌人的机会及下一步动作余量；其设计价值在于让主动接近与短时防护形成衔接。策划需要结合敌群密度、冲刺路径和实际碰撞评估这组关系，并观察它是否支持赛拉菲娜连续作业的玩法身份。界面同时展示普通、精良与稀有品质的效果文本，用于核对成长是否形成可理解的差异。

图 30　Godot编辑器中的C10祝福工作台，使用现有“优雅回旋”配置展示参数与实际效果预览。策划在同一界面审阅作用条件、效果量级与品质差异；配置确认保存后，再通过重新进入相应抽卡或关卡流程检查实际结果。该页不即时重建已生成的候选，也不承担运行中祝福热更新。

4.8 经济与结算：让奖励回应玩家的表现

预期体验。 结算首先解释本次表现，再将不同能力转化为相应成长。整洁体现家政目标，风格体现战斗组织，用时体现处理效率，仪态体现过程稳定性。分项评价让玩家知道改进的方向；奖励映射则让这种改进能够支持下一次尝试。

四项评分与评级。 五关版本的基础满分为100分，未启用额外委托条款时按下表计算：

五关标准用时依次为：门厅180秒、长廊300秒、宴会厅420秒、锅炉房540秒、温室300秒。四项相加后，从高到低检查评级与附加条件：

风格的过程事件用于建立与维持段位。例如墙面撞击记10、目标撞击记15、收容基础记25；它们通过段位变化进入战斗期间的平均表现。最高段位曾达到S，并不意味着整场风格自动得到30分。委托条款另有修正：“委托人挑剔”Ⅰ／Ⅱ分别将S线提高至93／96、A线提高至75／80；“失态赔偿”可另扣总分。整份委托的终章总评按已完成关卡的平均分定档，完成五关后即取五关平均，不重复套用单关的零失态门槛。

从分项表现到奖励。 基础关卡报酬按各自行为计算，而非简单将总评级乘到所有货币上：

主线终章金币另以800为基数，乘总评倍率S／A／B／C的1.5／1.25／1.0／0.8及条款倍率，并取整到10；镇魂钟尚未习得时的终章晶体为固定3颗，不参与上述倍率。练习委托不发这些报酬。

图 31　门厅参数编辑界面。奖励计算按分组维护，使完成效率、整洁与仪态、风格表现及后续获得节奏之间的关系能够分别检查。

结算页示意。 下图以正式评分函数与奖励服务计算的示例数据说明各分项关系：门厅ORDER为94，战斗平均风格分24，用时198秒，失态1次。对应四项为36、24、13.5、10，总分83.5，评级A；同一输入产生茶券2、晶体1、金币132。条目中的收容次数、Q次数与最高段位用于复盘，不再额外重复加到总分。

图 32　正式结算界面的评分示例，展示分项得分、总分、评级及三种报酬的来源。分值按正式公式计算，数据为示例，非真人通关记录。

观察与裁决。 AI负责复算阈值、核对奖励来源与资源读取，并检查重复发放等流程问题；系统与数值策划判断评价是否鼓励预期行为、额外投入是否值得，以及低表现玩家是否仍有可继续推进的空间。资源维护入口与实际结算页共同支持配置、结果和玩家理解之间的核对。

4.9 动画联调：保持动作意图、事件与反馈的时间关系

预期体验。 玩家需要从姿态读出准备、发力和恢复，并在输入、出手和接触之间感到一致。更流畅的素材只有与动作节奏、玩法事件和反馈峰值协调，才能形成清楚、可信的行动结果。

控制方法。 动画配置维护播放倍率、混入混出、副运动与时钟策略，素材清单维护帧数和素材映射，玩法系统维护生效事件。动画页将动作帧带、阶段、事件标记和当前状态集中观察。例如米露待机素材为 16 帧、12 fps，混入与混出各为 0.16 秒，体现素材连续性与动作过渡属于不同控制层。

观察与裁决。 连续播放判断节奏和衔接，暂停与单帧用于观察释放、接触和状态恢复的关系；同输入对照检查调整是否掩盖首个可见响应或破坏既有时序。AI 维护映射、采样和对照，动画与战斗策划共同判断发力是否可读、恢复是否自然。角色与怪物的补帧、轮廓修正和弹性设计作为内容制作案例另行展开，避免将工具界面等同于动画成果。

4.10 HUD：在正确时刻支持玩家的下一次判断

预期体验。 HUD 应帮助玩家确认状态、委托目标和可用行动，同时为角色、敌人、准星及落点保留视域。信息丰富度需要与当前任务匹配：探索时维持进度和定位，精确操作时突出目标，阶段完成时及时确认成果。

控制方法。 战斗 HUD 通过原生布局场景维护组件的锚点、位置、尺寸和部分文字样式；运行逻辑维护动态内容、显隐、动画及避让。整体移动组件时，图像与所属文字保持关联。任务栏高度随条目变化，Boss、警报等事件信息协调占用。既有动作聚焦示例采用 35% 的任务栏透明度，并在动作结束后延迟 0.35 秒恢复，其目的在于保持空间记忆，同时将注意力让给当前操作。

观察与裁决。 原生编辑器用于维护布局，实际关卡与状态序列用于判断可读性；长文案、任务更新、瞄准、释放、恢复和事件并发分别检查。自动检查保护引用、区域与状态接线，UX 评审判断视觉搜索成本和信息察觉。AI 承担布局接入、测量与状态覆盖，开发者决定显示优先级、视觉层级和最终信息取舍。

4.11 制作价值：让每次调整成为能够延续的设计判断

这套体系将毫秒级反馈、秒级动作和关卡级节奏纳入同一协作方法。策划先说明期望玩家感知到什么、作出什么选择，再选择对应变量和比较条件；AI 执行修改与重复验证，工具记录实际结果、配置差异和候选方案，开发者作出最终取舍。确认后的参数、预设与裁决记录成为下一轮工作的依据，使设计意图能够跨工具、跨工作会话持续保留。

因此，控制能力的成熟度体现在能否持续回答具体设计问题：命中为何更有分量，某波遭遇为何形成了过强压力，技能为何没有改变行动选择，提示为何错过了玩家的注意窗口。调参台与相邻编辑工具缩短了问题定位和方案比较的路径，使 AI 的执行效率服务于稳定的体验迭代。

五、各制作工具中 AI 的操作与验收边界

工具接口决定可读取、可修改和可自动检查的范围；生产是否可控，还取决于资产结构与数据责任。

工作流的关键是让每次交接保留修改入口。Blender 中的高质量场景进入 Godot 后，还需要资产复用、碰撞、交互和关卡场景的组织；模型能显示不等于关卡能长期维护。自动检查扩大覆盖范围，最终仍以真实游戏路径和设计者判断决定是否交付。

六、证据类型与适用边界

各类材料回答不同问题，不能相互替代。

以 HUD 为例，设计稿定义目标，区域图说明约束，运行状态图说明指定条件下的结果；外围页面的原生编辑截图则补充维护入口。它们均不能独立证明全部战斗状态与分辨率已经通过验收。材料来源、版本和验证范围共同构成复核依据。

七、反思与建议

第一，AI 提高了生产速度，也放大了方向错误的代价。 AI 可以迅速完成一个复杂但并不正确的方案。建议在每个阶段开始前设置一次强制的路线复审。

第二，AI 协作中的事故大多发生在系统边界，而非能力不足。 多个工作线共享一台机器与一套工程时，曾出现显卡过载导致硬重启、编译中间状态影响其他工作线、缓存访问冲突等问题。解决方法与管理真人团队一致：明确所有权、共享资源排队、在隔离环境验证后再合并。

第三，体验与审美的最终判断仍需由人完成。 对照条件的一致由脚本与流程保证，但"是否好看、手感是否到位、信息是否读得清"需要开发者亲自判断。成对截图、红线标注与针对性修正，是目前最有效的视觉协作方式。

第四，关卡与场景是 AI 最需要边界约束的领域。 AI 可以高效地还原结构、生成度量与批量巡检，但从有限参考推导三维空间、平衡"好走"与"设计意图"，仍需关卡策划的判断；应区分"结构数据一致"与"场景设计完成"。

第五，制作控制依赖可持续维护的内容结构。 固定配置的持久化、资源职责的清晰划分和修改结果的可验证性，共同决定开发者能否独立推进后续迭代。AI 的交付需要覆盖这些制作条件，并与生成内容一并接受评审。

落地顺序建议 ：先围绕核心玩法明确配置来源与验收条件，建立固定输入和代表场景；再为高频调整建设调参、对照及资源维护入口，完善资产导入、关卡场景、交互绑定与重导保护；待修改、保存、运行和回归形成闭环后，逐步扩大 AI 并行制作的规模。