致敬十年

最近受到一些朋友的触动，考虑趁着年底总结以及休假接近尾声，将过去时光中的工作经历记录下来，做一个自我复盘：“凡是过去，皆为序章”。

除了复盘之外，也希望这些文字能够给予和我有着类似经历的朋友们，一些启示和帮助，以及在一些场合下，减少我一遍又一遍的简要或详细的经历介绍。毕竟时间宝贵，多一些折腾，少一些寒暄，会更有趣一些。我希望未来再做介绍，可以用一个经历不那么平淡的、有追求的、精力充沛的、爱折腾的人概括。

我会先将过去十年的职业历程，进行总结和概述，然后分阶段展开每一段经历中的收获，希望对同有“折腾之心”的你有所帮助。

历程回顾

回顾最近十年的职业历程，我的职业路线可以说“既大众又小众”，先来聊聊大众化多一些的部分。

• 从岗位职业历程来看，我经历了几乎所有技术人都会走的路：初级工程师、高级工程师、资深工程师、技术专家、架构师；
• 从岗位职责来看，我也几乎走完了互联网业务研发岗位需要做的事情：普通组员、具备指导他人能力的活跃分子、具体业务的负责人、前端开发团队的负责人、产品研发团队负责人；
• 从公司类型和规模来看，我覆盖了多数人会做的选择： 上市名企（新浪、淘宝、阿里云、美团点评）、能够上市的领域头部独角兽（美团、小赢）、兼顾创业性质又有体制特点的民非创新研究院（智源）

如果忽略技术、管理双线发展的事情，上面的历程应该是中国互联网职场人的典型缩影。这些“爬格子”的历程背后，无可回避的一个词是：天时地利。但重点是，这个机会是你创造或寻找的，还是单纯的被动等待天上掉馅饼，恰好砸到你身上呢？

在同样的公司、组织机构中，同一批人“天时地利”的机会其实是平等的，我个人认为主要的差别在于心态是否主动，你否愿意去创造或寻找机会，去证明自己、去拿到阶段的成果，以及是否尽可能地进行了充分思考，果断的进行了决策。除此之外，人和也很重要。需要信任你、愿意授权和能够给到资源的老板，和你互相交付后背、相信你的团队伙伴。这里有一个绕不开的话题，就是对上和对下管理，以及团队建设，代码世界尚且复杂，现实社会中更是如此，人和相比较天时地利，只难不易，这点后续展开。

聊完大众话题，接着来聊聊小众的部分：

• 我可能是少数离开北京去杭州工作，但因为突然出现的异地恋，又折返回北京的家伙。也曾因为工作关系，需要不时奔波于杭州、深圳。
• 除了最后一家单位不能上市外，我所在的几家公司均上市，而我也在不同的岗位和角度见证了这个过程所需要做的一些产品、技术、人员上的准备。
• 在技术发展路径上，除了技术和管理双线发展之外，我可能是少数从后干到前，又从前干到后的家伙，并且是这里面少数可以不依赖 Java 技术栈吃饭的。
• 我的工作历程中，不论是做 toC 还是 toB 业务，亦或者是 toG 业务，以及不论做什么类型的产品，“基础工程” 以及 “从零到一” 的出现频率都远高于其他关键词。
• 我曾经做过“技术布道师”的岗位，参与和负责过国内两家头部互联网公司对外开源项目相关的事务，对于技术团队文化建设的事情，略知一二。
• 我曾参与组织过不止一次近千人或千人以上的“技术大会”会务相关的事情，这些会议有国内会议、也有国际会议。
• 我坚持写了十四年的技术博客，最近四年的平均每周分享一篇“具备实践价值”的技术干货。知乎上今年目前的阅读增量在 60 万，纯文章阅读增量在 40 万+，从我个人网站上 Google Analytics 分析报告，每年至少有十万以上的访客，其中 77% 在国内，以及 5000 以上的老读者访问内容。今年开始写一些更“大众”的内容，在外部平台阅读量不少都破万了。

新浪云计算 - 工作的起点

关键词：前后端分离大重构、底层依赖更换、前端基础库建设、指导新人、招聘面试、开源项目、技术分享

技术栈：PHP、MySQL、JavaScript、jQuery、Bootstrap

说起新浪云，多数人都会陌生，甚至会发出“新浪还有云”的疑问，但是如果提到 SAE，或许稍微从业年资久一些的开发者中，不少人都曾经领过或者买过的“云豆”，甚至在这个当时国内领先的 PaaS 平台上托管过自己的小项目。毕竟，十年前SAE云平台上的开发者注册数量，远远碾压同期其他产品。直到多年后，加入阿里云，遇到了当时的“友商团队”时，大家聊起 SAE 和 ACE 两个产品的时，打趣之余，更多的情绪是惋惜。

加入新浪云充满了偶然，因为初入行的我，并不知道下面这些关键词，对于我的职业生涯意味着什么：以媒体为主业的老牌名企、研发部门建制成熟、整个研发部工龄都比较长、几乎没有前端的后端云产品团队。

在 2012 年年中，加入团队的第一周后，我大概率成为了理想国际大厦17楼动态平台研发部、以及我们云计算部门里的唯一的一名前端工程师，或者说想专注干前端的工程师。（甚至在我面试时，团队开发经理都是借了一名微盘的前端工程师来帮助完成面试，可惜的是，这位同学在我入职后很快他就跳槽去了百度。）在团队经理 @世江 的信任和部门里各位老大哥（这里不at了，人太多，肯定漏人）的不吝赐教之下，到 2012 年年底的时候，我已经可以独挡一面，甚至还负责起指引和面试新同学前端相关工作的任务。

2013 是漫长的一年，新浪内部开始准备分拆微博上市，团队内部也因为有同学得到了来自不错投资机构的机会准备独立出去干一番事业，在谢绝了来自内部和外部的工作邀请后，我在理想国际 17 层的小格子间里，安静的干了一年。过程中终于将运行了四年的云管理平台项目重构完成，将混杂在项目 PHP 代码中的前端逻辑全部抽象了出来，封装了一个基础的前端库，将过时的 MooTools 更换为了 jQuery，在无 PRD 的情况下，将整个平台的前端框架替换成了 BootStrap，并做了一些界面和功能调整。这些技术调整，有不少直到现在运行的云平台上还都保留着。除此之外，还和伙伴们一起做了私有云版本的云管理平台。

工作之余，也搞过一些比较有趣的小东西，比如把经典的五分钟安装的 WordPress 定制成一分钟就能够安装的 WordPress 定制版：WordPress For SAE；做了一个前端 Error Tracker用于主动获取前端程序异常，能够快速进行功能修复的工具；和小伙伴一起做了能够检测平台用户访问几家友商网络质量的小工具，用于服务质量对比；还做了一些基于 jQuery 的前端组件、写了一些 Chrome 插件；以及在 2012 年、2013 年写下了五十来篇技术分享。

在新浪云的时光里，我慢慢从新人变成了老人，并见证了不少伙伴的离开。在 2014 年初，我做出了一个“决定”，想要做一个专业的前端，并纠结是否要去有“大量同类工程师”的地方。因为我潜意识里“骑驴找马”是不好的行为，于是我和时任主管 @kobe 提出了我的困惑和当前的状况，至今我都记得 @kobe 的建议是，“更大的团队对你的发展更好，大胆去试。”（很多年后，朋友聊天，据说我走之后，隔壁部门同期小伙伴纷纷收到了主管的安抚红包，以及语重心长的“好好干”）

于是，我放心的提出了离职，正式准备面试。因为之前加班特别多，所以剩余的调休加上年假有小一个月的时间，这个过程中，我就安心的退掉了北京的房子，回到了家里，享受再次上班忙碌前的“慢时光”。

机缘巧合之下，我遇到了最后一任女朋友，然后开始了一场漫长的异地恋。

淘宝网 - 前端领域深耕

关键词：项目技术栈更换、前端基础库建设、开源项目、技术分享、技术大会

技术栈：Node.js、JavaScript、KISSY

在拿到两家当时头部的前端团队的 Offer 后，我选择了 “淘宝网” 这个事后看来有无数槽点，但是又让我深爱的团队：当时节假日回家非常不方便、飞机总晚点、机票特别贵、而且收留了一群包括我在内的“奇怪的家伙”的团队。如果你让我打分，我可能会给它打满分，参考知乎老问题 “淘宝 UED 前端团队究竟好不好？值得去吗？”中我的答案。

把家搬到了杭州后，独立开荒了一些项目之后，和一位同学一起负责我的淘宝业务，没错，就是网页版淘宝登陆后展示的第一个“门户”页面，当年双十一、双十二 GMV 导流转化全集团第一的站点。这个项目是淘宝第一批使用 Node.js 作为中间件的同构类型项目，简单来说就是开发人员需要同时用 JavaScript 开发后端业务接口和前端交互功能，这个 Node.js 框架的名称是：Midway。关于它，知乎上有一个详细的帖子。虽然当时颇具争议，但是在 2021 年回望过去，你会看到行业里的头部公司也好，中等规模的公司也罢，在前端性能优化的方案中，Node.js SSR 方案始终会留有一席。

回想起那段封闭开发的经历，耳畔依稀会响起当初在会议室里小伙伴的吐槽：“啊，做不完、会要崩了、调不通，不想写了…”。也会清晰记得大家窝在一个臭烘烘的小会议室里，拉来腼腆至极的 @朴灵 朴大师做外援结对 debug，一起解决久攻不下的数据序列化的问题。项目的结果自然是好的，平稳地度过了双十一、双十二的 “DDoS 考验”，虽然受限于当年的大 Java 体系，部署设计比较复杂，但不论是实际运行，还是用户侧整体页面响应、以及我们的开发效率简直是全面开花，一度甚至让实际参与开发的我们认为它有发展成“银弹”的潜力。浏览器前端环境里，我们也使用了当时计划全面重构的 KISSY 新版本… 现在回过头来看，整个项目风险点还是蛮多的。

从 @堂主 手里接手了消息组件之后，基本上所有“淘宝消息”相关的事情就都过来了，从集团所有电商页面中的消息吊顶到 B 端的消息管理平台，以及后面差点出问题的双十一、双十二全网侧边栏中的“消息”功能。我依稀记得这个组件因为要适配淘宝茫茫多的业务页面（拥有不同的碎片化的基础前端库），因为需要处理兼容性问题，所以导致不得不“恶补”之前因为使用 jQuery 而忽略的“原生 JS”（ES5）。在折腾的过程中，我们也玩了一些好玩的东西，比如在前端进行发送消息预埋，以减轻服务端在大促节日的压力。当然，因为当时消息功能需要借助 Flash 长链接以及 LocalStorage ，也踩过安全的坑、半夜爬起来解决问题。

除了小团队协作之外，还在淘宝体验了大规模协同作战，茫茫多的开发一起制作双十二淘宝全网侧边栏。说起来幸亏有了之前做我的淘宝的经验，和小伙伴在所有的可能出现问题的地方都做了降级开关，以防不测。没想到零点的时候，双十二开始，和钱相关的优惠券功能，还真因为上游后端协商的精度口径有偏差，出现了面额放大的吓人问题，好在有之前的准备，有惊无险。

在紧张的工作之余，有幸参与了当年 D2 的举办，负责整体活动票务相关技术，以及运营事务。因为前端团队缺少服务器资源，所以就盯上了免费的 GitHub 和不花钱的老淘宝技术博客服务器资源：我在 GitHub 上创建了一个项目，并在微博上宣传，需要参与者使用 Fork + PR 来的方式提交参会申请，然后使用 GitHub 的 WebHook 搭配淘宝技术博客，做了一个自动化的 D2 邀请函分发系统。当时这个方式还是比较 Geek 的，在一众微博老同事的帮助转发之下，热度到了 23万，GitHub 上的项目 Fork 数也迅速破了 800，最终报名人数有 1100，实际到场有 800 多人，远远打破了之前历年的记录。

因为饱受工作中因为开发环境带来的不畅快，还利用周末时间还制作了一套开发&测试工具。也和团队小伙伴们一起，为两本“动物书”贡献过章节翻译，给杭电小同学培训过前端技能，开发过 WordPress 下载量破万的爆款插件。这个时候，我开始对开开发环境、交付效率产生了浓烈的兴趣，毕竟“君子不器”嘛。

可惜的是，因为异地恋的艰难和未来家庭规划的原因，我不得不开始考虑离开淘宝，回到北京。

美团网 - 全面成长

关键词：基础技术、从零到一、在线统计、在线收银台、自动化测试

技术栈：Node.js、Docker、JavaScript、Nginx、React、Electron、CasperJS、PhantomJS…

在比较早的时候，和行业内一位比较资深的前辈沟通，他推荐我去美团他同事所在的部门：基础研发部。出于谨慎和礼貌，谢绝了这个推荐。但是不久之后，这位突然打来电话，“来北京，我带你。我到美团了。你就只想做个前端？…”

之后，就是无缝切换城市，大概用了一周左右到时间，我从杭州余杭搬到了北京望京，一个熟悉又陌生的地方。加入了这个当时只有三个人的团队：Rank、小黑（当时还在读书）、我。相比淘宝而言，当时的美团并不大，甚至显得很小巧。研发都挤在施耐德大厦，在之后很长一段时间里，开发同楼层找人吼一声就行了。

很长一段时间里，@Rank 每天都在想办法忽悠人入伙，我和小黑就扛起了几乎所有的开发工作，招人的问题直到 @崔凯 、@随机 的入伙之后，才有了明显的改善。在有了基础班底后，从前期技术规范制定、基础开发框架搭建、研发流程确定都搬上了日程。过程中，还经历了大家一起为研发职级标准做贡献的的事情。伴随着开心的争吵，团队的基础日渐踏实，但是依旧缺人。于是，我又开始了无休止的加班：一个人同时负责美团网的 Web 统计 SDK 的设计和开发、美团网H5版（虽然我不想这么称呼它）收银台的设计和开发、支付和统计使用的 HTTPS CDN 方案和实际部署运维、以及还要和小伙伴一起做团队基础开发工具的建设，直到半年后，团队新入职两位同学 @王强、@禹霖 接手了我的活之后，才得以喘息。

记得我移交项目的时候，Web 统计 SDK 已经应用公司全网大型应用和部分 Hybird 应用，而现在更是几乎无所不在，在漫长的、研发团队缺少机器资源的时间里，之前搭建的 HTTPS CDN 方案，更是承载了不知道多少来自全网买买买的请求量。相比传统的实现方式，这个方案对于 URL 无污染且准确率较高 (前端对账 97%+)，可以说它解决了我对淘宝 SPM 打点统计方式污染链接的不爽，也开启了日后折腾统计和数据的大门、以及无止尽追求极限服务器性能的开始。

收银台则填补了美团没有 H5 版本的支付渠道的问题，支持了当今各种手机浏览器以及绝大多数 Webview ，诸如微信和一些公司内外的 Hybird 应用中，在当年完成之后就明显提升了支付成功率，支付项目组为公司单这一个项目就带来了以亿为计单位的收益。

项目从零到一落地之后，感激老板赏识，我得过两次破格晋升的推荐机会（在岗年资不够），虽然没有用到，直到美团点评合并之后，我才得以晋升。但是时隔多年，依旧感激于 @Rank 和 @随机 的信任。

过程中，对内做了不少分享，也在 2015 年、2016 年留下了几十篇文章。

随着美团技术品牌越来越响亮，大团队的人数越来越多。与此同时，团队开始更加注重效率和研发效能，需要做一些基础方向的尝试和探索，于是我和五六个小伙伴开始了漫长的“自我折磨”过程，因为这都是我们的第一次。我负责的方向是“UI 自动化测试”，希望以无侵入的方式，根据开发或用户的交互直接生成能够自动化测试的代码，我的目标是 100% 的无副作用的生成录制，以及在各种客户端场内（各种浏览器、Webview、MVVM框架、传统 JS 库环境） 100% 的无副作用的复现。

时隔多年回溯这段过程，依旧能回忆起当时踩过的坑、技术失误，以及那段时间出现的，正式从业以来第一次失去技术自信的难过。用“走火入魔”来形容也毫不为过。项目最终的结果是应用到了内部系统中，节约了一部分人力成本。许多年后，我在朋友的对外技术分享看到了这个曾经让我“吃不下、睡不着”的项目，在实际项目中还是起到了一些微小的作用，还是蛮感慨的。

长期做基础建设，没有得到预期的结果，让我当时十分郁闷；加上好不容易晋升，就赶上了美团点评合并后的职级大调整，我的职级对标回到了我在淘宝时的样子，闷上加闷，甚至让我一度觉得我自己成长不足，辜负了时间。

感激那段时间里，基础技术团队每一位小伙伴和 @随机 的开解和帮助。

在 2016 年 9 月，女朋友来到北京准备继续上学，我们异地恋结束正式结束。我开始考虑换一个环境，重新开始。

阿里云 - 视野补充

关键词：基础技术、老项目重构、从零到一、招聘

技术栈：React、Angular、Docker、Node.js

巧合之下，和淘宝前师兄、主管 @风驰 沟通之后，了解到团队计划在北京开分舵，我有比较大的发挥空间，可以进行团队建设。深入沟通之后，我上班的两点一线就更新了坐标，每天上班可以少走 1 公里路了。不同与淘宝时期，需要 Base 在杭州，这次绝大多数时间都在北京。

我有忙碌的思想准备，但是没有想到会这样忙。尤其是在财年末加入团队，遇到了业务迭代压力的高峰。而我所在的北京小分队，最初也只有4个人：两位 UI 设计师、一位交互设计师，以及我。

这个开局，似乎有一些熟悉的味道。

刚入职就同时接手了 6+ 控制台项目，以及相关控制台海外站的建设任务，为了不被这些项目“压死”，腾出时间做招聘、我开始处理项目中的技术债，在大概做了下面的事情之后，我得以缓一口气：改造前端工具链、重构业务模块、对代码进行动静态分析，配合脚本自动对老框架的程序进行多语言填充。

我重构了其中的 3个控制台业务，用之前积累的经验和方法简化了控制台的前端架构和设计方案，并实现了一套新的配置管理方案，可以做到不发版本更新业务逻辑、动态的打功能“补丁”。

为什么这么做呢，因为阿里云的客户规模非常大，研发基础要求之一就是要稳定，内部软件版本发布经常会遇到“因为其他团队、其他的业务发布出现故障，或者因为节假日禁止发布，连累整条链路冻结发布”，然而这种事情一旦出现，就会产生需求堆积、以及耽误你发现的明显需要修复的 Bug。加上当时负责海外站，负责对接老外的同事，不时会提出一些特别琐碎的功能问题，以及细节翻译问题，为了不产生频繁的“发布周知”动作，这个借鉴自移动端的动态补丁的方案，或许就是当时的最佳方案了。

当时前端还没有 esbuild 这类异构的构建工具，所以记忆中针对 WebPack / Grunt 等工具也做了不少 Hacks 处理，让构建速度能够达到秒级。没想到在美团后期持续做工程建设的经验，在此刻被释放了出来。

除此之外，我们很难想象阿里云当时的前端框架居然是自创业初期就留存下来的上古版本的 Angular ，因为产品一直在高速迭代，所以没有人去做框架调整。于是，我就又开始了再一次的“云控制台重新开发”的活，不同的是，这次要使用的框架是 React 版本。因为之前在新浪、淘宝、美团的经验，项目自然是毫无波澜的走完了。

紧张到爆的工作之余，我还参与了 Tengine、Altas 等开源项目的开源建设，认识了一些朋友。不过真的是因为太忙了，我甚至连周末、回家后的时间都在不停的处理工作的事情。以至于当时已经写了快十年的技术博客在 2017 年几乎都断更、空白的。

在当时极高的工作负荷之下，回家经常发生吵架拌嘴的情况，高频率需要加班处理问题，也会影响到家人休息。除此之外，我在北京推荐入职的同学不约而同的选择了拥抱杭州“大部队”，建设北京开发团队的目标越来越遥远。直到有一天，团队有一位关系还不错的同学离职，沟通之后，我意识到了一些之前因为忙碌忽略的问题：我的职业成长空间、这个北京开发团队的建设、以及何时大团队能够进入正常的节奏呢？

于是和直接主管 @山重 沟通后，我开始准备离职流程，离开阿里云。感谢过程中 @山重 师兄的帮助和开解、指点，@风驰 师兄的理解和包容，团队其他小伙伴的帮助。

小赢科技 - 团队建设

关键词：老项目重构、从零到一、持续集成、基础技术设施、团队管理、人员招聘

技术栈：Vue、Docker、JavaScript、Node.js

当时，还是女朋友的媳妇考博成功。在那个时间点，我也特别希望我个人的事业上出现新的变化，能够将之前离开美团时，想要得到的“组建团队”的目标实现。巧的是，刚刚离职，就收到了朋友的介绍，来到了刚刚遭遇研发团队重组的小赢。

相比较其他部门，前端团队⾯对的问题更加严峻：技术栈繁杂且落后，维护成本颇高；缺少文档管理，老的产品逻辑没头没尾；缺少工程基础设施，发布依赖人肉，效率和质量都比较低，交付品质全靠个人经验；而且头疼的是，初期团队成员的招聘，全部都是由非前端背景的代理主管在我到岗前一阵搞定的，而且此刻团队还有 50% 的空缺需要补。

此时公司还未上市，影响力极其有限，招聘遇到的问题，像极了之前在美团时，我所在团队刚刚建立的状态。相比较在阿里云、淘宝的时候，发条微博都能勾搭到简历和需要内推到同学，这段过程度过的非常难，在线下面试了百余号人之后，终于将团队人数扩冲到了 10 人。

在此期间，为了提升开发效率和交付质量，我将团队项目技术栈进行了统一，定制了团队的开发脚手架；率先将持续集成在前端团队全项目落地、推动了公司持续集成落地、使用 Docker 容器化方案保障了工程的稳定构建和高效；还通过前端工程化的方式，完成了自动化埋点；将小程序引入业务，尝试制作 Chrome 插件工具来解决一些业务实际问题。

伴随公司上市节奏的加快，公司的平稳运行，我们开始进行职级体系建设（又是似曾相识的感觉），开始进行团队合并。互联网平台部的组织架构的上出现了调整和下沉，前端团队允许做的事情，慢慢出现了曾经可能淘宝才会遇到的问题。我之前的直接汇报对象，技术副总也开始转移重心，计划开启内部创业，为了不影响原公司运行状态，所有基层干部保持不动，所以我的汇报对象，也开始有了调整。

团队权限和业务范围收缩之后，我有了时间去参与外部技术分享，在参加一场会议之后，遇到了一些老朋友和新朋友，大家的观点触动了我，于是我写下了《职业上的思考》这篇内容。我需要一个崇尚技术、更开放的环境，以及“未来能给自己带来归属感、成就感的产品和领域。”

当时希望能够通过内部的技术文化建设，来引起一些转机，于是就和我的老东家们的、负责技术品牌建设的团队（阿里、美团）们的同事取了取经，美团技术学院的刘老师，给予了我非常多可行的建议，也播下了一粒种子。

记得和老大“@乐风”提及我计划离开的时候，我们聊了很久。老大的不少提点直至今日都受用颇深。因为连续三段“前脚离职、后脚入职”，疯狂输出的状态，让我感觉疲惫不堪，于是谢绝了老大新团队的入伙邀请，给自己放了一个长假。进一步思考这段时间的得失，在离职之后，我写下了这《一年以来的职业历程总结》，当是告别了过去。

这次休假开始，也是我正式恢复对外技术分享、进行持续技术内容写作的开始。

美团点评 - 学习“运营”，“兼职”开发

关键词：技术布道、开源建设、从零到一、人员招聘

在之前的职业历程中，我一直在当事人的角度来看待问题，如果我切换为旁观者，不以一个绝对的利益相关者，得到的结论是否会有变化呢？

在 2018 年的年末的总结里，我当时的想法：

从代码爱好者、脚本小子到工程师，我应该差不多花了十年。从工程师到技术专家花了差不多三年，从技术专家到架构师又花了差不多两年，越来越快的变化，其实并不会带给我越来越多的满足感和成就感，因为我最初只是想做对的事情成为受人尊重的工程师而已。 当想法被环境附加了太多额外的因素，我或许做了太多容易做却不一定是对的事情，稍微远离业务能够让我思考的更清楚，也能够让我接触到更多领域的知识。我认为恐慌来自你知道你不知道，而不是你不知道你不知道，完善的知识管理体系能让自己更有安全感，以及做出更好的决策。

接着，我接受了刘老师的建议，准备在求婚之后结束休假，回到此时已经是“美团点评”的美团。加入了一个特别的部门：技术学院。希望通过客观的自我观察和验证，我之前的想法是否正确。

相比之前的每一段经历，我的领导和前辈们对于我的帮助几乎都聚集在技术和职业深度上。在这段经历中，刘老师的不吝教学、悉心教导、充分信任，以及无数次包容我的无知莽撞，则让我在技术以外事情上，不断开悟和锐变，虽然过程极其痛苦，但是领悟之后，会颇有“五柳先生传”中“每有会意，便欣然忘食”的愉悦感。

重新加入美团后，我对内负责团队内技术产品的重构开发，对外负责公司优秀技术内容挖掘，帮助那些和我有些许相似的人，让有价值的人和事发挥更大价值。

我希望能够通过我的些许努力，能够帮助到那些和曾经的我类似的技术人，帮助他们把手里“折腾”的技术的价值描述清楚，让更多的人了解和知道他们的能量，避免可能正在、或者将要在晋升过程中因为笨嘴拙舌描述不清楚技术价值，而错过宝贵晋升机会的可怜的家伙。

入职前半年，我的主要精力在美团这边的“技术布道”上，我重构了一些运维成本颇高、使用体验不佳的团队技术产品，将技术开发、运维成本降至了可以接受的程度；简单优化了公司提交开源、对外技术内容贡献的流程；使用“无服务方案” 开发了对内的技术导航、技术博客两个小产品；以及帮助技术团队们做了一些招聘和对外技术分享的事儿。

但是很快，工作上有了新的外部合作需要，我需要不停的穿梭于中关村和望京，去一个当时刚刚成立的“民非组织”干活，需要灵活切换“美团技术布道师”和“智源外部技术顾问”两个角色来进行一些资源协调的事儿。当时主要的工作目标是帮助这个组织完成基础的信息化建设，以及想办法搞定“智源社区”这个尚存在想法中的概念产品，并且因为我的身份是外部顾问，所以要尽可能控制的投入精力。

然而，随着越来越多的“社区建设”工作的参与，我在过程中主动或被动的体验了“顾问”、“商务”、“猎头”、“架构”、“开发”、“运维”、“安全” 多个职能角色，从最初协助社区负责人建设社区技术产品、聚拢“社区志愿者”，到最后变成了这个社区的产品技术负责人。

在第一届智源大会举办完成后，我和兼任智源运营副院长的刘老师沟通，离开了美团点评，加入了智源这个当时只有 13 个人的组织。

又是熟悉的开局味道，仿佛有魔咒一般。

智源社区 - 一切都是从零到一的创业

关键词：从零到一、基础技术设施、产品开发、团队管理、人员招聘

技术栈：Node.js、Docker、Nginx、PHP、Vue、ClickHouse、Ruby、Go…

“AI必将改变世界，你想成为这一伟大进程的一份子吗？”

在告别2019中，我提到了我加入智源最初的动机，荣誉感、使命感，以及那个许多数次“从零到一” 让我备感折磨，又享受和期待不一样的“创业感”的过程。

虽然这个民非组织此时毫无名气，但是它要完成的任务却被早早的安排了下来，也在同年的北京政府工作报告被 “cue” 到，甚至被列为重点工作内容之一。经过两年的发展，智源已经成为了北京十四五规划和二零三五远景目标纲要中的一部分。在连续举办三年的智源大会和几十场学术会议后，在国内外 AI 圈子里，大家或多或少都知道甚至参与了这个偏硬核学术的会议。

在尚未正式加入智源时，伴随着不断的了解，我发现中国的人工智能社区其实还在偏早期的阶段，如果我们能做一个“中立的”、“硬核的”、“有趣有用”的社区，那么对于中国国内的学者、学生、工程师、技术爱好者而言，会是一件非常有意义和价值的事儿。而且这个意义，显然比 “美团点评技术”品牌更大，从可以帮助到的人的人数来看，受众要多的多。

但是，在它小有名气之前，在领创空间加班的时候，总能看到一位“老同志”在厅里或许因为思考、或许因为发愁，不时来回踱步。其实当时，我也挺愁的，担心被他抓住，笑嘻嘻的问：“小兄弟，你给简单讲讲，社区是啥？” 以及每日需要和刘老师进行汇报的当前开发、团队组建进度。

原本以为在小赢这类“上市前的公司”做招聘，会是我职业历程中最难的时刻。加入智源后，发现在民办非营利组织中做招聘，更要命的是做互联网风格的产品技术团队的招聘，真的困难。加上早期产品形态和定位尚未想清楚的时候，整个团队需要不断试错、不断的自我折磨和验证，难上加难。客观的说，不是每个人都适合需要探索的项目，更多的人在从业的时候，会更希望团队能够成为他/她从业履历上漂亮的一笔，而不是稀里糊涂、抹不掉的一团文字。

除此之外，不利于招聘的客观因素还有很多，比如薪酬对标、比如岗位职级体系的建设和完善需要时间、以及比如很长一段时间里，我们的主管院长因为一些原因，并不能够 all in 过来，在内部资源争取上，我们或多或少难免受到影响。为此，也是煞费苦心，想了不少办法，最终还是把团队建了起来。

困难虽多，但是人还是要招的、社区产品还是要做的，我们经历了 2019 年智源大会依靠两个人顶起来线上线下、票务支付、线上直播的黑暗时期，当时团队一度走到只剩下一半人；也经历了 2020 年在疫情最严重的时期，刚刚重组的团队远程协作的困难时期；还经历了 2021 团队在大会前因为组织调整减员、错误用人规划产品、以及积累下来的技术债导致的致暗时刻。

过程中，除了主管院长刘老师的授权和信任之外，愁的来回走的“老同志”也给了我们不少有效的建议和帮助，悉心教导如何做事更为妥当。当然，也会有一些短期跳起来够不着的要求、或者说是美好的期望。

创业两年过后，在研究院里，来自内部对做社区的质疑越来越少，或许是我们做到了一些基础的要求，也或许是大家也习惯了吧（笑）。其实翻看以往媒体宣传，可以看到在很长一段时间里（模型出现之前），社区产品是为数不多的，研究院可以直接对外展示成果的内容之一。

在几乎听不到 “研究院做什么社区啊”、“社区有什么可做的”之类的声音之后，我们开始纠结怎么才能把社区做好的自我折磨阶段中。而这个时候，我们出现了极其严重的错误，关键岗位用人失误。一度甚至引发在大会举办前就将团队崩溃的局面，好在还是抗了过来。在最终搞定了全链路接口和业务都能承载 1 万 ～ 10 万 QPS /s 之后，智源大会这类“性能挑战”成为了历史。

在经历过社区建设之后，我可以笃定的说，产品形态只是社区的一部分，和严格要求技术指标的技术产品思路是不同的。除了诸如无门槛的大规模的在线直播、直播相关交互、内容相关的安全对抗，需要技术护航、提供基础的服务性能之外。只要产品符合其背后组织的品牌价值，具体做成什么样子、具备什么功能，并不重要。相比之下，重要的是为什么做这个功能，对应的运营手段是否能跟上，以怎么运营，才能产生更多的和人之间的“化学反应”。内容、运营、技术，都是产品的一部分，相互补充，难以分割。在保障内容质量的前提下，技术不行的时候，运营多搞一些，运营跟不上的时候，技术顶一下，很多事就扛过去了。

随着 2021 北京智源大会的结束，完成了对师长们的承诺，我正式递上了辞呈，我觉得是时候再次给自己放个小长假，然后再思考下一段该如何启程啦。毕竟，回忆智源这段经历，都是一件耗费体力的事情，因为真的太累了，远超以往。具体细节可以参考 2019～2021 过程中的各种记录，比如这个、这个、或者是这个。

自小赢后的这三年，工作之外，我大概写了 150 篇技术相关的文章，用于技术分享和内部简单培训使用，涵盖了基础技术设施、容器化实践、效率软件使用、编程技巧、硬件相关的内容。去年年末看到全年数据的时候，还是蛮惊讶的。期待今年结束后，全年的数据结果。

感谢 2019～2021 这些日子里，信任我以及相信智源并加入过智源的伙伴。如果有缘看到这里，转送你们两句这两年师长们赠予我的话：

• “人生就是不断开悟的过程，你这个是小问题，经历过就好啦”
• “有的事吧，过程很痛苦，结果可能会美好。”

最后

写完了十年的流水账，除了一路上帮助我前行的师长之外，同样感激所有帮助过我的人，一则怕疏漏、二则担心造成不必要的困扰，在此就不一一 at 了。

我希望接下来的十年里，继续对世界保持好奇心，继续尝试创造、继续进行技术分享，继续去感染和改变我能改变的一切。也期待接下来的时光里，所遇到的好玩的事、有趣的人会更多一些。

– To be continued