不懂就问 是不是评论图片都不行了？

起因是有佬友发了下20字评论的帖子，都说是不错的想法，然后我就跟了下面的图，怎么就被举报删除了？这属于滥用举报吗？

10 个帖子 - 5 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: 河北彩伽)

如何让 Codex 同时支持 ChatGPT OAuth 与自定义 API Provider

最近 OpenAI 又调整了 ChatGPT OAuth 登录的 codex 用量，原本可能已经不是很宽裕的 5 小时窗口又被削减了一轮，再加上 4 月 2 号开始的双倍额度活动也结束了，我自己的实际体感是现在可能半小时到一小时就会蹬完五小时的额度……但活总得继续干下去呀？

所以我需要一个 fallback 方案：平时继续用 ChatGPT OAuth 登录，毕竟订阅额度不蹬白不蹬；额度不够的时候无缝切到第三方 API provider 继续续命。Codex CLI 本身是支持自定义 provider 和 profile 切换的，所以这件事技术上完全可行。但我实际配置的时候踩了不少坑，这篇文章就是把整个过程讲清楚。

我碰到的问题

首先，Codex CLI 支持两种登录路径：

1. Sign in with ChatGPT：浏览器 OAuth 回调，走 ChatGPT 的额度和数据策略
2. Sign in with API key：直接用 OpenAI 平台的 API key，走 API 侧的计费

在此基础上，Codex 还允许你定义自定义的 model_provider，指向任何兼容 OpenAI 协议的第三方服务，很多第三方中转的配置方式就是让你在 config.toml 文件里覆盖他们的配置以通过中转来调用codex模型的。

因此，我最开始的配置直接用了三方中转的方案：定义一个自定义 provider，指向中转服务的 base URL，然后加上 requires_openai_auth = true。想法很朴素，觉得这样就能"借用 OpenAI 的登录态，走第三方的线路"，两全其美。

结果就是各种稀奇古怪的认证报错，排查下来问题出在三个地方：

requires_openai_auth = true 不是我以为的那个意思。 这行配置的真实含义是：这个 provider 没有自己的 API key，它的认证来源是 OpenAI。一旦我们这么写，它就不是一个"独立通道"，而是 OpenAI 身份体系下的一个变体。所以当你试图在 ChatGPT OAuth 和第三方中转之间切 profile 的时候，底层的认证根本就没换过，两条路共享同一套身份。

auth.json 被我搞脏了。 Codex 会把登录信息缓存在 ~/.codex/auth.json 里，我之前把第三方中转的 API key 也塞进了这个文件。OAuth 缓存和第三方 key 混在一起，Codex 自己都分不清当前该用哪个凭证。

openai_base_url 会污染内建 provider。 Codex 有一个顶层配置项可以直接改写内建 openai provider 的 base URL。如果你在全局设了这个字段指向中转，那即便你写 model_provider = "openai"，请求也不是真的走官方。名字叫 openai，实际已经被改写了。

这就导致明明我选择 codex --profile chatgpt 了，请求还是跑到中转，或者报出莫名其妙的 key 错误。

正确的配置方案

ChatGPT OAuth 应当走内建的 openai provider，不动它的 base URL，不塞任何多余的东西。第三方中转走一个全新的自定义 provider，用自己的 env_key 读取自己的 API key，跟 OpenAI 的登录态没有任何关系。

我用的是站内的 foxcode，因此配置文件 config.toml就以此为例：

# 默认走 ChatGPT OAuth
profile = "chatgpt"

model = "gpt-5.4"
model_reasoning_effort = "medium"
disable_response_storage = true

# ---- Profiles ----
[profiles.chatgpt]
model_provider = "openai"
model = "gpt-5.4"
model_reasoning_effort = "medium"

[profiles.fox-api]
model_provider = "fox"
model = "gpt-5.4"
model_reasoning_effort = "medium"

# ---- 第三方中转 Provider ----
[model_providers.fox]
name = "fox"
base_url = "https://code.newcli.com/codex/v1"
wire_api = "responses"
env_key = "FOX_API_KEY"

在这份配置里：

● 默认 profile 是 chatgpt，日常直接输 codex 就走官方 OAuth，不需要每次手动指定
● 第三方 provider 没有 requires_openai_auth，它只认 FOX_API_KEY 这个环境变量，跟 OpenAI 的登录态完全解耦
● 没有设置 openai_base_url，内建 openai provider 保持纯净，指向官方

然后是环境变量和 alias：

# 在 .zshrc / .bashrc 中
export FOX_API_KEY="你的第三方中转key"

# 日常快捷入口
alias codexfox='codex --profile fox-api'
alias codexg='codex --profile chatgpt'

不要把第三方 key 命名成 OPENAI_API_KEY，也不要在 shell 里全局导出 OPENAI_BASE_URL 指向中转。这些残留变量会覆盖 Codex 的配置，profile 切换会直接失效。

处理 auth.json

如果你之前往 ~/.codex/auth.json 里塞过第三方 key，直接删掉这个文件，然后重新跑一次 codex login，让 ChatGPT OAuth 生成一份干净的缓存。第三方 provider 的 key 只通过环境变量读取，不经过 auth.json。

如果你在意安全性，还可以把凭证缓存切到系统 keyring：

cli_auth_credentials_store = "keyring"

日常使用

配置完之后日常使用很简单：

# 平时用 ChatGPT OAuth 额度
codex "帮我重构这个函数"

# 额度不够了，切第三方中转
codexfox "帮我重构这个函数"

codex 走官方，codexfox 走中转。不需要手动清环境变量，不需要删 auth 缓存，不需要记住"我现在到底是什么状态"。后续如果你还想加更多 provider，继续沿用同一套原则：新的 profile，新的 provider，新的 env_key，不碰 openai。

其他的常见误区

祝大家蹬 Codex 蹬得愉快！

4 个帖子 - 3 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: 时歌)

gpt plus 现在怎么用这么快

奥特曼是不是给我们降额度了，我怎么感觉现在还没有以前的1/3额度啊，五小时一会儿就没了，这样搞，我得再买三个号才够用啊。

7 个帖子 - 6 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: Humpy)

汐洛日常4.10-无语住了

9 个帖子 - 7 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: 浅羽暮桐)

头一次用cursor就被嘎嘎了？

各位佬，我头一次用cursor,怎么加载不到模型呢？也开启了TUN模式全局了啊。
请各位指点一下；另外问一下有没有办法不开TUN 模式 用这个玩意的方法？

5 个帖子 - 3 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: 贩卖郎)

想把pdf格式试卷题目像纸质一样方便标记做题+做笔记，在win端或者安卓平板端

请问有没有好的解决方案
或者ai时代了，有没有必要折腾一下把题目自己弄个分类题库，建个错题集这种，同求现成解决方案

2 个帖子 - 2 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: montillo10)

智普的老套餐可以转让吗？

有人说续费有二维码支付，也有人续费绑定微信支付宝无法转让（重新开就不是老套餐了）

1 个帖子 - 1 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: miaoxiansheng)

提问：哪个模型对视频与书籍学习的能力好一点

我最近有想做一个就是把一系列专业书籍都放入一个坑中，然后对ai进行提问判断对错以及找出所在的出处，比如视频的几分几秒，书本的第几页，让学生多翻翻书算是。对于视频来说，画面内容转化为文字，会不会损失太多信息，你们觉得呢？

1 个帖子 - 1 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: BrK)

快科技报道：再夺全球第一！百度伐谋Agent 2.0登顶MLE-Bench，号称打败opus 4.6快科技

再夺全球第一！百度伐谋Agent 2.0登顶MLE-Bench

快科技4月10日消息，百度智能云的伐谋Agent 2.0又拿下一个世界级第一，在机器学习工程权威基准MLE-Bench上登顶，还刷新了最好成绩。这个评测是OpenAI主导设立的，里面有75个来自Kaggle的真实工

1 个帖子 - 1 位参与者

阅读完整话题

via LINUX DO - 最新话题 (author: Tony)

【福利】快三级了，发一个GPT的token（车已开走）

要升3级了 ，还差几个爱心，留下一个key给大伙应急，垃圾小鸡轻蹬 🫣
余额:900刀左右

CCSwitch链接：已经用了1B了，预计还剩65%；车门焊死，满头大汉不能容纳了 🫢 ，下次有机会再分享。
总结 （点击了解更多详细信息）
粘贴到浏览器地址栏即可开蹬； 🤣

15 个帖子 - 15 位参与者

阅读完整话题

via LINUX DO - 热门话题 (author: jlweb)

看到挺多人对自动化ai科研感兴趣，我来分享一点自己的经验

开场先叠个甲，CS PhD 在读，发过 CVPR、ICCV、ICML、NeurIPS等。Claude官方max订阅。ChatGPT pro订阅，以及Gemini Ultra。
首先，现在 AI 写论文这件事已经非常成熟了。如果你只是写一些不需要任何实验的论文，我觉得它是完全可以胜任的，甚至它会写得比你还好，只不过需要一些 Harness 以及skill来适配你的工作流。

重新编辑把所有内容放到主楼层了。

但是我现在想讨论的是 Deep Learning 方向的科研任务。AI 是否能完整地解决 Deep Learning 的任务，主要分为以下几个过程：

1. 文献调研
2. 确定 Baseline
3. 确定 Idea
4. 写代码跑实验（实现 Idea）
5. 分析实验
6. 写论文

我真正尝试了几次，自己也搭了多套系统，纯skill方式，agent方式，魔改omc/omcodex等，都会发现最起码到目前为止，它还是没有办法完全自由推进。过程中确实会有一些让人 Amazing 的点，但更多的时候，它还是会在一个地方陷进去打转。
先说模型使用的问题，如果你想拥有最好的性能，三家模型肯定都是要用的。因为首先它们擅长的侧重点不同，其次，多元模型交叉可以互相 review。

这种情况下是防止幻觉以及提升能力最好的办法，类似于只要写过代码都知道，ensemble 是最无痛体验的最好方式。

其次，关于文献调研。

首先，AI 的文献调研能力一定是比人强的。我发现找调研（survey）这个过程中有很多值得探索的点，比如大模型是怎么读内容的：是让它自己通过 Web Search 读原文，还是你给它下载好 PDF 之后再喂给它读？以及是直接读PDF还是转markdown在读，这里面有很大的探索空间，也就是怎么把这个流程做到最稳定、最可用。

另外我发现，如果让它读一些论文，因为论文动辄三四十页，它其实会“偷懒”，只读前三页。但事实上，也不需要把一篇 PDF 完整地读完，因为里面很多信息是你只在特定时候才需要的。

比如说：

1. 比对结果的时候，你才需要看实验结果。
2. 在最开始，你可能只需要看一个摘要和引言（introduction），就可以判断它到底能不能被你用到。

另外发现最核心的问题是，针对一个点不断翻找、搜论文的时候，系统一定能搜到很好的论文并基于此提出 idea。但我当时考虑的流程是：

1. 首先会提出很多 idea。
2. 然后交叉 review，看哪个 idea 更好。
3. 确定这个 idea 后，再出发去看看有没有润色、打磨的点，以及它的 novelty 够不够。

在这个过程中，基于idea搜论文最大的问题是找到的文献太多了。所以按严格标准来算，你的所有 idea 都没有 novelty。但事实上，这些 idea 可能已经比绝大多数 CVPR 的方法更有新意了。

所以这个评判标准很难界定，而且受模型影响很大。

如果让他确定 Idea 以后从零开始写代码的话，效果一定会很差，这个毋庸置疑。我把这个放在最先，希望大家不要在上面浪费时间。如果你看到开源项目连这点都没有考虑的话，可以直接放弃它，它是不可能好用的。或者最起码，它不可能帮你发出一篇实验能复现、没有任何幻觉造假的 Top Conference 论文。

所以我们一定要找到一个 Baseline。当然，最简单的方式是你已经确定了研究方向和 Baseline，然后基于它去修改，这样就可以跳过这一步。

基于 Baseline 的话，就到了我们的复现环节。复现 Baseline 的主要意义在于：既然 AI 跑这些任务很容易，我们可以简单复现一下 Baseline 的结果，方便观察我们的 Idea 是不是真的 Work。

复现过程中需要安装环境和下载数据集，这里其实有蛮多坑的：

1. 网络连接不稳定：尤其是服务器在国内的话，连接各种资源非常不稳定。
2. 缺乏监控机制：它毕竟是大语言模型驱动的。比如它去下载一个数据集，如果没有监控，可能第一秒就挂掉了，但没有人管它。
3. 进程阻塞：装环境的时候如果报错就会卡住。

我当时觉得这些任务都应该交给 Sub-agent，或者通过 exec 调用。我不想让它在主线程运行，一方面是在主线程会影响上下文，另一方面是会让我卡在前台等待，而这明明是可以并行处理的。

因此我加了很多监控机制。我考虑过用 Python 写一些 watchdog，或者是加一些心跳轮询之类的机制，但是都不是很 work。

尤其是叠加了 SSH 服务器、给服务器配代理这些操作，以及服务器上可能有数据集不需要下载，但是要验证数据集完整性等问题，导致这件事变得非常 tricky。

因此，我目前也没有想到能完美解决这件事的方式。它可能有能力帮你全做完，但用的不一定是你想要的方式。比如：服务器上其实已有这个数据集，它却给你重新下载一套
但是这个是针对全自动化的。如果你自己已经下好，并且能告诉它路径的话，它其实可以避免这个问题。

Idea 实现以后，深度学习实验最大的问题就是你如何判断这个实验是否值得跑，以及它是否真的在运行。

大模型遇到的最大问题是：代码改好跑起来后，系统就一直在等，以为它已经正常运行了，可能第一秒就挂了。这个倒是有办法解决，但更大的问题在于：

1. GPU 利用率不高：这需要单独处理。
2. Loss 直接 NAN：这也得及时处理。

所以这些细节都是一个完善的科研系统必须要考虑的事情。必须让 GPU 得到最大的利用，并且在实验出现明显不行的信号时，第一时间进行处理。
3. 异常信号处理：或者还有一些情况，就是 Loss 可能没有出现 NaN，但是已经有一些明显的信号表明这个实验继续下去没有意义。由于 GPU 资源是一件很昂贵的事情，所以我们当然希望这种情况也能得到处理。

另外还有一个比较重要的，是多种模型之间如何交互的问题：到底是用 MCP、Exec 还是别的方式？

目前我自己的感受如下：

1. MCP 是一定不能考虑的方式，最垃圾的方式。
2. 最好区分是一次执行的任务还是多轮执行的任务
(a) 需要上下文的，可以通过 T-Max 开 Panel，让他们可以实时交互
(b) 一次执行Exec即可。

写到这儿突然发现，忘了说一个很重要的问题：多个模型到底如何交互？
目前看下来，因为前面也提到了一定要运用多个模型的能力，主要的使用方式可能有两种：

1. EXEC。
2. 让他们能主动交互的 tmux 开 panel。

第一种方式用来最简单的review，比如同时10个idea，10个并行exec命令review idea。第二种方式可以实现主的调度器给任何的 session 发信息，并且可以追问，保持上下文。

还有就是上下文管理的问题。我花了很多时间来尝试，能不能让我的每一个 session 都有我想要让它有的上下文。

但我发现目前来看，不知道是我还没调教好，还是确实比较困难，效果不是特别好。但我还是会尽量让它干净一点，所以主调度其实不做任何事情。
因此参考 Harness Engineering，我主要做的改进如下：

1. 优化 Session 交互与状态记录
不管怎么开启 Session 都方便交互，系统会记录当前的进度、具体做到哪里，以及是否存在活跃的 Task，防止开了新 Session 以后，甚至不知道有 GPU 任务已经在跑。
2. 规范 Agent 间的交付流程
不同的 Agent 之间会有明确的输入输出格式，并且通过在磁盘上读文件的方式来完成他们的输入。

因为主要是分享自己用的过程中的一些感受，还没做好写一个教程的准备。毕竟自己也是初步的探索，所以就是基本想到哪儿说到哪儿。

整篇帖子由 Typeless 完成输入。

38 个帖子 - 13 位参与者

阅读完整话题

via LINUX DO - 热门话题 (author: NeverMore)

美国要给中国要拔网线了

美国考虑禁止中国三大电信公司连接美国网络，并禁止运营数据中心

美国联邦通信委员会（FCC）周四表示，根据初步得出的结论，将以危害国家安全为由，禁止美国和其他通信运营商与被列入美国受限清单的中国移动、中国电信和中国联通等三大中国电信公司进行互连。

他们也考虑禁止这些上述电信公司在美国境内运营数据中心，以及将上述禁令延伸至受限清单内部分企业的附属公司。也将禁止通信运营商与安装了华为和中兴通讯设备的公司进行通信互连。

美国联邦通信委员会将于 4月30日的会议上就上述提议进行投票。

消息来源
https://docs.fcc.gov/public/attachments/DOC-420715A1.pdf

豆包解读

70 个帖子 - 63 位参与者

阅读完整话题

via LINUX DO - 热门话题 (author: 隔壁王叔叔)