就是意外出现一个训练较少的 token ，它的 embedding 方差很大，直接影响了 LayerNorm 层的计算，导致后续 token 归一化后数值集体偏向同一个方向,attention score 分布严重退化（趋向于 uniform 或 single token attention ）梯度也跟着爆炸/消失

这个增量解析好像并不一定能提升性能。。也许是对比的文档比较短？
我这边测试最高 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 等原生对象包装）写才不会出事