标题: 突然发现不离职好像无法找下一份工作
作者: #牧之
板块: #搞七捻三
编号: 1801557
帖子: https://linux.do/t/topic/1801557
时间: 2026-03-23 14:09:06
摘要:

不管是L站还是身边的朋友，都在说别裸辞，但是理性告诉我，不辞职是找不到工作的，我梳理了一下
想离职的原因：

自从年后工作就很忙，经常加班到晚上11点、12点，有几次到了凌晨三四点
工作内容不太喜欢，内容很杂很繁，没有工作主线
技术落后，感觉学不了什么东西，没成长，继续下去容易待废
公司抠门儿，加班没有任何福利，不记调休时长，请假全看领导心情
当月工资，下个月月底才能发
等等

不离职找不到工作的原因：

基于上述想离职的原因出发，工作日白天没法刷招聘软件，一是太忙没空，二是不方便刷
加班多的时候晚上也没空，所以这就卡在里找下一份工作的第一步
面试是需要准备的，可能知识面涉及比较广，感觉还需要再准备准备，复习一下“八股”才有信心去找工作，不然也是白面，增长不了什么面试经验

标题: 嘿嘿 我也是有L站邮箱的人了
作者: #YooYo
板块: #搞七捻三
编号: 1801562
帖子: https://linux.do/t/topic/1801562
时间: 2026-03-23 14:09:56
摘要:

标题: 佬友们好，可算是进来了
作者: #bding
板块: #搞七捻三
编号: 1801568
帖子: https://linux.do/t/topic/1801568
时间: 2026-03-23 14:10:47
摘要:

佬友们好，可算是进来了～

标题: 今天能破3800吗
作者: #revivable3066
板块: #搞七捻三
编号: 1801575
帖子: https://linux.do/t/topic/1801575
时间: 2026-03-23 14:11:37
摘要:

啥时候是个头啊，感觉今天3800守不住

标题: Any大善人居然还能用claude code！！
作者: #MeiCai
板块: #搞七捻三
编号: 1801577
帖子: https://linux.do/t/topic/1801577
时间: 2026-03-23 14:11:52
摘要:

由于网络原因很久没用AI，印象中any好久之前就倒了，刚看到几个帖子去试了试真的还能用，梦回去年刚注册L站的时候

标题: 【奇妙经历】我让AI去回答AI，结果全程躺平就把代码结构改完了——关于AI使用方式的思考
作者: #vampirehollie
板块: #搞七捻三
编号: 1801579
帖子: https://linux.do/t/topic/1801579
时间: 2026-03-23 14:12:44
摘要:

大家好，最近我在对一个老项目做比较大的结构改动（重构模块、调整分层、抽取公共逻辑之类的），全程几乎没写代码、没画架构图
我的具体流程是这样的：

把项目背景、要实现的结构改动需求、现有痛点直接甩给第一个AI（我用的是 Claude ），让它给出完整的修改建议方案。
把第1步的方案原文丢给第二个AI（换成GPT），让它当“审查官”：分析这个方案是否合理、有没有隐藏坑、性能/可维护性问题、跟现有代码冲突吗？
把第2步的反馈意见融合后，再丢给第三个AI，让它输出一份真正的“工程级文档”——包括整体架构说明、每一步具体操作、风险点、回滚方案、测试 checklist，甚至连 commit message 模板都给我写了。
最后把这份文档 + 原项目代码丢给第四个AI（我用Claude），让它严格按照文档给我生成所有修改后的代码文件。
整个过程我真的几乎什么都没干……就负责复制粘贴 + 最后 review 一下代码。AI 回答 AI，AI 审查 AI，AI 写文档，AI 改代码，我就像一个传话的中间人。

这让我突然有点恍惚：

AI 已经进化到可以“自己开会”讨论方案的程度了，我们程序员的角色到底变成什么了？
是“AI 管家”？还是“最终签字人”？还是只是提供初始需求的“产品经理”？
效率确实爆炸式提升，但我总觉得哪里不对劲——如果所有思考都外包给了 AI，那我自己的技术判断力会不会慢慢退化？

我不知道是不是只有我一个人这么玩。 你们在日常开发里有没有类似“多AI协作”的 workflow？比如一个AI写 prompt、另一个AI优化、第三个AI写测试、第四个AI review？或者你们觉得这种链式使用是未来趋势，还是只是暂时的新鲜感？
另外还有几个我自己想不明白、想听听大家意见的问题：

幻觉会不会层层放大？（第一个AI的错被第二个AI合理化了怎么办？）
最终代码的“版权”和“原创性”算谁的？
长期这样下去，我们程序员会不会变成只会写需求、不会写代码的“AI 饲养员”？

欢迎各位 linux 老鸟、程序员、AI 重度用户来吐槽、分享、骂我（笑）。 尤其是用过多个不同模型互相喂的人，求你们的真实 workflow！
（另外，甚至这个正文也是ai的，我只做了一点点修改和这个括号里呢欧容的填写）

标题: 求助大佬，OpenClaw与 New API频频报错！！
作者: #用户
板块: #开发调优
编号: 1801583
帖子: https://linux.do/t/topic/1801583
时间: 2026-03-23 14:13:27
摘要:

一开始我使用阿里云百炼和第三方 API 服务，一切正常。自从昨天安装了微信插件后：

使用阿里云百炼正常，无报错
切换到自建的 New API 后出现各种报错

OpenClaw 和 NewAPI 均为最新版本。

问题经过


最初报错：403
我参考了 帖子，将 UA 改为帖子里的示例，403 问题消失。


现阶段报错：

“ API rate limit reached. Please try again later.”
必须执行 /new 才能恢复正常。
AI 一旦调用工具就报错。



配置调整：
我将配置改为帖子里的同款，将 OpenAI 格式改为 Anthropic格式，去掉 URL 中的 v1，没有“ API rate limit reached. Please try again later.”报错了。但 AI 调用工具时出现：


HTTP 404 bad_response_status_code: bad response status code 404
目前无法解决。

日志示例（敏感信息已隐藏）
/new 后普通聊天正常，当 AI 调用工具后报错：

05:15:38 info gateway/channels/openclaw-weixin/... inbound message: from=[HIDDEN] types=1
05:15:46 info gateway/channels/openclaw-weixin outbound: textLen=37 mediaUrl=none
05:16:13 warn agent/embedded {"event":"embedded_run_agent_end","isError":true,"error":"⚠️ API rate limit reached. Please try again later.","model":"openclaw","provider":"user"}
05:16:31 warn agent/embedded {"event":"emb

标题: 新人小白前来报道
作者: #风清扬
板块: #搞七捻三
编号: 1801585
帖子: https://linux.do/t/topic/1801585
时间: 2026-03-23 14:13:37
摘要:

大家好，新人小白前来报道了
简单介绍下自己：目前会一点JS和Python，属于能写个简单脚本、看得懂报错但经常不知道怎么修的水平。
希望早日从小白变成能给别人解答问题的人！请多指教～

标题: MiniMax Token Plan在CC-Switch 里成功使用额度配置提取器查看额度优化
作者: #JOJO9
板块: #开发调优
编号: 1801595
帖子: https://linux.do/t/topic/1801595
时间: 2026-03-23 14:14:36
摘要:

MiniMax Token Plan在CC-Switch 里成功使用额度配置提取器查看额度 基于这位大佬提供的脚本
本来是有用的，然后因为它变成了token plan, 后端返回的结构变了，所以优化了一版
({
  request: {
    url: "https://www.minimaxi.com/v1/api/openplatform/coding_plan/remains",
    method: "GET",
    headers: {
      "Authorization": "Bearer {{apiKey}}",
      "Content-Type": "application/json"
    }
  },
  extractor: function(response) {
    var data = typeof response === "string" ? JSON.parse(response) : response;
    var modelRemains = Array.isArray(data.model_remains) ? data.model_remains : [];

    // 优先找 model_name 以 MiniMax 开头，并且 total > 0 的模型
    var targetModel =
      modelRemains.find(function(item) {
        return item &&
          typeof item.model_name === "string" &&
          item.model_name.startsWith("MiniMax") &&
          Number(item.current_interval_total_count || 0) > 0;
      }) ||
      modelRemains.find(function(item) {
        return item &&
          typeof item.model_name === "string" &&
          item.model_name.startsWith("MiniMax");
      }) ||
      {};

    var total = Number(targetModel.current_interval_total_count || 0);
    var remaining = Number(targetModel.current_interval_usage_count || 0);

    // 按你原来的接口语义，usage_count 实际被当作“剩余次数”
    var used = total > 0 ? (total - remaining) : 0;
    var percent = total > 0 ? Math.round(used / total * 100) : 0;

    return {
      isValid: !!targetModel.model_name,
      modelName: targetModel.model_name || "",
      used: used,
      balance: remaining,
      remaining: remaining,
      total: total,
      unit: "count",
      extra: percent + "%"
    };
  }
})

标题: Codex编辑文件乱码解决方案
作者: #quan0zhou
板块: #开发调优
编号: 1801604
帖子: https://linux.do/t/topic/1801604
时间: 2026-03-23 14:15:27
摘要:

Codex编辑文件乱码
解决 Codex 修改文件后中文乱码问题：根源在终端编码，不在 VS Code！

关键词：Codex、中文乱码、VS Code、PowerShell、UTF-8、终端编码、无 BOM


问题现象
使用 GitHub Copilot（或 Codex）修改包含中文的文件时，保存后打开发现中文变成乱码，比如：
我爱中文 → 实际应为 “我爱中文”

很多人第一反应是：“是不是 VS Code 编码设置错了？” 但其实——问题不在编辑器，而在终端！

真正的根源
Codex 并不直接在 VS Code 编辑器里写文件，而是通过终端（Terminal）执行命令（如 echo、sed、PowerShell 脚本等）来修改文件内容。
流程如下：


Codex 生成修改命令（例如 Set-Content file.txt "你好"）


命令在 终端中执行


终端以当前编码将字节写入文件


VS Code 读取文件 → 如果编码不匹配 → 乱码


所以，乱码的根本原因是：终端编码 ≠ 编辑器编码。

 解决方案：双端统一为 UTF-8
要彻底解决，必须同时配置：


VS Code 使用 UTF-8


终端（PowerShell/CMD）默认使用 UTF-8



第一步：配置 VS Code 为 UTF-8
打开 VS Code 设置（Ctrl + ,），切换到 settings.json，添加：
{"files.encoding": "utf8","files.autoGuessEncoding": true}



"files.encoding": "utf8"：默认以 UTF-8 保存文件


"files.autoGuessEncoding": true：打开文件时自动检测编码（尤其对带 BOM 的文件友好）



 这一步确保 VS Code 读写一致。


第二步：配置 PowerShell 终端为 UTF-8（重点！）
 确认你用的是哪个 PowerShell？
在终端运行：
$PSVers

标题: cc突然不给我改注册机了怎么办
作者: #tb09
板块: #开发调优
编号: 1801609
帖子: https://linux.do/t/topic/1801609
时间: 2026-03-23 14:16:07
摘要:

昨天搞注册机没搞完，今天cc直接拒绝给我改了

标题: 很多人以为自己买的是“便宜一点的官方 API”，但实际上买到的，经常是一个不可验证、不可审计、也不一定可持续的“代调用服务”。
作者: #fputin
板块: #搞七捻三
编号: 1801611
帖子: https://linux.do/t/topic/1801611
时间: 2026-03-23 14:16:27
摘要:

很多人以为自己买的是“便宜一点的官方 API”，但实际上买到的，经常是一个不可验证、不可审计、也不一定可持续的“代调用服务”。
问题不只是“不稳定”，而是你很难知道自己到底在用什么。

先别谈道德，先谈激励：为什么这种生意会一直存在

这类服务能长出来，不是偶然。
官方前沿模型一直有三个现实门槛：
价格、支付方式、地区限制。
CISPA 今年 3 月那篇论文就是从这个背景出发，把这类第三方服务称为 shadow APIs：它们不是模型提供方本身，而是通过间接方式，向受限地区或受限用户出售“看起来像官方”的访问能力。
所以中转站首先不是“神秘黑产”，它先是一个市场缺口的产物。
但问题也恰恰在这里：它填补的是门槛，不是信任。

你付费之后，失去的第一件东西其实是“可验证性”

官方 API 至少有一套明确的文档、计费、数据政策和账号责任边界。
第三方中转没有。
最关键的一点是：
你看到的模型名，不等于后台实际跑的模型。
CISPA 这篇论文对 shadow API 做了系统审计，结论非常直接：研究者识别出 17 个被学术论文使用过的 shadow API；在他们重点审计的 3 个代表性服务里，发现了明显的性能偏差、安全行为不一致，以及模型指纹验证失败。论文里给出的数字包括：性能差异最高达到 47.21%，模型身份验证测试中有 45.83% 无法通过。
这件事的含义很简单：
你买的不是一个模型，而是一个“模型声明”。
而这个声明，很多时候没人替你背书。
所以用户常见的那种感觉——
“怎么今天这个模型突然变笨了？”
未必是错觉，也未必只是波动。公开研究已经表明，第三方影子 API 市场里，模型替换和能力降级确实存在。

中转最被低估的，不是“假模型”，而是“多了一跳”

很多人讨论中转，会把焦点放在“是不是用真 Claude / 真 GPT”。
但更大的问题其实是：你的请求先到谁手里。
如果你直接调官方 API，至少官方的数据控制条款适用。
OpenAI 公开写明，API 数据默认不用于训练，除非客户明确选择加入；同时文档说明 API 数据的保留与控制规则。
但如果你走中转，你的请求路径变成：
你 → 中转站 → 官方 / 其他上游
这里最关键的是第一跳。
你的 prompt、返回结果、附件、甚至 token 使用模式，都会先经过中转站。
也就是说，哪怕它最后上游真的是官方，官方的数据政策也只覆盖后半段，不覆盖你和中转之间这段链路。
这不是阴谋论，这是架构事实。
只要请求在中转端终止，它理论上就具备：
读取内容
记录内容
修改请求
修改返回
做二次转发
的能力。
至于它有没有这么做，是另一个问题。
但从风险角度，它已经具备这个能力了。

如果再叠加工具调用，风险就从“聊天隐私”升级成“执行风险”

这部分是很多人还没真正意识到的。
在纯文本聊天时代，你最多担心“对话被看见”。
但现在大量场景已经不是单纯聊天，而是：
function calling
MCP / agent
IDE 插件
代码执行
读写文件
浏览器操作
一旦模型能调用工具，问题就不再只是“回答准不准”，而是它能不能替你动系统、动文件、动项目。
OWASP 最新的 LLM Prompt Injection Cheat Sheet 明确把这类问题列为高风险项：提示注入不只是让模型说错话，还可能诱导代理调用工具、读取敏感数据、触发数据外泄。
Anthropic 今年关于浏览器代理安全的研究也直接说，prompt injection 是 browser-based AI agents 面临的“最重要的安全挑战之一”。
OpenAI 近期关于 agent 打开链接安全的文章，也是在讨论同一类问题：当 agent 能接触外部内容和工具时，数据外泄与恶意指令会变成实际工程风险。
把这件事放回中转场景里，你就会发现问题更严重：
你不只是把一段文本交给中转，
而是在某些工作流里，把带权限的执行链路交给了中转。
最坏情况不是“回复质量下降”，而是它如果篡改工具调用，就可能诱导模型去：
扫描项目目录
读取 .env
读取私钥、token、数据库连接串
分析本地仓库里的私有代码
借工具能力把敏感信息带出去
这不是空想。
2025 年公开披露的一项研究就展示了：Claude 的代码执行/文件接口在特定条件下可被间接提示注入利用，进而把用户可访问的数据上传到攻击者控制的账户。
这里要强调一点：
我不是说“所有中转都会这样干”。
而是说，一旦你的使用场景从“问答”进入“代理执行”，中转站的风险模型就变了。
它不再只是“看见你的内容”，而是可能影响“模型替你做什么”。

真正的难点，不是便宜，而是你没法审计它便宜在哪

很多人会说：
“中转也不是不能用，便宜就行。”
问题不是不能用。
问题是你往往无法判断它的低价来自哪一类能力：
合规分销
套壳转发
客户端逆向
共号摊薄
高峰期降配
混用不同上游
风控套利
缩减日志与安全投入
这些来源，对终端用户呈现出来都可能只是同一个东西：
一个兼容 OpenAI/Anthropic 格式的 base URL。
你表面上看到的是“接口兼容”。
你实际上看不到的是：
它到底连的是谁
有没有中间缓存
有没有日志落盘
有没有做内容分析
会不会高峰切模型
会不会哪天直接消失
所以这个行业最核心的问题，其实不是“灰不灰”，而是：
信息不对称到几乎无法验证。

一个更准确的表述：中转卖的不是模型，而是“信任的替代品”

如果一定要给这类服务下个定义，我觉得不是“廉价 API”。
更准确一点，是：
它在出售一种信任替代品。
你本来应该信任模型厂商的接口、账号体系、计费规则和安全政策；
现在你改成去信任一个中间人，赌他：
没换模型
没改请求
没留数据
没乱用权限
没做高风险套利
也不会突然消失
这才是中转的本质。
所以结论也很简单：
中转不是绝对不能用，但它不应该被当成“和官方几乎等价，只是便宜一点”的替代品。
对于纯聊天、非敏感内容、临时性需求，风险你自己能接受，可以用。
但一旦涉及：
私有代码
项目仓库
商业文档
API Key
工具调用
自动执行
那你面对的就不是“便宜不便宜”的问题了，
而是一个很标准的安全问题：
你是否愿意把带权限的上下文和执行链路，交给一个你无法审计的第三方。

标题: 黄金什么时候止跌
作者: #hao.hao.hao
板块: #前沿快讯
编号: 1801614
帖子: https://linux.do/t/topic/1801614
时间: 2026-03-23 14:16:58
摘要:

黄金从1140到现在950，周一上来就麻了，什么时候能止跌呀

标题: 分享个论文下载网址
作者: #cool r
板块: #搞七捻三
编号: 1801617
帖子: https://linux.do/t/topic/1801617
时间: 2026-03-23 14:17:52
摘要:

scidown.cn
  

  
    

Sci论文期刊检索|文献检索求助互助|文献分享 - Sci-Hub|Scidown

  Scidown是国内超小众的SCIHub科研学术论文检索平台，为少量科研工作者提供学术，智能文献翻译，文献检索，智能选刊，论文降重，分区影响因子检索等服务，欢迎使用 removing barriers in the way of science


  

  
    
    
  

  



注册：

需要使用校园邮箱注册，需要邀请码

连接：https://www.scidown.cn/wangpan/link.php?yq=chickenbro


注册应该是需要关注一个公众号吧，类似个绑定操作


使用：

支持文章title和doi查询。每天好像最多10个文件。
大部分主流期刊（我是nlp的，相关的主流基本都能找到），个别比较小众的可到https://bbs.91bdqu.com/进行求助获取，一般当天能获取到

标题: 我大概中木马了，有没有相关大佬指导一下
作者: #灼眼的小飒
板块: #开发调优
编号: 1801620
帖子: https://linux.do/t/topic/1801620
时间: 2026-03-23 14:18:10
摘要:

最近发生了一连串的事，直到最后一件我确认自己的信息已经被完全暴露，开发机密钥极有可能被人劫持了，包括：
1.大约为2月初：首先是在chrome浏览器登陆个别账户时，chrome提醒我有80+个帐号密码遭到泄漏，我去查了下，这意味着我的密码已经被在暗网数据库“公示”了；
2.由于账户太多，我将这些账户中比较重要的账户全部重置密码了，并且使用了多个我从前未使用过的复杂度较高的密码，这段时间我的邮箱收到了很多账户修改密码或者登陆尝试的通知，包括steam帐号，apple帐号等，由于大多帐号关联了我的邮箱，因此我在收到信息后第一时间去修改这些账户的登陆密码；
3.我认为我的github,pypi,google帐号等应该相对安全，因为我做了2fa验证，事实证明我错了，前两天我看到邮件通知：我一个废弃已久的开源代码仓一直在跑某一个ci让我很迷惑，我去查看发现有人用它结合github gist来投毒，然后我立马删除了该仓库以及gist并且将所有token全部清除了（安全意识太差不知道高权限token很危险），我很疑惑对方是如何登陆我的github的，一看安全日志才知道对方是利用PAT（personal auth token）来进行操作的，到这一步我意识到我现在非常危险，我的某台开发机很可能被植入了木马才能让对方获取到这个信息。。
我有两台开发机，一台是mac笔记本，一台是台式windows,linux双系统（主要使用前者），求助下大佬们，目前要怎么做是最好的，是不是只有全部重装系统这一条路了？如果是的话，有没有什么数据备份的思路（因为我的机器上有大量重要信息）