在开始正式介绍之前，我想起来我妈在我小的时候跟我吹牛逼，说学会了音标就可以“看见一个词就知道它怎么读，听见一个词就知道它怎么拼”。当时把我迷得星星眼都快掉地上了。不过幼年课外班这个东西，只能说是纯传销，以至于我彻底对于英语丧失兴趣。
没想到这么多年过去了，我又把它捡起来了。
自然拼读法，指的是根据单词的拼写就可以推测它的读音；同样的，根据单词的读音就可以推测它的拼写。
中文拼音是完全可以做到，我们看到 suí biàn 就知道它念“随便”，听到“随便”，也可以写出来它的拼音是 suí biàn。但是对于英文就不是了，拼写和读音并不是双射，只能说只有一部分（我觉得甚至不是大部分）遵守这个规则。
经过学习，我觉得根据拼写猜读音会容易一些，但是根据读音猜拼写，就会难一些。
TEE（Trusted Excution Enviroment）我一直没有学明白过，也是借着 recycle 学长的论文的机会，重新学习了一下。
我觉得我一直没有学明白的原因是，TEE 涉及的技术太繁多了（内存加密，安全世界，加密计数器，可信报告，……），而又缺少核心定义，以至于我对于到底啥是 TEE 一直没有具体的概念，反而被上面描述的技术或者概念牵着鼻子走。而实际上这些技术与概念，往往是为了应对某种具体的攻击场景，并不本质。以内存加密为例，难道它只能用在 TEE 中吗？显然不是的，这套加密算法可以被用于任何容易遭受物理攻击或者重放（replay）攻击的地方；同样的，也不是说 TEE 就一定需要内存加密，如果没有物理攻击（比如说手机，或者 HBM 这种天生对物理攻击防御能力强的硬件），也可以不需要内存加密。
所有的依赖问题，大抵都会与“菱形依赖”有关。也就是如图所示， Web Lib 和 Log Lib 都依赖于 JSON Lib（相当于菱形的下半部分）：
Web Lib 和 Log Lib 对于 JSON Lib 的依赖要求是不同的，Web Lib 要求 >=1.0 ，而 Log Lib要求 >= 2.0 ，最终的 Log Lib 需要同时满足这两种条件，也就是 >= 2.0 。
而当这写条件无法满足的时候，这个系统就崩溃了。不过如果软件都保持向后兼容性（backward compability），那么按理说应该我们总能通过“装最新版”的方式来解决依赖问题。但问题就在于，这里是现实：
在使用服务器等非非本地电脑的情况下，我们常常面临一个非常原始的 shell。这种原始的环境，不仅会降低开发的效率，而且还会导致操作错误的概率大大增加（比如还未激活某个 python 的虚拟环境，就进行一些包的安装等，或者在错误的路径下删除文件）。
在 LLM Agent 和 VSCode 自动化的背景下，大大降低了 shell 中需要优化的 cli 工具的数量，比如说 docker，文件管理器，编译命令，下载命令，direnv，手册查询命令，git 客户端等，这些都可以很好被 Agent 或者 VSCode 代替。
在这种严苛的环境下，这对 cli 工具提供了更加严苛的要求和品味，我总结为如下几点：
