游戏客户端的简历,项目描述写得再细,也顶不过让人看一眼画面。所以作品集链接基本是必放的。 问题在于放上去之后到底发生了什么,大多数人没验证过。
导出一份 PDF,把有链接的那一行复制到记事本里。如果粘出来是「作品集」三个字,或者是一串断成 两截的地址,那这个链接对机器等于不存在。对方要是靠系统自动抓候选人链接,抓不到;要是自己 动手复制,复制出来打不开。
三个位置,各有各的代价
放法就三种:头部联系信息那一行、每段项目经历的末尾、单独开一个「作品集」章节。

头部那一行。 好处是唯一入口,HR 找联系方式时顺手就看到。代价有两层。一是版面,头部本来 就要塞电话、邮箱、城市,再加一条地址容易折行,折完整个对齐关系都得重调。二是这一行在读者 眼里性质是「联系方式」,链接混进去容易被当成又一个联系方式跳过去。只有一个总入口的人适合 放这里。
顺带说一个坑。不少模板的头部信息行是纯文本渲染的,看着像链接,其实点不动。不繁简历的模板 也是这样:头部的网址字段是文本,真正带超链接的是「作品集」章节。这个区别下一节展开。
项目经历末尾。 就近原则,读到哪个项目点哪个,匹配关系最清楚。代价是重复:五段项目挂五个 同域名的链接,版面上是五行噪音,读者也不知道该点哪个。适合项目之间差异大、每个都有独立可看 产出的情况。
独立的作品集章节。 这一节要占掉整整一块版面,所以只有在作品本身就是主要证据时才划算, 比如美术、技术美术、独立开发者。投引擎、性能、框架方向的人我不建议开这一节:被它挤掉的通常 是工作经历,而那些岗位想知道的是你怎么把帧率打上去,不是你的场景好不好看。
可点和可复制是两件事
PDF 里「能点」和「能复制」由两套东西负责,互相独立。
能点靠的是链接注解。PDF 在页面上圈一块矩形区域,记一个目标地址,阅读器在这块区域上显示手型 光标。这块区域下面印着什么字,和它跳到哪里,没有必然关系。
能复制靠的是文本层,也就是这一页有哪些字符、按什么顺序排。你复制、按 Ctrl+F、或者让程序读取 内容,拿到的都是这一层。
于是常见的坏法有这么几种:
- 蓝色的「作品集」三个字。点得动,复制出来是「作品集」。地址只活在注解里,机器读简历时 拿不到。
- 地址完整印着,但没挂注解。复制得出来,点不动。这种其实还能用,只是多一步。
- 二维码。既不在文本层,也不是注解,就是一张图。机器完全读不到,人还得掏手机。
要两条通道都通,做法只有一个:让完整地址以明文出现在正文里,同时给它挂上超链接,锚文本 就用地址本身。 写成「作品集」「点这里」「我的 GitHub」,一定会丢掉一条通道。
不繁简历作品集章节的两种样式,差别正在这里。列表样式把完整地址作为可见文本印出来,旁边配一 个小二维码;网格样式在你填了作品名称时只显示名称和二维码,地址不进文本层。想让机器读到地址, 选列表。
还有一个和中文简历有关的坑。地址太长在 PDF 里折了行,复制出来可能断成两截,中间多出空格或者 换行,粘到浏览器地址栏里打不开。中文简历的文本层还有一类更隐蔽的坏法,人眼完全看不出来, 我们单独写过一篇。自查方法是同一个:导出之后复制,粘到 记事本,看是不是完整的一行。
链接本身也要短。github.com/yourname/project-name 比后面拖着一串 ?utm_source= 参数的分享
链接更不容易折行,也更不像广告。
一个链接还是一组链接
按你手里能拿出来的东西分。
只有一到两个能看的作品:一个链接,放头部或者放在对应项目的末尾。不要为两个作品单开一节。
三个以上而且质量不齐:一个总入口,指向你自己做的落地页,页面上按你想让人看的顺序排。 这个顺序你控制得了,平台的默认排序控制不了。
作品分属不同性质,比如一个上架小游戏加一个开源工具:这种反而不该合并。开源工具挂在对应 的项目经历下面就行,合并成一个总入口只会让人在不相干的东西里找他关心的那个。
判断标准就一条:点进去之后,对方还要不要再做一次选择?要,说明入口开多了,或者落地页没组织好。
落地页该放什么
按「对方只看第一屏」来设计。这个假设我们没有数据支持,不同公司差别很大。但按它设计的页面, 对方愿意多看几屏也不吃亏;反过来赌对方有耐心,赌输了就没有第二次。
第一屏要回答三件事:这是什么类型的东西、你做了哪部分、能不能马上看到画面。
第三件在游戏岗位上是硬指标。能直接看到画面的形式,我的排序是:
- 能直接播的短视频或 GIF。 最保险,不挑设备,不用等加载。一分钟的剪辑够了,前五秒就要 出玩法画面,别放 Logo 动画。
- 浏览器里能跑的 WebGL 构建。 体验最好,但要标一句「建议电脑打开」,手机上大概率跑不动, 或者操作根本没法用。
- 上架页面(TapTap、App Store、Steam)。可信度最高,它证明这东西真上线了。缺点是页面上 讲的是产品,不是你。
安装包下载排在最后,我的建议是干脆别放。让对方为了看你的简历装一个 APK,这个要求太大了。
网盘链接和个人博客首页同理。凡是点进去还要再操作一次的,都算多加了一道门槛。
每个作品下面配两三行字:项目类型、周期、团队规模、你负责的模块、用了什么方案。别把简历上的 句子原样搬过来,这里是它的展开版。简历上写了「对象池复用降低 GC」,落地页上就该有前后两张 Profiler 截图。可以对着站内的 U3D 开发工程师简历范例看, 它每条项目描述都带具体手段和结果,落地页要做的就是把这些手段摊开给人看。
商业项目受 NDA 限制时怎么展示
商业项目不能展示是常态,外包和大厂项目尤其如此。但限制分好几层,别混在一起处理。
已经公开发行的产品。 产品本身不是秘密。放它的官方上架页,写清你负责的模块;不能放的是 内部数据、未公开的玩法、还没上线的版本。这一条最容易自我审查过头:一个在 TapTap 上有大量 公开评论的游戏,你说你做过它的角色系统,不构成泄密。
没上线或者已下线的项目。 不放链接,在项目描述里写品类和你的技术方案。「某 SLG 手游」比 写公司名安全,信息量也够用。至于流水、DAU 这类不能写绝对值的数字,可以换成相对值或区间, 业绩数据涉密时的三种量化写法那篇讲得更细。
内部工具和引擎改造。 这类东西通常没有对外形态。可行的替代是用业余时间重写一个最小版本, 代码是你自己写的,可以公开。这比在简历上描述一个谁也验证不了的内部系统有说服力。
有一类地址无论如何都不能出现:公司内网 Wiki、Confluence、内部 Git 仓库。对方点不开,还会 让人怀疑你的保密意识,两头亏。
如果确实什么都放不了,就在项目末尾写一行「受保密协议限制,方案细节可面谈」。这句话本身是加分 的,它说明你知道边界在哪。空着不解释,对方只会以为你没做出东西。
技术栈怎么写才不像标签云
游戏客户端的技能栏最容易变成一片名词:Unity、C#、Shader、Lua、热更新、UGUI、DOTween、 Addressables、Profiler……二十个词铺开,信息量接近零,因为每个词都可以只是「听说过」。
两个改法。
给词加限定。 站内那份 U3D 范例的技能栏里有一条是「性能优化(Profiler / DrawCall / 对象池)」,而不是光写「性能优化」。括号里那三个词说明你具体动过什么,是能被追问、也经得起 追问的写法。「Shader」可以写成「Shader(URP 自定义 Lit / 溶解与描边)」。括号里填不出东西的 词,那个词就该删掉。
让每个技能在项目经历里至少出现一次。 技能栏是索引,项目经历是正文。索引里有、正文里查不到 的词,面试官会挑出来问,而那通常正是你最不想被问的。反过来,项目里反复出现的东西,技能栏里 写一次就够。
分组两到三组足够:引擎与语言、图形与性能、工程化与平台。分到六组,就变成了另一种形式的标签云。
设计和美术岗同理。视觉设计师的简历范例里技能栏是按能力 分的(品牌全案、Design System、动效),工具名 Photoshop / Illustrator / Figma 挤成一条放在 最后。会用工具是入场条件,把它排在能力前面等于主动降级。
导出一份 PDF,做三件事:把链接那一行复制到记事本,看是不是完整地址;在阅读器里点一下,看跳不 跳;用手机打开那个地址,看落地页第一屏有没有画面。三件都过,链接这部分就不用再操心了。