如题，我在业余时间开发了很多小程序，有工具类的，也有实物类的。但是我不会运营，基本上都是0访问，偶尔有几个自然搜索量，同类型的排名也比较低。根据官方文档，也做了代码上的优化，但是效果几乎为0。有大佬知道怎么优化、运营吗？感谢！ 5 个帖子 - 3 位参与者 阅读完整话题
小白开发插件，在期间看文件的时候学到的一些东西，特地分享给大家： 博文链接： https://418122.xyz/posts/project/chrome-extension-basic-structure-beginners-guide 插件仓库链接： https://github.com/V-IOLE-T/tab-harbor GitHub 正在尝试上架 Chrome 插件商店 很多人第一次打开一个 Chrome 插件项目时，会看到一堆文件名，然后立刻陷入混乱。 index.html 、 style.css 、 manifest.json 、 background.js 、 content.js 、 app.js 看起来都像"代码文件"，可它们根本不在同一个层面上工作。想真正看懂插件，关键不是背文件名，而是理解这些文件分别处在什么位置，承担什么职责，以及它们如何配合浏览器、网页和用户界面一起运转。 这篇文章想做的事很直接，就是把这些文件背后的逻辑彻底串起来，让你在看到一个插件目录时，能迅速判断每个文件到底在做什么。 index.html 是插件界面的骨架 在 Chrome 插件里， index.html 通常用来描述某个页面的内容和结构。它决定页面上会出现什么元素，比如标题、按钮、输入框、文本区域，也负责把样式文件和脚本文件接进来。你可以把它理解为一个界面的骨架，因为页面里"有什么"这件事，主要就是由 HTML 决定的。 如果一个插件有弹窗界面，那么点击插件图标后看到的内容，通常来自某个 HTML 文件。有些项目把它命名为 popup.html ，有些项目也会叫 index.html 。名字并不重要，重要的是它是否被浏览器当成插件页面真正加载了。 下面这个例子足够说明它的角色： <!DOCTYPE html> <html> <head> <link rel="stylesheet" href="style.css"> </head> <body> <h1>Hello Chrome Extension</h1> <button>点击我</button> </body> </html> 这段代码里，页面里有哪些内容，完全由 HTML 决定。它告诉浏览器，这个页面有一个标题，有一个按钮，同时还引入了样式文件。你在页面里看到的一切界面元素，本质上都从这里开始。 style.css 决定界面看起来是什么样 如果说 HTML 负责把页面元素摆出来，那么 style.css 负责让这些元素有可读性、有层次感，也更像一个真正能用的界面。字体大小、颜色、背景、边距、按钮的外观、元素之间的排列方式，这些都属于 CSS 的领域。 比如下面这段代码： body { width: 250px; font-family: Arial, sans-serif; padding: 10px; } h1 { color: blue; font-size: 18px; } button { background-color: green; color: white; } 这段样式并没有改变页面里"有什么"，但它显著改变了页面"长什么样"。这正是 CSS 的作用。很多初学者一开始会把 HTML 和 CSS 混着理解，实际上它们解决的是两个完全不同的问题。HTML 决定内容和结构，CSS 决定视觉和排版。 放到插件环境里也是一样。无论这个页面是弹窗页、选项页，还是插件扩展出来的其他界面，CSS 的职责都很稳定，就是把原本生硬的结构变成可以阅读、可以操作、也更符合界面习惯的样子。 在插件里，HTML、CSS、JavaScript 分别站在不同位置上 只看 HTML 和 CSS，还只是理解了插件界面的静态部分。一个真正可用的插件，还必须让界面"动起来"，这时候 JavaScript 才会加入进来。 HTML 负责搭出页面结构，CSS 负责赋予它视觉效果，JavaScript 负责让页面对用户的操作做出反应。比如用户点击按钮后获取信息，或者把某个结果显示到页面上，这些都属于 JavaScript 的工作。 下面这段代码很简单，但它能准确展示 JavaScript 的作用： document.getElementById("btn").addEventListener("click", () => { console.log("按钮被点击"); }); 这时候你就能看到三者之间的协作关系。HTML 放了一个按钮，CSS 把这个按钮变得更清晰、易用，JavaScript 让这个按钮具备"点击以后发生事情"的能力。它们共同组成了插件界面这一层的完整逻辑。 manifest.json 是插件的入口和规则中心 当你把眼光从界面移开，就会看到插件最核心的配置文件，也就是 manifest.json 。这个文件的重要性非常高，因为 Chrome 浏览器安装和加载插件时，最先读取的就是它。没有它，插件无法被识别。写错了它，插件也可能根本无法运行。 它承担的职责可以概括为一件事，就是告诉浏览器：这个插件是谁，它有哪些页面，有哪些脚本，想申请哪些权限，以及这些能力应该如何被组织起来。 最简单的内容通常长这样： { "name": "My Extension", "version": "1.0", "manifest_version": 3 } 这里记录了插件的基本身份信息。接着你还会看到它声明插件弹窗页面： { "action": { "default_popup": "popup.html" } } 浏览器读到这里，就知道用户点击插件图标时，应该打开 popup.html 。如果插件带后台脚本，还会出现类似配置： { "background": { "service_worker": "background.js" } } 如果插件需要把脚本注入网页，则可能是这样： { "content_scripts": [ { "matches": ["https://*/*"], "js": ["content.js"], "css": ["content.css"] } ] } 如果插件要访问某些浏览器能力，还得显式申请权限： { "permissions": ["storage", "tabs", "activeTab"] } 所以，从更本质的角度看， manifest.json 的作用，就是定义插件"能做什么、在哪里做、通过谁去做"。这也是为什么它像一个总开关。你后面看到的页面、脚本、权限，最终都要回到这里去确认。 background.js 像插件的后台调度中心 理解了 manifest.json 后，再去看 background.js 就容易多了。这个文件通常不负责展示界面，也不会直接嵌在某个网页里。它更像插件的后台控制层，负责监听浏览器事件、处理全局逻辑、协调不同模块之间的通信。 比如插件刚被安装时，它可以执行初始化逻辑： chrome.runtime.onInstalled.addListener(() => { console.log("插件已安装"); }); 它也可以监听某些全局事件，或者接收来自界面页和内容脚本的消息： chrome.runtime.onMessage.addListener((message, sender, sendResponse) => { if (message.type === "getData") { sendResponse({ data: "这是后台返回的数据" }); } }); 为什么插件需要这样的文件？因为有些事情不适合写在界面脚本里，也不适合写在网页注入脚本里。比如统一管理状态、协调多个标签页、处理浏览器级别的事件、访问某些只允许后台使用的 API，这些任务都更适合放在后台脚本中。 如果你使用的是 Manifest V3，那么这里还有一个重要变化。 background.js 在很多情况下是以 service_worker 的方式运行的。它不会一直常驻，而是事件来了就唤醒，执行完任务后可能进入休眠。这背后体现的是 Chrome 的设计取向，它希望插件更节省资源，也更容易控制风险。 content.js 是插件进入网页内部后的执行者 如果说后台脚本站在浏览器层面处理逻辑，那么 content.js 站在网页现场工作。它会被注入某个网页中，因此可以直接访问这个网页的 DOM，也就是页面上的标题、按钮、正文、输入框这些真实存在的元素结构。 举个最简单的例子： const title = document.querySelector("h1"); console.log(title.innerText); 这段代码能直接读取网页上的标题内容。它也可以修改页面： document.body.style.backgroundColor = "lightyellow"; 甚至还能监听页面中的某些操作。也就是说， content.js 的核心价值，在于让插件真正进入网页环境，看到页面内容，并对页面进行读取或修改。 不过这里有一个非常容易被忽略的边界。 content.js 虽然运行在网页里，但它依然属于插件。它拥有插件赋予的能力，也受到插件环境的限制。它和页面原生脚本之间并不是完全共享一切的关系，因为浏览器会通过隔离机制防止它们互相污染。这个细节很关键，因为很多初学者会误以为内容脚本和网页自身的 JavaScript 完全是一回事，实际情况并没有这么简单。 插件的核心难点，在于多个运行环境同时存在 当你把 popup.js 、 background.js 、 content.js 放在一起看时，很容易觉得它们全都是 JavaScript，所以好像只是写法不同。真正的区别并不在语法，而在运行环境。 界面脚本运行在插件自己的页面里，只有当这个页面被打开时它才活跃。后台脚本运行在插件后台，专门处理全局事件和中转逻辑。内容脚本运行在目标网页中，负责接触页面本身。这三种脚本虽然都写成 .js 文件，但它们能访问的对象、拥有的权限、存在的生命周期都不一样。 这正是 Chrome 插件学习曲线真正陡峭的地方。你卡住的往往不是 API，而是脑中没有建立"多环境协作"的图景。一旦建立起这个图景，再看文件结构就会清晰很多。 一个最常见的协作流程，到底是怎样跑起来的 假设我们做一个非常简单的插件。用户点击插件图标，弹出一个小窗口，窗口里有一个按钮，点击按钮后读取当前网页标题并显示出来。这个功能很小，但它足以把前面提到的所有角色串到一起。 首先浏览器会读取 manifest.json ： { "manifest_version": 3, "name": "Title Reader", "version": "1.0", "action": { "default_popup": "popup.html" }, "permissions": ["activeTab"], "background": { "service_worker": "background.js" } } 这一步完成后，浏览器已经知道这个插件长什么样，有什么弹窗页面，有什么后台脚本，以及它申请了当前标签页权限。 当用户点击插件图标时，浏览器会根据 default_popup 打开 popup.html 。页面一打开，HTML 会把结构渲染出来，CSS 负责样式，页面脚本负责交互逻辑。如果 popup.html 里有一个按钮和一个显示结果的区域，那么脚本就可以写成这样： document.getElementById("btn").addEventListener("click", async () => { const [tab] = await chrome.tabs.query({ active: true, currentWindow: true }); document.getElementById("result").textContent = tab.title; }); 如果需求只是读取当前标签页的标题，这样就够了。但如果你想读取网页内部更细的内容，比如某段正文、某个按钮文本、某个元素属性，那仅靠弹窗脚本通常不够，你就得让 content.js 进入网页现场去执行。 它可以先读取网页内容，然后把结果通过消息机制发回插件系统： const pageTitle = document.title; chrome.runtime.sendMessage({ type: "pageTitle", data: pageTitle }); 这时候如果流程稍微复杂一些，后台脚本就会出场，承担协调者角色。比如弹窗先给后台发消息，后台再联系当前标签页里的内容脚本，内容脚本拿到网页数据后返回给后台，后台再把结果转给弹窗。这个链路看起来绕了一层，但你会发现它的分工很清晰。界面只处理用户交互，后台处理协调和调度，内容脚本只关注网页现场。 示例代码大致可以写成这样。 popup.js ： chrome.runtime.sendMessage({ type: "getPageInfo" }, (response) => { document.getElementById("result").textContent = response.data; }); background.js ： chrome.runtime.onMessage.addListener((message, sender, sendResponse) => { if (message.type === "getPageInfo") { chrome.tabs.query({ active: true, currentWindow: true }, (tabs) => { chrome.tabs.sendMessage(tabs[0].id, { type: "readTitle" }, (response) => { sendResponse({ data: response.title }); }); }); return true; } }); content.js ： chrome.runtime.onMessage.addListener((message, sender, sendResponse) => { if (message.type === "readTitle") { sendResponse({ title: document.title }); } }); 把这段流程真正看懂后，你对插件的整体架构就已经入门了。因为你会意识到，插件开发的本质不是单纯地写一个页面，而是把浏览器环境、插件界面和网页环境连接成一个系统。 app.js 到底是什么，它为什么总让人困惑 很多人学到这里，又会看到一个新的文件名，叫 app.js ，然后开始怀疑自己是不是漏学了某种"官方角色"。其实这里最需要澄清的一点是， app.js 并不是 Chrome 插件规范里规定必须存在的文件。它通常只是开发者自己起的名字。 这意味着，当你在一个插件项目里看到 app.js 时，不能直接根据名字判断它一定负责什么。判断它职责的关键，始终只有两件事，就是它在哪里被加载，以及它运行在什么环境中。 如果 popup.html 里有这样的代码： <script src="app.js"></script> 那这个 app.js 很可能就是弹窗页面的主逻辑脚本。它可能负责监听按钮点击、获取输入框内容、调用浏览器 API、更新页面文本等交互行为。比如： document.getElementById("btn").addEventListener("click", async () => { const [tab] = await chrome.tabs.query({ active: true, currentWindow: true }); document.getElementById("result").textContent = tab.title; }); 如果它被 options.html 引入，它就可能是设置页脚本。如果它出现在 manifest.json 的后台配置中： { "background": { "service_worker": "app.js" } } 那它虽然名字叫 app.js ，实际承担的就是后台脚本的职责。如果它被声明在 content_scripts 中： { "content_scripts": [ { "matches": ["<all_urls>"], "js": ["app.js"] } ] } 那它本质上就是内容脚本。 所以，理解 app.js 最重要的一句话是， 文件名本身不决定身份，加载位置和运行环境才决定身份 。很多初学者容易被文件名带偏，以为名字像什么就是什么。实际开发里， main.js 、 index.js 、 app.js 这类名字都很常见，它们更多反映的是工程命名习惯，而不是浏览器规范。 判断一个脚本作用时，最可靠的方法是什么 如果你以后再打开一个陌生的插件项目，最稳妥的阅读方式就是先看 manifest.json ，再看 HTML 文件，最后才去看具体脚本内容。 manifest.json 会告诉你有哪些页面、有哪些后台脚本、有哪些内容脚本、申请了哪些权限。HTML 文件会告诉你哪些 JavaScript 是页面脚本，因为它们会被 <script src="..."> 直接引入。脚本内容本身才会进一步告诉你，这个文件内部具体写了什么业务逻辑。 这个阅读顺序很重要，因为它会强迫你从"运行上下文"去理解代码，而不是从"文件名猜测"去理解代码。你一旦形成这种习惯，不光看 Chrome 插件会快很多，将来学 Vue、React，甚至看更复杂的前端工程，也会有更强的拆解能力。 学插件时，最推荐的理解路径 对于初学者来说，最容易迷失的地方，是一上来就想把所有文件和 API 全部记住。这样做通常效果很差，因为你的脑海里没有一张系统图，记忆就没有挂钩点。 更好的路径，是先看清谁负责界面，也就是 HTML、CSS 和页面脚本。然后理解谁负责进入网页读取和修改内容，也就是 content.js 。最后再理解谁负责监听全局事件、连接各个模块、处理中间调度，也就是 background.js 。当这条主线建立起来以后，消息传递、权限管理、脚本注入这些内容都会顺势变得可理解。 如果你一定要用一句话概括整个插件结构，那么这句话可以写成这样： manifest.json 先注册角色并声明权限，HTML 和 CSS 负责界面呈现，JavaScript 负责交互逻辑， background.js 负责后台调度， content.js 负责进入网页执行具体动作，而 app.js 是否重要，取决于它究竟被谁加载、运行在哪个环境里。 结尾：真正该建立的，是"环境意识" 学 Chrome 插件，表面上像是在学很多零散文件。更深一层看，你其实是在学习多个受控运行环境如何协作。浏览器层、插件界面层、网页内容层，这三层有各自的边界，也通过消息和配置互相连接。你一旦抓住这个系统视角，就不会再被文件名和目录结构轻易迷惑。 所以当你下次看到一个插件项目时，先别急着问"这个文件名是什么意思"。更值得问的是，这个文件由谁加载，它运行在哪里，它能访问什么，它和谁通信。只要这四个问题想清楚，整个项目的骨架就会慢慢显形。 【拓展思考】 Chrome 插件很像一个小型多进程系统。弹窗脚本、后台脚本、内容脚本分别处在不同上下文中，消息传递像协议，权限声明像访问控制，页面注入像受限部署。你如果从系统设计的视角理解插件，后面学浏览器扩展、Electron、前端工程化，很多概念都会互相打通。 1 个帖子 - 1 位参与者 阅读完整话题
我在使用GLM Coding Plan，数小时内完成过去需要数周的开发工作，赠送你1张7天AI Coding体验卡，一起来用吧： 智谱AI开放平台 7 个帖子 - 5 位参与者 阅读完整话题
如题 我在使用GLM Coding Plan，数小时内完成过去需要数周的开发工作，赠送你1张7天AI Coding体验卡，一起来用吧： 智谱AI开放平台 3 个帖子 - 2 位参与者 阅读完整话题
也不能说是bug吧，只能说开发出来的东西能用。 稍微中型点的就像东拼西凑的一样，很难有很少的体验 需要多次打磨，也不知道是不是我要求太高了 以前ai都无法正常一个正常的应用，现在可以但是还觉得不够 各种框架 技能都试过了 但是总感觉不够好 我是只用codexapp了 9 个帖子 - 8 位参与者 阅读完整话题
IT之家 4 月 18 日消息，《杀戮尖塔 2》开发商 Mega Crit 昨天发布博文，公布游戏的更新路线图。 IT之家从博文中了解到，本作未来将支持 Steam 创意工坊、新增图鉴系统，后续的更新工作主要集中在 Bug 修复、性能兼容性优化、音效优化、平衡性调整等。远期规划则有移植主机平台、Steam 成就 / 集换式卡牌、“真结局”及相关内容。 不过 Casey 表示， 目前团队暂时不会确定 1.0 正式版的推出时间 。原因主要在于 Mega Crit 是一个小团队，目前不会通过大规模扩招加快进度，严格地遵循某个时间表只会做出粗制滥造的游戏。 官方透露，自发售以来 ，《杀戮尖塔 2》玩家已经累计爬塔 1.45 亿次。 在“灯火钥匙”事件中，56% 玩家选择归还钥匙，44% 玩家选择与神秘骑士战斗。在“战史学家突袭”事件中，88% 玩家选择解救角色，12% 玩家选择直接开启宝箱。在“满屋芝士”事件中，63% 玩家选择立即食用芝士，37% 玩家选择挑选特殊芝士。在异鸟巢事件中，51% 玩家选择带走鸟蛋，49% 玩家选择食用鸟蛋。
现在并行开发的任务越来越多了，经常会开着5、6个终端一起干活，但这样就会导致很多都回复不及时，想问下佬友们有没有什么好的监控工具人，推荐一下，拜谢！ 7 个帖子 - 4 位参与者 阅读完整话题
1、字节抖音财经风控 38 15+房补 2、快手推荐算法引擎 36 16+房补 3、小公司量化开发 35 16+房补+少量期权 均为base北京，总包算下来差不多，工作强度方面1和2是10-10-5,3应该是9-6:30-5。 个人认为1和2的平台大一些但是工作压力会更大，3的行业、公司和业务稳定性存疑，但是比较wlb。字节给的业务不如快手核心，而且财经的卷度应该会比较高，但是字节本身的平台又确实比快手更高一些，因此现在也是很纠结。 求佬友们给些建议，谢谢大家！ 4 个帖子 - 3 位参与者 阅读完整话题
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 事情的起因是，最近想玩一玩胶片摄影，但是奈何 Android 没有很好的测光软件，索性自己就vibe了一个，现已开源： https://github.com/JessieChan0730/com.lamameter.pro 目前 v1.1.0 版本已经实现了最基本的测光功能，接下来计划实现下面几个功能： 白平衡检测 估焦测距 分区曝光 目前部分界面的设计： 求求佬友们给给建议（无论是功能、UI还是BUG都可以） 。如果有佬友喜欢这个项目，觉得这个项目还不错的话，也可以帮忙提提issue或者点一点star 。感谢各位佬友的支持啦！ 2 个帖子 - 2 位参与者 阅读完整话题
项目介绍： 基于Vue 3、Tauri 2、Naive UI的极简Windows 桌面应用模板，用于快速开发桌面程序。 整体风格为：深色+ 半透明+ 极简工具感+ 轻微动效的Mica 风格桌面应用模板。 项目地址 github.com GitHub - llds66/vetra: 一个极简的 Windows 桌面应用模板，基于 Vue 3、Tauri 2、Naive UI 和... 一个极简的 Windows 桌面应用模板，基于 Vue 3、Tauri 2、Naive UI 和 UnoCSS 截图 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： 我的帖子已经打上 开源推广 标签： 是 我的开源项目完整开源，无未开源部分： 是 我的开源项目已链接认可 LINUX DO 社区： 是 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出 1 个帖子 - 1 位参与者 阅读完整话题
我之前尝试过 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 位参与者 阅读完整话题
IT之家 4 月 18 日消息，科技媒体 Wccftech 昨日（4 月 17 日）发布博文，报道称三星电子为应对 AI 市场需求激增，并匹配英伟达等主要客户每年推出新 AI 加速器的节奏， 将高带宽内存（HBM）开发周期从 2 年大幅缩短至 1 年。 消息称三星电子战略调整高带宽内存（HBM）业务，为确保每年都能推出新一代 HBM 标准，放弃沿用多年的 2 年产品迭代周期，转而采用 1 年开发周期。 IT之家注：HBM 是 AI 加速器的核心组件，三星作为该领域的关键供应商，目前最新产品为 HBM3E，下一代 HBM4 预计今年随英伟达 Vera Rubin 及 AMD Instinct MI400 平台一同推出。 行业分析师认为，1 年周期能帮助三星在与美光、SK 海力士的竞争中巩固技术优势，避免在快速迭代的 AI 内存市场掉队。 同时，这也将助力三星在未来的定制化 HBM5 市场获得领先地位，满足全球科技巨头缩短开发周期、优化供应链的需求。 缩短开发周期的关键，在于三星公司的全产业链掌控能力，为加速迭代提供了坚实基础，内部完成从基础裸片生产、内存堆叠到封装的全流程，并已拥有适配其 HBM 业务的理想基础裸片解决方案。
当你在自己开发的软件中，用画布管理上百个会话，上百万文字。软件完全开源，完全为了自己使用特化有多爽 每一个卡片都是传统的一个对话窗口，只能说太爽了 7 个帖子 - 3 位参与者 阅读完整话题
关于 opencode go 订阅，想入手一个作为日常开发的兜底，有佬友订阅过吗？速率和用量如何？ 6 个帖子 - 5 位参与者 阅读完整话题
IT之家 4 月 18 日消息，谷歌开发者博客昨日（4 月 17 日）发布博文，宣布在安卓 17 Beta 4 更新中，计划主动终止占用资源过高的应用， 强制执行设备级内存限制与异常检测服务。 在安卓 17 Beta 4 更新中，谷歌为了进一步优化设备性能，引入基于设备总内存的应用内存限制机制。这一机制旨在通过设定确定性的内存边界，解决因个别应用内存失控导致的系统级不稳定问题。 该机制会实时监控异常服务，强制终止超出基准线的应用，倒逼开发者优化臃肿软件，解决卡顿问题。 在之前的安卓版本中，应用可使用的内存上限主要受限于 largeHeap 属性以及系统整体的内存压力（LMK - Low Memory Killer 机制）。 这种模式虽然灵活，但容易导致“劣币驱逐良币”， 单个内存泄露严重的应用可能占用过多资源，导致系统频繁杀后台、UI 卡顿甚至整机重启。 IT之家援引博文介绍，在安卓 17 系统中，系统根据设备的物理内存总量， 为应用设定了明确的内存使用上限。 在安卓 17 Beta 4 阶段，谷歌限制设定较为保守， 主要目标是建立系统基线，精准打击“极端内存泄漏”和“异常值”应用， 当应用的内存占用触及该上限后，系统将介入干预，防止其继续分配内存。 为协助开发者排查内存问题，Android Studio Panda 版本在性能分析器中集成了 LeakCanary 任务，并提供基于触发器的性能分析功能，可在应用触发内存限制或检测到异常行为时自动收集堆转储数据。 当应用因触及内存限制被终止后，系统会在 ApplicationExitInfo 的 getDescription () 方法中返回字符串标识 MemoryLimiter。开发者可以通过监听此标识，快速判断应用崩溃是否源于新的内存限制策略。 Android Studio Profiler 中的 LeakCanary 任务 该机制的核心目标是创造更稳定、更确定的运行环境，阻断因单个应用内存溢出引发的系统连锁反应（如 System UI 重启、设备发热），官方预计绝大多数合规应用不会受到此限制的影响，主要影响对象为存在严重内存泄漏或过度优化的异常应用。
best权重是个软链接，指向具体的权重文件。我以为ChatGPT能反应过来，结果直接一下全删了。给的默认权限，现在删文件都不需要审核了！奥特曼对自家模型也太自信了 尤其是ChatGPT在闯祸之后还一种无所吊谓的语气，真是气死我了！ 重新训练吧… 4 个帖子 - 3 位参与者 阅读完整话题
IT之家 4 月 18 日消息，广汽集团 4 月 17 日宣布正式组建全新智能座舱产品线，这是继整车与动力总成业务单元相继落地并高效运转后，广汽集团自主板块在智能化领域布局迎来的又一次关键里程碑。 IT之家从文中获悉，当前，语音指令响应不及时、不同车型操作逻辑不统一、交互系统缺乏情感化设计等问题，正成为影响用户购车决策的关键因素。 过去行业普遍存在的“功能堆砌”模式 ，已难以满足用户对智能座舱的期待。为了从根本上打破这一困局，广汽集团组建独立的智能座舱产品线。 全新的智能座舱产品线将对座舱领域的 软硬件资源、研发能力、设计团队 进行系统性整合，统一负责全品牌的产品定义、技术规划与用户体验设计。通过打破原有技术边界，广汽集团将彻底告别“ 为了配置而配置 ”的开发思路。 在流程上，智能座舱产品线将贯通“用户需求-产品定义-技术开发-量产交付-持续迭代”的全生命周期，同时，深度嵌入整车开发体系，与各整车业务单元建立高效协同机制， 在车型规划最初阶段即介入 ，确保不同车型均能为用户提供有辨识度的 广汽 智能体验。 在核心能力上，智能座舱产品线将依托广汽自主研发的“ 星河智舱 ”系统，通过 AI 大模型、多模态交互等前沿技术，将用户洞察转化为精准感知、主动守护与个性化服务的核心能力，推动智能座舱从“被动响应指令”向“主动理解需求”跨越。
小弟最近刚使用claude code进行开发，但发现单纯发一个halo就会占据15%的上下文，这是正常现象吗？ 安装了ecc插件、但我通过/context查看，发现skill部分也就11k，大头是Messages部分，我该从哪些地方排查自己到底发送了哪些Messages呢？ 9 个帖子 - 4 位参与者 阅读完整话题
github.com GitHub - anthropics/claude-desktop-buddy: Reference and an example for the Bluetooth API for... Reference and an example for the Bluetooth API for makers in Claude Cowork & Claude Code Desktop [!quote]+ 适用于 macOS 和 Windows 的 Claude 可通过 BLE 将 Claude Cowork 和 Claude Code 与创客设备连接起来。 通过 BLE 将 Claude Cowork 和 Clude Code 与制造商的设备连接起来，这样开发人员和制造商就能构建硬件，以 显示权限提示、最近消息和其他交互。我们 围绕 Claude 的创客社区的创造力给我们留下了深刻印象。 提供一个轻量级、选择性的应用程序接口是我们的一种方式，它能让我们更容易地构建 提供一个轻量级、可选择的应用程序接口是我们的一种方式，可以让用户更轻松地构建与 Claude 集成的有趣的小硬件设备。 例如，我们在 ESP32 上制作了一个桌面宠物，它依靠许可 批准和与克劳德的互动。没事的时候它会睡觉、 在会话开始时唤醒，在等待审批提示时会明显不耐烦。 在等待批准提示时，它会表现出明显的不耐烦，并让你在设备上直接批准或拒绝。 3 个帖子 - 2 位参与者 阅读完整话题
在此记录一个在开发自测环节中遇到的问题: 先上代码(已脱敏) type TestData struct { Data []byte `json:"data"` } func TestTryEncryptoClient(t *testing.T) { jsonStr := "{\"Data\":\"4GFwsR9XFRkyb/9Hn14zNpQRFE4V/f1hLIDlnff6LLPR/EvRmSW6ma6PHZiamB4mDeynjRYfVsfipg==\"}" message := &TestData{} err := json.Unmarshal([]byte(jsonStr), message) if err != nil { panic(err) } result := message.Data t.Logf("%v", result) t.Log(string(result)) sprintf := fmt.Sprintf("%s", result) t.Log(sprintf) t.Logf("bad base64: %s", result) t.Log("test done") } 输出内容(goland)控制台 [224 97 112 177 31 87 21 25 50 111 255 71 159 94 51 54 148 17 20 78 21 253 253 97 44 128 229 157 247 250 44 179 209 252 75 209 153 37 186 153 174 143 29 152 154 152 30 38 13 236 167 141 22 31 86 199 226 166] 짍V��� 짍V��� 짍V��� xxx_test.go:193: test done 现象描述: 此段代码会造成如下代码片段未能输出 t.Logf("bad base64: %s", result) ，并且如果是多协程测试条件下，很可能会造成控制台卡住(无法输出后续内容) 原因分析: 在此过程中，我们错误使用了%s来匹配 []byte 类型的数据，虽然golang在编译或者goland在运行前检查中不会报错/warning，但是在最终输出的时候，由于 byte[] 中包含了不能被控制台解析的控制字符，所以会造成最终输出内容的错误(也可以叫做编码不匹配)，并且由于大部分编码都会兼容ASCII编码，在上述输出中会有byte为22的控制字符-> ASCII中描述为暂停等待同步字符，所以在多线程/协程测试中会导致控制台卡住等待同步完成 解决方案: 使用string现式包裹 []byte 即可 sprintf := fmt.Sprintf("%s", string(result)) 总结: 下次当遇到控制台卡住无输出的时候，记得检查是不是%s遇上了 []byte 类型的数据(常见某些加密流中的测试，用于观察加密后的字符输出) 1 个帖子 - 1 位参与者 阅读完整话题