个人3D项目写进简历，先回答“我到底做了什么”

消息提到，有开发者表示决定用 Muse Spark 1.3 xhigh 在 Three.js 中压测 3D 游戏逻辑，并称构建了包含不同时段和车辆物理的浏览器驾驶演示，还给出了可试玩链接。这条动态对准备投前端或图形方向的读者来说，价值不在工具本身，而在于它暴露了一个常见问题：简历上写“用 Three.js 做了驾驶演示”，招聘方看不出你的贡献。素材没有说明作者的具体分工、投入时长，也没有性能、帧率或兼容性数据，所以不能照搬它的成果，只能借用表达思路。

把“用了什么”换成“解决了什么”，是第一步。写法上可以做对比：一种写“使用 Three.js 实现 3D 驾驶场景”；另一种写“为了让不同时段切换时操作不中断，我如何组织场景更新，并用哪些操作路径验证”。注意，后一句只是假设示例，不对应素材中那个演示的实际实现；素材只说了演示包含不同时段和车辆物理。真正要你做的是，从自己的项目里找出一个具体决策，用“问题—取舍—验证”重新组织。用 [实际记录] 占位，提醒自己补上真实测试数据，而不是编造帧率或用户量。 延伸阅读：Web前端开发工程师简历范例、模板和制作技巧

面试被追问项目细节时，怎么讲清技术取舍

面试准备的重点不是背功能列表，而是能说清你怎么做决定。可以提前准备三类回答：为什么这样选、遇到什么限制、怎么验证。素材提到作者称结果超出预期，但没有给出任何可核查指标，所以你不能替它下结论。你可以讲自己的项目：假设场景是你需要实现白天和夜间切换，一种做法是切换时重建整个场景，实现快但可能卡顿；另一种是复用已有对象、只更新光照和材质参数，改动多但切换更平滑。你要能说清当时选了哪种、为什么、代价是什么。车辆物理同理：自己写简化运动逻辑，还是引入现成物理库，各自对调试难度和可控性有什么影响。

验证环节最容易被忽略。可以准备这些核查点：在哪些浏览器上试过；低端设备上表现如何；用什么操作路径复现问题；帧率下降时先排查哪一层。这些只是面试准备的追问方向，不是断言面试官一定会问。素材中的试玩链接说明项目至少处于可演示状态，但可演示不等于可讲清，更不等于跨浏览器兼容。如果简历里写“完整演示”，至少自己要能解释哪些功能完整、哪些还是占位。

项目还没打磨完，要不要写进简历

可以用三条标准判断：可演示、可讲清、可核查。作者给出试玩链接，说明至少可演示；但素材没有说明它是否正式发布、是否经过多端测试，这些都要在简历里谨慎表述。可演示不等于可讲清，更不等于经得起追问。

如果项目还在早期，只写你实际完成的部分。面试前想清楚：如果对方要求现场打开演示，你能解释当前哪些功能是完整的、哪些还是占位。不要写“提升了渲染性能”却没有测量方式，改成“在[设备/浏览器]上，用[操作路径]观察[具体现象]，用[实际记录]记录”。

一个实际可做的小建议：挑项目里一个具体决策，用三句话写下来——当时的问题、你选的方案、你怎么确认它有效。写不顺的地方，就是面试前需要补的功课。