rt，之前刷帖子的时候看到一个挺实用的脚本，刷主帖，右侧有个悬浮窗显示L站首页帖子列表，可以快速跳转新帖，当时想用，结果一刷新忘了，不知道有没有佬友有印象 7 个帖子 - 4 位参与者 阅读完整话题
主帖链接： 『LDML主贴』用于讨论评价大模型能力的排行榜网站！！ ↑↑↑关于本站的具体情况，请点击上方主帖查看详情↑↑↑ 情况 LDML大模型排行榜站已经开了一周了。前两天我们上新了几个新的模型，但是却没人来投票，导致根本没有数据来做排行榜。刚上的更新帖子还没几个人看就被L站的大数据刷下去了。然后我看到半年前也有人提出了”L站专属大模型榜单“的概念 跳转帖子：Linux do专属大模型榜单 ，当时呼声很高，但是至今没有实现。针对他的一些想法我认为可以吸收并加以改良。现在就LDML站的情况，求各位佬友来指导指导建议。 一些提案 鉴于LDML站的引流纯靠L站帖子，我考虑制作一个活动区，时不时展出几个大模型的输出对比，让佬友们进行投票与讨论，来决出胜者，同时计入活动区的记录中，以供全局参考。 针对QQbot佬友的概念，LDML站可以推出一个题库栏，由佬友们来上传题库，我们时不时会进对大部分模型进行测试，来得出一个客观的排行榜。这个题库我们不会进行公示，仅用作LDML模型的测试用途。 发放一些抽奖红包用于引流，为本站排行榜做出贡献，即可参与投票 需要解决的问题 站内数据十分贫瘠，这一周仅注册了100位左右的用户，参与投票的仅不到20人，这样的数据量完全不足以支撑排行榜的可靠性 针对QQbot佬友的概念，我们会支出不少token用于测试大模型，我坚持认为公益站不应与钱扯上关系。那么这部分支出只能由我一人承担，我在考虑有无必要开放类似于”爱发电“这种投喂方式。以及是否有违社区的规则和建站的初衷。 针对QQbot佬友的概念，其中提到关于专家组的建设，这是一个很难抉择的问题。作为一个社区排行榜，理应让社区内所有成员都有平等参与的机会，专家组的申请和通过是否设立门槛，门槛多高，这很难确定。我不希望这个排行榜最后成为”小团体“的片面见解。 欢迎各位佬友在评论区提出建议和见解，为我们LDML站献上一份力！！！感谢各位！！！ 6 个帖子 - 4 位参与者 阅读完整话题
之前的那个主帖因为写错栏了被佬友删了，现在这是新的 CHY公益站 主帖 2026/5/30 站点已恢复，但是数据还是没了 92 个帖子 - 70 位参与者 阅读完整话题
聊天生图站主帖： 【Picpi Chat 工艺站】支持聊天和 image2，支持上传图片，文生图，图生图，正式上线！ OpenAI Codex 工艺站站主贴： 【picpi 皮皮公益站】已3个月稳定不中断！ 主力模型:OpenAI Codex 从 【picpi 皮皮工艺站】开放注册，不再是邀请制，但是订阅仍需LDC购买。 继续 现在已经把聊天站和OpenAI Codex站整合在了一起。 由于邮箱一直爆炸，所以搞了一个新网站专门用于注册。这样就不会炸了。注册之后就可以愉快的聊天生图啦！ regapi.picpi.top picpi sub2api 注册 11 个帖子 - 8 位参与者 阅读完整话题
工艺站主帖： 【picpi 皮皮公益站】已3个月稳定不中断！ 主力模型:OpenAI Codex 这几天2~3月份注册的号掉了1000多个，存活的仅剩500个了。由于这批号都是没有绑定手机的，重新登录都需要接码，只能放弃这批号了。不过用了这么久，也算是寿终正寝了。 我从4月份开始就已经在为大量掉登录的情况做准备了，已经预料到，这批佬号可能在未来的一段时间掉登录，之后重新登录需要添加手机号。 从4月份开始我就已经在陆续注册绑定手机的账号了，目前有1000多个4月份绑定手机号的号，已经全部加入到号池中顶上了。注册机依然在继续注册，所以不用担心，我们的号池虽然折损很多，但是面对这波掉号潮还是没有问题的。 由于注册机开满了，账号活跃需求也随之增加，老友都过来聊聊天生生图呀。但是不要为了聊而聊，也不要用来生 图，正经使用就好。 【Picpi Chat 工艺站】2.0更新，性能优化，页面显示优化！支持聊天和 image2，支持图生图。 福利羊毛 从 【Picpi Chat 工艺站】支持聊天和 image2，支持上传图片，文生图，图生图，正式上线！ 继续 Picpi Chat 工艺站 服务器资源不足，只能开4线程，人多可能拥挤。 https://chat.picpi.top/ 2.0 更新 添加了图片生成等待动画 [image] 添加了图片画廊的支持，和GPT官网对齐。 [image] 添加了链接的支持，和GPT官网… chat.picpi.top PicpiChat 11 个帖子 - 8 位参与者 阅读完整话题
看到相关主帖都是去年的了，最近想克隆我声音制作视频，想知道现在有什么比较效果比较好的模型推荐吗（据我所知就是qwen，小米？minimax，但是实际效果我不太清楚）？感谢佬友们回答！ 6 个帖子 - 6 位参与者 阅读完整话题
可以展开/折叠的 Callouts 在新增回复帖或主帖内容变化后，会重置到其默认展开/折叠状态。 这不太算得上预期行为，因为同样有展开折叠特性的 <details> 就很稳定。 如果有人往一个 Callouts 里塞了很多内容，恰好浏览时还产生新回复或主贴修改，这个 bug 会很不爽。 [!tip]+ 默认展开 内容 [!question]- 默认折叠 内容 （点击了解更多详细信息） 1 个帖子 - 1 位参与者 阅读完整话题
这是一篇分帖，主帖请见： 编码尝试：使用Brainfuck实现Brainfuck解释器 - 开发调优 - LINUX DO 前 水 言 终于从无穷无尽的ddl里面解脱出70%了，能有点时间继续写了！ 先来给佬u们贴个成果截图： 自 举 自 举 自 总共套了4层： 最外层是 @so1ve 开发的BrainFrost。（BF→x86-64机器码编译器） 第二层是以16777216位长，16栈深构建的解释器。 第三层是以480位长，16栈深构建的解释器。 第四层是一个小小的echo程序。 太爽辣！ > w < 好了，说回正文：Boot 主帖中说到，这个Boot需要这些功能： 读取指令直到指令终止符。 重新编码指令以加速后面的运行。 将指令逆序写入 .text 段。 这一条是什么，滚木吗？ 我们来分析一下实现： 逆序写入是最简单的，只需要确保每一次 有效 输入之后会多执行一个 < ，我们就能左移一格。 主循环，稍难一点，它会一直执行直到读取到我们规定的终止符 ~ 。 一个巨大的类switch结构，这个最难，它负责识别不同的指令，并执行对应的逻辑。 一个重编码指令的逻辑，这玩意超级考验设计。 1. 内存分配 首先，我们需要一大堆的 > ，用来把指针移动到整个程序段的最右边，这些 > 的个数就是解释器程序段的大小。 按理说，有这么大就够了，但很显然，指针向左移动，意味着指针右边是写好的数据，而boot是有逻辑需要运行的，少不了临时变量，所以我们很自然地要把临时变量放在左边还没有写入的空白处。 问题来了，假如我们有16384格程序段，boot运行时的临时变量占用为n，那么当指针写完从左往右的第n+1格之后，再向左移动时，临时变量区就会撞墙，程序就炸了。 所以，在分配完所有程序段之后，我们还需要向右移动额外的n格。 第一段我们就写好了，像这样（假设我们有32指令段大小，并且boot需要占用8格临时变量） >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 程序段 >>>>>>>> 临时变量 2. 主循环 当我们移动到起点之后，我们就需要开启我们的主循环。 在brainfuck中，循环是依赖于0和非0的，我们必须要用数值来控制我们的循环。但很显然，这个循环长度我们预先不知道，所以我们需要使用 状态变量 来控制整个循环。只要状态变量非0，循环就会进行下去。在我们boot的逻辑中，循环只会执行一次，不妨一开始就把状态变量设为非0，然后在读到终止符的时候置0，这样循环就结束了。 状态变量的非0值，其实用多少都行，不过为了迁移（我们是需要逐渐把整个临时变量区左移的）的时候快速移动，这个数字距离0越近越好，所以我们可以使用1或者255。这里，我采用了1作为这个值。每轮循环结束时，我们都需要左移这个量。 然后，要进入循环，则循环之前我们需要把指针指到状态变量，一轮循环结束后，为了继续/跳出循环，我们也需要把指针移回状态变量。 我们据此可以写一个永远向左直到撞墙炸掉的循环： 我们假定指针最开始指在程序段的待写位，而待写位的左8位是循环控制位 {控}{ }{ }{ }{ }{ }{ }{ }{写} ^^指针初始位置 <<<<<<<<<+ 移动到控制位，并置非0 [ 主循环 [-<+>] 移动当前控制位到当前控制位的左1位 < 把指针移动到新控制位 ] 我们就做出了一个永远向左移动的循环。 3.直接输入与缓冲输入 未完待续 1 个帖子 - 1 位参与者 阅读完整话题
看到很多帖都没了， 提醒一下，大家小心说话，避免引起争议 看到很多关于某个话题的主帖都被举报没了，尽量不要提到相关话题， 无论你是否有恶意，都会被有心人恶意曲解成有恶意，从而造成骂战，导致管理需要控管一下， 被删帖就算了，反正也不影响，被封禁可以私下找管理申诉而不是在运营板块发帖 也不是只有发主帖会喜提七天大礼包，就算只是条评论，也可能会被封禁 如果要发就稍微修饰一下言词，不要直说XXX很糟，而是改成我觉得XXX可以更好 10 个帖子 - 8 位参与者 阅读完整话题