在计算机领域有一个非常经典的业务模型 —— IaaS、PaaS、SaaS，借助这个业务模型的区分，我们可以快速的给自己的产品找到定位。
但在看产品的时候，其实你不应该去关注这些技术维度 —— 或者说，你真正应该关注客户的问题，以及你如何看待这个问题。
当你关注问题的视角不同，你的产品形态也会完全不同。
举个例子：
当你去找你的产品的竞品的时候，除了去关注同一个层次的产品，也需要关注到哪些和你不是同一个层次，但解决的问题相似或类似的产品，这些东西会有助于你更好的理解自己的产品，并划分产品的界限。
今天在上班路上听播客听到了关于创业公司和大公司的事情（也可能是我看即刻看到的，记不清了）。提到了大团队和小团队的工作体验。刚好也聊一下自己的体验。
小团队
我进公司以来，其实大部分时间是在小团队工作 — 轻服务团队，20多个人，包含产研。虽然大家都是研发工程师，但细分为架构组、业务组、前端、产品组四个方向，每个组内几个人，坐在两排位置上。
在轻服务的工作体验最大的就是 —— 开心，我们只需要关注我们想要做的事情，把我们要做的事情做到最好就可以。不需要太过思考这个业务对于领导和公司的价值（我乐观的相信这个业务是有价值的，未来是可以成的）。我的日常工作是创造出一个新的东西来，去解决新的问题，价值感满满。
不过现在回过头来想想，我们当时之所以能做的那么开心，可能很大程度上是王潇在替我们负重前行，帮我们扛住了更大的压力，让我们可以更加的开心做想要做的事情。
大团队
来到开放平台后，我的工作模式不可避免的从一个小团队的模式变成了大团队的模式。开放平台单产品就有 20 人左右（产品+运营），加上研发，估计要百来人？
我们每个人工作的事情也会更加的细致和细分，每个人都在做一些更细致的问题。以我为例，我最近专注在如何让飞书开放平台的 OpenAPI 可以更好用。虽然说起 OpenAPI ，大家都觉得这是个小事，但想要做好还是有许多细分的事情要做。我需要在更加细分的领域深耕细作。
在小的领域深耕细作的价值感显然不如创建新的东西。但我觉得不一定是坏事，过去我的似乎都太过于野路子、创业公司化，深耕细作磨练一下自己是一个不错的选择。
在开放平台的另外一个感受就是 —— 责任，不同的 leader 的管理风格不同。有的 Leader 的风格好处是让每一个人都可以更加专心做自己想做的事情。另一方面也会失去承担更大责任的可能（因为责任都是Leader在扛）。另外的 Leader 显然对于我是有明确的预期的，对于我来说，我也感受到了这样的预期。对我自己而言，是一种压力，也是一种激励，希望自己可以达成那样的预期。
总结
大团队也好，小团队也罢，都有所得，挺好。在小团队野路子不是坏事，在大团队深耕细作也不是坏事，只知道这一种选择才是坏事。记得，参差多态乃是幸福本源。
飞书执行季 OKR 已经很久了，相比于过去的双月 OKR，我认为这确实是一个好的事情。季度 OKR 可以让我们在一个更长期的事情上来完成我们要达成的目标而无需担心自己所做的事情要更加的长远和长期，也期待更多的团队和协作方可以享受到季 OKR 的带来的长期。
但从另外一个方向来看，即使我们使用了季度 OKR，也需要关注执行的迭代。
OKR周期是我们达成目标的周期，而做事的手段则应该尽可能的敏捷和快速。快速判断、快速执行、快速复盘、快速修正。
目标大和周期长是我们要着眼于更重要、更长期的事情。而迭代的敏捷，则可以帮助我们更好更快的抵达目标。
作为一个技术出身的产品同学，我比较自豪的是，我不会提出一些非常离谱的需求。因为我大体上可以感知到技术的边界在哪里，但另外一个层面，我同样也会有比较严重的自我阉割的问题。
比如，如果某一个数据的要求严重超出了一般意义上的限制，我可能就会先自我阉割，认可这个事情虽然能做，但可能 ROI 划不过来，前置给了判断。但实际上，真的做不到么？未必，也可能只是我们没有去做。当然可能 ROI 上划不过来，但在产品对标和洽淡合作时，这些可能是会被客户挑战的问题：“为什么你不如 XXX”
下次做决策，要先多调研一下， 再做判断，不能让自己的技术脑完全占领了高地。
我们部门名字之前是叫「Integration and AI Solutions」，但坦白来讲，过去我一直没太理解这个部门的含义，加上自己的序列一直是产品，所以始终带着 Product 的帽子，而没太在意 Solution。但最近发生的一件事，让我更理解我们的部门名，以及，想清楚了更应该做什么。
作为 RD 出身的 PM，我不自觉的会将手头在做的事情进行抽象 —— 抽象出面向对象的类，避免面条式代码。这样做很好，我们尽可能的提升我们在做的事情的可复用性（从一个具体的事项中，抽象出可以服务更多的人的需求，这也太产品了）。但，这样也很坏，因为一但没有把握好度，就会陷入到无限抽象的怪圈里。虽然产品抽象出来了，但用户的问题并没有得到解决。很显然，我曾成为后者，忙于抽象和设计产品，而不是真正的解决问题。
而走过这个阶段，我所得到的教训便是：「做事应该先 Solution，后 Product」，你需要先为用户解决问题，产生价值，再思考如何通过抽象去服务于更多的人。如果过早的开启抽象，大概率会陷入到虽然设计的很好，但不落地，不解决问题的困境当中。
用户关心的不是你的 Product ，他只关心他的问题是否得到解决， Product 只是 Solution 的一环。如果连问题都没有解决，那你的 Product 又有何用呢？
我希望我的反思能够启发大家，在产品开发和解决方案提供之间找到合适的平衡点，共同进步。
在上次写完「为什么是产品决策优先级」之后，我也和身边的几个产品同学聊了聊我的推演逻辑，他们给了我不同的输入，让我觉得，这些内容应该分享出来，既帮我厘清了思路，也帮助我看到了不一样的产品。
首先是产品 A 同学， 他的观点很简单：产品经理之所以决策优先级，是因为产品经理为这个产品的最终结果负责。这个逻辑其实是从证明的视角来看的，虽然所有人都为产品结果负责，但运营同学可以通过篇一些其他指标来证明自己的价值 —— 比如运营指标好；研发同学可以通过技术指标来证明自己的价值。唯独产品经理别无选择 —— 他成功与否的评价唯一标准便是 —— 产品自身的成功与否。产品最终承担一个产品背后的所有结果，从权责利对等的视角来看，则应该由产品 —— 这个最终承担后果的人来作出决策。
其次是产品 B 同学，他的观点比较有意思，也给我带来了不同的视角：产品经理之所以需要决策优先级，是因为价值不明确，需要“有判断力”的人来做出价值判断。他给我觉得例子是早期头条研发，早期的头条研发在整个产研链路上是比较有话语权的， 原因是产品的收益相对明确 —— 调整某个策略，能够非常明确的计算和评估出 ROI，导致最终优先级和价值回收变得非常简单粗暴 ： 按照策略的预测上能力即可。相比于简单粗暴的广告 / C 端业务，B 端的业务显得收益不那么明确 —— 产品设计出一个功能，商业化团队未必能卖出去；商业化需要的功能，从产品视角来看，未必是适合产品定位的。从产品到商业化的长周期链路，使得对于产品的决策能力要求会更强 —— 需要产品能够从海量的信息中找到什么是最重要的？找到那个必须要做的事情。
这个是个好问题：
我的答案如下：
总结一下：
压力山大的时候，我就会选择去零食箱拿点零食，来消磨自己内心的压力（这也是为啥体重一直居高不下）。取零食多了，我开始有一些有意思的发现：
让我想到一个问题 — 如果我是餐饮同学，我会怎么做？
如果我希望零食被消耗的更快，那我会每次拍照或简单统计一下剩余的零食，然后大概可以知道不同楼层的零食偏好，并在下一次补仓周期里，重点补上那些大家消耗比较快的零食。这样可以让零食大量的被消耗。
如果我希望零食被消耗的更慢，那我会每次拍照并简单统计一下剩余的零食，这样可以大概知道大家不喜欢什么，在补仓周期里就可以进一步的补充大家不喜欢的零食，从而让零食可以被消耗的更慢。
我最近在用 Youtube 看《喜人奇妙夜》（毕竟 Youtube 上有纯享版，体验太好了）。同时，为了方便我可以在地铁/高铁上看，我还会使用 Youtube-DLP 下载到本地。但，Youtube DLP 下载到本地的视频文件往往名字都特别特别的长，比如：
【纯享】《看不见的TA》i人闫佩伦和“鬼怪”张佑维变室友？ ｜ 《喜人奇妙夜》Amazing Night EP3 SKETCH #喜人奇妙夜 #闫佩伦 #张祐维 [XUsi1R1Ny80].f614.mp4
这个内容长度中存在了大量的无用信息，虽然对于 Youtube 这样的视频平台来说，有助于流量和搜索，但对于我这样的本地存储用户来说，大大的影响了我的本地观感，因此，我一般都会手动移出其中的无用信息。只保留作品名和基础的介绍信息，比如上面的文件名我会修改成 《看不见的TA》i人闫佩伦和“鬼怪”张佑维变室友？.mp4。
当然，我可以写一个脚本来完成，但重命名这件事实在是太过于常见了，所以我也懒得写脚本（且脚本还需要指定路径，麻烦。），刚好，SetApp 套装中有一个 Renamer 的 App，可以解决这个问题，于是便有了这篇文章，介绍我自己是如何处理的。
Renamer 提供了多种重命名的能力，其中包括文本替换、正则表达式替换、数字、移出文本等多种能力，这些能力将会成为我稍后使用的工具。
如果看我们的文件名前后，可以很清晰的分辨出，我操作了两个部分：
因此，我需要用到两个模块，来实现替换 —— 正则表达式（Regular Expression） 和文本替换（Find & Replace）。
纯享因为是固定文本，所以替换比较简单，新增一个替换的动作，选择 Find & Replace，并配置只对文件名生效，设置 Find 为【纯享】，Replace 为空，就会在执行替换的时候，将【纯享】替换为空文本，来达到移除特定内容的效果。
当然， 同样的功能你还可以用移除文本来操作 —— 选择 Remove Text, 并把要移出的 【纯享】放在里面即可。
【纯享】因为是固定文本，相对简单，但后续的内容则就复杂了许多，其中的内容会变化，且包含了大量的 ID、标签等信息，单纯的 Find & Replace 是无法解决的，因此我们这里用到正则表达式替换来完成。
你可以借助于 Regexr 这个网站来调试你的正则表达式，在上方编写你的表达式，并在下方填写你的测试文本，通过高亮，即可判断是否正确匹配。
测试匹配正确后，复制上方的正则规则，在 Rename 中新增一个 Regular Expression 替换动作，配置成文件名 Only，并填入你的正则表达式。
最后，拖入你要修改名称的文件，就可以查看到批量修改文件名的效果了。这时你只需要拖入多个文件，就能一次性给 N 个文件完成更名的动作了。
在 X 上看到小橘子的这个信息，我觉得可以给一些我自己的输入。
从我自己的视角来看：如果你还愿意在这家公司工作，那么就应该继续持有。
接下来继续解释原因：
我这几年也在做一些投资，来满足自己在规律性的投资之外的动手的欲望。我卖飞过 NVDA、卖飞过 PDD、卖飞过 Microsoft。不过整体的收益还是正的，倒也还算是有一些心得。
期权可以理解为你所在公司的一部分权益，是兑换未来股票的机会。他代表着你对于一家公司的金钱的投入（虽然你并没有真实投入钱，但它也会占用同样钱的机会成本）。而你为一家公司工作，则是对这家公司的时间投入。
从这个视角来看，如果你觉得一家公司还不错 、还在增长，或还有增长的空间，你应该继续持有这家公司的期权或股票（至少这些不是卖出期权的理由）。那么，什么是我们卖出的理由？是我们发现更好的投资标的（比如你当前公司的增长是年化 10%，但你找到了年化 50% 的渠道）；或者是我们发现当前公司已经不是优质的资产（比如你的公司已经在走下坡路了，它已经无力增长）。
如果你的卖出期权的理由符合上述两者任一，那么不要犹豫，卖吧。此外，如果你发现卖出的理由是当前的公司已经不是优质的资产，我建议你额外加一层评估：我当前是否有必要继续在这家公司工作？避免金钱投入分散了风险，但大量的时间放在了垃圾的资产之上。以及，记得在离职的时候把你的所有期权出清（既然它对于你来说已经是劣质资产了，为什么不卖掉呢？）。
当然，上述的这些条件依然需要你自己判断。不过，如果你持有的是自己所在公司的期权，其实相对来说还是好判断的，因为你真的懂这家公司，你真的能够感受到它的好与坏。相比于不熟悉的投资经理来说，我们还是可能拿到更细节的信息辅助判断的。这些信息，足够让你判断是否要继续持有当前公司的期权了。
这个分享是我在 2024 年 5 月份的飞书 AI 训练营的分享，我觉得这个 PPT 的内容可以完美的诠释我对于 Hackathon 的态度，所以除了视频，我将文字稿也完整的撰写出来，希望让这篇文章对 Hackathon 感兴趣的你，能够有些帮助。
Hackathon 是一个起源于美国硅谷地区的创新技术活动，来自不同背景、技术各异的天才开发者们会现场组队，在 24 小时内进行代码开发、创造新的产品，以解决某一个具体的行业难题或痛点。
当然，得益于技术基建的发展，Hackathon 不再是工程师、开发者们的专属，借助于各种 Low Code、Zero Code 工具，非技术人员也可以打造出一个产品，来解决一个具体的问题。
Hackathon 有三个非常显著的特点，也是我个人非常喜欢 Hackathon 的原因：
我进一步解释一下我为什么认为短时高强度是 Hackathon 的精髓。
如果你做过力量训练，就知道有效的力量训练是让你在短时间内做最大力量的练习，以让你的肌肉发力，直至断裂的效果，并通过休息来让肌肉组织重新生长和链接。而Hackathon就有类似的效果，让你在一个很短的时间内去做一个看似不可能的事情，通过在这个极短时间内做事，来实现锻炼的效果。当你完成 Hackathon 之后，就可以复盘自己在 Hackathon 中的所作所为，并一次优化自己的下一步动作。
而且，因为Hackathon 本身的开放性，你可以在不同的 Hackathon 当中去锻炼不同的能力，第一场可以锻炼开发能力、第二场锻炼产品能力、第三场锻炼运营能力，以此类推，逐步把自己的各项能力的短板完成补上。
短时高强度另外的一个好处，便是沉默成本可控。我每次参加 Hackathon 的时候，都抱着：大不了这两天就浪费了的心态参加 Hackathon，因为就算我这次 Hackathon 一无所获，我也不过是浪费了 24 小时，周末在家躺平刷抖音也是浪费 24 小时，又会亏到哪里呢？而实际上，当我抱着这样的心态去参加 Hackathon，再配合自己多次参加 Hackathon 的经验进行一些基础的设计，我大部分时候都是有所收获的，甚至是大有所收获。
上面说了 Hackathon 的特点，接下来说说“你”为什么应该参加 Hackathon
为了学习新的技能
当你确定要参加一场 Hackathon 之后，马上就会面临组队和选题的问题了。组队不多说，每个人都有自己的风格，你可以选择强强联合，也可以选择百花齐放，自己喜欢就行，也往往不会成为大家困扰的内容。
而选主题往往会成为大家最困扰的问题，毕竟日常的工作当中，我们往往是在做命题作文，很少让你去自主命题。但 Hackathon 往往是不预设主题的，你需要自己去研究、发现，找到合适的主题。
从我自己的经验而言：
当然，找到这些问题可能不代表你马上会选择，很多时候，我们会担心自己选择的问题很小，不值得我们去解决。这里我的观点是：问题大小并不是关键，关键在于这个问题是否有价值，以及你是否能够在 Hackathon 的时间范围内解决它。毕竟没有人预期你会在一个 Hackathon 当中解决光刻机的问题。
当你真的打算去解决这个问题的时候，如果无法判断自己的问题是否有价值，一个最简单的方法是，先想清楚自己要解决谁的问题，然后找到符合这个画像的人，去问问他，给他提供这样的解决方案，是否可以满足他的问题。
对于没有项目管理经验的人来说，Hackathon 是一个完美锻炼自己项目管理能力的试炼场。因为这是一个资源有限（3~5个人，24~72小时，满打满算 15 人天），同时 DDL 明确、目标明确的项目。
你需要在项目的开始时，找到项目最重要的P0、P1、P2，并安排好人、事物，让大家知道自己在什么时候应该做什么事情。此外，你还需要为项目规划合理的 Milestone，以便于检查项目的执行情况，降低风险，并尽早的发现风险点位，解决风险。
当你能够做好一个 Hackathon 项目的项目管理，那么对于一些小团队内部协作的项目管理，你便有了基础的经验，下次自己去做项目的时候，也就不会那么的焦虑。
在 Hackathon 的最后，一般是项目的路演。对于路演，我只有一句忠告：“项目路演很重要，要当成一件事来规划”。
我们在 Hackathon 的前半程都是在设计和实现产品，是一个”做产品“的过程，而路演，则是”卖产品“的过程，你要让评委 Buy in，让你的目标受众 Buy in。在 Hackathon 当中，你即要能做产品，也要能卖产品。毕竟，现在是一个酒香也怕巷子深的时代。
把路演当成一件事，提前规划和留出时间做你的演示文稿，可以有效降低你在路演过程中的风险，同时如果可以的话，至少演练 1~２次你的演示文稿，以确保每个视频＼动图＼文字都是正确且易于理解的。
在你的路演过程中，如果有一些演示，可以用录制好的动图、视频，这样可以从整个过程中“偷时间”，将真实的产品演示放在最后，这样如果你的路演还不错，评委会给你时间让你演示完，以查看实际的效果，你就有了更多的时间去表达自己的主张。
以及，提前想想，假设你是评委，你会怎么挑战自己的项目？这样提前做好准备，就能更好的去应对评委的提问。
以上的这些，是我自己参加 Hackathon的一些经验分享。希望能帮到你，同时，也希望你能享受 Hackathon，感受 Hackathon 的魅力，把 Hackathon 当成一种生活方式来体验。
今天参加一个线下活动，和朋友聊起来对于 AI 的恐惧和焦虑，问我该不该引导孩子去接触这一轮的 AGI 工具、接触这些 AI 工具。
我给了一些建议：首先，我认为我们应该给孩子接触 AI 工具。AI 的大趋势是不可逆的，基于这个前提，我们不应该抗拒孩子去接触 AI，甚至应该尽早的让孩子去建立 AI 的认知，知道什么是 AI 能做的，什么是 AI 不能做的，已经应该明确 AI 和 人类的价值边界。
在聊天过程中，我们聊到了如何用 AI，我自己的观点是：
我们需要让孩子知道如何提问，以及区分出它是工具还是目的。工具掌握用法，并要明确我们的目的是什么。
剩下的，让他自己去玩就好啦。
基于上述的认知，我认为现在可以推荐的工具如下：
如果可以，当然是给孩子用最好的。但这个有门槛，以及作为家长，你可能要考虑 ChatGPT 本身是有风险的，可能会输出一些你不希望的内容（比如色情、暴力之类的）。
推荐程度： 5 🌟。
AI 搜索，体验很不错。如果孩子有搜索和探索的欲望，那么这个可能会比 Google 会是一个更好的体验。
推荐程度：5🌟
秘塔搜索的研究模式，比较适合孩子做一些方向的研究。可以让孩子在日常学习和生活过程中，有问题，提问。
推荐程度：5🌟。
在和这个家长聊的时候，发现现在缺乏一个 For 家庭教育场景下的GPT产品。这个产品的客户是家长，用户则是孩子。
和标准的大模型 、 产品之类的区别，是提供一些家长控制能力，这样会让家长们减少焦虑。
但我内心的另外一个声音告诉我：真的做出来，可能孩子也不会用，更好的办法是在现有的产品上加入家长控制模式。
每年我都会给自己开一些新的坑，用于探索新的技术方向、新的领域。2024 年，我的新项目是 —— Read it!
Read it! 是一个用于分享我自己觉得不错的文章、网站的地方， 你可以在这里看到我日常浏览网页过程中发现的不错的网站、文章。
我会在分享链接的过程中，加上一些我自己的看法、总结。
readit.ixiqin.com，就可以看到我分享的网站。https://readit.ixiqin.com/rss/bookmarks/ 贴在你的 RSS 阅读器里，就可以查看到它。我是湾区日报的读者，也很喜欢湾区日报的形式。包括过去也尝试过用 WordPress 之类的系统来搭建类似的形态。但，繁琐的操作会消磨我分享的耐心。
最近又在整理书签，加上也开始进行一些大模型应用的开发，所以决定借助大模型来帮助我自己完成一些工作，就重新搞起了 Read it! 这个项目。
Read it! 目前的工作模式挺简单的，我找到觉得不错的文章，直接在 IM 里发给他，他会自动解析我的意图，并将解析出来的结果录入到系统当中，给大家看。想来这样的交互可以让这个项目活得更久一些～
Read it! 可以理解为是我自己再看的各种文章，所以并不会局限领域、方向，只要是我自己看的觉得有收获的，我都会分享。后续会考虑提供分标签的订阅方式，这样你可以选择只订阅自己喜欢的文章。
在开发前端应用的时候，我比较推荐在真正开始写代码之前试着画一画组件树 / 状态树。
在很多时候，可能你的设计师已经帮你做好了组件树，但在某些场景下，你的设计时并不会帮你拆解组件树，或者是你是直接和产品经理对接，他不会帮你拆解组件树。
这个时候，相比于写代码，我更推荐你先拆解组件树，在完成组件树之后，再开始你的 Coding。
Figma / Sketch 之类的软件提供的分组能力、图层的能力，可以帮助你将组件合理的拆解、分组、归类。当你完成树的建设之后，可以试试看将不同的模块拆解，每个模块是否可以独立正常的运转。如果不可以，则说明你的状态拆解的可能是有问题的。
当你完成拆解之后，只需要按照你拆解出来的树组织你的 Component 即可。
作为一个非典型 i 人，我因为电池容量极大，导致尝尝被人认为是一个 e 人。但坦白来讲，我真的是一个 i 人。因为我知道，自己其实能表现的很 e，不过是因为我的电量足够大给大家的错觉。一旦我在社交中消耗了自己的能量，便需要通过写作和整理，来疗愈自己，给自己充充电。
写作可以让我梳理脑海中纷乱的思维，强迫自己按照结构化的思维来思考问题，并尝试梳理脑海中的问题。我长期自己积累的 memos，则可以确保我总是有的写、有想写的内容。
整理则可以让我放空大脑，专心思考眼前的事物应该分到哪个类目，并将其放置到合适的位置。
你的自我疗愈手段是什么呢？
在入住杭州「菲住不渴」酒店时，其全屋智能让我感受颇深，整体体验也不错。但在入住的过程中，我也发现这个酒店中的一些不适的点位。而这些不适的点位，正是我们没有考虑到用户的需求，以我们自己的傲慢，来让用户「学习使用」。
一个典型的例子是，菲住不渴酒店的卫生间大灯是没有开关的，当你早上起床时，你想要上厕所，你需要喊「天猫精灵，打开卫生间灯」。当我做这个动作的时候，我感受到了设计师深深的优越感以及我对于这个设计的不适。
我是一个人入住的酒店，这个状态可能还是可以接受的。但假如这个是一对夫妻、一组同事来入住。早起开灯去卫生间的代价是让另外一个人苏醒，这个设计有点愚蠢。设计师很相信天猫精灵的能力，但没有考虑到这个可能并不是一个适合的场景。
我们在设计产品功能的时候，应该充分的考虑用户的使用场景，以及需要给用户提供必要的降级方案（比如这个 Case 中，卫生间提供一个开关即可），不要让我们的优越感支配我们，设计出强迫用户的选择。
最近去杭州住了一下阿里的「菲住不渴酒店」，感受一下阿里巴巴对于未来酒店的定义。其中有好有坏。这里简单描述一下我自己的个人体验。
菲住不渴酒店的整体设计风格是比较简约且具备「未来感」，如果用一个更具象的描述的话，就是整个酒店充斥着弧角和多彩灯光，使得整个酒店从设计上给人以「未来感」、「科幻电影」感。
整体的设计偏简约，猛地一看，和过去我们熟悉的各种酒店是完全不同的，的确从设计上来看更加的「未来」。
房间内部的设计延续了酒店整体的设计风格，以白色、弧线为主。清冷的性格对于喜欢雍容华贵的带娃家庭，可能不是一个好的选择，但对于出差、热爱科技感的年轻人来说，还是一个可以体验的选项。
菲住不渴酒店的一大特色是其智能化，所以其屋内放置了大量的智能化设备（虽然并不一定能每个都串起来），让没有使用过智能家居的人来说，可以快速感受到各种智能设备带来的好处。
首先，第一个会让你感到 Aha 的，是房间的人脸识别门锁，这个门锁是我整个入住过程中，体验最深刻的。你不再需要担心出门是不是没有带门卡，只要走到房间门口，人脸识别，就能进入房间。对于容易丢三落四的人来说，真的是福音。
房间内有一个天猫精灵，你可以睡觉的时候让它帮你关闭整个房间的所有灯光，就不用自己起床来关灯了（这一点很好，当然你也可以自己在家整一套智能家居）。
此外，床头给你准备了无线充电，你可以把手机放在上面充电，数据线可以安心的放在行李箱当中，来使用。
菲住不渴的酒店参数是朝着五星级酒店的方向去对标（但显然没有那么好啦），比起我们常住的全季、亚朵，是要好上不少的。
早餐当中有面包、咖啡、水果、凉菜、热菜、面档（云吞）、缙云烧饼、寿司、蒸档。对于住的人来说，虽不能比拟五星级酒店，但也绝对算得上是不错的一餐了。
菲住不渴酒店的位置在阿里巴巴西溪园区，所以对于要到阿里巴巴办事的人来说，住这家酒店会非常方便。但如果你是来旅游的，那这个酒店就不是太推荐了，主要还是离市区太远了，中间隔着一个西溪湿地，并不是一个适合旅游者入住的酒店。
整体来说，我认为菲住不渴的住宿体验是可以接受的。虽然号称智能未来酒店，但在如今各家都有了送外卖机器人；各家也都会在自己的房间配置一些基本的智能家居设备的时候，菲住不渴酒店就没有那么显眼。
但另一个层面，这家酒店创办于 2018 年，如果用 2018 年的视角来看，那菲住不渴的确可以称得上是「未来酒店」。
但如今的我们再去，就当成一个普通酒店入住就好啦。
最近这几天，大量的南方游客涌入哈尔滨，在哈尔滨吃喝玩乐。在这个过程中，当地人对于南方游客的爱称引起了我的注意 —— 「小土豆」。
当然，我并不打算指责当地人或游客，各自有各自的想法和诉求。当地人希望用爱称来虚拟化所有的游客，以拉近距离。而游客则希望找到自己的认同感，从而快速定位自己和他人的区别。
我更关注的是 —— 昵称爱称这件事本身。
假设两个人毫无关系，完全平等，我们一般都是直接喊名字，甚至是直接「美女你好」、「帅哥你好」。但当其中一方对另一方有明显的诉求时，昵称就会开始弱化自己，抬高他人。就像技术圈喊「大神」一方面是认可大神的能力，另一方面则是希望大神给自己提供一定的帮助。
当我们被某些昵称 / 称呼感受到不满 / 舒服时，我们需要想想，这个称呼/这个描述的背后，是他对于我们什么样的预期？