标题: gemini-3-pro-preview的使用感觉
作者: #guan yu
板块: #搞七捻三
编号: 1185391
帖子: https://linux.do/t/topic/1185391
时间: 2025-11-19 09:18:11
摘要:

昨天听说上线赶紧去试了一下。
我先说一下我的情况，我是付费用户（不然没法用），在模型列表里找了一下才发现的，因为不太起眼……
聊了一会，首先，上下午的长度输出似乎没有特别明显的变化，其次，我不得不说和2.5比起来确实好了很多。
举个例子，我在输出一个问题的时候，得到的回复通常比较完善，回复的语气也比较接近chatgpt的感觉，就是比较“温柔”。
文字上的输出修饰也很漂亮，似乎对人类有点理解了。
当然我也只是粗略的感受了一下，也有负面的（听别人反馈到的），但是目前我这里还没有大问题。

标题: 时间线上的帖子全是哈基米3...
作者: #川皇
板块: #搞七捻三
编号: 1185402
帖子: https://linux.do/t/topic/1185402
时间: 2025-11-19 09:19:28
摘要:

一条一条又一条，条条都是哈基米

标题: antigravity 隔这食物链呢
作者: #stoneGovo
板块: #开发调优
编号: 1185411
帖子: https://linux.do/t/topic/1185411
时间: 2025-11-19 09:20:29
摘要:

cursor importfrom vscdoe

antigravity import from vscode and cursor

标题: 3级是什么感觉
作者: #旺旺旺
板块: #搞七捻三
编号: 1185421
帖子: https://linux.do/t/topic/1185421
时间: 2025-11-19 09:21:11
摘要:

谁能点赞说明下3级是什么感觉呢，什么时候才能到3级

标题: [求助 手搓的 LinuxDo 签名生成器
作者: #张麻子
板块: #搞七捻三
编号: 1185445
帖子: https://linux.do/t/topic/1185445
时间: 2025-11-19 09:24:45
摘要:

手搓的LinuxDo签名生成器第二版来了 
  

资源荟萃
    
  
  
    第一版使用数据生成PNG图片, 由于图片大小和渲染问题, 不太美观,且清晰度不够,如下图: 
 [图片] 
第二版采用了SVG图片格式,并且增加了部分美化的小图标,如下图 
[图片] 
签名图片的获取地址没有变: https://linux-do-card.0x1.site/ 
开源地址也没有变: https://github.com/zjkal/lin…
  


这个佬做的签名网站我咋打不开呢,是现在有什么新要求了吗

标题: 【深夜反思】我欠儿子一个道歉：关于男人“坐着尿尿”的真相，这事儿真不丢人
作者: #ocean-zhc
板块: #搞七捻三
编号: 1185452
帖子: https://linux.do/t/topic/1185452
时间: 2025-11-19 09:26:17
摘要:

说实话，写下这就话的时候，我心里挺复杂的，既有点惭愧，又有点打开新世界的惊喜。
事情是这样的。家里卫生间总有一股挥之不去的“隐形尿骚味”。虽然老婆经常刷，我也偶尔帮忙，但那个味道过两天就又冒出来，尤其是马桶周边的地砖缝隙里。
我一直坚定地认为，这绝对是我那个4岁儿子的锅。
每次带他上厕所，我都在旁边像个教官一样盯着：“瞄准点！”、“别滴到外面！”。只要发现马桶沿上有一点水渍，我就认定是他干的，免不了一顿唠叨甚至训斥。我觉得小孩子嘛，控制力差，肯定是他把尿撒得到处都是。
直到上个月，按照老婆的强烈建议，就尝试了在家“坐着尿尿”。这一坐，就是一个“辈子”。哈哈哈，预约了一辈子。。
神奇的事情发生了。
那个困扰我们家很久的、若有若无的尿骚味，竟然彻底消失了！马桶圈下面、地砖缝隙，甚至不需要刻意去刷，都干干净净。
我这才去查了一下资料（作为一个理科男，我竟然现在才查）。原来，男人站着排尿时，无论你瞄得有多准，都会产生肉眼看不见的“微小液滴飞溅”（Micro-splatter）。这不仅仅是液体撞击水面，更是液体流速本身造成的喷雾效应。
这些微小的尿液颗粒，会飞溅到马桶圈底部、马桶外壁，甚至两米开外的牙刷上。日积月累，这就是卫生间异味的元凶。
那一刻，我看着正在客厅玩积木的儿子，心里全是愧疚。
原来这么多年，那个把卫生间弄脏的“罪魁祸首”，根本不是那个还在努力学习瞄准的孩子，而是自以为“枪法神准”的我。我用成年人的傲慢，误解了孩子，还让他背了这么久的黑锅。
现在，我已经彻底加入了“坐着尿尿党”。
兄弟们，放下所谓的“男子气概”包袱吧。在家坐着尿尿，真的不丢人。
第一，卫生间真的不臭了，家庭矛盾减少50%；
第二，不用频繁刷马桶死角，解放劳动力；
第三，坐下来那几十秒，还能顺便回个消息、刷个短视频，不香吗？
从今天起，做一个温柔的、坐着尿尿的爸爸。儿子，对不起，老爸以后陪你一起坐着。

标题: gemini3出了，各位佬准备怎么用他呢？
作者: #夜猫疯
板块: #开发调优
编号: 1185474
帖子: https://linux.do/t/topic/1185474
时间: 2025-11-19 09:31:17
摘要:

刚起来，等下去试试。
目前能想到的有，1、claudecode 接入gemini3.0？没试过也不知道行不行。
2、搞个镜像站玩玩gemini3？
3、用geminicli，但是好像他的cli似乎不咋好用
各位佬还有什么有趣的用法吗？

标题: Google Antigravity登录成功但卡在别的地方了
作者: #愿静
板块: #开发调优
编号: 1185483
帖子: https://linux.do/t/topic/1185483
时间: 2025-11-19 09:33:30
摘要:

看站里很多佬友都说登不上，但是我一下就登上了。
兴冲冲的打开一个本地的java项目，安装好java的拓展，突然发现！
右侧可以选择模型和输入内容的区域变成了：

已经持续半小时，不知道这是啥bug，重启也不行

标题: 各个方向用哪个AI? 比如前端用gemini3
作者: #疯王伊里斯
板块: #搞七捻三
编号: 1185492
帖子: https://linux.do/t/topic/1185492
时间: 2025-11-19 09:35:03
摘要:

那么后端呢? 写作呢? 翻译呢? 文案呢? 等等各个方向.
目前都是用 claude-sonnet-4-5.
已经习惯在舒适圈了, 听听各位佬的经验, 等用到的时候去实测一下.
还是想物尽其用.

标题: 全球 AI 网关架构：CloudFlare 故障启示
作者: #triplekillgod
板块: #开发调优
编号: 1185500
帖子: https://linux.do/t/topic/1185500
时间: 2025-11-19 09:35:46
摘要:

全球 AI 网关架构：从入口到计费记录的完整链路
在构建一套能够覆盖全球、多区域部署，并支持跨供应商路由的 AI 网关体系时，我们很快意识到，仅仅把一组区域化的集群堆叠起来并不能真正解决问题。真正的挑战在于链路的完整性：当请求从不同地域、通过不同网络条件，并借助多家入口提供商接入系统时，网关内部的调度与控制插件如何与 DCDN、区域网关协同工作，从而保证“入口稳定性”“跨供应商调度能力”和“故障场景下的可用性”能够形成一条连续且可控的技术链路。本文试图从这个角度拆解整个过程，依次说明每个组件在链路上扮演的角色，以及它们之间如何自然衔接，从而支撑一个稳定、可观测和可审计的全球 AI 调用体系。
为了让讨论更直观，我们沿着请求的自然路径，从 DCDN 入口开始，依次跟踪到区域网关、节点内部调度逻辑，并最终到达 usage / 计费记录的汇总过程，从而呈现整个体系如何在复杂性和一致性之间取得平衡。
从 10,000 米俯视这套系统，可以用一条简单的链路来概括：
终端用户
   │  单一域名访问
   ▼
〔DCDN / 全局入口层〕
   │  多家 CDN / PoP，按地域、健康度和策略动态选路
   ▼
〔区域网关集群（Gateway Node，多区域）〕
   │  鉴权 / 风控 / 供应商选择 / 内部调度插件
   ├──────────────→ 各区域 AI 供应商 / 模型
   │
   ▼ usage / 计费事件
〔全局管理平面〕
   ├→ Manager：入库 / 结算 / 风控
   └→ Admin：统一管理入口（配置 / 报表 / 策略分发）

1. 全局拓扑：三层结构背后的链路逻辑
从任意地点发出的请求，在本架构中通常经历三层逻辑。首先，它落在全局入口层，由多家 DCDN 提供的边缘节点尽可能就近且稳定地接收流量；随后，请求根据地理位置、健康状态以及流量策略被引导至对应区域的网关集群，由区域网关完成鉴权、风控、租户映射以及供应商选择等核心操作；最后，当请求进入具体节点后，节点内部的调度与控制插件会在统一状态视图下执行决策、管理回退，并将整个调用过程的关键事实写入 usage 日志。
前两层的关注点在于“请求在哪里落地以及应送到哪个区域”，而第三层则关注“在区域内如何执行、如何控制状态、如何确保记录的准确性”。三者之间既有清晰边界，也高度协同，形成一条既分层又连续的技术链路。
2. 全局入口层：多路径容错与动态选路
入口层的核心目标是：在全球范围内，以最低延迟和最高可用性接住请求。实现这一目标并非简单堆叠 CDN 节点，而是要求入口对网络状态高度敏感、能够动态适配和调整路由策略。
具体做法如下：
对外单一域名背后接入多家 CDN / PoP，每个节点不仅提供网络覆盖，还参与健康检查与动态权重计算；
入口层持续执行健康检测，包括可用性、延迟、丢包率和错误率等指标，根据策略动态调整流量权重；
当某家提供商或 PoP 出现异常时，流量会自动切换至其他 DCDN 或自建入口，以确保整体链路不受单点故障影响。
在架构设计上，Cloudflare 是其中重要的一环，但其身份是“可替换路径”，而非单点依赖；入口层完成路径选择之后，流量会根据地域策略被分发至对应区域的网关集群，从而为后续调度提供稳定前置条件。
如果单独放大入口层，大致是下面这样的形态：
用户浏览器 / 客户后端
           │  访问 api.xxx.com
           ▼
      统一域名（DNS / Anycast）
           │
   ┌───────┴────────┬───────────────┐
   ▼                 ▼               ▼
〔DCDN 提供商 A〕 〔DCDN 提供商 B〕 〔自建入口〕
   │                 │               │
   └─────── 基于健康度 / 延迟择优 ───────┘
                     │
                     ▼
            目标区域入口（如 AP-SG / EU-FRA）

3. 区域网关层：一致代码、策略下发与区域自治
当请求抵达某个区域后，它将进入部署在该区域的网关集群（Gateway Node）。这些集群之间保持对等关系，运行相同代码并共享统一策略模型，同时基于管理端下发的配置针对区域特性进行策略调优，包括供应商选择、网络线路偏好以及服务级别控制。通过这种方式，系统在全局保持一致服务形态的同时，也能应对区域网络波动和供应商质量差异。
区域网关的主要责任包括：
完成基础鉴权与风控，拦截异常流量；
将请求映射至租户、产品线和具体服务类型；
根据区域配置选择供应商和代理线路，并在必要时执行有边界的本地回退（fallback），避免单个渠道故障引发区域级连锁抖动。
节点内部的调度与控制插件便在此层执行，它将上述动作串成原子化执行过程，确保一次调用从进入到离开都是可控、可审计、可回溯的。
从拓扑上看，一个区域内大致是这样的结构：
           区域入口（例如 AP-SG）
                     │
                     ▼
                区域负载均衡
                     │
         ┌───────────┴───────────┐
         ▼                       ▼
    Gateway 节点 1           Gateway 节点 2   …（同一集群）
         │                       │
         └──────── 共享状态层 / 策略配置 ───────┘
                     │
                     ▼
           本区域 AI 供应商 / 代理池

4. 节点内部调度插件：识别、决策与记录的连续过程
节点级调度插件是整个链路的核心，其流程可划分为三个连续阶段：识别、决策和记录。
识别阶段：构建调用上下文
插件识别调用方身份、调用目标、模型类型、服务级别以及预期区域，并基于管理端下发的配置构建策略视图，为后续决策提供统一上下文，从而保证不同区域或入口的请求在策略执行上保持一致。
决策阶段：在统一状态层上进行原子判断
插件在全局状态层上执行原子操作，包括额度消耗、并发控制、限流判断，并结合区域路由规则选择具体供应商或代理链路；当出现供应商不可用或网络错误时，插件在策略允许范围内发起区域内回退，仅切换至备选渠道，并严格控制边界，避免级联重试或状态重复扣减。
记录阶段：将调用事实写入 usage
插件将调用过程的关键数据（入口来源、落地区域、供应商选择、回退信息等）写入 usage / 日志体系，这些数据会被管理端用于结算、风控、分析以及未来调优。该流程确保多入口、多区域、多供应商环境下的调用结果保持一致、可追踪。
如果只看单个节点内部，可以把这段流程串成一条清晰的处理链路：
         进入节点的请求
                 │
                 ▼
           身份 / 租户识别
                 │
                 ▼
              风控校验
                 │
                 ▼
        状态层检查与占用（额度 / 并发 / 限流）
                 │
                 ▼
        按区域 / 策略选择供应商与代理
                 │
                 ▼
          发起下游调用（含一次受控回退）
                 │
                 ▼
        写入 usage / 日志 → 供管理端消费

5. Cloudflare 故障处理：入口与网关双重兜底
我们在设计中不假设第三方入口永远稳定，而是将其视作可能出现局部或区域性故障的组件，并在入口层与网关层构建双重保护。
入口层保护
健康检测是入口层的常态，当 Cloudflare 的某个区域、某组 PoP 或整体网络异常时，系统会立即将对应路径标记为不可用，并将新流量优先路由到其他 DCDN 或自建入口。已有连接短时间内可能受影响，但不会阻塞新请求。
网关层保护
当请求进入网关后，如果下游某 AI 供应商不可用，调度插件会在策略允许下触发一次区域内备选供应商回退，并将回退信息写入 usage。整个过程严格控制边界：不会多次跳转，也不会造成状态重复扣减或计费误差。
这种设计保证了在第三方入口发生故障时，系统能够从入口和区域两端自我修复，最终用户感知更多是性能波动而非服务不可用。
6. 计费与额度管理：插件作为统一状态执行器
尽管本文不展开具体计费公式，但与架构相关的原则明确如下：
所有额度、并发、限流等状态集中存放于全局状态层，而非依赖任何单台 Gateway 节点；
调度插件在全局视角

标题: Google 出新东西了? 还是我孤落寡闻了?
作者: #卡皮巴拉
板块: #搞七捻三
编号: 1185510
帖子: https://linux.do/t/topic/1185510
时间: 2025-11-19 09:36:29
摘要:

废话不多说, 我看还在 public perview 阶段
https://antigravity.google 官方网址单纯一个网址

标题: gcp求助，一直244
作者: #金亦求金
板块: #开发调优
编号: 1185512
帖子: https://linux.do/t/topic/1185512
时间: 2025-11-19 09:37:06
摘要:

如题，想用gcp300，卡是ether和coca都试过了，应该不是卡的问题，ip用的美国家宽，号用的16年老号（没啥痕迹的），最有可能的问题是哪个因素呀？球球佬们指点