(已oc)文案策划暑期实习面经-网易互娱

tl:2月底投递简历,简历一小时通过3.7笔试-4.28一面-5.19二面-5.21.晚上八点oc+offer
基本来说面试只要通过了两天就有消息,但是约面的时间安排在了很后面,所以战线拉得很长。base杭州。
一面:
1.自我介绍(把自己的简历和面试官说了一遍)
2.看你拆解了燕云的剧情,你是怎么拆解的?
3.你在拆解的时候有什么新的感想吗?比如这个地方和你玩游戏的时候设想的不一样?
4.你觉得什么样的剧情是好的剧情?
5.你最喜欢燕云什么剧情?
6.那你用刚才你说的那个评价体系给你最喜欢的剧情打分。
7.那我们来看看你的作品集,你这个科幻小说讲的什么故事?
8.这个故事放在游戏里怎么持续的吸引玩家呢?(面试的时候感觉是面试官对我的故事不感兴趣,但是现在想想应该只是想考察我懂不懂游戏和故事的结合)
9.这个故事的外部危机是什么?
10.你的这么多作品里有什么鲜明的人设吗?
11.那这个人物的台词你怎么设计的?
12.你说这是个主动型进攻的女主角,那她怎么主动勾引男主,有具体的情节吗?
13.那你之前的故事里还有什么很好的情节吗?(怪我没有梳理作品集,很多情节都忘得一干二净了,我就随口编了一个,面试官听到我记不得了之后就又回到了我的第一个科幻小说作品)
14.你这个科幻小说,我如果要把这个主角放在二次元游戏里,你怎么给他做人物形象设计?(说的很普通)
15.面试官追问:那我现在需要让他角色更加鲜明,更有记忆点,你还能怎么给他设计外貌呢?
16.反问

一面的面试官姐姐真的很好很好,很温柔的。

二面+hr面:面试官迟到了一会儿,但是人也很好,算是体感上来说我经过的最好的leader面,但我实在太紧张了,口干舌燥。
1.自我介绍。
2.然后就是长达5分钟的脱离游戏文案的问答,一听到和文案没有关系我就开始肾上腺素飙升——以为面试官对我不感兴趣,其实她也只是单纯的问问而已。
3.你这个在学校里的拍片子的班是虚拟班还是长期班?
4.面试官喃喃自语:那你们一个月要写这么多的剧本,这个周期还挺紧张的(把我整紧张了)
5.然后不知道为什么我又提到自己在做AI短剧,面试官问我现在AI短剧的剧本是手搓还是AI写的。(我说手搓,并且批判了AI)
6.AI短剧和之前的真人短剧叙事上的区别?
7.你之前做的这个游戏之后还有吗?还是只有这一部?
8.然后开始挖我的作品集(玩家市场反馈and自己听到反馈后该如何修改)
9.聊燕云十六声剧情优缺点。
hr面。

互娱是我暑期实习的最后一个面试,再找不到游戏文案的工作我就要准备进入短剧编剧行业了,并且打算下半年考公,没想到啊峰回路转,柳暗花明又一村啊。
全部评论

相关推荐

在我来鹅之后,接到的第一个完整大需求就是需要编写一个skill,之前的实习也写过一些skill,但是在我的理解中skill就是跟提示词没差,把你需要的目标全写上就好了,所以第一次mr我提交了一个超过1200行的md,被mt打了回去,为了完成这个需求,我又赶紧请教了我身边的大神同学,获取一些写skill的经验,将原先1200行的md进行了对应的references拆封,又通过我朋友教我的验证机制验证这个skill的效果,最后完成了我的第一个需求。正好前两篇文章给大家分享了写好的用来包装简历的skill,那么今天来给大家分享怎么去写一个好的,可以实际用来工作的skill,摆脱只会写提示词的尴尬。构建 Skill 的五个步骤Step 0:先写 EvalsEval(Evaluation,评估)是一套结构化的、可重复运行的测试用例集,用来判断 Skill 的表现是否符合预期。它不是泛指"测试一下",而是开发 Skill 的前提条件。一个典型的 Skill eval 集至少包含三类用例:- 正例(Positive):用户说“帮我看一下这个 PR 能不能合”,验证 Skill 应该被加载- 负例(Negative):用户说“帮我把代码格式化一下”,验证 Skill 不该被加载——路由别跑偏到不该触发的地方- 边界(Edge):“这个 PR 改了一行日志,要不要审”,验证边界情况下的路由行为正例和负例都要写,而且负例往往比正例更值钱——误触发是 Skill 路由的头号失败模式。Eval 不只是测一次。Perplexity 的 eval 分三个层次:如下图每种都要在 GPT、Claude Opus、Claude Sonnet 不同的 orchestration 模型上分别跑——Sonnet 和 GPT 的 Skill 行为差异很大,只在一种模型上过了不够。没有 evals,你改 description 就是在盲改,一个新 Skill 也可能悄悄搞坏已有的十个 Skill。Step 1:写 Description(最难的一行)description 是路由触发器,不是文档。写好它不需要关心 Skill 的内容,只需要关心能不能在正确的时间加载、有没有意外触发到不应该触发的地方——误触发是头号失败模式,每加一个 Skill 都有可能让其他 Skill 变差。糟糕的 description 描述 Skill 做什么,好的 description 说什么时候加载。举个监控 PR 的例子:不要写这个 Skill 做什么,要写工程师感到焦虑时会说什么——"babysit"、"watch CI"、"make sure this lands"。快速检查清单:- 以"Load when…"开头- 控制在 50 词以内- 描述用户意图,最好来自真实查询- 不总结工作流程Step 2:写 Body跟同事讲工作流程和跟 LLM 讲工作流程完全是两回事。对几乎任何面世超过一年的软件工具,只要提名字,模型已经知道怎么用。所以跳过模型已经懂的部分。不用写出每一步命令。比如不要写 git log → git checkout main → git checkout -b clean-branch → git cherry-pick commit。写 "Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why." 模型在后者上表现好得多,尤其是事情不按预期走的时候。太规定的指令比灵活的指令更脆弱。然后聚焦 gotchas 和反例,它们是最高信噪比的内容。每次 Agent 搞砸了就加一条,gotcha 会自然地累积起来。条件逻辑或内容太重的东西移出 SKILL.md,放到 accessory file 里渐进加载。Step 3:用层级结构- scripts/ —— 确定性逻辑,模型不用每次重新发明- references/ —— 重型文档,条件触发才读("如果 API 返回非 200,读 api-errors.md")- assets/ —— 输出模板,模型直接复制填充- config.json —— 首次运行设置,问一次保存下来对于极其复杂的 Skill,进一步考虑是否应该拆成一组 Skill,用 depends: 声明加载关系。Step 4:迭代切分支出来,在无 Skill 的状态下跑 hero query(核心用户场景查询),建 eval 集,反复调。提交 review 时最好一个 changeset 里自带 eval 集。Description 里的小词改动对路由影响很大,甚至会 spillover(溢出)到其他 Skill,所以这些在 Step 5 之前做完。Step 5:发布大家快把这5步实行起来,成为写skill专家吧!
琉璃梦忆:直接skill creator 管你这那的
AI了,我在打一种很新的...
点赞 评论 收藏
分享
码客明:我教你个方法,你和你室友沟通一下告知他这个事情。然后就说导员问我就说,室友已经和导员提前沟通了。最后被查到你就说室友和我说了他已经和你沟通好了我没想到他是骗我的呀!把责任都甩给你室友,当然你出去实习的室友也肯定愿意承担这个责任。
点赞 评论 收藏
分享
评论
1
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务