V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  codehz  ›  全部回复第 1 页 / 共 146 页
回复总数  2907
1  2  3  4  5  6  7  8  9  10 ... 146  
6 小时 8 分钟前
回复了 wlfh2008 创建的主题 推广 [Claude Code] 不玩套路,留言就送$10
HONGMACC-5E48A84A
体验一波,好用的话就付费了
1 天前
回复了 wyttt 创建的主题 OpenAI chatgpt 炸了,代码跑着跑着出现了成人内容
就是意外出现一个训练较少的 token ,它的 embedding 方差很大,直接影响了 LayerNorm 层的计算,导致后续 token 归一化后数值集体偏向同一个方向,attention score 分布严重退化(趋向于 uniform 或 single token attention )梯度也跟着爆炸/消失
这个增量解析好像并不一定能提升性能。。也许是对比的文档比较短?
我这边测试最高 1.4x,最低 0.9x 4.6ms vs 4.9ms 这样
3 天前
回复了 zpvip 创建的主题 Ruby on Rails 以后发软件库是不是只用发 spec?
可以当作 vibe coding 测试工具,来测测 GLM-4.7 / Kimi-k2-thinking / MiniMax M2.1 / Qwen Coder 这些国产模型能不能独立实现()
3 天前
回复了 ethusdt 创建的主题 程序员 大模型 agents 为什么不自带 skills?
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
虽然好像只能显示几个文本()
7 天前
回复了 vodmaker 创建的主题 分享创造 我又 Vibe Coding 了一个 Agent 项目
其实可以增加一些读取上下文的工具调用,例如拿到前一个用户执行的输出一类的(配合 shell 集成),再加点用户交互的工具调用,接入某个 TUI 库生成简单的界面(如要求用户选择某个选项,或者输入内容),就很实用了
这个镜头控制模式经常放大着把地球弄到页面底部去,感觉不是很对
国内基本上用不了跨设备 passkey (除了果子生态,安卓这边要连谷歌服务器交换密钥),绑定了人家用手机发现登不上就有得玩了()
2025 年 12 月 30 日
回复了 itechnology 创建的主题 程序员 个人本地开发相关的软件你们都是装在哪里?
多买几个机器不就好了,小主机也不占地啊,可以用 kvm 切换或者直接远程控制
2025 年 12 月 29 日
回复了 lemoncoconut 创建的主题 程序员 AI coding 是否会导致小众技术栈逐渐消亡
ai 的迁移能力超乎你的想象()
只要别太离谱,基本上你想到的小众语言 ai 都可以很快胜任
而且移植库也更方便了,以前还要纯苦力移植,现在 ai 翻译移植库非常容易()
2025 年 12 月 25 日
回复了 jaydenWang 创建的主题 程序员 React 缺失的“M”层:我开发了 Zenith,重塑完整的 Model
其实主要问题是
https://laike9m.com/blog/avoid-mini-frameworks,171/
引入了太多不属于库的新概念,虽然你可以解释说是大家最后都会这么做,然而最后会这么做和一开始就要这样做还是不一样的()
2025 年 12 月 24 日
回复了 jaydenWang 创建的主题 程序员 React 缺失的“M”层:我开发了 Zenith,重塑完整的 Model
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 等原生对象包装)写才不会出事
1  2  3  4  5  6  7  8  9  10 ... 146  
关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   907 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 45ms · UTC 21:19 · PVG 05:19 · LAX 13:19 · JFK 16:19
♥ Do have faith in what you're doing.