thevita

提供一点信息: https://www.volcengine.com/docs/82379/1346560

火山引擎好像是要手动管理 cache 的，大概看了下，好像没说 completions 会自动给 prefix cache ，未验证，仅提供方向，看看 你 api 的 usage 有没有命中咯

本质就是 小程序不想让你操作 DOM, 只提供封装后的给你, UI 的实现就可以有私有实现（比如 暴露一些 wx 内部的 API/控件 什么的出去）

浏览器为什么不这么设计: 因为原来没有这样的需求

这里 独立的 JS 线程 就是 个 没有 web api javascript instance （因为所谓的 “多个线程同时修改 DOM ，可能会导致竞态条件和不可预测的结果”，就是 web api 不提供线程安全性），现代 web 浏览器里也是有的，就是 Web Worker ，

只是小程序，的与 UI 线程的通信/交互啊什么的都是封装好了的，Web Worker 里你得自己来

我怎么感觉 “现在为了 k8s 集群部署，就把服务拆分出去，每个服务一个单独的仓库。” 这里槽点最大啊

代码组织方式应该是服务于开发团队的协作方式的，而不是紧急为了在 k8s 上部署（就是所有代码都在一个仓库里也不是就不能在 k8s 上部署了啊，无非就是 google 搜不到而已..，看不懂）就这么大动干戈的让所有人去适配机器，，，

rust 的 内核当然是有的

https://github.com/asterinas/asterinas

Asterinas is a secure, fast, and general-purpose OS kernel, written in Rust and providing Linux-compatible ABI.

所有方法都重写成:
sql.execute(
openai.chat.completions.create(, message=["hey, here is my parameters: {paraMap}, funcName: {funcName}, dbSchema={dbSchame}, how can I query data. give me sql"])
)

因为综合评价一个人的能力真的挺难的，至少得约出来聊几次吧，还需要聊的人比较会聊，但这会带来新的问题，即人给予个人经验的评价一定是带有偏见的，对于 hr 来说，机遇学历的评价就是一个极具性价比的手段

因为: a) 每个人手不一样，b) 每个人使用习惯，发力方式不一样

就一点商业上就存在巨大不确定性：微软自己也做游戏机

我的习惯，如果预期自己本地的分支会持续很长时间不能合并的话，此时应该考虑

1. 看能不能拆成多个 提交分批合并, 对 review 的人也友好点
2. 每天上班第一步 pull --rebase
3. 最后 提交 mr 前, 对提交进行 squash 整理，保证每个 commit 都是完整且正确的