2027 届校招 · 求职方向:AI 项目专员

把 大模型能力
做成可度量、可迭代的业务成果

字节跳动内容安全策略实习:独立负责 4 个 Policy 的 Prompt 工程,以 Precision / Recall 驱动迭代;
课余 Vibe Coding:零框架依赖的像素风互动叙事游戏,已上线并完成一轮首屏性能优化。

查看 Prompt 实战 试玩小游戏 ↗

实习实战 · 字节跳动

Policy Prompt Engineering:让审核大模型「判得准」

负责 IGS(互惠索礼)、DT3P(引流第三方平台)、MTE、LI 等 4 个内容安全 Policy 的 Prompt 工程。 每周对模型判案结果做数据清洗,用 Precision / Recall 双指标度量效果,目标 P70 / R50, 形成"改 Prompt → 小样本验证 → 大样本回归 → Bad Case 归因"的完整迭代闭环。

4个 Policy 独立负责
P70 / R50精确率 / 召回率目标
10FP 小样本先验证再放量
6000→3000Token 精简后 PR 反升

① 我的迭代方法论

  1. 冷启:规则 + 正例双输入

    先吃透 OPUS 审核规则(正向条件 / 豁免条件),再把样本库里的正例全部拉出来观察违规形态——纯按规则写会漏内容,纯抄 case 会过拟合,两者结合准确率最高。

  2. 小样本快速验证

    每改一版,先在当轮 10 个 FP 上单独验证:确认改动对目标 case 有效、方向没跑偏,再跑大样本,避免"改好 10 个、带崩 100 个"。

  3. Bad Case 聚合归因

    抽检 Bad Case 找共性(常有 15/20 是同一问题),一条规则改动一次性消掉一批;并让 AI 工具帮我概括每个 case 的思维链、输出整体结论,把时间花在判断而不是翻表上。

  4. 版本管理 + Diff 回滚

    每版记录改动点。新版 PR 下滑时不推倒重来,而是拉出"V1 对、V2 变 FP"的 Diff Case,逐个对比两版 COT 定位原因(如答案模板过细诱发幻觉)。

② 我总结的 Prompt 写作五原则

01

结构清晰最重要

先定 Step1 / Step2 / Step3 的骨架再填内容,每个场景内部逻辑保持一致(都是"判定条件 + 条款")。结构清晰后,改一个 Step 不会波及其它 Step,定位 FP 又快又准;还要避免条款间自相矛盾——模型会因此这次判 A、下次判 B。

02

判定条件要前置、要精准

能写进判定条件的就往上写,精准描述"要识别什么";避免上面写得笼统、下面堆一堆排除条款。原则性的整层豁免(如才艺豁免)上提,细碎的非决定因素不要混在豁免里。

03

答案模板与 Prompt 同构

输出按 scenario 分段,方便 RCA 精准定位是哪一类判错。模板只在命中时要求说明理由——曾踩过坑:模板写太细,模型觉得"你都写了肯定有",反而硬猜产生幻觉。

04

Token 做减法

Token 太长会让 P、R 双低且不稳定:注意力被稀释,模型抓不住重点。实测从 6000 压到 3000 左右指标反而提升,之后我把 Prompt 稳定控制在 3000–5000 token,能 5 个字讲清就不写一句话。

05

Step 间解耦

不同 Step 不重复定义同一概念。例如 Step1 已定义"索礼",Step2 就不再耦合索礼描述,直接删掉重复段落——重复内容看似强调,实则制造歧义。

③ 实战案例:IGS 互惠索礼的三步判定结构

IGS = Reciprocal Gifting,核心是我抽象出的一句话:"直播中观众送给主播一个礼物,主播回报观众一个东西,且两者必须有因果关系。"

Step 1 · 索要礼物

识别三类索礼信号:TikTok 礼物(圆形金色图标)、金币 coins、真钱(如 5 美元 / 800 日元);信号来源覆盖文本、画面图标、ASR 语音三个通道。

Step 2 · 回报

枚举 5 种回报场景:互动指标(关注/点赞/灯牌)、游戏物品(皮肤/道具,须是具体名词)、数字内容(账号/电话)、抽奖资格、支持者阵营加分。

Step 3 · Link 关联

索礼与回报必须存在同一位置 / 明确时序 / 因果关系,没有关联不判违规。并沉淀特殊规则:游戏动作不算回报、Drop 武器算、游戏币≠真钱、cohost 不算 FP。

实战案例:DT3P 引流第三方平台的两条判定路径

路径一 · 常规引流

第三方平台信息 + 可操作符(用户 ID / 链接 / 二维码,仅有 "INS" 字样不算),且存在无互动久坐或第三方画面占屏 50%+ 的引流行为;有真实观众互动则豁免。

路径二 · 支付平台

第三方平台 + 支付平台(如 PayPay + 账号、银行 + 账号)直接判违规,不被互动豁免——支付场景零容忍。

④ 心得:这段实习改变了我写 Prompt 的方式

  • Prompt 是工程,不是许愿。每一版改动都要能回答"针对哪批 FP/FN、预期哪类 case 翻转",用指标而不是感觉验收。
  • 先写结构,再写句子。骨架错了,措辞再精致也是错的;骨架对了,调优只是局部手术。
  • 样本和规则缺一不可。规则告诉我 policy 的"法理",正例告诉我真实世界的"案情",只看一边都会偏。
  • 克制比堆料难。Token 减半后效果更好、答案模板变薄后幻觉更少——大模型不需要面面俱到的叮嘱,需要清晰无歧义的边界。
  • 让 AI 参与分析 AI。用大模型批量概括 Bad Case 的 COT,把人力留给最终判断和策略设计,这也是我理解的"AI 提效"的正确姿势。

个人项目 · Vibe Coding

《小迟去哪儿》:毕业生人生选择互动叙事游戏

一款像素风 Web 小游戏:在"人生车站"操纵主角余小迟,登上五辆列车体验五种毕业去向—— 社畜号(就业)、学术号(考研)、编制号(考公)、留子号(留学)、待机号(Gap)。 对话分支、限时问答、申论卡片排序、留学材料拖拽上传等玩法均已实现,全程用 AI 协作编码(Vibe Coding)完成。

🎮 在线试玩(Demo 阶段)

手机竖屏体验最佳;桌面端在画面左侧 40% 区域按住拖动出现虚拟摇杆。

打开在线 Demo ↗ 查看源码

关于已知的「首屏黑屏」问题

线上 Demo 首次打开可能黑屏约 1 分钟。排查发现:4 张 NPC 精灵图是 1536×1024(共 5.8MB),游戏必须全部加载完才首帧渲染,而画面中人物显示高度仅约 80 像素。

已完成修复并本地实测:nearest-neighbor 像素风缩至 768×512(340KB,体积 −94%)+ 增加加载提示,首屏 60 秒 → 1–2 秒,人物零变形。修复已提交,推送后 Netlify 自动重新部署。

游戏切片

切片 1 · 车站自由探索动态虚拟摇杆、像素站台、站牌与引导提示
切片 2 · 与列车员对话分支对话系统,"上车 / 再看看"决定走向
切片 3 · 登上社畜号登车演出后进入第一章生活地图(就业线)

技术栈与工程亮点

栈

Vite + TypeScript + Canvas 2D

零运行时框架依赖。静态场景预绘制,逐帧只更新镜头、角色与少量环境动画;逻辑分辨率 360 宽等比适配,桌面居中竖屏,适配刘海屏安全区。

构

数据驱动的多路线叙事

五条人生路线复用同一套事件执行器、地图与互动组件,新增剧情只需编写内容数据文件,不新增页面。

件

自研交互组件库

多点触控虚拟摇杆(指针归属 / 中断归零)、邻近范围交互、分支对话、限时问答、卡片排序、材料拖拽上传。

测

Playwright 回归 + CI 部署

跨浏览器用例覆盖移动、碰撞、五路线完整流程与小屏对话;Netlify 推送 main 自动构建发布,仓库保留每个阶段的验收记录。