{ "version": "https://jsonfeed.org/version/1.1", "title": "Jie’s Vibes", "home_page_url": "https://bojieyang.github.io/", "feed_url": "https://bojieyang.github.io/feed.json", "description": "", "icon": "https://bojieyang.github.io/apple-touch-icon.png", "favicon": "https://bojieyang.github.io/favicon.ico", "expired": false,"author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null},"language": "zh-CN", "items": [{ "id": "https://bojieyang.github.io/posts/warp-to-rescue-google-misidentify-ip/", "title": "IP送中的解决办法", "summary": "使用 WARP 解决 Google 将 VPS IP 识别为中国大陆 IP", "content_html": "

请前往新网站阅读。

", "url": "https://bojieyang.github.io/posts/warp-to-rescue-google-misidentify-ip/","tags": ["科学上网","IP送中"],"date_published": "2026-05-25T00:00:00+08:00","date_modified": "2026-05-25T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/trump-effect/", "title": "特朗普效应", "summary": "特朗普的上台可能给 2025 年带来哪些投资机会？", "content_html": "

请前往新网站阅读。

", "url": "https://bojieyang.github.io/posts/trump-effect/","tags": ["投资","投资备忘录"],"date_published": "2025-03-03T00:00:00+08:00","date_modified": "2025-03-03T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/several-stews/", "title": "几道炖菜", "summary": "近期做了几道炖菜，品相不好，但味道还不错。", "content_html": "

请前往新网站阅读。

", "url": "https://bojieyang.github.io/posts/several-stews/","date_published": "2024-07-09T00:00:00+08:00","date_modified": "2024-07-09T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/refactor-website/", "title": "重构个人网站并启用新域名", "summary": "全面拥抱 Node.js 生态", "content_html": "

我在 2021 年底决定开始写博客，那时的首要目标是低成本地完成站点搭建并尽快开始发布文章。于是我直接使用了 Jekyll 框架并部署在GitHub Pages。这个方案的优点是 Jekyll 非常容易上手且对博客类型网站支持很好，结合 GitHub Action 部署简单且完全免费。另外由于我对我的设计能力完全没有信心，于是使用了 mvp.css 这个只需写页面结构，无需编写 CSS 即可获得美观样式的方案。

现在回过头来看，这个方案很成功，让我快速的把博客搭建起来并持续写了 20 多篇博客。

当前方案的不足

不过这两年多使用下来，这个方案也有一些不足之处：

重构的契机

不过我一直说服自己博客最重要的是持续输出内容，而不是折腾各种酷炫的技术和好看的主题。因此我给自己设定了需要同时满足三个条件才能考虑博客的重构。它们分别是：

今年，压死骆驼的最后一根稻草终于出现了🤣。那就是 squoosh cli 不再维护了。这导致其只支持 Node.js v16。而 v16 版本的生命周期在 2023 年 9 月就结束了。于是我在站点构建时又多了个步骤：切换 Node.js 版本到 v16。在这样切换了几次后，我终于下定决心要进行重构了。

新的方案

近几年流行的前端框架之多，既有 Nextjs 这种最流行的大众之选，也有我个人最喜欢的 Remix，甚至还有很多小众但各具特色的框架，简直让我犯了选择困难症。不过考虑到博客是典型的重内容、轻交互的网站类型，我最终选择了 Astro 这个后起之秀。毕竟其官网的介绍就是 “The web framework for content-driven websites”。

Astro 的功能很全面，但有两个特性对静态站点 (SSG) 特别有用。一个是 Content Collections 特性：提供了以类型安全 (type-safety) 的方式定义和验证任意文档类型。另一个是 astro:assets 特性：可以在站点构建时自动压缩和裁剪图片。

关于博客的样式，我本来想简单选个主题完事，但后来觉得自己的博客还是应该有自己的风格，用了主题后反而不便于调整修改。于是用 tailwindcss 完成了初版的样式设计。

还有一个重要改变是网站托管从 GitHub Pages 迁移到了 Cloudflare Pages。这个改变主要是考虑到未来有些功能会需要后端服务的支持，必须选择一个支持服务端渲染的托管环境。而这样的托管环境，开发体验最好的是 Vercel 和 Cloudflare Pages。我最终选择了 Cloudflare Pages。原因是 Vercel 虽然也提供了很慷慨的免费额度，但一不小心也可能出现刷爆信用卡的情况。

改版收益

经过这次改版，在技术和内容这两方面都获得了很多益处。

技术方面

内容方面

除了技术方面的改进。这次重构在内容方面也做了一些调整优化。主要集中在以下方面：

过渡方案

由于有人已经收藏了或是通过 RSS 订阅了当前站点，因此直接将当前站点下线或重定向到新域名并不是一个好的选择。在未来很长一段时间内，当前网站仍将继续存在，但新文章则只有摘要信息和对应的新网站的链接，以引导用户至新网站。

快来看看

写了这么多，终于可以放上新网站的链接了。 https://bojie.site，快来看看吧。

", "url": "https://bojieyang.github.io/posts/refactor-website/","tags": ["Astro","Cloudflare Pages"],"date_published": "2024-06-20T00:00:00+08:00","date_modified": "2024-06-20T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/from-using-line-providers-to-self-hosting/", "title": "从使用机场到自建服务", "summary": "从使用机场到自建服务，从 openclash 到 sing-box，到目前为止感觉良好。", "content_html": "

为什么要做这件事

过去两年我一直使用某个机场的最基础便宜的套餐，每年的花费大概在 200 元左右。平心而论，该机场服务很稳定，价格也不高，用户体验也还不错，因此过去我一直在用。该机场一直推荐首选 clash 作为科学上网的工具，而我为了方便家里多个设备同时使用，选择了在路由器上安装 openclash 的方案。openclash 其实功能挺全面的，虽然配置界面一言难尽，但好在基本上只需要初始配置一次后就不再需要经常面对了。因此也就一直相安无事的用着。

但从去年年底 ChatGPT 的发布后，情况出现了一些变化。无论是 chatGPT 还是 Claude，甚至是 Copilot 都限定了支持的区域。而我使用的那个机场会优先把我的访问调度到日本、台湾、新加坡等地区，而这些地区基本都不在支持的范围内。这就导致了我要经常切换线路才能正常使用这些服务。多次手工切换让我感到有点麻烦，于是我开始琢磨怎么能自动化的处理这个问题。

另一个问题是我喜欢在 Netflix 看美剧，Netflix 会检测来访的 IP 地址是否属于账号对应的国家。虽然我我使用的机场支持 Netflix 线路切换，但在 4K 画质下偶尔会卡顿一下。虽然发生并不频繁，但却十分影响观影体验。我猜测原因可能是因为高峰期同时服务的用户过多，导致机场服务器带宽过载导致。

要解决线路切换的问题并不困难。最简单的解决方案是通过分流规则来处理，将特定域名的请求交给特定区域的代理节点来负责，这样就能解决这个问题了。但我是通过机场提供的订阅链接来实现代理节点的配置和分流设置的，无法直接修改配置文件。虽然 openclash 支持通过自定义的第三方规则来覆盖订阅链接中的分流规则，但是附加规则的定义不可避免的依赖订阅链接中定义的服务器策略组，如果机场的服务器策略组配置或名称发生变化，则第三方规则就会失效。并且这种情况我只有在出现问题后排查才能发现，为了避免这种不确定性，我没有采用这个方案。

另一个解决方案是不使用机场，转而采用在 VPS 上自建服务的方式来科学上网。这样既可以保证 VPS 的 IP 的所属国家，又可以独占 VPS 带宽。同时解决以上两个问题。

因此我打算先搭建一个服务做个简单的尝试，验证一下方案的可行性。

自建服务

由于目前 AI 产品基本是美国公司，自然不会限制美国访问。因此 VPS 毫无疑问要选择美国机房的。网上 VPS 提供商非常多。我稍微做了点功课后发现，廉价的且有美国机房的 VPS 提供商，口碑最好的是 RackNerd 和 Cloudcone。我最终选择了 Cloudcone LA 区域最便宜的 VPS，年付 17.5 美元。

自建服务最担心出现且很容易发生的一个情况是 IP 被 GFW 封锁。原因是 GFW 有协议嗅探能力，能够识别出部分代理协议。我在网上查阅了一些资料，发现 VLESS-XTLS-uTLS-REALITY 和 Hysteria2 这两个代理协议反嗅探能力最强，基本不会被 GFW 识别到。我最终选择了 VLESS-XTLS-uTLS-REALITY 协议，原因是 Hysteria2 需要配置一个域名，而我不想为科学上网再单独购买一个域名了。

原以为最复杂最容易出问题的服务器搭建环节，反而是最简单的和最快速完成的。使用 Xray-REALITY 管理脚本，只需几个回车就完成了服务搭建，全程耗时不超过 3 分钟。反而是客户端配置花费了最多的时间。

从 openclash 迁移到 sing-box

配置客户端时我才发现，开源的 clash 内核 不支持 VLESS 协议，只有闭源且收费的 clash premium 才支持，而在这个场景下我更愿意使用开源的产品。另外还有一个 clash 的二次开发版 clash meta 支持 VLESS 协议。但不知为何，在我将 openclash 切换到 meta 内核后，出现频繁的内核崩溃，导致完全无法使用。

这导致我不得不开始考虑 openclash 之外的客户端方案。又在网上做了一番功课后，我发现了 sing-box 这个后起之秀。其完全开源，同时软件更新非常活跃，并且最值得称道的是配置文档说明，既简洁又清晰明了。另外还有一个意外惊喜是，在 openwrt 23.05 版本 (当前最新稳定版) 的官方 opkg 仓库中，已经包含了 sing-box，因此在 openwrt 下安装完全不费事。

我当前使用的 openwrt 的版本是 22.03，不过从 22.03 升级到 23.05 并不困难，官方支持通过 Sysupgrade 直接升级。我只花了不到 20 分钟就完成系统升级并安装好了 sing-box。

我花了半个小时浏览了一遍配置说明后就开始进行配置文件编写，除了在 tun 模式配置上遇到了些问题（在网上搜索后在恩山论坛的一个帖子得到了答案）外，其他部分的配置基本都是查阅配置说明并复制参考配置按需修改即可。

从开始进行客户端配置到最终可以使用自建服务科学上网，我总共花费了半天左右时间。

使用感受

在写这篇博客时，我已经使用自建服务一个多月了。服务非常稳定，几乎没有出现过代理不可用的情况。之前担心的 IP 被封的情况也没发生，看 Netflix 也完全不卡了。简言之，这次自建服务的尝试是非常成功的。我会继续使用下去。如果后续我的看法发生了变化，我会继续更新此博客。

简单的总结一下，自建方案的优点是：

  1. 安全性高，不用担心机场存储你的网络访问记录和（可能存在的）窥视你在网上的一举一动。
  2. 稳定性强，不用承担机场跑路的风险。
  3. 网络速度快，独享流量和网络带宽。

相对于使用机场而言，自建方案也有一些不足之处的：

  1. 单 VPS 没有故障转移的能力，一旦 VPS 故障或 IP 被封就无法科学上网了。而如果采用多 VPS 部署服务，虽然可以自动故障转移，但每年花在 VPS 上的钱会比使用机场高出不少，并且绝大多数时间服务器都是闲置的。
  2. 自建服务也就意味着需要自行维护。也就没有了使用机场的简单省事。虽然在完成服务器搭建后的这一个多月里我都没有登陆过 VPS 了，但这并不意味着没有维护成本，后续的软件升级维护等事项依然会持续耗费精力。

总而言之，自建方案在得到了更多安全性的同时牺牲了一些便利性。因此更适合有一定技术能力且愿意在这方面投入精力的人。

One More Thing

通过这次自建服务的经历，我发现我甚至可以非常粗略的估算出机场的成本和利润率。估算方法如下：最便宜的 VPS 大概一年 17 美元，提供每月 3T 流量和 1G 带宽。而我使用的机场最便宜的套餐是一年 26 美元，提供每月 200G 流量和 100M 带宽。由此可以推算一台 VPS 可以支持 10 个用户同时使用完全绰绰有余。而实际情况是 10 个用户同时跑满带宽的情况非常低，因此机场应该会大量超卖。再考虑到机场大规模采购 VPS 甚至直接在 IDC 托管服务器设备的成本应该更低。由此可以推断在用户充足的情况下，占机场成本最大的服务器和网络成本还不到营收的 3%，甚至更低。这也就可以理解为什么机场都提供非常慷慨的分销返利了。

", "url": "https://bojieyang.github.io/posts/from-using-line-providers-to-self-hosting/","image": "https://bojieyang.github.io/assets/img/dist/from-using-line-providers-to-self-hosting.webp","tags": ["互联网","科学上网"],"date_published": "2024-04-07T00:00:00+08:00","date_modified": "2024-04-07T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/leverage-your-skills/", "title": "给你的技能加上杠杆", "summary": "做对的事远比把事情做对更重要。", "content_html": "

什么工作才是有「钱途」的？

我认为可以从技能可替代的难易程度和需要自己持续投入时间的多少这两个维度来衡量。

技能可替代性很好理解，如果一个人目前的工作技能可以被另一个人或机器轻易的取代，那就说明这项技能的可替代性很强。

一项技能是否容易被替代，主要取决于两方面的因素：掌握此项技能的难易程度和拥有此项技能的人的供给量。

如果一项技能只需要很短的时间就可以完全掌握，那意味着几乎任何人都是潜在的技能供应者，由于没有门槛限制，供应近乎无限，所以收入只能维持在最低水平（因为总有人愿意以更低的工资来获取这份工作）。此类工作的代表是「街头发广告传单」，「日本的煮饭仙人」等。衡量标准是「在喝醉的情况下是否仍然能够完成此项工作」。由于技能水平不会随着工作年限的增加而进度，此类工作几乎没有提升空间，因此明智的选择就是尽早退出。

打磨专业技能

需要更长时间才能掌握的复杂技能，由于习得这项技能需要更多的时间，因此技能的供给者会减少很多，所以可替代性会低很多，因此收入相对前者会高很多。比如客车司机至少需要几个月的培训和考试才能取得职业资格，翻译则需要数年的时间才能掌握一门语言，因此他们的潜在竞争对手会少一些，收入也会随之提高。

但并不是掌握了复杂技能就万事无忧了，随着科技的发展进步，一些专业技能正在变为普通人的通用技能；一些之前只能由人来完成的工作，可能在不久的将来被机器代替。最近的二三十年，客车驾驶技能就已经从专业技能变为了通用技能，因此近十年出租车司机的收入水平一直是停滞不前的。以前翻译一本图书需要翻译人员耗费大量的时间和心血才能完成，但随着 AI 技术的飞速发展，现在的图书翻译仅需要机器翻译后再由人工校验和少量润色即可完成。可以预见，在不久的将来，翻译技能也会变成普通人的通用技能。

发挥创造性

一个工作中越是固定和重复的事项，越容易被机器替代。反过来说，一项工作越有创造性，就越难以被机器替代。

当你发现在工作中，总是在走流程，而很少有需要发挥创造性的时候，就需要警惕起来了，这通常意味着可替代性很强。要想避免这种情况，就要通过在事项或流程中增加你的创造性来影响业务结果，如果你能做到这一点，那你几乎肯定会在同事中脱颖而出。

如果一个工作需要很多创造性，那从事这份工作的收入一定是很可观的，可以达到中产甚至富人阶层。此类工作的代表有：美国的医生和律师、中国的软件工程师等。随着工作年限的增加，相应的技能经验也在持续积累，因此有不错的上升空间，此类工作甚至可以一直做到退休。

增加杠杆效应

虽然高创造性的工作很好，但依然有这样一个事实：这只是在通过自己的时间来换取收入。这种交换有个很大的局限性，那就是如果不投入时间进行工作，就没有收入。

更好的工作是利用别人的时间来换取收入，从某个角度可以被认为是增加了杠杆效应。加杠杆的方式通常有三种，分别是：人力杠杆、资金杠杆、产品杠杆。

人力杠杆是指让别人为你工作。公司中的员工在本质上就是在用自己的时间来替他们的老板完成工作。比如一个公司中的所有销售人员所获的收入，从某种意义上看，就是老板花钱买自己在销售这项工作上的投入时间。

资金杠杆是指通过投资获得收益，也就是俗称的钱生钱。一级市场的风险投资，二级市场的股票交易都属于此类。还有一种情况是通过获的他人的投资来加速一项工作，比如加盟店模式，也是通过资金杠杆来加速营收的增长。

产品杠杆是指通过打造一项产品来获得收入的方式。比如出了一本书，通过这本书的版权获取收益；开发出了一个软件服务，按订阅收费等。这种方式最大的特点是在打造产品的过程中需要花费自己大量的时间，一旦产品完成后，需要投入的时间就会急剧减少。

在过去相当长的一段时间里，人力杠杆和资金杠杆是主要的加杠杆方式，但他们也需要承担相应的风险，所以主要是富人在使用。而产品杠杆则是随着互联网的发展在过去二十年里大放异彩，从 Mark Zuckerberg 创造出社交网络 Facebook，从 J. K. Rowling 写出作品 Harry Potter，我们可以看到一个普通人把自己的技能叠加了产品杠杆后所能发挥出的威力。

此外，这三种杠杆并不是互斥的。它们还可以叠加，并且这种例子很常见。比如找 VC 拿到一笔风险投资后，开一间公司招聘数名软件工程师开发一个网络游戏，通过游戏道具付费的方式获得营收。这个例子就同时利用了上面提到的三种杠杆。

所以，单纯从收入的角度来看，一项工作应该既是难以替代且具有创造性，同时还可以利用至少一种杠杆效应，才是理想的工作。

怎样找到这样的工作呢？

最简单的方法，就是给你的技能加上一个产品杠杆，这几乎是任何人都可以采取的方案。如果你是一个在大厂任职的程序员，可以考虑利用业余时间开发自己的应用软件；如果你是一个网站的责任编辑，可以考虑写一部作品或是开通公众号写博客；如果你是广告公司的策划，可以考虑利用周末拍个短视频。

通过这种方式，既在打磨自己的技能水平，也在逐步打造属于自己的产品。同时，由于没有辞去当前工作，所以风险很小，可以让你多次尝试。而一旦成功的打造出产品，你就拥有了这份理想的工作了。

参考

1.「技能与杠杆矩阵」来源于 The magic of doing $10,000 per hour work

2.「三类杠杆效应」来源于 纳瓦尔宝典

", "url": "https://bojieyang.github.io/posts/leverage-your-skills/","image": "https://bojieyang.github.io/assets/img/dist/10k_matrix.webp","tags": ["读书笔记","职业发展"],"date_published": "2023-05-26T00:00:00+08:00","date_modified": "2023-05-26T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/a-few-life-hacks-keep-me-slim/", "title": "几个让我保持身材的生活习惯", "summary": "一个多月无刻意节食，我仍然瘦了 8 斤。", "content_html": "

每逢佳节胖八斤

自从 2021 年初我从 180 斤减到 140 斤后，之后 2 年中体重一直保持在 135 斤左右。为此我还写了给普通人的瘦身减脂框架这篇博客来介绍经验方法。

不过今年我回老家过春节，陪父母住了一个月，情况发生了改变。在这一个月里，我妈天天给我做好吃的，导致我每顿的饭量基本是在杭州时的两倍，再加上没有什么像样的运动，短短一个月，我的体重从 135 斤增长到了 143 斤，腹肌也从分离的八个岛屿变成了 One Piece。

用生活化的方式保持身材

回杭州后，我就开始有意识的控制体重。不过这次，我并没有采用之前严格方式，而是通过更加生活化的方式来完成的。效果仍然十分好，短短 1 个月，我就回到了 135 斤，腹肌也回来了。

本次采用的理念与之前文章没有任何变化，核心思路依然是持续制造热量差。只不过，之前的方式是先通过公式计算初基础代谢，再通过查饮食的营养成分表来判断大概摄入热量，然后配合运动，来达到消耗的热量大于摄入的热量的目标。而这次，我没有那么刻板的执行，而是通过一些日常小技巧来做到。

保证入睡前有饥饿感

之前的方法我这两年实践下来，发现其实最难的是判断摄入热量这个环节。通过营养成分表来判断，优点是计算简单，准确率高。但它的缺点也很明显，只适合于制成品，对饮食的约束太大。如果在餐馆吃饭，或是自己开火，就没有办法通过查营养成分表的方式来知道摄入的热量了。

由于我今年的年度挑战是做一百道不同的菜，因此需要经常自己做菜，查营养成分表的方式就行不通了。

于是我就换了一个思路：想要知道摄入的热量只是手段，最终目的其实是想要知道当天是否制造了热量差。那么，有没有什么方法能够直接判断出来呢？我网上搜索加亲身实践后发现，有一个简单的方式就能大概判断出来，那就是入睡前是否有饥饿感。

如果在入睡前能感到有点饿，那就说明当天已经完成了制造热量差的目标了。入睡前是指进入梦乡前，而不是刚躺上床。

刚开始几天可能把握不好尺度，导致饥饿感时有时无。但只要多试几次，基本就能找到规律。我这次花了一周左右，之后就基本每天都能保证在入睡前有饥饿感了。

几个亲身实践的有效的方法

有了判断方法后，我就开始尝试调整一些生活方式，来达到这个目的。经过一个多月的实验，我总结出了以下几条（对我）有效的方法：

写在最后

要想控制体重、保持身材，本质还是要持续保持热量差。以上方法只是简化了判断热量差的方式，然后用几个生活习惯来尽量达到这一点。

如果你也想要尝试这个方法，不要刻板执行，可以做一些适合自己的调整。并且每周测量体重，通过体重变化情况来判断方法是否有效，如果有效就持续，否则就需要进行一些调整后再执行一周看看效果。

", "url": "https://bojieyang.github.io/posts/a-few-life-hacks-keep-me-slim/","image": "https://bojieyang.github.io/assets/img/dist/a_few_life_hacks_keep_me_slim.webp","tags": ["健身","瘦身","减脂"],"date_published": "2023-03-20T00:00:00+08:00","date_modified": "2023-03-20T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/my-first-github-action-released/", "title": "我的第一个 GitHub Action 发布了", "summary": "记录我开发并上架第一个 GitHub Action 的过程和从其中学到的东西", "content_html": "

背景

事情的起因是由于 new Bing 整合的 ChatGPT 很好用，让我使用的频率增加了很多。于是我就把博客加入了 Bing Webmaster Tools，然后在其中发现了IndexNow这个工具。

这个工具简单来说就是一个搜索引擎的联盟，主动向任何一个联盟内的搜索引擎推送网址收录请求，其他搜索引擎也会得到通知。因此既提高了搜索引擎收录的时效性，又避免了分别向不同的搜索引擎各自提交一遍的繁琐事项，

于是我想用它来实现将每次新发布的博客自动提交给搜索引擎，以便其收录。

由于我的博客是采用Jekyll搭建并托管在GitHub Pages的静态网站，所以最理想的方式是采用 Jeykll-plugin的方式在构建时自动提交给搜索引擎。但是可惜，我没有找到对应的 plugin，而我也不想为了开发这个 plugin 去学习ruby这门语言。

于是我想到可以退而求其次，通过 GitHub Action 来实现这个功能。这样除了让我可以用熟悉的语言来开发，还有几个额外的好处：

于是说做就做，我花了几天时间，开发了 IndexNow Action，目前已经在我的博客上使用起来了。同时也发布到了 GitHub Marketplace，其他人也可以使用。

使用方式简介

使用方式很简单，在博客里我就简单介绍一下，完整文档可以去官方地址查看。

# 只要在你的 GitHub workflow 中加入以下 step 就可以使用了。steps:    - uses: bojieyang/indexnow-action@v1 # v1 is the latest major version following the action-versioning.    with:      sitemap-location: \"https://example.com/sitemap.xml\" # your sitemap location, must start with http(s).      key: ${{ secrets.INDEXNOW_KEY }} # The key you get from IndexNow.

我从中学到的东西

预期花费天数要乘以三

我原本认为我基本上用一天时间就可以完成功能开发和验证，但实际上花了 3 天，其中一天还搞到了凌晨 3 点多（见令人抓狂的小插曲部分）。原因是我自以为懂javascript，但实际上我从没在工作中用过这门语言，远远谈不上熟练。因此在开发时各种查语法，查 API 的用法花费了很多时间。再加上低估了写使用文档的时间，让我的实际投入时间大概是预估的三倍多。

总之，实际做起来，就会出现各种预期之外的情况，整体上会比预想的花费时间要多很多。因此要留足缓冲时间，以免到时手忙脚乱。

在下一个项目使用 typescript，无论项目大小

我在初始化项目时是用的官方工程模版，官方其实提供了 2 个模版，一个是 javascript-action, 另一个是typescript-action，我选择了javascript-action，原因是我以为代码量很少，体现不出 typescript 静态类型检查的优势，编写类型声明相关代码反而会让编码更繁琐。

事实证明这是个错误的决定。由于我的语法不熟，刚开始写出来的代码有各种小问题，如果是静态类型检查，基本上编辑器就直接提示错误了，最不济在编译期间也能发现。但 javascript 的动态类型让这项检查推迟到了运行时，于是我不得不通过 单元测试 --> 发现一个编码问题 --> 修复后再单元测试 --> 再发现另一个编码问题 这种方式来完成开发，增加了很多无谓的时间消耗。

这还是一个非常小的项目，动态类型检查对效率的负面影响就已经到了能够感知到的程度。如果是更大的项目，本该在编译时解决的问题被拖到运行时，所浪费的时间会更多。

产品的美在于统一，统一要靠规范

GitHub 对规范的重视程度让我吃惊。由于我打算让其他人也能使用这个工具，因此就需要写README介绍使用方法。

原本我以为可以随意写，就去找几个知名项目准备借鉴一下。结果让我发现了GitHub README Spec。是的，就连写 README也有规范，而且还规范的很详细，各种示例与解释说明都很完整。于是我好奇的随机查看了几个 GitHub 上的仓库，发现他们的 README 都遵循了规范。

进而发现，GitHub 在很多细节上都有规范。比如，要想上架 Marketplace，要遵循 Action-Versioning，一个关于 GitHub Action 版本设置的规范。

在 Action 的图标方面，GitHub 也有规范，用户不能自行上传图标，只能从 feather icons中选择图标，但是可以自定义图标颜色。这个方案既规范了图标的尺寸和形状，又避免了审核问题，还保留了一定的自由发挥的空间，真是一举三得，非常巧妙。

在各种细节层面制定规范已经很不容易做到了，GitHub 厉害的地方在于，它让整个社区都能很好的遵循规范，从而让这个社区体现出一种统一的美感。要知道这是一个全球性的社区，其中的难度不言而喻。

令人抓狂的小插曲

是什么事情让我凌晨 3 点还在熬夜呢。就是官方模版克隆下来的项目提交到 Workflow 上死活跑不通。

需要的必传参数始终无法注入到 Action 的执行代码中，运行结果就是提示必填参数没有设置。但明明代码和官方示例一摸一样。

我有一个（不好的）习惯，当我认为一个问题应该解决并且我可以解决的时候，不把这个问题解决掉我就睡不着。于是我反复对比我的执行记录和官方执行记录，从怀疑代码到怀疑环境，从怀疑环境到怀疑镜像。每次重试都是同样的错误提示。在网上搜索了很久，也没什么收获。

\"让我抓狂的错误提示\"忽视一条提示引发的惨案

就在我快要抓狂的时候，突然发现一直存在一条发现高脆弱性代码的提示信息，而这条信息官方示例的执行结果中没有出现。奇诡的是，同样的代码为什么官方的执行结果没有这条提示信息？我当时已经不想再思考这个问题了，看了下关于这个高脆弱性风险的解释和修复方案，很容易修复。于是准备把这个修复后就睡觉，结果发现，修复了这个高脆弱性风险后，奇迹般的，参数注入进去了，执行结果一切正常了。

我顿时来了精神，开始分析（猜测）原因。结果发现，官方的执行结果之所以没有这条高脆弱性提示信息，是因为对应的代码检查规则在最近几天才加入的，而官方的运行结果是几周前的。

我接下来猜测，可能因为这个高脆弱性风险是关于脚本注入的，所以当命中这条规则后，GitHub Action 就自动不再进行环境变量传递以规避可能的安全风险。为了验证是否是这种情况，我又把代码改回去实验了一次，结果又执行失败了，果然和我猜测的一致。

\"修复高脆弱性风险的代码\"CodeQL js/shell-command-injection-from-environment

解决了这个问题后，终于可以睡个好觉了。

事后回想，也许程序员还是有些代码洁癖更好，这样以来，发现存在类似的提示，不管三七二十一先都修复了再说。也就不会出现我这样的情况了。

最后，附上项目官方地址，欢迎使用，欢迎反馈 BUG，欢迎 PR。

", "url": "https://bojieyang.github.io/posts/my-first-github-action-released/","image": "https://bojieyang.github.io/assets/img/dist/indexnow_action_released.webp","tags": ["SEO","IndexNow","GitHub Action","IndexNow Action"],"date_published": "2023-03-13T00:00:00+08:00","date_modified": "2023-03-13T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/cooking-in-february/", "title": "学做菜的第一个月，比我想象的简单", "summary": "二月份我一共做了 16 道菜。从只会煮蛋泡面到基本半小时内搞定一道简易菜；从家里只有盐和酱油到现在有十多种不同的调料；点外卖和在餐馆吃饭的次数用两只手也能数得清了。", "content_html": "

一个成功的开始

确定今年的年度挑战是做一百道菜以后，我从 2 月 7 日回杭州到今天 (3 月 6 日)，一共做了 16 道不同的菜，有的菜还用不同的教程重复做了几次来比较口味区别。

这一个月，我从只会煮蛋泡面到基本半小时内搞定一道简易菜；从家里只有盐和酱油到现在有十多种不同的调料；点外卖和在餐馆吃饭的次数用两只手也能数得清了。\"调味品全家福\"调味品全家福

我学做菜的方式很简单，就是刷小红书，遇到教做菜的视频就点进去看看，这么操作几次后，小红书就经常给我推荐教做菜的视频了。然后我再从中挑选我喜欢吃的菜来复制。吃完后如果觉得味道好，就加入收藏备忘；如果觉得味道不好，就尝试总结下找找原因，过几天再做一次。

这样持续了几周后，我从最开始的做菜过程中手忙脚乱到知道要事先准备好所有食材调料再下锅操作；从搞不清调味咸淡到基本能做到八九不离十的程度了；常用的调味品也基本备齐了。

心得体会

在这个过程中，我有以下几点体会。

从简单的菜开始

从操作步骤少，烹饪时间短的菜开始。试想如果我花费了一个多小时做了一道红烧肉，结果发现做失败了，废弃的食材和浪费的时间带来的挫败感可能让我就此打住，不再继续尝试了。所以这一个月，我一般都选择能在 15 分钟内做完的菜，这样既不太费事，又有成就感支持着做下一道菜。

如果一定要做一道复杂的菜，那就选择用半成品来简化步骤。 本文封面图是「笋干红烧肉炖土豆」，如果要从头开始做，要耗费一个多小时的时间，于是我 (聪明的) 买了一个笋干红烧肉罐头来简化制作过程。在做这道菜的时候，我所做的就是三个简单步骤：

  1. 把罐头倒进锅里；
  2. 把土豆切好也倒进锅里，加水炖 20 分钟；
  3. 出锅前调味和加香葱。

这样，一道本月最佳菜品就完成了。

同理，当我想炒肉丝时，不会选择买块肉回来自己切，而是会直接去超市买肉丝；当我想要炒饭时，会直接去超市买一袋混合蔬菜 (胡萝卜丁、青豆、玉米粒) 作为配菜。

不要勉强自己做菜

当连续几天都做菜后，可能会出现厌倦的情况。毕竟既要事先准备和加工食材，又要事后刷锅洗碗。相较于外卖或者在外就餐，确实要麻烦不少。出现暂时不想做菜的状况也是很正常的。如果在这样的情绪下勉强自己继续，容易产生抗拒感，把这个事情当作任务或者负担，反而没法长期执行。

按《微习惯》这本书介绍的方法，要想培养一个习惯，最重要的是目标要足够小，小到不需要使用意志力来坚持。人一旦感觉到自己在坚持，就会下意识的认为这是一个负担。对应到做菜这件事，我给自己设立的微目标是每周做一道菜就算完成目标，如果超额完成目标，就给自己一些奖励。

按需购置

没有必要尝试一次性把调味品、厨具等都买齐，事实上也不可能一次性都买齐。这么做的结果就是要么在做某个菜时发现还有需要的东西没买，要么就是长期不用闲置浪费。更好的方法是按需购买，随着做菜的进程慢慢添加需要的东西。

对我而言，如果近期想要做的一道菜需要长时间炖煮，才考虑买砂锅；如果近期需要做卤菜，才考虑买腌制相关的调料。关于调料，也不是教程上的都需要准备，有的调料可以用其他替代，或者干脆不放。比如教程上说要用花雕酒，但如果你知道其目的是去腥，那用料酒代替也可以；教程上说要放鸡精、蚝油等，但如果你知道其目的是增加鲜味，那么没有就可以不放。

\"只用盐调味的蛋炒饭\"只用盐调味的蛋炒饭

选好厨具

对于我来说，在做菜过程中，没有什么比糊锅更令人沮丧的了。更别提还增加了刷锅的难度。我刚开始时用的是一个普通的无涂层铁锅，可能是因为不会开锅和保养，基本每次炒菜都会不同程度的糊锅，尝试了网上搜到的各种号称炒菜不粘锅的方法都没什么效果，让我头疼不已。

几次之后我实在受不了，换了个麦饭石的不粘锅。从那以后再也没糊锅过。每次做菜心情都变得更好了。

二月菜品列表

这些就是我在二月份做过的菜了，对应的教程都在小红书的收藏专辑学做简易菜中了。

菜

汤

主食

", "url": "https://bojieyang.github.io/posts/cooking-in-february/","image": "https://bojieyang.github.io/assets/img/dist/my_best_cooking_of_february.webp","tags": ["年度挑战 - 2023","烹饪"],"date_published": "2023-03-06T00:00:00+08:00","date_modified": "2023-03-06T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}},{ "id": "https://bojieyang.github.io/posts/annual-challenge-2023/", "title": "2023 年度挑战", "summary": "2023 的年度挑战是做一百道菜。", "content_html": "

扎克伯格每年都要树立一项个人挑战1，借此机会学习新的东西。我在两年前了解到了这一点，也开始实践这一方法。

前两年的挑战都顺利完成了，转眼间来到了 2023 年，今年我设立的年度挑战是做一百道不同的菜，以此来学习如何烹饪。

这个系列就是用来记录这一过程中我学到的东西，或是一些有趣的事情。

  1. 扎克伯格的年度挑战列表 ⇪

", "url": "https://bojieyang.github.io/posts/annual-challenge-2023/","image": "https://bojieyang.github.io/assets/img/dist/annual_challenge_2023.webp","tags": ["年度挑战 - 2023","烹饪"],"date_published": "2023-03-04T00:00:00+08:00","date_modified": "2023-03-04T00:00:00+08:00","author":{ "name": "bojieyang", "url":"https://bojieyang.github.io", "avatar":null}}] }