非要用的话，建议用旧版，我以前用的是 6.3.3 ，后面懒得折腾换系统自带天气了。

很多软件都是越更新越难用，我记得淘宝某次更新以后就把「立即购买」按钮搞得特别大，很容易误触，气得我当场卸载重装旧版，后面就一直没升级了，不知道现在改回去没有。

没用过 mint ，也很久没用过 gnome 了

建议检查两点：
1. gnome-keyring 是否安装
2. gnome-keyring 是否启动

@fbxshit #14 当然，这只是个水印技术，但是原理上是类似的。

大模型会根据上一个 token 预测下一个 token ，这个水印的原理就是在生成下一个 token 前，根据水印哈希+前一个 token 计算出一个可用的 token 白名单，然后提高生成 token 落在白名单里的概率，来实现将水印编码进去的效果。

这个技术是固定水印+动态白名单，只能起到验证水印的作用——即使用水印重新生成一遍白名单，然后验证每个 token 是否落在白名单内，概率越高则越可能加了水印。

但是将这个技术稍加改动——使用密钥生成一个绿名单，然后在生成下一个 token 时，用要编码的信息（ 0/1 ）来干预（降低/提高） token 落在名单中的概率，就是反过来编码任意信息了。
干预程度越大，信息密度越高，语句也越不通顺，干预程度越低，信息密度越低，但隐藏效果也更好。

这不就是大模型水印技术吗，只不过你想嵌入的不是水印而是秘密信息。

https://github.com/jwkirchenbauer/lm-watermarking

炸多了就有经验了，这种基本都是 compositor 的问题 https://i.imgur.com/agAJ0Rd.png

现在这么松的吗，数年前我也是阿里云服务器过期换腾讯云，立马就被阻断了。

这玩意儿宣传的两大特点好像互不兼容啊：WASM 支持和无缝调 Python 库

如果为了 WASM 用它，就会发现用不了 Python 生态，还不如用其他支持 WASM 的生态更好的语言。
如果为了 Python 库用它，那为什么不直接用 Python 。

有些人可能没用过 Cursor 或者用过但是没注意过这个问题。

按我理解，OP 的意思应该是：Cursor 既然都做了本地化，为什么不做彻底，要用「 Always respond in 中文」这种变扭的形式。

这个疑问是合理的，答案也很简单——Cursor 压根没做本地化，这就是个模板，你自己填的啥语言这里就是啥，我怀疑填火星文或者搞 Prompt 注入都没问题，当然没啥意义就是了。

这玩意儿不是为每个语言定制的，而是一个单纯的模板「 Always respond in {}」，后面就是你首次启动时自己输入的语言。

发现目录层级这玩意儿还是有些门道的

`..` 其实不能被删掉，也就是说 a/c 和 a/b/../c 并不等价，因为 b 可能是一个符号链接，此时它的父目录就不是 a 。

Rust 和 Python 的实现都是正确的，只会删掉多余的 `/` 和 `.`，并且在文档中强调了这一点
Go 和 NodeJS 都会把 `..` 也删掉，但 NodeJS 提到了它的行为并不严格遵守 POSIX 规范

@vinle 这不是 utf8 吧，只是单独提出了一个类型用来表示 unicode code unit ，语义上更明确了，但没有任何编码信息

现在这些大模型给我的感觉就是：富有经验，但沉溺在自己经验里的工程师，一旦跳出它的舒适圈，就很难绷。

前几天有段 Rust 代码想重构一下，是用 async + rayon + opencv 对一批图像进行处理。

由于把 async 和 rayon 混在一起比较麻烦，我一开始选择是每个 task 把“所有”图片处理完再进行下一个 task ，大概像这样 async task1 （过滤） -> rayon task2 （多线程计算） -> async task3 （收集），但这样显然效率不高，应该流式处理更合适。

然后我就试了让 gemini 2.5 pro 和 claude 3.7 sonnet thinking 帮我重构一下，我解释了这段代码在干啥，我为什么这么写，我现在希望重构成哪种效果……

结果惨不忍睹，它们做的事情包括但不限于：
1. 先计算，再过滤收集——即使我强调过计算非常慢
2. 把计算任务也全部放到异步 task 里——你觉得我为啥要特地拆成三个 task
3. 遇到所有权和生命周期问题就是一通乱改，改了几次过不了就全部重写（？？）
……

最后为了预防高血压，还是自己写了，其实就是把 rayon 换成一个线程池，然后三个 task 之间用 channel 通信。就这么个简单的任务，这些刷起题来比我强到不知到哪里去的 AI 硬是没做出来。

> 真正优秀的交互，应当是符合认知直觉的，而不是让人产生模糊感和不确定性。

交互是否合理不应该看用户的选择吗？

我看了一下我手机（小米）里的全面屏手势教程，发现侧滑返回用的示意图是左侧滑动，教的时候也是先教左侧
滑动——但事实上我大部分时候用的都是右侧滑动。在看到这个帖子之前，我都没有意识到原来还可以左侧滑动。

在提供两种滑动的情况下，我自然而然地就选择了右侧滑动，这是不是可以说明，至少对于像我一样的用户来说，右侧滑动是一个更好的设计呢？

你这「教用户做事」的味儿也太浓了……

> 还有 Optional 一类的，和 if 没太大区别，只不过前者在语法上做了强制（不检查错误，不能拿到结果），还有一些语法糖（ user?.address)。

大部分人想要的不就是糖吗？谁会关心和类型和积类型的区别，自己写得爽就行了。
即使 Optional 这类方案，没有糖也很难受，比 if err != nil 好看不到哪儿去。

比如 Rust 没有任何糖的上抛：
let ret = match foo() {
Ok(v) => v,
err => return err,
}

后面大家受不了，加入了 try! 宏：
let ret = try!(foo());

再后面直接加入了问号运算符：
let ret = foo()?;

自己写正常的数学表达式，然后让 AI 帮你转成 Go 写法 https://i.imgur.com/agAJ0Rd.png

这里面只用过 copilot ，首先 agent 模式慢很多，不管是请求还是编辑都慢。
这个其实我还能接受，但 tab 实在是差远了！

copilot 的 tab 别说补全代码，TM 连基本的重构都做不好，给的建议莫名其妙，

> 20 刀一个月是赚不了钱吗

我也觉得现在的 Cursor 没以前好用，但是你说 20 刀赚不赚钱，那肯定是不赚钱，完全是在烧钱抢市场。