“头文字D Arcade Stage 8 无限”里的椿线下山AE86 第三人称追尾视角这段画面在不少赛车内容里都出现过。把它放到技术视角看它其实是一套很典型的组合第三人称跟随相机 街机化漂移物理 线性油门刹车输入 固定机位录制。这套组合看起来简单真要在 PC 上复现或者自己做一个原型坑主要集中在相机阻尼、车辆参数和帧率稳定性这三块。这个场景的核心特点可以先摆出来第一视角是追尾第三人称相机跟随带延迟和回正第二车辆是前置后驱的 AE86下山路段以连续发卡弯和长下坡为主对刹车点和重心转移特别敏感第三操作输入是街机框体逻辑油门刹车方向盘三件套第四街机基板是专用硬件民间运行会涉及 ROM 和模拟器的版权问题需要单独说清楚。这篇文章会带读者做四件事拆解这个场景的技术构成、给出 PC 端环境准备清单、用 Unity 和 Python 写一套可运行的相机与遥测示例、以及整理一份第三人称驾驶视角的排错表。适合正在做赛车游戏原型、想做第三人称跟随相机、或者想研究街机漂移手感参数的技术读者也适合只是想搞清楚“这段画面为什么看着舒服”的内容创作者。先说明一点下文不会提供任何街机 ROM、模拟器破解或非授权运行方案。椿线下山这个场景只作为技术分析的样本实际动手部分全部基于开源引擎和自建原型素材和录像的使用也要遵守平台版权规则。1. 核心能力速览先把这段内容的技术规格整理成一张表。需要强调的是街机原版的参数属于厂商资产这里不给具体数值只描述技术维度和通用判断。能力项说明内容类型街机赛车游戏的第三人称追尾视角游玩画面车辆AE86 Sprinter Trueno前置后驱手动挡逻辑赛道椿线Tsubaki Line下山方向连续发卡弯加长下坡视角追尾第三人称相机位于车尾上方偏后带阻尼回正输入方式方向盘、油门、刹车、挡位街机框体或手柄映射物理特征街机化漂移抓地力曲线偏宽容容错高于模拟类渲染要求稳定帧率优先第三人称视角对地形绘制距离敏感是否支持网络 API不支持这是本地单机渲染场景没有 HTTP 接口是否支持批量任务原版不支持但可以通过外部脚本做遥测采集和批量跑圈适合场景赛车游戏原型开发、相机系统研究、漂移手感调参、内容录制从这张表能看出一个关键点这个场景的技术难点不在“能不能跑起来”而在“跑起来之后镜头稳不稳、手感顺不顺”。第三人称赛车视角是一个对延迟极其敏感的系统相机比车身晚半拍玩家就会觉得车在飘相机跟得太紧过弯时视野又会被车身挡住。后面几节会围绕这两个矛盾展开。另外要提醒的是街机版和家用移植版在物理参数上并不完全一致网上流传的各种“AE86 调校数据”来源混杂没有官方依据的数值不要直接照搬。自己做原型时参数应该从手感出发反推而不是从所谓“真车数据”出发。2. 场景拆解AE86、椿线下山与第三人称视角椿线是现实中真实存在的山道位于箱根外围特点是弯多、坡度变化大、路面窄下山方向长时间处于制动和重心前移状态。赛车游戏选这类路段做赛道本质上是在放大“刹车点判断”和“出弯给油时机”这两个技术动作。对开发者来说这意味着赛道数据里的坡度、曲率半径、路面附着系数三个字段必须做得足够细否则玩家会觉得弯道“假”。AE86 在游戏里的定位是一台轻量后驱车动力不强但车重小转向响应快。街机版对它的处理方式是放大可操控性漂移起始的临界速度被压低反打方向后的回正速度被提高让玩家在连续弯里能做出连贯的甩尾动作。这套处理方式和模拟类赛车游戏完全不同模拟类追求的是轮胎模型真实街机类追求的是操作反馈明确。做原型时要先想清楚自己站在哪一边两边的参数体系不能混用。第三人称视角在这个组合里承担的是信息传递功能。玩家看不到方向盘转角也感受不到重心转移所有判断都来自画面车身姿态、前轮指向、地平线倾斜、速度感。所以第三人称相机不是简单的“跟在后面”它要把车辆的横摆角速度、侧倾角、纵向加速度翻译成画面的构图变化。这也是为什么很多自制赛车原型跑起来总觉得“不对劲”问题往往出在相机而不是物理。再补一个细节下山赛和上山赛的镜头处理也不一样。下山时车辆重心持续前压相机如果固定在车尾正后方画面会显得车头一直往下扎。常见的处理是把相机稍微抬高、略微前移让车头在画面里的占比更大同时用轻微的俯仰补偿抵消坡度感。这类调整没有标准答案只能靠实际跑圈反复看。3. 适用场景与合规边界这个场景适合三类人。第一类是做赛车游戏原型的开发者需要一套能快速验证手感的第三人称相机和车辆控制。第二类是做技术内容创作的作者想分析赛车游戏的镜头语言和物理表现。第三类是模拟赛车玩家想理解街机手感和模拟手感之间的差异在哪里。不适合的场景也要说清楚。如果你要的是高保真驾驶训练街机化的漂移物理并不适合它的抓地力曲线被刻意放宽了用来教学会传递错误的车辆极限认知。如果你要的是多人竞速的完整产品这个场景里的技术点只是其中一小块网络同步、匹配、反作弊都不在讨论范围内。合规边界必须单独强调。街机游戏的基板程序、ROM 镜像、美术资源都属于版权方资产未经授权的复制和运行存在法律风险本文不提供也不讨论这类方案。想要研究这套视角和物理正确路径是使用开源赛车模拟器或者自建原型比如基于 Godot、Unity、Unreal 从零搭一个简化版。录制和发布游戏画面时也要遵守对应平台的版权规定商业用途需要获得授权。还有一层是素材授权。如果你在自制原型里使用了真实车辆模型、真实赛道数据、真实品牌标识同样需要确认授权状态。很多开发者在这一步踩坑原型做完准备上线才发现车模不能用。更稳妥的做法是早期就用占位模型和虚构赛道等玩法定型后再替换。最后是数据采集的边界。下面会讲遥测脚本这类脚本只应该读取你自己运行的程序产生的数据不应该尝试读取或修改第三方游戏的内存。后者既涉及技术风险也涉及用户协议问题。4. 环境准备PC、外设与显示做第三人称驾驶原型硬件门槛其实不高但对“稳定”的要求比“性能”更高。一台带独立显卡的普通台式机就能跑起来关键是帧率不能抖。第三人称相机是逐帧插值的帧率从 60 掉到 45相机的跟随曲线就会变形玩家感知到的就是“镜头一顿”。环境清单可以按这个思路准备项目建议说明操作系统Windows 10/11 64 位外设驱动和引擎工具链支持最完整引擎Unity 2022 LTS 或 Godot 4.x两者都能快速搭第三人称相机原型显卡独立显卡支持 DX11 及以上具体型号按目标分辨率实测内存16GB 起步赛道资源和贴图加载会占一部分显示1080p 起步刷新率越高越好高刷对追尾视角的顺滑感提升明显输入设备手柄或方向盘方向盘带力反馈体验更接近街机录制工具OBS Studio用于观察实际输出帧率和掉帧点外设这块值得单独说。手柄的摇杆行程短转向输入是“点到点”的适合街机式快速反打方向盘的转角范围大输入是“连续量”适合精细的刹车点控制。如果你的原型目标是街机手感手柄调校优先级更高如果目标是模拟手感方向盘和力反馈就是必需品。两种输入在代码层面的映射逻辑完全不同后面第 7 节会展开。显示设置上有两个容易忽略的点。一是垂直同步第三人称视角开垂直同步能明显减少撕裂感但会引入一帧左右的输入延迟竞技向原型建议关掉改用帧率上限。二是渲染分辨率追尾视角的远景地形占画面比例大如果开了分辨率缩放远处山体的锯齿会非常明显反而破坏速度感。磁盘空间按引擎版本和资源量估算一个带完整赛道和车辆的最小原型加上引擎缓存预留 20GB 左右比较稳妥。如果要做多赛道切换还要考虑资源打包和按需加载。5. 第三人称相机系统的实现要点这是整个场景里最值得深挖的部分。第三人称追尾相机的基本结构是“弹簧臂 阻尼 朝向补偿”听起来简单但每一项都有讲究。弹簧臂负责相机和车身之间保持固定距离同时避免相机穿进地形。阻尼负责让相机的位置和旋转滞后于车身制造“跟随感”。朝向补偿负责在车辆横摆时给画面一个额外的偏航让玩家能提前看到弯道出口。下面是一段 Unity 里的最小实现可以直接挂到相机上跑起来using UnityEngine; public class ChaseCamera : MonoBehaviour { public Transform target; // 车辆根节点 public Vector3 offset new Vector3(0f, 1.6f, -5.8f); public float positionDamping 8f; // 位置跟随速度 public float rotationDamping 6f; // 朝向跟随速度 public float baseFov 58f; public float maxFov 76f; public float maxSpeedKmh 180f; public float lookAtHeight 0.9f; public LayerMask obstacleMask; // 用于防穿模 private Rigidbody targetRb; private Camera cam; private float speedKmh; void Start() { cam GetComponentCamera(); if (target ! null) { targetRb target.GetComponentRigidbody(); transform.position target.TransformPoint(offset); } } void LateUpdate() { if (target null) return; speedKmh targetRb ! null ? targetRb.velocity.magnitude * 3.6f : 0f; Vector3 desiredPos target.TransformPoint(offset); // 简单的射线防穿模相机离车身之间被遮挡时向前收 Vector3 dir desiredPos - target.position; if (Physics.SphereCast(target.position, 0.3f, dir.normalized, out RaycastHit hit, dir.magnitude, obstacleMask)) { desiredPos target.position dir.normalized * (hit.distance - 0.2f); } // 位置阻尼用 1 - exp(-k*dt) 保证不同帧率下手感一致 float posT 1f - Mathf.Exp(-positionDamping * Time.deltaTime); transform.position Vector3.Lerp(transform.position, desiredPos, posT); Vector3 lookPoint target.position Vector3.up * lookAtHeight; Quaternion desiredRot Quaternion.LookRotation(lookPoint - transform.position); float rotT 1f - Mathf.Exp(-rotationDamping * Time.deltaTime); transform.rotation Quaternion.Slerp(transform.rotation, desiredRot, rotT); // 速度感FOV 随车速线性扩张 if (cam ! null) { float t Mathf.Clamp01(speedKmh / maxSpeedKmh); cam.fieldOfView Mathf.Lerp(baseFov, maxFov, t); } } }这段代码里有三个细节值得单独讲。第一阻尼用的是1 - exp(-k * dt)而不是直接乘k * dt。前者在不同帧率下表现一致后者在掉帧时会突然变慢手感会飘。这个问题在第三人称相机里非常常见很多自制原型的“镜头不舒服”根子就在这里。第二防穿模用的是 SphereCast 而不是 Linecast。相机有视锥体积用单条射线检测容易出现边缘穿墙加个球体半径能缓解。如果赛道有大量近景山体和护栏这一步是必须的。第三FOV 随速度扩张的幅度要克制。从 58 到 76 是十几度的变化视觉上已经能提供明显的速度感。有些原型一上来就把 FOV 拉到 100过弯时会产生强烈的透视畸变反而让人晕。朝向补偿部分可以根据需要再加一层。思路是把车身横摆角速度映射成一个额外的偏航偏移让相机在漂移时稍微“看向弯心”。这个偏移量要加死区否则直线上车辆轻微摆动就会让画面左右晃。具体实现和车辆物理强相关这里不展开。6. 漂移手感与车辆参数的调校思路街机漂移和模拟漂移的差别核心在于“容错”。街机版会让玩家在临界点附近有更大的操作窗口模拟版则要求玩家精确踩在抓地力极限上。做原型时如果目标偏街机车辆参数要往“宽容”方向调。车辆参数最小集可以组织成一份配置方便运行时热更新{ vehicle: { mass: 940, wheelBase: 2.4, trackWidth: 1.35, centerOfMassHeight: 0.42, driveType: RWD }, engine: { maxTorque: 220, maxRpm: 7800, idleRpm: 900, torqueCurve: [0.35, 0.72, 0.88, 0.95, 1.0, 0.92, 0.78] }, tire: { frontGrip: 1.05, rearGrip: 0.96, peakSlipAngleDeg: 8.5, falloffRate: 0.62 }, steering: { maxAngleDeg: 32, speedSensitive: true, sensitivityCurve: [90, 90, 70, 50, 38, 28] } }这里面几个字段决定了漂移好不好做。rearGrip低于frontGrip是后驱车甩尾的基础差值越大越容易起漂。peakSlipAngleDeg决定轮胎在多大侧滑角时达到峰值抓地力数值越大越过临界点越晚容错越高。falloffRate决定越过峰值后抓地力衰减多快数值越小衰减越缓漂移越容易维持。steeringSensitivityCurve这个数组容易被忽略。赛车游戏在低速和高速时对转向输入的响应应该不同高速时如果还保持全角度转向车辆会瞬间失控。这条曲线通常在低速段保持大角度高速段快速收窄具体拐点要靠实车跑圈调。重心高度centerOfMassHeight影响侧倾和重心转移。数值调低会让车更稳调高会让车更灵活但更容易翻。AE86 原车重心偏低原型里给到 0.4 左右是一个合理起点但具体还是要看你的模型比例。还有一点漂移手感不只是参数问题还和输入滤波有关。手柄摇杆的原始输入是阶跃式的直接送进物理系统会产生抖动需要加一层低通滤波或者斜率限制。方向盘输入则要处理死区和线性度中间段的细微修正能力直接决定玩家能不能救车。7. 输入设备映射与力反馈输入映射这一层本质是把物理设备的连续量翻译成游戏逻辑的标准化输入。手柄和方向盘的映射模型差别很大需要分开处理。用 Python 做输入调试是个不错的选择能快速验证手柄轴映射和死区设置import pygame import json DEADZONE 0.08 filtered {steer: 0.0, throttle: 0.0, brake: 0.0} def apply_deadzone(value, deadzoneDEADZONE): if abs(value) deadzone: return 0.0 sign 1.0 if value 0 else -1.0 return sign * (abs(value) - deadzone) / (1.0 - deadzone) def low_pass(prev, current, alpha0.35): return prev (current - prev) * alpha pygame.init() pygame.joystick.init() if pygame.joystick.get_count() 0: raise SystemExit(未检测到手柄请检查连接) joy pygame.joystick.Joystick(0) joy.init() print(设备名称:, joy.get_name()) print(轴数量:, joy.get_numaxes()) clock pygame.time.Clock() running True while running: for event in pygame.event.get(): if event.type pygame.QUIT: running False elif event.type pygame.JOYBUTTONDOWN and event.button 7: running False raw_steer joy.get_axis(0) raw_throttle joy.get_axis(5) raw_brake joy.get_axis(4) steer low_pass(filtered[steer], apply_deadzone(raw_steer)) throttle max(0.0, (raw_throttle 1.0) / 2.0) brake max(0.0, (raw_brake 1.0) / 2.0) filtered {steer: steer, throttle: throttle, brake: brake} print(json.dumps({k: round(v, 3) for k, v in filtered.items()}), end\r) clock.tick(60) pygame.quit()轴编号在不同设备上不一样跑之前先打印get_numaxes()和逐轴数值确认映射这一步不能省。很多人调半天手感不对最后发现是油门映射到了扳机轴的反方向。力反馈是方向盘体验的关键。基本原理是把轮胎的侧向力、路面颠簸、转向极限反馈成方向盘的扭矩。做原型时可以先用最简单的模型侧向加速度越大回正扭矩越大接近抓地力极限时叠加高频抖动提示。真要做细就要把前轮两个轮胎的受力分别算出来再通过 FFBeffect 合成。手柄没有力反馈但有震动。震动可以用来提示轮胎打滑和路肩强度不能太大否则连续弯里会一直震玩家很快就关掉了。还有一个实操建议输入映射一定要做成可配置项不要在代码里写死。不同玩家的设备、习惯、死区偏好差异很大一个硬编码的映射表会让测试反馈变得毫无意义。8. 帧率、录制与性能观察第三人称驾驶视角对帧率的要求比第一人称更高因为相机在持续移动画面里几乎没有静止参照物。帧率不稳时玩家感知到的不是“卡”而是“车不受控”。性能观察要盯几个点。第一是 CPU 主线程耗时车辆物理和输入处理都在这里如果物理步长和渲染帧率不一致会出现手感抖动。第二是 GPU 耗时主要集中在远景地形和车辆反射。第三是相机相关的射线检测如果每帧做了大量 SphereCastCPU 开销会突然上去。用 OBS 录制时建议把游戏帧率和录制帧率解耦。游戏锁 60录制 60输出用硬件编码能避免录制线程抢占资源导致的掉帧。如果要做慢动作分析可以单独录一版 120 帧的素材事后降速观察漂移过程中的车身姿态变化。性能排查的通用顺序是先看帧率曲线确认是持续低还是间歇掉持续低就降分辨率或减远景细节间歇掉就查垃圾回收、资源加载和射线检测。第三人称相机如果每帧都做地面检测和防穿模射线很容易在复杂地形上出现尖峰。还有一个小技巧把相机的 LateUpdate 和物理更新分开看。物理在 FixedUpdate 里跑相机在 LateUpdate 里跑两者频率不一致时会出现“车在动但镜头跟得慢半拍”的观感。解决办法是在相机里做插值补偿或者把物理步长调到和渲染帧率匹配。9. 自动化跑圈与遥测数据采集这个场景不是服务端项目没有 HTTP 接口也没有任务队列。但“批量”这件事在本地依然有意义同一辆车、同一条赛道、不同参数组合跑几十圈采集遥测数据用来对比调参效果。下面是一个采集脚本的框架读取你自己程序输出的遥测日志做批量统计import csv import glob import os import statistics LOG_DIR ./telemetry OUT_CSV ./summary.csv def load_run(path): rows [] with open(path, newline, encodingutf-8) as f: reader csv.DictReader(f) for row in reader: rows.append({ t: float(row[time]), speed: float(row[speed_kmh]), steer: float(row[steer]), yaw_rate: float(row[yaw_rate]), slip_rear: float(row[slip_angle_rear_deg]), }) return rows def summarize(rows): if not rows: return {} speeds [r[speed] for r in rows] slips [abs(r[slip_rear]) for r in rows] return { frames: len(rows), duration: round(rows[-1][t] - rows[0][t], 3), speed_max: round(max(speeds), 2), speed_avg: round(statistics.mean(speeds), 2), slip_avg: round(statistics.mean(slips), 2), slip_p95: round(sorted(slips)[int(len(slips) * 0.95)], 2), } def main(): files sorted(glob.glob(os.path.join(LOG_DIR, *.csv))) if not files: raise SystemExit(未找到遥测日志) results [] for path in files: rows load_run(path) item summarize(rows) item[file] os.path.basename(path) results.append(item) keys [file, frames, duration, speed_max, speed_avg, slip_avg, slip_p95] with open(OUT_CSV, w, newline, encodingutf-8) as f: writer csv.DictWriter(f, fieldnameskeys) writer.writeheader() writer.writerows(results) for r in results: print(r) if __name__ __main__: main()这个脚本的价值在于把“手感”变成可比较的数字。跑同一段山路改一次后轮抓地系数对比slip_p95和speed_avg的变化就能知道这组参数是让车更容易漂还是更难控。靠肉眼一遍遍跑效率太低。批量跑圈要注意两点。一是每次运行要用独立的日志文件文件名带上参数标识否则事后分不清哪份数据对应哪组配置。二是要固定随机因素比如起步位置、天气、轮胎温度初始值否则数据之间没有可比性。遥测字段的选择也有讲究。除了速度、转向、横摆角速度建议至少记录四个车轮的滑移率和垂直载荷。垂直载荷的变化能直接反映重心转移是调悬挂和重心高度的关键依据。这些数据在第三人称画面上完全看不到但对参数调校的价值远大于画面本身。10. 常见问题与排查方法第三人称驾驶原型的问题相对集中整理成表格方便对照。问题现象可能原因排查方式解决方案画面抖动或镜头一顿一顿帧率不稳或相机阻尼用了乘 dt 的写法打开帧率统计检查 LateUpdate 逻辑改用 1-exp(-k*dt) 阻尼锁帧或开垂直同步过弯时相机穿进山体缺少防穿模检测在复杂弯道开启 SphereCast 调试可视化加球体射线并做距离回缩高速时画面产生强烈透视畸变FOV 扩张幅度过大对比不同 FOV 下的弯道观感把 FOV 变化控制在十几度以内车辆一打方向就失控高速段转向角度未收窄打印转向输入和横摆角速度曲线引入速度敏感转向曲线漂移起不来前后轮抓地力差值不足或峰值侧滑角太小查看后轮滑移率和侧向力曲线降低后轮抓地系数调大峰值侧滑角漂移起来后救不回来抓地力衰减过快输入滤波过重检查 falloffRate 和输入低通系数减缓衰减速度降低滤波强度手柄油门没有反应轴映射错误或扳机轴方向相反逐轴打印原始数值修正轴索引和映射方向方向盘回正力矩异常力反馈合成参数错误断开力反馈逐项测试按侧向加速度线性映射回正扭矩录制视频掉帧编码线程抢占 CPU 或磁盘写入慢观察录制时的帧率曲线改用硬件编码输出到高速磁盘遥测数据无法对比随机因素未固定或文件命名混乱检查日志文件名和初始条件固定起步状态文件名带上参数标识远景地形出现明显锯齿分辨率缩放或抗锯齿等级过低对比不同抗锯齿设置提高渲染分辨率或改用时间性抗锯齿排查这类问题有一个通用原则先分离变量再定位模块。手感不对先确认是输入层、物理层还是相机层的问题做法是逐层关闭。把相机换成固定机位如果手感正常问题就在相机如果仍然不对再往下查物理和输入。这个思路比凭感觉瞎调参数高效得多。还有一个容易被忽略的点是引擎的物理步长。默认步长在高速场景下会导致轮胎模型计算不连续表现为车辆在高速弯里轻微抽搐。把步长调小能缓解但会增加 CPU 开销需要在稳定性和性能之间找平衡点。11. 最佳实践与工程建议第一先做最小可运行版本。一辆方块车、一段简单坡道、一个第三人称相机能在十分钟内跑起来再逐步替换模型和赛道。很多原型死在“一上来就想做完整赛道”的阶段。第二把相机、物理、输入拆成三个独立模块各自有独立的调试开关。调相机时冻结物理调物理时固定相机这样才不会互相干扰判断。第三参数配置外置。车辆参数、相机参数、输入映射全部用配置文件支持运行时热重载。这是提升调参效率最直接的手段没有之一。第四建立基准测试场景。固定一段赛道、固定初始速度、固定操作序列每次改完参数跑一遍记录圈速和遥测指标。没有基准调参就是玄学。第五录制和分析分开。录制用干净的画面分析用带 HUD 和遥测覆盖的版本。两者需求不同混在一起会拖慢排查速度。第六注意素材和内容的合规。车辆模型、品牌标识、赛道数据、背景音乐都要确认授权状态。自制原型早期用占位资源等确定了再替换能省掉大量返工。第七接口和自动化要留口子。即使当前是单机原型也建议把遥测输出、参数加载做成标准化格式。后面想做批量对比、自动调参、录像回放这些口子会省很多事。第八不要把街机手感和模拟手感混为一谈。两者服务的目标不同参数体系也不同。想清楚自己要哪一种再决定往哪个方向调否则会得到一个两头不讨好的中间态。12. 收尾这个场景真正值得研究的地方椿线下山、AE86、第三人称追尾这三个元素组合出来的画面之所以耐看不是因为某个单点技术多复杂而是因为相机、物理、输入三层咬合得紧。相机把车辆状态翻译成可读的画面物理给出符合直觉的反馈输入层保证玩家的操作能准确传达。任何一层出问题整体观感就会垮。如果只挑一件事先做建议先把第三人称相机调顺。它是玩家接触最直接的一层也是最容易做出明显提升的一层。相机稳了哪怕车辆物理还很粗糙整体观感也能立住。反过来物理调得再好镜头一直飘玩家也感受不到。最容易踩的坑有三个阻尼写成乘 dt 导致掉帧时手感变形、高速段转向不收窄导致车辆瞬间失控、防穿模缺失导致相机钻进山体。这三个问题在自制原型里出现频率极高提前规避能省掉大量调试时间。往后可以扩展的方向不少。相机层面可以做多机位切换、回放系统的轨迹重放、漂移时的动态构图。物理层面可以接入更完整的轮胎模型、悬挂几何、空气动力学。工程层面可以把遥测、参数、场景做成一套可复用的调参流水线。这些扩展都不依赖任何第三方游戏资源全部可以基于开源引擎自己搭。最后再强调一次边界街机原版的程序和资源有明确版权归属研究这套视角和手感不等于可以随意复制分发。自己搭原型、自己调参数、自己录自己的画面这条路走得通也走得稳。
