Linux.do热榜 · 2026-08-07 历史榜单

这是 2026-08-07 的 Linux.do热榜历史存档。查看 实时Linux.do热榜 获取最新排名。

1. 1
   说个恐怖故事：服务器G口已经不够用了

   比较敏感一些的佬友应该发现了，最近有时候访问社区帖子会出现偶尔的卡顿，再点又不卡。看服务器 load 也不是那么高，根本没往网络这块想，原来 1G 的带宽已经不够用了。 之前的截图没保存，我们随手截个sar图来看一看： 第二个口是 1G 网口，第五个口是我们升级新装的 10G 网口，大家可以算一下，其实已经超过 1G 带宽，不升级要丢包的。 昨天已经动用钞能力给社区所有服务器升级了 10G 网口，今天大家应该能感觉到访问流畅。至于为什么 1G 口还在用，是因为有些服务不想停机切换，有空再弄吧。 这当然构不成公告，我们想说的是：经过软硬件升级和评估，我们终于能再度开放实时私聊功能，佬友们可以点击头像旁边的对话按钮进行体验了。 不过多占用各位时间，接着奏乐接着舞～ 568 个帖子 - 557 位参与者 阅读完整话题

2. 2
   喜迎 DS-v4-Flash 紧急扩容

   太猛了，DeepSeek一发版本，在某个无人在意的角落，就有一个无名的社区要炸。 但这是好事，喜迎新国模，国模崛起是人心所向，需要大家多多支持。至于我们，没关系，直接加机器就行了。 社区已再度紧急扩容，接着奏乐接着舞～ 新模型出来了，都去支持一下啊，该测试的测试，该写代码的写代码，水什么社区呢 313 个帖子 - 306 位参与者 阅读完整话题

3. 3
   久等了，宝可梦机场之八月免费兑换码猜猜我是谁

   八月限定兑换码活动开启！ 各位训练家，八月福利已经到达！ 本月兑换码藏在一张神秘图片中，需要大家仔细观察、开动脑筋，找到正确的兑换码后，即可前往官网兑换本月免费流量。 活动玩法： 兑换成功后，可获得八月限定流量奖励。 https://love2.p6m6.com https://web1.52pokemon66.cc 326 个帖子 - 313 位参与者 阅读完整话题

4. 4
   这个冷饭是必须得炒一下了

   从搞点好玩的，进一步和Telegram集成继续讨论： 因为每天日志里最多报错就是这种了。为什么，因为根本就不知道怎么填啊，填 @xxx 的（还有直接填 @linux_do_helper_bot ）、填网址的、随便填几个字符串的。 加上这个插件本身没有校验填的 Chat ID 是否正确，然后就导致了日志里一堆此类错误： 所以不得不开个帖子炒下这个冷饭了，配置请仔细阅读帖子： 搞点好玩的，进一步和Telegram集成 运营反馈 现在我们可以通过 Telegram 收到关于自己的社区通知了，更可以快捷回复、点赞哦。 具体这么做： 打开 LINUX DO Helper 机器人，点击开始应该会收到操作指引。 复制指引中的 Chat ID 数字，填入：https://linux.do/my/preferences/profile 页面的 Telegram 通知 输入框后保存即可。 [image] 设置完毕后即可收到论坛通知… 填数字！填数字！填数字！ 276 个帖子 - 236 位参与者 阅读完整话题

5. 5
   差点猝死，而且丢失了期间所有记忆，佬们注意休息

   前天熬了个通宵，再此之前每天都是高强度vibe，连着一个月了吧，每天就睡4个小时左右，前天熬完通宵早上八点多了，手上的活马上干完了，但是有点困了，所以就想着要不去图书馆吧，离开了床就不会想睡了，所以我就喝了两杯咖啡，早上九点多到图书馆了，继续vibe到了14点左右，实在是累了，准备去网吧打会游戏。 到了网吧之后和朋友双排的，整个人也不咋在状态，大概16点多的时候我突然两眼发黑了，我就给我朋友说了一下，我说我状况好像不太对，也就是说完这句话之后，当我再次睁眼，已经是28个小时之后了，后面听我妈和网吧网管的讲述，我16:10分就在网吧包厢开始抽搐，然后彻底昏死过去了，120来了之后测了心率，210的心率，他们说当时我是有意识的，也能做出反应，甚至后面是警察送我回的家，我也自己回了卧室睡觉，但是我真的一点记忆都没有，给我的感觉就是，上一秒我给我朋友说两眼发黑了，下一秒就是28个小时之后了。而且抽搐的时候咬到舌头了，舌头上全是伤，现在吃个东西都很难受。 真的太恐怖了，还好我是在公共场所，要不然这会已经上天了。佬友们平时一定要多休息，活干不完可以慢慢干，命没了就真没了 题外话就是，我居然觉得这种感觉有点神奇，难以置信，他们都说当时我有意识也能回答问题，但是对此我真的一点记忆都没有，一片空白，就感觉是别的东西在控制我说的话一样 344 个帖子 - 312 位参与者 阅读完整话题

6. 6
   泪目，Cloudflare 大善人终于搞域名优惠了？

   坦白说比较少见 cf 搞域名优惠活动，这玩意有个数限制吗，有没有懂的佬友？ 续费价格： 123 个帖子 - 118 位参与者 阅读完整话题

7. 7
   【CHY公益站】上架自部署 k3

   公益推广 （点击了解更多详细信息） 为了节省资源，把 DeepSeek V4 的上下文压制到了 200K 244 个帖子 - 195 位参与者 阅读完整话题

8. 8
   14岁孩子在小天才手表里看黄片咋教育

   昨天晚上，媳妇儿给孩子小天才手表充电时，发现里面有黄片，该怎么教育孩子啊。 521 个帖子 - 481 位参与者 阅读完整话题

9. 9
   【小鸡毛】不要再问为什么小鸡毛GPT用不了了，已经泥菩萨过江自身难保了

   渠道基本上拉闸的差不多了，还有一小部分渠道和技术掌握在一小部分人手中 号池几百个PLUS，也不知道是破限弄死的，还是奥特曼杀死的 5月份至今的战绩： 维护渠道花掉的钱： 6570亿token，564956刀 76 个帖子 - 73 位参与者 阅读完整话题

10. 10
    记一次对 DeepSeek V4 Flash 0731、GPT 5.6 Luna/Sol、Claude Opus 5、Grok 4.5、Kimi K3 的真实项目需求的横向评测（仅 284B 的 T1 模型！）

    由于测试的模型越积越多了，表格会删除一些同厂商的旧模型，你可以在之前的评测帖子里找到它们的成绩。 项目 这是一个 Unity C# 项目，我进行测试的是一份皮肤系统需求案，我已经做了好预制体，而模型需要编写代码。 本轮与上两轮评测的项目和环境都完全一致： 第一轮 … 上一轮 模型来源 Grok 4.5: Grok Build Kimi K3: 火山 Agent Plan Claude Opus 5: Claude Code 自行中转 GPT 5.6 Sol/Luna: Codex 自行中转 DeepSeek V4 Flash 0731: 官方 API 速度 排名 模型 时间（分钟） 备注 1 Composer 2.5 3 2 Grok 4.20 0309 Reasoning 3 3 Step-3.5-Flash 6 4 Mimo V2 Omni 7 5 Doubao-Seed-2.0-Lite 7 6 Doubao-Seed-2.0-Pro 9 7 Doubao-Seed-2.0-Code 9 8 Qwen3-Coder-Next 9 9 Claude Sonnet 4.6(high) 9 10 Qwen3.5-Plus 9 11 GLM-5 Turbo 10 12 Minimax M2.7 10 Highspeed 版本 13 Qwen3.5-Flash 10 14 Grok 4.3 10 15 Gemini 3 Pro 11 16 Grok 4.5 13 17 Hy3 Preview 13 18 GPT-5.5(low) 13 19 Grok Build 0.1 14 20 GPT-5.5(medium) 15 21 Mimo V2 Pro 15 22 DeepSeek V4 Flash 0731 17 23 DeepSeek V4 Flash 17 24 Qwen3.7-Plus 17 25 Qwen3.7-Max 18 26 GPT-5.5(high) 19 27 Claude-Opus-4.7(Max) 20 28 GLM-5 20 29 DeepSeek V4 Pro 21 30 Gemini 3 Flash 22 31 Claude-Fable-5(xhigh) 23 32 Mimo V2.5 24 33 KAT-Coder-Pro V2 24 34 Minimax M3 25 35 Claude-Opus-4.6(Max) 26 36 GPT-5.5(xhigh) 28 37 Gemini 3.1 Pro(high) 29 受 429 请求频率限制影响 38 Claude-Opus-4.8(Max) 33 39 Kimi K2.6 33 40 Qwen3.5 9B GGUF Q4_K_XL 35 MBP M4 Pro 48GB 本地部署 41 Qwen3.5 35B A3B GGUF Q4_K_XL 36 MBP M4 Pro 48GB 本地部署 42 GPT 5.6 Sol 36 43 Mimo V2.5 Pro 37 44 Kimi K2.7 Code 39 45 GLM-5.2 45 46 Claude Opus 5 55 47 Kimi K3 93 48 GPT 5.6 Luna 95 令牌数 Grok 4.5: 未知 Kimi K3: 15M(¥40) Claude Opus 5: 24M GPT 5.6 Sol: 未知 GPT 5.6 Luna: 47M DeepSeek V4 Flash 0731: 21M(¥0.94) 代码行数 Grok 4.5: +1924, -18 Kimi K3: +1903, -6 Claude Opus 5: +1943, -8 GPT 5.6 Sol: +1201, -8 GPT 5.6 Luna: +1223, -13 DeepSeek V4 Flash 0731: +2184, -133 完成度 Grok 4.5 审查结论: 完成度非常高，出现两个功能错误问题。 （点击了解更多详细信息） Kimi K3 审查结论: 完成度非常高，出现两个功能错误问题。 （点击了解更多详细信息） Claude Opus 5 审查结论: 完成度非常高，出现一个细节问题。 （点击了解更多详细信息） GPT 5.6 Sol 审查结论: 完成度极高，无明显问题。 （点击了解更多详细信息） GPT 5.6 Luna 审查结论: 完成度尚可，存在功能未实现及多个细节问题。 （点击了解更多详细信息） DeepSeek V4 Flash 0731 审查结论: 完成度较高，但有多个细节问题。 （点击了解更多详细信息） 最终总结 排名 模型/层级 说明 Tier 0 该等级的模型实现与线上基线高度一致。 1 Claude-Fable-5 1 GPT 5.6 Sol 1 Claude Opus 5 2 GPT 5.5(xhigh) Tier 1 该等级的模型的代码正确完整且可编译，仅少量边界问题或轻微不一致。 3 Claude Opus 4.8(Max) 4 Kimi K3 4 Grok 4.5 4 GLM 5.2 5 Kimi K2.7 Code 6 GPT 5.5(high) 7 Composer 2.5 8 DeepSeek V4 Flash 0731 9 Kimi K2.6 10 GPT 5.6 Luna 11 GPT 5.5(low) 12 GPT 5.5(medium) 13 Claude Opus 4.6(Max) 14 Claude Sonnet 4.5 Tier 2 该等级的模型的代码至少可编译或仅极少量的语法错误，但是存在明显功能错误、遗漏或与需求/线上不一致。 15 GLM 5.1 16 Minimax M3 17 Mimo V2.5 Pro 18 GLM 5 19 Kimi K2.5 20 Claude Sonnet 4.6(high) 21 Qwen3.7-Max 22 Qwen3.5-Plus 23 KAT-Coder-Pro V2 24 DeepSeek V4 Pro(max) Tier 3 该等级的模型的问题很多且无法编译，或者存在不少幻觉。 25 DeepSeek V4 Flash(max) 26 Claude Opus 4.7(Max) 27 Qwen3.7-Plus 28 Grok Build 0.1 29 Grok 4.3 30 Mimo V2.5 31 Hy3 Preview 32 GLM 5 Turbo 33 Gemini 3.1 Pro(high) 34 Mimo V2 Pro 35 Mimo V2 Omni 36 Minimax M2.7 37 Step-3.5-Flash 38 Qwen3-Coder-Next 39 Gemini 3 Pro 40 Gemini 3 Flash 41 Doubao-Seed-2.0-Code 42 Doubao-Seed-2.0-Pro 43 Doubao-Seed-2.0-Lite 44 Qwen3.5-Flash 45 Qwen3.5 35B A3B GGUF Q4_K_XL 46 Qwen3.5 9B GGUF Q4_K_XL 47 Grok 4.20 0309 Reasoning Kimi K3 & Grok 4.5 Kimi K3 与 Grok 4.5 犯的是同一个问题，果然是同根生。 Grok 4.5 是我日常偶尔在用的模型，因为它速度快，效果也不错，非常期待它后续的 Grok 4.6、Grok 4.7 版本。 Kimi K3 的速度实在是太慢了，再加上消耗的令牌数也不低，所以直接打破了评测最长耗时记录，并且遥遥领先，整整花了一个多小时才完成了测试。 最近我在尝试使用 Kimi K3 重构一个项目的 UI，这是一个由 GPT 5.6 生成的管理工具，即使我给出了多个设计要求，但界面依然是非常浓郁的 AI 味。 Kimi K3 在这方面确实非常不错，它给出来的设计草案和 Demo 看起来很棒，两者对比之后才发现觉得 GPT 5.6 编写的界面有 AI 味的原因。 GPT 5.6 的设计主要差在排版、整体元素的大小和间距上，Kimi K3 的设计则更加精致。 由于 Kimi K3 的重构工作还未完成，就暂时不放图片出来对比了。 总结来看，我会愿意让 Kimi K3 进行 UI 设计，但在其它任务上，无论考虑速度还是性价比都不如使用 GPT 5.6。 而 Grok 4.5 的速度非常快，在日常任务中我愿意使用它来替代 Composer 2.5。 Claude Opus 5 Claude Opus 5 花费了 55 分钟完成了评测，我认为一部分原因是它读取了非常多的 .prefab 文件，并且非常深入，因为它找出了很多预制体上的问题（虽然并不在需求要求的范围内）： - m_goListContent 未绑定 ContentSizeFitter 组件，滚动范围可能不对。 - Viewport 的 Mask 没有 Graphic，实际不会裁剪。 - m_goTemplateListItem 上没有 Button， 可能无法点击。 这些问题是第一次有模型提出，而且我确实有印象，在之后的线上版本中我陆续修复了这些问题。 但预制体并不在评测范围内，因为我也不想它直接去读取预制体文件（数据量很大，费 Token 也费时间，所以我有在需求案里直接描述了所有相关预制体的结构），只能说耗时过多情有可原，但也不予加分了。 代码的完成度上，Claude Opus 5 只犯了和 Claude Fable 5 一样的一个细节错误，比 Claude Opus 以往的版本的表现都要好。 GPT 5.6 Sol GPT 5.6 Sol 在浏览了一遍代码库之后，遵从指令向我询问了它不确定的问题。 这是 GPT 5.5 及其它模型都没有做到的，或者说它们并没有发现这些问题，因为询问的问题都是之前模型易错的问题。 GPT 5.6 Sol 花费的时间也是 GPT 系列模型有史以来最长的，它不仅阅读了代码，还阅读了配置表。 值得一提的是，GPT 5.6 Sol 我是测了两次，因为第一次评测时，我发现它在遇到问题时，并没有直接向我提问，而是先去查找提交历史、其它分支的代码，它通过这种方式发现了线上分支的代码，于是我直接中止了对话。 这种情况可能之后会越来越常见，评测的环境需要更加严格了。 最终，GPT 5.6 Sol 相对 GPT 5.5 来说，它花费的时间更长，但是它也做得更多。 即使需求案里没有要求的，它也会认为这是应该做的，比如说这个评测需求里，红点系统、自动切换系统都只写了一半，涉及到的地方都使用了 TODO 进行注释。 虽然皮肤涉及到了这些系统，但是需求案并未要求要补全红点或者自动切换系统的功能，GPT 5.6 Sol 还是默认认为这些系统应该是完整的，尽力去做了。 DeepSeek V4 Flash 0731 这篇文章中前四个模型其实在上个星期就测好并且写好了总结，但一直不太想发布，因为一直在等一个良（梁）日。 突然今天 DeepSeek V4 Flash 正式版发布，并且 GPT 5.6 Luna 的价格令人震惊瘫坐，看来吉时已到，正好测了立马发布。 本次 DeepSeek V4 Flash 正式版与预览版本的表现确实天差地别，以下分点说明： 正式版本用时与预览版本差不多，但是正式版本在完成编码后花了几分钟尝试用各种方法想要通过编译去验证代码正确性，要说明的是由于是 Unity 项目，一般模型是不去编译验证的，因为 dotnet build 会失败。 前 10 分钟，它都在阅读已有代码库，大概有 5 分钟都在尝试编译验证代码，实际编码的时间我估算只有 2 分钟左右，而预览版本是没有尝试编译验证的，不考虑这部分时间的话，正式版本的速度要比预览版本快 5 分钟左右，也就是快了 30%。 他会通过 python 去解析必要的 Prefab YAML 文件验证代码正确性，很少有模型会做到，但最后的总结报告并没有像 Opus 5 一样找出预制体中的问题，当然也没有像 Opus 5 一样花了太长时间去阅读预制体。 DeepSeek V4 Flash 也像 GPT 5.6 Sol 一样，即使需求案里没有要求的也去做了，比如红点系统，并且令人惊喜的是，它给出了有效的总结报告，即指出了自己疑惑、猜测出的决策： # 需要你确认的设计决策（需求未明之处） 1. "新皮肤"红点判定：服务器未下发新皮肤标记，我按客户端推断实现 —— 首次出现的已拥有皮肤（启动 useSkins + 打开界面返回的皮肤列表）标红，点击任意红点皮肤后全部清除。功能上线时老玩家的已有皮肤会先亮一次红点。 2. S2C_SKIN_LIST.TotalAttrs 未使用：由于 C2S_SKIN_LIST 按类型请求，TotalAttrs 是单类型还是全局总和无法确认，属性总览改为按文档描述客户端合并（使用中皮肤属性求和）。若服务器期望用 TotalAttrs，请告知。 3. 称号预览等级：项目无玩家等级字段，m_textTitleUserLevel 显示的是神针等级（主城建筑等级）。 4. 已过期皮肤视为未拥有（显示锁定 + 去获取按钮）。 5. 气泡预览中的 m_textBuble 文字：需求未定义内容，保留预制体默认，未做修改。 犯了经典的皮肤类型映射错误，还有预览展示错误、初始化数据问题，而且出现了少见的独立页签状态和使用中缓存问题。 最终，根据审查结论，DeepSeek V4 Flash 正式版的完成度逊于 Composer 2.5、GLM 5.2 等模型。 将 V4 Flash 正式版排在 GLM 5.2，甚至是 Composer 2.5 的后面可能招来很多争议，我也有心理准备。 特别是有像 DeepSWE 这样也非常符合我的使用体验的基准测试，测试结果是 V4 Flash 正式版的得分超过 GLM 5.2 不少。 但通过我自己这次进行的 Unity C# 需求开发中的表现来看，284B 能有这个表现已经非常惊艳了，但用 284B 的模型全面战胜 1T+ 的模型，在评测过后，我持怀疑态度。 GPT 5.6 Luna GPT 5.6 Luna 这次测的是 Max 思考程度，由于它现在的价格在购买订阅后几乎等于不要钱，并且宣传的速度也非常地快，那么我对它的实际能力就很感兴趣了。 实际测试有一点大跌眼镜，在 Max 思考程度下，它竟然打破了 Kimi K3 的耗时记录，花费了 95 分钟才完成了整个测试！ 这并不是它的令牌输出速度太慢，实际上是执行步骤非常多，花费了整整 47M 的令牌数，是一般模型的 4 - 5 倍。 GPT 5.6 Luna 主要犯了一个功能未实现的严重错误，但其实它可以完成的更好，它在中途其实已经停下来询问过自己不清楚的地方， 但由于这些问题都可以从代码库中找到答案，所以之前模型的询问我也是没有直接给出答案，而是让模型自行仔细阅读代码。 但最终依然没完成此功能的开发，总结中也有列出自己未实现此功能，是因为无法找到对应的数据。 这样看来，GPT 5.6 Luna 给我的感觉就更像是 GPT 5.6 Sol 的阉割版，能够思考但是又思考得不足。 导致了它在面对这种对它来说复杂的需求时耗时太长，且最终完成的效果也不够好。 作为一个定位是经济快速的模型，在这种需求上实际体验不如 Grok 4.5、DeepSeek V4 Flash 这些模型。 总结 前沿模型完成任务的速度越来越慢了，无论你是说因为模型大了还是高峰期限速之类的，最终对于用户来说就是慢了，除了 Grok 4.5、DeepSeek V4 Flash 以外，其它几个模型花费时间都超过了 30 分钟。 模型猜测用户意图的能力越来越好了，Opus 5、DeepSeek V4 Flash 会查看预制体中的错误，5.6 Sol 会查看配置表中的错误；在这个评测场景来说是好的，但是否会过拟合还得再测试更多场景。 DeepSeek V4 Flash 正式版与 Grok 4.5 会替代 Composer 4.5 成为我日常快速任务使用的模型，首先它们足够快，给人的感觉都很可靠，其次效果也足够好，而 DeepSeek 主要胜在不用担心降智，价格极其便宜且易于获取。 Kimi K3 与 Opus 5 成为我前端、架构、3D 设计所使用的模型，之前我不会为了这些任务专门使用一个模型（只用 GPT）。 GPT 5.6 Sol 成为我的主力模型，之前是 GPT 5.5。 GPT 5.6 Luna 在订阅中价格便宜，但对于复杂需求来说不太好用，但不排除它有非常好的执行简单任务的能力。 T1 行列现在已经成为基线了，DeepSeek V4 Flash 正式版的发布甚至让其已经成为斩杀线了，非 T1 模型几乎不用再考虑使用，并且期待第一个进入 T0 行列的国产模型出现。 70 个帖子 - 65 位参与者 阅读完整话题

11. 11
    【蓝色大肥鱼竟敢吃白饭】

    ds v4没发布时：金融吸血鬼的谎言泡沫即将破裂 v4 预览版发布时：deepseek的新一代大模型发布，但代价是什么？ v4 预览版承认由于gpu产能导致现在自己价格虚高时：一颗新星正在冉冉升起 v4 预览版打二五折时：开源界的英雄正在拯救闭源的黑暗ai界 v4预览版宣布命中缓存输入打1折时：德技双馨的老企业家梁文峰再攀高峰 v4预览版宣布25折永久保留时：伟大的梁圣和他的大赢鲸莅临ai界 v4 正式版迟迟不出时：爱梁，信梁，等梁 v4宣布涨价：蓝色大肥鱼竟敢吃白饭， v4正式版跳票：小难梁掏不出大赢鲸 ds官方未就跳票做出解释：大wait die梁子重新定义七月中旬，ds的神话还能持续多久？ gpt luna降价：新一代斩杀线正清算被背信弃义的伪朝 v4 flash 0731发布：亿万鲸子清算！对所有AI企业后门进行深度求索！ 42 个帖子 - 41 位参与者 阅读完整话题

12. 12
    [富可敌国]「粥.Pro」全网首发“号池可见“且”重置同享“的GPT纯Pro中转站！佬友共可领15刀~

    首先感谢L站提供的推广机会~ 作为程序员真心喜欢这个社区~ 站点简介 【粥.Pro】是 ChatGPT Pro 账号专营中转站，站点链接：https://congee.pro 不玩数学游戏，充值比例 1￥ = 1$ 不设订阅捆绑，随充随用 0.20x 倍率 真诚换取信任，注重中转用户体验 QQ群：450981902 点此链接加群 建站初衷 期望解决所有中转站用户的两大痛点，也是部分佬友不愿意用中转站的两点顾虑： 无法确定中转站是否真的纯血 官方重置都被中转站赚进口袋 本站特色 期望建造一个更趋近账号拼车的平台，让大家看见账号情况，享受账号级权益： 首创用户可见号池，包括登录类型、订阅档位、剩余用量、重置次数等账号数据均下放至用户级可见，让大家清晰的查看到自己每一条使用记录的实际承担账号。 首创重置返额机制，若官方按下重置按钮或发放重置次数，本站将会把重置周期内用户实际消耗金额的90%返还为周限时额度，让大家同享周额度重置的乐趣。 些许福利 小站初营，感谢佬友们捧场支持，献上专属福利: 本站账号登录立得 5$ 本帖评论已注册的用户ID加赠 5$ 进群报上已注册的用户ID再赠 5$ 福利以限时额度到账，额度有效期3600天，可放心领取~ 限时额度 设定主要用于限时权益管理和退款金额统计，不会影响正常使用~ 限时额度全分组可用，不设范围限制 调用时优先消耗限时额度 1:1 抵扣普通额度 限时额度同样享受 重置返额机制 权益 目标用户 如果您符合以下用户特质，不妨来小站试一试呢 厌倦了在断断续续的低价渠道间东奔西跑 自充Plus号不够用，自充Pro号又用不完 想安稳用Pro号但担心号池混用和二手渠道 每次看到官方重置都眼馋自充党还假装不在意 想随充随用，不想背负周期限额带来的用量焦虑 站长想法真不错！我单纯想要支持一手 容量考虑 因小站首开试营，不敢肯定大家能共情接纳此运营模式，准备不一定完全充分。 福利预告 官方未重置，本站抛砖引玉，顺便测试功能完整性。 重置返利机制 的形式 返还30%周限额度。 站点链接： https://congee.pro 3368 个帖子 - 3246 位参与者 阅读完整话题

13. 13
    准备下一个项目就是动态家宽IP 和 家宽IP订阅节点 看看有多少需要要的，完成后送CDK【8/3 05:36 道爷我成了】

    准备下一个项目就是动态家宽IP 和 家宽IP订阅节点 看看有多少需要要的，动态家宽IP已经写完了测试完了 接下来就是订阅节点功能加上去看看我的出口节点咋样 https://linux.do/t/topic/2693888/6 新帖子 8/3 05:38 8/3 05:36 终于是写完了测试完了，今天发CDK 就50张 关注我，新帖子里会有CDK链接！ 就放几个出口IP吧 现在上千个家宽已经就绪 8/1 8:48 还没弄完，睡醒再弄了 8/2 18:23 起来了继续弄，动态api 我觉得暂时不会放了防止滥用也因为现在的带宽小承载不了太大，晚上好了放50位 7天订阅节点CDK 8/2 21:39 做最后的审查和测试明天放测试CDK 8/3 0:43 基本上完活了，白天或者晚上开放CDK测试 不做推广 我会另发帖子 173 个帖子 - 150 位参与者 阅读完整话题

14. 14
    【霸气公益】已运行超 1 年的公益站-纯国模-260801更新

    本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是 / 否 我的帖子已经打上 公益推广 标签： 是 我的项目属于个人项目，与公司或商业机构无关： 是 我的项目不存在QQ、TG等群组引流： 是 我的项目不存在非运营必要的网站引流： 是 我的项目不存在为他人推广、AFF： 是 我的项目无关联的商业项目： 是 我的站点存在登录，并已接入 LINUX DO Connect： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 平台昨日下午已更新最新deepseek-v4-flash-0731，同步上线hub站了 欢迎各位佬体验，2000元3个官方账号负载 手机编辑 有不到请佬们之处见谅 公益站地址：http://ai.121628.xyz 119 个帖子 - 102 位参与者 阅读完整话题

15. 15
    记录L站第一次中奖MacMini

    抽奖原帖：https://linux.do/t/topic/2663260/1567 @aihub 昨天午休刚睡醒，看到有个邮件通知，然后发现中奖了（中奖绝缘体） @aihub 佬的效率挺高的，不到 24 小时就收到了，真的特别感谢 来到L站学到了很多，也落地实践了很多 相比中奖，我觉得最大的收获还是在L站每天学习一点点，然后动手操作强化 真诚友善是必杀技，团结专业行稳致远 104 个帖子 - 103 位参与者 阅读完整话题

16. 16
    小孩子可以学 AI 原理吗？作为一名 11 岁接触 LLM 的小孩子，分享一些看法~

    Edit 建议佬友们读完全文再发帖讨论QAQ Edit 2 给没看过原帖的佬友大概介绍下背景，原帖是一位爸爸问能不能让自己的孩子学 ai 原理，下面有一些人说孩子太小不能学。我写这篇帖子的目的是为了证明这个年龄段的孩子可以学习 ai 原理。看来有不少佬友没看过原帖，我也确实表述没有很准确 qaq 从很想听听佬们的意见：孩子真的不能学习AI原理吗？继续讨论： 今天刷到一个帖子，发起讨论「孩子是否可以学习 AI 原理」。帖主 @StarFox 认为可以，因为简单理解 Transformers、CoT 的原理不一定要有数学基础。立刻有人反驳：不会线性代数，搞不明白向量叉乘，没有基础、黑盒学习能有什么效果？ 帖中讨论的对象主要是四、五年级到初中的小孩子，而幸运地，我正是在这个年龄段开始接触和使用 AI，也属于讨论的对象中的一员。评论区不少人是大学生、研究生、博士生，更多的人已经毕业工作，学识和能力都无疑在我之上，对于 AI 的理解也远比我深刻。然而，一些人对于我们的推测和断言，与我的体会有所偏差。古人云「耳闻之不如目见之，目见之不如足践之」，所以我今天斗胆来分享下自己的一些看法，还请多多指教。 先中译中一下帖主的意思。他所说的「简单理解」其实是一种直觉上的理解，或者说是「通过理解内涵逻辑从而塑造培养直觉」的方法。 比如梯度下降，公式上的理解是 \boxed{\theta_{t+1}=\theta_t-\eta\nabla J(\theta_t)}。而直觉上理解梯度下降则只需要在脑中构建一个高低起伏的空间，一个点从某一个位置出发，总是朝向向下坡度最大的方向移动，最终所有方向坡度都向上时（在谷处）停止。 不难发现，公式上的理解通常需要积分、导数、矩阵乘法、凹凸性的高数知识，而在直觉上理解是并不需要数学基础，是个人都会。在这里，如何表示「高低起伏的空间」、如何计算「向下坡度最大的方向」是哪个、如何计算「向特定方向移动后的坐标」，都像一个个封装好的函数。函数里具体是如何实现的，在这个阶段不必了解。 这就反驳了评论中常见的一种错误观点：学习原理就必须有高数基础。 接着我们再看评论中另一个常见观点：学习原理对应用没用。实际上，这种「直觉上的理解」对于应用 AI 相当有用。 因为如果他们在直觉上理解了注意力机制，就不难理解为什么指令要求后面加上一堆感叹号不能起到强调作用反而会稀释注意力，为什么 prompt 重复两遍可以提升性能、而重复五遍会降低表现[1]。如果他们在直觉上理解了 Tokenizer 的原理，看到模型算出 9.11>9.9、strawberry 里有 2 个 r 就不会大惊小怪[2]。如果他们知道每次预测都要综合计算前面所有上下文的 KV 矩阵，就能明白 context 管理的重要性，也就能明白如果模型拒绝要求时继续说服是没有效果的[3]。如果他们了解过拟合，就很容易推理出为什么<think>可以获得随机回复[4]。如果他们理解了语义激活，就能明白为什么 prompt 中使用正面要求比负向写法效果更好[5]。 再说说评论区中的另一种观点，就是愿意学习、有能力学习 AI 原理的孩子太少了。这就是太低估新时代的小孩子们了。读到这里可能一些人觉得我很厉害，而这种厉害只是个例。这句话有两个错误，第一，我并不厉害，第二，有无数比我年龄小、却比我厉害的多的人。前年我和学校里的一位同级生一起参加比赛，他在没有 Claude Code 的时代就已经精通十几种编程语言[6]。他在那场比赛中获得一等奖，而我却忘了保存拿了零分。今年我考入了苏州中学，而和我同一年入学的，还有比我小半岁、却维护着一个规模比我的项目大得多的 GitHub 仓库的 Nemo2011。今年是他维护这个 4.2k stars 仓库的第五年。即使倒退回几年前，以他们的智商和能力，不可能学不会 AI 原理。这样的人我身边就有三四个，可想而知，有能力有兴趣学习 AI 原理的孩子绝不在少数。 感谢你阅读到这啦。本文在飞机上撰写，没有网络因此部分信息没有查证，如有事实性错误，欢迎指正ww 来自 Google Research 2025 年末的一篇论文 Prompt Repetition Improves Non-Reasoning LLMs。原因是注意力是单向的，模型只看前文而不看后文，导致看问题前半部分时看不到后半部分。如果重复两遍，第二遍时看问题的前半部分就可以综合第一遍时问题的半部分，类似人类的回读。只对非思考模型有效，因为思考模型在思维链中会自己重复一遍。重复过多次会导致注意力涣散和减弱。 ↩︎ 模型不会数数一般是并行概率拟合本身不擅长计数、加之重复数据可能出现的结构位置混淆导致的。但 strawberry 里有几个 r 确实是 tokenizer 的问题。 ↩︎ 正确的做法是将拒绝的消息删除，然后重新发一遍 prompt。当然这个方法只对确实不该拒绝的情况有效，比如模型因为某些执念不想直接告诉你答案（非要你自己算）用这个方法可以解决，但模型如果因为请求违反伦理或政策而拒绝，就通常需要更复杂的破限方式。 ↩︎ DeepSeek 某个版本中，无上下文情况下发送<think>可以获得模型对一个随机问题的推理过程。当时小红书就有好多人觉得是 DeepSeek “把其他人的回答发送给我了”“非常恐怖会不会是数据泄露”，而且这样的帖子能获得数千点赞。实际原因是模式诱导。广义上来说也是过拟合的一种（格式过拟合）。 ↩︎ 也就是粉红大象效应。在 SOTA 模型中这个效应已经没有那么明显了，在大多数情况下他们可以很好地处理负向要求。但效果仍不如正向要求。 ↩︎ 本文发表后有人提出疑问。在此补充说明，这是他的自述，我未加修改。不过，无论能不能达到一些人心目中的「精通」标准，都不影响本文的论述逻辑链条的自洽性。 ↩︎ 227 个帖子 - 161 位参与者 阅读完整话题

17. 17
    「开源」拯救你的 grokfree，实测完美运行降智避免插件！

    本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 直接上图： 来说一下原理，我上一个帖子说过了， github.com GitHub - lij768423-svg/grok2api-egress-enhancements: Grok2API & CPA egress quality guard with proxy... Grok2API & CPA egress quality guard with proxy recovery, quarantine, migration, and operations UI 注册机 github.com GitHub - lij768423-svg/grok-register-panel: Grok register engine (Camoufox) + live web monitor... Grok register engine (Camoufox) + live web monitor panel cpa插件 【开源】 拯救你的 grokfree之 cpa 插件开源 开发调优 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 前情提要： … 243 个帖子 - 80 位参与者 阅读完整话题

18. 18
    关于渐进式披露工具上下文的几种方向讨论

    首先的首先，我们可以把大模型粗略看作一个极其复杂的函数。在这个函数里，每一次交互的输出（Response），都建立在输入（Context）的基础之上；如果写出来可能是： 在之前的 Agent 开发中，受限于各种繁杂的业务需求，以及在 AI 辅助开发的各种防御型编程习惯的诱导下，很多开发者为了让 Agent 在长程任务中表现得更聪明、不犯错，会倾向于在 System Prompt 里塞入无穷无尽的规范，在 Tools 里注册成百上千的工具 API，试图期望通过穷尽一切可能性，来覆盖复杂的业务场景。 至少我之前工作的公司就这么干的 毫无疑问，这种暴力堆料必定会碰到两面墙：一面是理论的墙，一面是现实的墙。 从信息论的视角来看，输入与期望输出之间的 互信息 决定了模型表现的上限。现实世界的信息复杂性是无法被轻易压缩的，这意味着为了让模型准确理解“目标是什么、为什么这么做、以及具体该怎么做”，我们确实必须给它提供相当充足的上下文。但矛盾之处在于，当我们指望 Agent 去执行一个横跨数小时、涉及几十轮决策的长程任务时，整个任务的决策树会呈现指数级的膨胀。如果我们为了应对所有潜在分支，在一开始就把极其庞杂的信息（成百上千的工具、巨细靡遗的规范）全部塞进去，那么对于模型在当前这一步的决策而言，大部分上下文不仅无效，反而构成了巨大的噪声。有效信息被淹没，互信息被严重稀释。信息越涣散，模型调和冲突与“瞎猜”的空间就越大，幻觉和偏离目标的概率随之飙升。 图：当前的 agent 与 harness 的关系 bybike： 在信息论中，互信息（Mutual Information, MI）衡量的是一个随机变量中包含的关于另一个随机变量的信息量，或者说通过观察一个变量所能减少的对另一个变量不确定性的程度。输入与期望输出之间的互信息实际上构成了模型输出质量的信息论上界：如果输入所携带的关于目标输出的互信息不足，无论模型能力多强，也无法可靠地还原出完整、准确的期望输出。 而从现实工程的视角来看，无限膨胀的上下文意味着什么？意味着令人难以忍受的首字延迟（TTFT），意味着极速燃烧的 Token 预算，以及在超出 Prompt Cache 命中范围后高昂的算力成本。 随着一个 ai agent 系统的不断发展，如果人类不会定期彻底审阅一遍 ai 的各种规则上下文（agent.md，memory，各种项目记忆开发规范等），那 ai 看到的上下文里的规则冲突会越来越多，直到编程一大坨屎山。模型在长程任务中就必须不断消耗宝贵的思考 TOKEN 去调和这些相互冲突的指令，去跳大神猜测哪条优先，用户到底想要什么。 最好的例子就是 SuperPower 等各种所谓的深度定制化规范开发的 Skills，可能它在六个月前确实是一个还不错的 harness 方案，但在 5.6 之后就显得十分的臃肿可憎。A\ 在迭代 Cladue 5 时代的 harness 时，直接将 Claude code 的系统提示词删掉了 80% 且没有观测到能力受损，可见模型能力进步之幅度。 图源：A\ 工程师的官方博客，描述了上下文规则里相互打架的现象 那我们应该如何破解这个「既要足够的信息量，又要极低的噪音和成本」的死局呢？ 目前的一个相对较优的答案是：渐进式披露。Anthropic 此前提出的 Skills 机制向工程界普及了这一哲学：我们不在一开始把所有知识甩给模型，而是给模型一个目录/索引，让它在需要时主动去检索和加载。这极大地释放了 System Prompt 的空间。 既然“知识约束（Skills）”可以被渐进式披露，那占据上下文另一大头的“工具（Tools）”行不行呢？ 答案是可行的。随着当前模型直觉规划能力和错误反思能力的提升，工具的按需加载在当前阶段已经具备了落地条件。但与普通的文本检索不同，工具的渐进式披露有着极其特殊的工程挑战。今天我们就来盘点一下，为了让工具“按需出现”，业内到底演化出了哪几种截然不同的方向。 一、必要的理解上下文 1.当前 agent 的工具调用机制是什么？ 相关概念我在之前的博客里已经重复过很多遍了，不过这里最好还是再重复一遍：我们日常看到的所有 Agent——不管是 Claude code、codex、Cursor 还是别的什么 Harness 框架——其内部的模型都一直，且只会做一件事，即预测并输出下一个 token。所谓调用工具，本质上是模型在某一刻，按照预先约定的格式，吐出了一段结构化的文本。 这是理解后续一切设计取舍的起点。 一次请求长什么样？ 当我们和 Agent 对话时，每一次发给模型的请求除了 system prompt，除了我们看到的聊天信息，背后大概还会附加一个 tools 的参数。一个最简化的请求大概是这样的： { "messages": [ { "role": "user", "content": "查询北京天气" } ], "tools": [ { "name": "get_weather", "description": "查询指定城市的天气", "parameters": { "type": "object", "properties": { "city": { "type": "string" } }, "required": ["city"] } } ] } 此即「注册工具」，我们把工具的名字、用途描述、参数契约塞到请求的 tools 字段里，告诉模型「这次对话中你可以用下面的这些东西」；模型在收到请求后，有两种可能的回应方式。第一种是我们最熟悉的，它会直接回一段自然语言： { "role": "assistant", "content": "好的，我来帮你查一下北京的天气。" } 第二种就比较有趣了，模型可能会判断「这个问题我应该调用工具而不是直接回答」，于是它返回的内容变成了这样： { "role": "assistant", "content": null, "tool_calls": [ { "id": "call_123", "name": "get_weather", "arguments": { "city": "北京" } } ] } 注意，这个 tool_calls 不是我们从模型输出的普通文本里用正则抠出来的，它是 Provider API 返回的原生结构，通常还会带一个 finish_reason: "tool_calls" 的标记。我们本地的 agent 程序看到这个标记，就知道模型不是在对用户说话，而是在说：「我需要执行这个工具，请把结果拿回来给我。」 至于 Provider 内部是怎么让模型乖乖吐出这种格式的，各家不完全一样：可能把工具定义序列化成特殊的提示词格式，可能用训练过的专用 tool-call token 标记调用边界，也可能在输出阶段施加 JSON Schema 级别的语法约束，确保模型产出的参数类型和结构严格符合注册时的定义。但万变不离其宗，输入中多了工具定义，输出中多了一个结构化的工具调用通道，仅此而已。 如果不注册呢？ 反正大模型是一个输入什么东西然后再输出什么东西的黑箱嘛，那假设我们不把 get_weather 放进 tools 数组，只在聊天消息里写一句：「你可以调用 get_weather，参数是 {"city": "北京"}」，这种情况下模型也当然认得这句话，甚至可能输出一段看起来很规整的 JSON： { "name": "get_weather", "arguments": { "city": "北京" } } 但这只是普通文本。在这种情况下，Provider 不会把它标记为 finish_reason: tool_calls，不会帮我们做参数校验，也不会给我们一个 call_id 来匹配后续的工具执行结果。我们的本地程序必须自己解析文本、猜测这段 JSON 是不是工具调用、手动校验参数格式、自己处理各种边界情况。 不过话说回来，这种「文本协议」在过去其实也流行过。在 2023 到 2024 年乃至2025年，很多 Agent 框架和工具走的恰恰就是这条路，最典型的就是 ReAct，还有 2024 年的 Claude Dev/Cline，以及后来继承这套机制的 Roo Code 和 Kilo Code 早期版本。它们的做法很朴素：在 System Prompt 里用 XML 或 Markdown 描述所有可用工具，然后让模型在对话中按约定格式输出调用指令。客户端捕获到符合格式的文本块后，解析、执行、把结果拼回对话。 这种实现在早期主要是为了快速兼容不同渠道的模型，不用管它们是否真的支持 Tool Calling；但代价是没有 Provider 层的语法约束，模型偶尔会写出格式跑偏的调用，如参数名拼错、少一个括号、甚至自由发挥出一段解释代替调用。这就对框架本身提出了很高的要求。随着各个 Provider 的原生 Tool Calling 越来越成熟、尤其是 Strict Tool Use 和结构化输出这类能力逐渐普及，文本协议路线在可靠性上的差距被越拉越大，慢慢退出了主流视野。 换句话说，两条路线的根本性差距在于： ❌ 文本协议（不注册）： 模型输出普通文本 → 本地自己解析 → 判断是不是工具调用 → 校验参数 → 执行 ↗ 灵活，但可靠性和工程复杂度全由框架承担 ✅ 原生 Tool Calling： Provider 返回正式 tool_calls → 本地直接读取 name、arguments、call_id → 校验授权 → 执行 → 按 call_id 回传结果 ↗ 可靠，但受限于 Provider 的 JSON Schema 约束 这件事为什么重要？ 在前面的讨论中，我们可以得到一个很简单的结论： 要做原生 Tool Calling，工具就必须出现在请求的 tools 参数里。Provider 在推理开始前就需要拿到所有工具的完整契约，否则它无法建立语法约束，也就无法产出合法的原生 tool call。 这件事听起来简直就像「人被杀就会死」一样合理自然，单独来看确实没什么。大部分 Agent 几个十几个甚至几十个工具，我们全部注册进去不就完了？ 直到 Agent 的能力越来越强，直到我们可能期望它在一个会话中灵活调度上百个工具。这时候，把全部工具定义一次性塞进 tools 数组就变得不再现实。 我们可以做一个简单的算术：假设一个工具的平均定义（名称、描述、参数 Schema）需要 400 个 token（这是一个非常保守的估算），那么两百个工具就占据了 80k token 的上下文；如果用户再疯狂一点多加一个 MCP，这些工具定义的总 token 数会迅速逼近甚至突破模型上下文窗口的实际可用的注意力上限；而即便没有突破，留给用户消息、历史记录和推理链的空间也会变得极其紧张。 几个月前，主流旗舰模型的实际可用上下文窗口大概在 150k 左右，而现在则普遍到了400-500k，不由得令人感慨 AI 能力提升之迅速；但可用窗口的增长不代表我们就可以当败家子嗯造上下文空间了，模型的注意力机制在大量低相关性的工具描述上仍然会产生显著的信息稀释和上下文腐烂效应。 那么，我们假设，如果一个 agent 有几百个工具，我只想在模型真正需要时才把工具的定义给它，会发生什么？实现起来容易吗？ 2.渐进式披露，和为什么渐进式披露工具需要独特的工程设计 为什么渐进式披露 Tools 会比 Skills 更加困难 答案是：在当前的 Agent 架构下，这件事会比想象中困难一点。 它触及了原生 Tool Calling 机制的一个根本性矛盾。在讨论 Tools 之前，我们先看一个相对轻松的参照物：Skills。 Skills 的渐进式披露在业界已经相当成熟，实现起来几乎没有阻力，因为 Skills 的本质是纯文本内容，一段 markdown 指令。它的加载流程是：用户提问，模型判断需要某个 Skill，Agent 从本地读取对应文件学习到相关领域知识，并据此回复或工作。 在这个过程中，所有的信息增量发生在消息的末尾，不涉及任何最前方请求结构的改动。 而“不改动前面的上下文结构”在当今的 AI 工程实践中恰恰是极其巨大的一项优势——因为它完美契合了各大模型厂商的上下文缓存（Prompt Cache）机制。 为了降低长文本推理的成本和延迟，当前主流 Provider（如 Anthropic、OpenAI）的缓存逻辑是：只要两次连续请求的前缀（Prefix）在 token 层面完全一致，模型就能直接复用前一次的 KV 计算结果。但这个机制极其严苛：前缀必须一模一样，哪怕在中间修改或插入了一个 token，后续所有的缓存就会瞬间报废。 理解了这一点，我们就会明白 Skills 渐进式披露的做法有多么平滑。当客户端在对话中途追加一条带有 Skill 内容的消息时，排在它前面的 System prompt、tools 数组、以及早先的历史消息可谓纹丝不动。因此，新请求的前缀没有遭到任何破坏，庞大的基础上下文依然能稳定命中缓存。新加载的知识只影响它之后的计算过程。 但 Tools 不同。 回顾第一节，原生 Tool Calling 要求工具的完整定义必须出现在请求的 tools 参数中。Provider 在推理开始前就需要拿到所有工具的 name、description 和完整的 JSON Schema，才能： 构建工具调用的特殊语法约束（如 Anthropic 的 Strict Tool Use 或 OpenAI 的 function calling grammar）。 在输出阶段识别 finish_reason: tool_calls 并正确解析结构化字段。 验证工具名称和参数类型是否合法，拒绝模型产生的幻觉工具调用。 如果我们不在 tools 中预先注册某个工具，Provider 就不会为它建立语法约束。即使模型自己在普通文本中写出了该工具的名称和参数，Provider 也不会将其识别为合法的原生 tool call，客户端只能退回到自己写正则解析 JSON 的“文本协议”野路子，失去原生调用的所有保障。 这意味着：要做原生工具调用，工具就必须出现在请求的 tools 数组里。而 tools 数组是请求结构的一部分，这代表它永远驻扎在请求的最前端，即我们传递给模型全部 prompt 的一个相对起始位置。 可以设想一下：我们的 Agent 有 200 个工具。为了做渐进式披露，我们固然可以在第一轮只把 5 个高频工具塞进 tools 数组。到第三轮对话时，模型意识到自己需要一个「创建 PDF」的工具——但这个工具不在初始的 5 个里。客户端此时只有两个选择： 选择 A：在下一轮请求中，把「创建 PDF」临时塞进 tools 数组。 tools 数组变了 → 请求最前方的结构变了 → 整个 Prompt Cache 全部报废 → 几万甚至几十万 token 的历史消息必须重新算一遍，不仅巨慢而且巨贵。 选择 B：保缓存，不修改 tools 数组，让模型直接在普通对话里按格式把参数当纯文本输出。 所以，正常情况下渐进式披露工具的核心死结出现了： 原生工具调用的可信度建立在「Provider 在推理前就知道所有工具的完整契约」这一前提上；而渐进式披露的本质是「推理前坚决不让 Provider 知道所有工具」。这两个需求在系统结构上是天然互斥的。 理解了这些约束之后，我们就可以来看业内为了解决「既要原生 tool calling，又要按需加载、不破坏缓存」这个三角难题，到底演化出了哪些思路。 二、业内都是怎么做的？ 1.最正统：Anthropic 的 Tool Search Tool A\ 在 2025 年 11 月发布了Tool Search Tool，大致的原理是：首先，客户端仍然需要把完整的工具契约全部发给 Anthropic；但是我们可以把某些没那么必要的工具标注为 defer_loading，被标注的工具不会进入模型的初始长下文。在这种情况下，agent 的初始上下文中只有 Tool Search 和少量的非延迟加载工具。Astropick 将会在服务端维护隐藏的工具目录。 大概的工具契约是这样的： { "tools": [ { "type": "tool_search_tool_bm25_20251119", "name": "tool_search_tool_bm25" }, { "name": "learning_create_cards", "description": "Create learning cards...", "input_schema": { "...": "完整严格 schema" }, "defer_loading": true }, { "name": "learning_create_plan", "description": "Create a study plan...", "input_schema": { "...": "完整严格 schema" }, "defer_loading": true } ] } 这里我们假设这个 Agent 是一个学习场景的专用 Agent，我们给它注入的工具有一大堆学习相关的工具，比如制卡之类的；那么当模型需要学习制卡能力的时候，agent 就会调用： { "name": "tool_search_tool_bm25", "input": { "query": "create flashcards from study notes" } } Anthropic 在服务端搜索工具目录，返回特殊的 tool_reference： { "type": "tool_reference", "tool_name": "learning_create_cards" } Provider 随后在当前对话位置把这个引用展开成完整工具定义。模型看到真实 schema 后，可以直接产生： { "type": "tool_use", "name": "learning_create_cards", "input": { "...": "严格参数" } } 内置搜索在 Anthropic 服务端运行，搜索结果和目标工具调用甚至可以出现在同一个 assistant response 中。客户端只需要执行最终的具体工具。 顺带一提，搜索有两个变体：tool_search_tool_regex_20251119 让模型写 Python re.search() 正则模式来匹配（上限 200 字符），tool_search_tool_bm25_20251119 则接受自然语言查询（上限 500 字符）。两者都会搜索工具名、描述、参数名和参数描述。 那么问题又来了，这种方式会破坏缓存吗？当然不会。这里的关键不是「发现后不改变工具列表」，而是 Anthropic 对 defer_loading 有一套特殊语义： 原始缓存前缀： [Tool Search] [System Prompt] [历史消息] 发现工具后： [Tool Search] [System Prompt] [历史消息] [tool_reference → 展开的真实工具契约] 我们可以看到，完整工具定义是在发现位置追加进去的，没有回头修改最前面的工具前缀。历史消息里出现过的 tool_reference 会被 API 全程展开，所以模型在后续轮次可以直接复用已发现的工具，不需要重新搜索。 这种实现方法的坏处是——强依赖于 Anthropic 这个 Provider，我们是没办法在自己的程序中离开 A\ 去复刻的，因为 A\ 控制了模型推理前的内部处理： 我们发送的 tools ↓ Anthropic 分成： - 隐藏工具搜索索引 - 模型可见上下文 - Tool Calling 严格语法 ↓ 按需将契约插入对话中间 那么其他 Provider 呢？OpenAI 自家的 Responses API 如今也提供了同构的 tool_search + defer_loading 协议（我们放到本节末尾再讲），但广大「OpenAI 兼容」生态——vLLM、OpenRouter、各家自建兼容层等通常只能二选一：发送 tools → 全部进入模型上下文，或者不发送 tools → Provider 不承认对应的原生调用。它们缺少 defer_loading 和 tool_reference 这种 Provider 级协议。因此我们如果自己动手动态增加工具，就会改变早期前缀并破坏缓存。 于是就有了下面两条客户端自救路线。 2.但是服务端不支持怎么办？一个折中的压缩选项：stub 注册工具 这是我之前实现过的一个方案，核心思路是：既然 tools 数组一个字都不能动，那就在「注册全部工具」的前提下，把每一个工具的契约在未被需要之前压缩到极限。 具体做法可以分为两部分。第一部分是把每个真实工具都注册成一个 stub：保留真实工具名，描述尽量压缩，参数契约则换成一个宽松的万能外壳；第二部分是在工具列表里常驻一个普通的 load_tool_schemas 工具，由我们的客户端实现。Stub 大概长这样： { "name": "learning_create_cards", "description": "从学习笔记创建记忆卡片。调用前必须先调用 load_tool_schemas 获取完整参数契约。", "parameters": { "type": "object", "properties": { "arguments": { "type": "object", "additionalProperties": true } } } } 完整的调用流程是： 模型认为自己需要制卡能力 ↓ 1. 模型调用 load_tool_schemas({ "tools": ["learning_create_cards"] }) 2. 客户端返回完整 JSON Schema（作为普通 tool_result 文本） 3. 模型按照刚拿到的 schema 调用 learning_create_cards 这个 stub 注意第 2 步的完整契约是以消息的形式回来的，追加在对话尾部，不碰任何前缀，因此可以复用之前的全部缓存。我们可以计算一下这种方案的 tokens 消耗：第一节中我们按照 400 token/工具估过 200 个工具的上下文消耗大概为 80k；换成 stub 之后，每个工具大概只剩名字、一句话描述和宽松契约，约 60-80tokens，同样的 200 个工具的上下文消耗大概可以被压缩到 15k 左右，降低了 80%的上下文消耗。 但这个方案并没有让问题消失，stub 的数量依然是 O(N) 的，并没有实现真正的渐进式披露加载；而且每个 stub 都常驻在模型的上下文中，对于模型注意力的消耗也仍然是实打实的。另外它本质上是一种「半原生」方案：Provider 的语法约束还在，但约束的是 stub 那个宽松外壳，真实参数的合法性需要完全靠客户端自己约束。 3.进一步简化：客户端实现 tool search，注册更宽松的工具 当然，我们可以进一步简化。 让我们重新审视一下目前工具调用的两个基本前提： 工具在 Provider 注册； 模型可以正确遵循工具契约。 第一条其实可以被收窄到极限——注册的可以只有一个工具；而第二条，随着当前旗舰模型指令遵循能力的提升，「把契约以文本形式交给模型，它就能照着填参数」已经是一项相当可靠的能力。因此我们完全可以定义一个通用的、全能的 invoke_tool，把所有真实工具都藏到其背后： { "name": "invoke_tool", "description": "执行工具目录中的工具。请先用 search_tools 找到目标工具，再按返回的契约填写 arguments。", "parameters": { "type": "object", "properties": { "tool_name": { "type": "string" }, "arguments": { "type": "object", "additionalProperties": true } }, "required": ["tool_name", "arguments"] } } tools 数组从此恒定，里面只有两个工具：search_tools 和 invoke_tool。一次完整的发现与调用是这样的： 1. 模型 → search_tools({ "query": "create flashcards from study notes" }) 2. 客户端 → 返回目录条目（工具名 + 一行描述，不含完整 schema） 3. 模型 → invoke_tool({ "tool_name": "learning_create_cards", "arguments": { "notes": "...", "mode": "qa" } }) 4. 客户端 → 按 tool_name 取出真实 schema 校验 → 执行 → 回传结果 （校验失败 → 回结构化错误 → agent 修正重试） 对比一下之前 2.2 节的方案： 之前： N 个具体 Stub + load_tool_schemas 现在： 1 个 invoke_tool + search_tools 初始上下文占用从 O(N) 直接变成了 $O(1)$——不管工具目录里躺着 100 个还是 10,000 个工具，模型看到的永远只有初始的两个工具（大概只有几百 tokens 的占用）。工具目录本身可以是一个普通的本地索引、一张数据库表、甚至一个 embedding 检索服务，我们在本地可以实现非常自由的检索。 那么，这个方案的代价又是什么呢？ 代价是我们无法复刻 Anthropic 的一个核心能力：Provider 只知道 invoke_tool 的外层 schema，不知道 learning_create_cards 的内层 schema。也就是说，在 Provider 侧是无法约束校验这个工具调用的参数是否「真的」格式正确的——外层有语法约束，但里面的 arguments 则是一个不设防的黑盒。真实校验必须由我们的客户端完整承担，一旦失败，就返回结构化校验错误让 agent 修正。除此之外还有一些隐性成本：真实参数变成了「JSON 里的 JSON」，转义和嵌套多了一层；而且这条路线对模型本身的指令遵循能力有门槛，太弱的模型会在第 3 步频繁出错。 公平起见，补偿也是有的：因为所有具体调用都收敛到了同一个入口，校验、授权、审计、限流这些横切关注点反而只需要在 Gateway 一处实现——这在多 User/Agent 场景里简直是意外之喜。 因此，没有 Provider 原生配合时，以下三个目标无法同时满足： 初始上下文不包含 N 个具体工具或 Stub； 工具列表始终稳定，不破坏早期 Prompt Cache； 每个具体工具仍以独立原生工具和严格 schema 被 Provider 调用、约束。 三者只能取二： 选择 结果 缓存稳定 + 具体工具原生调用 必须常驻 N 个真实工具或 Stub 初始无 N 个工具 + 具体工具原生调用 发现后动态修改 tools，破坏早期缓存 缓存稳定 + 初始无 N 个工具 只能常驻一个通用原生调用外壳，由客户端还原具体工具 4.Moonshot 的按需加载工具机制 Moonshot 在 Kimi K3 的 API 里提供了一个叫「动态加载工具」的机制。月暗的思路是：工具声明不一定要待在请求开头的 tools 字段里，它可以是一条消息。 具体做法是：在 messages 中插入一条 role 为 system、携带 tools 字段的消息。声明格式与请求顶层 tools 完全一致，且必须提供工具的完整信息（name、description、parameters）： { "messages": [ { "role": "system", "content": "You are Kimi, an AI assistant..." }, { "role": "user", "content": "Calculate fuel consumption." }, { "role": "system", "tools": [ { "type": "function", "function": { "name": "Calculator", "description": "计算器，只支持单个算术表达式的求值", "parameters": { "type": "object", "properties": { "expr": { "type": "string", "description": "算术表达式，支持四则运算、指数运算、对数函数、三角函数，使用 javascript 语法" } }, "required": ["expr"] } } } ] } ] } 这个设计有几个关键的语义： 携带 tools 的 system 消息与普通消息地位相同：它出现在 messages 的哪个位置，工具就从哪个位置开始对模型可见； 动态加载的工具与顶层 tools 声明的全局工具并存，模型可以同时看到两类； 注入的声明必须是完整定义，不能只传个工具名； 这条 system 消息不能再带 content 字段，否则请求会以 400 报错。 那缓存呢？官方给的原则有四条： 操作 对前缀缓存的影响 在 messages 末尾追加工具声明 不影响已有前缀缓存 后续请求原样保留已注入的工具声明 前缀保持稳定，有利于持续命中缓存 删除、修改对话中间的消息，或在中间插入新声明 变更位置之后的缓存可能无法命中 在顶层 tools 字段声明全局工具 不影响缓存命中 换句话说：追加，不要插入；注入了就别删。 工具声明被当成普通对话内容的一部分往后追加，前缀纹丝不动，就和 Skills 的加载路径一模一样。基于这个思路，官方顺手给出了 tool search 的参考实现（API 层面并没有内置的搜索接口）： 顶层 tools 里只声明一个自己实现的 search_tools； 在 system prompt 里告诉模型有哪些可搜索的工具目录/领域关键词； 模型需要工具时先调 search_tools，后端按关键词返回匹配的工具名和简介； 应用把命中工具的完整声明通过一条带 tools 的 system 消息追加到末尾； 模型在后续生成中直接原生调用这些新加载的工具。 我们可以将Kimi 的按需加载工具方案可以视为一种 Provider 原生支持的、协议设计更轻量、使用更自由的选择。它在协议层面上不需要任何的额外概念，不需要提供 defer_loading、tool_reference 等新字段，声明格式与顶层 tools 完全一致；在位置上，工具在 messages 的哪个位置注入，就从哪个位置开始对模型可见，直觉且可控，且天然的对缓存友好；在自由度更高的基础上还依然享有 Provider 侧的原生约束，不会像 invoke_tool 那样把参数黑盒化，十分之优雅，令人眼馋。 三、总结：渐进式披露与 tokens 经济学 在 Tokens 经济学中，我们会更加关注 Agent 运行过程中真正的高相关信息能够占据多少注意力，以及已经支付过计算成本的上下文能否被持续复用。 因此，一个好的工具系统并不是简单地让模型“知道尽可能多的工具”，我们的目标应当是让模型在当前决策中，只看到足以支持这一步行动的信息。将数百个工具的完整 Schema 一次性注入上下文，固然最大限度地保留了能力边界，却也会让大量与当前任务无关的定义长期占据注意力、Token 预算和首字延迟。工具越多，这种暴力注册的边际收益越低，边际成本越高。 但工具又不同于普通知识。Skills 可以作为文本自然地追加在消息末尾，而原生 Tool Calling 通常要求 Provider 在推理前获得完整工具契约。于是，严格原生调用、稳定的 Prompt Cache 和真正的按需加载，构成了一个无法仅靠普通客户端同时满足的三角约束。缺少 Provider 配合时，我们只能在三个目标之间进行取舍： 保留每个工具的独立原生调用，就必须让真实工具或 Stub 常驻上下文； 动态修改 tools 数组，可以获得严格 Schema，却会破坏早期缓存； 保持缓存稳定并将初始占用压缩到常数级，就只能通过 invoke_tool 之类的统一外壳，把真实校验下放给客户端。 至于如何抉择，那就要看各位 Agent 工程师们自己的权衡和 taste 了。 相关文档与延伸阅读 Anthropic：Tool Search Tool defer_loading、BM25/Regex 搜索以及工具发现后的调用流程。 OpenAI：Tool Search defer_loading 按需加载 Function、Namespace 和 MCP 工具。 Moonshot AI：动态加载工具 messages 中的 System Message，在对话过程中追加完整工具声明。 Anthropic：Tool Reference defer_loading、tool_reference、Strict Tool Use 等机制。 Anthropic：Tool Use with Prompt Caching 延伸阅读：上下文稀缺、RAG、Memory 与 Skills 82 个帖子 - 51 位参与者 阅读完整话题

19. 19
    【CHY公益站】本公益站没有闭站计划

    大概是昨天晚上 10 点到 11 点左右发生的事 幸好年轻人精力旺盛，不然我也要被折腾的关站了 64 个帖子 - 57 位参与者 阅读完整话题

20. 20
    那个最帅的男人的星辰站，出来解释下呗？

    muyuan佬已经给了处理了。说是之后会持续保持监控juice值。希望能保持下去吧。 为了避免大家讨论到后面越来越偏题，我这里强调几个点。 1.中转站的利润，这个帖子说的很清楚了，各种倍率有各种不同的渠道。 【无广告】中转站运营快一个月了，中转运营现状与成本分析 开发调优 中转运营现状与成本分析 继此前几篇中转运营科普帖 AI 中转站大起底：什么是中转站，倍率是什么（科普贴） https://linux.do/t/topic/2563086 https://linux.do/t/topic/2548075 之后，今天继续聊聊之前未说明的渠道和具体成本。 我们做中转服务约20天，目前正经历GPT市场“号荒”的第三天。 一、市面GPT倍率与号池来源 当… 2.大家讨论的时候可能忽略了sol掺luna的价格差距。 另外，我根本不会想用luna。因为luna在 给 我 的 项 目 埋 坑！ 3.实际上目前关于降智或者掺水的讨论已经推进到最后一点了。 4.保持理智，不要冲动。 本来今天下午发现gpt5.6-sol解决一个问题搞了2个小时没搞好，还以为是gpt官方降智+上下文太小导致绕了半天。 晚上刷ld站看到有个看起来还可以的软件，顺手测试了一下。 基于cot和juice的gpt5.6sol检测方式，从此告别掺假！[附实战案例] 平常sol-high都是40855。而星辰的sol的juice测试，竟然很大比例出现48（我除了软件，自己也测了好几次，80%都是48）平常几乎都是用sol-xhigh，切了api随手测一下就继续了，而sol和luna的xhigh全是128，导致以前完全没发现。 我同样也对其他的中转站进行了测试，并且也对我的官方订阅进行了测试。基本上不是40就是40855 这合理吗？你现在在做中转站。虽然是codex测试，倍率低，但是大家的k12或者bug-team渠道倍率都差不多啊，0.04-0.07。你觉得价格低了你就提升倍率呗，为什么要往sol里掺luna呢？ 我今天下午的项目被搞得一团糟，推进极慢，问题非常多。一开始我还以为是gpt降智了，重新调整了好久，修了好久的代码。晚上这一测确实是有点生气了。 希望站点的管理员赶紧处理一下问题。 附上测试日志。 君1.7z (6.0 KB) 374 个帖子 - 183 位参与者 阅读完整话题

21. 21
    自闭了，分手八个月了还是走不出来

    分手八个月了自己还是常常内耗，内疚，会想起之前做的事情，明明去年还很恩爱的在一起，今年就物是人非。在想当时要是做的好些会不会就不会分手了。 另一个感慨是就在结婚前，不要陪对方成长，多提高自己，陪对方成长的代价很痛。 PS：为什么佬友有很多人说到女生 32 岁，这个问题呢？有什么特殊含义吗？ 前景提要 楼主在河南省会的小国企上班，郑州本地人，一个月5-7K。然后这些年支持前女友考教师编，全省巡考，自己出钱出力，然后考上了周口的市区小学老师。考上前要求彩礼6.6，没房子有老家房子也行。考上后，彩礼20W，在周口买房，其他乱七八糟的。自己一直在攒钱达标，最后还是分手。 楼主29，女方32岁，7年了，可能女方父母在女方上岸后，一直想让对方找个体制内或者公务员吧，自己的确不属于体制内，而且家里是农村的，但是女方父母也是农村还有个28岁的弟弟无业，我也不知道是不是的确是考上编制了就是人上人了，阶级就不一样了，我很后悔支持对方考编，又出钱又出人。 还有一个事情，想问佬友，当时需要本人现场报名，我使了点手段，因为她两场考试冲突，帮她报上了（我查了一下，这种作假的被举报会被取消编制的即便被录用了）。现在我姐姐看我很难受，非要去举报，说过不下去都别好过，我很不知道该不该这样做。 最后就是一直走不出来，也不知道该如何释怀。 感觉自己七年的付出，说实在的都是我单方面付出，对方7年就给我买了一个眼罩和防晒衣，就这样我觉得有人陪我就很好，我很珍惜。【我感觉不是我单方面付出，可能我也没伤得这么深吧】 感谢 各位佬友 我自己努力往前走，看着大家也学到了不少。知道了男女关注点的不同，谢谢佬友们。至于举报，我再和我家人沟通一下吧。 还是希望佬友们以我为鉴，多提高自己，少帮助他人，可能干扰他人因果会有反噬吧。在婚姻中，男女看重的不同吗？观上个帖子佬友常说年纪问题 - #26，来自 zch 这个我以后多看看恋爱帖子，多学习。希望佬友们生活都幸福美满，谢谢。 420 个帖子 - 312 位参与者 阅读完整话题

22. 22
    【公益推广】方舟公益站

    本帖使用社区公益推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的项目是免费使用的，无收费（变相收费、赞助）部分： 是 我的帖子已经打上 公益推广 标签： 是 我的项目属于个人项目，与公司或商业机构无关： 是 我的项目不存在QQ、TG等群组引流： 是 我的项目不存在非运营必要的网站引流： 是 我的项目不存在为他人推广、AFF： 是 我的项目无关联的商业项目： 是 我的站点存在登录，并已接入 LINUX DO Connect： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 方舟公益站主站：https://new.bxacc.xyz/ https://us-new.bxacc.xyz/ https://auto-new.bxacc.xyz/ 注册提示429是因为我这小破服务器人太多炸了，稍等片刻就好了。 api调用推荐使用负载均衡节点，另外两个节点做备用，负载均衡无法使用（或速度过慢）时请使用其他节点 目前模型主要是deepseek-v4-flash，其他模型都不太稳。 站内联系方式已删除整改，请管理员重新审核谢谢！ 模型有GPT5.6 克劳德等等，模型如图： 98 个帖子 - 77 位参与者 阅读完整话题

23. 23
    【持续更新】GiffGaff 封号后反击全流程

    持续更新，因为我还没走完所有流程，所有有些流程暂时没有截图和说明，但是也希望能帮到大家。 giffgaff 最近大规模封号，在封号初期（大概头几个小时），有佬友通过申诉退款成功，但是后面估计申请退款的人太多里，所以客服团队开始全面模板化回复，并且拒绝退款： 第一步：通过官网联系客服申请退款 地址：Ask an agent 进入这个地址，会首先要你登录，这里不用担心，被封号了其实还是可以继续登录的，所以正常登录就行，但是有可能在登录时会出现请求验证码的窗口闪回的情况，多登录几次就可以登录了，验证码选择使用邮箱收取，因为手机已经收不到验证码了。 登录后会进入帮助请求界面： 然后依次选择： Plans, Credit and Payment Details（套餐、余额和支付详情） 你自己被封号的号码 Credit balance or plan allowance（余额或套餐余量） Credit balance（余额） Yes, unrelated to plans（是的，与套餐无关） No No 填写你的退款诉求，这里我不贴具体内容，大家可以用下面的提示词让 AI 写一封就行，这样也能保证不会出现大家模板化申诉的情况 提交 【背景信息设定】 扮演一位的真实英国电信运营商（giffgaff）的用户。 该运营商近期以“违反长期海外漫游公平使用政策”为由，在没有任何提前通知的情况下，直接对我进行永久封号。目前账号里还有一笔没来得及消费的余额。 【核心诉求】 我不指望解封号码，因为几乎不可能。我只需要他们把我账户里的余额原路退回就行。我需要为账号提交人工客服工单，请你帮我写 5 个完全不同版本的纯英文退款诉求。 【要求】 1. 不讨论“漫游条款”、“为什么不提前通知”、“你凭什么封我”等对错问题。 2. 不提恢复服务、找回号码、解封账户等请求。 3. 不要编造任何关于“我的信用卡挂失了/换新卡了”的故事，统一只说“退回到我原来的支付渠道”，因为当地有严格的反洗钱政策，一旦提及更换退回渠道，他们会以反洗钱法规为由，拒绝退款。 4. 绝不接受他们的封号理由。 5. 态度强硬。 【语言格式】 1. 输出内容必须使用地道的英式英语，同时附带中文翻译，以便于我校对。 2. 不需要写信件开头的，因为这是在网页文本框里直接提交的留言，直接从 "Hi"、"Hello" 或者直接陈述诉求开始即可。 （点击了解更多详细信息） 第二步：Trustpilot 差评 提交完以后他们不会马上回复你，这个时候打开 Trustpilot 评价链接，顺手给他们来一波差评逗逗这帮英国佬。大家不要有心理压力，因为我们本身就是合法合情合理的，我们又不是没付钱。花了钱还不给我们用，这什么道理，大家尽管冲。 https://www.trustpilot.com/review/giffgaff.com 第三步：索要“最终答复信”（Deadlock Letter） 第一步提交以后，大概等待 1~2 天时间，几乎 100% 会回复你一封模板化回复： （点击了解更多详细信息） 这时候在申诉的工单界面，向客服所要最终答复信，这份最终答复信是用于向 Ombudsman 提起申诉使用的，没有这封信你没办法提起申诉，所以务必索要。 如果你找不到你的工单了，没关系我都给你考虑到了，你可以通过这个链接进入工单列表页：Messages from agents Ombudsman 是英国消费者权益保护的独立第三方机构。只要在 Ombudsman 上申诉立案，无论最终裁决结果如何，giffgaff 都必须向该机构缴纳一笔数百英镑的案件处理费。 他们想没收我们 10 英镑，我们一定要让他们吐出远大于 10 英镑的钱才行，给他们长长记性。 可用于生成回复的提示词： 【背景信息设定】 扮演一位真实的英国电信运营商（giffgaff）的用户。 我之前因为被无预警永久封号，向客服提交了退还账户余额的申请。现在客服回复了我，以“违反长期海外漫游公平使用政策”等条款为由，拒绝了我的退款请求。 【核心诉求】 我的诉求升级了。我不接受他们拒绝退款的处理结果。我需要回复他们的工单，索要“死局信/最终答复信（Deadlock Letter）”，以便我可以将此退款纠纷提交给英国独立的“通信申诉专员（Communications Ombudsman）”进行仲裁。请帮我写 5 个完全不同版本的纯英文回复。 【要求】 1. 明确表达“我不接受你们拒绝退款的决定”。 2. 仅提及拒绝退款事项，不提及封禁原因，避免他们以此为由开始扯皮。 3. 明确提及 Deadlock Letter 和 Communications Ombudsman。 4. 不使用“仲裁（arbitration）”等容易产生误解或带有强烈法律判断的表达。 5. 态度强硬。 【语言格式】 1. 输出内容必须使用地道的英式英语，同时附带中文翻译，以便于我校对。 2. 不需要写信件开头的，因为这是在网页文本框里直接提交的留言，直接从 "Hi"、"Hello" 或者直接陈述诉求开始即可。 （点击了解更多详细信息） 第四步：向 Ombudsman 提起申诉 收到 gg 发来的 Deadlock Letter 后，首先把工单的网页打印一封为 PDF 存档，后面要用。打印方式是在工单网页，点击鼠标右键-选择打印，打印参数建议这样选择（主要参数是 A4、页眉页脚、背景）： （点击了解更多详细信息） 网页申诉渠道因为不支持非欧盟地区的国家，所以最好尝试用邮件形式向 Ombudsman 投诉（但是这里有点悲观，我估计 Ombudsman 是不受理的，不然网页端也不会做地区限制） 投诉方式是使用注册 giffgaff 的邮箱向 enquiry@commsombudsman.org 发送一封邮件，标题、内容可以尝试使用下列 prompt 生成： 你是一名熟悉英国消费者合同法、英国通信行业监管规则、giffgaff Terms and Conditions、giffgaff Fair Usage Policy，以及 Communications Ombudsman 投诉标准的专业投诉文书编辑。 请直接起草一份可以提交给 Communications Ombudsman 的正式投诉陈述。 不要向我提问，不要要求我补充日期、手机号码、账户号码、所在国家、余额金额、充值金额、付款卡信息或其他个人资料。不要使用任何方括号占位符。请根据下面已经确定的共同事实直接完成文书。 【已经确定的共同事实】 投诉人是 giffgaff 的个人移动通信服务用户。 giffgaff 以长期在英国境外使用服务、违反 Fair Usage Policy，以及其服务主要供英国境内使用为理由，永久断开移动服务并关闭账户。 账户关闭时，账户中仍然存在未使用的已购通信余额。由于 giffgaff 永久关闭了账户和服务，投诉人已经无法继续使用该余额。 投诉人要求 giffgaff 将未使用的已购余额退回原始支付方式。 giffgaff 拒绝退款，并援引其 Terms and Conditions 中关于账户余额通常不予退款的条款，同时再次强调投诉人违反了 Fair Usage Policy。 giffgaff 已经提供 Final Response，并告知投诉人可以将纠纷提交给 Communications Ombudsman。 投诉人不要求恢复账户、手机号码或移动服务，也不要求重新审查封号决定。投诉人的唯一诉求是退还账户关闭时尚未使用的已购余额。 【核心任务】 起草一份坚定、专业、逻辑严密的正式投诉陈述，要求 Communications Ombudsman 独立审查： 1. giffgaff 是否可以仅凭其内部 Terms and Conditions，在永久终止服务后保留消费者尚未使用的已购余额。 2. giffgaff 引用的不退款条款及其在本案中的适用方式，是否符合英国《Consumer Rights Act 2015》关于公平性、透明度和消费者合同解释的要求。 3. giffgaff 是否证明投诉人的行为给其造成了与被保留余额相对应的直接经济损失。 4. 在 giffgaff 已经通过永久关闭账户处理其所声称的 Fair Usage Policy 违规后，继续保留消费者的未使用已购余额，是否构成额外且不成比例的经济后果。 5. giffgaff 是否能够证明，保留全部未使用已购余额是维护其合法商业利益所必要且相称的措施。 【投诉范围】 投诉正文应明确说明： 1. 投诉人不要求 Communications Ombudsman 判断 giffgaff 是否有权执行 Fair Usage Policy。 2. 投诉人不要求恢复账户、号码、套餐或服务。 3. 投诉人不要求重新审查账户关闭决定。 4. 投诉人不准备通过 PAC 携号转网，giffgaff 提供的 PAC 信息与退款纠纷无关。 5. 投诉的唯一问题是：giffgaff 在主动终止服务并使余额无法继续使用后，是否有权拒绝退还消费者尚未使用的已购余额。 6. 最终要求只能是将未使用的已购余额退回原始支付方式。 7. 不要求道歉、账户恢复、号码恢复、服务恢复、重新审查、额外赔偿、精神损失补偿或其他补救。 【必须核查的 giffgaff 条款】 如果具备联网能力，请首先查阅 giffgaff 官方网站上在投诉发生时期适用的 Terms and Conditions 与 Fair Usage Policy。 只使用官方 giffgaff 页面，不引用论坛、社交媒体、新闻评论或第三方博客。 重点核查： 1. giffgaff 关于账户 credit 或 airtime credit 退款的条款。 2. giffgaff 所引用的不退款条款是否包含类似以下限制性表述： “in the absence of any legal or regulatory entitlement” 3. 如果条款承认法律或监管权利可以优先于内部不退款政策，应指出 giffgaff 不能仅通过引用该条款，就回避对英国消费者法的审查。 4. giffgaff 是否区分： - 消费者实际付款购买的余额； - promotional credit； - goodwill credit； - 其他没有现金价值的赠送余额。 5. 不要自行假定赠送余额必然可以退款。 6. 投诉的主要法律保护对象应是消费者使用个人资金实际购买、但因账户关闭而无法继续使用的余额。 7. 如果无法确定准确的历史条款版本，必须坦率说明，并使用能够找到的最接近事发时期的官方版本。不得假装已经核实不存在的历史版本。 【必须应用的现行法律】 以英国《Consumer Rights Act 2015》Part 2 为主要法律依据。 一、Section 62 说明消费者合同中的不公平条款对消费者没有约束力。 要求 Communications Ombudsman 审查相关不退款条款及其在本案中的适用方式，是否违反诚信要求，造成双方权利义务的重大失衡，并损害消费者利益。 分析重点包括： - giffgaff 单方面终止服务后，消费者完全失去使用已购余额的能力； - giffgaff 同时保留该余额，却没有继续提供对应服务； - 消费者已经承担永久失去服务的后果； - giffgaff 是否还可以自动获得消费者剩余的已购资金； - 这种结果是否超出执行 Fair Usage Policy 所合理需要的范围。 二、Section 68 说明消费者合同中的书面条款和通知必须透明，以清楚、易懂的语言表达。 要求 Ombudsman 审查以下内容是否被清楚且显著地告知消费者： - 账户因 Fair Usage Policy 被永久关闭时，未使用的已购余额是否会全部丧失； - 不退款后果是否在消费者购买充值时被明确提示； - 不退款条款是否清楚区分消费者主动停止使用和 giffgaff 主动终止服务； - 条款是否清楚区分已购余额与促销或赠送余额； - 消费者是否能够在购买充值时合理预见，账户被永久关闭后已购余额也会被全部保留。 不得仅因为相关内容出现在较长的 Terms and Conditions 中，就默认其满足透明度要求。 三、Section 69 说明消费者合同条款存在多种合理解释时，应采用对消费者最有利的解释。 如果 giffgaff 的不退款条款没有明确说明，在 giffgaff 主动永久终止服务的情况下，消费者实际付款购买的未使用余额也会被保留，应要求 Ombudsman 采用对消费者更有利的合理解释。 该解释应当是： giffgaff 可以终止服务，但不能仅凭模糊或宽泛的不退款条款，自动保留消费者为尚未获得的通信服务实际支付的款项。 四、Schedule 2, Part 1, paragraph 7 指出《Consumer Rights Act 2015》Schedule 2, Part 1, paragraph 7 将以下类型的条款列为可能不公平： 允许经营者解除合同，同时保留消费者为经营者尚未提供的服务所支付的款项。 不得声称该规定会自动使 giffgaff 的条款违法或自动保证退款。 应要求 Ombudsman 审查： - 消费者是否已经为未来通信服务支付款项； - giffgaff 是否主动终止了提供这些服务的合同关系； - 未使用余额是否对应尚未提供的服务； - giffgaff 是否有充分理由保留全部已购余额； - giffgaff 是否因保留余额而获得与其实际损失不相称的利益。 【比例原则和惩罚性后果】 可以谨慎引用英国合同法关于违约后果不得与经营者的正当利益完全不成比例的原则。 不要直接声称 giffgaff 的条款已经构成非法 penalty clause。 应使用条件式表述： 如果 giffgaff 将不退款条款作为违反 Fair Usage Policy 后的经济后果使用，Communications Ombudsman 应审查该后果是否与 giffgaff 执行其政策所具有的合法利益完全不成比例。 应指出： - 永久关闭账户已经处理了 giffgaff 所声称的违规； - 保留消费者未使用的已购余额属于另一项独立经济后果； - giffgaff 没有说明投诉人的行为造成了多少直接经济损失； - giffgaff 没有解释为什么必须保留消费者的全部已购余额； - giffgaff 没有证明该金额与其实际损失或正当商业利益相称。 【要求 giffgaff 提供的证据】 投诉陈述应要求 giffgaff 提供： 1. 账户关闭时实际生效的完整 Terms and Conditions 和 Fair Usage Policy。 2. 账户关闭时未使用余额的完整账户流水。 3. 能够区分已购余额、促销余额和 goodwill credit 的逐项记录。 4. 每次余额增加、扣除和使用的日期、金额与类型。 5. 账户关闭时实际剩余的已购余额金额。 6. giffgaff 认为其有权保留已购余额的准确合同和法律依据。 7. giffgaff 因投诉人的行为遭受的任何直接经济损失的计算。 8. giffgaff 认为保留全部已购余额属于必要且相称措施的理由。 【最终救济要求】 最终请求必须严格限定为： 1. 要求 giffgaff 将账户关闭时尚未使用的已购余额退回原始支付方式。 2. 如果账户中同时包含促销余额或 goodwill credit，可以要求 Ombudsman 先确认其中由消费者实际付款购买的部分，并至少退还全部未使用的已购余额。 3. 如果 giffgaff 对剩余已购余额金额提出异议，要求其提供完整、逐项列明的账户流水，由 Ombudsman 根据该流水确定退款金额。 4. 不要求恢复账户。 5. 不要求恢复号码。 6. 不要求恢复移动服务。 7. 不要求重新审查封号决定。 8. 不要求使用 PAC 携号转网。 9. 不要求道歉。 10. 不要求额外补偿或其他形式的救济。 退款必须退回消费者购买余额时使用的原始支付方式，不得建议退款到其他银行卡、其他账户、支票、账户 credit 或替代支付渠道。 【不得使用的说法】 不要写： - giffgaff has definitely broken the law - the clause is automatically unlawful - the terms are obviously illegal - the law guarantees a refund - giffgaff stole the money - giffgaff confiscated the balance - this is fraud - this is a scam - I demand reinstatement - I want my number restored - I seek compensation for distress 不要使用 theft、fraud、scam、confiscation 等煽动性词汇。 不要声称投诉影响了数万人，除非存在可以核验的官方数据。 不要讨论 Ombudsman 案件费、胜诉率或 giffgaff 是否会为了节省处理费用而和解。 不要要求恢复任何服务。 【语言和输出要求】 1. 先输出一份可直接提交给 Communications Ombudsman 的正式英文投诉陈述。 2. 使用自然、地道、正式的英式英语。 3. 使用第一人称，以真实消费者的口吻书写。 4. 语气坚定、有压力，但保持克制和专业。 5. 不写信件地址、主题行、Dear Sir or Madam 或落款。 6. 不使用姓名、日期、手机号码、账户号码、所在国家、具体余额金额或其他需要用户修改的内容。 7. 不使用方括号占位符。 8. 不向用户提出问题。 9. 不输出分析过程。 10. 英文正文控制在 700 至 1,000 个英文单词以内。 11. 英文正文后提供完整、准确的中文翻译。 12. 最后提供一份简短的证据清单，说明提交退款投诉时应上传哪些通用材料。 13. 最终只输出： - 英文投诉陈述 - 中文翻译 - 证据清单 内容你差不多自己改完以后，需要添加一些附件，必须添加的是 giffgaff 工单的 PDF 存档，也就是上面让你打印的那个，然后尽可能也把银行卡支付截图、giffgaff 流水短信截图、giffgaff 充值明细截图（可通过 giffgaff - orders and payments 里的 Order and payment history 获取）都发送过去。 目前我也是刚发送邮件，后面有消息了再更新。 第五步：向支付发行卡银行提交争议处理 这个我还没做，明天我试一下，今天太忙了没空弄。但是看了各种帖子，貌似已经没用了，引用佬的回复： 在另一个话题中 10 点更新：招行 visa 的客服打电话说了，刚接到上级通知，这是个大规模群体事件，gg 卡那边说不服务国内用户，所以他们说管不了，无法追回～ 更新：刚刚正好有空，给工商打了个电话，客服反馈因为已经超过 60 天了，所以没办法直接做拒付申请。现在给我提交了一个工单，让我等他们反馈，后续有进展了我继续更新。 更新：周末时候，工商的人工表单填了，然后找我确认要不要继续申诉，他们说成功概率不大，因为支付时间远超 60 天，继续申诉的话无论结果如何，都需要支付大约 45 元的调单费，这个费用我没太听清楚是什么，好像是国际结算中心那边需要的费用。现在暂时是没继续发起信用卡争议了，招商那边的结论大概率就是工商的结论。现在就等 Ombudsman 那边的回复邮件了，说是 10 个工作日给结果 其他 后面继续整理其他渠道、方法，反正不能让他们好过 129 个帖子 - 98 位参与者 阅读完整话题

24. 24
    TrueSOTA API中转站公测，注册送 20 刀

    各位佬友好，我们是个创业团队，平时也重度使用 Codex、Claude Code 这些 Agent。 TrueSOTA 最早是搭给团队内部用的。此前买过不少 API，也见过中转站里线路不稳、模型质量不一致、出了问题找不到人的情况。折腾久了，我们干脆自己维护了一套，现在开放出来给大家试试。 官网：https://true-sota.com/(需 Linux.do 登录才能领额度） 新站靠吹牛证明不了什么，先把目前能做的说清楚。 客服问题有跟踪 遇到故障或调用问题，可以直接联系 Discord 客服，处理进度都公开可见；能解决的尽快处理，涉及上游的也会持续跟进，直到有明确结果。 Discord： TrueSOTA 官方账号池，稳定优先 目前采用 ChatGPT 官方账号池。价格会贵一点，因为我们不碰高风险账号，也不追求很大的账号量，先把现有线路维护稳定。 价格和退款规则简单 ChatGPT 统一 1 x 倍率，订阅折算下来约等于 0.5x-0.7x 倍率。充值和订阅都支持按使用比例退款，用掉多少算多少，剩余部分可以退。 支持 Linux DO 一键登录 登录后创建 API Key 即可使用。 注册直接送 20 刀 不用抽奖，也不用先回帖，登录 Linux.do 注册后额度直接到账:https://true-sota.com/ 我们已经把稳定和服务放在前面，但中转站还应该做好什么，自己猜总归不准。领到额度的佬友，麻烦回来吱一声，顺手回答两个问题： 1. 目前主要使用什么 Agent 工具？ Codex / Claude Code / Cursor / Cline / OpenCode / OpenClaw / 其他 2. 除了稳定和服务，希望网站尽快增加或改进什么？ 具体模型 / 价格套餐 / 用量统计 / 团队管理 / 状态页 / 其他 缺什么、哪里不好用，都可以直接提。 赠送额度用完后，可以先从 6.9 元套餐开始，小额试用，合适再续，不建议一次多充。 248 个帖子 - 201 位参与者 阅读完整话题

25. 25
    都在聊公益站，我聊聊liWAN公益站

    “你搞这个赚钱么？” 我并非科班出身，AI也只是兴趣，加入L站是慢慢了解、使用AI后才听说的论坛，加入L站后，我最爱逛的是“人工智能”、“原创”两个标签板块。 大家分享着自己的开源项目、交流自己的技术经验，虽然我看起来很吃力，也是回味无穷。 “人工智能”标签板块下时不时会看到一些公益站的帖子，我也曾慢慢攒ldc兑换了第一个公益站的邀请码，所以我非常明白ldc的来之不易。 我非常感谢我曾使用过的公益站，包括不限于冰、君の公益、黑与白、薄荷、小鸡毛等，是他们让我在使用AI时有了试错的机会。 好像有些跑题…因为我在跟我老婆逛街，她在试衣服，我无聊编的。 说回我的公益站，它是在6月18日开的站，开站后正如一些佬的“公益站生命周期循环”总结一样： 大家都搞公益站我也搞一个。 哈哈哈！抽象又现实。 开头也说了，我并非科班出手，面对太多人注册和小鸡顶不住，我是真的毫无招架之力，不过好在有一些佬的公益站，问问gpt、问问claude，勉勉强强维护下去了… 开LDC邀请码后，我是满满的罪恶感，因此有了“活力格”的诞生，它的初衷非常简单，我害怕大家因为使用LDC购买邀请码后当个囤囤鼠，一点都不去用token，我是真的害怕到时候上游拉闸了各位佬用不了。 慢慢的维护，公益站存活快半个多月，而半个多月我拒掉了很多商单，老婆说我总是搞这个还不赚钱，天天熬夜，干脆别搞了，我想也是，就发了个帖子说准备跑路。 跑路还没2天，Hermes在微信给我推了个渠道（以前写的定时任务每天去自己采集渠道），liwan 原地复活了。剧透 从开站到现在也马上快两个月，时间过得好快啊，商单也在慢慢恢复接单，抽空的时候维护下渠道和公益站，嗯！蛮好！ 现在隔三差五的出现LDC与公益站有关的讨论帖子，几乎都是因为所谓的“高额LDC”。 我想说，大家都是成年人，有最基本的判断能力，公益站能不能用，站内的搜索、公益站的模型广场，都能够体现，再不济找管理员反馈，论坛是包容的，说明你的原因，就像当初加入L站要写申请一样，我想，管理员肯定会给你一个交代。 L站不只是有公益站和羊毛，它还有其他的内容，我讨厌现在的公益站氛围，我更讨厌那些“做臭”公益站的** 我自己的公益站已经停止了注册，就让它变成最初的样子吧，如果哪天我真的维护不下去了，只能提前说抱歉，我会退你们ldc的。 在另一个话题中 8 月 4 日 点 22 点更帖： 每隔几天就有 ldc 和公益站之间的小事讨论来讨论去 peace&love 55 个帖子 - 50 位参与者 阅读完整话题

26. 26
    佬们，想换工作了，怎么学习 AI Agent 开发呀

    请教一下各位佬，现在想转行做 agent 开发，有没有推荐的学习路径呀 培训机构 实战书籍 学开源框架源码 或者其他 佬们有没有经验可以分享一下呀，目前是前端转全栈了 我把目前收集到的和佬们推荐的列一下，方便各位佬一起学习： 免费在线阅读： AI Agent 开发项目实战 – 李文周的个人站点 （@it_wangxiaobai 佬推荐） AI 智能体实战速成指南：从零到企业级落地 | ai-agents-from-zero （@tensor 佬推荐） 深入理解 AI Agent - AI Agents in Depth （@miracle_c 佬推荐） Hello-Agents AI Agent 架构：从单体到企业级多智能体 | Wayland Zhang AI Agent Guide - 通识教程(@bin10 佬推荐) AI 工程从零开始(@bin10 佬推荐) Agent 工程哲学(@bin10 佬推荐) Pi Agent Book(@bin10 佬推荐) pi agent blog(@bin10 佬推荐) Learn Claude Code(@bin10 佬推荐) Learn Claude Code(@bin10 佬推荐) Learn Agent the Hard Way(@leihb 佬亲自出品) 收费课程： Agent 设计模式之美 （@dxmy 佬推荐） 54 个帖子 - 37 位参与者 阅读完整话题

27. 27
    突然感觉结婚真没意思

    大家随便看看，我就吐槽一下，文笔不行也不会排版 结婚4年了，每天和老婆不是上班路上吵就是下班路上吵，总是因为一些鸡毛蒜皮的事情 也可能是我太直男了吧，在我看来老婆向你说一个事情是让你解决的，特别是一些工作上的事情，我总是想着法给他解决，但是她从来不是这么认为，只是把我当成个负面情绪垃圾桶，只想让我接受她的负面情绪，让我一起吐槽，并不是找我要解决方案，我给他解决办法他总是不按照我说的去做，还一直反驳我，最终就升级成吵架了 举个例子吧，比如她和我说她领导总是不看重他，只给她派杂活，有好的项目也都是给别人的，或者是让别人分一杯羹，她也想提升自己的能力。我就给他讲让他主动一点接任务或者就和领导说一起去出差见客户（她沟通能力不行）学习学习，但她想要的是让我来一起吐槽她领导，总是说她要的不是给她出主意，只是为了和我吐槽一下。 还有今天早上上班路上，因为明天早上要带孩子去医院看病，她明天要加班，问我什么时候能看完，她要申请加班，我就说你反正只能申请7.5小时随便申请早上路过的时候打个卡你给他干到7.5小时就行了，以前就是这样。她说现在管的严了，不能这么搞，那我就说了8点半看上 验个血 差不多9点多点能结束，她又反驳前面还有20多个人哪那么快能看上起码2分钟一个人。然后又问我应该申请什么时候加班，我说你早上去看病路过公司先打个卡，她说可以提前打卡，那我就说 随便申请几点，申请到7.5小时就可以了，她又说那我白给公司加班什么什么的，搞不懂她逻辑。就一路上一直追问我要申请几点，我被问烦了就说你爱几点几点，时间干够不就行了，她一直担心现在公司抓的严什么的，别人有本事这么搞，我不行（她做售前的，手里有的是公司把柄），然后就吵了一路。我就很不爽她这么看不起自己，然后又那么看不起我给她的办法，总觉得我给出的解决方法不行。 总感觉我们不在一个频道上，她逻辑能力不太好，反应慢，还总是自我感觉良好。现在让我回想起来怎么都是缺点，不知道是不是我心变了还是她的好我已经习惯了，我自认为每天上下班接送老婆孩子没什么问题，可能性子比较急，就总是和她吵架，但是我真的是想给她解决问题，她要的那种只是倾听我真的做不到，我会不自觉的就想既然他和我提出她工作上的困难，那就是为了让我给出办法解决的，不知道广大佬友是不是这么认为的。 就写到这吧，在办公室里，再写要掉珍珠了不太好，也不知道为啥我这么感性。 感谢看到这的佬友们，能看完我这文理不通的一大段话，谢谢！！！ 362 个帖子 - 236 位参与者 阅读完整话题

28. 28
    我也聊聊我的公益站

    随便聊一聊公益站吧 搞七捻三 “公益站评分”真的有必要吗？揪出坏人或许可以换一种方式 运营反馈 hlool公益站其实做的时间不长，到现在都是小站 没有这种太大的必要。 我觉得这个积分放在这里比较好看，说不定哪天可以在 L 站买房。 因为像智谱、Kimi 还有 MiniMax 那个时候的价格说实话不算特别高，给的量也相对还可以一些，也没有那么多的限制。 但是 Coding plan 这个东西，就在我开始做测评站之后两个月左右，就已经开始恶劣的生存环境了： 先是从阿里开始带头，把这个东西变成了 token plan，又搞了这些七七八八的限制； 加上智谱之类的各种封号。 这导致我想要做的国模公益站，提前放弃了想法。 第一轮 Bug Team： 第二轮 Bug Team（我当时用的那一轮）： 我的公益站是在这一轮开启的： 一开始，我的公益站全部都没有收 LDC，因为我不确定公益站什么时候会关。在 Bug 第一天的时候，我确认了一下，发现这个还蛮持久的。 到了第二天，有人建议我开一下 LDC 兑换。因为当时 100 刀大家很快就跑完了（我是给每一个进站的都送了 100 刀），所以我就开了 LDC 的兑换码。结果开完之后，大概买了几个我也没什么印象了，但是卖出去蛮多张额度卡。有的找我退了，也有一部分没有退。在 Bug 结束之后，没办法，我就闭站了。 但是，有消费过 LDC 的用户还是有几个的，他们也没有发起退款申请，所以我觉得很不好意思。我就发帖说，之前有付费或者付过 LDC 的用户，我就用我的 PRO 号，把你们所有的额度都消耗完。 在这个期间，我又去了解了一些其他的渠道，比如 Plus，包括第 3 轮的 bug team（也就是现在炸弹车的前身）。 公益站开的是 LDC 付费，采用邀请制，每个人买的是兑换码。一开始设置的是 20 LDC，一路涨价到现在是 688 LDC。差不多有半个月左右，没有拉新的邀请码进来了。 那天纯粹是因为我自己开了一些 Plus 号。那时候 Plus 号的成本还是比较低的，大概五六块钱一个，相比于 Bug Team 会好一些，Bug Team 那时候都是一天两天左右才会炸。plus号的话可以用一周。我就觉得，如果放到公益站里边，因为那个时候公益站的人不是很多，但如果我开放的话，消耗额会很大，我自己又吃不下这么大的量。 所以我就想着，要不然就发到“扬帆起航”去，按照 0.01 的价格卖出去。反正其实也等于是公益了，只是价格比较便宜一些，这是我自己的心里想法。 我那个时候是想着：如果我卖这么低的价格，会不会很容易就把这些号消耗完了？那我能不能稍微回一些本，或者学习到一些做低价中转之类的技巧？可不可以再去管理更大一些的号池？ 结果就是我发了“扬帆起航”，连续吃了好几个举报，帖子被下掉了。当天心里有点难受，感觉我平常也是做公益的，发这种东西也不是不尊重论坛的举报机制。 不过，我觉得这种东西吃举报也正常，确实也不好。因为一边开公益站，一边在“扬帆起航”里面再去卖，那还不如大大方方直接开一个“富可敌国”呢。 所以就有了帅站。一直开到现在，这个公益站也一直坚持到现在，每天也能稍微跑掉一些量。因为没有什么时间去维护，所以公益站那边直接接了帅站这边最便宜的 API，稳定性也是一致的。差不多就是这样，这就是我公益站一直开到现在的历程。 我主要想说的是，关于公益站收 LDC 的问题。说实话，如果让很多佬友浪费自己的 LDC 在一些没有用的公益站上，确实不太好。虽然我的公益站也没有做到百分之百稳定，但 LDC 毕竟是大家的心血。 对于新开的公益站，可以考虑不一定都要收 LDC。我觉得收 LDC 的站点应该具备一定的稳定性，最起码要让大家能把充值的额度消耗完。当然，这也是因为我在 LDC 收费前，就已经针对防止积分滥用、倍率乱飘的情况提前做好了预案。比如说，我的公益站签到的金额是每天消耗的，其他有的没的的倍率之类的也都是动态去进行调整的，所以我的公益站会相对于健康一些。 很多佬友可能说，开公益站的时候是一时脑热，没有对积分之类的做限制，导致积分或者签到积分膨胀得非常快。 公益站这个东西本身是好的，但是如果变成用来收割 LDC 的工具，那我觉得就不是很好啊。当然，这个东西也看个人动机，每个人有自己的行为准则，我也不好过多评价，这只能代表我个人的意见想法。 晚一点的时候，发一点邀请码吧，看一下有没有有需求的，可以蹲一下。你好，我的供应站不是说是百分之百调用成功的，因为也是目前的炸弹车。 反正你正常去我帅站用的话是 0.08 倍率，在我公益站里面用的话是 0.6 倍率，但是是 3 LDC 兑换 1。 直接拿钱在我那个 3a 站充也差不多啊，反正看大家自己的需求。我一向都是，包括商业站也好，公益站也好，大家都是量力而行，有能力就上，没能力就不要上。 稳定性我们没法打包票，但是能不能一直做下去，或者说在没有渠道假设断供的时候，一旦有渠道会不会恢复。这个我可以比较肯定地说，那我会恢复，不会全嘎的。 希望L战可以向上向好发展，大家还是减少一些相关的争议吧。 如果还是有很多老站长愿意去开公益站，大家可以提前参考一下我的做法：不要让积分膨胀得太快。因为积分膨胀太快的话，会导致你兑现不起，也会影响你自己的羽毛。我反正会比较爱惜我的羽毛，我对自己的声誉和相关评价会比较在意。我很难接受挨骂。 74 个帖子 - 68 位参与者 阅读完整话题

29. 29
    L站首发图片在多个平台被搬运的记录

    昨天晚上，我 vibe coding 画了一张说明 DeepSeek V4 Flash 更新后性价比的示意图： DeepSeek V4 Flash 0731 肘击 GPT & 最新斩杀线 直观示意图 开发调优 [artificial-analysis-all-models-4k] 结果第二天早上，就在 X 上刷到了改图： 打开L站，还看到了内销转出口再转内销： DeepSeek 毒圈/斩杀线，直观形势图 国产替代 还给标出来了（高亮的矩形里，都中毒了） 不知道 DeepSeek V4 Pro 正式版会把这个矩形拉到什么面积，求矩形（中的模型）的阴影面积 智普必须开始跑毒了 [image] PS:出口转内销了 出处在这里：DeepSeek V4 Flash 0731 肘击 GPT & 最新斩杀线 直观示意图 掉入deepseek斩杀线的模型，已经不需要了 搞七捻三 [image] 这使我好奇，各大平台搬运这张图的时间顺序是什么样的。 下面是我已知的发现： 当前晚上，就被搬运到 X 第二天凌晨，出现在了小红书 到了上午，出现在了抖音 到了下午，甚至4chan都有了 可以看出，X 和 小红书 大概是本坛以外 AI 信息最快的平台 我能找到的还十分有限。欢迎大家补充更多被搬运的情报，看看更多平台的信息是怎么流转的 44 个帖子 - 41 位参与者 阅读完整话题

30. 30
    gpt-5.6-luna的价格是不是有点夸张了

    我简单算了一下，一般来讲用gpt的话大部分人中转用的比较多，把plus池去掉，pro池一般是0.25r/刀的就已经很稳定了。 那这样子，就相当于0.05r/1m的输入，0.3r/1m的输出，0.005r/1m的缓存。。。。 中转站国模最多做到5折 拿ds-flash举例的话，就是0.5r/1m输入，1r/1m的输出，0.01r/1m的缓存 但是我用luna用的比较少，不知道luna和国模的什么模型能比较匹配能力比较相似，但是单看这个价格 70 个帖子 - 55 位参与者 阅读完整话题