V2EX › sillydaddy 的所有回复 › 第 7 页 / 共 157 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

For Existing Member Sign In

1 ... 3 4 5 6 7 8 9 10 11 12 ... 157

❮

❯

5 月 20 日

回复了 sillydaddy 创建的主题 › 程序员 › 小米的 coding plan 不能用了，缺少 reasoning_content 怎么办？

@pengyvz
@Sezxy
感谢，我先试试 Claude Code 行不行。不行的话我再试试 OpenCode 。

5 月 19 日

回复了 longxinglink 创建的主题 › ☕Vibe Coding🤖 › 不要在 520 当天晚上 vibe coding

哈哈，这些话我至少有 8 成都说过。

5 月 18 日

回复了 b309f3337 创建的主题 › 职场话题 › AI 时代，程序员被清楚地分为了两类人

利好 v 站：创意工作者的社区。

5 月 17 日

回复了 LittleYe233 创建的主题 › Solana › 为社么我在 pump 上买卖同样 1 万$v2ex，价格差距这么大

@sillydaddy 上面说的就是楼上说的滑点。流动性池有限导致的价格滑动。另外还有固有的手续费（ 0.3%左右吧）。加起来就是你看到的价差。

5 月 17 日

回复了 LittleYe233 创建的主题 › Solana › 为社么我在 pump 上买卖同样 1 万$v2ex，价格差距这么大

正如楼上说的，因为流动性不多。
看下面这张图：
https://i.v2ex.co/DQf128R6l.png

AMM 曲线是 XY=K ，其中 X 是 SOL 币，Y 是 V2EX 币。

假设在你买之前，池子中 SOL 和 V2EX 的库存，位于曲线的红框位置的点位。

可以看到红框的竖直高度，代表了池子中 V2EX 币数量的变化量。红框的水平宽度代表了池子中 SOL 币数量的变化量。
也就是说，你在用 SOL 币购买池子里的 V2EX 币时，点位会沿着曲线向右下移动。

现在你需要从池子中购买 10000 个 v 币，假如说买完这 10000 个 v 币后，点位还在红框范围内，那说明价格变化不大。但如果说 10000 个 v 币数量超出了红框竖直高度，那点位就继续滑动到第一个蓝框，或者第二个蓝框，甚至更下面的位置。

这时候，价格就变的高很多！

卖出 V2EX 币时同理，点位会向上滑。

如果 K 值比较小（也就是 X,Y 都比较少，流动性池子比较小），那么 10000 个 V2EX 币对应的滑动范围就很大。

如果形象理解的话，你看图片里面，每个框其实都表示在该价格下的可以提供的流动性（即可买的数量）。买完了这个流动性，就会挪向下一个价格点位！每个价格点提供的流动性是有限的。你可以算一下现在 V2EX 币的流动性，这 10000 个 V 币数量的变化，相比目前的流动性，可并不算小。

5 月 16 日

回复了 zzf 创建的主题 › 远程工作 › [实习] [可远程] Agent 工程师

「团队介绍我们是一家聚焦 [ Agent 操作] 的 AI 初创公司，通过 AI 让用户少折腾，直接拿结果。」

这就算公司介绍了，是吗？整的跟地下党招聘似的！你是来招聘的，不是来组党的。大大方方说出来又会怎么样呢？

5 月 13 日

回复了 ggp1ot2 创建的主题 › Cursor › 不吐不快， cursor 在变相折磨老用户

你的这个不能排除是网络的问题。

我的 Cursor ，有时只要网络抖动那么一下，就再也无法连上了，表现出来就是 Taking longer than expected 一直卡住。即使只中断那么 1 秒钟，也能点停止按钮。

但有时则会频繁自动重连，每次重连都算作一次新的 request 。关键这种重连你在表面上看不出来，对话还在正常进行，就看见后台统计非常短时间消耗了几十次（非常确定没有开 subagent ）。所以遇到这种网络就赶紧断开，换一个网络就好了。

所以说，用按次计费的，每天都要提心吊胆，又怕连不上又怕中断又怕重连。Cursor 的网络连接处理的真的很差劲。这么看，按 token 计费还是很省心的。

5 月 9 日

回复了 mutalisk 创建的主题 › 互联网 › 发现一个李鬼 v2，把 v2 的主题内容和评论都采集过去，发帖用户和评论用户一换，就变成一个新的活跃论坛了

「 51 做了个网站，女朋友调侃说做的什么垃圾有什么用，v 友们看下有用吗」： https://solodev.cool/create/51-created-a-website-and-her-girlfriend-joked-about-the-usefulness-of-what-she-d

这个 URL 翻译的不太行，"her girlfriend"是什么鬼？

5 月 9 日

回复了 HankAviator 创建的主题 › 问与答 › 有没有标记 AI 回复用户的脚本/扩展？

小鱼标签： https://v2ex.com/member/PipeCraft

5 月 8 日

回复了 Ethans 创建的主题 › ☕Vibe Coding🤖 › Claude Code 效率翻 N 倍的技巧：用 Git WorkTree 并行开发

我也是因为 vibe coding ，才知道 git 有 worktree 。

5 月 8 日

回复了 fishlium 创建的主题 › Cursor › 按次的 cursor 陨落了

为啥会没了，自动续费应该还会保持吧？

5 月 7 日

回复了 JoeJoeJoe 创建的主题 › Joe's Talk 🪐 › 感觉现在大部分的 VibeCoding 作品基本都是前端小玩具, 让人惊艳的作品太少了, AI 让我能快速实现想法,但是也让我变得更加浮躁, 反思!

确实是，我用 AI vibe 了下面这些，只有 1 个在用：

1. node-based 动画制作工具。发现不适合制作复杂的动画，抛弃！几万行代码。瞎了！！！改用 MotionCanvas 以及 Manim 这些现成的工具。

2. 简单的 gtd 时间管理工具。自己用着都感觉操作不方便。搁置中。

3. 自媒体流水线管理工具。功能挺丰富的，看板、筛选、可视化都有，但目前还没用到，因为同时启动的自媒体项目数量，还远远到不了用流水线管理的程度。偶尔看看里面的话题素材，希望以后能用上。搁置中。

4. v 站新帖监测工具。这个倒是在用，也挺管用的。高频使用中。

5. LogSeq 双向链接的可视化。vibe 了一半，设计水平还是不行。搁置中。

6. 数据备份命令行工具 PAR2 的 UI 管理界面，做完了但还没有用。搁置中。

应该还有不少其他的。

有时候工具太容易做，导致不假思索就去做工具，把精力放到上面，忘了原本的目标。

5 月 2 日

回复了 malagebidi 创建的主题 › 程序员 › glm-5.1, kimi-k2.6 在 code arena React 项目上排名 5 和 6，是不是真的好用？

@malagebidi #8 谬奖了，我修改一下之前的错误：

这个错了：「 Elo 胜率公式：胜率 = 1 / (1 + 10^(分差/400))」
应该是：「 Elo 得分公式：得分 = 1 / (1 + 10^(分差/400))」

因为 Elo 打分时有「胜」「负」「平」这 3 种。胜者得 1 分，负者得 0 分，平局各得 0.5 分。

我没有考虑平局，所以得出 10 次比赛里面，GLM5.1 也会对 Opus4.7 有 4 次战胜的情况。其实弱者得分，主要是从平局里面得来的（也不排除从战胜中得分，但比例应该很小，特别是分差大的情况下）：

Elo 相差 10 分得分 51.4% vs 得分 48.6%，A 胜率 2.9%，平局率 97.1%，
Elo 相差 50 分 57.1% 42.9% A 胜率 14.3%，平局率 85.7%
Elo 相差 100 分 64.0% 36.0% A 胜率 28.0%，平局率 72.0%
Elo 相差 200 分 76.0% 24.0% A 胜率 52.0%，平局率 48.0%
Elo 相差 400 分 90.9% 9.1% A 胜率 81.8%，平局率 18.2%
Elo 相差 800 分 99.0% 1.0% A 胜率 98.0%，平局率 2.0%

换成这种的话，GLM5.1 与 Opus4.7 差的 50 分意味着：在 20 次提问中，用户有 3 次觉得 Opus4.7 的答案比 GLM5.1 更好，其余 17 次，都很好。即 3 胜 vs 17 平。

可能这种情况更符合真实情况。

5 月 2 日

回复了 malagebidi 创建的主题 › 程序员 › glm-5.1, kimi-k2.6 在 code arena React 项目上排名 5 和 6，是不是真的好用？

所以，Elo 用在围棋比赛、赛车比赛时，就是绝对实力的差距。因为 1 场比赛，赢就是赢输就是输，不分情况。但用在编程上时，因为是先给定题目，再 PK ，那题目的选择就是比赛的关键变量，出简单题目 PK 与出难题 PK ，结果会不一样，导致分数计算也不一样。

Arena 的 PK 是类似于众包，所以，没办法控制用户向大模型提的问题是什么，难度分布是怎样的。同样 2 个模型，比如 GLM5.1 和 Opus4.7 ，都出简单题目 PK 得到的 2 者分差，肯定比都出难题 PK 时，得到的分差小。

5 月 2 日

回复了 malagebidi 创建的主题 › 程序员 › glm-5.1, kimi-k2.6 在 code arena React 项目上排名 5 和 6，是不是真的好用？

换句话说，如果你自己平时用的时候，问的问题的难度分布（比如 1 个超级简单的，10 个中等难度的，3 个架构设计的），与 Arena 用户在对答案投票时，问的问题难度分布（比如 2 个超级简单的，18 个中等难度的，5 个架构设计的）类似，那这个分数就很适用，分差完美反映了 2 者的实力差距。

5 月 2 日

回复了 malagebidi 创建的主题 › 程序员 › glm-5.1, kimi-k2.6 在 code arena React 项目上排名 5 和 6，是不是真的好用？

Elo 评分还是比较可靠的：Elo 基本是所有赛事都常用的评分机制：围棋、游戏、赛车等等。
这个分数，表明了 2 个对手比赛时的胜率。

Elo 胜率公式：胜率 = 1 / (1 + 10^(分差/400))

Elo 相差 10 分胜率 51.4% vs 胜率 48.6%，优势比较均衡，运气因素更大
Elo 相差 50 分 57.1% 42.9% 有不小的优势，五六次对局就能看出来
Elo 相差 100 分 64.0% 36.0% 明显优势，约 2:1 的胜率
Elo 相差 200 分 76.0% 24.0% 显著优势，约 3:1 的胜率
Elo 相差 400 分 90.9% 9.1% 碾压性优势，约 10:1 的胜率
Elo 相差 1000 分 99.0% 1.0% 几乎不可能输，约 100:1 的胜率

领先 50 分是什么概念呢？有 10 个问题，都给到 2 个模型，你会采用 A 模型的答案 6 次，B 模型 4 次。如果 2 个模型都很优异，这种采用率的差距比较明显了。但反过来想，如果与 Opus 4.7 thinking 比赛时，GLM 5.1 能在 10 次里面让用户采纳它的答案 4 次，那它的实力也不容小觑。

一个关键点就是，在比赛时，用户向 2 个模型提出的问题是什么，如果是写斐波那契数列程序，那甚至 qwen 都能战胜 opus ，毕竟这么简单的问题，所有的模型都能答的很好，用户只有选择「同样好」，这就会拉近 2 者的分数，如果都是用这样的问题 PK ，那么 Elo 分差就是 0 。

所以，要看 Arena 里面的 13 万次 votes ，用户都是问的什么问题，这是最关键的。如果 13 万次 votes 问的都是中等难度的问题，在中等问题难度 PK 中，都能让分差拉开 50 分，那么在高难度问题中，分差只会更大。

1 ... 3 4 5 6 7 8 9 10 11 12 ... 157

❮

❯