/tag/开始

各位佬，最近nba季后赛开始了，想看看球赛，今天库里已经回家说晚安了。 想问问有没有ios端能看NBA比赛的软件，不是腾讯和咪咕的 2 个帖子 - 2 位参与者 阅读完整话题

什么是Agent？ 在开始讨论前，我们需要建立一个相对统一的共识，那么就先需要给Agent下一个定义：Agent并不是聊天机器人，而是一个可以 自主完成任务 的 软件系统 。 软件系统很好了解，就是指由多个相互关联的软件组件组成的 集合体 ，它作为一个整体在计算机硬件上运行，以实现特定的功能或解决复杂的问题。 不同于单个程序（ 比如我们使用的linuxdo pro脚本 ），软件系统是一个更宏大、宽泛的概念。它不仅包含可执行的代码，还包括配置文件、系统文档、测试记录以及用户手册等一系列配套资源。通常情况下可以划分为三类系统软件、支撑软件和应用软件，而目前的一般语境下的Agent系统就是属于应用软件的范畴（ 当然也有完全基于AI的操作系统的概念提出，但是我自己觉得还是太远了点儿 ）。 那么何谓自主？从工程定义来看，自主性（Autonomy）是指系统在 无需人类实时干预 的前提下，能够闭环完成“感知环境 → 制定决策 → 执行任务”的能力。如果仅仅以“减少人为干预”为标准，那么当前许多工作流增强工具（如各类对现有 LLM 或 Codex 进行封装优化的插件）似乎都在无限逼近这一状态。但仅凭于此，就能称其为“完全自主”的 Agent 吗？ 并非如此，自主还有一条最重要的要求就是 达成目标 ，这个可谓是难住了绝大多数的Agent。因为很多Agent，尤其是用来Coding的Agent，完全不能达到我们的目标，简单来说就是我想的和你做的完全不一样，即便是有对应的文档去约束，也并不会有很大的提升，其实很多时候都是Agent在猜你想干什么。 那么我们只能从Agent的结构来优化，以便达成我们的目的。 一般情况下，一个完整的Agent系统主要由以下五个核心层级构成： 模型层 (LLM)： Agent的主要认知中枢，负责理解人类自然语言的意图、进行逻辑推理以及生成决策。 记忆层 (Memory / Context)： 负责状态管理。包含短期记忆（当前任务的上下文记录）和长期记忆（历史交互、经验总结、存在向量数据库中的业务知识，很多企业其实还停留在这一层），使其能在多轮交互和长时间任务中保持连贯性。 规划层 (Planner)： 负责将复杂的大目标拆解为可执行的子任务（Sub-tasks）。常见的技术路径包括 ReAct（Reason + Act，即“思考+行动”循环，现在基本上使用的都是这个，主要是稳定）、思维链（CoT）等。 工具层 (Tool / Skill)： Agent 的“手脚”。允许 Agent 通过 API 调用外部系统，例如搜索网页、读写文件、运行代码、操作终端，或者调度第三方办公软件（如 Jira、Slack、GitHub）。 执行层 (Executor)： 按照规划层的步骤，调用对应的工具进行实际操作，并接收环境反馈（Observation）。如果报错，它会根据反馈不断调整策略重试，直至任务完成。 看起来是没什么问题，但是我们稍微对比一下人类的思考过程：在Agent中，LLM虽然被称为“认知中枢”，但在人类认知中并不存在一个单独的模块负责理解、推理和生成语言。人类的语言理解、逻辑推理、知识检索、情绪判断等是分布在多个神经系统中的，例如语言皮层、前额叶、海马体等（ 并非在水字数，确信 ）。 这么说来，LLM其实更像是一个 压缩后的认知模拟器 ，而不是一个真正的“大脑模块”。这也就是为什么我们的想法会和Agent的实际执行出现比较大的偏差，因为人类会想象会吃会喝会听会说，是建立在一个多模态的世界中，token能存储的信息还是太少了。（ 那是不是说我们说话越伪人输出越规范，那么我接下来就要稳稳的接住你了 ） 那么话说回来，在后面的叙述中，我们必须放弃“要让 Agent 像人一样去领悟”的幻想。（ 放弃幻想，准备斗争！ ） 那么问题就出现了：既然Agent并不像人类一样思考，我们该如何设计Agent系统？ 如果我们继续坚持“让LLM像人一样理解任务”，那么大多数Agent项目都会陷入一个非常典型的困境： Prompt 越写越长，但效果并没有明显变好。 （ 实际上对于上下文长的，比如没有降智前的Claude-4.6-Opus 1M版本，对于长上下文的理解其实是非常不错的，但是稍微上下文短一点的，比如Gemini-3.1-Pro，还没聊多久就会直接注意力漂移，其实我更喜欢叫注意力涣散，因为真的很贴切 ） 这是因为LLM的能力本质上是 概率语言模型 ，它擅长的是模式匹配，而不是稳定的任务执行。（ 比如输入同一段Prompt，得到同一段思考路线的可能性很小 ） 因此，如果整个系统完全依赖LLM的“理解能力”，结果往往就是：Agent在 猜测用户的意图 ，而并非 执行明确的任务 。（ 我不猜，我会先搞清楚，避免文档爆炸… ） 这也是为什么很多 Coding Agent 在实际使用时会出现一种非常奇妙的体验： 我让它做 A，它最后给我做成了 B。 甚至有的时候南辕北辙做成了-A，这时候我们会因为蠢笨的模型而急血攻心当场嘎掉（bushi）。 模型不够聪明是一方面， 任务本身没有被工程化定义 则是另外一方面，这就是Agent设计的问题。 因此，可以得出结论，在真正可用的Agent系统中， 不要试图让Agent理解一切，而是要限制Agent的理解范围 是一个非常重要的设计原则。 从这样的角度看来理解，那么从Prompt Engineering到Prompt Programming到Tool Augmentation到Agent Engineering到Context Engineering到Workflow Engineering到Capability Engineering最后目前到Harness Engineering，这一连串的流程就是将LLM从一个近乎无限发散的系统约束成为一个可靠的能正常工作的系统。 为什么我会需要一个Agent？ 在明确了Agent是什么以及我们需要做成什么样的Agent系统之后，那接下来就是一个相当重要的问题，我们为什么需要一个Agent？ 无法控制的成本 在这里先偏个题，先介绍一个内容，索洛悖论（Solow Paradox）。 1987年，诺贝尔经济学奖得主罗伯特·索洛曾断言：“我们到处都能看到计算机时代，唯独在生产力统计数据中看不到。” 然而，在后面的美国的互联网泡沫极大的带起了生产力发展，也带起了十几年的互联网公司的高速发展，形成了独有的互联网经济。而现在的AI和1987年的互联网也是有一定的相似之处的。 正如我们前面所说的，LLM本质上是一个“高维数据压缩后的认知模拟器”，而非严密的逻辑引擎。这种基于概率的生成机制，直接击中了商业应用中的致命痛点：极高的边际成本、人类验证成本和系统改造成本。 将AI的准确率从80%提升到95%可能只需要几个月，但从95%提升到99.9%（至少需要达到企业级可用标准）却需要指数级的工程投入，一般企业根本没有对应的盈利来覆盖这个成本。 AI生成一篇报告或一段代码只需几秒钟，但其中很大概率潜藏着幻觉（Hallucination）或细微的逻辑错误，如果聘请专业人那么为了 审查和纠错 所花费的时间，这就抵消了AI自动生成所节约的时间，也需要花费很高的成本。而如果采用AI review，有可能出现越审查越分析效果越差的问题。而在医疗、法律、金融等容错率极低的行业，这种验证成本甚至高于纯人工。 孤立的AI工具（如网页版 ChatGPT 或独立的代码补全插件）很容易开发，但要将AI深度集成到企业极其庞杂、老旧的底层IT系统（如ERP、CRM、核心数据库）中，面临着巨大的工程阻力，大家维护过比较老旧的系统都知道，一旦稍微改动有可能导致的就是崩溃。（ 即便是新的系统也很容易成为屎山，比如OpenClaw，每一次的更新都是稳定性的一次巨大挑战 ） 零和博弈的困境 并非所有的效率提升都能转化为真正的 GDP 或社会生产力大爆发。尤其AI擅长的很多领域，在宏观经济中属于 零和博弈（Zero-Sum Game） 。 Jevons悖论 ：技术进步提高了资源利用效率，结果却导致该资源的总消耗量不降反升。 当AI让写邮件、做PPT、写公关稿变得异常简单时，结果往往不是员工每天多出4 小时休息时间，而是公司要求产出5倍数量的邮件和PPT。AI导致了信息的通货膨胀，我们大部分精力被消耗在“用AI制造垃圾”和“用AI总结别人制造的垃圾”这种无意义的内卷中。 而很多AI本该有的产能在红海中的互相争夺中消耗了大量，很多AI应用被投入到广告定向、高频交易、SEO优化等领域。这些技术或许能帮A公司抢走B公司的利润，但从全社会宏观视角来看，其实并没有创造出新的增量价值，仅仅是提高了竞争的基线门槛。 鲍莫尔成本病（Baumol’s Cost Disease） ：由美国经济学家威廉·鲍莫尔（William Baumol）在 20 世纪 60 年代提出的一种经济现象。由于服务业 （如医疗、教育）的生产效率难以提升，为了与制造业争夺人才，其工资必须跟随社会整体水平上涨，从而导致这些服务变得越来越贵。 AI可能会让数字内容的生产成本趋近于零，但经济中不可被 AI 替代的部分（如线下服务、精密制造、实体护理、物流配送）的相对成本将显得越来越高，从而拖累整体经济的生产力增速，这一点目前在国内不是特别的明显，但是在阿美莉卡尤为明显。 讲到这里，简单总结一下就是AI的确让我们局部跑得更快了，但在整个经济大盘里，我们大概率只是在原地打转甚至跑得更累。因为本质上盘子没有做大，只是开始了互相兼并，大公司兼并小公司的业务，中小公司越来越不好过，于是就出现了明明程序员的生产力超级爆发，但是大家开始纷纷失业。 技术重构的“时滞效应” 历史一再证明，通用目的技术（现在就是GPT、Claude等，过往如蒸汽机、电力、计算机）要转化为生产力，往往需要长达数十年的“时滞（Implementation Lag）”。 在19世纪末电力就被发明，但直到20世纪20年代才带来工厂生产力的爆发。因为早期的工厂只是简单地把巨型蒸汽机换成了一个巨型电动机，依然使用旧的物理传动轴；直到工厂主意识到电可以被分割为小型电机（分布式驱动），等彻底重构了工厂的流水线布局后，生产力才真正飞跃。 今天的企业使用AI，很大程度上就像“用电动机替换蒸汽机”，只是把AI作为一个单点工具塞进旧的工作流中（比如让客服人员旁边挂一个AI助手，而实际我们也是这么做的），并且AI的推广也非常受限于这个公司决策者的眼光。真正的生产力爆发，需要彻底拆解并重构企业的组织架构和业务流程（Workflow），这涉及巨大的沉没成本、部门利益博弈和员工抵触，绝非朝夕之功。 所以初创小公司在本次AI浪潮中更容易成功，因为以AI为中心设计的软件和工作流就是比传统的工作流要高效许多。 难以触及的物理世界 AI要想真正产生颠覆性影响，就必须触及核心数据和改变物理世界，但这恰恰是目前各大公司的雷区。 高价值的商业决策需要极其核心的内部数据（财务、用户隐私、战略机密）。受限于GDPR等数据保护法案以及对数据泄露的恐惧，绝大多数大企业和政府机构都在物理隔离AI，甚至禁止员工将核心数据输入给外部大模型。没有高质量的私有数据喂养，AI对业务就只能做表面的文字游戏。（ 所以之前有佬友问我未来需要什么能力，我就说一定要了解业务，了解业务非常的重要 ） 当然也存在本地模型微调来服务于本地的方式来完成需求，但是这条路远没有听起来那么顺畅。部署过本地模型的佬友都知道，只是本地单机单人使用部署还算是比较简单的，但是想要一套给整个企业使用的本地部署就是一件非常困难的事情。 首先，私有化部署的门槛高得离谱。 且不说动辄数百万的算力采购成本，光是找到既懂公司业务又懂模型微调的人才，就可以让多数传统企业的CIO挠破了头。 更尴尬的是，假设你费尽心思把内部财务数据和客户档案喂给本地模型，调出来的东西往往还不如直接用GPT的效果好。开源模型与闭源模型的差距一时半会还是难以逾越的。（ 还是期待DeepSeekv4的开源可以追上国外闭源大模型 ） 其次，物理世界的反馈闭环真是太难打通了。 目前的AI主要爆发在“数字世界”（文本、图像、代码），但人类社会的基石是“原子世界”（农业、制造业、能源、实体供应链）。机器人技术（具身智能）的发展远落后于大语言模型。只要AI还没有真正长出能在物理世界中精确执行复杂任务的“手脚”，它的生产力影响就会被严重限制在第三产业（服务业/知识产业等）里面。 AI写段代码错了无非报个bug再改，成本近乎为零。但在物理世界里，AI控制机械臂抓错一个零件，可能就是几十万的设备损毁；AI误判一个农业灌溉指令，毁掉的可能是一季的收成。错率的天壤之别，决定了AI在物理世界的渗透速度注定是数字世界的十分之一甚至是更低。之前去东莞的厂子和那边的老板来聊天，大部分都是用的传统方案，本质上还是之前智能化、自动化的延续。 很多时候并不需要一个Agent 在长篇大论探讨了这么多AI的局限和宏观困境后，我们不可避免地要面对一个极其现实的结论： 在当前的绝大多数业务场景中，你其实根本不需要一个Agent。 当我们手里拿着Agent这把闪闪发光的“智能锤子”时，看什么业务都像钉子。但工程的本质永远是成本与收益的博弈。 如果一个任务是高度确定性的、有明确规则边界的（比如定时拉取某个接口的数据、按照固定格式生成Excel报表、或者对数据库进行简单的增删改查），写一个传统的Python脚本、配一个Cron job，或者直接用现成的RPA工具，不仅边际成本几乎为零，而且能保证100%的执行确定性和毫秒级的延迟。 相比之下，如果我们非要强行引入一个Agent去执行这些规则明确的任务，你不仅要支付昂贵的Token费用，要忍受大模型的推理延迟，最要命的是你还得时刻提防它突发发神经，偏离原本极其简单的执行逻辑。但是目前的很多做决策的人并没有意识到这一点，因为他们自己就没怎么用过LLM以及Agent。 在真实的商业落地中，“可预期性”往往比“聪明”更重要。Agent最大的魅力在于处理“模糊意图”和“探索非结构化环境”，但这恰恰也是它最大的稳定性软肋。 为了让一个基于概率生成的Agent表现得像传统软件一样稳定，开发者往往需要堆砌无数的Prompt、设计复杂的约束护栏（Guardrails）以及多重验证逻辑。费了九牛二虎之力，最后只是硬生生地把一个聪明的Agent逼成了一个极其低效、昂贵且脆弱的“IF-ELSE状态机”，这不就是杀鸡用牛刀？ 所以，如果你的需求能用几百行清晰的代码、一条复杂的SQL，或者传统的API调用来解决，千万别上Agent。只有当业务中确实包含了大量需要动态决策、理解复杂非结构化上下文、或者需要跨越多个未知系统进行探索性规划时，才是Agent真正应该出场的时刻。 一味追求架构上的时髦，只会把原本只需要一辆自行车的确定性路况，硬塞给一台维护成本极高、方向盘还容易失灵的喷气式飞机，不要强行复杂化。（ 这里推荐奥卡姆剃刀 ） OpenClaw带来的启示 在前面花了这么大篇幅给AI泼冷水、谈局限之后，你可能会觉得这篇文章的主旨就是“AI啥也不是，大家散了吧”。 但恰恰相反。 2026年春天OpenClaw的爆发（ 我愿称之为龙虾狂欢 ），反而给了我们一个非常有意思的观察窗口：AI到底是如何从“工具”向“助手”过渡的。 国内厂商的反应更是异常疯狂，先是阿里云、腾讯云连夜上线一键部署服务，电商平台上“上门安装OpenClaw”的服务报价从499到1000元不等，深圳龙岗等地甚至出台了“龙虾十条”，对基于OpenClaw的“一人公司”创业项目最高给予大额支持。 这股狂热背后，OpenClaw到底做对了什么？ 毕竟人们从来不缺会聊天的AI，缺的是能轻易接管工作流的AI。 ChatGPT爆发之后，市场上最不缺的就是“会说话的模型”。用户的新鲜感早就被消耗得差不多了。大家真正开始焦虑的问题变成了：你除了会陪我聊、帮我写、帮我总结之外，到底能不能替我把活干掉？ OpenClaw的爆发，本质上踩中的就是这个情绪变化。它满足的不是“再来一个更聪明的聊天机器人”，而是“终于有一个东西可以轻松的接管我的操作链路了”。 这也是为什么它能引发比普通Agent框架更强的讨论度。（ 当然少不了我们国内营销号的卖力炒作 ） 但问题来了，既然OpenClaw这么牛，那前面那些论断是不是就可以收回了？ 没那么简单。 首先是 安全失控 。OpenClaw能操作你的电脑，就意味着它也能删掉你的邮件、文件，甚至被恶意提示词劫持后做出你完全意想不到的事。工信部NVDB在2026年2月就发布了OpenClaw安全风险预警，明确指出其存在信任边界模糊、权限管控缺失、易被攻击劫持等严重问题。奇安信的监测数据显示，截至1月29日，全球范围内暴露在公网上的OpenClaw资产总数高达15039个，其中中国以2990台暴露设备位列全球第二。 这意味着数千台服务器处于“中门大开”的状态，攻击者可以轻易接管实例、窃取API密钥、执行远程命令。（ 全成肉鸡了 ）这恰恰印证了AI在物理世界和系统层的渗透，容错率极低，但安全基础设施完全没跟上。（ 利好网安？ ） 其次是 企业落地撞上了“三堵墙” ，分别是认知墙、数据墙、生态墙。第一批部署OpenClaw的企业发现，它的底层任务调度优化空间有限，长期记忆模块的原生能力不足，Skill生态的质量参差不齐。可能有一半的企业部门已经进入规模化使用阶段，但真正敢把核心业务交给它的，少之又少。 更要命的是， OpenClaw自己也面临设计哲学上的根本困境 。它要求用户明确告诉它用什么Skill、文件放哪、Shell怎么跑，本质上还是“你给工具+你全程盯着”的模式，那时候站里面到处都是养龙虾的攻略，但是用户需要的是一个助手而不是小孩，我需要到手即用而不是需要高质量token和大量时间去养。 而技术社区里最多的抱怨是版本迭代引入稳定性问题、issue堆得越来越多、响应速度跟不上。（ 屎山堆得太高了 ） 当一个系统的复杂性超出了工程团队的可控范围，“概率性智能”的副作用就会指数级放大。（ 幻觉叠加幻觉最终造成任务目标严重偏移 ） 所以OpenClaw给我们的启示就只有一条：它证明了用户对于一个通用级的助手是多么的需要。 但要真正让AI产生生产力革命，光有能用的Agent远远不够。你还需要与之配套的安全基础设施、组织架构重构、以及整个社会对新工作范式的适应能力。OpenClaw只是这场漫长重构的第一块拼图，后面还有九十九块等着我们去补。说白了，它只是把AI的能力边界向外推了一小步，让我们更清楚地看到了下一步要翻越的山应该是什么样子的。 （猜测）LLM的下一代交互方式 原本这一节我写了很多，但是写完之后我还是发现有点局限于我自己的眼界了，于是我删除了自己写好的稿子，保留这一节打算请各位佬友集思广益，互相讨论。 究竟是要做成插件平台还是做成快应用平台还是完全自主进化的Agent？ 写在最后 这一篇可能写的比较多杂，写的时间也是比较长，但是我还是决定发出来供大家讨论一下。 目前AI应用的发展其实已经隐隐看到了瓶颈，因为Agent自从提出来之后到现在基本上没什么很大的发展，不管是什么各种新概念的提出来大家都会感觉没有质的提升，一年前的茫然可能到现在还是比较茫然，并且更重要的原因还是大量的企业没有动力去更换自己的固有工作流，所以这个出清的过程将会是相当漫长的。 动动你的小手，将这篇文章链接直接糊到你老板脸上（ 不太建议这么做 ），免去你大部分的解释时间~~ PS：发在搞七捻三就是本文不构成任何开发建议，仅作公开讨论，请各位佬友见仁见智。（ 叠甲有点晚了好像 ） 1 个帖子 - 1 位参与者 阅读完整话题

几年前开始有头屑和油头困扰，开始使用去屑洗发水，将就着过了几年。 一年前开始头屑变得严重，用手挠头像下雪一样，一直挠头，头屑一直下个不停。当天洗完头，吹干后还是有头屑。上班被同事看到很尴尬，非常困扰，试了好多办法，终于找到一个相对彻底解决方法，现在基本一周两洗都还好。 分享下用过的产品，希望有一款对大家有帮助。 总结来看分三类，核心是看成分 1 二硫化硒成分 ： 市面最主流去屑洗发水带的成分，不同品牌只是成分占比高低。 ①selsun ： 澳洲的品牌，是我最开始用的去屑洗发水，黄瓶和紫瓶都买了。 黄瓶侧重去屑，效果要好一些，不过洗完比较毛燥，用梳子梳容易卡住； 紫瓶控油，日常主要关注头屑，没怎么注意控油情况，好像是有些效果。 这个品牌是用过最长时间的洗发水，不过最近一年，可能产生抗性，洗完没啥用，开始找替代 ②希尔生二硫化硒洗剂 ： 头屑比较严重时期在药店买的，头两次确实有些效果，洗完同样头发比较毛躁。买过两次，这个算是药品，对皮肤有刺激，不敢频繁使用，不频繁使用好像效果又不好，后续就放弃使用了。 ③白云山二硫化硒 ： 这个是我媳妇给买的，之前在B站也经常看到广告，不过买的时候是头屑最严重时期（头屑如下雪），洗完头发不毛躁，但是洗完还是有头屑，搞不定。 ④京东京造二硫化硒 ： 这是看网友推荐比较多的，不过我还没用上，就用其他洗发水解决头屑了，以后可能会试用下。 2 中药配方 ： 中药配方 ：生侧柏叶 15g，苦参 9g，马齿苋 5g，马鞭草 5g，一共1块7贼便宜。 这个是头屑最严重时期，换了好多洗发水都没用，实在没招，去了个三甲中西医医院挂了老中医给开的，使用后确实立竿见影。原以为根治了，没想到一两个月后又开始复发了。这玩意是中药，洗的时候有味道，个人不喜欢，就没去医院续。 3 酮康唑成分 复方酮康唑 ：头屑最严重时期，到处刷帖，刷到有网友推荐，原本没报太大期望，但是没其他好的选择，抱着试试心态jd次日达下单赶紧搞上，没想到确实好使，洗完后第2天基本没头屑。 2月份买的，到现在完全已经没有下雪般头屑，感觉应该基本解决了。这个也是有点刺激头皮，不太适合频繁用，现在是偶尔想起来就用酮康唑，大部分时间依旧用白云山和其他洗发水交替使用。 以上是个人头屑抗争经验，每个人发质皮肤情况不同，不确定哪个对大家有用，给大家一些参考，建议不同成分都可以试试，希望大家不再受头屑困扰！ 以下是不同成分对比，仅供参考 11 个帖子 - 8 位参与者 阅读完整话题

一场针对海外影视资源的版权整治风暴正在席卷国内网盘行业。以夸克网盘为代表的多个平台自4月10日起启动全面清查行动，重点清理用户存储的未经授权的美剧、韩剧、泰剧等境外影视内容。这场被业内称为"最严清查令"的行动导致大量分享链接失效，引发用户紧急转移数据，部分依赖海外剧集的影视博主连夜发布备份提醒。 根据平台发布的公告，用户需在4月10日23点前自行删除存储的违规内容，并清除社交媒体上的相关分享链接。多位影视博主通过社交平台紧急通知粉丝，部分热门剧集的分享链接已出现批量失效情况。有用户反映，其存储的数百部海外剧集在行动启动后被系统自动标记，部分文件甚至无法正常打开。 面对突如其来的清查，用户群体迅速形成应对策略。部分人通过将文件名改为拼音缩写、使用特殊符号等方式规避检测，另有人选择将资源迁移至百度网盘等尚未被波及的平台。更有技术型用户将数据转存至本地硬盘或搭建私有云存储（NAS），以彻底摆脱对第三方平台的依赖。一位资深剧迷表示：“这次清理让我想起十年前的BT下载时代，只是存储介质从硬盘变成了云端。” 网盘上有资源的佬们注意了 提前下载！不要整了看不了了！ 现在很多美剧都用国内的网盘分享，影响还是挺大的 新闻来源： MSN 更多阅读 1 个帖子 - 1 位参与者 阅读完整话题

佬们，昨天还在分享 小辣椒 の 公益站 。今天打开一看，好家伙！怪不得之前帖子有很多佬说自己号被清了 ，而且有些只签到没有用也给清了。看到公告真相大白了，坚持住啊！！！ 20 个帖子 - 14 位参与者 阅读完整话题

但不知道那些一直retry的号是怎么判别的，是随机？还是指定？看注册地区？还是啥，目前还是不知道怎样简易判别，现在这么多pro号只能一个一个去测，有没有佬知道是什么原因 ，还是说谷歌正在慢慢恢复这些号？ 25 个帖子 - 10 位参与者 阅读完整话题

不懂就问，刚刚开始使用阿里的Qcoder,我发现它的auto模式竟然比其他任何一个高级模型的倍率都高，为什么？一般不都是auto模式的倍率比高级模型倍率都要低吗？ 3 个帖子 - 3 位参与者 阅读完整话题

我让他根据我的代码写论文，前面一切正常，获取文件，读取文件啥的，但是一旦进入说要开始写论文，就会像这样卡住，token数也不增加。 我用的是第三方中转，后台已经5分钟没有新的请求了，但是在终端还在转圈圈 4 个帖子 - 4 位参与者 阅读完整话题

抽奖主题： GLM Coding Plan体验卡 奖品详情： [奖品]：GLM Coding Plan体验卡 * 2 活动时间： 开始时间：[此帖发出开始] 截止时间： Sat, Apr 18, 2026 10:00 PM CST 参与方式： 在本帖下回复任意内容 抽奖规则： 每位用户仅允许参与一次。 将使用 LINUX DO 抽奖工具 在所有回复中随机抽取中奖者。 注意事项： 本活动将在活动截止时间后关闭回帖，以确保公正性。 中奖者将在活动结束后在本帖公布，并通过论坛站内信由发起人通知领奖方式。 所有规则及抽奖结果由 @feilong 及论坛 管理团队 最终解释。 发起人承诺： 作为本次抽奖的发起人 @feilong ，我承诺本话题的抽奖活动严格遵守 LINUX DO 社区抽奖规则 。因违反上述规定引发的公平性争议或其他问题，均由我独立承担相应的道德与法律责任。 期待您的积极参与，祝您好运！如有任何疑问，欢迎随时联系 @feilong 或论坛 管理团队 。 20 个帖子 - 19 位参与者 阅读完整话题

抽奖主题： 准备升 3 抽一个 66 元支付宝口令红包 奖品详情： [奖品1]：[66 元红包] 活动时间： 开始时间：[2026/4/18-16:30] 截止时间：[2026/4/20-16:30] 参与方式： 在本帖下回复任意内容 抽奖规则： 每位用户仅允许参与一次。 使用 官方抽奖工具 随机抽取中奖者。 注意事项： 采取快速参与和抽奖策略，不墨迹。莫名被封了好几次，留多一天吧 18 个帖子 - 18 位参与者 阅读完整话题

因为版权官司问题，导致夸克等一些国内网盘开始删剧封号保全。 有类似封号删除资源等等系列操作的夸克用户吗？ 我的账号里面保存了一些美剧，还没细看呢，需要自己加密处理，还是什么之类的。 6 个帖子 - 6 位参与者 阅读完整话题

我之前尝试过 spec 驱动开发，但是要写一份长长的 spec 再给 AI 开发实在劝退我。别说自己写 spec，就是 AI 帮我写完，让我 review 我也没耐心看完。于是我发明了 TODO 驱动开发。 什么是 TODO 驱动开发 简单来说，就是将需求拆解后，在项目代码中需要修改处加上 TODO 注释，再让 Coding Agent 使用 git 读 diff，获取所有新增 TODO，再逐一编写代码。 TODO 驱动开发有什么优点 第一，也是最明显的优点，TODO 驱动开发是从源码出发，让你自己找到需要修改的点，可以是一个待完成的函数，一个需要新增的类，甚至是一个模块，加上对应的 TODO 信息，再转交给 agent 进行实现。你的工作流基本还是在 代码编辑器/IDE 中，不需要你改变现有工作流。 第二，Coding Agent 在读取 diff 信息时能顺便看到代码上下文，不需要你费劲说明应该改哪个模块。 第三，由于已经明确具体修改点以及每个点的修改逻辑，对于没那么强的模型也能有相对更好的执行效果。 第四，由于已经明确具体修改点以及每个点的修改逻辑，Coding Agent 的改动更可控，Review 起来也更容易 2 个帖子 - 2 位参与者 阅读完整话题

同一台服务器 + 相同的网络 + 相同的请求内容 + 一样的请求链路 4.15号左右开始，发现CPA反代超级慢 账号都是Team + Plus 为什么速度差距这么大？ 测速图片如下 16 个帖子 - 13 位参与者 阅读完整话题

带了动态血糖仪后发现自己餐一血糖容易爆炸，于是也开始了饮食焦虑 吃水果特别容易炸，面包蛋糕那些就更别提了 但是因为工作烦躁的时候，又很想吃点什么缓解一下 求佬们分享下下～ 14 个帖子 - 12 位参与者 阅读完整话题

经群友证实，是假消息 11 个帖子 - 10 位参与者 阅读完整话题

安装后运行claude提示这个了。 该版本的 D:\tools\nodejs\node-v24.11.1-win-x64\node_modules@anthropic-ai\claude-code\bin\claude.exe 与你运行的 Windows 版本不兼容。请查看计算机的系统信息，然后联系软件发布者。 安装回旧版本 2.1.112就正常了。 npm install -g @anthropic-ai/[email protected] 15 个帖子 - 8 位参与者 阅读完整话题

Introducing Claude Design： https://claude.ai/design 额度也加了Desgin额度，不知道是有多少token 一开始还要set up，还要关联GitHub账号，不是很想去设置，但是最近想做一个产品，然后输出对应的PPT试试 3 个帖子 - 3 位参与者 阅读完整话题

官网是说按次数计算，关键我5小时用量才25% 6 个帖子 - 3 位参与者 阅读完整话题

抽奖主题： gpt team 车位 奖品详情： [奖品1]：gpt team 车位一个【无质保】 活动时间： 开始时间：2026 年 4 月 18 号 截止时间：2026 年 4 月 19 号 18:00 参与方式： 在本帖下回复任意内容 抽奖规则： 每位用户仅允许参与一次。 使用 官方抽奖工具 随机抽取中奖者。 注意事项： 本活动将在活动截止时间后关闭回帖，以确保公正性。 中奖者将在活动结束后12小时内在本帖公布，并通过私信通知领奖方式。 所有规则及抽奖结果由活动发起人和论坛 管理团队 最终解释。 期待您的积极参与，祝您好运！如有任何疑问，欢迎随时联系抽奖发起人。 141 个帖子 - 135 位参与者 阅读完整话题

IT之家 4 月 18 日消息，科技媒体 Windows Central 昨日（4 月 17 日）发布博文，报道称微软内部正推进 Windows K2 项目， 通过 WinUI 3 架构重构 Windows 11 开始菜单（目前使用 React 构建），支持用户自主调整菜单尺寸，并可一键关闭推荐、固定应用等闲置区域。 消息称微软正基于 WinUI 3 重构 Windows 11 开始菜单， 重点聚焦于自定义功能与性能响应两大核心领域，预计将为用户带来更灵活、更高效的使用体验。 自定义功能方面，新版本打破了现有的屏幕尺寸自适应限制。目前系统仅根据显示器大小强制分配布局，而更新后用户将拥有完全的自主权， 可以根据个人偏好自由选择小尺寸或大尺寸布局。 界面上重构的 Windows 11 开始菜单还采用模块化方案，用户进入设置后， 可清理不需要的界面元素，关闭推荐源、固定应用甚至所有应用列表。 在性能方面，现有的开始菜单在 CPU 高负载时常出现数秒延迟，而微软通过架构优化，围绕着“始终保持响应”的设计目标， 在系统处于高强度的负载压力下，也能保证菜单瞬间弹出。 这一性能提升同样覆盖搜索体验，解决了旧版在高负载下容易丢失按键输入的顽疾。 IT之家援引博文介绍，除了基于 WinUI 3 重构 Windows 11 开始菜单外，微软 Windows K2 项目还覆盖 Windows 11 其它诸多方面，设计目标是重新聚焦资源，致力于将 Windows 11 打造为一个快速、流畅且稳定的平台，系统性解决用户在使用过程中遇到的各类痛点。