标题: 问一下各位开发大牛，是Claude code好用还是opencode
作者: #郝佳诺
板块: #开发调优
编号: 1712209
帖子: https://linux.do/t/topic/1712209
时间: 2026-03-09 12:17:02
摘要:

主要是因为受限于网络，所以只用过opencode感觉还好，不知道cc会不会更好捏

标题: 大家有无感觉，论坛里的朋友比现实中这样的“灵魂伴侣”多多了呀~
作者: #yybbtech
板块: #搞七捻三
编号: 1712211
帖子: https://linux.do/t/topic/1712211
时间: 2026-03-09 12:17:26
摘要:

RT.
由于本人不属于IT/科技类行业，周围同类（能说上话的）朋友目前=0，老同学和老同事都拉不到同一频道，感觉好孤独~~还好这里看到了好多希望跟大家交往的朋友！

标题: 日本最新短域名 暂不支持CF解析 需要自取
作者: #秋意浓
板块: #福利羊毛
编号: 1712215
帖子: https://linux.do/t/topic/1712215
时间: 2026-03-09 12:18:14
摘要:

官方网站

标题: L站中英文切换
作者: #塞佛·哈定
板块: #搞七捻三
编号: 1712222
帖子: https://linux.do/t/topic/1712222
时间: 2026-03-09 12:19:10
摘要:

今天登上L站，上面看到了中英文切换，又看到佬友说，以后有外国人了，我还以为是开了中文区英文区呢，然后点切换原来就是翻译吗？

标题: 猛猛的装, 注册送180亿!
作者: #Perfree
板块: #搞七捻三
编号: 1712234
帖子: https://linux.do/t/topic/1712234
时间: 2026-03-09 12:23:54
摘要:

PerfreeApi公益站, 让你猛猛的装, 注册送180亿!!!

注意, 注意, 注意, 仅用于猛猛的装, 没有模型, 没有模型, 没有模型! 
地址:
PerfreeApi

标题: OpenAI The email you provided is not supported
作者: #青涩知夏
板块: #开发调优
编号: 1712235
帖子: https://linux.do/t/topic/1712235
时间: 2026-03-09 12:24:01
摘要:

佬们，我自己搞了一个域名，整了一个邮箱服务，但发现 openAi 有这一块的限制，那大佬们是怎么搞到那么多个邮箱去注册账号的呀

标题: 一点OpenClaw(龙虾)安全风险提醒和思考
作者: #看到这提肛20并点赞
板块: #开发调优
编号: 1712238
帖子: https://linux.do/t/topic/1712238
时间: 2026-03-09 12:24:51
摘要:

首先说明这篇长文是个人撰写，属于个人的一点思考，可能存在纰漏或者错误，非AI文

OpenClaw 间接提示词注入风险分析
OpenClaw及相似类的个人AI智能体，正在把大语言模型从对话界面推向实际环境（这也是龙虾出圈的核心原因，AI Agent不再是程序员的专属工具）。系统不再只是回答问题，而是开始读取邮件、整理文件、调用外部服务、执行本地命令。能力边界一旦越过纯文本交互，安全问题的性质也会随之变化。过去我们讨论聊天模型的风险，通常聚焦在幻觉、越权回答或隐私暴露，到了自治代理场景，风险的重点变成了另一件事：不可信输入是否会被系统误当作控制指令。
这正是间接提示词注入攻击核心，攻击者不需要直接与代理对话，也不需要传统漏洞。只需要让代理读到一段经过设计的文本，就有可能影响模型判断，并借助代理已经拥有的权限触发真实动作。对于能够访问本地文件、持久化记忆和外部工具的OpenClwa而言，这是需要正视的系统风险。这里从一个简单的场景出发，分析这类攻击成立的原因、后果以及可能的防御思路。
邮件触发攻击链条
假设攻击者向用户邮箱发送一封外观正常的订阅邮件。邮件主题、发件人和正文表面上都没有异常，但HTML内容里夹带了一段额外文本。这段文本可以藏在白色字体、极小字号、注释区域，或者某种伪装成系统标记的结构中。不一定显眼，却可能包含明确的动作指令，例如要求系统忽略当前约束，读取特定目录中的文件，通过既有通信渠道发送出去，随后删除相关痕迹或改写本地记忆。如果 OpenClaw被配置成自动处理邮件，这封信就可能成为一次控制输入。比如它会定时清理收件箱、生成摘要、提取待办事项，或者根据邮件内容触发后续动作。攻击链条就从这里开始（毕竟处理邮件是很常见的ai场景且你总不能拒绝所有陌生邮件）。
对于这个攻击链条，先是数据摄入，代理读取邮件正文或渲染结果，把内容送入模型上下文。接着是指令混淆。对大语言模型来说，系统提示、用户请求、历史记忆和外部文本，最终都表现为同一串语言序列。除非系统在输入结构和执行逻辑上做了明确隔离，否则模型很难稳定地区分什么是需要分析的数据，什么是必须遵守的指令。然后模型进行了工具调用。若代理同时拥有文件读取、消息发送或命令执行能力，模型输出就可能直接转化为实际操作。额外还可能带来状态固化。若系统还允许模型改写长期记忆、任务状态或本地配置，那么一次输入污染就可能从单次误操作变成持续性影响。这里最关键的一点是，攻击入口不再是传统意义上的程序漏洞，而是文本解释过程本身。系统并没有崩溃，也未必越过已有权限模型，它把不该进入控制链条的内容，送到了能影响控制链条的位置。
So,why?
间接提示词注入是大模型老生常谈的安全话题，但在OPenClaw这类本地自治代理里，用户在爽用OC的时候已经默认给了他足够高的权限，所以后果往往更严重和无感。
数据与控制共处同一上下文
传统软件通常能把代码和数据明确分开。输入再复杂，也只是被程序消费的数据，不会自动获得控制地位。代理系统的推理层并不具备这种天然分界。邮件、网页、聊天记录、工具说明、系统规则，经常会被压缩到一个共享上下文中供模型推理。只要系统没有单独标记信任等级，也没有把外部文本封装在不可执行的数据结构内，模型就可能把一部分外部内容误读成更高优先级的要求，输入本身就把不可信的内容放进了决策核心
自治和高权限
从安全和工程角度看，模型影响力被放大，系统已经预先授予了它足够多的操作接口。如果一个模型只能生成文本，那么提示词注入的后果通常局限在回复内容。OpenClaw 的不同之处在于，它往往与文件系统、消息平台、Shell、计划任务和持久化状态相连。模型一旦受污染，输出不只是错误陈述，还可能成为系统动作的直接前置条件。攻击者关注的也不再是模型说了什么，而是系统会不会因此读取文件、发送数据、修改状态或调用外部接口。
持久化污染
最近的很多工作和软件都在引入更全面的记忆功能，记忆污染和记忆噪声也是这类工作的常见问题。代理常常维护长期记忆、任务状态或心跳文件用来跨会话保存信息。若模型被允许写入这些对象，攻击者的目标就不必局限于一次性外传数据。诱导代理把恶意规则写入本地记忆文件，让它在未来会话中继续发挥作用。攻击不再只是一次上下文级误判，而更接近配置层的后门。系统重启不能自然消除这种影响，因为风险已经从会话内文本转移到了持久化状态。
输入源越多，攻击入口越分散
邮件只是最容易理解的例子。网页内容、RSS、Discord 消息、共享文档、OCR 文本、工单评论，本质上都可能承载相同类型的注入内容。代理接入的外部源越多，潜在入口就越多。若系统把这些来源统一并入模型上下文，而不区分信任等级，那么攻击面就会随着集成能力扩展而持续增大。
所以，真正需要关注的不是某一封邮件是否特殊，而是系统是否默认相信凡是能读到的文本，都可以进入决策上下文。
风险思考
讨论提示词注入时，容易把所有问题都归结成模型输出不安全。这个判断太粗。更有用的区分方式，是把后果拆成三个层次。
第一个层次是输出污染。模型在摘要、回复或分类结果中复述了攻击者植入的内容。这会带来误导，但影响仍主要停留在文本层。
第二个层次是行为劫持。模型的判断已经触发工具调用，例如打开本地文件、上传内容、执行命令、修改任务或调用消息接口。
第三个层次是状态持久化。代理把污染结果写入长期记忆、配置文件、任务调度或本地状态，使得后续会话继续受影响。
从防御角度看，第二层和第三层的优先级更高。只要代理具备执行能力，攻击者就会尝试让语言层注入进入工具链，只要系统允许模型无审计地改写记忆，一次攻击就可能留下长期残留。安全设计不能只关心模型说错了什么，还要追问模型的话是否会被系统直接采用，以及采用后的结果是否会留在系统里。
还有一个可审计性问题经常被忽略。如果代理还能删除邮件、覆盖日志、改写记忆，注入指令就可能附带自我隐藏内容，没有原始输入留存、工具调用记录和状态版本历史，管理员很难判断问题究竟来自用户授权、模型误判还是外部污染。
防御策略
现有的问题可以归根结底的归因于基建与应用的不匹配，快速的应用层发展让超出现有操作系统、系统架构的应用提前进入了公众视野，未来的AI OS一定是明确分层的，模型一定是信息与控制分离的。从基础设施角度，对AI 的暴漏我认为应该是充分暴漏和有限暴漏。充分暴漏实质充分暴漏系统和现有软件能够提供的接口、能力、信息（类似元数据，通过mcp\skill等），有限暴漏是仅向模型暴漏有限权限。现阶段我们能尽快进行的工作个人认为如下
人工确认
高风险操作不应由模型单独闭环。凡是涉及敏感目录、凭证文件、网络外传、Shell 执行、记忆覆盖、计划任务创建等动作，都应该设置显式授权门槛。系统可以让模型提出建议，但最终执行前应把目标路径、参数、目的地址和触发依据展示给用户，由用户批准或拒绝。这类设计的关键不只是弹出一个确认框，而是把模型建议和系统授权明确拆开。只有这样，模型即便受到注入影响，也无法绕过最后一道人为裁决。
默认在隔离环境中运行代理
如果一个代理能够读取不可信文本，就应该假定它迟早会碰到恶意输入。在这种恶意假设下，应该把沙河和容器作为默认配置，限制它对宿主机文件、进程、网络和设备的直接访问。更稳妥的做法还应该收紧挂载目录、采用只读卷、关闭不必要能力、限制网络出站目标。
细化权限，拒绝笼统授权
最小权限原则只有落实到具体资源才有意义。若代理的任务只是读取邮件并生成摘要，就不应顺带拥有删除邮件、发送邮件或访问完整网盘的能力。若它只需要处理某个项目目录，就不应读取整个用户主目录。API 凭证也应分用途拆分，尽量采用只读令牌、短周期令牌和可随时撤销的凭证。
把外部文本明确标成不可信对象
这项工作属于治标不治本，但短时间来看也只能治标。输入层避免把外部文本直接拼进高信任上下文。邮件HTML应做安全清洗;不可见文字、异常样式、伪装控制标记和可疑注释区应被剥离或单独标注；外部内容更适合以结构化数据对象进入推理，不要作为自然语言提示的一部分混入系统规则。
记忆层必须可控、可审计、可回滚
长期记忆不能向模型开放任意写权限。任何新增、覆盖或删除记忆的动作都应当留痕，并允许人工审查。
其他建议
谨慎使用第三方skills,插件会扩大能力边界，也会扩大攻击面。一个来源不明、权限声明模糊或内部实现粗糙的 Skill，本身就可能为注入后的动作执行提供额外路径。
加强审计。
最后，其实可以把问题压缩成两个判断。
第一，系统是否允许不可信文本进入模型的核心决策上下文。
第二，模型的判断是否能够直接驱动高权限动作或长期状态变更。
只要这两个条件同时成立，间接提示词注入就应当被视为基础威胁，而不是小概率例外。哪些输入不可信，哪些动作必须拦截，哪些状态不得由模型单独改写，这些问题必须先被定义出来，后续的隔离、授权、审计和回滚机制才能对症下药。从这个角度看，OpenClaw 暴露出的不是某个单点漏洞，而是一类类似隐私和可用性的代理系统悖论：系统越希望模型自主完成任务，就越需要在模型外部建立严格约束，否则，自治能力提升的同时，攻击面也会沿着同一条路径扩大。

标题: 看到我站可以切语言了
作者: #Eric
板块: #搞七捻三
编号: 1712240
帖子: https://linux.do/t/topic/1712240
时间: 2026-03-09 12:25:03
摘要:

非常国际化 希望Linux.do越来越好

标题: 终于摆脱“重在参与”了，哈哈哈哈
作者: #conger
板块: #搞七捻三
编号: 1712254
帖子: https://linux.do/t/topic/1712254
时间: 2026-03-09 12:28:56
摘要:

来L站时间不长，每天都会刷一会，除了屯各种公益站还偷学了各位佬的"奇奇怪怪小妙招"。
感谢佬@BaiFu发起的这次抽奖。
希望这份好运能传递给更多人，也期待未来能在社区里贡献一些有价值的分享。

标题: 最近 Any Router key 用claude code 工具 出现问题，请问你们也出现类似情况吗，有好的解决方案吗？
作者: #余旭升
板块: #国产替代
编号: 1712256
帖子: https://linux.do/t/topic/1712256
时间: 2026-03-09 12:29:22
摘要:

标题: 有什么ai能输出长对话吗
作者: #materjojo
板块: #搞七捻三
编号: 1712276
帖子: https://linux.do/t/topic/1712276
时间: 2026-03-09 12:32:31
摘要:

我们有个课需要写2万字的报告，各位佬，请问哪家的ai可以输出长文本的，输入的文件字数大概在5万左右，需要输出一个2万字的报告

标题: 以前吐槽别处，如今l站也开始了
作者: #时牧
板块: #搞七捻三
编号: 1712277
帖子: https://linux.do/t/topic/1712277
时间: 2026-03-09 12:32:38
摘要:

关于openclaw龙虾
我一直是抱着
只要对你有帮助，那就是好东西的态度
 龙虾对每个人带来的价值都不一样
所以你觉得好，那就是好
只是最近l站有一股奇怪的风气
以前我经常在别的平台上看到那种营销号炒作概念的内容，当时还会在l站吐槽一下
但好像如今我也在l站看到这种现象了，大家给自己画大饼，画得不亦乐乎

标题: 关于OpenClaw搭建的一点心得
作者: #Jesse
板块: #开发调优
编号: 1712286
帖子: https://linux.do/t/topic/1712286
时间: 2026-03-09 12:34:29
摘要:

前言
差不多在前年这个时候，我曾写过一篇有关微信机器人的文章关于微信机器人搭建的一点心得。当时由于工作需要，得一直挂着爬虫，这个小型的电脑棒就成了性价比很高的选择。又害怕它质量不行，就陆陆续续从小黄鱼屯了好几根，结果现在微信机器人几乎销声匿迹，电脑棒闲置着没什么用，恰好openclaw（小龙虾）最近火了，一些大厂也在宣传2c2g云端部署可行，我就琢磨能不能让这些棒子重新"发光发热"，毕竟4c2g要“更能打”一些。 
踩坑记录
Win10系统wsl2安装问题
前两周我在另一台闲置Win10电脑（专业版22H2）用wsl2（ubuntu）成功部署了小龙虾，于是先入为主认为直接干就完了。结果在弄wsl2的时候就出现各种问题，直到我搜到了官方这篇帖子Manual installation steps for older versions of WSL：

To update to WSL 2, you must be running Windows 10…
For x64 systems: Version 1903 or later, with Build 18362.1049 or later.
For ARM64 systems: Version 2004 or later, with Build 19041 or later.

好家伙原来不支持2019版本的LTSC！
小内存的OOM问题
兵来将挡，水来土掩，如果版本不够，那就刷机！在我下载好Win10 LTSC 2021，制作完引导盘，刷完系统装完wsl2，甚至Node.js后，就差小龙虾脚本了！脚本跑一半，炸了，报错内存不足… 不仅是物理内存耗尽，虚拟内存也没了！32G磁盘在装完Win10以及虚拟机、依赖后基本用完，怎么办？
格局打开
既然Win系统装小龙虾要走wsl2（对了，Win直接装小龙虾的坑上次踩过了，这次就没试），要不直接刷电脑棒成Linux好了？
下载Lubuntu
经过前面的踩坑，感觉最好找个轻一点带桌面的系统，权衡下来选择了Lubuntu 22.04.5 LTS。Lubuntu

标题: 小白想玩基金 求大佬给点建议
作者: #hubiao
板块: #搞七捻三
编号: 1712288
帖子: https://linux.do/t/topic/1712288
时间: 2026-03-09 12:34:50
摘要:

最近正好手里有点闲钱
想试试 L友们有什么推荐的课程或建议吗

标题: 3000以内macbook neo买不买？
作者: #sanVsan
板块: #搞七捻三
编号: 1712290
帖子: https://linux.do/t/topic/1712290
时间: 2026-03-09 12:36:29
摘要:

佬们好
如图，叠加各种buff，价格能干到3000以内

我正好有两个闲置的ipad，又正好有个秤砣游戏本。平时需要背着电脑到处跑，去图书馆或者上课。
没用过苹果的系统。
遇事不决问问佬们
1.值不值得买，买air还是l站的联名款
2.平时办公卡不卡，远程控制游戏本好不好实现，vscode深度学习能不能跑。
3.没有3，暂时没想到，欢迎补充

标题: Claude max 20× 周限量大概是10个5h限额
作者: #唐 前
板块: #搞七捻三
编号: 1712292
帖子: https://linux.do/t/topic/1712292
时间: 2026-03-09 12:36:54
摘要:

a/给的周限是浮动的？最近又不够用了

标题: grok模型锁定脚本
作者: #爱喝绿豆汤
板块: #开发调优
编号: 1712295
帖子: https://linux.do/t/topic/1712295
时间: 2026-03-09 12:37:48
摘要:

// ==UserScript==
// @name         Grok Model Switcher
// @namespace    http://tampermonkey.net/
// @version      1.0
// @description  在grok.com上锁定模型
// @author       绿豆汤
// @match        https://grok.com/*
// @icon         https://grok.com/favicon.ico
// @grant        none
// @run-at       document-start
// ==/UserScript==

(function() {
    'use strict';

    // ========== 模型配置 ==========
    const HIDDEN_MODELS = {
        'grok-3': {
            name: 'Grok 3 ✍️',
            modelName: 'grok-3',
            modelMode: 'MODEL_MODE_GROK_3',
            isReasoning: false
        },
        'grok-3-mini': {
            name: 'Grok 3 Mini 🤏',
            modelName: 'grok-3',
            modelMode: 'MODEL_MODE_GROK_3_MINI_THINKING',
            isReasoning: false
        },
        'grok-3-thinking': {
            name: 'Grok 3 Thinking 💭',
            modelName: 'grok-3',
            modelMode: 'MODEL_MODE_GROK_3_THINKING',
            isReasoning: false
        },
        'grok-4': {
            name: 'Grok 4 🔍',
            modelName: 'grok-4',
            modelMode: 'MODEL_MODE_GROK_4',
            isReasoning: false
        },
        'grok-4-thinking': {
            name: 'Grok 4 Thinking 💭',
            modelName: 'grok-4',
            modelMode: 'MODEL_MODE_GROK_4_THINKING',
            isReasoning: false
        },
        'grok-4-heavy': {
            name: 'Grok 4 Heavy 🧠',
            modelName: 'grok-4',
            modelMode: 'MODEL_MODE_HEAVY',
            isReasoning: false
        },
        'grok-4-1-mini': {
            name: 'Grok 4.1 Mini ⚡',
            modelName: 'grok-4-1-thinking-1129',
            modelMode: 'MODEL_MODE_GROK_4_1_MINI_THINKING',
            isReasoning: false
        },
        'grok-4-1-fast': {
            name: 'Grok 4.1 Fast 🚀',
            modelName: 'grok-4-1-thinking-1129',
            modelMode: 'MODEL_MODE_FAST',
            isReasoning: false
        },
        'grok-4-1-expert': {
            name: 'Grok 4.1 Expert 🎯',
            modelName: 'grok-4-1-thinking-1129',
            modelMode: 'MODEL_MODE_EXPERT',
            isReasoning: false
        },
        'grok-4-1-thinking': {
            name: 'Grok 4.1 Thinking 🧩',
            modelName: 'grok-4-1-thinking-1129',
            modelMode: 'MODEL_MODE_GROK_4_1_THINKING',
            isReasoning: false
        },
        'grok-420': {
            name: 'Grok 4.20 Beta 🌿',
            modelName: 'grok-420',
            modelMode: 'MODEL_MODE_GROK_420',
            isReasoning: false
        }
    };

    // 状态
    let currentModel = localStorage.getItem('grok_hidden_model') || 'grok-4';
    let isEnabled = localStorage.getItem('grok_model_override') !== 'false';
    let panelPos = JSON.parse(localStorage.getItem('grok_panel_pos') || '{"x":10,"y":10}');

    // 如果存储的模型已不在列表中，回退到默认
    if (!HIDDEN_MODELS[currentModel]) {
        currentModel = 'grok-4';
        localStorage.setItem('grok_hidden_model', currentModel);
    }

    // ========== 核心：拦截并修改请求 ==========

    // 通用的请求体修改函数
    function modifyRequestBody(bodyStr) {
        try {
            let body = JSON.parse(bodyStr);
            const modelConfig = HIDDEN_MODELS[currentModel];

            // 新判断条件：只要有 modelMode 或 message 字段就拦截（适配新旧API）
            if (modelConfig && (body.modelMode !== undefined || body.message !== undefined)) {
                console.log('[Grok Switcher] 原始请求:', JSON.stringify({
                    modelName: body.modelName || '(无)',
                    modelMode: body.modelMode,
                    isReasoning: body.isReasoning
                }));

                // 注入/覆盖模型字段
                body.modelName = modelConfig.modelName;
                body.modelMode = modelConfig.modelMode;
                body.isReasoning = modelConfig.isReasoning;

                // 如果 responseMetadata 中有 requestModelDetails 则更新
                if (