标题: 关于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，也欢迎说说你那边大概怎么用的。
看下区域稳定、线路类型、成员分散程度，这几个东西到底哪个更致命。

标题: 怎么邀请人进站呢
作者: #moaiwo
板块: #搞七捻三
编号: 1834150
帖子: https://linux.do/t/topic/1834150
时间: 2026-03-27 11:59:01
摘要:

如题怎么邀请人进站呢 各位佬们

标题: 有云台算法经验的佬友吗
作者: #cuican
板块: #搞七捻三
编号: 1834153
帖子: https://linux.do/t/topic/1834153
时间: 2026-03-27 11:59:15
摘要:

有个岗位帮朋友内推， 25k-30k×13薪，可以看我另外一个帖子：有佬友找工作吗，云台算法工程师，有想法的私聊我，给你邮箱内推简历哦

标题: 今日大A走势
作者: #xuanRan
板块: #搞七捻三
编号: 1834160
帖子: https://linux.do/t/topic/1834160
时间: 2026-03-27 12:00:46
摘要:

大A上午啥情况？一枝独秀？？？

标题: 最新可托管CF的EU域名
作者: #czone
板块: #福利羊毛
编号: 1834172
帖子: https://linux.do/t/topic/1834172
时间: 2026-03-27 12:02:24
摘要:

地址：https://www.myown.eu
可注册 *.my.be
还有好多3位的

标题: Apifox 供应链投毒事件有感：普通开发者后续到底该怎么防？
作者: #zyc8
板块: #开发调优
编号: 1834173
帖子: https://linux.do/t/topic/1834173
时间: 2026-03-27 12:02:59
摘要:

这两天我自己排查了一轮 Apifox 这次供应链投毒事件，越排查越后怕。
最难受的点其实不是“有没有中招”本身，而是这类问题一旦发生，向我这种普通开发者真的会很被动。因为你信任的软件、正常安装的软件，结果自己带毒了。等你发现的时候，最担心的已经不是软件本身，而是本机上的各种信息有没有被读走，比如：
• Apifox 账号信息
• 机器指纹、主机名、MAC 地址这类信息
• shell history
• Git / npm / SSH / 云平台相关凭证
• 服务器登录密码、管理后台密码等
我自己这次已经做了一轮排查和清理，也把本地残留、history 之类都处理了一遍，但说实话，这种事情还是让我有点后怕。
所以我现在特别想认真请教大家一个问题：
站在普通开发者 / 独立开发者 / 小团队开发的角度，后续到底应该怎么尽可能避免这类问题？
我目前想到的方向有这些，但不确定是不是最优解：
1. mac 上装更强的出站防火墙，比如 Little Snitch / LuLu，重点监控软件偷偷外连
2. 凭证尽量不明文落盘，比如 Git 走 Keychain，不在本地存 .git-credentials
3. 服务器尽量别再用 root + 密码直登，改成普通账号 + sudo，最好限制 SSH 来源 IP
4. 尽量减少本机存放高价值凭证，比如 SSH 私钥、云平台密钥、各种 token
但是总感觉还是有风险，所以想请各位佬帮忙分享一下：
• 你们平时是怎么防这种“正常软件被投毒”的？
• mac/windows 上有没有真正实用的安全工具推荐？
• 小团队有没有成本不高、但效果不错的安全方案？
• 除了杀毒 / 防火墙 / 凭证管理之外，还有哪些我没想到的习惯或流程？

标题: 财富杂志爆料Anthropic新模型：新模型Mythos和新模型级别Capybara
作者: #绪里
板块: #搞七捻三
编号: 1834178
帖子: https://linux.do/t/topic/1834178
时间: 2026-03-27 12:03:42
摘要:

原链接：https://fortune.com/2026/03/26/anthropic-says-testing-mythos-powerful-new-ai-model-after-data-leak-reveals-its-existence-step-change-in-capabilities/。原链接需要订阅财富杂志。
其中重要的信息是，Anthropic的人为错误导致泄露了大概3000份未发布的文件，被财富杂志发现，现在Anth已经关闭了这些文件的访问权限。但文件里泄露了一些博客草稿，说有一个叫Claude Mythos的新模型，并且未来会有一个叫Capybara的新模型级别。Capybara计划中会比Opus更大更强，成本也更高，说是在coding、学术推理和网络安全测试里得分大幅提升。官方说代表了AI性能的step change，但因为运行成本太高目前只向部分“抢先体验客户”开放测试。草稿还说新模型在网络能力方面远超其他AI模型，Anthropic担心它会被黑客利用来发现漏洞开展大规模网络攻击（当年OpenAI在GPT2时代也担心过类似的东西？），所以Anthropic决定优先把新模型提供给网络安全防御组织来提前巩固代码库。