互联网大厂“黑话”完全破译指南

在互联网大厂工作，有时候听同事聊天就像在听天书。为了帮助大家快速融入（或者假装自己很懂），我特意整理了这份“保姆级”黑话词典。本文纯干货，不整虚的，建议收藏防身。

🙋‍♂️ 第一部分：职场通识篇（非技术岗也要懂）

1. PRD (需求文档)

• 全称：Product Requirements Document
• 人话解释：产品经理的“圣旨”，也是程序员和测试员干活的唯一法律依据。简单说，就是一份详细说明书，告诉大家“我们要造个什么东西”。如果没有这玩意儿，开发就可以理直气壮地拒绝开工。
• 场景举例：
  • 就像装修时的施工图纸。没图纸，装修师傅（RD）根本不知道插座装哪，装错了还得拆了重来（返工）。

2. A/B Test (赛马机制)

• 人话解释：成年人不做选择，两个都要。当产品经理拿不准哪个方案更好时，就让一部分用户看A版页面（比如红色按钮），一部分看B版（绿色按钮），最后看数据说话，谁效果好就留谁。
• 场景举例：
  • 就像可口可乐出新品，不知道大家喜欢樱桃味还是香草味，就先在两个不同的超市分别上架，看哪个卖得快，最后决定量产哪个。

3. PD (人天)

• 全称：Person Day
• 人话解释：计算工作量的单位。意思是一个人干一天活，叫1PD。这是项目排期时的通用货币。
• 场景举例：
  • PM：“这个需求很简单，怎么要这么久？”
  • RD：“这功能逻辑复杂，我评估需要3PD（一个人写3天），你要是急，给我加个人，也许能缩短到1.5天。”

4. WLB (工作生活平衡)

• 全称：Work-Life Balance
• 人话解释：能不能准时下班。这是打工人最关心的指标。WLB好，意味着不怎么加班，周末双休；WLB差，约等于“996”或“007”。
• 场景举例：
  • 面试黑话：“我们团队创业氛围浓厚” = WLB极差。
  • 面试黑话：“我们团队比较养老” = WLB很好。

5. JD (职位描述)

• 全称：Job Description
• 人话解释：招聘广告。告诉你这个岗位是干嘛的，需要你会什么技术，以及（画饼）能给你什么。
• 场景举例：
  • 看JD时要学会“翻译”：写着“抗压能力强”，通常暗示加班多；写着“弹性工作制”，可能意味着下班时间不固定。

6. Base (工作地点)

• 人话解释：你的工位在哪个城市。
• 场景举例：
  • 猎头问：“你考虑Base哪里？” 意思就是问你想去北京、上海还是杭州上班。

7. RD (研发/码农)

• 全称：Research & Development
• 人话解释：写代码的人。在公司里，大家通常统称程序员为RD。
• 场景举例：
  • “这个需求你去找RD评估一下可行性。” = “你去问问写代码的能不能做。”

8. QA (测试)

• 全称：Quality Assurance
• 人话解释：找茬的人。他们的工作就是给RD写的代码挑刺，发现Bug，确保上线的产品没有质量问题。
• 场景举例：
  • 上线前夜，QA大喊：“有个P0级（最高级）Bug，今晚谁也别想走！”

9. PM (产品经理)

• 全称：Product Manager
• 人话解释：提需求的人。连接业务方和技术方，负责画原型、写PRD、催进度。
• 场景举例：
  • RD的天敌。日常对话：“这个需求做不了”、“这个需求下个版本再做”。

💻 第二部分：技术硬核篇（听懂研发在吵什么）

1. 埋点 (监控探头)

• 人话解释：给App装监控摄像头。在代码里偷偷安插一些“探头”，记录用户点了哪里、停顿了多久。这些数据是A/B Test和产品分析的来源。
• 场景举例：
  • 你在淘宝看这双鞋看了多久、最后买没买，都是通过埋点记录下来并传给服务器的。

2. 覆盖率 (考试范围)

• 人话解释：测试到底测全了没有。通常指“代码覆盖率”，比如我写了100行代码，测试用例跑过了其中的80行，覆盖率就是80%。
• 场景举例：
  • 就像期末考试复习，书上一共有10章，你只复习了5章。考试如果考到没复习的那5章（未覆盖的代码），你就挂了（出Bug）。

3. 单元测试 (零件质检)

• 人话解释：最小维度的测试。不测整个系统，只测一个函数、一个方法对不对。
• 场景举例：
  • 造汽车时，先单独测试“刹车片”好不好用，而不是等车装好了再去撞墙测试。测刹车片的过程就是单元测试。

4. 灰度发布 (试喝模式)

• 人话解释：切忌梭哈。新版本上线不直接推给所有用户，而是先放给1%的人用，没问题再加到10%、50%，最后全量。
• 场景举例：
  • 大型网游更新，通常会先开几个“体验服”让玩家进去踩坑。体验服没问题了，再更新到正式服。

5. PR / MR (交作业)

• 全称：Pull Request / Merge Request
• 人话解释：请求把我的代码合并进去。RD在自己的分支写完代码后，不能直接塞进主仓库，要发起一个申请，让别人检查。
• 场景举例：
  • 就像你写完了作业（代码），交给课代表（主仓库），请求他把你作业收起来订到全班的作业本里。

6. CR (作业批改)

• 全称：Code Review
• 人话解释：代码审查。在合并代码前，老员工或者同事会围观你的代码，指出哪里写得烂、哪里有隐患。
• 场景举例：
  • 公开处刑现场。大佬指着你的代码说：“这里为什么要写个死循环？”

7. TP99 / TP999 (尾部延迟)

• 人话解释：绝大多数人的体验。TP99 = 20ms，意思是99%的请求都能在20毫秒内完成。这个指标比“平均时间”更能反映系统的卡顿情况。
• 场景举例：
  • 班里平均分90分（平均值），看似很好，但可能有一个人考了0分（长尾）。TP99就是把考分从高到低排，看倒数第1名（排除掉最差的1%）的分数，更能反映“最差情况下的体验”。

8. N个9 (靠谱程度)

• 人话解释：系统一年能正常工作多久。
• 场景举例：
  • 3个9 (99.9%)：一年大概有8.7小时系统是挂的。
  • 4个9 (99.99%)：一年只有52分钟是挂的。
  • 5个9 (99.999%)：一年只有5分钟是挂的（大厂核心系统的目标）。

9. QPS / TPS (手速/吞吐量)

• 全称：Queries Per Second / Transactions Per Second
• 人话解释：系统一秒钟能抗多少揍。这是衡量系统性能的核心指标。
  • QPS (每秒查询数)：侧重于“读/查”。比如大家都在刷微博看热搜。
  • TPS (每秒事务数)：侧重于“写/交易”。比如大家都在双11零点下单付款。
• 场景举例：
  • QPS 就像图书馆咨询台，每秒钟能回答多少个“厕所在哪”的问题。
  • TPS 就像银行柜台，每秒钟能完整办理多少笔“转账业务”（涉及身份核对、扣款、回单等一系列动作）。通常TPS比QPS更难做高。

10. 服务大盘 (驾驶舱仪表盘)

• 人话解释：系统的实时体检报告。一个聚合了所有核心数据（QPS、错误率、CPU使用率等）的监控大屏幕。
• 场景举例：
  • 运维和开发人员就像飞行员，服务大盘就是飞机的仪表板。
  • 大促（如618）的时候，大家就盯着大盘看。如果曲线平稳，大家喝茶；如果某条曲线（比如错误率）突然飙升变红，大家就要准备“救火”了。

11. 上下游 (食物链关系)

• 人话解释：谁依赖谁，谁就是下游。这描述的是数据流向和依赖关系。
• 场景举例：
  • 买奶茶场景：
    • 你（顾客）点单 -> 呼叫服务员。你是服务员的上游（发号施令）。
    • 服务员（接单） -> 呼叫后厨做茶。服务员是后厨的上游。
  • 系统场景：
    • “订单系统”调用了“支付系统”。订单系统就是下游（因为它依赖支付），支付系统是上游（提供服务）。如果上游（支付）挂了，下游（订单）通常也会报错。