[分享发现] 昨天我送走了 5 位同事
前言
昨天送走了五个同事，两个人跟我进行了交接。 明白回到这一天，但是没想到这么快。
2024 被裁
2024 年， 我被上家公司裁员，开开心心拿了大礼包。随后开始找工作，找了 1 个月，免了近 20 家， 在社保没有断缴的情况下入职了。
2024 入职
如果说有那么一家创业公司，大家跟随着三个创始人满腔热血的进入 AI 事业， 背靠上市公司。 在 AI 泡沫越来越大的 2024 年， 大家充满干劲，我估计我还是会再选一次，哈哈哈。
一起努力
大家经为了参加 WAIC （世界人工智能大会），经历过熬夜加班， 跟摄像老师反复确定 demo 。 用的 F3 拍摄，但是最终播放在大果冻屏幕上；
也经历过为了商业化项目，连续 9-12-5 ， 干了两周，大家后面都请了病假。 虽然后续没卖多少；
也为了机器人项目出差熬夜 虽然也快黄了；
风向变了
创始人是公司的灵魂， 但是身体已经被卖给了资本，身不由衷。方向是集团控制的，在沟通不顺的情况下，CXO 还是选择离职， 当创始人离开的时候， 这个公司基本上就是没了。在 3 个月后，也就是今天， 基本上这层楼的空了。我也送走了很多同事。 当然谁 tm 来送我呢， 估计大礼包都会因为申请破产而泡汤。
下一步
如果不出意外，我可能会再更新一版《 2026 提桶记录》
不过这一次，我打算给我自己半年的时间， 这一次我要为自己加班，这一次我要为谈客户，签合同。 总之感谢公司，感谢集团，给我这两年的时间成长。 如果不是今年安排我去趟深圳，可能我还是会去找工作，男人到了年纪，真的会想做自己的事情。 也感谢 AI 这个时代，不论结果， 还是得试一试。
via V2EX (author: 312ybj)
前言
昨天送走了五个同事，两个人跟我进行了交接。 明白回到这一天，但是没想到这么快。
2024 被裁
2024 年， 我被上家公司裁员，开开心心拿了大礼包。随后开始找工作，找了 1 个月，免了近 20 家， 在社保没有断缴的情况下入职了。
2024 入职
如果说有那么一家创业公司，大家跟随着三个创始人满腔热血的进入 AI 事业， 背靠上市公司。 在 AI 泡沫越来越大的 2024 年， 大家充满干劲，我估计我还是会再选一次，哈哈哈。
一起努力
大家经为了参加 WAIC （世界人工智能大会），经历过熬夜加班， 跟摄像老师反复确定 demo 。 用的 F3 拍摄，但是最终播放在大果冻屏幕上；
也经历过为了商业化项目，连续 9-12-5 ， 干了两周，大家后面都请了病假。 虽然后续没卖多少；
也为了机器人项目出差熬夜 虽然也快黄了；
风向变了
创始人是公司的灵魂， 但是身体已经被卖给了资本，身不由衷。方向是集团控制的，在沟通不顺的情况下，CXO 还是选择离职， 当创始人离开的时候， 这个公司基本上就是没了。在 3 个月后，也就是今天， 基本上这层楼的空了。我也送走了很多同事。 当然谁 tm 来送我呢， 估计大礼包都会因为申请破产而泡汤。
下一步
如果不出意外，我可能会再更新一版《 2026 提桶记录》
不过这一次，我打算给我自己半年的时间， 这一次我要为自己加班，这一次我要为谈客户，签合同。 总之感谢公司，感谢集团，给我这两年的时间成长。 如果不是今年安排我去趟深圳，可能我还是会去找工作，男人到了年纪，真的会想做自己的事情。 也感谢 AI 这个时代，不论结果， 还是得试一试。
via V2EX (author: 312ybj)
[Apple] IOS 的黑苹果是不是不远了
https://github.com/oosexgang/hackios-xnu-kernel 这个项目把 IOS16.5 安装在了安卓手机上，不过没有蜂窝网络和 applestore ，但是可以在 wifi 下巨魔自己装软件吧
via V2EX (author: Himmel)
https://github.com/oosexgang/hackios-xnu-kernel 这个项目把 IOS16.5 安装在了安卓手机上，不过没有蜂窝网络和 applestore ，但是可以在 wifi 下巨魔自己装软件吧
via V2EX (author: Himmel)
[分享创造] 花了两周做了个 bra size 计算器，纯静态 + Cloudflare Pages，聊聊选词和计算逻辑
最近花了两周时间，做了一个面向美国用户的 bra size 计算器： https://brascale.com/
整个站是纯静态的，没有后端、没有数据库，部署在 Cloudflare Pages 上。目前做了四个页面，核心功能就是根据用户输入的身体围度，计算一个参考内衣尺码。
做这个项目的初衷很简单：想试试用一个足够轻量的工具站，从关键词研究、页面设计到计算逻辑，再到 SEO 部署，完整跑一遍流程。
记录一下过程中比较值得分享的几个地方。
一、为什么选这个方向？
一开始并没有直接写代码，而是先看关键词。
美国用户搜索内衣尺码相关问题时，会涉及很多不同的搜索意图，比如：
● bra size calculator
● band size calculator
● sister size calculator
● bra size conversion
这些词看起来都和同一个需求有关，但用户真正想解决的问题不完全一样。
主词的竞争通常比较激烈，成熟的大站已经有相对完善的页面、外链和品牌积累。新站如果一上来就想竞争最宽泛的关键词，可能很长时间都没有什么结果。
所以我选择先从细分需求入手。
比如，有的人只想知道自己的下胸围应该对应什么 band size；有的人已经知道自己的尺码，只是想找姊妹码；还有的人想弄明白英寸和厘米之间的换算。
这些需求虽然相关，但完全可以分别设计页面，让每个页面尽量解决一个明确的问题。
这里也不是说长尾关键词一定比主词容易做，而是对于一个没有太多资源的新站，先把具体需求研究清楚，比直接冲最热门的词更有操作性。
关键词研究最后还是要回到搜索结果本身：看看现有页面解决了什么问题、有没有信息缺口，以及自己能不能做出更清晰、更方便使用的工具。
二、尺码计算逻辑，比写页面麻烦多了
这是整个项目里我觉得最值得花时间研究的部分。
内衣尺码计算并不是简单地把两个数字相减，再查一张表就完事了。不同品牌、国家和计算体系可能存在差异，如果直接照搬网上的一张旧表，很容易出现结果看起来合理、实际上却不太对的情况。
我在实现时，主要处理了下面几个问题。
1. 统一计算单位
内部计算以英寸为基准。
如果用户输入的是厘米，先转换成英寸：
inches = cm / 2.54
这样后续的 band、bust 和 cup 计算都使用同一套单位，避免在不同单位之间反复计算造成误差。
显示结果时再根据用户选择的单位进行转换。
2. Band size 怎么取？
这里采用下胸围取最近偶数的规则。
例如，下胸围测量值是 31 英寸，按最近偶数取值会得到 32 band。
这个步骤看起来简单，但需要注意测量值处于两个偶数中间时的处理方式，以及输入精度和四舍五入规则，否则不同页面可能算出不同结果。
3. Cup size 怎么算？
基本思路是用上胸围与下胸围之间的差值作为参考：
差值 = 上胸围 − 下胸围
然后根据差值映射到对应的罩杯。
我采用的映射规则中，差值小于 1 英寸时对应 AA，后续再按照设定的区间映射到其他罩杯。
这里需要强调一点：这是一套明确的计算规则，不代表所有品牌都使用完全相同的尺码体系。实际穿着效果还会受到品牌版型、胸型和测量方式的影响。
4. 姊妹码怎么换算？
姊妹码（Sister Sizes）的基本规律是：
● Band 增加 2，Cup 字母通常向下调整一级。
● Band 减少 2，Cup 字母通常向上调整一级。
例如，34C 的姊妹码通常包括 32D 和 36B。
原理是通过调整下胸围，同时调整罩杯容积，使不同尺码之间尽量保持接近的罩杯容量。
实现时不能只做字符串替换，还要处理罩杯字母的顺序、边界情况，以及不同尺码体系的差异。
5. 最麻烦的是 plus-four 算法
我在研究旧尺码表时，发现一个很容易造成误判的问题：plus-four 算法。
一些传统计算方法会先根据下胸围增加 4 英寸，再推算 band size。
这会产生一个很明显的差异：29–30 英寸的下胸围，经过某些旧式规则处理后，可能会被归到 34 band。
如果用户习惯的是不额外加 4 英寸的现代测量方式，这个结果就可能让人困惑。
因此，我没有直接把网上找到的旧 chart 当成唯一标准，而是明确采用自己的计算规则，并尽量让输入、换算和结果展示遵循同一套逻辑。
这也是我觉得工具站开发中很容易被低估的一件事：代码本身可能只需要几十行，但你得先搞清楚自己到底在实现哪一种规则。
三、为什么选纯静态 + Cloudflare Pages？
目前整个网站使用纯静态页面，没有专门的后端服务，也没有数据库。
选择这套方案，主要有几个原因：
1. 计算可以在浏览器本地完成。 用户输入围度后，直接通过 JavaScript 计算结果，不需要把数据发送到服务器。
2. 部署简单。 页面构建完成后直接部署到 Cloudflare Pages，不需要维护服务器、数据库和 API。
3. 访问速度和维护成本比较友好。 对于计算逻辑简单、数据量不大的工具站，没有必要为了技术架构而增加复杂度。
另外，页面里的图形尽量使用内联 SVG，而不是随便找一些模特照片或者商品图片。
一方面是版权问题，另一方面是工具本身也不需要大量照片才能完成任务。
如果以后考虑接入 AdSense，图片版权和页面内容质量也值得提前考虑。不过，使用 SVG 并不意味着自动符合 AdSense 政策，最终还是要看整个网站的内容质量、实用性和政策合规情况。
对这种小型工具站来说，我更倾向于先把核心功能和页面体验做好，而不是先堆很多视觉元素。
四、部署和 SEO 过程中踩过的坑
纯静态站不代表上线就万事大吉，域名和搜索引擎相关的细节也需要处理。
1. www 和裸域的统一
例如：
● brascale.com
● www.brascale.com
如果两个地址都能正常访问，却没有统一的规范域名，可能会给网站的索引和维护带来不必要的复杂性。
所以需要明确一个主域名，并将另一个域名通过 301 重定向过去。
这里要注意，不只是首页，其他页面的路径也应该正确保留，避免所有地址都被错误地重定向到首页。
2. Sitemap 和规范 URL
Sitemap 需要列出希望搜索引擎发现的规范页面地址，并且确保这些地址实际可以正常访问。
我在处理 URL 时也特别关注了尾斜杠的一致性。
严格来说，sitemap 并不是必须全部带尾斜杠，而是要和网站实际使用的规范 URL 保持一致。如果
因此，最好提前确定 URL 规则，再统一处理页面内部链接、canonical 标签和 sitemap。
3. 纯静态网站也需要考虑 SEO
工具站很容易出现一种情况：功能确实能用，但搜索引擎看到的页面内容非常少。
所以每个页面除了计算器本身，还需要清楚地解释：
● 这个工具解决什么问题；
● 输入的数据应该如何测量；
● 计算结果是怎么得出的；
● 结果有哪些局限；
● 用户接下来可以做什么。
这些内容不只是为了 SEO，也是为了让用户真正理解计算结果。
五、接下来准备观察什么？
网站上线只是第一步，接下来更值得关注的是实际数据。
我比较关心几个问题：
● 细分关键词能不能带来真实的搜索流量；
● 用户更常使用主计算器，还是某个具体的细分工具；
● 搜索用户进入页面后，是否真的完成计算；
● 哪些页面值得继续投入时间优化。
对小工具站来说，开发完成并不意味着项目验证成功。真正重要的是能不能找到明确的用户需求，并通过搜索流量持续获得用户。
如果最后发现某些关键词没有流量，或者用户需求和预期不一致，也需要根据数据调整，而不是不断增加功能。
目前先把第一版跑起来，后续再根据真实反馈迭代。
网站放这里： https://brascale.com/
如果大家也做过面向海外用户的纯静态工具站，尤其是通过 SEO 获取自然流量的，欢迎交流一下：你们通常会先做一个覆盖面比较广的主工具，还是先从几个具体的长尾需求切入？
via V2EX (author: sobinyuan)
最近花了两周时间，做了一个面向美国用户的 bra size 计算器： https://brascale.com/
整个站是纯静态的，没有后端、没有数据库，部署在 Cloudflare Pages 上。目前做了四个页面，核心功能就是根据用户输入的身体围度，计算一个参考内衣尺码。
做这个项目的初衷很简单：想试试用一个足够轻量的工具站，从关键词研究、页面设计到计算逻辑，再到 SEO 部署，完整跑一遍流程。
记录一下过程中比较值得分享的几个地方。
一、为什么选这个方向？
一开始并没有直接写代码，而是先看关键词。
美国用户搜索内衣尺码相关问题时，会涉及很多不同的搜索意图，比如：
● bra size calculator
● band size calculator
● sister size calculator
● bra size conversion
这些词看起来都和同一个需求有关，但用户真正想解决的问题不完全一样。
主词的竞争通常比较激烈，成熟的大站已经有相对完善的页面、外链和品牌积累。新站如果一上来就想竞争最宽泛的关键词，可能很长时间都没有什么结果。
所以我选择先从细分需求入手。
比如，有的人只想知道自己的下胸围应该对应什么 band size；有的人已经知道自己的尺码，只是想找姊妹码；还有的人想弄明白英寸和厘米之间的换算。
这些需求虽然相关，但完全可以分别设计页面，让每个页面尽量解决一个明确的问题。
这里也不是说长尾关键词一定比主词容易做，而是对于一个没有太多资源的新站，先把具体需求研究清楚，比直接冲最热门的词更有操作性。
关键词研究最后还是要回到搜索结果本身：看看现有页面解决了什么问题、有没有信息缺口，以及自己能不能做出更清晰、更方便使用的工具。
二、尺码计算逻辑，比写页面麻烦多了
这是整个项目里我觉得最值得花时间研究的部分。
内衣尺码计算并不是简单地把两个数字相减，再查一张表就完事了。不同品牌、国家和计算体系可能存在差异，如果直接照搬网上的一张旧表，很容易出现结果看起来合理、实际上却不太对的情况。
我在实现时，主要处理了下面几个问题。
1. 统一计算单位
内部计算以英寸为基准。
如果用户输入的是厘米，先转换成英寸：
inches = cm / 2.54
这样后续的 band、bust 和 cup 计算都使用同一套单位，避免在不同单位之间反复计算造成误差。
显示结果时再根据用户选择的单位进行转换。
2. Band size 怎么取？
这里采用下胸围取最近偶数的规则。
例如，下胸围测量值是 31 英寸，按最近偶数取值会得到 32 band。
这个步骤看起来简单，但需要注意测量值处于两个偶数中间时的处理方式，以及输入精度和四舍五入规则，否则不同页面可能算出不同结果。
3. Cup size 怎么算？
基本思路是用上胸围与下胸围之间的差值作为参考：
差值 = 上胸围 − 下胸围
然后根据差值映射到对应的罩杯。
我采用的映射规则中，差值小于 1 英寸时对应 AA，后续再按照设定的区间映射到其他罩杯。
这里需要强调一点：这是一套明确的计算规则，不代表所有品牌都使用完全相同的尺码体系。实际穿着效果还会受到品牌版型、胸型和测量方式的影响。
4. 姊妹码怎么换算？
姊妹码（Sister Sizes）的基本规律是：
● Band 增加 2，Cup 字母通常向下调整一级。
● Band 减少 2，Cup 字母通常向上调整一级。
例如，34C 的姊妹码通常包括 32D 和 36B。
原理是通过调整下胸围，同时调整罩杯容积，使不同尺码之间尽量保持接近的罩杯容量。
实现时不能只做字符串替换，还要处理罩杯字母的顺序、边界情况，以及不同尺码体系的差异。
5. 最麻烦的是 plus-four 算法
我在研究旧尺码表时，发现一个很容易造成误判的问题：plus-four 算法。
一些传统计算方法会先根据下胸围增加 4 英寸，再推算 band size。
这会产生一个很明显的差异：29–30 英寸的下胸围，经过某些旧式规则处理后，可能会被归到 34 band。
如果用户习惯的是不额外加 4 英寸的现代测量方式，这个结果就可能让人困惑。
因此，我没有直接把网上找到的旧 chart 当成唯一标准，而是明确采用自己的计算规则，并尽量让输入、换算和结果展示遵循同一套逻辑。
这也是我觉得工具站开发中很容易被低估的一件事：代码本身可能只需要几十行，但你得先搞清楚自己到底在实现哪一种规则。
三、为什么选纯静态 + Cloudflare Pages？
目前整个网站使用纯静态页面，没有专门的后端服务，也没有数据库。
选择这套方案，主要有几个原因：
1. 计算可以在浏览器本地完成。 用户输入围度后，直接通过 JavaScript 计算结果，不需要把数据发送到服务器。
2. 部署简单。 页面构建完成后直接部署到 Cloudflare Pages，不需要维护服务器、数据库和 API。
3. 访问速度和维护成本比较友好。 对于计算逻辑简单、数据量不大的工具站，没有必要为了技术架构而增加复杂度。
另外，页面里的图形尽量使用内联 SVG，而不是随便找一些模特照片或者商品图片。
一方面是版权问题，另一方面是工具本身也不需要大量照片才能完成任务。
如果以后考虑接入 AdSense，图片版权和页面内容质量也值得提前考虑。不过，使用 SVG 并不意味着自动符合 AdSense 政策，最终还是要看整个网站的内容质量、实用性和政策合规情况。
对这种小型工具站来说，我更倾向于先把核心功能和页面体验做好，而不是先堆很多视觉元素。
四、部署和 SEO 过程中踩过的坑
纯静态站不代表上线就万事大吉，域名和搜索引擎相关的细节也需要处理。
1. www 和裸域的统一
例如：
● brascale.com
● www.brascale.com
如果两个地址都能正常访问，却没有统一的规范域名，可能会给网站的索引和维护带来不必要的复杂性。
所以需要明确一个主域名，并将另一个域名通过 301 重定向过去。
这里要注意，不只是首页，其他页面的路径也应该正确保留，避免所有地址都被错误地重定向到首页。
2. Sitemap 和规范 URL
Sitemap 需要列出希望搜索引擎发现的规范页面地址，并且确保这些地址实际可以正常访问。
我在处理 URL 时也特别关注了尾斜杠的一致性。
严格来说，sitemap 并不是必须全部带尾斜杠，而是要和网站实际使用的规范 URL 保持一致。如果
/page 和 /page/ 的处理不统一，就可能出现重复 URL、重定向链或者错误的规范地址。因此，最好提前确定 URL 规则，再统一处理页面内部链接、canonical 标签和 sitemap。
3. 纯静态网站也需要考虑 SEO
工具站很容易出现一种情况：功能确实能用，但搜索引擎看到的页面内容非常少。
所以每个页面除了计算器本身，还需要清楚地解释：
● 这个工具解决什么问题；
● 输入的数据应该如何测量；
● 计算结果是怎么得出的；
● 结果有哪些局限；
● 用户接下来可以做什么。
这些内容不只是为了 SEO，也是为了让用户真正理解计算结果。
五、接下来准备观察什么？
网站上线只是第一步，接下来更值得关注的是实际数据。
我比较关心几个问题：
● 细分关键词能不能带来真实的搜索流量；
● 用户更常使用主计算器，还是某个具体的细分工具；
● 搜索用户进入页面后，是否真的完成计算；
● 哪些页面值得继续投入时间优化。
对小工具站来说，开发完成并不意味着项目验证成功。真正重要的是能不能找到明确的用户需求，并通过搜索流量持续获得用户。
如果最后发现某些关键词没有流量，或者用户需求和预期不一致，也需要根据数据调整，而不是不断增加功能。
目前先把第一版跑起来，后续再根据真实反馈迭代。
网站放这里： https://brascale.com/
如果大家也做过面向海外用户的纯静态工具站，尤其是通过 SEO 获取自然流量的，欢迎交流一下：你们通常会先做一个覆盖面比较广的主工具，还是先从几个具体的长尾需求切入？
via V2EX (author: sobinyuan)
[问与答] 如果，我是说如果，谈婚论嫁时，女方父母提出让男方婚后工资给女方管理，怎么破局。
女方家经济情况不差，女方不是那种以父母为首的人，女方父母接触下来也不是那种不讲道理的人。
彩礼三金之前和女朋友沟通过，都是正常范围，大概是 8-10 区间，给到女朋友，女方父母同样给这么多给女朋友。
女方年收入 14w 左右
男方年收入 30w 左右，房贷剩 50 w
如果，我是说如果，万一谈结婚时女方父母为了给女方争取到最大的利益，问出了这个话，在不破坏关系的前提下怎么破局。
比较明确的是不可能给女方管理，最多共同账户，当然用随便用。
问这个是因为女朋友说她妈妈私下问过她这个问题说婚后双方资金怎么管理。
via V2EX (author: PoorGuy188)
女方家经济情况不差，女方不是那种以父母为首的人，女方父母接触下来也不是那种不讲道理的人。
彩礼三金之前和女朋友沟通过，都是正常范围，大概是 8-10 区间，给到女朋友，女方父母同样给这么多给女朋友。
女方年收入 14w 左右
男方年收入 30w 左右，房贷剩 50 w
如果，我是说如果，万一谈结婚时女方父母为了给女方争取到最大的利益，问出了这个话，在不破坏关系的前提下怎么破局。
比较明确的是不可能给女方管理，最多共同账户，当然用随便用。
问这个是因为女朋友说她妈妈私下问过她这个问题说婚后双方资金怎么管理。
via V2EX (author: PoorGuy188)
[问与答] 理性讨论，是平台激发了人性的恶还是人性本来的恶找到了展现的平台
前几天 Pdd 下单了几个小工具，由于是用的多选模式，下单后订单显示一个店四个订单，然后昨天一大早突然给我发了四张无门槛券，原因是发货超时，然后我发现这个无门槛券总价值超过订单总价了，等于我没啥损失还赚了，然后昨天商家还是没发货，我晚上的时候就退货了，下单了另外一家，事后我想如果我不退货是不是商家要亏钱做这笔生意，我甚至还幻想过要是一直不发货会不会平台还会继续给我赔偿券，联想到这几年那么多离谱的仅退款事件，放以前谁会想到退货退款可以不给商家把货退回去，到底是平台在培养人性的恶还是人性的恶找到了发挥的平台。（已经给那个商家发了红包，退回了无门槛券的等值金额）
via V2EX (author: Atlas058)
前几天 Pdd 下单了几个小工具，由于是用的多选模式，下单后订单显示一个店四个订单，然后昨天一大早突然给我发了四张无门槛券，原因是发货超时，然后我发现这个无门槛券总价值超过订单总价了，等于我没啥损失还赚了，然后昨天商家还是没发货，我晚上的时候就退货了，下单了另外一家，事后我想如果我不退货是不是商家要亏钱做这笔生意，我甚至还幻想过要是一直不发货会不会平台还会继续给我赔偿券，联想到这几年那么多离谱的仅退款事件，放以前谁会想到退货退款可以不给商家把货退回去，到底是平台在培养人性的恶还是人性的恶找到了发挥的平台。（已经给那个商家发了红包，退回了无门槛券的等值金额）
via V2EX (author: Atlas058)
[酷工作] 字节 Data｜ 2027 届全职与实习岗位（个人内推）
字节跳动 Data ｜ 2027 届全职与实习岗位（个人内推）
对大模型、推荐、搜索、广告感兴趣的同学看过来。字节 Data 团队开放 2027 届全职和实习岗位，方向包括：电商推荐 × LLM 、国际电商大模型应用、搜索 / 广告 / 推荐、数据知识系统。地点：新加坡、西雅图、圣何塞。
岗位一览（个人整理，非官方）： https://datajobs-refer.xyz
内推码：41KCZBD
评论或私信「内推」
个人内推、非官方，岗位信息以官方招聘页为准。
English:
ByteDance Data | 2027 Full-Time and Internship Roles (personal referral)
Roles: https://datajobs-refer.xyz | Referral code: 41KCZBD | Comment/DM 「内推」. Personal referral, not official.
via V2EX (author: hitnutshell)
字节跳动 Data ｜ 2027 届全职与实习岗位（个人内推）
对大模型、推荐、搜索、广告感兴趣的同学看过来。字节 Data 团队开放 2027 届全职和实习岗位，方向包括：电商推荐 × LLM 、国际电商大模型应用、搜索 / 广告 / 推荐、数据知识系统。地点：新加坡、西雅图、圣何塞。
岗位一览（个人整理，非官方）： https://datajobs-refer.xyz
内推码：41KCZBD
评论或私信「内推」
个人内推、非官方，岗位信息以官方招聘页为准。
English:
ByteDance Data | 2027 Full-Time and Internship Roles (personal referral)
Roles: https://datajobs-refer.xyz | Referral code: 41KCZBD | Comment/DM 「内推」. Personal referral, not official.
via V2EX (author: hitnutshell)