小白开发插件，在期间看文件的时候学到的一些东西，特地分享给大家： 博文链接： 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、前端工程化，很多概念都会互相打通。 2 个帖子 - 2 位参与者 阅读完整话题
目前规划是前期公益 后期盈利， 后期想把大部分模型都上上实现盈利， 本人做抖音直播短视频的 所以推广问题不大， 考虑是自身技术有限，所以想找一些大佬作为云股东一起建设，后期可以爽蹬。 目前注册机注册速度很慢，解决不掉，需要找个有开发和解决中转站的大佬一起研讨 服务器啥的需要买个啥样的比较好，比如日本的美国的，我有个美国表弟后期我懂点了可以在他家部署个正儿八经的家宽服务器，然后我用他的卡 买opus4.7的api接入站内就可以实现纯血了 然后我再混点反代 就可以实现盈利了！！！哈哈哈哈哈哈哈哈哈 不好意思跑题了，奸商的嘴脸又暴漏了，我只是想了解下逻辑 为啥可以掺着卖。。。 回归正题，云股东依旧可以长期享受爽蹬 但是前提是要有贡献共同维护好站点， 相比大家都在公益站上来回徘徊，是因为我觉得大部分公益站都没有赢利点必然不长远嘛， 如果有赢利点 战长可以有维护成本 这个事必然会长远一点， 小白也只是有点自己的见解而已，欢迎大家毛遂自荐，时间充足的，有能力解决问题的， 包括我也想把那个即梦注册机看看咋可以变成api直接导入到AI漫剧对接下 最好， 目前就买了一个域名，下一步买个服务器，求大家推荐下，一步步的来。 服务器我还自己做了一个网站和小程序我也需要放在上面，注册机我也放在上面， newapi也部署上面去，然后最好是可以养个小龙虾在上面 平时就可以遥控龙虾直接在服务器上修newapi了 是这个样的吗 球大佬指点一二。 28 个帖子 - 8 位参与者 阅读完整话题
个人声明 本人为小白，只是提出一种可能的猜测，分享出来，并非绝对如此，请理性看待。 本人并非专业人士，请保持怀疑态度。 疑似被阉割的Claude Opus 4.7 2026年4月16日，A社发布了它们的新模型。 在发布后的几天内，几乎如潮水般的吐槽涌现——人们纷纷表示新模型的问题令人烦恼，我简单总结几点： 1.不说人话 2.上下文倒退 3.分词器更换，价格变相增高。 4.自适应思考不稳定 此外，A社着重削弱了其在网络安全方面的能力，相较于Opus 4.6模型，低了0.7% 项目 Claude Opus 4.7 Claude Opus 4.6 Cybersecurity vulnerability reproduction (CyberGym) 73.1% 73.8% 从中，我似乎感觉到一种感受：这个最新的Opus 4.7 模型，甚至并不如前作Opus4.6，或者说，简直像换了一个模型。 甚至诞生了关于它们的有趣图片： Opus 4.7 Opus 4.6 的确，Opus 4.7在各个方面似乎都差于Opus 4.6，不稳定…记不住事情…说话像GPT，这甚至可能令人思考——这到底是不是一个新发布的Opus模型。 神秘的Claude Mythos Preview 在Opus 4.7 推出前，A社曾泄露了它们的前沿模型消息，Mythos（卡皮巴拉），借着这张模型对比图，我们也许可以略窥一二它可能达到的强大（因为截至目前为止，大部分人无法使用这个模型，A社向部分B端提供此模型，并且貌似放弃了C端市场） Claude Mythos Preview 几乎全面领先于 Opus 4.7，也远远超越其他模型。 当然，它的价格让人无奈，我列出一个表格来使对比更清晰对比 模型 输入价格 (每百万 token) 输出价格 (每百万 token) Claude Mythos Preview $25 $125 Claude Opus 4.6/4.7 $5 $25 Claude Sonnet 4.6 $3 $15 Claude Haiku 4.5 $1 $5 Claude Mythos Preview的价格相较于Opus翻了5倍，这种恐怖的价格也许与其的模型参数量有所关系，大多人猜测，这个价格恐怖的模型大概率参数量一样是 Opus 模型的数倍。 订阅套餐的额度提升 翻译：Opus 4.7 使用了更多思考代币，因此我们提高了所有订阅者的速率限制以弥补这一点。祝你玩得开心！ 据佬友测试，pro账号的5h，7d，可能已经全部翻倍，其他订阅目前我尚未得知。 这与我的标题有什么关系? 我们可以将前面的线索串联起来，首先，A社发布了一个新的Opus（4.7）模型，而此模型，综合方面甚至不如旧版本的Opus（4.6）。 那么，推出这个模型的目的大概率不是为了让人去辱骂它们（因为它们大概率已经自己使用过了，也应该知道这个最新模型的问题。） 在前面我们得知，Claude Mythos Preview 的价格是极为昂贵的，且不面向大多数C端。 而这时有一个很重要的问题需要确认，因为它关乎我的论点。 那就是——Claude Mythos Preview 是怎么来的：我猜想它是源于Opus 4.6。 此外，我需要提到一种可能，Claude Mythos Preview也许有可能是A社重塑的一个全新模型，与Opus 4.6 毫无瓜葛，这都是可能是，所以理性看待我的想法——它并不准确。 Opus 4.6 几乎是一个强大的模型，它稳定，上下文强大，说话清晰易懂，几乎没有任何语料污染。 也许在此基础上，A社投入巨大将其的参数量堆到一个恐怖的规模，造就Claude Mythos Preview 的恐怖能力，但同时，它的价格也过于高昂，导致无法完美的使用它（算力，种种因素束缚着这个模型） 同时，A社也许自认为已经将这条路堆到了极限。 所以它们需要转型——Opus 4.7。 一个很有意思的点是，Opus 4.7 使用了新的分词器，我并没有学习过大模型的种种，但我意识到这可能是一个巨大的变化，A社重构了Opus 4.7这个模型，目前的新模型是一个新的基础开始。 请辩证看待，怀疑看待，这段话可能不对，我并不了解大模型，我只是猜测。 并且这也许有所佐证，Opus 4.7 与Opus 4.6的上下文简直是大变样。 所以我提出一个大胆的假设： Claude Mythos Preview 是一个已经走到头的方向，它昂贵，且难以进步 所以A社推出了新的模型——Opus 4.7 面向B端进行试水，它大概率是一个全新的模型，用于转型，他们也许希望制造出更便宜，更好用的模型，因为原有的路可能无法走通。 而这时，庞大的C端是一个完美的地方。 大概率佬友们都知道，A社的官方Claude订阅额度是非常之高的，在A社增加所有订阅配额前，大概是这样 套餐 5h $ 限额 7d $ 限额 月 $ 限额 Pro ($20) $4.1 $37.5 $163 Max 5× ($100) $24.8 $312.5 $1,354 Max 20× ($200) $82.5 $625.0 $2,708 而如今参考pro订阅翻2倍的案例，我们得知，pro额度目前的月限额大概为：300美刀。 我不能去揣测max套餐的额度，因为我并没有这方面的知识，所以我们假设——这三个套餐都有一定量的提升。 但是为什么？ 为什么A社这个几乎抠门的骨子里的公司要提升额度？？？ 我们知道，目前的订阅已经是赔本了（即使会降智，我猜测这是一种采集完数据后降本的策略，因为前几个月已经采集到了足够的信息） 那么它为什么要再次提升额度？ 我想，是因为新的Opus 4.7 模型，如果A社想要获得更多信息，那么提高配额是一个绝妙的点子。 能看出来其实目前的A社套餐便都是赔本订阅，人们花着极少的钱购买到了远超数倍的体验。 A社为什么要推出这些套餐？A社是为了打市场吗？我想——这可能与模型有关。 每次出新模型后都会高智商，随后降智——这也许是吸取到了足够数据后的降本。 而目前，Opus 4.6依旧降智，人们需要去使用Opus 4.7 ，全新的更多配额让更多的人去使用Opus 4.7，那样的数据也许是极为重要的。 5 个帖子 - 4 位参与者 阅读完整话题
先说一下自从我加入了论坛的确学习到了很多以前没有接触到的技术，也有看到佬们有发帖说现在论坛讨论技术的少了反而都在分享AI、公益站以及抽奖相关内容。自我感觉现在在AI疯狂迭代更新的时代这也算比较正常的，但是我也更想有更多大佬们的技术分享，从而填充自己。回想以前看L站主要是看搞怪三七的佬们的经典发言，但是现在佬们应该是本着不学习就等于退步原则都在努力学习，现在的搞怪三七的搞怪内容也没有以前的多了。 随着现在codex基本上已经死了，现在也不会侵犯谁的利益等，所有想抱着不懂就问的学习态度想就以下内容请佬们帮忙解惑，万分感谢 佬们经常说的反代，是不是可以理解为我用国内的网络想去访问哪些不支持国内的模型就需要类似转发服务。比如我买一个国外的云服务器然后利用CPA这样的形式进行访问 我看很多佬都在自己建中转站，那我比较好奇的是，佬们是在本地电脑上进行注册GPT然后CPA生成的JSON上传到服务器上还是直接在服务上进行注册 佬们在搞注册机注册的时候是不是会有一个代理池然后从里面拿ip进行注册 如果说我的服务器是美国的那么我还用去挂代理换ip吗。是不是可以直接用云服务的ip 还有一点疑问就是佬们的云服务应该都是用的linux的系统，那么要怎么装代理软件操作什么的。 文采不好写的可能没有什么逻辑也是想到什么说什么，原本在没写的时候有很多疑问现在写这写这就想不起来了，恳求大佬帮忙解惑讨论 1 个帖子 - 1 位参与者 阅读完整话题
我个人觉得佬们需要思考的问题不是vibe coding的影响问题。而是你做的东西价值在哪里？能解决什么问题？为什么客户要付费买这个服务，为什么找你做/买这个服务！ 6 个帖子 - 5 位参与者 阅读完整话题
大火的 Hermes AI Agent 小白如何整 想在 Windows 上使用 却被 WSL2 和复杂的环境配置劝退？ 一键脚本来了，附视频教程 M.'s Blog – 17 Apr 26 Windows 一键部署 Hermes AI Agent 小白也能玩转 NousResearch 大模型！ 想在 Windows 上体验强大的 NousResearch Hermes AI Agent，却被 WSL2 和复杂的环境配置劝退 2 个帖子 - 2 位参与者 阅读完整话题
今天看到一篇帖子： 10年内，小白和大牛用ai工具vibecoding，能做到几乎没差别吗 我看完了下面的所有的评论，在我自己所在一些AI群里曾经看到过好多次群友提出类似的问题，我跟身边的同事朋友也经常会谈论到这样的话题，我其实已经做了一些Research，所以与其在帖子下面留言，我想自己开一篇表达一下自己的想法。 本篇完全手搓，不过有借助AI整理思路和提纲同时做数据收集，希望是合规的，如果不是也请告知，今天是我入L站的第二天 。 首先我自己的工作是某大厂的IT项目经理，管理开发团队10年有余，团队里一大把30年以上工作经验的资深构架师和程序员，我自己爱人也是20年以上的Senior SW Engineer，当然也有不少大学刚毕业的实习生和毕设学生。所以对于我以下所提到的观点和结论自认还是站得住脚的。 关于Vibe Coding, 应该追溯到2025 年 2 月，Andrej Karpathy 发了一条推文，定义了一种新的编程方式：完全沉浸在感觉里，拥抱指数级增长，忘掉代码本身的存在。他管这叫 vibe coding 。 这条推文截止我写文现在已经有了 680 万次浏览。同年11月，Collins 词典把它评为年度词汇。 现在 2026 年已经快过去一半，92% 的美国开发者已经在用 AI 编程工具，GitHub 上 46% 的新代码由 AI 生成。一个 85 亿美元的市场，从一条推文里长了出来。 但一个问题也跟着浮出水面： 小白用 AI 写代码，做出来的东西 bug 满天飞，项目稍大就是屎山。大牛用同样的工具，生产率却在飞涨。 （源于原帖主） 随着 AI 工具不断进化，小白和大牛之间的差距会缩小吗？10 年后，一个编程零基础的人，能靠 vibe coding 做出和资深工程师一样水平的东西吗？ 这个问题的答案能决定不少人的命运，至少几百万吧。如果 AI 能抹平差距，"学编程"这件事的意义就要被重新定义。如果相反差距在扩大，那正在用 vibe coding 做项目的小白们，可能正在铤而走险。 为什么这么说呢？我们来看下面这组数据。具体数据来源参考最后的参考链接。 数据给出了一个反直觉的答案： 用了 AI 反而更慢 2025年 一个叫 METR 的研究机构做了一项严格的随机对照试验，让 16 名资深开发者完成 246 个编码任务。用 AI 工具 （Cursor+Claude) 的那一半，完成速度 慢了 19% 。但魔幻的是他们自认为快了 20%。感知和现实之间差了 39 个百分点 。 与此同时，高级开发者报告了 81% 的生产力提升，32% 的人超过一半代码由 AI 生成。初级开发者呢？只有 13% 达到同样比例，Anthropic 的研究还发现他们的代码理解力 下降了 17% 。 同一个工具，让强者更强，弱者更弱。 工具救不了判断力 我至今所看到的小白卡的几个地方： 描述不清需求。 小白说"帮我做个登录功能"，大牛会指定 JWT 认证、bcrypt hash decrypt、rate limiting、OAuth2。两个 prompt 产出的代码质量天壤之别。大牛脑子里有完整的安全威胁模型，小白根本不知道自己漏了什么。 看不见安全漏洞。 2026 年初，安全公司 Escape 做了一项大规模扫描。他们检查了 5600 个公开部署的 vibe coding 应用 。发现 2000 多个高危漏洞和 400 多个泄露的密钥。 Veracode 的研究更系统，他们测试发现 45% 的 AI 代码含 OWASP Top-10 漏洞，两年的模型改进没有改善这个数字。对小白来说 AI 输出是黑盒，对大牛来说是白盒。 屎山不可避免。 AI 生成的代码是局部最优的。没有人在全局层面做架构决策，完美的代码片段拼在一起也会变成灾难。项目越大，这个问题越致命。 Token 消耗就是知识税。 大牛一个精确的 prompt 就能拿到正确代码，小白可能要 10 轮对话、5 次返工、3 次推倒重来。多出来的 token 本质上是在为"不知道自己要什么"和"不知道怎么判断结果好坏"付费。你的知识越少，同样的结果你付出的代价越高。 大牛的 81% 从哪来 高级开发者的提升来自三件事： 用 AI 消灭样板代码等重复劳动 用 AI 加速对陌生技术栈的探索 用 AI 扩展自己的能力边界（比如后端工程师用 AI 写前端）。 这三件事有一个共同前提：你得有足够的知识来判断 AI 输出的质量。AI 工具越强大，能执行的指令越复杂，而越复杂的指令越需要深厚的技术功底才能发出。 就像给所有人一架钢琴。钢琴越好，郎朗和初学者之间的差距越明显。好钢琴能更忠实地反映演奏者的水平。 回到原帖的问题：十年后会怎样 我想大概有三种可能。 地板上升： 小白从 20 分涨到 80 分，大牛从 90 分涨到 99 分。差距缩小了，但当所有人都能做到 80 分时，80 分就不值钱了。就像智能手机让人人都能拍出 80 分的照片，但专业摄影师并没有失业。 差距扩大： 如果 AI 工具继续朝"更强大的 agent"方向发展，高级用户获得更多控制权，初级用户并没有获得更多保护网。差距可能从 2 倍变成 10 倍。 职业重构： 如果 AI 能自主完成从需求到部署的全部工作，"程序员"这个职业本身会被重新定义。写代码的差距消失了，但"理解问题"和"做决策"的差距可能更大。 最准确的判断可能是按项目规模来分：做小应用，差别不大。做平台级产品，差距依然巨大。 回到本帖的问题 Vibe Coding 能抹平小白和大牛的差距吗？ 我的回答是：在某些维度上，差距会缩小到可以忽略。在另一些维度上，差别会大到让人绝望。 而决定你站在哪一边的，从来 都是你脑子里装了什么。 如果觉得这篇对你的认识的更新产生了影响，请点一个免费的小心心 ，也欢迎留言表达你的想法。 参考链接 METR 研究：AI 工具让开发者慢了 19% particula.tech – 13 Mar 26 AI Coding Tools Make Developers 19% Slower: What the Research Says A gold-standard RCT found experienced devs are 19% slower with AI tools—while believing they're 20% faster. Here's what the data actually means for your engineering team. The state of vibe coding in 2026 hashnode.com The state of vibe coding in 2026: Adoption won, now what? tldr: 92% of US developers use AI coding tools daily. 46% of new code is AI-generated. Trust in that code has dropped from 77% to 60%. Vibe coding won the adoption war. The quality war is just startin Forbes: Vibe Coding Has A Massive Security Problem https://www.forbes.com/sites/jodiecook/2026/03/20/vibe-coding-has-a-massive-security-problem/ 高级开发者 81% 生产力提升 https://blog.vibecoder.me/vibe-coding-for-senior-developers 24 个帖子 - 16 位参与者 阅读完整话题
开发调优 > 开发调优, Lv1 背景 小白是前一个月刚入站的小萌新，刚毕业快满一年，从事的工作方向也是机器人控制这一块，在某些时候也需要用到AI coding辅助我进行开发思路，去年最开始尝试的是trae，那时候的trae反馈一般，后来基本上还是古法开发，一边问AI，利用AI提供的思路结合自己的经验去进行开发 随着后面的Cursor等软件的盛行，基本上用的是Cursor这个软件，但是这个软件的Pro+花费还是有点太贵了，有些肉疼，不是因为这个套餐，是因为这个cursor给的额度属实是有点低，配合这个IDE，用着属实不习惯。 接着就是claude盛行，再到后面的codex等等，后来发现更适合我的还是像vscode和cli这种形式， 目前尝试的方案 之前尝试用了别人的中转站，但是结合在L站看佬们发的一些经验贴，发现之前的某鱼的中转站实在拉跨，模型估计也是套壳 后面考虑直冲claude的账号，用了一个月，plus，观感确实不孬，使用体感也还行，后面还用了codex，性价比也不错 求教，想咨询各位佬目前针对coding以及hermes Agent这种的API所选择的方案是什么 目前尝试的方案 今天尝试了两位佬分享的注册机使用以及古法手搓GPT账号的教程，估计是因为自己IP不稳定的原因，古法注册GPT的后面还是弹出手机号的验证，试了很多次无望，结合自己的一些困惑，因此有了这篇求教贴 之前也尝试使用了GLM以及minimax的套餐，用minmax的套餐来进行openclaw等智能体的API，但是实际上质量确实堪忧，回答质量这一块，GLM的套餐已经是抢不到的状态了 之前打算用佬们的公益站来着，比如冰佬等等，但也不好意思白嫖，所以也没用哈哈哈 疑问点 求教点 佬们目前选择的方案是什么，针对AI coding这一块自己搭建还是选择了什么方案，选择的方案有什么需要注意的地方捏 像Hermes Agent，Astrbot等框架，佬们的评价是什么，是否有必要搭建一个属于自己的智能体助手，与此对应的API key如何拥有性价比的方案去选择搭建呢 萌新第一次发帖，发帖之前已经严肃阅读社区准则，请佬们多多指教 12 个帖子 - 7 位参与者 阅读完整话题
有没有大佬给指点下 这个注册机是咋配置的 纯小白， 不知道用哪个邮箱注册率高啊 节点啥的 我都不会搞T T 现在用的 协议 古法用了一下 注册不上呢 1 个帖子 - 1 位参与者 阅读完整话题
如题，render总是要求验证信用卡，新人小白没有信用卡要怎么解决 1 个帖子 - 1 位参与者 阅读完整话题
25年毕业，刚入职半个月，岗位AI全栈开发（前后端，微调全都干 ）薪资12k，公司总共10人，天天自掏腰包买gpt pro和一些中转站来进行开发，整天的工作内容就是调试提示词，一点代码开发都不涉及。我们有两个老板，一个懂技术一个不懂，不懂的那个是只投钱的那种，我们开发部就两人，调了半个月提示词，另一个老板的需求像在许愿，我们做的就是电商方面的，生成商品图片，他想在只提供几个图片的情况下让大模型生成一个尺寸和现实中尺寸相差无几的那种，还要让AI去精修原来的图片让它看着更值钱更有质感（听到这个就有点麻，这应该取决于模型的能力吧，还是在白底的情况去弄），感觉进来啥也没学到，开发也没有，佬友们我该不该辞职重新找一个 4 个帖子 - 3 位参与者 阅读完整话题
小白想问下各位大佬们，你们有没有使用上claude opus 4.7，体验咋样，求分享 3 个帖子 - 3 位参与者 阅读完整话题
现在肯定不行，现在小白用ai工具vibecoding，只能弄出来各种bug和各种漏洞的玩具，项目稍大点就是屎山。但大牛却能把ai工具用出花来，生产率噌噌噌的提高。 但10年内，随着ai工具的不断进化，小白vibecoding出来的东西能达到大牛的水平吗。 9 个帖子 - 9 位参与者 阅读完整话题
只说国产也都是在聊Qwen，GLM， 为啥之前火出圈的DeepSeek现在不名不见经传了。我本人一直用CodeX和Gemini，国内的就体验过Qwen。 15 个帖子 - 15 位参与者 阅读完整话题
感觉这个opus4.7就是参照现有模型的分数制作的，每项分数都超过现有最高模型一点（或接近），但又不会高的离谱，这是要学硬件厂家挤牙膏吗 其它厂家发模型也有点难了，数据是要超opus4.7，还是超mythos 4 个帖子 - 4 位参与者 阅读完整话题
（话题已被作者删除） 1 个帖子 - 1 位参与者 阅读完整话题
因为现在CLAUDE貌似很难搞作为小白在咸鱼买来先试试刚入坑。。 按DEEPSEEK说的应该是假无疑了 有的检测出来只有21另外一个网站测出来 这个网站测出来显示都是通过但是我一看答案全部是不对的 我是不是买到垃圾了？ 11 个帖子 - 4 位参与者 阅读完整话题
Additional features Daily included routine runs You haven’t run any routines yet小白快去研究 4 个帖子 - 4 位参与者 阅读完整话题
本人是一个刚入门的新手小白，在配置codex的时候遇到问题，前来求助各位佬。 如图所示，我在某公益站上的账户余额是有的，在我配置到cc switch上，选择配置如下 结果弹出额度不足，同时，在选用其他中转站 时常提示如下，可是登录iu中转站上是能看到对应模型的。向各位佬们求助 8 个帖子 - 5 位参与者 阅读完整话题
1.我想使用自己的api，是要安装continue插件对吗？ 2.vscode和antigravity有什么不同？gemini和我说如果我希望ai能够自动修改代码、新建文件或者是跑终端命令之类的内容，需要再安装别的插件，是这样吗？ 3.公益站的带cc后缀或者是codex后缀的是不是需要装cc或者codex插件？ 4.之前都在antigravity上傻瓜式使用，现在还没懂应该做点什么能还原之前在antigravity上的用法，请佬们帮忙解惑 1 个帖子 - 1 位参与者 阅读完整话题