观察行业对 AI 演进的视角以及这项技术被运用的多样化方式，是一次非常有启发性的经历。以下是我对本次活动核心见解的总结。

核心观察与体会 (Key Takeaways)

软件生命周期中“瓶颈”的转移

由于 AI 极大地提升了编写代码的速度，传统软件开发中的瓶颈已经发生了转移。现在，产品管理、UX 设计、合规审查以及人工代码审查成为了减缓项目交付的主要约束。特别是当 AI 一次性输出海量代码时，审查这些 AI 生成的代码需要耗费巨大的时间成本。

技术债的飙升与代码质量的退化

虽然 AI 加速了代码生成，但它也引入了所谓的“企业级质量差距”（Enterprise Quality Gap）。企业虽然看到了开发速度的激增，但随之而来的是代码复杂度的增加和严重的 Bug。数据显示，主要由 AI 编写的代码，其严重 Bug 增加了 40%，整体 Bug 数量增加了 70%。此外，LLMs 往往为了通过测试而盲目修补代码，却不考虑整体架构，这很容易让一个清爽的 300 行脚本变成一份长达 6000 行且难以阅读的“邋遢代码”（sloppy code）。

基础设施与生产环境的可靠性挑战

构建一个基础的 AI agent 并不难，但要让它达到生产级别（production-ready）却极其困难。在现实世界中运行的 agent 经常会遇到分布式系统的故障，比如 API 频率限制、网络拥塞以及工具崩溃。如果一个长周期运行的 agent 在任务中途崩溃，它会丢失所有的进度和上下文，这意味着开发者之前投入的时间和 Token 成本都付诸东流。

AI 素养与初级开发者的断层

目前存在着巨大的、尚未解决的“AI 素养”（AI literacy）差距。公司都在渴求 AI 技能，但对于如何教授用户正确编写 prompt、审查输出内容以及编排系统，目前还没有统一的方法论。这对初级开发者构成了巨大挑战：他们传统上是通过完成入门级任务来学习手艺的，而这些任务现在正被 AI 自动化。因此，行业正在苦恼于如何培养下一代有能力监管这些 AI 系统的资深工程师。

T 型人才与分布式管理

行业将更加青睐“T 型”全才，而非纯粹的专才。因为 AI coding agents 承担了大部分原始代码生成工作，工程师必须拓宽其横向技能，涵盖产品管理、用户体验和系统设计，以便有效地驾驭这些工具。因此，传统的工程经理角色正在扁平化。管理职能不再集中在一个人身上，而是分布到整个团队中。每一位工程师都正在成为“编排者”（orchestrator），必须独立管理一群 agents，定义产品目标，批判性地审查输出，并迅速做出决策。

开发者的脉动 (The Developer Pulse)

董事会对高管的压力：为了市场热度的盲目采纳

受限于错过机会的恐惧（FOMO）和拉升股价的欲望，投资者和董事会要求立即接入 AI。高管们面临着交付短期生产力增长的巨大压力，有时甚至不惜通过“大裁员”来取悦市场。由于这些领导者往往脱离日常技术工作，他们优先考虑快速部署而非长期架构的稳定性，为了跟上趋势不惜冒着做出灾难性商业选择的风险。

领导层：用更少的人实现更高的吞吐量

高管们将这种压力传导至一线，其指令非常明确：“代码更多，人更少。”他们期望工程师利用 AI 工具（如 coding agents）来大幅提速。然而，领导层往往误解了 AI 速度背后的隐藏成本，将“原始代码生成”与“解决实际问题”混为一谈。这迫使工程师在软件开发生命周期（SDLC）尚未准备好时就采用新工具，导致了摩擦以及对软件交付速度不切实际的预期。

工程师：面对堆积的技术债与组织信任危机

利益相关者对 AI 驱动速度的压榨，正在营造一种焦虑文化，并加剧技术债。与其优先处理没完没了的 Pull Request，工程师更应该让自己沉浸在持续学习中，因为模型和框架正以指数级速度演进，僵化的专业知识很快就会过时。当 AI 生成 Bug 或架构烂摊子时，一线开发者最终要负责修复这些“企业级质量差距”。如果被短期指标逼得太紧，工程师难免会通过弄虚作假来完成产出配额，导致“PR 垃圾”和系统性倦怠。我们的焦点必须从单纯的榨取利润和裁员，转向构建健壮的系统和维持技术素养。

建议：运用共情与沟通

由于领导层往往基于热度和 FOMO 运作，追求即时结果，这种紧张关系是客观存在的。工程师和经理可以尝试对高管保持共情——他们虽然不写代码，但面临着巨大的市场压力。此外，真正的专家优势在于跨越不同抽象层级沟通技术现实的能力。通过清晰的沟通来管理利益相关者的预期，证明可持续的 AI 采用需要扎实的工程基础，而不仅仅是速度。

Google 的护城河与优势

在大会第一天，Google 展示了多款新模型和工具：Gemini 3/3.1（多模态）、Gemma 4（开放权重）、AI Studio（原型开发），以及 Veo 3.1（视频）、Lyria 3（音乐）和 Genie 3（世界模拟）等创意模型。

在我看来，基于以下核心战略和结构性优势，Google 在行业中保持着独特的地位：

基础设施与垂直整合 

Google 已成功部署了多个经证明对生产级用户体验有效的顶级 AI 模型。通过自研 TPU 硬件，他们实现了垂直整合，消除了对外部基础设施供应商的依赖，确保了长期的成本效益和运营独立性。

开发者生态与良性循环

 Google 培育了专为编排 AI agent 设计的整套工具、API 和服务。凭借财务稳定性，他们提供的竞争性定价和免费层级降低了准入门槛，形成了“采用率提升-模型优化”的良性循环。当公司在 Google Cloud 上验证其业务逻辑时，这种供应商锁定（vendor lock-in）为 Google 超越 AWS 等竞争对手提供了契机。

无处不在的应用触达点

移动设备和浏览器仍是用户交互的主要门户。Android 和 Chrome 生态系统为 Google 提供了独一无二的触点，可以直接向用户部署 AI 体验。这种广泛的存在有助于收集高质量数据，而数据是 AI 系统迭代改进最关键的资产。

通用型 vs 特定型 AI

 虽然 Google 目前的 AI 产品侧重广义通用，与 Anthropic 等专注特定领域的对手有所不同，但其庞大的内部需求量，必将驱动其在代码和设计等领域掌握领域特定型 AI，通过强大的组织执行力填补差距。

基于这些洞察，我对我们公司的战略方向有了更清晰的认识：我们必须开发自己的专有 AI 模型以保持运营独立性，同时构建应用型 AI 解决方案和 agents，从而创造更具沉浸感和价值驱动的用户体验。

I leveraged Gemini to research and aggregate this technical data, while the interactive components of the page were built using Claude Code.

疫情让大家的工作生活方式都有了很大的改变， 对我个人而言也有很多体验和成长。

时间线

先来回顾一下基本的时间线：首先是从2022年3月开始一直居家办公，所有交流都是远程视频会议的形式，因此后来见面时都惊讶与脑海中预期的身材不符。

接着2021年8月公司开始邀请员工自愿回公司，10月开始部分食堂提供午餐，我在11月因为孩子转学到公司附近的学校开始每天到公司方便接送孩子，但绝大多数都单独在一个房间里开会。

到了2022年7月我感染了新冠，在家休息了两周之后开始居家办公，另外孩子的在8月转到了离家较近的学校所以一直没有要去公司，一直到9月才重新开始一周去2-3天。10月的时候发现了家附近有直接到办公楼门口的班车，于是又转换了交通工具来更好的利用通勤。

但直到目前4月也基本一半时间居家办公一半时间去公司，只是通勤的交通工具会应天气情况二变化。

改变与发现

这三年的不同工作方式对每个人都有改变，对我来说也是如此，有好的也有不好的就挑几个分别聊聊。

好的地方

咖啡

我一直都很爱喝咖啡，每天1-2杯。在办公室里我会用公司的意式浓缩咖啡机给自己做拿铁，偶尔还能做出拉花。一开始居家办公的几个月我只能用法压壶来泡咖啡喝，后来想着居家是个长期的事情，于是买了Breville的半自动意式浓缩咖啡，生活一下子变得更有精神了。

我开始网上订购当地不同烘培的咖啡豆来尝试不同的口味，也在咖啡拉花得到强化。但有一点最重要的是我发现了自己乳糖不耐受的事实，也解释了为什么我在公司喝完自己做的拿铁就特别爱上厕所。公司里都是全脂纯牛奶，在家里我就买低脂无乳糖的。

对话

我的声音比较低，所以跟人当面说话的时候别人经常听不到我说话的声音。在说英语的时候我又会不自觉的把声音压得更低，当又不太会说的单词时我又会放轻发音试图蒙混过去，这样就更让对方听不清我要表达的意思。

居家工作之后，所有工作上的会议交流都通过Zoom视频电话会议，这样很好的掩盖我的缺点：声音不太低，我就靠话筒近一些或者对方把音量调高一些；单词不确定我就在电脑上快速搜索来确认。

经过这几年在线上的锻炼，见面交流虽然还是有声音过低的问题，但流畅度有了很大的提高。

亲子

在家工作最大好处之一就是减少了上下班的时间，特别是避免了堵车造成的时间浪费。于是我有更多时间跟孩子交互接触，即使有些陪伴的质量并不算高，但体量决定增加了很多。另一方面，太太多承担了全家的早餐和午餐，我也相应的分担了一些照顾孩子工作，比如洗澡、刷牙。这也让我感受了更多他的成长。

坏的地方

健康

居家办公的时候基本上都是坐在电脑前工作，开车出门接送孩子，每天最频繁的走动就是在书房和不到20步远卫生间，最长的距离就是停车场到教室。当时没有用智能手表，但是估算一下可能一天总动走动不到2000步。同时因为疫情，也不能去公共场所进行锻炼，这导致我能明显感受到身体状态的下滑。特别明显的地方就是腰背经常强烈酸痛，甚至不能站立很久。

很明显的对比就是在我回到公司上班之后，我在办公室有意识的更多站立工作，同时每天中午吃饭要走比较长的距离到食堂，单单这些小的变化就让我再没有感到腰背的不适。

通过这个经历，也让我发现减少身体疼痛不一定是要针对痛的地方。比如腰痛，是因为长期久坐腿和臀的肌肉力量减弱同时增加了腹部重量，进而身体压力都转移到了腰部。所以腰部的按摩并没能缓解我的疼痛，更有效的反而是简单的走路恢复腿部力量和平板撑来增加腹部力量。

交流

上边说居家办公通过视频电话让我的对话变得更有效，但另一方面也让同事间的交流变得没那么频繁。所有的交流都需要非常刻意地创建一个会议，打开视频进行。不像在办公室可以发生在任何随意的场景：办公桌旁，小厨房，食堂等等。特别是午餐时间，其实是大家互相随意交流生活，了解每个人的最好时间。亦或在前往下一个会议室的路上硼矿，随便简单聊几句也能快速交换一些信息或者激发出几个想法。

此外，在某些特别的会议上，比如绩效对话，我个人觉得面对面的交流会更好。我可以更注意对方的表情和身体细节来改变我的对话方式和内容，或者用一些肢体语言来补充口头交流。

空间

居家办公另一个大问题就是家庭空间被挤压，家里需要一个地方甚至一个房间来长期提供办公场所。疫情期间，由于学校关门，很多孩子也要在家上网课就更进一步割裂了家庭空间。我们还比较幸运，孩子的托儿所因为规模比较小在疫情最严重的时候也可以一直运行，我还可能白天把孩子送出去，在家占有一个房间来开会办公。

除了空间尺寸，空间的舒适度也是一个问题。办公室一般都会长期开着中央空调让温度一直保持在一个常态，这样我就能感到身体上的舒适从而更好地工作。但是在家的时候，冬天有时候就冷得无法集中注意力，虽然有中央暖气但是又觉得只有一个人在家没必要开。到了夏天，因为没有空调，有些日子又热得直冒汗。

很多时候，习惯了一些行为方式，就成了惯性不太容易改变，但当一些外界因素造成我们不得不去适应新的变化的时候，发现其实有些改变也不见得都很坏。

第三方厂基于Google配合Android系统手机为手表开发的Wear OS发布过很多智能手表，但是由于各种原因都没有Apple Watch那边受欢迎。Pixel Watch是第一款由Google自己发布的智能手表，紧靠着Pixel手机的产品线。因为是第一款自然跟比较成熟的Apple Watch还是无法比拟。

我个人对手表有比较强的需求，这样我可以随时方便地抬手看时间，而不需要每次掏出手机再点亮屏幕。不过我对智能手表一直没有很大的热情和期盼，一来它的大多功能都还无法取代手机对我而言主要功能还是看时间，而来它的低续航又需要我付出其他的精力去维持它的功能。

所以过去一年里， 我日常使用的是 Fitbit Charge 5，在保持一周左右的续航的同时，还能获得简单的健康和锻炼信息。可能正是因为 Pixel Watch 跟 Fitbit 有自然的继承，让我在 Pixel Watch 的转换感到无比的舒适。在拥有同样的 Fitbit 的功能同时，还有更好的交互界面。虽然续航是最大的短板，最多只能持续24小时，但是基于更好得电池布局其充电速度非常得快，很大程度得弥补续航得不足。另外，每天我也会在洗漱时讲手表摘下拿去充电，并没有感到不便，因此 Pixel Watch 自然成了我的日常佩戴。

Pixel Watch有不少 Google 和 Fitbit 出的第一方应用，也可以在Play Store上下载很多第三方应用。由于屏幕过小，我并不是特别习惯使用这些应用。但是也有几个功能我非常喜欢使用。

一个是用手表唤起手机铃声，这样就能很快找到手机；另一个是通过手表来控制在手机上的媒体播放，特别是调节音量，我就不需要拿出手机来控制了。

目前还没有对 Pixel Watch 进行深度发掘，希望以后能有更多的发现和惊喜。

Pixel Phones

自2018年介绍了一下 Pixel 3 XL 手机已经有4年时间了，Pixel系列也到了第7代。中间因为没有看到特别大的提升以及听到的质量问题我跳过了 Pixel 4，但集齐了 Pixel 5，Pixel 6 Pro 和 Pixel 7 Pro。

Pixel 5 是2020年底疫情期间发布的，这是目前整个系列唯一只有一种尺寸的手机，并且还只有一个 128GB 的存储容量选项。可以理解应该是当时因为供应链无法适应疫情这个突发情况，而不得不进行缩减来保证基本的供应。Pixel 5 在处理器上甚至比 Pixel 4 还差一些，而处理器芯片的短缺也在疫情期间持续了很久。

Pixel 5 一直被我作为工作机使用到现在。在工作上，我只要用它来回复短信和邮件，比较复杂的工作就切换到电脑上完成，所以并不需要特别强的性能和特别大的屏幕，其轻便性反而是优势。

2021年底，Pixel 系列重新回到了两款不同尺寸手机的节奏，不过大屏幕的手机命名由原来的 XL 变成了 Pro。一般企业对于产品线改名非常慎重，容易造成用户对于产品差异的迷惑。仔细对比各款手机，确实看出 Google 在 Pixel 手机上的策略改变。

以往普通款和相应 XL 款确实只有屏幕尺寸上的不同，所以基础价格上也只相差 $100。而 Pixel 6 和Pixel 6 Pro 在内存上差了4GB (普通款8GB，Pro款12GB)，另外 Pro 款的后置摄像有3个，比普通款多一个，前置摄像头像素11.1MP，也比普通款的8MP高，因此整体价格上有多$300。

但是相对于以往，Pro 价格比XL的价格高一些，但是普通款却比原来价格低了。比如 Pixel 4 发行价是$799，而 Pixel 6 的发行价只有$599，这也相对降低了 Pixel 手机的进入门槛，可以吸引更多非 Pixel 用户了购买。

我个人对 PIxel 6 XL 的体验并不是很好。首先手机质量第一次超过了200g，让我使用时会很快感到手腕变酸而不能持久使用。后背相机镜头周围有一款凸起，使得放置时会不平。那块凸起时玻璃材料，导致不到半年就意外摔出了很大的裂纹，拍照时就出现虚光。指纹识别上去掉了后背的实体感应器，改为正面屏幕下的感应，具体使用时准确度下降了很多，经常变成密码输入。我个人时比较喜欢后背的设计，同时还有下滑调出通知栏的方便功能。处理器芯片时第一款由 Google 自己开发的 Google Tensor，有了更多内置 AI 功能，但我并没有感受到具体的体验提升。

源于对数字7的喜爱，今年 Pixel 7 Pro 预售时我就下单了这部手机。这部基本是前作的优化版，而非进化版。从硬件配置上比较，Pixel 7 Pro 比 Pixel 6 Pro只在处理器上改到 Google Tensor 二代，其他方面都很相同或接近。但是硬件和软件上的各种优化都让我有了更好的体验，比如后置摄像头的凸起部分由玻璃变成了铝合金，这样就不容易出现裂痕。手机重量虽然变轻了一些，但还是有200g，依然很考验腕力。

最后，延续过往的惯例放上最近3款Pixel手机的照片和规格对比：

（照片来自Pixel XL。我还是有经常拿第一代Pixel来使用，因为这款还有 Google Photos 无限原始尺寸上传的福利。)

我入手的第一款无线耳机是2016年买的Bose QuietComfort 35。在开放式办公室工作我一直期望有一部降噪耳机，如果是无线的就更好了，但在当时对于$350的价格还是比较犹豫的。

一个在Apple的朋友跟我说他们有员工折扣可以买这款耳机。这一下子让我惊讶到原来Apple员工折扣单单可以买Apple自家的产品，还有在Apple Store卖的其他东西都可以。他查了一下可以最后的价格含税差不多是原价的85折，我一下子心动了。当他说下单可以当天就近去Apple Store取货，我立刻把信用卡号发给了他。

这部耳机的好不用多说，降噪功能让我工作时可以非常专心，出差的时候我也会带到飞机上来隔绝飞机上的声响好安心入睡。耳机的音效也是让我最舒适的，完全打压Apple的各种耳机。耳机的电源续航能力也很好，所以一直用到现在。现在耳机垫因为时间原因已经老化破皮了，我还刚刚给它换了新的。

要说不好的地方，夏天带着比较热是一个，但考虑到办公室的空调总是很低这个不是问题；另一个就是比较大也比较沉携带起来不太方便，一般我都留在办公室的抽屉里。最多的状况还是同事有事找我时基本完全听不到他们的声音呼唤，接着就被他们拍肩膀吓到。

我的第二副无线耳机是Bose的SoundSport，是我在2017年的黑五Amazon上打折时买的。当时我跟着健身教练在做锻炼，想着需要一副方便的耳机跑步热身的时候可以用，于是就买了下来。

这幅耳机也基本只在健身房运动的时候用着，但是它的效果其实一般。一来电池的容量小也很容易掉电，经常是我想到用的时候从包里拿出来发现它没电了；二来如果单用一个耳机听歌，那另一个垂下来就不太方便。但也因为这根连接线，我从来没有像Apple AirPods需要找一只丢失的耳机的烦恼。

虽然这幅耳机体验一般，但是还是时不时的会拿出来用一用。

接着要介绍的是我买来之后就基本没有用过的Google Pixel Buds。相对于2016年，2017年我的手头没有那么紧张了，于是就开始尝鲜的方式来支持Android手机和相关的设备（那年我也预定了一部Essential Phone，还好最后它没有发货），于是在Pixel Buds发布的11月初我就到官网预购下单，在12月末收到了货。所以它比Bose SoundSport买得早，但是收到晚。

这副耳机差到我已经不想说了。我当时两部Pixel 1和Pixel 2手机都不能快速的连接这副耳机，连上了经常断开；音质也不是用来听歌的；麻绳的直观也戴着不舒适。所以买来的第一天我尝试用了一下，基本就放在盒子没有动过了。

当时也有想过要退货，毕竟已经提前有了很相似的Bose SoundSport。后来想想就留着收藏吧，也许未来Pixel设备展览的时候，还能把它搬出来。

最后要介绍的是Apple AirPods，我在Costco网上于2019年买了AirPods 2又在2020年买了AirPods Pro。一开始我是不屑买Apple的AirPods的，因为作为Android工程师我日常基本不使用iPhone，也顺带不接触其周边。这也是为什么之前的无线耳机都是其他牌子的，而且跳过了AirPods第一代。

有一天看到Costco上打折，我就想买一个试试吧，反正也能跟Android手机连接。用了之后就开始“真香”，于是AirPods就自然而然地变成了我主要使用的耳机：工作的时候戴着听歌，健身的时候戴着跑步，睡觉前戴着看视频。我也不止一次在找寻丢失的耳机或者耳机盒，好在到现在它们都还完好。

随着2020年的疫情，我们全部都在家工作，我就更加依赖AirPods来开视频会议。因为AirPods可以单用一个耳机，另一个放在盒子里充电，这也让我在会议马拉松的日子里总有一个耳机可以使用。

AirPods虽然可以跟Android通过蓝牙连接，但是跟Mac电脑直接的切换就没有那么方便。于是为了免去设备切换的麻烦，我又买了AirPods Pro固定于电脑连接用来开会，而AirPods就拿来连接手机在带娃的时候听听歌看看视频。

Apple AirPods最让我糟心的地方就是：降价太快了。我买的Bose耳机这么多年价格都没变过，AirPods差不多过几个月就价格$20，Costco动不动就有个折扣，真是心塞。

对于无线耳机，其实我已经开始对Sony的降噪耳机有些心动了。虽然现在还没有强烈欲望要购买，将来肯定还会再购入新设备，毕竟电池使用使用寿命是有限，而工作时候听歌还是要持续下去的。

在评定过程中，不经让我想起了我在美国毕业后第一份工作刚开始不久就受到差评并且被放进 Performance Improvement Plan (PIP)，就趁这机会将这段经历写下来分享一下我的感受和成长。先算不上剧透地剧透结果：我成功地通过了PIP，在公司里愉快地待了快两年，期间拿到了工作签证，最后离职的时候还被强烈挽留，但 PIP 中的一些认知让我还是决定换了公司。

在工作一个月之后，我被两位主管 D 和 J 一起请到会议室，告知我的工作效率太差，需要对我执行 PIP，并当场给了我一个计划书让我签字。计划书的主要内容是需要在一个月完成一个比较复杂的指定项目，如果完不成公司可以解雇我。当时我刚从学校，我其实完全不清楚这个流程是怎么回事，只感到我马上要失去工作然后就需要离开美国。

现在回顾第一份工作的前两周，我的任务主要是学习iOS开发，但是当时安排给我的Mentor是做Android的，所以很多问题都没能给我直接的答案，我只能自己专研Objective-C的语言特性，而没有花太多的时间在分配的任务上。之后一周要做的工作任务又变成用 PHP 开发服务器端的，于是我又重新开始学习 PHP 的语法。然后那个新任务还需要新建数据库的表，然后我又不紧不慢地找 IT 部的人帮新建数据库，当他们问我新表的名字，我说不清楚用什么名字然后又回去跟同事讨论了一下。

不可否认，我的工作方式和效率确实都没有达到基本标准，当时我的英语能力十分拙劣因此不能很好的表达自己的进度，所以对我评价是准确的。只是公司处理方式值得商榷，我当时只是新毕业生，刚离开学校进入社会还在适应新的环境，公司也没有给我设立明确的任务目标，安排的 Mentor 也没有提供高效的指导。当然对于创业公司而言，缺乏入职指导流程也是很常见的事情。

另一方面后来我了解到这家公司的招聘文化似乎就是“Hire Fast, Fire Fast”。Hire有多快？我面试那天当场就开出 offer 让我签。Fire 有多快？有很多人被放进过 PIP 然后被开除。我似乎是唯一一个PIP幸存者，但被开除的同事都很快在其它公司找到更好的工作。甚至连 Recruiter 都被放进去，但是美国人没有后顾之忧直接拒绝了然后帅气的离职走人，而我则必须默默承受下来。

在我接到 PIP 的项目之后，我自然是承受着很大的压力，不敢跟同公司的好友交流，更不想跟家人坦露，只是跟他们说最近比较忙然后开启加班模式。同时我开始计算我银行的存款，估算每个月房租和日常开支看看能支撑多久让我找下家公司。甚至想象着之后我是否每天还要假装出门好让太太以为我还在上班，但其实去咖啡馆刷题找工作。当想到我的 OPT 身份还有差不多九个月的时间，应该足够找到下一份工作，于是我的心情轻松了一些，更专注到了工作上。

在那个项目上，我直接由主管J领导，而他是真的在指导我了解项目需求和代码结构，还花了几个小时给我讲解iOS的MVC 模式，让我觉得是在帮我提高能力而非借这个流程将我开除。也由于项目时间的压力，我更主动去寻求同事的帮助以求更快了解业务逻辑和测试案例，每天都在公司待到晚上10多才离开。

过了一周我就对这个项目有了比较好的解决思路，这时第一月花在Objective-C语言特性上的研究时间也在此发挥了效果，我利用了 Class Extension 对代码做到了很好的解耦，让我的功能可以运行又不影响整体代码。有过了两周我基本完成了整体的功能需求，只是入口比较粗糙。

然后我又开始浪了起来，没有继续完善各种功能，而是开始做PPT把我这几周了解到的东西还有我的设计思路汇总了一下。想着一来可以做为笔记，二来最后给主管进行项目演示时也可以给他展示一下。

之后某天，我跟主管 D 和公司 CTO 约好晚饭后给他们做演示。但是那天碰巧有个项目要发布，于是他们一直专注在了那上面，我只能一直在旁边等着。这也是公司一个陋习，每次项目发布都在晚上还常常没事也要拖到凌晨才结束。好在那天他们半夜有了空闲来看我演示，当然PPT是直接略过了，他们看我操作了整个过程，又亲自上手操作了一下发现几个小 bug，但基本功能和效果都没有出差错。

一个月期限过去了，我没有听到任何决定消息，于是继续完善着这个项目。那段时间，我变得坦然了许多，感觉自己有学到东西没有浪费时间，而且这个项目也挺有成就感可以在之后的面试拿出来说一说，所以不太担心离职找工作的问题。又过了一周快到周末的时候，两个主管依然是突然把我叫到了会议室，然后通知我通过了 PIP，可以继续留在公司，然后让我签了 PIP 完成的文件。之后一个月，他们只叫我继续去做这个项目在服务器端数据存储的方面的优化，于是我又变成了放空状态，开始自己琢磨东西。

最后这个项目并没有发布使用，因为后来我被调到了Android组，又还是学习新东西：Java和Android，也开启了我延续至今的 Android 开发职业生涯。在那Android组里，组长 V 会手把手指导我解决问题让我了解任务，组员全都是中国同事让我得到了更多交流和理解，也让我的更好地适应了职场生活。

现在回想 PIP 的过程已经变得释然，最后的结果也是幸运的。那场经历也让我领会到很多，比如身份(status)很重要所以后来找工作都会以能快速办绿卡为优先要素，有了身份才能有更多选择。主管 J 也给了我一些见解，比如“Don’t be loyal to the company”，毕竟大家签的是 “at will” 的工作合同，员工可以随时离开公司，公司也随时取代员工。

就像 PIP 全名(Performance Improment Plan)所描述的，它本质不是为了用来开除员工的，它原来的目的是帮助员工提高能力，只是某些公司或者不负责的管理者为了避免法律和道德纷争借用了 PIP 了完成开除人的目标。对于管理者，他们需要花很多精力去构思 PIP 中的项目的适应性，也需要很多精力投入到有问题的员工来帮助他们去真正提升工作必要的能力。

我也感谢主管 J 当时对我的指导。后来 J 为我的绿卡申请的工作证明提供了不可或缺的帮助，几年前我又反过来帮他拿到了现在公司的经理职位。我们还一起在同一个大项目合作了一年多的时间，期间他又教了我很多管理上的东西。

目前还带在身边的下边三块，还有一块在一次家人过来玩时让他们存储照片带回去了，下次有机会找到了再补上照片。

第一块移动硬盘是在大二的时候买的，当时的HP Compaq笔记本电脑有80GB的容量，其实完全够用。但是那时候的重装 Windows XP 系统是非常平常的事情，所以有个移动硬盘来备份文件也是很有必要的。于是在爸妈带着去老家当地的电脑城买下了第一块标志为 IMB 且外壳全金属的移动硬盘，而且我还清楚记得价格是700元整。这块硬盘容量有120GB，当时在寝室里也算是大容量的装备了。

那时候还没有Spotify或者网易云音乐，所以硬盘里装的最多的就是下载的 mp3 音乐（原谅我下载盗版音乐，我也是收藏过很多正版磁带和CD的，但是实在买不起全部）。而且我基本都是整张专辑下载并歌手分类保存，也算构建一个小曲库。这些音乐也一直伴随了我十多年，直到后来在线听歌变得方便。

第二块移动硬盘已经不太记得价格和时间了，好像是大三通过易迅网购的硬盘然后再买外壳组装了一个320GB。其实当时并没有实际需求，只是室友都渐渐组装出了更大的容量，于是我也想着扩充一下。价格已记不清了，但是基本也在700元以内的价位。

这块硬盘里除了音乐，装得最多的就是美剧（再次请求原谅，但是那时候没有正版渠道可以收看这些美剧，到了美国我终于可以订阅流媒体来重新观看）。剩下还有就是课件和项目的整理，有时候还会把网上的文章复制成文件方便离线阅读，但因为都是文本文件，总共加起来不到5GB。

到了美国读研究生的时候，我开始用Apple电脑，而之前的硬盘都是Windows下的NTFS，所以很长时间只能读不能写。那时候开始接触到 Dropbox，大部分的学习文件都同步了上去，所以硬盘里主要还是音乐。还记得当时把mp3拷贝到电脑后，文件名在Mac OS系统里各种显示乱码，找了很多方案才解决了。

渐渐的，生活和旅行照片录像在硬盘里占了越来的空间，就开始考虑买了更大容量的硬盘。另外想着毕业旅行会要留下一些记忆，或者可能要回国发展，于是就在Amazon赶紧买了一个大容量的硬盘。

但是这个硬盘完全没有便携属性，从第一张对比照片就能看出来他比其他硬盘都大非常多，还需要额外的电源供电才能运行，所以特别麻烦。现在看产品名字才明白它并没有欺骗我，这是一个台式电脑的外接硬盘，只是我以为这是移动硬盘。不可否认，这块硬盘后来变成我最常用的，毕竟容量大一块顶两块移动硬盘加笔记本电脑。

随着Google Photos的出现，我手机新拍的照片基本全部都同步。后来买了GoPro，偶尔录制的旅行视频渐渐变成了占硬盘里最多容量的文件。但基本没有出现容量不够的情况。

前两年逛 Costco 网站的时候，看到 5TB 的移动硬盘打折，于是就心动下单买了这第四块硬盘。拿到手后就把前几块硬盘里所有的内容都转到了这块硬盘上。甚至把Google Photos上的照片也全部都下载回来在硬盘里备份了起来。但即使这样也没用掉一半的容量。

这块硬盘虽然没有我第一块硬盘那块小巧，但考虑到它的容量，这便携性和方便性实在让人欣喜。唯一要挑不完美就只能提下数据线是Micro-B，不是我目前最常用的USB-C，当然多用个转接头也不是什么大问题。

回想我买移动硬盘的过程，其实都没有强烈的需求，我不是美术或者视频编辑工作者，也不是什么高清发烧友，所以基本不需要存储体积大或者数量大的文件。另一方面即使是针对高清文件，似乎显示器和处理器才是最关键的设备。

随着各类技术的革新换代，所有东西估计都可以在云端快速存储和访问，目前感觉不会再有买移动硬盘的需求，未来如果需求出现了，我再回来继续分享一下。

So, in this article, I’d like to share some work I found specifically on Protocol Buffer Version 2 that can reduce the method count. If your app is also heavily relying on Protocol Buffer, I hope these approaches are useful for you too.

General Approaches

1. Use Protocol Buffer Java Lite Runtime

Just as the name indicates, the dependency library is much smaller than the regular Protocol Buffer Java runtime, the generated code is also much slimmer. However, the APIs are compatible between those two versions, so the call sites would not be affected when changing the library.

2. Don’t use <Message>OrBuilder interface

For each Protocol Buffer message definition in .proto file, the Protocol Buffer compiler generates an interface named <Message>OrBuilder (<Message> is the name defined in .proto file). This interface would be implemented by the concrete <Message> class and the corresponding Builder.

It might be attractive to use it as a variable type thereby you can depend on abstractions to not concrete classes. But calling methods on Java interface would make Dex take count of those methods.

In reality, every place can directly use either <Message> or Builder, then the optimization tool (like R8, ProGuard) can safely remove the methods declared on the interface.

Special Tricks

Protocol Buffer Java Lite is very good, but if I open the magic box of generated Java classes, I notice it’s still not optimal for Android. There are a couple places I could modify to make it more effective for Android applications.

Instead of copying the Java files and making the change, which is error prone when engineers update the .proto file, I created a script to automate the job. Just add the execution of this script at the end of the Protocol Buffer gradle task, so it works just as a complement of Protocol Buffer code generation process.

[codesyntax lang=”groovy” lines=”normal”]

protobuf {
  protoc {
    artifact = 'com.google.protobuf:protoc:3.7.0'
  }
  plugins {
    javalite {
      artifact = 'com.google.protobuf:protoc-gen-javalite:3.0.0'
    }
  }
  generateProtoTasks {
    all().each { task ->
      task.builtins {
        remove java
      }
      task.plugins {
        javalite { }
      }

      // `getOutputDir()` can only be read during configuration, 
      // so it’s out of action block
      def outputDir = task.getOutputDir(task.plugins[0])
      task.doLast {
          exec {
              commandLine file('protobuf-optimizer.py')
              args outputDir
          }
      }    
    }
  }
}

[/codesyntax]

In the script, I have made the following modification on generated java code.

1. Change the modifier of Builder constructor from private to package

Simply running the sample addressbook.proto from Protocol Buffer tutorial side, you would get a class like the following snippet:

[codesyntax lang=”java” lines=”normal”]

public static final class Person {
    private Person() {}

    protected final Object dynamicMethod(
            com.google.protobuf.GeneratedMessageLite.MethodToInvoke method,
            Object arg0, Object arg1) {
        switch (method) {
            case NEW_BUILDER: {
                return new Builder();
            }
        }
    }

    public static final class Builder {
        private Builder() {}
    }

}

[/codesyntax]

When analyzing the APK file, we could would find some synthetic classes and methods:

This is because the outer class is accessing the private constructor of the inner class. The generated synthetic class would contribute an extra constructor to the Dex file. Therefore, by simply removing the private from Builder(), you can remove such classes and methods.

2. Create helper method to do bit mask check

The big difference between proto2 and proto3 is that the later version has removed has<Field>() method for String and primitive types. If your project is using proto2 and heavily checking the field presences, the following trick would help you on app size.

Proto2 uses bit field to mark the presence of declared fields, those has<Field>() methods have the same pattern:

[codesyntax lang=”java” lines=”normal”]

public boolean hasId() {
  return ((bitField0_ & 0x00000002) == 0x00000002);
}

public boolean hasEmail() {
  return ((bitField0_ & 0x00000004) == 0x00000004);
}

[/codesyntax]

But actually, the final executable bytecode would be more concise if you change the code as below:

[codesyntax lang=”java” lines=”normal”]

public boolean hasId() {
  return checkBitMask(0x00000002);
}

public boolean hasEmail() {
  return checkBitMask(0x00000002);
}

public final boolean checkBitMask(int bitMask) {
  return ((bitField0_ & bitMask) == bitMask);
}

[/codesyntax]

On the method count perspective, this could enable the Code Shrink tool to inline has<Field>(), because it is a one line method call, then you would only have checkBitMask() in the final Dex file.

On JVM bytecode perspective, ((bitField0_ & 0x00000002) == 0x00000002) requires 4 more instructions than checkBitMask(0x00000002). Therefore the more has<Field>() methods you have, the more you would save on it. Even if it’s just a few methods, because they would be inlined, which will be talked about below, there would be no cost.

3. Change Enum to @IntDef

Each Enum type introduces at least 4 methods, that’s why Android Developer Docs recommend to use @IntDef and @StringDef to replace them. But Protocol Buffer follows Effective Java recommendation, and generates Enum classes for message types like enum and oneof.

The Protocol Buffer generated Enum class only has one int value, such Enum is called a CountEnum, which is straightforward to strip out the class and use the value directly. You can use the script to modify it to be @IntDef, but because you can also integrate a powerful bytecode optimizer: Redex, it can complete the work for us.

4. Use R8 Rule -alwaysinline to force inline has<Field>() methods

From Jake Wharton’s blog post, I found this special R8 rule to force inline some methods. Sometimes, method inline could increase the app size as it duplicates the content of the methods. But if we combine the trick 2 in the list, we can see the method reduce very small app size increasing.

[codesyntax lang=”java” lines=”normal”]

# ProtoBuf generated class - always inline hasXXX() methods
-alwaysinline class com.iderzheng.proto.* {
    public boolean has*();
}

[/codesyntax]

两年前，我在 Facebook 完成了100场面试的里程碑，分享一篇对于面试心得讲了讲面试对我带来的个人能力的提升。今年五月，我差不多在一年半的时间里又完成了100场面试让总数达到了200场。接着到了今年十月份，其中一类面试—行为面试(Behavioral Interivew) 我也完成了100场。感觉是个不错的时机来再来写篇文章分享一下，但这次我没有特别心得体会总结，就聊聊一些随意的想法。

美国科技公司对于软件工程师招聘比较常用三种面试形式：写代码(Coding)，系统设计(System Design)，行为面试(Behavioral)。对于大公司来说，他们常年都会很多招聘指标，也有大量的申请人，所以相对于中小公司，在大公司更容易获得面试方面的培养机会。（Facebook内部对不同类型的面试都有内部代号，但是因为不对新人记忆不友好，慢慢开始弃用了。）

当我作为面试者时，我对它们的难易程度排列为：系统设计>>行为面试>写代码。毕竟代码是可以通过刷题来提高的，行为面试也主要是讲自己的故事，而系统设计的广度和深度的把控就比较不确定了。

而当我变成面试官时，从另一个角度排列顺序就变成了：行为面试>系统设计>写代码。这排位主要根据我写面试反馈结论所花的时间来衡量：一般代码面试的结论我需要5-10分钟完成，系统设计则要15-30分钟，行为面试则尝尝花费我30-60分钟。主要原因是行为面试要做的内容记录就很多，次要原因是英文写作还是我的短板。因此我后来只做行为面试来锻炼我自己的英文写作，同时也让我享受挑战的乐趣。

之前的文章我讲了面试在广义层面带来的各种不同的好处，面试了所以不同类型面试后，我想再聊聊各类面试对于作为面试官的软件工程师在公司内的职业发展不同阶段所能带来的特定技能的锻炼和提升。进而让面试者从另一个角度来了解面试的意义和价值。

代码面试(Coding Interview)对面试官最直接的能力体现就是“代码审核(Code Review)”。当面试者完成算法实现之后，面试官就要对提交的代码进行审核查看是否完成了问题需求，代码是否整洁，是否有bug等等。在我做代码面试的时候，我对不同的面试者基本都只问相同的几道题目，即使我已经见到了很多不同的解法，但仍然会碰到面试者给出不同的解法实现也依然有效，就需要我去仔细验证同时要接受不同于我初始想法的解决方案。当公司或者团队规模比较大的时候，代码审核这一工作就是保证代码质量的一步重要流程，所以对于每个软件工程师都应该去参与和提升的技能。

做代码面试也可以锻炼如何向他人发布任务并且清晰表达任务内容的工作。当面试者答不出来或者走到错误方向的时候，还要想合适的办法去引导他们。有时会在初期的电话面试里，面试者的能力水平差别较大，我还会要给他们做知识点讲解和指导帮他们了解让他们不觉得做不出来会有压力，但这种情况基本面试就到此为止了。

系统设计面试(System Design Interview)对面试官的能力要求就在“设计审核(Design Review)”。在大公司里，一般系统比较复杂并且参与研发的人数众多，在增加或修改某个功能的时候就需要通过各类文档来进行沟通交流和记录，其中包括架构提案文档、设计方案文档等等。然后公司里比较资深的工程师们会阅读审核这些文档来提出各类不同修改意见，甚至驳回。系统设计面试差不多就在模拟这种审核会议的场景，面试者就是方案的提出者，面试官就是审核人员。由于每个人背景知识不同，所以关注点也会各不相同。

行为面试(Behavioral Interview)对面试官的能力要求在我看来主要是如何通过几个问题从主观角度挖掘出面试者的内心渴望，并考察是否与公司和团队的方向一致并提供支持。前两种面试的评价都有客观标准可以考量，行为面试的评价则趋于主观，但是当面试官经受过比较好的培训和练习，也能在心中对于特定问题的答案定出一系列的标准尺度。大公司里有晋升和绩效考核，因此管理者们（Engineering Manager）就需要有这种挖潜组员内心渴求和对职业发展的期望。因此对于希望从技术岗转到管理岗，或者刚到管理岗的人会有很大的帮助。对于面试者而言，了解公司的企业文化和工作方式，给出与之相应的答案会更容易得到青睐。

总结一下，对于初中级工程师来说做代码面试最合适提高基础能力，对于高级程序员想再往上升就可以花时间在系统设计面试上，对于想转管理岗的工程师则尝试更多行为面试。

另外，对于在公司里做不做面试官或者做哪类面试，主要看对自身以及团队和公司的成长是否有大的帮助。比如对我个人来说在工作中我已经做了大量的代码所以很快对代码面试失去了兴趣转而做更多系统设计面试，但后来我想转管理岗位，所以就专注在了行为面试上。最近我又完成了对管理岗面试的培训，以提升自己对于招聘管理者的能力对于中级管理职位的了解。

这本书主要给出了7个有效的提问，并且对每个问题做了一种定性。其中前三个提问是我日常跟我的组员做 1-on-1 时一直在用到的，只是因为习惯了我没有强烈意识到我的提问内容，而且显然这些提问是有效的。而另外三个提问则是我的 Mentor 和我的上级们经常会对我用到的，以后我也会更注意使用来获得更多价值。最后一个问题则是一个新鲜的提问，我印象中可能在一些反思会上碰到，但是看完之后我强烈意识到这个问题正是我可以真正寻找到我作为 Manager 的工作价值的一种很好的方式。

在7个主要提问的章节之间，作者也分享了八个提问的技巧帮助读者更好地在提问过程中获得价值。这些技巧也表述的非常的直接，有几个我在过去日常中有使用到而且觉得是非常有效的，所以未来也会去努力掌握其他几个技巧。

我将书的大体内容用XMind做成了阅读总结，把关键的提问和技巧都罗列其中。但是还是强烈推荐大家去

下载 SVG