这个增量解析好像并不一定能提升性能。。也许是对比的文档比较短？
我这边测试最高 1.4x,最低 0.9x 4.6ms vs 4.9ms 这样

可以当作 vibe coding 测试工具，来测测 GLM-4.7 / Kimi-k2-thinking / MiniMax M2.1 / Qwen Coder 这些国产模型能不能独立实现（）

skill 还是得自己写才有用，通用的能力直接模型本身提升就好。。

检查了下，唯一给“长”上下文支持的是 0x 模型 raptor mini (GPT 5 mini 的微调），给到了 200k ，但因为是 thinking 模型，本身吃 token 就厉害，所以实际上也不太好用

@lesismal 无关模型，因为是 api 那边的限制，opus 能完成是 opus 模型本来就好，你看这不给了个 3x 吗🌚上下文限制的影响是大项目经常陷入总结上下文，优化工具调用的循环（尤其是重构时，改文件次数较多的情况）😂opus 一次性做好不需要多少上下文自然没啥影响，倒是进行一个大规模重构试试，读几十个文件后 128k 就满了，个别模型用的人多的时候还会给你限制到 64k ，更加没法用了

主要问题是上下文阉割，啥模型进来都给你卡到 128k 上下文（）
也许这就是 copilot 还能保持按请求付费的原因

我记得安卓新版有提供在状态栏上显示胶囊的 api ，是不是可以直接接入（）
https://developer.android.com/develop/ui/views/notifications/live-update
虽然好像只能显示几个文本（）

其实可以增加一些读取上下文的工具调用，例如拿到前一个用户执行的输出一类的（配合 shell 集成），再加点用户交互的工具调用，接入某个 TUI 库生成简单的界面（如要求用户选择某个选项，或者输入内容），就很实用了

这个镜头控制模式经常放大着把地球弄到页面底部去，感觉不是很对

国内基本上用不了跨设备 passkey （除了果子生态，安卓这边要连谷歌服务器交换密钥），绑定了人家用手机发现登不上就有得玩了（）

多买几个机器不就好了，小主机也不占地啊，可以用 kvm 切换或者直接远程控制

ai 的迁移能力超乎你的想象（）
只要别太离谱，基本上你想到的小众语言 ai 都可以很快胜任
而且移植库也更方便了，以前还要纯苦力移植，现在 ai 翻译移植库非常容易（）

其实主要问题是
https://laike9m.com/blog/avoid-mini-frameworks,171/
引入了太多不属于库的新概念，虽然你可以解释说是大家最后都会这么做，然而最后会这么做和一开始就要这样做还是不一样的（）

6202 年还在依赖实验性装饰器这点就已经输了（）
zustand 里想用 class 其实可以直接做一个中间件来做，以下是 ai 一秒生成的代码，可能有误，但大体思路明确

https://grok.com/share/c2hhcmQtMi1jb3B5_424db85c-b856-4a85-a83e-d185fca2c8b7

zustand 的核心就是那个 selector 机制，避免了 context 的牵一发动全身问题
其他的一切都只是为了一个简单好用的 api ，包括那个 set get 的设计，做成这样是为了能方便被中间件扩展，某种意义上说，相比于函数式或者面向对象，zustand 的 middleware 设计更偏向于 aop 也就是面向切面编程

主要是就算你想在外面直接调用 set 也可以使用那个 selector 函数的 setState 方法，所以我完全不知道为啥你有导出 set 的想法（）

@jaydenWang zustand 的派生不是直接在 selector 里写的吗，我倒好奇你是怎么用的
语法上确实没阻止你直接导出 set 但一般人也不会这么写啊

zustand 里唯一看上去是函数式相关的，大概只有不可变数据和纯函数更新这两点了，但完全不能和真正意义上的函数式打等号，一些资料里这样写单纯是因为他们没搞清楚概念，真正重要的是那个 flux 模型，它看似与函数式紧密联系，但实际上是完全不同层次的抽象，只能说有一定的相似性

Flux 的核心原则包括：
单向数据流：数据流动是单向的，避免双向绑定带来的复杂性和不可预测性。典型流程是：View 触发 Action → Dispatcher 分发 → Store 更新状态 → View 重新渲染。
单一真相来源：应用状态集中在 Store 中，而不是散布在各个组件。
动作驱动更新：状态变化通过明确的 Action 来驱动，便于追踪和调试。

zustand 只是在这个基础上把开发体验做了一定的提升，简化了使用：
不需要 Dispatcher 或严格的 Action/Reducer 分离。
直接在 store 中定义状态和更新函数（这些函数类似于 Action Creators ），通过 set 函数不可变地更新状态。

至于为啥不用 class ，还不是因为 js 本身局限性，无法高效跟踪深度嵌套类型的变动，只能采取创建新对象的方式来触发更新——例如 zustand 同一家出的那个 valtio ，就是使用 proxy 做的状态跟踪，为了解决 js 的局限性，其实不仅带来了很多损耗，也需要遵循很多规则（ this 使用规则，还有 proxyMap proxySet 等原生对象包装）写才不会出事

我翻遍了资料也没看 zustand 说它是函数式啊？能不能先别立一个稻草人呢