2026-01-18 07:24:55
所谓投资，就是好公司+好价格，仅此而已。作为普通人，和基金和机构比起来，优势之一便是拥有自己独特的认知，这些认知，无论是多么小众，还是听起来多么 “常识”，如果用得好的话就是优势，是能够帮助投资变现的。
就我自己而言，符合这一条件的，我可能也能找出个别几家公司来，而 Atlassian 便是其中之一。我相信大多数人，特别是那些所谓的金融分析师对它未必了解，而作为软件工程师的我，则一直以来都使用它的产品，有的时间段内甚至是重度用户，自然对它我有我自己的认识。这支股票一直在我的列表上，截止本周五，Atlassian 的股价（TEAM）跌到一个非常诱人的程度（120 刀以下），我认为是一个非常好的机会。本来我一直就想写一些我对不同公司商业模式的看法，那正好这是一个很好的机会，就来聊一聊 Atlassian。这些都是我自己的观点，未必正确。
将近十年前离开 Amazon 以后，我经历的每家公司都使用 Atlassian 的产品，尤其是 Jira 和 Confluence，有时还有 BigBucket。尤其是在 Oracle 工作期间，我是真正的重度用户，每天接触大量的 Jira tickets，备受 Jira 系统的折磨，参与 Jira 稳定性的问题讨论，甚至还开发系统大量调用 Jira 的 API，我们自己实现的工作流引擎就支持复杂的 Jira 交互。当时有个戏谑的说法就是，Oracle Cloud 从上往下一层一层，什么 SaaS、PaaS、IaaS，其实下面还有最底下的一层，而这一层就是 Jira。
一直以来，Atlassian 在推动客户从本地私有部署进化成为云托管的（也有一些数据安全要求高的可能是其它数据中心的）。我觉得这个思路是非常正确的。本来，本地且不说支持服务的难度更高，营收的天花板才是最大的问题，客户上云之后，连带服务、新产品（包括 AI 的新特性）推送等等都可以很容易地进行，这比单纯的卖软件授权要有多得多的盈利可能性。
本地部署的情况下，费用收取可以采用按人头的方式，但是这种方法比较落后，上限很低，而且在 AI 时代要减少用工的短期趋势下，这是非常不利的。因此上云可以带来质量更高的订阅制收费模式，以及基于 feature、插件，甚至 AI token（配额）等等的收费模式。单客户的价值可以进一步提升。
从公开的数据来看，上云后，大客户流失率小于 2%，基本上这可以抹平一些人对于上云会丢失客户的担心了。这其实也体现出了产品的护城河。就拿 Jira 为例，很多人可能会觉得 Jira 是一个非常好用的跟踪问题的工具，不过我看到一种说法很有道理，完全相反，Jira 其实是一个很难用的工具，但是它的难用恰恰把你给绑住了。它可能用起来不是那么友好，但是它提供的复杂功能，加上历史数据，让你很难离开它。除去数据，Jira 本身也支持复杂的自定义工作流，整个流程（以及涉及到的部门和人）都被捆住了之后——想想看，功能、数据、流程和人，面对这样的强耦合，要想迁移开去，是非常难的，我想不是它真正的用户，是很难体会到这一点的。换言之，一旦上了贼船，要想下船岂是那么容易的？在上云之后，我相信 Atlassian 的定价权会进一步加强。
除去最核心的护城河——迁移成本以外，还有其它一些特性也构成了护城河，比如它的插件生态。生态的建立和谁先进入市场来培育用户有关，就像是 Amazon 的 Echo 从技术上也许不如 Google Home，但是它的生态建立起来了，各种应用和设备都和 Echo 整合起来了，其他厂商很难再进入了。Jira 有超过 5000 个插件，这让其他公司很难快速地做出一个替代品来。
最近一段时间，软件股、SaaS 股都被市场抛售，而且是不分青红皂白地抛售。对于 Atlassian，市场大致的逻辑是，AI 可以让写代码变得非常高效，那么软件流程管理工具 Jira 和 Confluence 这样的知识库工具就可能变得没有那么大的价值。可是，真的是这样吗？
其实，市场的担心不无道理。首先，按照人头收费的方式，在软件开发不需要那么多人的时候，就面临着自然而然的市场规模的收缩；其次，Jira 这种传统的数据存储的方式是结构化的，好处是 schema 清晰，便于处理，但是却不是最自然的人类记录数据的方式，而 LLM 才是能够 “理解” 和 “记忆” 非结构化数据的；最后，正是因为机器、流程、规则等等都喜欢结构化的数据，也正是因为它们的程序具备单一目的时才容易写出来，于是我们才创建了那么多工具和交互界面，因此实际上这些繁杂的工具和界面都是 “反人类” 的——当我们真正使用一个聊天输入框来使用纯自然语言进行交互的时候，这些工具似乎都显得没那么必要了……顺带提一句，这就像手机上无数的 app 一样，我想未来的手机应该是一套统一的交互界面搞定一切的，app 就算有，也应该是工程师考虑的东西，不应是用户考虑的东西，用户不应该花费时间精力在 app 的安装和切换上面。
我的想法是，这个方向兴许是没错的，但是这需要时间一点一点地来证明。我想起了 2000 年的互联网泡沫，市场也许想的方向都是对的，但是它太心急了一些，仿佛一夜之间所有坐电脑前的白领都可以下岗一样。从目前而言，我认为你不能指望做出分析决策的大多数人都具备软件工程师的背景，事实上，从目前的情况来看，AI 在这方面被显著地高估了，并且我认为 Jira 和 Confluence 这样的工具其实并不会受到显著的影响。我自己也用 Windsurf 等等工具协助写代码，但是短期内 AI 的代码能力和如此大程度地替代软件工程师，还差得很远，这一点，我相信很多非专业的人是很难理解的。
另一方面，在相当长的时间内，系统出现的问题，还是会通过 Jira 的 ticket 来跟踪，而无论这是人还是 AI 造成的问题；而数据，无论是人来使用还是 AI 来使用，作用依然是举足轻重的。逐渐地，Jira 和 Confluence 这样的系统也会逐渐革新，以将 AI 的能力逐渐集成进来（比如 Rovo，它尝试提供一层代理，正如前面提到的统一了的输入框一样，封装底下复杂的工具和功能，让交互变得简单）。同时，前面说到的护城河，依然会让向替代品的迁移变得困难。总之，就像早在十九世纪初 George Carley 就提出了现代飞行的原理，但是直到一百年后的 1903 年，莱特兄弟才让飞机上天，工程的问题的难度往往被人低估——我认为这个过程可能确实会发生，但它需要花费大量的时间和投入。
Atlassian 这几年做了不少收购，大致路线我还是能够大概看懂的，主要是围绕他们要解决的问题，收购一些相关的公司，他们的产品可以作为整个解决方案工具集的一部分。比如，Loom 则是一个很好用的屏幕录制和视频分享工具，可以用来帮助会议纪要和内容管理，视频可以和现有的 Jira 等等工具集成。Atlassian 的最终目标，可能是想跳出这个作为单一 “工具” 提供商的圈子，变成一个提供统一开发工作平台的厂商。
但也有一些很难看懂，比如去年收购了 The Browser Company（Arc 和 Dia 浏览器的开发商），因为这个浏览器是 AI 原生浏览器，可以直接理解屏幕上渲染的内容。我想可能他们是要抢占用户使用的入口，这很像互联网公司抢流量入口一样，但是最后的用户体验会是怎样的，让用户抛弃掉现有的浏览器来使用这个新的入口吗？这很难让人信服。
谈过 AI 之后，再来看看 Atlassian 同一领域的竞争对手。整体来看，主要就是 GitHub 和 GitLab。虽说还有一些轻量级和更现代的解决方案，但是从竞争对手来说，我觉得最大的威胁还是来自于 GitHub，因为GitHub 的最大优势就是深度整合的全家桶（一体化），GitHub 可以带来项目管理和代码管理的流量。从我的角度看，对于开发者来说，GitHub 有天然的优势，但是对于非技术人员来说，Jira 和 Confluence 反而占有一个更好的位置；另外一个方面，是 GitHub 在 DevOps 这个圈里面负责的范围还是太小，而 Atlassian 的解决方案可以覆盖更大的部分，包括代码之后的运维等等。当然，这是一个价值千金的问题，我其实很想知道 Atlassian 的管理层有怎样的想法，从长远看打算做什么来应对。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
2026-01-06 12:20:44
自我上次 2018 年回国已经过去超过 7 年了，这次回国呆了超过两周，感触还是很丰富的，整理得不够系统，简单把它们罗列下来。我虽然长期不生活在国内，但是我始终是中国人，也始终用简单的 “国内” 两字替代 “中国国内”，我非常热切地想了解中国国内的变化。当然，时间关系，我的观察不会很深刻，因此我的观点未必都是正确的。
中国的基建搞得真的很棒，要说出行恐怕中国是最便捷的国家了。期间坐了公交、高铁、卧铺、游轮、出租、网约车，或者是干脆步行……都很方便。我想，这应该是得益于中国超强的基建能力。这是让我无比自豪的一点，虽说以前在国内待着的时候并没有深刻体会。
关于网约车，我的记忆还停留在那个滴滴和快滴烧钱拉客的年代。后来我知道的是，滴滴独打天下了。如今我看到的是，滴滴也似乎未必能玩得过竞争对手了。因为它的竞争对手早就变了，已经是高德地图这样的流量入口。当年阿里下错了很多步棋，但是阿里没有下错高德地图这步棋，这是少有的流量入口应用。我拿高德地图搜网约车，就会显示一堆可选项，来自不同的网约车公司，接着直接对接支付宝，这个平台把端到端做得真是不错。说起高德地图，想起那时候百度地图是通配，再想想百度的其它业务，顺便叹息一下它的没落——真是拿了一手好牌，打得稀烂（比如搜索和地图）；好容易盼走了对手（Google），却输给了时代（比如移动互联网）；起了个大早，赶了个晚集（比如 AI）。
关于中国的铁路客运，效率依旧是没得说。从浙江的一个小城到广西桂林旅游，去程高铁，回城动车软卧，前者要快四成。两种不同的体验，但是共同点一句话说就是很快速、舒适。小时候绿皮火车的记忆慢慢淡忘，那时候车厢里挤满的人群，无比酸爽的味道，还有在铁路上行驶咯噔咯噔的响声，以及卫生间不可描述的卫生状况……而现在，整个过程都很舒适。
中国经济的三驾马车投资、消费和出口里面，回国后我最先感觉到的是，消费力普遍不足。不只是大宗商品，比如我家乡海边大量的空置房屋，甚至烂尾楼，就说一些普通的步行街，没有什么人气，当然，大城市的情况会好一些。消费这个东西是和经济密切相关的，而经济又是和信心密切相关的。
我问了问家人都使用什么电商平台，得到的答案各异。我是使用京东的，主要还是因为货品普遍靠得住，并且配送比较迅速，大部分两三天内就能收到，还有不少当日达，这在美国还是比较难做到的。现在成本的因素还是占据大头，但我相信如果中国的经济能慢慢地稳住回升，老百姓手里有钱的话，京东的配送优势就能更好地发挥出来了。
这个时代已经变成了一个普遍忧虑的时代，但是忧虑的主线还是老的三座大山：住房、教育和医疗。住房是如今这其中最大的问题，我想上一辈人借着改革开放、人口爆炸以及居民加杠杆的多重优势，获得了相当大的收益，但是这种收益我认为有很大一部分是时代的红利，而非个人能力。如今这个接力棒传不下去了，八零九零后就被迫成为了最后一棒的接盘侠。住房的问题每个人都在说，而教育方面，除去反内卷，我能看到的是一些幼儿园也开始公费化，这是整个社会的进步；医疗方面，我留意到药品价格被打下来了，但是没有医疗保险足够的覆盖，很多人还是因为一病返贫的忧虑而不敢花钱。一些思维开化一些的年轻人，在挣扎无效之后选择躺平，这些都是时代特有的烙印，我觉得舆论媒体需要包容，而非打压这样想法的人，毕竟从长远看，都是社会的进步。
我一直看好中国的发展，趁这次回来，想用人民币买一点基金。但是这个过程挺坎坷，折腾了我不少时间。这个恰好是和前面说的出行和基建完全相反。
银行就像一头大象，似乎笨重得难以跟上这个时代。举个例子，我想在国内买一点基金，通过工商银行的渠道，有无数的限制和烦人的手续。我连着跑了两趟银行也没有彻底搞定。这期间我的感觉就是，我的钱根本就不是我的钱——我取不出来，转不出去，买不了东西，做不了投资，全都有很烦人的上限，而且这个上限还很不容易改，做什么改动还要看流水，还要解释原因……
投资经理笑呵呵地服务，但是申购费居然要 1.2%，而互联网平台（我用的财付通）只有它的 1/10，一开始我得知这个还觉得是不是搞错了，差那么多钱，那银行还搞个屁？果断选择后者，果然整个流程非常顺利。当然，我因为不想开股票账户，就直接买基金，这个申购基金的流程要麻烦得多，连购入价都要等两天才能看到。
从长期投资的角度看，国内我置信程度最高的互联网公司就是腾讯，这次更坚定了我的想法。我经常说的一句话是，在港股市场如果有一笔闲置的钱，而且不知道买哪家公司，那就买腾讯。腾讯已经深入人们的生活，它的护城河可以说看不到边。阿里作为第二梯队，要差一些，尤其是在流量入口方面；当然，电商业务我觉得它是很难打赢拼多多的。除去它们，作为第三梯队，我觉得我能看得懂一些的还有携程。
我本身有克罗恩病，这次因为肠梗阻被迫住了几天医院，有这么几个感受：一个是整体费用比较低，特别是药价，前面已经谈到了；第二个是医生上来就给用了大杀器的药物，比如针对中到重度感染的联合抗生素等等，对于我的轻度感染有杀鸡用牛刀的感觉。当然，我毕竟不是医生，但是我了解到大家都是谨慎为上，目标就是最快速度缓解症状、治疗疾病，这和我过往所理解的在医疗上权衡利弊的理念有所区别。
再有一些病房里的规定，让我觉得不太舒服。比如对于我这样一个血糖正常的年轻人，一天查六次血糖，每四小时一次，结果就是我睡觉也睡不好，我觉得也是似乎有点过度医疗了。
可能很多人已经忘记了当年雾霾的天空，PM2.5 仿佛已经是一个遥远的回忆。这次回国，从下飞机开始空气质量就让人惊艳。能源结构的大换血和产业升级的效果有目共睹。除此以外，马路上的垃圾和随地吐痰等等情况也少了很多。不过来到郊区野外，还是能见到不少垃圾。
我是在小红书上面找的桂林本地旅行中介，没有任何购物环节，纯是跟车景点一个一个地玩，我们包车游览了完整的五个白天。桂林山水甲天下，我的桂林之行的过程也很顺利，感受非常好。和导游聊了聊，这两年内地和香港游客增加，但外国游客减少。希望国家之间的关系能够更健康和平稳，这样中国的旅游资源能够在世界范围内受到更多的欢迎。
中国文化的一个根基就是美食，我相信无论出国多少年，无论接受多少各个国家的食物，我始终是那个要归家的少年，而我的胃始终是中国胃。踏上中国的土地，敞开吃的第一顿不是大鱼大肉、山珍海味，而是油条、小笼包、稀饭和茶叶蛋。在美国也能吃到口味各异的中餐，但时隔七年能够吃到家乡的味道，仿佛旅程的仆仆风尘和满身疲惫都被瞬间治愈了。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
2025-11-24 11:30:38
作为业余爱好，一直很喜欢研究企业的商业模式。我以往觉得电子商务这个赛道竞争很激烈，生意很难做，尤其是中国当前的环境下，近些年在商业模式上也没有太多有意思的创新。快两年前，写过一点关于拼多多的，但主要是批评，我不喜欢它的生意模式，我觉得它的壮大会打压中国的品牌成长。这个观点至今依然成立，不过，除此以外，那个时候我对于拼多多的理解还是比较浅薄的。随着这两年拼多多的成功，我觉得我看到了它越来越多以前没有看到的东西。这些东西让我越来越觉得，黄峥，真的是个眼光很长远，执行上也很厉害的人。
最早的时候，我以为拼多多的核心就是低质量、低价的策略。后来我渐渐明白，所谓的低价策略，只是最肤浅的一个表象。
如果退到十年以前，应该很少有人能同意，在如此激烈的电子商务赛道上，已经有了老牌的阿里巴巴，还有重供应链的京东，拼多多能够挤进来，分到一杯羹。而如今，不仅如此，它的增长居然已经让这两家都难以望其项背。
说到阿里巴巴，如今看，它还是犯了一个企业扩张以后变得局限、傲慢的通病。早些时候马云就评论京东说这种重资产玩不转，到后来张勇则认为拼多多只会帮助阿里巴巴教育用户和开拓市场，阿里巴巴错过了太多的机会。
拼多多的核心商业模式是什么，招股书中讲是中国的 Costco+Disney，零售+娱乐。但是它没有对比阿里巴巴和京东，来进一步细致地说明它是打算怎么赚钱的。看起来这些零售电商很接近，其实很不一样。阿里最值钱的是什么，是商家；但是拼多多呢，是消费者。就连对于 “砍一刀” 这样的基于社交的病毒式营销，也是基于消费者这个核心。拼多多教育用户，你要关心你买的产品和价格，但不要关心是什么品牌、是谁生产的。拼多多不在乎丢失商家，而是推行白牌商品，达到极致的性价比，以最简单的低价方式来留住用户。所以说，传统电商那套基于流量变现的策略在拼多多这里行不通了，拼多多更关心的是单一性价比高的商品，谁来拿订单？很简单，价低者得。
Costco 玩法的其中一个核心就是由它来代替用户选择性价比高的品牌，利用巨大的订单量，来和生产的商家谈价格。在同样具备规模效应的情况下，这是它和沃尔玛这种靠商品品类之全而获得用户的商业模式来说，最大的优势之一。比方说，在 Costco 买衣服，你不会找到很多的品类，每种衣服的类型可能就那么一两种衣服，但是衣服的质量可以，而且性价比没的说。一句话概括，单一的种类，巨大的订单量。
阿里也好，京东也好，它们都可以把消费者直接对接到商家，砍掉中间环节，但是这样的消费者依然是没有议价能力的，因为消费多少不能提前确定，每一单的规模又小得可怜。但是类似于 Costco，拼多多的做法是什么？把大量消费者的需求捆绑起来，它们出动去和生产产品的商家谈，这就让商家愿意去用一个更低价格来换取很早就可以确定的大订单。商家被迫报低价来抢单，商家和商家之间抢拼多多这个大客户，这种模式和白牌商品有着最天然的契合。可以认为，这是团购的升级版，我觉得这才是拼多多最核心的玩法。
提到了 Costco，再来说 Disney，这主要说的是娱乐和社交。和传统电商个人选择和购买的模式不同，拼多多可以利用团购的本质来强化社交这个行为。因为团购需要多人参与，拼多多就可以提供一个可以游戏的平台，这也是其它传统电商很难和它竞争的一个方面。无论是养成类的多多果园（这个真是一个提高日活的绝招）还是社交裂变类的砍一刀，还有那些对于很多人来说看起来并不高级的幸运转盘……购物变成了只是游戏过程中的一个环节。
再来看看拼多多扩张的过程当中，那些成功而重要的决策。
首先是 “砍一刀” 这样的病毒式营销，这可能是像我这样的人最早听说拼多多的时间。那段时间，恰好是微信摇一摇春晚大肆撒钱的事情发生之后。众所周知，腾讯的这一方面的眼光总是很独到，藉由微信等等流量平台，他们也有非常大的用户数据和这方面的经验。腾讯投资了拼多多，或许这盘大棋中，也告知了拼多多这样一个事实——大量的网民们，他们的微信账户有着红包摇来的钱，这是最好的建立拼多多性价比消费心智的时间。配合 “砍一刀”，拼多多的初始的大规模获客就这样做到了。
第二件火爆的事情可以说是拼多多玩的 “仅退款”，阿里和京东根本当时根本就没法快速跟进。因为他们需要考虑这些极度便利消费者的措施，对于品牌相当负面的摧残和打压。品牌就意味着溢价，有了溢价就没法极度地考虑性价比。从这个角度来说，长期看，拼多多的市场很大，并且阿里和京东根本没有办法去抢，无论是国内还是海外。阿里也许能把很多第二产业、第三产业做成，能把阿里云做成，甚至能把芯片也搞起来，但是传统电商，对于大多数人来说，考虑到目前大多数人的消费习惯和能力，我觉得它长期下来是不可能搞得过拼多多的。
再有，拼多多对于资金的分配，也是极致的典范。想想阿里什么都要投钱，铺开来如此之大的摊子，什么都搞，拼多多非常本分，就做自己风格的电子商务，就是扎根于农村下沉市场，和阿里、京东比起来极少的员工数，尽可能地避免重资产，连办公楼都是租的。每次财报，都是不分红，并且低调地强调未来的风险，最近火爆的 AI，拼多多也似乎尽量去避免接触，这样的管理层，在如今这个习惯于画大饼的世界似乎真是独一无二。
接着，我想到了微博和小红书。微博是大 V、名流为核心的玩法，无名人士的发声微不足道；小红书呢，则是基于草根的玩法，它的推荐系统是最核心的资产，它可以让一个无名之辈的帖子出现在感兴趣的用户的眼前。我觉得这是小红书和微博最大的区别，这也是微博已经是上一代互联网产品，逐渐衰落的原因之一。以此类比，阿里巴巴上的品牌企业，就是大 V 和名流；拼多多上的无数白牌商家，就像是不知名的草根。单一草根势单力薄，但是拼多多这样的平台把他们的力量汇聚起来，消费者买到东西的时候兴许不知道是哪家草根商家生产了他的货品，但是千千万万的草根商家就能够借助这个平台，靠着生产白牌产品，把自己的小小生意做下去。这样看，其中的历史意义显而易见。
最后，事物还是要从两面看。拼多多的商业模式风险也非常显著，我觉得这可能也是市场不愿意给它一个足够溢价的原因之一。最大的风险还是在监管和地缘政治方面的，比如美国 “小额豁免” 漏洞的利用，最近已经补上了，且看它在美国市场上之后的表现。还有就是一些合规调查，包括仿冒商品等等方面，其实有很大程度上也是要限制中国商品在其它市场上低价的倾销。
总之，这林林总总的事情，无论是战略还是实施，都让我觉得拼多多真是一家非常厉害的企业，黄峥真的是一个很厉害的人。黄峥受到段永平影响很大，他要 “做对的事情，并把事情做对”，但我不知道对于他来说，什么样的事情是对的事情。当然，我觉得我还是没有很深刻地读懂拼多多，以上只是我现在的思考，这真是一家太有意思的企业。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
2025-07-27 10:55:18
首先，从高维度看，OAuth 是要解决什么问题？
OAuth 要解决的是客户端在不知道和不使用用户密码的情况下，怎么样安全访问并获取用户所拥有的资源的问题。
顺带说一句，经常和 OAuth 一起谈到的 OIDC 则是解决了用户信息（profile）获取的问题。简单说，OAuth 解决了 Authorization 的问题，OIDC 解决了 Authentication 的问题。
OAuth 有几种角色：
所以 OAuth 就是用户想通过某种机制，通过 Client 和 Authorization Server 交互来获得能够访问资源的 token。
对于 OAuth2.0 的授权流程，可以根据 grant type 来做个归类。下面的图示全部都来自 Auth0 的官方文档。
1. Authorization Code：用户访问 web app，web app 的后端请求 auth server，于是重定向到登录页面，用户输入登录信息，auth server 就给 web app 一个授权码，这个授权码通过 callback URL 返回，而这个参数一般放在这个 url 的参数中，比如：http://…/callback?token=TOKEN。之后 web app 就可以拿着授权码去取 token 了。这种方式不需要用户这边存放任何 secret，但是需要用户参与 consent，并且具备 web app 的后端，因为和 auth server 的交互主要都是 web app 后端完成的。
但是这种方法存在一些 concern，比如说，这个 code 如果在返回途中被截获怎么办，截获者就可以使用这个 code 来获取 token 了。
2. PKCE：对于上述问题，有一个改进的办法，就是使用 PKCE（Proof Key for Code Exchange）来给它增强。基本原理是，客户端生成一个随机字符串 code verifier，根据一个算法 code challenge method 来生成它的 hash（challenge），获取授权码 code 的时候需要把这个 method 和 challenge 带过去；接着，code 正常返回，但之后客户端拿着 code 去获取 token 的时候，需要带上这个 code verifier，这样 auth server 就可以根据之前拿到的 method 和 challenge，以及刚得到的 code 和 code verifier，来校验用户是不是可以得到这个 token。
在这种情况下，如果 code 被劫持，那么对方拿到了 code，却没有 code verifier，也就没什么用。
这种方法是比较推荐的，对于一些 CLI 登录使用这种方法的时候，重定向 URL 可以是一个带有 code 的指向 localhost 的地址以被 CLI 捕获。
3. Device Code：前面说到的 Authorization Code 这种方法还有一个变体，就是对于一些需要用户参与，但是又没有浏览器（或者自动打开浏览器）的场景下，这个重定向到浏览器来获取用户 consent 的过程，被其它方式来取代，这种变体可看做名为 Device Authorization 的流程：
可以看到，上面的浏览器重定向的过程被替换成了返回 code 和 verification url，然后用户使用 verification URL 加上这个 user code 来完成 consent 的过程，在这个过程完成之后，这个 device 才被授权。在这个过程完成之前，需要 app 不断去 poll 检查是不是 device 已经被授权了。
4. Client Credential：前面说到的 Authorization Code 虽然好用，但是需要用户手动登录确认的过程，对于一些没有人参与的 M2M（machine-to-machine）系统而言，这是不现实的。因此在 client id 的基础上，再加上一个 client secret，一样可以完成 auth 的流程。这种场景其实就相当于是 client 和 resource owner 是同一个了：
5. Implicit：这种其实就是上面 Authorization Code 的简化版，去掉了 code 的环节，直接发 code。这种方式在 app 只有前端的场景下（比如 SPA）使用，因为它没法进行后端和 Auth Server 的通信。但是这种方式因为安全性低，因而不推荐，因为即便是 SPA，还是可以用前面说的那种 PKCE 增强的 Authorization Code 方式来实现。
再来看这个 callback 的 URL，和前面提到的 Authorization Code 流程不一样的是，它返回的 token 放在 URL 的 fragment 里面，而不是 query 里面，比如：http://…/callback#token=TOKEN，这样做的好处是这个 TOKEN 不会在浏览器跳转的时候送到服务器，就不容易泄露。
6. Password：这种方式其实就是让 client 获知用户的用户名和密码，属于风险比较大的做法，要求这个 app 是用户百分百信任的——这也就是说，它没有解决 OAuth 本身应该解决的问题，因此很少使用。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
2025-05-19 07:18:12
入职 Coupang 两个月了，第一个月主要上手和开发 BOS（Business Operating System）系统，第二个月开始调研选型 ML Workflow 平台。前者目前来说相对比较简单，后者对我来说是一个新坑，也比较有意思，随便写写技术上的体会。
先扯点题外话，其实这次求职有几个比较符合我预期的机会，可在思考之后，我基本上毫不犹豫就选择了 Coupang 这一家。最主要的原因，并非因为雇主，而是因为要做的事情。一个相当规模的团队，在大干一场的早期阶段，要在搭建起属于自己相当规模的 AI infra 来。
我觉得软件行业的巨大的变革，新世纪以来就三次，第一次是互联网应用的崛起，我太小没能做啥；一次是十几年前的 cloud，看着它从爆发式增长到如同水和电一样进入我们的生活，可我算是错过了它比较早期的阶段，即便相当长的时间内我在 Amazon，但是我却并不在 AWS；而这一次，当 AI 的浪潮再来的时候，我就很想行动起来，真正投身其中。程序员的一生能有几个赶这样大潮的机会呢，我不想再错过了。虽说我没有 AI 的技术背景，但我知道 ML infra 到 AI infra 却是个我可以切入的角度——从我最初接触软件开始，尤其是学习全栈技术的时期开始，我就认定，技术是相通的，这十几年来我一直在如此实践。因此在调查和思考之后，我觉得这是一个我不想错过，并且更重要的是自认为能够抓住的机会。
当然，就此打住，我目前只是这个领域的初学者，因此理解并不深入。
接着说正题，在这一个月之前，虽然我经历过不少关于 workflow 的团队，虽然我参与过从零写完整的 workflow 引擎，但这些都是针对于通用 workflow 而言的，我对于机器学习的工作流，也就是 ML workflow 可以说一无所知。于是在问题和需求调查的过程中，第一个关于它的问题就自然而然出现了，我们是否真的需要 ML workflow，而不是通用的 workflow 系统？
其实，这主要还是由于 ML 的生态所决定的。通用 workflow 可以完成很多的事情，但是在机器学习到 AI 的领域内，这个过程中最主要的目的就是把 raw data 给转换成经过训练和验证的 model，其中有很多部分都是有固定模式，因而自成体系的。举例来说：
总之，ML workflow 更像是一个 workflow 中的重要分支，它的特异性显著，因而从架构上它有很多在我们谈论通常 workflow 的时候不太涉及的特点，并且它们具有明显的共性。
Workflow 这样的系统，和很多 infra 系统不同的地方在于，它具有全栈的特性，需要从端到端从用户完整的 use case 去思考。回想起通用的 workflow，我们会想，用户会去怎样定义一个 Workflow，怎样运行和测试它，并且怎样部署到线上跑起来。这其中的前半部分就是 development experience，而后半部分则是 deployment experience。
首先，对于 development experience 这个角度，ML workflow 有它独特的地方，其中最主要的就是 Python SDK。
通用 workflow 我们讲定义一个新的 workflow 的时候，我们通常都需要写一个 DSL，里面定义了一大堆 task 和依赖关系，而对于做得比较好的 workflow 系统来说，可能还需要一个可视化的 drag-and-drop 界面来方便地创建 workflow。
但是对于 ML workflow 来说，它最特殊之处是对于 Python code 的无缝集成。因为 Python 之于 ML 的地位就像是 Java 之于企业架构的地位，任何一个 ML workflow 客户端首先要考虑支持的编程语言就是 Python，用户通过往大了说是 SDK，而往小了说则是简单的 Python decorators，就可以定义 task 和 workflow。比方说，一个简单的 Flyte 的 hello world：
from flytekit import task, workflow
@task
def say_hello(name: str) -> str:
return f"Hello, {name}!"
@workflow
def hello_workflow(name: str = "World") -> str:
return say_hello(name=name)
在 ML workflow 的世界中，这是除了 DSL 和视图化之外的第三种定义 workflow 和 task 的方式，也是必须具备的方式。
第二个，对于 deployment experience 的角度，大致上是基于 Kubernetes 从 control plane 到 data plane 固定的交互机制。
我不知道这是不是一种关于 ML workflow 的约定俗成，但是通过调研 Kubeflow Pipelines、Flyte 和 Metaflow，我发现这三种对于 control plane 到 data plane 的交互模式是出乎意料地一致。
注：也有把 Operator 那一层归为 data plane 的，我觉得都说得过去。
其中 Metaflow 说的是使用 Kubernetes 集成的情况，因为它并不是非得依赖于 Kubernetes。
但大多数使用都是基于 Kubernetes 的，而且基本上都是这个套路，control plane 的 service 收到请求以后，通过创建 K8s CRD objects 的方式告知 workflow controller（scheduler）来执行 workflow，对于 task 的执行通过调用 data plane 的 K8s API 来创建 task pods 执行。
对于特殊的 task，需要交由特殊的 K8s operator 来执行，那么这个 “交由” 的过程，也是通过 K8s 这一层的 CRD change 来实现——Propeller 负责创建 CRD，而对应的 operator 负责 monitor 相应的 CRD 改变并相应地执行任务。Propeller 和 operator 二者互相并不知道对方的存在。这种方式对于保证 operator 的重用性和跨 workflow 系统的统一性简直是太棒的设计了，我们在 try out 的时候，就让 Kubeflow Pipelines 系统中的 operator，去执行 Flyte 给创建的 PTJob 和 TFJob。
关于架构，我觉得 Flyte 的这张架构图对于 components 层次的划分说得非常清楚，下面的 control plane 和 data plane 是可以有属于自己的 cluster 的，不过值得说明的是，真正最终执行的 task pods，也就是图中的最下面的 K8s Pod，也是可以放在另外的 cluster 上，由远程的 K8s API 调用触发的，这样就可以带来更多一层的灵活性：
再来比较这三个 workflow 的优劣，我并不打算列全，而是简单说说自己印象最深的几点：
在我把这三者全部在 EKS 上搭了一遍并使用了一圈，也仔仔细细对别了特种特性和优劣之后，我对于 Flyte 的特性比较感兴趣，我觉得它们对我们团队也比较有用。
具体来说，很多区别但最重要的是两个：一个是 strong typing，其它两个都只支持 Python 类型的 hints，就这一点上，和一些 ML engineer 也讨论过，把问题发现在本地，是非常吸引人的；再一个是 multi-tenancy，对其 Flyte 有很多原生的特性支持，在平台完成之后，我们希望把平台上 ML 的能力开放出去，因此这是很重要的一个特性。此外，我也在考虑对于一个 control plane + 多个 data plane 这种 use case 的情况，这部分的需求还比较模糊，但是 Flyte 依然是这方面支持特性相对比较多的一个。
无论最后的结论为何，我希望我们能够比较灵活地部署选中的这个 ML workflow system，比方说，在 CLI 上，我们考虑在更高维度建立出一层，用户使用同样的命令，无论下面执行的 workflow 系统是什么，都不需要改变，这样一来，等到未来如果我们需要支持第二个，应该能够比较容易地整合进去。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》
2025-02-21 05:23:32
自去年秋天裸辞之后，一直在考虑职业生涯的问题。之后加入求职大军，目前进展还算顺利，作为软件工程师的下一站也将很快确定下来。但是这一次的 career break，虽说时间不算长，却给了我莫大的启发，我也有了一些思考。
其实在去年年初的时候就简要叙述过这个事情。熟悉我的朋友都知道，我的职业生涯有点奇怪，从 Huawei 开始，我是一个全栈工程师（fullstack engineer），从网页设计、前端开发到后端开发都是一锅端的，当时也非常喜欢这个方向，这也是我后来在极客时间上写 《全栈工程师修炼指南》这门课的原因之一。
不过后来这个兴趣点也在慢慢迁移，在加入 Amazon 之后，我陆续经历了两个大的 data platform 团队，一个是做销量预测（demand forecasting）的，一个是为 retail 一侧计算成本和利润的。在这两个 team 中，都要和大数据打交道，和 scientists 和 analysists 一起合作，而我作为一个 engineer 的基础工作，就是把 infra 维护好，提供好用的工具让他们的问题观测和分析更简单。也是从 Amazon 开始，我开始更关注一个模糊的目标，一个可以持续建设的 platform，关注一个 solution stack，而不是具体某个 service，或者某个具体技术。
差不多六年之后，在 Oracle，我带领的 team 则是侧重于 infra 了，依然是作为 engineer，主要为 cloud 管 datacenter 的两个东西，一个是 process automation，一个是 matadata storage。在这个比较大的 team 我获得了比较大的职业生涯成长，我们 own 一个非常完整的 solution stack，也越来越确定我关注的重点，以及未来发展的方向。虽然从一定意义上来说，做的事情依然是 full stack 的，但我开始更多地称呼自己 platform engineer，而不再是 fullstack engineer 了。
之后在 2022 年加入了 Doordash，从巨头转向更加敏捷的中型互联网公司，一开始在一个偏向于 infra 的团队，做 gateway platform，我还是比较享受这一年多的时间的。当时 team 里面有一个非常有经验和见解的工程师，我从他身上学到不少。后来因为 org 调整的原因，我选择抓住机会去做了很短一段时间的产品，回头看这个决定有些鲁莽，但至少也确认了一件事情，单纯做产品并不是我最喜欢和擅长的。
对于下一站，我的几个在考虑的选项中，无疑都是偏向于 platform 和 infra 的 team，其中有两个机会我尤其感兴趣，其中一个是维护开源的高并发 library 的，还有一个是做 AI infra 的。现在我正在努力做的功课，就是把它们前前后后都了解清楚，然后做出自己的选择。
这是个很好的问题。只不过，这个 “将” 可以斟酌，因为它已经替代一些初级的工程师工作了。但放眼未来，它到底能替代多少工程师的工作，我不知道。现在，很显然的有两件事：
但是关于上面这第 1 点，这样的 “替代” 到底能达到多深的地步，我不知道。我隐约觉得，能被替代的工作往往是非常具体，逻辑比较确定和简单，而且不需要处理人际交流和关系的工作。以前有人觉得，AI 不能替代艺术家的工作，因为他们的工作是创造性的。可是你现在看看呢，写作、谱曲、绘画，都变得可能了，可是我并不想反驳这条观点，而是想说，这从一定的角度上来看，我们是不是可以说，艺术家们的工作，其实也并不全是创造性的呢？
而关于上面这第 2 点，有更多岗位要远比软件工程师更值得担忧，而软件工程师们，只不过是因为现在站得和 AI 更近，替代后的成本节约更多，因而更焦虑。就如同软件行业是经济的风向标一样，当工程师们开始焦虑，不久的将来整个社会都会焦虑。从好的一面看，当工业革命开始，无数人担心机器代替人类工作，但最终机器却为人类创造了更多的工作，我想这一次机器替换成了 AI，道理也一样。无论如何，不要逃避，而要尝试改变和拥抱这样的变化，因为这个趋势是不以人的意志为转移的，该来的总会来。
我觉得，总体来看，AI 将很快替代的，未必是工作，而是特定领域的技能。我觉得这句话里面，有两个重点，一个是 “技能”，一个是 “特定领域”。同一份工作，也许需要能力和技术将大不相同。对于一个需要做出复杂判断的工作，并且这个工作还需要许多不同领域视野和经验积累的，AI 相对会更难替代。
对于一些传统行业而言，那里有更多的固化、低效、不愿革新和进取的工作。我有个朋友在保险行业，做的事情就是要用科技（不仅仅是 AI）来变革，把保险公司从传统上认为人力资本巨大的企业变成一个靠软件来横向扩张的 SaaS（软件即服务）公司。趁这个 job hunting 的机会，我也去了解了一番。我觉得，这些看似红海的传统行业实则是使用软件革新的蓝海，未来会有更多的 SaaS 公司。有很多这样的传统领域，成长缓慢，或者利润率低，资本不太看得上，但是从这个角度思考，或许有大的机会。
在刚离职的时候，我曾经提到过对于就业市场的理解。大致来说，就是比我 2022 年下半年那会略好，但是想要回到疫情前那种 “无比风光” 的状态是不可能了。现在回头看，在经过了一番求职的折腾后，我可以说，这种观点还是大致正确的，不过就业市场比我最初想的，还是要好不少。简单说来，我觉得近期软件工程师的机会，比 2022 年下半年要多不少。
其次，一个萝卜一个坑。我记得 2017 年那会找工作的时候，我可以先把 phone screen 搞定，然后排一堆 onsite 在同一周并行，这样的话一旦我拿到 offer，如果需要选择的话比较容易操作，因为它们的时限都比较接近。但是这次好几家公司都是过了 phone screen，然后告诉我坑已经被填了。所以之前并行的策略没有那么有效了，看到心仪的职位，不仅需要面试得好，还需要尽快完成。
再次，bar 还是很高。有时候看到很多软件工程师朋友还在谈论刷题的话题，其实刷题是必要条件没错，但是离实际需要差太远了。从分配时间的角度，还是需要更多时间分配到其它环节去。总体来说，就算两轮 ps 加上 5 轮 onsite 的话，ps 全都要 positive，onsite 全都要 positive，也许最多一轮 on boundary，否则基本就挂了；有些情况下，就算全是 positive，如果不够 strong，还是会 downlevel。所以，总体来看 bar 还是比较高的。行业发展就是这样的，软件业也不是例外，求职门槛提高，这是行业成熟的一个标志。
最后，回头看，去年的这个裸辞还是果断（或者武断）的，但是回想起来，如果再给我一次机会，我估计还是会做出同样的选择。没有什么对错，就是做出自己的选择而已。这段 break 的时间我还是比较享受的，而且除去 career 发展的目的以外，由于再在 job market 上面走一遭，起码从面试的角度来说，有了比较新鲜的认识，哪一天如果被裁员，我相信也不会过度慌乱。这也算是一个额外的收获吧。
我知道有很多朋友和我一样，近期在求职。这个过程很辛苦，也可能有磕磕绊绊，希望大家都能保持自信，或长或短的时间，找到自己理想的职业生涯下一站。
文章未经特殊标明皆为本人原创，未经许可不得用于任何商业用途，转载请保持完整性并注明来源链接 《四火的唠叨》