@Cu635 微信官网： https://linux.weixin.qq.com/

@klesh 不支持 Wayland 。张小🐉把 Qt 砍得只剩 xcb 后端了，只能 XWayland 来运行。不过我目前没发现有兼容性问题，输入法之类的都正常

1. 这个在参数里写的很清楚了：「支持移动/联通/电信/广电 5G/4G 等网络。双卡使用说明：支持 5G SA 」，https://www.vivo.com.cn/vivo/param/iqooz10turboplus

我也同意楼上，倒不是什么 v 不 vivo 、i 不 iqoo 的问题，是这个价位现在基本都在砍 NSA 。其他品牌也差不多

2. 你自己发的链接说得挺清楚了，这个没得洗，就是国内厂商懒，都没兼容 OAuth 2.0 （或称 Modern Auth ），微软去年把 Basic Auth 协议停了，国内直接摆烂不跟进了。

技术客服倒是也不算说错，Basic Auth 在个人账号上确实被微软限制了。

我比较好奇「系统自带邮箱支持 Exchange ActiveSync 」是哪里说的，是 iQOO 官方吗？

@alleluya #89 如果你是指抽象的输入方案，确实打不出；如果你是指官方开发的「小鹤音形输入法」这个软件，那它是能打出的。

就好比：「全拼方案」本身也打不出不会读的字，但「搜狗输入法」可以打出。「 u 或 ` + 拆字」是一个实际软件的辅助功能，而不是加进音码方案定义的东西。所以我不太清楚你想问什么。

@alleluya #87 小鹤音形=小鹤双拼+小鹤形码。实际上是要求你一个字既会读又会写，从两个角度筛选来获得低重码率。如果只会写要用纯形码才能打出来，比如五笔。

至于你说的拆字，这种就属于不同输入法方案的附带小功能了。例如万象拼音，假设不认识「雨辰」合起来的字，用反撇号引导：「`yuif 」（ yuif 是小鹤双拼的 yu chen ）就能找到 震、𮦩、䨯 等等。

@w568w 笔误：5 中的「继承了 GraalVM JIT 」应为「继承了 GraalVM AOT Cache 」。

> GraalVM for JDK 24 是作为 Oracle Java SE 产品组件获得许可和支持的最后一个 GraalVM 版本

我从上面的 Reddit 帖子摘一些内容吧，我也差点被误导了：

1. GraalVM for JDK 根本没死，死的是「 Java SE 产品中的 」 GraalVM 。Oracle 的 GraalVM 项目负责人也证实了这一点。鲜为人知的是，Oracle JDK 包含了 GraalVM JIT （即在运行时使用 Graal 编译器进行即时编译的选项）。看起来，这个选项可能并没有取得预期的商业成功，因此 Oracle 从 Java SE 中移除了 GraalVM JIT ；

2. GraalVM for JDK ，尤其是其中的 Native-image 和 Truffle 项目，没有任何停止或删除；

3. Oracle 将不会再投资这个项目了，因此可以预见维护会放缓。但是亚马逊、微软、IBM 、Red Hat 均有贡献，不至于因为 Oracle 离场被扼杀；

4. 这意味着购买 Oracle Java SE 商业版本的用户将不再获得该产品中包含的 GraalVM JIT 和 Native-image 的技术支持。它将成为一个独立的组件；

5. Project Leyden 是另一个故事：它确实继承了 GraalVM JIT ，但和 Native-image 没有直接关系（而后者才是大部分 Java 用户使用 GraalVM 的原因）。

@strobber16 > 没有速记机一样思路的输入法

你要找的是不是宫保拼音： https://github.com/rime/home/wiki/ComboPinyin

另外可以看看这个问题： https://www.zhihu.com/question/653936085 ，大致总结一下就是：

1. 普通键盘对并击的支持很不好，只能用专门的速录机或特制键盘
2. 普通键盘并击的最好历史大赛成绩也和五笔打字员差不多，甚至不一定能超过双拼
3. 打字超过 100 字/分钟，就快要超过思考码字的速度了，再加快已经只有速录的意义了。权衡一下，学习并击的成本不值得

分享一下之前的调研结果。本人小鹤双拼 4 年使用者。

输入速度受平均码长、击键速度、是否有重码、退格概率等影响。

1. 从平均码长（单位：按键/字）上来说：

全拼（已考虑缩写和智能补全）[1]：2.98
小鹤双拼 [2]：2.50
自然码 [3]：2.20 左右
五笔 [4]：2.17~2.48
小鹤音形 [2]：1.80~2.20

结论：即便考虑上你说的「全拼支持首字母缩写」，全拼也依然无疑是码长最长的输入方式。而形码通常能探到下限，接近 2 键/码。

2. 击键速度在主观方面取决于个人练习，客观方面取决于输入方案的键位是否合理、打起来是否不卡手。可以在 [5] 量化评测不同方案的输入移动距离、手指使用频率等。

3. 我个人感觉，重码和选码是最影响输入速度的方面，甚于打字方案本身。因为识别汉字和按数字键选择永远比肌肉记忆慢一个数量级。形码或辅助码在这方面有优势。不过我自己没有用过形码，就不多做评价了。

4. 退格概率主要受输入方案的容错率的影响。一般来说，越是紧凑编码的方案，对输入精准性的要求就越高。所以，这方面全拼反而是最有优势的：无论是 shuang 还是 shuagn 都很容易被输入法自动纠错，但双拼或形码经常就必须退格，对输入速度有一定负面影响。

总体来说，「全拼的平均速度最快，但双拼和形码的上限更高」。如果追求极致的输入速度，经过足够练习后，双拼是能够远超过全拼的。

[1] https://zhuanlan.zhihu.com/p/82897751
[2] https://zhuanlan.zhihu.com/p/491861664
[3] https://xbeta.info/input-skills.htm
[4] https://www.zhihu.com/question/432465117
[5] https://macroxue.github.io/shuangpin/eval.html

借楼问问 supabase 相比直接用 postgresql 有什么优势？我没搞明白这个的优点

@yuuou
> 只存在于 oppo 及其子品牌
我以为蓝绿技术共享会把漏洞也共享过来，看来我想多了。那就放心了

> “留给恶意应用的利用时间不多了” 这个结论不对
嗯嗯，最后一句是反讽

这个问题在 OriginOS 上有吗？试了一下 OP 发布的测试工具 onepush.apk ，OriginOS 5 未能复现

---

另外厂商这回复效率神了，装死四个月，SRC 屁用没有，最后还是得开放出来才肯回应，就这样还要修半个月。一个字符串拼接 SQL 修半个月？？留给恶意应用的利用时间不多了

@w568w V2EX 这编辑框，一按回车就有概率发出去……

我的建议是，从网上找找 Reverse-engineering system prompts 的方法，把提示词弄出来看看。影响因素太多了，假如提示词只是说「你是 Claude 模型」但没指定版本呢？假如上下文太长出现幻觉呢？假如提示词是每轮对话随机切换的呢？想实锤 A 模型是不是 B ，即使拿到权重都很难说，不要尝试从前端断案了。

退一万步说，作为用户，你花 Qwen 的钱给你更贵的 Claude ，高兴还来不及呢

原因太多了，可能是：

1. Coder 提示词不干净
2. 自己加了提示词
3. 模型因没有针对性训练，出现幻觉随口瞎答
4. 模型因上下文太长出现幻觉
5. 主观上想蒸馏，直接收集和训练了 Claude Sonnet 的数据
6. 主观上不想蒸馏，但搜集到的互联网训练数据被 Claude Sonnet 污染的比例太大
7. ……

> 底层是 claude 吗

我很好奇「底层」是什么意思？有种「拿着前后端知识强行解释不熟悉的领域」的美。我猜你是指「阿里云提供的 Coder API 实际上是直接调用 Claude 的 API 」？ Anthropic 的 API 那么贵，阿里图啥？就为了名声硬烧钱？而且 Anthropic 自己肯定会阻止这种行为啊，人又不傻

> 我使用千问 coder 回答是 Claude3.5 但是我使用千问 3max 回答就是 Claude4 ，内置不应该回答是同一个模型吗

不应该啊，为什么应该？你绝对肯定地给出这个论断的理论依据是什么？

@LLLeo 从 Android 10 开始就不需要了

@Ketteiron #1 用一些公共服务的外链确实是个思路。

> 不行的话发公告让用户多捐点，攻击者成本太低了，除了加钱硬抗没有办法

看了下国内 DDoS 高防，腾讯云起步价 1 万元/月，Cloudflare 也差不多，太难顶了

出必捧场

@xyxc0673 > 有试过 GPT-5 吗，体感上比 Claude 4 好不少，不怎么会乱写

试过一点，后面没续费 GPT Plus 了。改天再看看。

@anivie > 看来要考虑 rn 了

RN 其实也差不多。跨平台本来就是个坑特别多的事，纯粹经验导向，AI 和文档在修平台特定的 Bug 时屁用没有，最后还是得回到 StackOverflow 、Github Issues 甚至源码。

如果已经有网页了，考虑一些直接 Web 项目打包成 App 的工具吧，比折腾 Flutter 简单。不过有时间的话学习一下 Flutter 还是挺好的，收益很高

@w568w #3 这里可以给个实际的例子，是我维护的一个开源项目里某成员（不会 Flutter ）希望用 Claude Code 实现一个云控的功能： https://github.com/DanXi-Dev/DanXi/pull/560 ，Claude 在很多明显的地方犯了低级错误，给我肝火都 review 上来了。

我自己用下来的体验是很差。 原因有几个：

1. Flutter 并没有一套通用的状态管理范式，AI 又写不来第三方范式。

Flutter 本身的状态管理只能说是勉强能用的级别，稍微复杂一点的状态就要依赖第三方库，比如 provider 、bloc 或 riverpod 。每种第三方库的 user base 没有前端那么大，设计模式也不像前端那样已经被 React 一统江湖。Claude Sonnet 4 是都会一点，但很容易产生幻觉、调用不存在的接口或回落到 Flutter 自带的简陋状态管理上，每个页面给你乱造一堆轮子函数，罔顾现有的状态管理范式。

2. 大部分 Flutter 开发者的水平很差（身边统计学，从我接触过的项目来看），基本都是和 OP 一样赶鸭子上架被老板叫来写的，都会带有自己原本语言的 code smell ，故总体代码质量很差。

比如我见过原来写 Android 的开发者（ Java ）起手就是 xxManager 、xxBuilder 、xxBeans……实际上和 Dart 的轻量级目标是背道而驰的。这种低水平开发者导致的就是低水平的库和代码质量，训练进模型也会导致模型更容易产生幻觉。

3. 除了状态管理，Flutter 本身生态和前端一样：比较细碎且高度依赖第三方库，对 AI 的学习能力要求很高。