2017 年 11 月 28 日，还在大学宿舍里的我，提交了 PicGo 的第一个 commit，距今已经 8 年。现在看来，时间是过得真快啊。

如果你不知道 PicGo 是什么东西，也不会妨碍你阅读。从我提交它的第一个 commit 的那刻起，命运的齿轮就已经悄悄开始转动。我的研究生生涯、实习、工作都有它的影子，甚至我自己想要做的事情，我想学习的东西，也受到它很大的影响。

正巧前段时间，前微信的一个同事发的一篇文章《从广深到北美——本科毕业这四年》也让我内心深深地触动。因为我跟他一样，我也问过我自己这个问题：“我想过一个什么样的人生”。

2017.11 ~ 2020.6

PicGo 的诞生

在写 PicGo 之前，我最主要的学习 & 开源的项目是 hexo-theme-melody，也就是我的博客所用的主题。在这个主题上，各种天马行空的想法，感觉很赞的交互、很棒的 UI 我都在这个主题上基于它的风格自己实现了一遍。而在写 PicGo 之后，由于经历有限，这个项目的维护就逐步滞后以至于最后基本不怎么维护了，并由此催生了 hexo 社区另一个很知名的主题 hexo-theme-butterfly ，这个主题是基于 hexo-theme-melody 二次开发而来，也感谢作者把 hexo-theme-melody 放到致谢中。

我是在写博客的时候想要个好看点的主题，就自己写了上面那个开源项目。而你一旦开始写博客就无法避免的一个问题：你要如何往你的博客里贴图。

如果你是用一些平台发布文章，比如微信公众号，它们的后台本身提供了图片上传能力的就问题不大；但是如果你是用 markdown 写文章，那么一旦要传图片，就会比较麻烦。

通常来说你有几种选择：

1. 把图片跟着 markdown 一起上传，用相对路径，比如 [img](./xxx.jpg) 。这种方式的优点是比较简单，缺点是图片必须严格跟 markdown 文件放一起；一旦图片挪窝，就无法加载了；以及可能会因为图片较大，加载较慢。
2. 把图片上传到远端服务器上获取图片的 URL 再写到 markdown 里，通常国内把这种存图的地方叫做图床。这种方式的优点是图片和 markdown 解耦了，可以在很多场合都可以复用；图片本身如果加上 CDN、图片压缩等处理方式的话，会加载更快。缺点是，大部分情况需要花钱买服务，还有可能遇到盗链的情况。但是瑕不掩瑜，优点还是远大于缺点的。
3. 把图片转成 base64 编码内联到 markdown 文件里。优点是图片不会丢；缺点是图片文件如果很大，转成 base64 编码会更大；而且图片无法在其他地方复用。

我自己是采用第二种方式。一开始其实还好，后面发现要传的图片一旦很多，就会遇到严重的效率问题。举个例子，我要在 markdown 里贴一张图片，需要如下几个步骤：

1. 打开我的图床服务商的网站
2. 登录
3. 找到上传图片的地方上传图片
4. 等待上传成功后，获取上传后的图片 URL
5. 粘贴到 markdown 里

可以看到要在 markdown 里贴一张图片，至少需要 1～2 分钟。当时我就在想有没有什么办法能够提高这个效率呢？于是我就在网上找解决方案，还真给我找到了，有一类工具叫做图床工具，就是专门用来解决这个问题的。当时我在 mac 上发现了一款叫做 iPic 的工具非常吸引我：

通过简单的拖拽，就能快速上传一张图片，并且把图片链接放到你的剪贴板里。这样的话，写 markdown 传图这件事情就变得非常简单：

1. 上传图片
2. 粘贴到 markdown 里

从原本的 1 ～ 2 分钟，变成了秒级的操作。这真的让我非常兴奋。不过试用之后发现了一些缺点（当然可能是我的问题）：

1. iPic 默认的免费图床只有微博图床一种，如果我想用自己的图床服务商，需要花钱升级
2. iPic 只支持 macOS 系统，我当时有台 macbook，还有实验室的 windows 机器，所以我两个平台都有这个诉求，iPic 只有一个平台支持，所以我第一条付费的话就感觉比较亏

那怎么办？于是我在当时市面上又找了一圈，但始终没有找到更满意的方案。最后我就在想，这玩意应该也不难，我有前端方面的知识，我是否能够自己写一个这样的小工具自己使用呢？

于是我就开始调研写这个工具的方案 —— 最早本来想学下 macOS 或者 iOS 开发，用 Swift 来写，但是后来想想我之后还是要在 Windows 上使用，就得找跨平台的技术方案。也非常巧，那个时候 VSCode 已经小有名气，它底层的 Electron 框架也已经相对成熟。Electron 能解决我跨平台的需求，又是用我熟悉的前端技术栈来构建，同时发现大部分 iPic 实现的交互，在当时的 Electron 提供的 API 里我基本也都能实现，所以我很快就锁定了这个方案。

于是我就在 11.18 开始边学边写了第一版的 PicGo，现在看来它真的非常简陋，但是已经有了之后版本的基本雏形。

写完第一版之后，我自己感觉还是很好用的，就想着推广一下。我尝试了很多平台效果都比较一般。最后是在少数派上发了一篇《PicGo：基于 Electron 的图片上传工具》 之后，被推荐上了少数派的首页，效果非常明显。我记得很清楚，PicGo 的 GitHub Star 数在上完少数派首页后一下子就突破了 500。对当时的我来说真是无法想象，是非常有成就感的事情。

在接下来的一两年里，我除了在实验室打工以外，剩下的业余时间基本都花在迭代、更新 PicGo 上。同时我在开发 PicGo 的过程中，也在不断学习和总结。我把我的经验、遇到的问题，最终凝聚到了我自己的博客《Electron-vue开发实战》中，这个系列全网的阅读量有几十万。当时国内市面上并没有系统性的 Electron 开发教程，大部分都是 API 文档搬运工。所以我的教程其实影响了很多后来学习 Electron 开发的人。比如 gridea 的作者就看过它并给了好评；比如 rubick 的作者就加过我的微信，他说他是跟着 PicGo 一步步成长的。时至今日，你在谷歌上搜索“electron vue 开发实战”，第一条依然是我的博客。

PicGo 1.x 版本是在不断支持新的图床（比如一开始只有微博和七牛图床）的过程中迭代。这个过程虽然能够一直有事情做，但是市面上的图床服务商那么多，每个都需要我手动做适配，后期出问题的情况下，维护成本高、精力无法跟上，而且 PicGo 会做成一个臃肿的图床服务商的集散中心。但是不做这些图床服务商的支持，又会让 PicGo 的用户群体受限。

正当我在苦恼的时候，一个划时代的 issue 点醒了我，这个用户向我提的意见是「希望能把对各种图床的支持，做成 插件化 的管理。Core + Plugins 这样的做法是否可行？」。可行，当然可行。类似 VSCode 一样，本体管好基本的功能，其他额外的能力让插件做就行。

于是 PicGo 在我开发到 1.6 版本之后，就停止了内置图床服务商的开发，转向了如何实现一个 Core + Plugins 架构的道路上。我之前并没有做过任何插件系统的开发，但是我用过一些带有插件系统的工具，比如 Webpack、VSCode 等。一开始我想着是否能复用他们底层已经实现的能力，比如 Webpack 底层的 tapable 。但是后来仔细想了之后，我觉得 PicGo 的上传图片流程没有那么复杂，用 tapable 的话有种杀鸡用牛刀的感觉。所以最终我还是决定自己实现一份，反正是我自己的项目，就当做学习，边学边写就是了。

开发插件系统之前，最重要的一件事情就是我把 PicGo 抽象出了一个底层的流水线模型，从 input 到 output，然后这里面的每个模块、事件钩子都是可以被插件化的，能够极大提升它的插件自由度。这个模型可以说是奠定了 PicGo 后续迭代的思路和方向，而最终的事实证明，它是成功的，这个我们可以放到后面说。

想清楚这个模型之后，我就开始了边学边写之旅。这个过程其实真的要学习的东西非常多，写一个插件系统要考虑的事情不只是插件系统本身，要考虑很多东西，比如：

1. 插件系统在什么环境下可以被使用，CLI? GUI? Node.js 项目中？进而这个插件系统能否无缝接入我已经实现的 Electron 版本的 PicGo 中？
2. 插件系统文档
3. 插件如何分发、搜索、下载、启用
4. 插件如何开发、调试、提供了什么 API
5. 等等

这里面的每一步都是我自己一点一点摸索出来的。终于，在 2019.6.13 我发布了基于 PicGo-Core 插件系统的 PicGo。在开发它的过程中，我还顺便拿到了当年前往广州微信暑期实习的机会。

实习

因为对象当时还在北邮读书的缘故（对象小我两届，我们之前约好了我在北京工作两年后，等她毕业找工作再一起看看是否要换城市），所以当年的暑期实习我就希望找北京的实习机会。后来就找了学长（非常感谢学长）内推了北京的微信。北京微信之前没怎么招前端实习，正好那年招，我还很开心，就去面试了。但是面完才了解到北京微信当时的那个部门前端就一两个人，思考再三我觉得还是想到一个大一点的前端团队里，所以我最后拒绝了那边的实习 offer。 然后微信的 HR 就找到我问我考不考虑广州微信的小程序前端团队，我在跟对象商量后，觉得实习反正就两个月，到时候回北京再找工作也可以。于是又面了两轮广州微信，接了广州微信的实习 offer。

面试的时候，PicGo 其实给到了非常好的背书，因为那个时候它已经有不少的 Star 了，作为一个在校生，这个是非常强有力的证明，关于它的诞生、迭代的思考我也能侃侃而谈。所以基本上面试官都会对这个项目非常满意——进而对我也很满意。

于是在 2019 年的 6 月底，我前往广州微信实习了。因为有 Electron 的开发经验，所以去广州的团队写微信开发者工具的时候，很多门槛其实对我来说就比较低。我记得当时入职的第一天下午就解决了一个 bug，提了第一个 PR，这也成了我整个实习生涯的一个缩影——天下武功，唯快不破，你就说写得快不快吧，哈哈。

我还记得很有意思的一件事情是，当时实习没多久（大概一周左右吧），组长找我 1-1 聊天，末了问我有啥需求、不满意的地方跟他说，我就说当时只给我配了台性能很一般的联想笔记本（当年实习生不知为何只配了 Windows 的笔记本），写开发者工具的话性能有点费劲。于是他 1-1 结束后立即帮我安排了台性能更好的台式机给我开发。现在想想，当时的我还真敢提需求哈哈。

到了 8 月份，微信的每个实习生都要进行一个转正答辩。上面说了，因为对象在北京读书，我当时一直是想着回北京找工作的，因此我“毅然决然“地拒绝了微信的转正答辩流程（现在回头看，我当时也是很牛的，拒绝了转正）。为此我的组长和我的 mentor 也没少找我谈心，希望把我留住；不过我最终还是决定回北京找工作。他们最后发现拗不过我，就祝福我了。在我实习最后，全组人还一起吃了顿饭来欢送我，当时真的觉得组里氛围真好，也挺不舍得。不过我还是按原计划结束实习，回到了北京。

秋招

回北京后就开始紧锣密鼓地准备秋招，其实在微信实习之后，我觉得只是写页面的前端部门已经没啥意思了，我希望能够接触泛前端的一些技术栈（比如 Node.js 工具链、全栈、跨端等），而不只是做页面切图仔。现在想想，可能正好对上了后来前端很流行的一个词叫做「大前端」。所以北京很多公司的前端部门都被我 pass 了，我当时最想去的是字节飞书，去做 Lark 的桌面客户端。

面飞书前，我还面了猿辅导，面试过程其实很顺利。我记得在国庆前后吧，就拿到了 offer。但是当时给到的 offer 低于了我的预期，所以我其实并没有立即决定要去猿辅导。当年猿辅导给钱多，还 10-7-5，在北邮内部的口碑非常好。其实要是猿辅导当年给的 offer 达到我的预期，我可能真的就去猿辅导了hh（但是后来没过两年国家就出台教培相关的政策，猿辅导不幸中招，也裁员了很多，这是后话了）。

面完猿辅导之后，我就托了北邮的一个学姐（非常感谢！）帮我内推了飞书的部门，正好是我想去的主端的部门。飞书的技术面有三轮，在现场，一个下午全部面完。我记得挺清楚，我的一面答得挺不错，先笔试后面试，我感觉能给到 90 分。但是我的二面有好几个问题卡壳了，我感觉只能给 50 分，本来以为已经结束了，结果还有三面。三面的时候，我感觉答得中规中矩，又是 PicGo 的经历救了大命，这一轮我感觉可以给到 60 分吧。

于是面完飞书，就开始了漫长的 offer 等待。这过程中因为猿辅导已经发了 offer，但是因为低于预期我不想去，而字节还迟迟没出结果，内心其实是很焦虑的，考虑到二三面的情况，我担心字节的 offer 是凉了。我对象看在眼里其实也挺难受，所以我们在一起聊天的时候，她不断提起说「不然你再试试微信吧，那个团队你不是挺喜欢的么」，一开始我其实是拒绝的，因为我不想违背我们一开始的约定；而且微信我拒绝人家在先，我也实在没有什么脸舔回来。

不过这个世界就是这么神奇。在我等待字节的 offer 快一个月之际，微信的 HR 找上来问我是否还考虑之前实习的团队？当时我已经明确放弃了猿辅导的 offer，而字节的 offer 又迟迟等不来，身边的同学们都已经收到 offer 并且有些同学已经签了，这种感觉确实还挺煎熬的。

等待的过程中，之前认识的一个在快手（现在不在啦）的大佬 TX 非常希望我能去他们团队。我跟他说，他也知道我大概率两年后等我对象毕业后就会离开北京了，他说没问题，来面面先。经过他不断地游说，我还去面了快手，面试体验也不错。最后虽然非常抱歉，还是没有去快手，不过感谢 TX 一直以来的指导和鼓励，非常有帮助。

有一天晚上，我跟对象在学校操场散步，我提到说微信 HR 又找我问是否还考虑微信的事情，她就问我说你喜欢那个团队么？你想做那个团队做的事情么？那个晚上我们坐在操场旁边的看台聊了好久，我们最后都哭了，但是我们都认为微信那个机会挺好的，还是去争取一下吧。

于是第二天，我跟微信 HR 回复说“我考虑了可以再试试“。由于我之前实习的时候已经面试过微信，并且在组里实习表现也不错，所以这次我可以跳过组里的面试，直接走两轮面委（微信的面试委员会，都是级别比较高的大佬）。我记得面委面试的时候，没有想象中那么困难，更多地就是聊天，谈项目经历。可能我在微信的实习经历算是个比较大的背书，所以面委并没有什么很困难的问题，两轮面试在一天内就结束了。第二天，微信 HR 就马不停蹄地给我发 offer 了——还是非常有诚意的，给了当年的 SSP offer，并且入职就是 6 级工程师（腾讯当年一般本科生入职是 4 级，研究生入职是 5 级，我相当于高一级入职），收到 offer 我还是很开心的，跟对象分享了这个消息，她也非常开心，终于拿到了秋招满意的 offer 了。我当天就接受 offer 了。

不过这个世界就是这么神奇（x2）。 在我接受微信 offer 的第二天，字节的 HR 也终于打来了电话，跟我说我的 offer 下来了。我当时的心情变成了 🤨 这样，我就跟她说了昨天微信已经给我发 offer 了，字节的 offer 等了一个多月，实在太久了。她说“因为字节今年内部有些调整所以很多 offer 审批就慢了。不过你也可以听听我们的 offer 吧。” 字节也给到了当年的 SSP offer，甚至能给到北京户口（当年还没有计划单列，所以北京户口是非常珍贵的）。不过因为我从一开始就不打算留北京（从上大学开始，我就不打算留北京），所以北京户口在我这里其实不是加分项，而是减分项——我一旦接受户口了，反而会让我离开的时候很麻烦（比如要交违约金、影响后面几届的学弟学妹等等）。从结果上来说，字节给的 offer 其实是比微信更多的，不过那个时候我心里有点纠结，因为在微信实习过，对于微信的团队我很喜欢，所以对于字节的 offer 我还有点犹豫。于是我跟 HR 沟通说，我可以去字节实习一段时间，再做决定，HR 很爽快就同意了。于是 2019 年底，我就进入字节的飞书部门开始实习了。

在当时，我已经知道飞书是一个很好用的办公软件，所以我还蛮期待在里面的工作体验。我入职的时候发现我的 mentor 就是我的一面面试官，还蛮惊喜。我的 mentor （后面简称他叫 FQ 吧）也是个很厉害的人，想要啥就自己去争取。他早年是去了国企，结果发现干着没啥意思，就自学编程结果来了字节。我入职的时候，他负责的部分是飞书的插件系统，这个是个还挺重要的部分。我作为他的小跟班，入职之后我就努力在做代码的阅读理解，因为他就坐我附近，所以很多时候有问题我就能立即请教他。他对我始终不缺夸奖，总是夸我上手快，做事情认真。以至于我们那个大组其他同事见到我都是说「听说你是 FQ 那个很厉害的实习生」，非常感谢他的认可和培养。

我记得很清楚，实习的时候还有个美国小哥坐我旁边，中文说得非常流利（印象中好像他是哈佛毕业的），来中国不能说是体验生活，但是来字节可以说是体验工作了哈哈，他拿着中国的工资过中国的生活，跟大家也相处得非常愉快。他跟我负责的东西不是一个方向的，不过我们平时还是会经常交流。他甚至还组织了（哈哈当然我不知道是他主动的还是被其他同事“怂恿“）一个英语角，每周都会有一个晚上，大家找一间会议室，然后边吃饭边用英文聊天。一开始我还不好意思，但是后来他鼓励我如果感兴趣也可以来参加，于是我后来也参加了好几次，还是挺有意思的。

在字节实习的时候，感觉其实也不错。不过有一点确实能感觉到部门太多，部门和部门之间的部门墙有点高。以我做的插件系统为例，我们需要接入飞书除了 IM 以外的其他模块，比如日历、邮件等等，他们会依赖我们的一些 API，所以一旦要做优化、改版之类的，就会频繁遇到上下游沟通协作的事情。当时的我还是实习生，感受不深，但是好几次 FQ 去开完会回来都是摇头、叹气。现在想想可能有很多事情他也无法左右吧。

毕业季

临近春节的时候，发生了一件后来影响全世界的事情——新冠疫情。我还记得当时我在飞书的工位上看到一则新闻，大概是武汉出现了不明传染病，那个时候还不知道这个事情会影响这么深远。以至于我那次从北京回家的时候，行李都没带多少。结果没过两天，武汉就封城了，学校后来也通知不要回去了；于是我就在家里改毕业论文、远程在字节实习。（划重点，这里是我第一次远程工作，以后要考）

疫情在家的那半年，每天就是上班、吃饭、睡觉。也无法出门，也没咋运动，真的是我有史以来长胖最快的一段时间，我体重一度到了 74 kg（我正常的体重大概是 65 kg 左右），整个人从轮廓上胖了一大圈。我一度怀疑我是不是从此以后就无法瘦回去了。事实证明我多虑了，我现在的体重又是稳定在 65 kg 左右了。

我在字节的实习也在 5 月份落下了帷幕。期间在字节的组长也找我聊过两三次，希望我能留下，不过最终思考再三，我还是决定去微信。在告别了字节的同事们之后，我就开始准备毕业相关的事项，以及广州租房的事情。

我依然联系的是实习的时候在广州租房的那个房东（他也是个二房东），而且还专门跑了广州一趟看看房子如何。2600 一个月，合租的一个单间，能看到广州塔；其实感觉是有点小贵，不过当时腾讯给应届生是有 1500 一个月的房补的，所以算下来就还行，能够接受，最后看完房子就签了。

后来临近我要入职的时候遇到一个坑爹的事情，那个房子因为地板漏水被楼下的业主投诉了，导致我租的那个房子里的租户都要搬走，业主要拆地板修漏水。临近入职遇到这个事情一下子打乱了我的节奏，如果没处理好我到广州可能还没地方住，非常闹心。二房东手上没有更好的房源了，于是我只能在网上看那种连锁的租房平台，比如自如和蛋壳。当时正好有个已经去广州的北邮同学（他也是入职微信），我只能不好意思请他帮我看看公司附近的一个蛋壳公寓上的房源如何。最后他通过微信视频带我远程看房，并最终敲定了，非常感谢他🙏。当然这里租的蛋壳公寓，半年后就暴雷了，这个后文再说。

那年因为疫情，无法返校，没有毕业典礼，甚至我的行李也只能拜托我的舍友帮我把最贵重的一些东西邮寄回来，其他的很多东西都被我舍弃了；也因为疫情，没法跟对象见一面。在这种有点遗憾的背景下，我只身前往了广州，正式开始了我的工作生涯。

2020.7 ~ 2023.1

我在微信期间的经历，大致可以分为两个部分——一个上半场，一个下半场。上半场的工作虽然累，但是成就感非常高，我在其中也连续得了两次高绩效；下半场的工作，成就感开始逐步消失，取而代之的是对所做事情的价值的怀疑，以至于我最终做出了离开微信的决定。

上半场

我很喜欢微信在 TIT 创意园的办公点，都是矮楼，不用等电梯；平时可以在园区里散步，风景很好（毕竟本身也算是个景点了），跟同事们饭后散步绕圈、聊天、八卦是当时工作之余非常向往的事情。

由于我当时入职的时候职级就比正常硕士生高，所以组长对我的要求和期待也会更高一些；不过当时入职之后，我发现比起实习的时候，要接触的事情、概念比我实习的时候多了很多，同时组长又交给我一个比较复杂的任务，于是第一个月我成了问题小伙，有不懂的东西就到处问。微信在文档落地这点其实做得不太好，大家都不爱写文档，很多东西都是口口相传，如果我不问，我可能就一直不知道。

不过做开发者工具的日子没过多久，我就跟另外两个小伙伴被调去支援另一个组的工作，他们那个时候做的小游戏引擎项目正在上升期，极度缺人。不过他们做的事情跟我们组做的开发者工具还是有较大差异的，所以当时其实我们三个人压力都挺大的，每天都要加班到挺晚，只为补足欠缺的知识，以及能够快速帮他们解决一些问题、做一些需求。

我其实有点忘了当时我是怎么度过那段时间的了，现在想想还是很不可思议。虽然解决问题的时候成就感还是很高的，不过确实不算是感兴趣的东西，所以我到现在已经忘记了很多当时做的项目、专有名词。我只记得当时做项目期间，跟同事一起追美股 GME 的惨痛回忆哈哈。第一次绩效考核的时候，由于在支援的项目做得不错，还拿了个高绩效。

这中间还发生了另一个坑爹的事情。10 月底的时候，有个同事问我说「皮蛋你是不是住的蛋壳公寓」，我说是的。然后他就转发了一个文章给我。我看了下是深圳的蛋壳公寓有些租户发现蛋壳公寓的一些服务（比如无线网络、定期保洁等）开始出问题了，客服也无法及时解决问题。它的微博也只是一味在说自己没问题之类的。当时我住的那个蛋壳公寓倒是还没遇到前面所说的那些问题，但是我看了不少深圳蛋壳的租户已经在网络上发帖各种问题，感觉还是有点风险。因为我也快到了续期的时候（此前我是交了半年的房租，因为当年有个活动是一次性交半年能免一个月房租，所以实际是交了 5 个月房租），想到一续期就是半年起步，万一这真的暴雷了，岂不是血本无归；于是我赶紧想着不续租了，看看不然换自如，因为当时看自如还是挺稳的。正好同小区有另一个房源自如正摆上了货架，价格跟我当时租的蛋壳差不太多。于是我马上约了看房，并且看完觉得还不错，所以我就立即做了决定要换租；当时我对象还觉得我做决定有点太草率了，我当时也觉得有点着急，但是我想着毕竟不能赌蛋壳没风险，就宁可亏半个月的房租，也要换租；因为是同小区，所以那次我就自己打包了所有的行李，叫上我几个好朋友一起帮我搬家，完了之后请他们吃了小区门口的陈记顺和，那顿陈记顺和是真好吃啊。后来蛋壳就真的暴雷了😂。

过完年回来之后，我就逐步从游戏引擎项目抽身，开始做小程序真机调试的一个架构升级（也就是后来的真机调试 2.0）。其实一开始这个东西，我们也不知道能不能做成（只有基础库的一个理论实现，但是没有实装），有没有什么坑，所以一开始组长只是让我去做做看。我们要做的架构升级，其实当时市面上并没有第二家做过，所以我是没法摸着石头过河，我只能自己做过河的人。这个项目涉及到跨好几个组、部门的同事。说实话，毕业不到一年，我需要自己去找各个上下游（尤其要协调微信客户端同事的资源）来跟我一起确定方案，联调，发版等等，现在想想我当时还挺牛。这中间的坑就不多说了，每一步都是坑。为了能够确保跟他们能联调上，有问题可以及时沟通，我甚至有段时间只要一旦他们开始能够跟我联调之后我就坐到他们旁边，跟他们结对编程。

我记得有次我跟 iOS 的客户端同学，查一个问题在 TIT 查到了凌晨。在最终基本定位到问题之后，我们还点了夜宵烧烤在工位上吃完才走。非常感谢 iOS 这个同学，他跟我一样当时都没有额外的怨言，我们就是想在那天把那个问题解决了，解决了之后 iOS 这侧就彻底跑通了。那种纯粹为了解决问题，解决了问题又得到纯粹的成就感的感受，到现在还印象深刻。

终于在这个项目开始 3 个月之后，终于跑通了第一个 MVP。后来经过一些性能优化、问题修复之后， 21 年 7 月正式发布到线上。到现在，这个真机调试 2.0 的整体架构还是没有发生非常大的变化，依旧还在运行。现在你所用的每个微信小程序，都需要经过它来进行真机调试。后来借此还去了趟 T Web 做了个微信小程序真机调试的技术分享，这也是我第一次做讲师做对外的技术分享。

下半场

22 年开始，可能是受疫情的影响，整个互联网的氛围突变，降本增效成为了当年的主旋律。这对于微信或者说对于我们部门的影响主要有两个：

1. 裁员，基本每个组都有裁员指标；甚至有些是整个部门、中心裁员。
2. 各部门、各个中心需要「自负盈亏」，需要做可以盈利的项目

我们组也有裁员，有个跟我挺要好的同事（当时跟我一起支援去做游戏引擎的一个同事）是正好自己想走了，所以拿着裁员补偿就走了。后来他玩了半年，也挺爽的。对于这种自己想走的，裁员反而不一定是坏事。

留下来的人就得经历上面说的第二个影响了：需要做可以盈利的项目。这对于我们这种做开发者生态的团队，在当时（如果当年 AI 发展像今天，可能就好说了）是非常难盈利的。开发者众所周知都是「一毛不拔」除非真的能解决他们的痛点。因此开发者工具、开发者社区等我们组负责的项目在当时就被认为是不赚钱的项目，就要被削减人力，减少维护成本，转而去做盈利的项目。

但是要做盈利项目谈何容易？这个要求是自上而下传达的，要做什么却变成是自下而上去想的。我不反对有些创意可以从一线员工发起，但是我认为在当时那种情况应该是掌舵人给出方向更合理。最终我们组拉了个大会，要做个付费的开发平台，里面聚合了几种看着毫不相关的子产品：

1. 多端开发（小程序转成 App）
2. 微信网关
3. 用户行为分析（无埋点）
4. 身份管理（后来并入多端）

同时为了跟微信撇开关系，这个平台的名字还不能跟微信有关系（我也没想懂这个是为啥，可能是觉得不跟微信沾边更能盈利？）。最后名字被定成了一个非常奇怪的 「Donut 开发平台」。

这个东西槽点太多了，我从一开始就觉得这玩意成不了，至少盈利不了。现在回头看，确实没成，它的研发成本远远远远大于用户付费的收入，以至于最后 Donut 开发平台现在已经不维护了；里面的一些能力被并入了现在的微信开发者平台，而且也取消了盈利的目标。

接下来我说说我自己粗浅的理解，为啥我从一开始就觉得这玩意成不了。因为我看到要做这个平台的时候，我问我自己的第一个问题就是：这个以盈利为目标的平台的目标用户到底是谁？

把这个四个子产品拆解一下：

1. 多端开发。目标用户肯定不是大商家，因为大商家基本都会有自己的 App。所以只能是小商家。
2. 微信网关，目标用户肯定不是中小商家，因为微信网关收费很贵，所以只能是大型商家才能负担得起；同时也只有中大型商家才有对安全、速度等有相对高的要求；小商家用户量都没多少，为啥要花钱买这个？
3. 用户行为分析，目标用户也肯定不是大商家，因为大商家一般都会有自己比较完善的埋点上报用来做用户行为分析。所以只能是小商家。
4. 身份管理，这个不表了，因为这个后来做着做着也非常怪就并入多端，作为多端项目登录的一个解决方案了。

所以可以看到四个产品其实是各自为战的，并不是 1+1+1+1 > 4 的，甚至是 1 + 1 + 1 + 1 < 4 的感觉，我很难想象有哪个商家能够同时把四种服务都付费用起来。而且既然是做个盈利的项目，目标用户不清晰，就很难做商业化、推广。甚至我们也没有专门的售前、售后团队，微信一直没有客服基因，我实在想不出怎么能够把这个项目做到盈利。

但是一旦这个项目的定位不是做一个可盈利项目，而是作为微信开发者生态的补充，那么很多事情就能说得通了；它就变成了一个小商家，利用微信开发平台提供的能力，逐步成长为一个大商家的故事。可惜很遗憾，当时的定位决定了它做不成。事实也证明，这个平台如今已经被放弃维护，这里面的项目不再以盈利为目的，而是重新变成开发者生态的补充，并入了微信开发者平台。

因为 22 年降本增效，好几个同事要么被裁员，要么自己离职，导致有很多事情最终都交接到我这边。我一边要做新的开发平台，又要接手很多维护的事情。所以在 22 年一整年，我做的事情就非常杂，而且我也做得很不舒服。年初定的 OKR 根本没有参考意义，因为做的事情跟计划差距太大。

我记得 22 年上半年的时候，各地的健康码为了避免在大批量验码（比如做核酸检测）的时候宕机，都被要求 QPS 达到多少多少。因为当时我们有个小程序压测平台，他们就会用这个东西来测他们的健康码的性能。这个平台正好交接到我手上，所以我有好几个半夜（因为健康码只能在半夜进行压测）都得跟这些政府的健康码团队一起联调压测的问题。但是这些辛苦的付出，其实只有我自己知道，有次我跟组长提过一嘴，但是也只是得到了一声笑笑。

到 22 年底的时候，一方面我有太多要负责的杂事、一方面主线要做的项目又不能拉下，但是这个项目又让我很难认同用户价值，我的整个工作状态已经变得非常差。正好那个时候又遇上疫情反复，我们也都居家办公了，我发现居家办公的时候，我的效率相比在工位办公的时候还更好。我从那时起开始思考我是否要继续留在微信了。我抽空开始写简历，开始刷题练练手，但是我始终没有把我的简历投出去，因为我还想着等着年底答辩之后再说吧。

压死骆驼的最后一根稻草，便是 23 年 1 月初沟通绩效的时候。我觉得我这一整年在我负责的所有事情上（尤其我接手了好几个同学的事情）都做得很好（虽然主要的项目我不认可，但是我还是尽我所能做好它），应该能够拿一个好点的绩效去答辩（当年的答辩，绩效分占 60%）。那次不少其他的同事也觉得我应该能拿个好的绩效。结果组长沟通完，还是拿了个普通绩效。在我听到绩效结果的当天，我就决定去看看外面的机会，并投出了我的简历。

而这次投简历，我有两个原则：

1. 我希望是远程工作，因为我觉得我远程工作效率更高
2. 我不想去大厂，我想去创业公司，我想了解业务、创业公司是怎么盈利的

当然原则一可能已经限制了很多大厂是没法提供给我远程岗位的，正好匹配上第二条规则。其实一开始我对象听到我想找的是远程的工作，还是很担心我找不到的，她建议我如果找一段时间没找到的话，还是找正常的非远程的工作岗位吧。我跟她说就试试 1 月份能不能找到，如果找不到我就找非远程的岗位。其实一开始的一两周，投出去都没有什么水花；直到一天，我投递的 MoeGo 正好缺前端，他们也愿意给优秀的候选人远程工作的机会，于是我就抱着试一试的心态去面试了。

临近月底的时候，我已经拿到了 offer，并且薪资也是在我预期内的。拿完 offer 不久，就到了年终的沟通（腾讯的年终沟通在过年前），我发现我虽然拿的还是普通的绩效，但是我的年终可以说是垫底的水平也不为过（甚至不如我刚毕业的那年的年终）。因此从那刻起，我就下定决心要离开微信了，我觉得我的付出并没有得到认可。

于是，年后回来的第一天，我做足了心理准备，就向组长提出了离职。组长其实还挺惊讶，因为他从来没想过我会提出离职。他觉得大环境这么不好，能够在微信有份工作已经是很好的一件事情了。但是我觉得在这里继续待下去，我已经无法学到我想学的东西了。在微信，如果一个项目做黄了，再做另一个项目就是了，毕竟微信能养得起。但是我理解如果我们是个创业团队，我们可能活不过三个月，我想去了解创业公司是怎么思考问题的，怎么做到养活自己的，怎么做到盈利的。所以我在跟组长聊完，还没等他跟总监说的时候我就在系统里发起了离职申请。总监当然也很惊讶，也找我沟通，也想挽留我，甚至说可以争取保我这次晋升。但是同一时期我另一个同事他表现也很好（也是当时跟我一起去支援游戏引擎的另一个同事），晋升名额是有限的，我不希望因为我导致他这次又无法晋升成功（他上次已经失败一次了），所以我跟总监说，我不想要这个名额，把名额给他吧。不过最后这个同事也没晋升成功，他后来在我离职后不久也主动离职了，现在是另一个公司的扛把子，这就是后话了。

我离职的时候，我的工作拆散交接给了 8 个同事。二月底，我正式离开了我工作了 956 天的鹅厂。

开心的事

当然，这几年里也有不少开心的事情。22 年 6 月的时候，我跟对象买房了，需要 24 年才交楼（现在看看可能是站在了最后一波高峰，哈哈），但是至少确定了我们的小家；国庆回家订了婚，然后回广州后就跟对象领证了（那个时候我们已经谈了 6 年了），终于可以叫老婆了。

PicGo 在这个期间里更新到了 2.3.1 版本，GitHub start 19k+，下载量达到了 640k+；成为了 Typora 、Marktext 等文本编辑工具官方支持的图片上传工具；腾讯云官方推荐的图床软件；社区贡献的插件数量也到了 50+；我想，作为一个我只能业余时间抽空开发的项目来说，它已经远远超出了我的预期。

微信小结

说实话，在微信这几年也学到了非常多东西。一个从来没接触过的东西，需要在很短的时间内上手、解决问题、开发需求等等这些能力，在微信这里我觉得还是得到了相当程度的锻炼。尤其在当时没有 AI 编程工具辅助的情况下，这些真的就是综合素质硬实力的体现。在前端领域，微信小程序的前端可以说确实算是国内前端工程师的天花板级别的水平（虽然对外的一些功能或者产品被用户吐槽甚多），研究的东西非常之深入，经常要跟客户端、Chrome 源码等打交道。在其他很多公司，遇到难题想到的一般是绕过去，但是在微信小程序这里遇到难题基本上是要跨过去。而且很多时候我们在做的事情，是市面上没有地方可以参考的。比如我做的真机调试 2.0，比如我们需要把 VSCode 这个 Electron based 的编辑器整合进 NW based 的微信开发者工具里。所以在这里，前端的技术深度是绝对够深。

不过可能也因为对于技术深度得过分追求，对于产品价值的把控，对于用户的使用体验等等就会有所欠缺。在微信小程序，前端如果只会写 Web 页面，是非常容易给低绩效的。在这里一定要做出有技术深度的东西才行。在早期，技术能够解决用户问题，能够带来实际价值，尤其小程序的很多创新需要技术支撑。但是后来随着时间的推移，low-hanging fruit 已经被摘得差不多了，就开始内卷了，大家不得不开始做一些为了追求技术深度、为了晋升答辩而做的事情。但是技术深度其实不等于用户体验、产品价值。这也是我在微信后半程做事情的时候发现越做越怀疑自己的一个原因。我们很多决策并不是建立在用户调研的基础上，而是「我觉得用户需要这个，我觉得用户会用这个」这种方式去做产品。我在做 PicGo 的时候发现真正好的产品，是愿意倾听用户的。所以在微信这个环境下，我发现我很难能够跟用户走得更近，而我下一阶段想要学习的东西，需要换个地方了。微信就像是个围城，里面的人想出来，外面的人想进去。

总之，感谢在微信的经历，在这里跟很多很厉害的大佬们学习了非常多知识，掌握了很多技术以及学习未知的方法；也感谢我自己愿意迈出这座城，我收获了很多同事的友谊，也得到了很多的帮助，感谢你们。

2023.2 ~ 2025.11

在美国，宠物服务的商家分成好多种类型。比如 Grooming 就是提供宠物剪毛、洗澡这类服务的商家。它们又分成了 Salon（开实体店的）和 Mobile（开着房车的，如下图），尤其后者在美国是一种非常特别的商家类型，买或者租一辆房车，就可以开始自己的 business。 MoeGo 做的事情就是给这些商家提供电子化的平台（Web & App），方便他们管理自己的日程、员工排班、收发顾客的消息，以及对外提供在线预约的网站等。美国的人工很贵，做一次剪毛、洗澡可能就要大几十上百刀。而 MoeGo 的一个月订阅费也不便宜，也要几十到 200 多刀，在国内这个事情不敢想。但是如果使用了 MoeGo 之后能获得更多的订单，可能一单就能回本。所以从这样的角度看的话，商家用了之后生意变好了就会愿意继续续费下去。同时 MoeGo 不仅做 SaaS 订阅，还自己做支付方式，可以根据商家的交易流水抽点，所以商家生意做得越好，MoeGo 的收入也会越高。这些也是我认为 MoeGo 的商业模式能说服我的原因。

从微信离职后没几天，我就入职了 MoeGo。根据一开始跟 HR 的协定，我需要去深圳驻场办公一个月，熟悉一下工作、同事等，然后才能回广州远程。公司那个时候人还不多，就几十个人，其中还有一部分同事是在美区的。因为人不多，所以深圳的办公点我们甚至一开始还是租用的类似共享办公室的场地。不过虽然硬件条件跟微信没法比，但是公司里每个人给我的感觉都是朝气蓬勃的，我想这个可能就是创业公司的氛围吧，我觉得我应该是来对地方了。

我来的前两天主要在熟悉公司的各种文档，以及了解我们的代码仓库、提交、发布流程等等。不过因为有微信的历练，所以这些东西我上手的速度很快。我在第三天的时候已经修复了一个线上问题，第九天的时候已经发布了一个需求，而这个需求是当时产品和设计师特地要等我入职后给我做的需求。我的上手速度远超她们的预期，以至于她们都没准备好我下个需求。所以在没有业务需求的时候，我就干起技术相关的东西。我发现 MoeGo 的一些基建有可以改善的地方，我就自己花时间做了一些技术重构。

其实来 MoeGo 之前，我的面试官（后来也是我的 mentor，不过在 MoeGo，mentor 叫做 buddy，会更亲切点）问过我一个问题「你是更愿意做技术，还是更愿意做业务呢？」我说其实我没有什么偏好，我在微信主要做技术，我来 MoeGo 我也愿意做业务。

从 IC 到 Manager

3 月初的一天，我的 leader 把我喊去 1-1（每个新人入职基本他都会 1-1 一下）。所以本来我以为就是普通的一个 1-1，聊聊入职感受啥的。但是没想到他说“这次呢还有一个事情，招你的时候，是打算招个前端 manager 的。” 我说我在面试和 offer 阶段都没有收到过这个消息，还是有点惊讶的。然后我也说我之前没有做过 manager，不确定能不能做好。他鼓励我说没关系，可以慢慢来，我们觉得你可以做好。然后就跟我聊了下我后续要负责的业务和团队，对我的预期等等。

1-1 后，我跟我老婆说了这事，其实当时还是蛮激动的。不过说实话我之前没有当过 manager，我也真不知道要怎么做。不过我想清楚的一个事情是，我不希望做成以前我遇到的 manager，我希望我能够对我的组员负责，能够帮助他们有所成长。

一开始我的团队加上我只有三个人，我们主要负责了两个方向，所以大概是其中一个人负责一个方向，我和另一外一个同学负责另一个方向，同时我还兼顾团队管理、项目管理、技术选型等一系列工作。这个阶段里，我其实对于 manager 的认知还没有那么深。因为人少，而且创业公司业务发展快，所以我并没有就做成了一个甩手掌柜，也是深度参与了一线开发。在 23 年一整年，我写的代码量，大概是整个微信时期的好几倍。当然因为业务不一样，所以代码行数并不能说明太多，但是至少那段时间我觉得我工作还是很开心的，我的产出也一直很高效。我觉得做的东西有用户在使用，并且每周我们还有内部的一些 post，能够看到用户真的很喜欢我们的新功能。那个时候成就感真的很足。

后来没多久，我就成了面试官，参与公司的前端岗位的候选人面试。这也是我第一次做面试官，为此还旁听了好几场的面试，最后大概了解了面试的时候需要考察候选人的内容、标准。23 年入职的前端工程师，大部分都是我面试通过后拿到 offer 的，为此我自己私下感觉还挺自豪。

一开始，公司还没有严格的绩效制度，也没有职级。正常表现的话，年底的年终就是按合同上的发满 3 个月，所以其实整个公司的氛围还是挺好的，很难和卷这个字眼挂上钩。但是不卷不意味着大家都躺平，相反，大家基本上都是很有责任心的，哪怕公司规定的下班时间是 6 点半，还是有不少同学因为项目进度会主动留下加班，只为项目能顺利上线。

后来出了个事情，让我对 manager 这个岗位，有了更深刻的认知。有段时间有其他团队的不同同学都通过直接或者间接的方式跟我反馈我团队里的 G 同学跟他们合作的时候表现不太好，他思维太过发散，经常很多开会决定的事情他在做的时候又要发散一下，导致做项目容易 delay，以至于有些同学一听要跟他合作就头疼。不过因为他跟我直接合作一起做过一个项目，我对他整体的技术背景、为人处事态度都有所了解。所以我觉得这个同学还是有机会能够改善的。于是我跟他开始了不定期的 1-1，跟他沟通了问题，我也给出了我的一些解决方案，然后我跟他一起尝试从后续每个项目开始做改进。同时，他自己也意识到了同样的问题，他对我提出的点也非常虚心的接受，也跟我一起想办法去做改善。半年后，他已经是大家认为有十足进步的同学；从 24 年到今年他已经拿到了多次高绩效。这个事情应该可以算是我在 MoeGo 当 Manager 的一个缩影，我跟 G 同学一起合作变好的这件事情给了我很大的鼓励，我觉得我真的帮助了我的组员变得更好，而且我也有这个能力。

再后来，有次去深圳跟组员们一起聚餐（在此之前我们公司聚餐基本都是先用当时一年一人 200 的经费团建，经费用完了就 AA），那一次我觉得作为组长，请大家吃顿饭应该是很正常的事情，所以我那天饭后就把单付了。当大家后来得知是我请客的时候，他们甚至觉得不应该让我出钱，应该让公司出钱😂，以至于他们最后甚至又重新把饭钱汇总了还给我，说「这次不算，大家之前都说好是 AA 的，下次你再请我们」。我老婆听到这事情之后，都震惊了，怎么还会有组员主动不要组长请客把钱退给组长的。那一刻，我还是挺感动的，我觉得我对大家真心的付出，大家收到后也会真的爱我。当然后来我跟他们说好了下次去深圳，请他们吃饭，最后我们一起吃了顿挺好吃的烧烤。

23 年下半年开始，随着公司不断有新人入职，组织架构变大，公司要开始研究绩效制度，开始研究职级、绩效制度。我们这些小组长有段时间每周都要被拉去开会，商量什么样的职级、什么样的绩效制度等等。因为大家之前也没啥经验，也基本就是依葫芦画瓢，然后再根据我们公司内部的情况，做一些调整。最后出来的方案，其实从我的视角来说还是个比较能让人接受的方案。不过最终在后来都被推翻了。

持续大半年的项目

23 年底，有个非常大的项目，关乎着 MoeGo 是否能从服务单店的模式扩展到服务多店甚至是连锁店、加盟商这种 enterprise 级别的商家。为此我们需要对整个系统，从底层的数据模型，到上层的 UI 界面都做非常大的重构，来支持 enterprise 级别的商家，而我被分配做这个项目的前端 owner。说实话，我一开始其实并没有想到这个东西的面积和复杂度会如此之大，以至于产研一开始的计划甚至是 24 年农历新年前能够完成。

一开始这个项目只有我一个前端在介入，因为其他人需要把手头的需求了结之后才能投进来。这个过程中我除了要做已经明确的重构需求之外，我还需要把整个系统需要改造的部分摸清楚，划分清楚哪些模块要做什么样的改造；从而到时候有其他同学能够来一起参与需求开发的时候能够知道做什么，怎么做。

这个对我来说其实还是蛮有挑战性的一件事情，因为以前大部分时候我基本上要么是自己独立开发，或者就是跟一两个同学一起合作开发，做的事情都比较独立或者聚焦。而这次我需要协调公司里几乎一半左右的前端同学一起完成这个非常大的项目。我们的项目里又经常有牵一发动全身的模块，改一个地方可能很多地方会受到影响，就像一张蜘蛛网，近看是根线，远看是个网。其实身处其中的时候还没有这种很强烈的感受，因为我就是当做一个需求在推进。等到做完第一个里程碑之后，我才回过神来，原来我已经做到了。

这个项目持续了大半年，我们最终分成好几个阶段交付。虽然跟一开始的预期差距有点大，但是至少我们在年前完成了关键的里程碑，意味着我们已经可以迁移用户到这套新的系统里了。于是年后回来到 7 月中，我们在做的事情就是不断迁移老的用户到新系统里，直到 7 月中，所有的用户都用上了新系统。其实在我加入 MoeGo 之前，也有过一次尝试，想做到类似这次的重构，但是那次因为人力的原因没有实现；而我这次把这个事情落地了，也因此拿到了 Outstanding 的绩效，还晋升涨薪了，这对我来说是个莫大的肯定。

而我还在这个项目收尾的阶段，就又被调去负责另一个会直接影响公司发展路线的项目——去支持新的商家运营模式，从 Grooming 到 Boarding & Daycare。

总得来说，这段时间在 MoeGo 过得虽然也挺辛苦，但是很快乐，很有成就感，为此我在少数派上发表过一篇文章《远程工作一年，是什么样的体验》。

从 Grooming 到 Boarding & Daycare

Grooming 其实只是宠物服务领域一个比较垂直，比较小的类别。这种类别的大商家不多，大部分都是中小型商家。那么宠物服务领域的大商家在哪里呢？就是 Boarding & Daycare 这类商家，翻译过来就是寄养、日托。这类商家基本上都是开实体店的，而且因为要寄养，场地、店面也会更大一些，每日的订单、流水也会更多。而且有些商家还是混合型的，也就是既能提供 Boarding & Daycare 的服务，又能提供 Grooming 的服务，还有提供其他比如 Trainning 、Dog walking 等服务。总之，这类商家的体量更大，能提供的服务更多，收入也更高，市场地位也更强。所以 MoeGo 想要在宠物服务领域 SaaS 做大做强，只支持 Grooming 是肯定不够的，支持 Boarding & Daycare（下文简称 BD） 乃至其他服务类型的商家是必然。

为了兼容原来的 Grooming 商家的体验和生态，我们一开始并没有办法做一套全新的系统，而是在 Grooming 已有的一些模块上继续增加 BD 相关的能力；有些模块是 Grooming 所没有的，那种模块倒是可以重新开始实现。

我们的 PM 和设计师还专门去美国出差，做用户调研，访谈，把用户的需求转成我们的产品功能，再通过研发把功能实现交付给客户。整个事情其实是挺合理的，不过我后来才知道，BD 的商家在用 MoeGo 之前，基本上都会使用的一个很成熟的软件叫做 Gingr。它已经在 BD 领域深耕十多年了，功能已经非常完备、成熟。而 MoeGo 对于 BD 的支持几乎可以说是从 0 开始，很多用户已经在 Gingr 里用得很顺手的功能，在 MoeGo 这边要么没有，要么得用一些 workaround 才能用起来。不过不管怎么样，我们在 24 年底通过近半年的努力，还是跑通了一个 BD 商家基本的日常操作流程，成功接入了第一个 BD 商家。另外，对于 MoeGo 而言有个好消息，Gingr 由于被收购，经过资本市场的一系列操作之后，它只剩下数量可怜的维护人员，基本不再迭代了。换句话说，只要我们稳扎稳打，Gingr 的用户迟早都会是 MoeGo 的，因为 MoeGo 已经完成了支持 enterprise 级别商家的基础，市面上除了 Gingr 以外其他的都还在早期阶段。

不过老板们不这么想，也可能资本市场时间就是金钱。总之在我们还在打磨 BD 在 MoeGo 生态里的各种功能、体验问题，还没做好吸纳市面的其他客户的时候，前线已经传来了我们已经在跟XX、YY等大商家接触、承诺、签单的消息了。很多东西我们还没做，就已经被承诺出去。导致原本我们是正排的时间线，突然之间变成了倒排。而且在当时的人力资源紧张下，大家只能加班加点，赶在 DDL 之前去完成这些需求。就在这种紧张的工作节奏下，我们即将迎来年底的绩效考核。

裁员

25 年年初，MoeGo 迎来了第一次非常严格的绩效考核，每个团队的每个组员的绩效，组长给了多少分，为啥给这样的分，给多了还是少了，需要 HR、CTO 以及跨团队的另一个高职级的同学来一起做校准，这个校准的标准，是直接拿着字节的职级标准来过的。那次我记得我特地去了趟深圳，从下午 3 点，一直跟他们对到了晚上 8 点半。我有两个组员在非常严格的标准下，被降成 need improve（1-5 分制的 2 分）。在过程中，他们 push 到我的点是哪怕是 need，他们也想要直接裁员。我举了之前我跟 G 同学一起改善成功的例子，但是他们回绝我的说辞是「你的时间很宝贵，不应该浪费在这种事情上。每年毕业生、找工作的人那么多，再招个更好的就行了」，我当时内心非常震惊，因为他们确实有做的不够好的地方，但是完全不至于被打 2 分，更不至于被裁员，更何况我们的业务还在发展，还缺人呢。从这里开始，我发现我们在价值观上已经出现了一些偏差。

后来，MoeGo 就开始了一轮非常大规模的裁员，我组里那两个被打了 2 分的同学，最终也没有例外。这次裁员有几个很明显的点，尤其像非业务团队，比如 QA，就是裁员到留下能够勉强 cover 公司业务的人数；「性价比不够高」的同学是重灾区；我们组的 N 同学，被裁员的当天，他在收拾东西的时候笑着说好难过；K 同学，被通知要裁员的时候直接大脑一片空白，许久才说了一句话。我那天在广州的屏幕前也哭了。由于那次的年终还没发放，我就问 HR 说他们的年终还能发放么？HR 说决定权在我手上，我是愿意发他们的年终，还是把这笔钱省下来发给留下来的人。我没有犹豫，我说我觉得他们应该拿到这笔年终，哪怕 2 星只有一半的年终。所以他们应该是当年那波被裁的同学里，少数的既拿到了年终又拿到了裁员补偿的同学，我想这是我能为他们做的最后的一件事情了。

除了年初这波大规模裁员以外，后面陆陆续续还有裁员，这些裁员就是非常突然的了。我记得一个非常让人哭笑不得的事情是，某个团队某个同学 Q，被裁员的当天下午 5、6 点才突然被 HR 拉着告知被裁员，以至于她手上当天还有待发布的项目没得发；而且事情非常突然导致她的 PM 也找不到她，还不知道发生了啥，在群里急着找人，其他同学也不知道发生了啥，人就不见了，真是让人哭笑不得。

最后说说我自己的绩效吧，我本来以为至少能有个 meet（3 分），毕竟 24 年我做了那两个特别大的项目，还是有业务产出的。结果是 2 分，然后还有两个月的年终被扣了。CTO 跟我说了一堆我还有待改善的点（比如什么我毕竟刚当 manager，当然还有很多需要 improve 的地方巴拉巴拉），同时还给了几个任务，说是完成了任务之后，那两个月年终就能拿回来。当时我并没有多想，因为听说 24 年，BD 的业务结果并不好，Manager 要承担业务结果，我能理解，我认为 25 年应该会做得更好点，到时候再拿回来就是了；不过后来我才知道，几乎所有的 manager 这年的年终都被扣了一部分，说辞也都大同小异，这就很好玩了。

330 - 530 - 1230？

经历完年初的裁员风波之后，我们的业务还是要继续。很快来到 3 月份，之前说的给用户承诺的东西逐步要开始兑现了，但是我们发现很多东西都没实现或者只有个 DEMO 版本。因此整个公司开始动员，用 330（3 月 30 日）作为一个时间节点，鼓动大家争取在 330 之前完成一些必要功能的实现。同时，因为 BD 这边的 PM 设计师以及后端的组长去美国出差，国内办公室需要有人带，所以我还去深圳待了 3 周。

本来以为 330 是终点，做完 330 的需求后我们可以重新按自己的规划来走。结果在 4 月 27 的时候开了个会，CTO 拉着产研团队，说现在事情非常紧急，来自美区的 CEO\GTM 团队发现大商家需要的很多功能，我们还没实现，我们必须要把大商家他们高优需要的功能实现了，才能避免他们离开我们的平台。

为此我们发动了 530 的「战役」，要在 5 月 30 日之前，完成大商家所需要的需求（当时说时间窗口只有一个月）。其实我们的整体规划里，很多东西其实不是不做，而是当下这个时间点会做其他更高优的需求；但是大商家的需求一来就变成了最高优先级，频繁插入打断我们原本的节奏。530 期间，CTO 提出的点是要把大商家的需求跟我们原本的需求 merge 成一条线；又因为大商家之前基本都是用的 Gingr，所以我们需要把 Gingr 里大商家需要，但是我们又没有的功能，立即抄过来。

所以我取消了原本规划的五一出行，甚至五一期间我还加了几天班，就是为了跟 PM、其他组长确定我们五一回来之后，需要做哪些需求，哪些需求谁来做，需要做多久等等。其实我们当时拿到最初的需求清单，第一眼反应就是根本做不完。最终的结果也是，我们在一系列已经被认为是高优的需求里，再次筛选出一波高优需求，在现有的人力资源的情况下，5 月份我们加班加点最终也没完全做完那些需求。有些需求甚至到 7、8 月份才最终做完。

在 530 开始前，我就在想这个东西真的能做完吗？要是做不完又会怎么样呢，公司会因此倒闭了么？为什么要给用户承诺那么多我们还没有的能力？然后用户进来了以后发现跟承诺不一样又生气想要离开，这种不是对我们平台伤害更大么？这也是第一次，我萌生了想要离开 MoeGo 的想法，因为我觉得这个阶段公司的种种行为、决策，我已经开始无法理解了。不过说来也巧，跟我一直以来配合的后端组长，也来找我聊这个事情，他也想走了。我劝他说可以再留一个月看看 530 之后会变成啥样。很快，他跟 CTO 提了离职申请，CTO 拉着他痛哭流涕最终把他成功劝下（结果没想到最后他留下了，我走了，哈哈），他说他被 CTO 画的未来愿景给说服了。

530 这个日子过去之后，530 的战役并没有立即结束。我们虽然没有完成所有的东西，但是还是完成了一些非常高优的需求，而这些完成的需求又暂时缓解了前线跟用户之间的冲突。所以我们在 530 之后继续补作业。虽然没有名义上的 630，但是整个团队的节奏依然还是非常紧张。

就在这个节骨眼上，发生了一件让我非常难以接受的事情，也是这件事情让我最终决定离开 MoeGo。有一次 CTO 在听产品汇报 demo 的时候，问了一下某个功能花了多少人日做完的，他认为只要几天，结果发现花了前端两人周，后端一人周，就很生气，就来问前端为啥需要花这么久的时间。实际上，需求本身看着很简单，但是背后的逻辑很复杂，而且我们经过长时间紧张的开发，已经积累了相当多的技术债。而且这两个前端同学我知道他们都不是摸鱼划水的同学，他们需要做这么久的时间也都是有原因的。我解释了一下大致的情况，但是 CTO 并不买单，拉了更多的人想看看到底怎么回事。于是我陷入了自证陷阱，拉着两个同学晚上紧急做了个复盘。我之所以这么着急是因为我不希望这件事情，影响到他们即将开始的年中绩效评估。结果 CTO 依然不买单。最终我拉上了 CTO 比较信任的另一个前端组长来一起证明这个东西确实需要花这么长的时间，才最终算是告一段落。

其实这个时候，我觉得在 MoeGo 工作已经不是很开心了，我每迈一个步子都得非常小心翼翼。但是为了即将开始的年中绩效评估，我还是想着给组员们站好最后一班岗再走。谁曾想，这个绩效评估原本是 8 月底结束，结果一直持续到了 9 月底。我跟每个人都仔细过了他们的自评材料，需要晋升答辩的同学我来回跟她对晋升材料 5、6 次。结果有些同学的评分，我还是没能争取到满意的结果。甚至有的同学大家都认为应该晋升的没晋升；大家都认为不应该晋升的结果晋升了；这里面的门道我就不多说了。总之，此时的我已经失去了继续往前跑的动力了。

而且我的身体情况确实在今年也变差了很多，年中体检的时候依然查出了高血脂（去年也有）；另外头上有颗痣，去年到今年变大了好多，最终去医院查了查，医生建议要做手术切掉。国庆回来后，我就请假去做了手术，把头上的痣切了。做完手术没多久，我就提出了离职申请。离职原因我说了主要是身体原因，我想休息一段时间。在预料之中，我的离职申请很顺利，也没有什么挽留，没有什么阻碍，甚至还被要求写一封全员信告知我要离职的原因，让大家不要有太多「恐慌」。

其实从 530 开始到现在，我感觉公司整体上的运作还是没有发生本质的变化，依然是被大商家的需求 push，而不是用做 SaaS 的方式去做软件。离职前，听说又要 “1230” 了。

25 年 11 月 21 日，我离开了即将待满 3 年的 MoeGo。

小结

在 MoeGo 的日子，其实跟微信有点像，也能分上半场和下半场。只不过上半场持续的时间会更久一些，原本我甚至觉得能够在 MoeGo 跟公司一起干到上市。虽然技术深度和技术难度，MoeGo 比不上微信，但是在这里我确实看到了一个产品是如何解决了用户的痛点，并且用户愿意为此买单，从而能够 cover 我们的成本，并最终实现盈利的。这个也正是我从微信离职的时候，想要在下一家公司里学习到的东西。MoeGo 的商业模式我是认可的，所以这也是我愿意从微信离职入职这样一家创业公司的原因。

我在 MoeGo 做的两个最显著的贡献，一个是帮助 MoeGo 可以从服务单店到扩展到多店、连锁店、加盟商的模式；第二个是帮助 MoeGo 可以从仅支持 Grooming 到支持了 Boarding & Daycare 等运营类型的商家。而这两个结合起来，则成为了我们今年能够去争取 Boarding & Daycare 大商家的资本。早期我也看到了，创业公司并不是什么事情都能做得正确，也会存在一些试错的项目，不过大家的想法都是想让公司更好，哪怕做错了，也不会有责怪，而是好好反思之后如何能做得更好。公司虽然存在一些问题，但是大家的冲劲、跟着公司一起成长的感受能够弥补这些缺陷。

不过随着时间的推进，公司规模的扩大，很多事情就开始变味了。24 年初的时候，HR 还在公司内部发了全员的 NPS 调研。我记得当时国内的 NPS 分很低，HR 说以后 NPS 会定期做，公司收到了大家的反馈，会一点点变好的。但是后来再也没有做第二次 NPS，之前承诺要变好的东西也一直没有落实。我一直觉得公司其实对内也算是在经营一款产品，它的目标用户应该是公司的员工。当我看到 Glassdoor 上美区的员工给到公司非常低分的评价，公司并没有因此做出一些改变的时候；当我看到国内的氛围在逐步变差，而公司的行动总是慢好几拍的时候，我感觉很难受。因为我觉得，如果一家公司如果员工都没法 serve 很好的话，它的员工做出的产品大概率也不会带有爱。尤其我们的产品跟宠物有关，感性的成分其实应该不能被忽视。以前我刚加入的时候每周还有公司提供的运动经费，鼓励大家去运动，后来取消了；以往每年 5 月 20 日还有个节日福利，可以让大家给家人买礼物、请家人吃大餐等，公司报销 520 元，今年也无声无息取消了，而且正好卡在 530 紧张的节点，大家正需要一些鼓励、一些关怀的时候。虽然后面通过其他方式「回来」了，但是重点在于那次无声无息的消失。

回想这几年，数不清多少次半夜被微信群、oncall 电话吵醒；数不清多少个节假日出门在外还必须带着电脑只为随时能解决用户问题；数不清为了解决用户反馈的哪怕很小的问题，花了多久时间去排查。其实解决用户的问题，得到用户的好评的时候，还是会很有成就感的。这些其实都是因为热爱，大家希望把事情做好，也希望以后公司能够看到大家的努力，能够认可大家的付出。

当然，作为老板站的角度跟我可能不一样。他更关心的是整个公司在资本市场上的占有率，关心投资回报率。公司活下去、增长是第一要素。CTO 的一些做法是个双刃剑，老板选择了接受其中的一部分，就必然要舍弃另一部分。所以从价值观上，我已经开始无法能够接受，于是我选择了主动离开。我觉得这个事情没有对错，只有适不适合。我觉得创业公司本来就是一个不断试错的过程，适合我的公司，我就留下来；不适合我的公司，我就离开。

不过在 MoeGo 的这一段时光，也还是很难忘。很多同事成了很好的朋友；很多事情，也让我成长许多。未来，我不会再为了所谓的职级、晋升这种事情被 PUA 了，这其实只是管理手段罢了。我想如果我之后要自己创业、做自己的事情，我看待事物的角度，应该比两三年前的我，会更丰富些。

最后，感谢在 MoeGo 认识的朋友们，感谢你们的支持与帮助，我自认为我做得还不错，就是遗憾无法跟你们一起走到最后了。离职前，很多同学送了我礼物，也让我非常感动，谢谢你们🙏

开心的事

跟在微信时期一样，在 MoeGo 的这几年里，生活中还是有很多事情是很开心的。

23 年的五一假期，我们去了成都，看到了胖乎乎的熊猫，跟在电视里看到的感觉还是有很大不同，非常可爱，我们甚至还拍到了 5 只熊猫排排坐吃竹子哈哈。

同月，跟老婆去拍了婚纱照

7 月，老婆神级的手速抢到了蔡依林的演唱会。时隔多年去听演唱会，现场的感觉还是很棒的。

9 月，我们还一起去听了西城男孩的演唱会，My love 一出口，就知道有没有啊。

10 月去听了五月天的演唱会，第一次在内场听演唱会，其实体验很不好，因为全程只能被迫站着了 hhh。

24 年 1 月初，在老家办了婚礼，去参加的同学都说是吃过的最好吃的婚宴，不过我们两个自己都没咋吃到，哈哈。

24 年 4 月，我们买了自己的🚗。因为新房 6 月就要收楼了，我们在此之前要到处去看材料、家具之类的，有辆车还是比较方便的，所以就买啦。

6 月，跑去惠州听了杨千嬅的演唱会，现场还来了山鸡哥，值回票价！（这一年来真的听了好多演唱会呀）

6 底月到 10 月，因为新房收楼啦，我们就不得不三天两头往新家跑，监督装修，选材料，选家具家电啥的，最终在 10 月份把装修都弄完了。装修的坑，如果之后我有时间，也可以再专门写写。

9 月份的时候，趁着中秋假期，请了几天假，跟老婆去了趟新疆（南疆），我们先落地喀什玩了两天，然后自驾前往塔县，在喀什往返塔县的路上再顺路玩一些其他的景点。除了人文、美食，我觉得南疆的风景也很👍。

去盘龙古道的时候，有个标语感觉很赞。希望人生尽是坦途吧，哈哈。

也是这次旅行，让我感觉我真的是很喜欢开车，我很享受开车给我带来的放松的感觉。

25 年 3 月 8 日，我们正式搬入了新家啦。（不过我刚搬进新家，第二天我就被叫去深圳出差三周了。）

6 月份的时候，终于瞅准一个空隙，请了一周的假去了趟西藏。除了有点高反以外，其他真的都很棒，西藏的风光也是独一档。我真的好喜欢开车啊！

25 年 10 月，Warp （一个很好用的终端工具）发来一个要赞助 PicGo 的邮件，让我非常惊喜，我没想到 PicGo 这个其实还没怎么做海外推广的项目，居然能收到来自海外团队的赞助。

后来我跟他们简单交流了一下，愉快地接受了他们的赞助（不多，但是得到的肯定是无价），前三个月会是个试用期，先看看效果再决定继不继续。为此我还需要开通 Stripe 和 GitHub Sponsor 功能，这个我可以后续放到一个单独的文章里说。

最后，PicGo 在 MoeGo 期间只发布了一堆 beta 版本，现在我终于有时间来发布它的正式版了。

结尾

我的博客从 2020.05.30 之后再也没有更新，今天是 5 年半以来第一次更新，好多以前想单独写的事情，因为各种原因没写成，最后都放到这篇文章里了。

回顾这 8 年，有高光也有低谷。PicGo 从 0 开始，达到了非常多的里程碑： 25k 的 GitHub Star； 100 多万次的下载（仅 GitHub Release）；接近 100 个社区贡献的插件、周边； Typora、Marktext 等文本编辑器官方支持的图片上传工具； Warp 的 Sponsor 等等。现在，一旦你遇到了需要图片上传获取链接的场景，PicGo 依然是你的第一选择。

而 “我想过一个什么样的人生”？我好像还没有一个非常清晰的答案，但是我逐渐想清楚的事情是，我不想因为所谓的职级、所谓的晋升、所谓的大厂光环这些东西去奋斗一辈子。其实这次跳脱出来，我发现程序员这个身份，很多时候是自己给自己上的枷锁——世界那么大，有那么多有趣的事情，有那么多有意义的事情，我为何要在这里或者那里浪费我仅有的一次生命？我 gap 又如何，我找不到下一份程序员工作又如何？职级是 P7 是 P8 又如何？只为这些人为划定的标签去奉献你的青春，想想其实有的时候还挺可悲。有好多事情我想做，但是一直没机会做——我想开车自驾漫无目的，我想把英语口语练好，我想学钢琴，我想学会做很多好吃的菜…… 说真的，世界上不是只有互联网一个领域，也不是只有大厂员工的身份才足够体面。这些套在头上的紧箍咒往往当你开悟的那刻，它就不再能束缚你的自由——我愿意从微信跳槽去当时不到 50 人的创业公司，我也愿意舍弃即将年底要发放的年终奖、创业公司给我的期权，给自己放个假，毕竟生命只有一次，开心最重要。

我很喜欢孙燕姿《开始懂了》里的一句歌词：开始懂了，快乐是选择。

今天，在 PicGo 即将迎来 8 岁生日之际，我发布了它的 2.4.0 正式版；而我于今天也迎来了我 30 岁的农历生日。30岁，对我来说是个新的起点，我得好好地想想我想做什么。在这里非常感谢我的老婆、我的家人、我的朋友能够在我做各种抉择的时候支持我的决定。人生的长跑，终点都一样，但是我可以有机会选择不同的起点。而你，我的朋友，未来的我们又会在哪里相遇呢？