企业官网建设流程全解析

1. 内容整体设计与思路拆解

1.1 技术美术在游戏研发里的真实定位

技术美术，英文叫 Technical Artist，行业内一般简称 TA。这个岗位在游戏公司里一直有点“两边都要沾”的味道：既不是纯程序，也不是纯美术，但又必须能跟两边顺畅沟通、解决问题。很多校招同学对 TA 的理解停留在“会写 Shader 的美术”或者“懂点美术的程序”，这个理解太片面了。实际上，2019 年前后的国内游戏行业，尤其是搜狐畅游这类既有端游积累又在大力布局手游的厂商，对 TA 的要求已经非常具体和务实。

我当时看到畅游的 TA 笔试题，第一感觉是：这公司是真的在招干活的人，不是在招理论家。整套题目覆盖了渲染基础、数学功底、引擎使用、性能优化、美术流程规范等几个大方向。表面上看是考知识点，实际上是在筛选一种思维方式：你能不能把一个模糊的视觉需求，拆解成具体的技术方案，并且落地到引擎里、跑到真机上、达到性能预算内。

从岗位分工来细分，TA 大致可以分成三类。第一类是渲染向 TA，主要工作是啃 Shader、写材质、调光影、做特效表现，这是大多数人印象里的 TA。第二类是流程向 TA，主要工作是做 DCC 工具链、写批量处理脚本、搭自动化管线、解决美术生产流程里的效率问题。第三类是性能向 TA，主要工作是做游戏性能分析、资源规范制定、Draw Call 优化、内存管理。畅游的笔试题里这三类都有涉及，说明他们期待的是一个“一专多能”的通用型 TA，至少校招阶段不会让你只干某一类活。

1.2 搜狐畅游这类大型 MMO 厂商对 TA 的期待

为什么要单独聊畅游这个厂商？因为不同公司对 TA 的期待真的不一样。做单机买断制游戏的公司，TA 可能更偏重画面表现和新技术落地；做超休闲游戏的公司，TA 的存在感很低；而畅游这种以《天龙八部》系列为代表、同屏人数多、场景复杂度高的 MMO 厂商，TA 的核心价值就一个字：稳。

MMO 游戏的同屏人数经常上百人，技能特效满天飞，场景里各种植被、建筑、水体、天气系统叠加在一起。你去用一两个炫技的 Shader 把单个角色做得特别漂亮，这个不难；难的是让 50 个角色同屏放技能时帧率不掉、内存不爆、发热不严重。所以畅游这类厂商出笔试题目时，特别爱考优化相关的内容。比如材质实例、合批机制、纹理格式、LOD 策略这些东西，都是在真实项目里每天都要面对的问题。

另外一点，2019 年这个时间节点很关键。那时候国内手游市场已经从“换皮就能赚钱”进入“拼品质”的阶段，Unity 是绝大多数团队的主力引擎。畅游在端游时代积累了大量自研引擎技术，但手游端也需要大量能快速上手 Unity 优化和渲染的人。校招 TA 进去之后，不会有太长的培养期，第一年就要能跟着项目跑。笔试题目考得基础、考得实，背后就是这个逻辑：我们不需要你有多惊艳的作品集，但你的图形学底子必须扎实，工具链上手必须快，出了问题你得知道去哪里查、怎么查。

2. 图形学与渲染核心考点拆解

2.1 渲染管线与光照模型的选择逻辑

畅游的笔试题里，渲染管线相关的内容几乎每年都出现。这属于 TA 的“基本功中的基本功”。最常见的考法有两种：一种是直接让你对比前向渲染和延迟渲染的优缺点，另一种是给一个具体的场景需求，问你选哪种渲染路径更合适。

前向渲染和延迟渲染的区别，用大白话讲就是：前向渲染是“每个物体都算一遍光照”，延迟渲染是“先把所有物体的几何信息存下来，再统一算光照”。前向渲染的优点是抗锯齿好做、带宽占用低、对移动端友好；缺点是光源数量一多，Draw Call 和计算量就成倍涨。延迟渲染的优点是支持大量动态光源，光源越多优势越明显；缺点是内存和带宽开销大，MSAA 很难做，对移动端的 GPU 压力很大。

当年很多同学能背出这两者的定义，但一到具体场景取舍就懵了。比如题目问：一个室外大世界、上百个动态光源、主要目标平台是高端手机，你怎么选？这时候正确答案不是“无脑选延迟”，也不是“移动端必须前向”。而是要先分析需求：上百个动态光源是不是真实需求？室外大世界能不能通过光照贴图和 Light Probe 把大部分光源烘焙掉？动态光源如果真需要，是哪种类型的动态光源，平行光还是点光源？想清楚这些再选方案，才有意义。这种分析问题的思路，比记住“前向 vs 延迟”的优劣势清单重要得多。

光照模型也是高频考点。Lambert、Half-Lambert、Blinn-Phong、Cook-Torrance 这四个是必须烂熟于心的。笔试里比较常见的考法是拿一个半透明角色受光效果异常的问题，让你分析原因。这时候很多人会想到调 PBR 参数，但真正的原因是：角色 Shader 用了半透明混合，而半透明物体在 Unity 里默认是不写深度的，导致光照计算时的法线方向或深度信息出现异常。半透和深度、光照之间的复杂关系，才是实际开发中真正会遇到的坑。

2.2 Shader 题里的隐藏陷阱：法线贴图与各种空间

Shader 相关的题，畅游出得很有水平，不是让你背语法，而是考你对“空间”和“变换”的理解深度。一个经典的题目是：为什么法线贴图大多是蓝色的？这题看似简单，其实能分三层回答。第一层：法线贴图里存的是切线空间下的法线方向，xyz 被映射到 rgb，而大多数法线方向是朝 z 轴正方向的，所以 b 通道值最大，看起来偏蓝。第二层：如果是世界空间法线贴图，颜色就不是单一蓝色调了，因为世界空间下各方向的法线都有可能出现。第三层：可以进一步聊为什么要在切线空间存法线。因为模型在动画过程中会发生形变，顶点会动、会转，如果法线存的是世界空间或模型空间，动画一变法线就错了。而切线空间是跟着顶点走的，动画怎么动，切线坐标系的基向量也跟着动，从切线空间变换到世界空间的矩阵可以在 shader 里实时算出来，法线方向就不会错。

这里面还藏着一个特别容易出错的点：法线贴图里法线方向与模型原始法线方向的关系。美术制作时，法线贴图通常存的是“相对于模型原始法线方向的偏移量”，或者说是“细节法线与低模法线之间的差异”。如果你直接把一张高模烘焙的法线贴图贴到低模上，却不做任何处理，在某些引擎里会因为坐标系轴向不一致导致光照方向看起来是反的。尤其是 OpenGL 和 DirectX 的 V 轴方向不一致的问题，不知道坑了多少新手 TA。这不是理论问题，是进项目第一个月就可能踩到的真坑。

2.3 数学题不会直接考你矩阵乘法，但会考你“知不知道为什么要做矩阵乘法”

数学功底在 TA 笔试里占比不低，但考查方式通常比较含蓄。很少让你纯粹算一个四阶矩阵的乘法结果，更多是让你“用人话解释一件事”。比如：“顶点从模型空间到屏幕空间，经历了哪些坐标变换？每一步在做什么？”这个问题的标准答案大家都知道：模型空间到世界空间用模型矩阵，世界空间到观察空间用视图矩阵，观察空间到裁剪空间用投影矩阵，最后做透视除法变成 NDC 坐标，再到屏幕空间。

但笔试如果只考到这一步，那还只是初中生水平。真正拉开差距的是：你能不能解释清楚“为什么需要这些变换”以及“这些矩阵为什么是四维的”。比如，平移变换不是线性变换，在三维空间里没法用 3x3 矩阵表示，所以要把坐标扩展到齐次空间，用四维矩阵，把平移塞到第四列。再比如，法线不能直接用模型矩阵变换，因为非等比缩放会破坏法线的垂直关系，必须用逆转置矩阵。这些细节才是 TA 和普通程序员的区别所在。

向量运算的考点也很实在。点积最常用的场景是判断方向关系：两个向量方向一致时点积为正，垂直时为零，相反时为负。半兰伯特光照就是把 N dot L 的范围从 [-1,1] 映射到 [0,1]，本质就是用点积做了个方向性判断。叉积在 TA 日常里更偏几何计算：算两个向量的垂直向量、算平面法线、处理三角形面朝向、甚至是做 procedural mesh 时的顶点顺序判断。笔试题如果让你判断一个三角形顶点顺序是不是顺时针，本质就是在考叉积的 z 值方向。

3. 引擎工具链与流程自动化

3.1 DCC 工具批处理：笔试里最容易被忽略的送分题

很多准备 TA 笔试的同学，把所有精力都花在看渲染管线、背 Shader 代码上，结果看到题目里出现可能涉及 Maya/Max 的批处理或工具链应用时，就开始皱眉头。实际上，畅游这类流程成熟的厂商很看重工具能力。美术团队每天要处理大量资源导入导出的活，模型改名规则、贴图格式转换、单位比例统一、轴翻转修正，这些重复劳动如果靠人工一个一个点，不仅效率低，而且一定会出错。所以 TA 的日常工作之一，就是做批处理工具把这些流程自动化。

笔试考这类问题通常不会考具体某个 DCC 的 API 细节，毕竟校招生不一定都用过同款软件。更多是考思路。比如给一个场景：项目规定所有模型文件必须用“资源名_LOD0”的命名规则，但外包交付的 200 个文件全是乱的，有叫“123.max”的、有叫“新建文件夹.max”的，你怎么快速处理？这题其实是考你有没有“用脚本批量操作”的意识。在 3ds Max 里写一段简单的 MaxScript 遍历文件、解析名字、重命名、重新导出，可能就几十行代码的事。在 Maya 里用 Python 加 pymel 也一样能做到。笔试不会让你现场写完整脚本，但会看你的解决方案里有没有“遍历目录”“正则匹配”“批量重命名”“规范化输出”这几个关键步骤。

再往前深一步，实际项目中模型资源不止要改名字。单位不对要缩放，轴方向不对要旋转，材质球名和贴图名不匹配要重连，控制器和动画层要清理干净。这些在笔试里不会一个一个考，但出题人会通过一个综合场景考察你有没有“资源处理全流程”的概念。当年我做这些工具的时候踩过一个坑：批量处理工具跑完之后，原始文件也被覆盖了，想回退都退不了。后来学乖了，所有批处理强制先做备份目录，处理完成后再做一次文件比对，输出日志。这种“防御式编程”的思维，在真实项目里比炫技重要得多，笔试如果能在答案里提到这层，会是一个很加分的细节。

3.2 移动端与多平台打包：工具链能力从 DCC 延伸到引擎

引擎相关的工具链能力，同样会是笔试关注的环节。Unity 和 Unreal 项目里，TA 干的最多的事情之一是维护“资源导入规范”。比如贴图导入之后，默认的压缩格式对不对？纹理的 Generate Mip Maps 选项有没有一致地打开？Model 文件导入时的 Scale Factor 是否会统一为 1？这些选项如果靠美术自己在导入面板里一个一个设，很容易出现两个模型同样的建模尺寸，进引擎后一个正常一个变大一百倍的问题。

解决这类问题的标准做法是用引擎的 AssetPostprocessor 这类导入后处理接口做自动检查：在资源导入后自动读取配置表，把贴图格式、压缩类型、尺寸上限、Read/Write 开关全部按照规范批量设定，不规范的直接打日志警告。Unreal 里的 Asset Action Utility 插件也实现过类似的批量处理。笔试可能会通过“如何保证几百个美术资源在导入后自动符合项目规范”这种题目，考察你是否具备这个层级的工具链意识。

3.3 材质实例与材质管理：流程问题最终会暴露在项目里

材质管理是另外一类很常见的工具链题目，而且经常和渲染、性能混在一起考。Unity 里的 Material 如果每个角色都单独建一个材质球，一个场景几十个角色，那材质球数量会变得非常臃肿。用 Material Property Block 或 Material Instance 来管理差异化的参数，是 TA 必须掌握的方案。

同一个角色的不同外观变体，用材质实例去改 Color、贴图、金属度、粗糙度，而主材质球始终保持唯一。这样既能保证表现，又能减少材质球数量，还能在合批时保留更多可能性。畅游笔试如果考到这个点，通常还会连带问一句：这几种方式的 GPU 开销有没有区别？这就是在考你“引擎封装之下到底发生什么”的理解——材质实例和原材质在 GPU 上是不是同样的 Pass，有哪些情况会打破合批。

4. 性能优化与资源规范

4.1 Draw Call 是什么，以及它怎么决定游戏的帧率

性能优化是 TA 笔试题里分量最重的板块之一。如果是 MMO 厂商，这块占比会更大。而 Draw Call 又是性能优化里最基础也最核心的概念。

Draw Call 可以理解成 CPU 向 GPU 发一次“把某某物体画出来”的指令。每次指令都有固定开销，指令的数量越多，CPU 的负担就越重。在移动端，CPU 性能本来就有限，Draw Call 一多，直接就卡在 CPU 的提交环节上，GPU 反而在大部分时间处于等待状态。所以大量减少 Draw Call 数量，是手游项目里最迫切的需求之一。

笔试对这个点的考法通常是让你分析一个场景的性能瓶颈。比如：一个开放大世界场景，里面有 300 个建筑、2000 棵树、500 个 NPC，像素级的帧率上不去，你会从哪些方向入手？很多人的第一反应是“降低画质”，或者是“调 LOD”。这些思路没有错，但不够体系化。一份合格的答案应该从 CPU 和 GPU 两个角度拆开分析。CPU 侧主要看 Draw Call 数量、脚本逻辑开销、物理计算开销、粒子系统开销；GPU 侧看填充率、Overdraw、后处理效果、贴图带宽。先通过 Profiler 定位瓶颈在哪一端，再针对性地做优化，而不是一上来就无脑砍贴图。

4.2 合批的真相：为什么材质一致性能省这么多

合批是降低 Draw Call 最直接的手段，Unity 里分静态合批和动态合批，笔试经常考两者的区别和限制条件。静态合批是预先把场景里不会动的物体网格合并成一个大的网格，代价是内存占用增加，而且合并之后不能再单独做剔除。动态合批是运行时把符合条件的物体合并提交，限制条件很严格：顶点数不能太多、材质必须完全相同、不能有 Mirror 变换，而且不同平台的支持程度不一样。

这里有一个真实项目里很常见的坑，笔试如果考得细，会让你判断“两个物体能否动态合批”。比如一个物体用了 Material 实例，另一个用了共享材质，即使两个物体的 Mesh 一样，它们能合批吗？答案是：如果实例化后材质属性没有变化，可能能合；但哪怕只改了一个 Float 参数，Unity 也会认为材质不匹配，直接打断合批。再比如，两个物体使用了同一个纹理图集的不同图集区域，但材质球是同一个，这属于可以合批的情况。因为 GPU 在采样纹理时只看纹理坐标在哪个区域，而纹理本身是同一张。这个知识点听起来简单，但实际项目里新 TA 经常在这个上面栽跟头。

4.3 跑在手机上的资源规范：贴图、模型、粒子的红线和底线

由于移动端的显存和带宽非常有限，贴图压缩格式的选择会直接影响项目的总体包体和运行时表现。笔试题目如果涉及移动端格式，往往会问：同样一张 1024x1024 的 RGBA32 贴图，在 iOS 和 Android 平台上分别应该用什么压缩格式？iOS 常见的选择是 ASTC（硬件支持情况下），Android 则是 ASTC 或者 ETC2，具体还要看目标 GPU 是否支持。如果用了不支持 ETC2 的旧设备，就要在导入设置里做兼容处理，或者提供降级方案，否则贴图会直接变成紫色或者显示异常。

Model 资源的规范也非常实在：单个角色面数上限、单棵树木面数上限、贴图规格不超过多少、粒子数量不要超过多少、粒子系统里是否允许使用实时灯光。这些数值可能因项目而异，但笔试真正的考察点，是候选人对“为什么要有这些限制”有没有清醒的认识。比如粒子系统数量限制，是为了避免填充率爆炸或者 CPU 粒子更新开销过大。如果答案只是“这是公司规定”，那说明还没有真正理解规定的目的。

4.4 资源监控与自动化质检：从“靠人盯”到“靠脚本盯”

资源规范制定出来之后，最难的不是写文档，而是执行。美术团队那么多人，不可能靠口头说、靠人工逐项检查。所以 TA 要写一套自动化检测工具，每天晚上定时跑一遍资源库，把所有超出规范的红线问题统计出来，生成日报推送给相关责任人。

工具从粒度上可以分成两层，第一层是资源本身有没有超标，比如贴图尺寸超了没有、面数超了没有、动画压缩方式对不对、音频采样率是否统一；第二层是场景级别的检查，比如场景里有没有动态阴影没有关闭的实时光源、Transparent 物体数量是否过多、每个相机是否正确配置。笔试题如果问到“你会怎么设计一套资源检查工具”，这就是一个可以参考的框架。做这个框架的难点其实不是代码本身，而是如何把项目里的实际经验转化为可执行的检查规则。规则定得太粗等于没定，规则定得太细又会降低美术的产出自由度，这个平衡点只能是“从实战项目中长出来的”。

5. 常见问题与答题技巧实录

5.1 笔试踩坑实录：不是不会，而是答歪了

我自己参加过不少 TA 相关的笔试，也看过很多校招同学的答题卡。现在复盘下来，大部分丢分不是知识储备不够，而是答题方式出了偏差。

最典型的问题是“只给结论，不给过程”。题目问“为什么法线贴图大多呈蓝色”，有的同学直接答“因为法线贴图存储的是法线方向，法线方向大多数朝上，所以 B 通道高”。这个答案不能算错，但很单薄，答案里没有提到切线空间，没有提到法线方向与 TBN 矩阵的关系，也没有展开为什么 B 通道能对应到 Z 轴。这样的答案在 HR 眼里会被判定为“背过结论，但理解不深”，评分自然上不去。正确的答题逻辑应该是：首先说明法线贴图里存储的是切线空间下的法线方向，其次说明为什么要用切线空间而不是模型空间或世界空间，最后再解释 rgb 到 xyz 通道映射，B 通道高所以颜色偏蓝。这样一层层剥开，才能表现出系统性思维和深度理解。

第二个常见问题是一些同学分不清回退方案和解决方案的边界。比如题目问“游戏场景中动态光源很多，帧率上不去，怎么优化”。有些同学会答“直接把动态光源改成烘焙光照贴图”，这确实是一种回退方案，但未必能解决“动态光源很多”这个实际需求。一个更好的思路是先分析哪些光源是可以烘焙的、哪些是必须有实时效果的，然后评估使用 Light Probe、Light Cookie 或者简化阴影配置等方式来控制开销。回退方案是解决问题最保险的手段，但不应该是第一选择。面试官真正想看的是候选人的取舍逻辑，而不是一个一刀切的结论。

5.2 备考时间分配与信息收集建议

如果你打算参加下一年的 TA 校招，笔试准备其实要从两个维度同时进行。第一是知识维度，图形学基础、数学基础、引擎原理、优化实战这四块必须系统过一遍。第二是信息维度，你投的每家公司的笔试风格差异非常大：有些公司喜欢考 Shader 代码题，有些公司喜欢考引擎使用细节，还有一类公司像畅游这样，更关注的是你做项目的整体思路和问题解决能力。

在知识维度上，如果是图形学入门，《Unity Shader 入门精要》是很多 TA 的启蒙书，我自己也反复翻过很多遍。但光看书不够，一定要自己动手写 Shader、自己搭测试场景、用 Profiler 跑一跑实际数据。很多同学以为理论掌握了就等于会了，其实笔试里有一个很常见的操作题：给你一段 Shader 代码，让你指出其中的性能问题。如果你自己没有实际写过 Shader，很难一眼看出问题是出在循环次数、动态分支还是贴图采样次数上。

信息维度上，笔试之前可以去搜下该厂商近两年的试题方向，虽然每年的题目不会完全一样，但出题风格通常会保持稳定。搜题不是为了押题，而是为了了解这家公司侧重考察你的哪些能力。有些公司很重视美术感觉，会给你一些效果截图让你分析可能用到的技术；有些公司很重视工具能力，会问你如何优化某种重复劳动；有些公司（比如当时的畅游这类大厂）很重视性能和规范，因为他们的项目体量大、上线的产品多，TA 要在一个复杂的环境中保证稳定。

5.3 笔试之后的面试追问：同一个问题，不可能只有一个标准答案

笔试只是第一步，通常通过笔试之后还有技术面试。面试里很大的概率会追问笔试中出现过的一些问题，而且问得更深。比如笔试里你答了“降低 Draw Call 可以使用合批”，面试官可能接着问你：如果某个物体使用了带透明通道的材质，还能参与动态合批吗？如果把场景里的地面拆成多个小块分别做碰撞体，合批之后碰撞计算会不会变成性能瓶颈？这些追问就是为了验证你是真的理解，还是只背了套路。

准备面试和笔试不太一样。面试更需要你用项目经验来支撑回答。如果面试官问“你如何优化一个场景的 Draw Call”，你最好举一个真实的例子：什么项目、什么规模、用什么工具分析、发现什么问题、做了什么决策、最终帧率提升了多少。即使你的项目经验不是游戏，而是图形学课程作业、开源项目、或者用 Unity 搭的一个小 DEMO，都可以用同样的逻辑去讲。重点不是项目的规模，而是你有没有一套从发现问题、分析问题、试验方案到验证结果的方法论。

我在辅导新人时最喜欢说的一句话是：技术美术面试里，大多数问题都没有唯一标准答案，面试官想听到的是你的思路、你的取舍、你踩过的坑，而不是一个标准答案。如果你只会背知识点，遇到面试官深挖一下就露馅了；如果你有一套完整的分析框架，哪怕一开始答偏了，面试官引导你一下，你也能立刻校正方向。

6. 笔试之外的长期积累建议

6.1 不要只看教程，要能复现和拆解

笔试考的是知识的宽度，而长期发展靠的是知识的深度和可迁移性。我当时的做法是，每学一个渲染技术，比如屏幕空间反射、体积光、视差贴图，边学边搭一个最小测试工程，把效果、参数、性能和常见问题记录成一篇笔记。笔记里会包含自己写的 Shader 代码、截图对比、Profiler 截图、参考链接，甚至包括“当时我觉得这个效果很酷，但后来发现项目里根本用不上”这类反思。这种复习回看的素材，在笔试和面试时远比临时抱佛脚来得有力。

拆解别人的作品也是一种高效学习方式。看一个效果图，先猜它可能是怎么做出来的，再用自己的知识去验证。比如一个角色脚下有柔和阴影，我可能会拆解成：投影用方向光，加 Blob Shadow 做兜底；或者用实时阴影加 Contact Shadow 增强接触感；又或者直接用一张烘焙好的软阴影贴图做假阴影。每一种方案都有自己的成本、效果和适用场景，把这些组合都吃透，才算是真正掌握了技术。

6.2 作品集里放什么更有说服力

很多校招 TA 会把作品集做成“会写多少种 Shader”的展示墙，上面放一堆各种风格的画面截图，这有一定作用，但公司更想看到你在一个完整场景里解决实际问题的过程。比如你做一个风格化场景，不只是展示最终渲染效果，还可以展示资源组织策略：哪些东西用动态合批、哪些用静态合批、为什么这个角色材质用了两个 Pass、场景里的灯光为什么这么配置。展现思考和迭代过程，比展示最终结果更有参考价值。面试官连问几句就能看出你有没有真正做完整项目，所以建议准备作品集时优先考虑完整性。

6.3 TA 是“越老越吃香”的岗位吗

最后聊聊职业预期。技术美术这个岗位，论写代码可能不如游戏客户端程序纯熟，论美术制作不如资深原画、模型师经验丰富，TA 真正的护城河在于“跨界”能力。图形学更新迭代很快，引擎版本不断升级，但解决问题的框架、与团队成员沟通的方法、对性能与画面平衡的判断力，这些能力是随着项目经验增长而不断加深的。

对校招同学而言，如果目标明确要入行 TA，不要只盯着笔试知识点本身，而是往上游想一步：这套知识体系长在哪些真实问题上，出了校门之后这些问题会以什么面貌出现。这也是我写了这么多关于笔试题的复盘和拆解之后最想表达的东西：技术会过时，工具会迭代，但底层的图形学原理、扎实的数学基础、严谨的工程习惯和清晰的沟通表达，会一直是 TA 的核心竞争力。