标题: Anthropic 内部新模型Claude Mythos ，听说比opus还要猛的多，内部声明会对网络安全带来新的挑战
作者: #Ndjasnd
板块: #前沿快讯
编号: 1834075
帖子: https://linux.do/t/topic/1834075
时间: 2026-03-27 11:45:04
摘要:

有佬了解内部信息吗

标题: vscode的claude插件，使用中转站，对话就跳登陆页面，如何解决
作者: #lubiancao
板块: #开发调优
编号: 1834094
帖子: https://linux.do/t/topic/1834094
时间: 2026-03-27 11:47:41
摘要:

vscode的claude插件，使用中转站，对话就跳登陆页面，如何解决？求救各位大佬

标题: 关于AI导游
作者: #xdtz
板块: #搞七捻三
编号: 1834110
帖子: https://linux.do/t/topic/1834110
时间: 2026-03-27 11:50:43
摘要:

国内有类似的工具吗，或者手动让ai生成一段带路线引导的导游内容然后转化成mp3？
比如我要去苏州西园寺玩，输入景点让ai生成一段从门口开始的导游词，是不是挺不错的

标题: [开源项目]前些日子有佬友私信我想要我们内部的Agent项目···
作者: #白芸汐
板块: #资源荟萃
编号: 1834121
帖子: https://linux.do/t/topic/1834121
时间: 2026-03-27 11:51:55
摘要:

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

我的帖子已经打上 开源推广 标签： 是
我的开源项目完整开源，无未开源部分： 是
我的开源项目已链接认可 LINUX DO 社区： 是
我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出


  

      github.com
  

  
    
  

  GitHub - CloudWide851/easy-agent: easy-agent is a white-box Python foundation for...

    easy-agent is a white-box Python foundation for building agent systems that you can actually inspect, test, and extend.


  

  
    
    
  

  


这是一个开源、白盒、可检查、可扩展的 Python Agent 运行时底座。有些佬友可能并不熟悉Agent如何设计，也不知道该如何在不同的项目运用Agent，于是我借鉴（copy）了一下我在内部使用的Agent项目（这个也是我设计的，只不过比较早了），然后以一个更新的架构和更好的兼容性给佬友们开源出来。
这个项目的设计理念就是一切行动可见，所以刻意将所有的动作都暴露了出来。
由于是这几天比较忙并且迁移工程是有点大的，所以大部分就用codex帮我代劳了。

而且肯定会有很多的bug，佬友们多多提有效的issues，用的是ap2.0的协议，有什么想加的功能也可以直接提，我会标记之后慢慢实现。
没什么技术含量，轻喷

标题: 有佬友找工作吗，云台算法工程师，有想法的私聊我，给你邮箱内推简历哦
作者: #cuican
板块: #非我莫属
编号: 1834128
帖子: https://linux.do/t/topic/1834128
时间: 2026-03-27 11:52:59
摘要:

职位：云台算法工程师
薪资：25k-30k×13薪
工作地点：深圳市南山区深大地铁站附近（1号线/13号线）
工作时间：9:00-18:30弹性打卡上下班，周末双休
岗位职责：
1.负责云台控制算法的设计与实现，包括：
1.1.1.三轴稳定控制、抗抖与外部扰动抑制
1.1.2.基于 IMU/编码器的姿态解算与姿态控制
1.1.3.目标跟踪场景下的云台随动控制
2.设计和优化云台控制策略：
2.1.1.姿态/角速度/电流多环控制结构
2.1.2.PID、前馈、模型补偿等控制算法建模与参数整定
2.1.3.抗抖滤波、限幅限速、轨迹平滑等控制逻辑
3.与视觉/感知工程师协作：
3.1.1.基于检测结果设计视角/构图保持、平滑跟随策略
3.1.2.负责视觉坐标到云台角度的坐标变换与标定
4.参与相关嵌入式软件开发：
4.1.1.在 MCU / SoC / RTOS 上实现控制算法
4.1.2.通过串口 / CAN / 以太网等与上位机交互
5.建立测试与标定流程：
5.1.1.稳定性、响应速度、平滑度测试与评估
5.1.2.标定与参数配置工具的设计和维护
任职要求：
1.计算机、自动化、控制、机器人等相关专业本科及以上学历，3 年以上相关经验（优秀者可适当放宽）。
2.控制理论基础扎实，熟悉 PID、串级控制、状态反馈等，并有实际调参经验。
3.至少熟悉一种姿态解算/传感器融合算法（Mahony/Madgwick、互补滤波、EKF 等），理解四元数、欧拉角、旋转矩阵及其转换。
4.具备以下任一经验优先：
4.1.1.云台/稳定器等相关项目经验
4.1.2.无刷电机控制（BLDC）、FOC、电机驱动调试经验
5.熟练使用 C/C++，熟悉嵌入式开发环境，编码规范良好；有 STM32 / ESP32 / RK 平台或 FreeRTOS / RT-Thread 经验优先。
6.理解基础信号处理与滤波（低通/带通滤波、卡尔曼滤波、噪声分析等），有抗抖处理经验更佳。
7.具备良好的沟通协作与工程实现能力，能与机械、硬件、算法团队高效配合。

标题: codex free 账号100个 新鲜出炉~
作者: #XZ
板块: #福利羊毛
编号: 1834130
帖子: https://linux.do/t/topic/1834130
时间: 2026-03-27 11:53:43
摘要:

codex free 100.zip (287.2 KB)
刚跑的，有需要的佬可以自取，麻烦路过的点个啦啦啦~干饭时间到了

标题: GPT的幻觉已经畸形了
作者: #缺失的触发点
板块: #搞七捻三
编号: 1834139
帖子: https://linux.do/t/topic/1834139
时间: 2026-03-27 11:56:18
摘要:

直接问他问题，一般它能答得很好，没有幻觉
一旦你把问题和答案一起输给他，它就会否定。哪怕你是正确的他都要说你是错的。
另一种情况是，如果答案是gpt的上个回答，哪你即使误解了他都判你是对的
实在受不了了！！！
只能多个大模型轮流用，deepseek现在生成的东西都贼官方晦涩冗长，gemini输出又极短，GPT擅长否定人，肯定自己，真的好难！

标题: 想问一下各位佬除了codex之外还有哪些可靠的反代渠道吗
作者: #admln
板块: #开发调优
编号: 1834143
帖子: https://linux.do/t/topic/1834143
时间: 2026-03-27 11:57:24
摘要:

最近team封的好厉害，感觉快死了，反重力不用说了，全封完了

标题: 一觉睡醒3个team都挂了
作者: #lofivo
板块: #搞七捻三
编号: 1834144
帖子: https://linux.do/t/topic/1834144
时间: 2026-03-27 11:57:35
摘要:

天才程序员陨落了

标题: copilot的教育优惠怎么也拉闸了
作者: #hefeng
板块: #开发调优
编号: 1834145
帖子: https://linux.do/t/topic/1834145
时间: 2026-03-27 11:57:45
摘要:

一直rate limit ，这个是政策改了吗

标题: GPT出现bug，额度全部重置了。
作者: #junes
板块: #前沿快讯
编号: 1834146
帖子: https://linux.do/t/topic/1834146
时间: 2026-03-27 11:57:56
摘要:

突然间所有gpt的额度都重置了

标题: 公众号发公益站，是否有利用公益站，博流量变现的嫌疑呢
作者: #Midsummer
板块: #搞七捻三
编号: 1834147
帖子: https://linux.do/t/topic/1834147
时间: 2026-03-27 11:58:19
摘要:

如题，我发现有公众号在宣传站内的公益站，

标题: 关于 OpenAI Team 风控，这周拿几十个号做了点测试
作者: #杨
板块: #文档共建
编号: 1834149
帖子: https://linux.do/t/topic/1834149
时间: 2026-03-27 11:58:46
摘要:

最近 OpenAI 对 Team 的风控明显紧了，翻车反馈一波接一波。
我和几个朋友这段时间手里刚好有几批 Team 号，就顺手折腾了一下，把几种常见用法都跑了一遍，想看看现在到底是哪种场景更容易出事。
我这边一共碰到四组情况
A 组：自建中转，同 Team 统一走家宽代理
这一组是目前最稳的。
做法很简单，就是自己挂中转，把同一个 Team 下的号尽量都走同一类家宽代理。
这里面不只是一个 Team，有几批 Team 都这么跑，甚至还有多个 Team 共用同一个家宽代理的情况。
到现在为止，这批都还正常，没看到封号。
这一组给我的感觉很直接：
家宽代理本身是一方面，但更重要的是，整个 Team 的环境比较统一，跑出来就稳定很多。
B 组：自建中转，但后面直接接原生机房 IP
这一组就很惨了。
前面还是自建中转，区别只是后端没接家宽代理，直接走原生机房 IP。
这类线路的性质，跟现在大部分机场节点其实挺像的，至少我自己是这么看的。
这一组我上了两批 Team，10 个号，最后一个没剩，全封了。
所以 A 和 B 摆在一起看，意思已经很明显了：
不是你有个中转就行，底层环境本身要是风险高，照样扛不住。
C 组：本地直接用，网络走机场
这一组也是全灭。
这里不是统一走中转，而是本地直接登 Team。
本地用的是机场，里面当然也有不少号称家宽的节点，但最后结果没区别，整组还是没了。
这组我现在比较怀疑的是节点切换和区域跳动。
因为本地用机场，很难保证线路一直老老实实待在一个地方。哪怕你自己没怎么折腾，实际出口是不是有波动、是不是短时间跳过区，外面也看不太出来。
所以这组让我有点改观：
不是节点名里带了“家宽”就够了，本地直接这么跑，稳定性未必真能达到 Team 现在这个风控强度的要求。
D 组：Team 分给朋友，各自在本地用
这一组也没好到哪去，最后还是全灭。
这个场景其实很常见。
同一个 Team，成员号分给朋友，大家各自在自己那边登，自己那边用。
结果也很直接，最后整组都没保住。
这组最难受的地方在于不好排查。
因为只要是多人分散使用，你根本没法保证每个人的网络环境、登录习惯、地区、切节点频率都差不多。
只要有一个人线路脏一点，或者大家分布太散，最后就可能不是封一个人的问题。
我自己现在基本怀疑两件事：

OpenAI 会看 Team 内成员是不是长期分布在不同区域。
也可能只要有人用了高风险线路，整个 Team 都会被一起带走。

哪条占得更多，现在还说不准，但 D 组这个结果已经很说明问题了。
四组放一起看，基本就是这么回事
A 组稳，B、C、D 三组全翻。
经过这一周实测，我现在对 Team 的理解大概是这样：
第一，看的不只是线路类型，还看整组是不是统一
A 组能稳，不只是因为挂了家宽代理，还因为整组走法比较一致。
C、D 两组会死得这么快，也不只是“用了机场”这么简单，更多还是因为环境太散，波动太大。
第二，原生机房 IP 这类底层环境风险确实高
B 组这点挺直观的。
前面已经做了中转，还是没扛住，说明问题不在“有没有包一层”，而在底子本身就不太干净。
第三，家宽这两个字不能单看
C 组里也不是没有所谓家宽节点，但照样没活下来。
所以我现在不太信“只要家宽就稳”这种说法。
我这边实测下来的感觉更像是这样：

稳定的家宽代理，配合统一的 Team 环境，确实更容易活。
本地直接用机场，哪怕里面有家宽节点，也不代表结果会一样。
Team 一旦开始多人分散、区域不一致、线路乱七八糟，风险就会往上走。

第四，Team 好像是会连带，不像Plus是单号，天然去掉了一些风险
这个是这次折腾下来最明显的感受。
要是单号风控，很多情况不该死得这么整齐。
但现在看下来，系统像是在看整个 Team 像不像一个正常团队，而不是只盯着某个号某次登录。
记下几个高风险场景
我这边踩出来的高风险场景，大概就是这些：

Team 内成员分散在不同地方，各自本地使用
本地长期靠机场跑，而且节点会切、出口会飘
同一个 Team 里混着用好几种不同环境
底层直接就是原生机房 IP
团队成员的登录习惯差异太大

反过来看，统一中转、统一环境、长期固定，确实稳很多。
至少我手里这几批号，结果就是这么摆着的。
最后
这几天实测下来，我现在最大的感受是，Team 已经不是“单号别太浪”那么简单了。
它更像是在看整组的行为是不是稳定、是不是像一个正常团队。
A 组一直没事，B、C、D 三组全翻，放在一起已经很能说明问题了。
现在影响 Team 存活的，肯定不只是线路名字好不好听，也不只是单个人这次上号干不干净，更多还是底层环境本身风不风险，以及整个 Team 的使用方式够不够统一。
如果有人手里还有一直稳着的 Team，也欢迎说说你那边大概怎么用的。
看下区域稳定、线路类型、成员分散程度，这几个东西到底哪个更致命。