2026年1月

Burp Suite Professional 2026.1 发布，新增功能简介

Burp Suite Professional 2026.1 (macOS, Linux, Windows) - Web 应用安全、测试和扫描

Burp Suite Professional, Test, find, and exploit vulnerabilities.

请访问原文链接：https://sysin.org/blog/burp-suite-pro/ 查看最新版。原创作品，转载请保留出处。

作者主页：sysin.org

Burp Suite Professional，更快、更可靠的安全测试，领先的 Web 安全测试工具包。

roadmap

Burp Suite Pro 简介

Burp Suite Professional 是一套用于测试 web 安全性的高级工具集 —- 所有这些都在一个产品中。从一个基本的拦截代理到尖端的 Burp 扫描器，使用 Burp Suite Pro，正确的工具只需点击一下就可以了。

强大的自动化让您有更多的机会做您最擅长的 (sysin)，而 Burp Suite 处理容易实现的目标。先进的手动工具将帮助你识别目标更微妙的盲点。

Burp Suite Pro 是由一个研究团队开发的。这意味着在发布之前，发现成果已经包含在最新更新中。 pentesting 工具将使您的工作更快，同时让您了解最新的攻击向量。

Burp Suite 专业版

新增功能

Professional / Community 2026.1

2026 年 1 月 16 日

本次版本引入了 Discover 选项卡、通过命令面板实现的更快表格导航、更智能的 SQL 注入检测、对 NTLM 的 SPNEGO 支持，以及其他改进内容，同时还包含一次 Java 更新和浏览器升级。

✅ 使用全新的 Discover 选项卡探索 Burp

已将原有的 Learn 选项卡替换为 Discover，这是一个经过精心策划的起点，旨在帮助你探索 Burp Suite 的全部潜力。Discover 会根据你所使用的版本重点展示关键功能、工作流程和学习资源 (sysin)，帮助你最大化利用当前可用的工具。

无论你是刚开始使用 Burp、在打磨成熟的工作流程，还是借助 Burp AI 提升技能，在 Burp 中始终都有新的内容值得探索。

✅ 通过命令面板实现更快的表格导航

现在，你可以使用命令面板在 Burp Suite 中的大多数表格里快速跳转到指定位置。新增了三个命令：

  • Go to top： 跳转到所选表格的第一行
  • Go to bottom： 跳转到所选表格的最后一行
  • Go to entry： 根据条目 ID 跳转到指定行

这些功能让你在不滚动、不丢失当前位置、也无需反复调整过滤条件的情况下 (sysin)，更快速、更轻松地浏览大型表格。

✅ 更智能的基于时间的 SQL 注入检测

Burp Scanner 现在会过滤由 Web 应用防火墙（WAF）对可疑载荷进行延迟处理而导致的误报。这在此类场景下提升了对真实基于时间的 SQL 注入漏洞的检测准确性。

✅ 通过 SPNEGO 支持 NTLM 身份验证

Burp 现在可以配置为使用 SPNEGO 编码来处理 NTLM 令牌。

✅ Java 更新

已将 Burp 使用的 Java 版本更新至 Java 25.0.1。

✅ 浏览器升级

已将 Burp 内置浏览器升级至 Chromium 143.0.7499.193（Windows 与 Mac），以及 143.0.7499.192（Linux）。

下载地址

Burp Suite Professional 2026.1, 16 January 2026

Architectures/DescriptionFile name (Professional)
Apple Intel x64 Installerburpsuite_pro_macos_x64_v2026_1.dmg
Apple ARM64/M Chips Installerburpsuite_pro_macos_arm64_v2026_1.dmg
Linux x64 Installerburpsuite_pro_linux_v2026_1.tgz
Linux ARM64 Installerburpsuite_pro_linux_arm64_v2026_1.tgz
Windows x64 Installerburpsuite_pro_windows-x64_v2026_1.exe
Windows ARM64 Installerburpsuite_pro_windows-arm64_v2026_1.exe

for macOS：Burp Suite Professional 2026.1 for macOS x64 & ARM64 - 领先的 Web 渗透测试软件

for Windows：Burp Suite Professional 2026.1 for Windows x64 - 领先的 Web 渗透测试软件

更多：HTTP 协议与安全

本文的目标是解释为什么现代LLM架构在前馈部分使用

SwiGLU

作为激活函数并且已经放弃了

ReLU

。

神经网络本质上是一系列矩阵乘法，如果我们堆叠线性层而不使用任何激活函数：

无论你堆叠多少层，它仍然只是一个线性变换，网络只能学习线性关系。

激活函数引入了非线性，使网络能够逼近复杂的非线性函数，这是深度学习表达能力的基础。

ReLU有什么问题？

ReLU

确实彻底改变了深度学习：

它简单、快速，并且解决了

sigmoid

或

tanh

等函数存在的梯度消失等问题。

虽然人们通常会列出使用

ReLU

时可能遇到的问题，比如神经元死亡等等，但这些问题要么是理论上的，要么在大多数情况下可以通过现代神经网络技术（批量归一化、自适应学习权重等）很好的避免。

不过在进入SwiGLU之前，我们先来看一个激活函数 Swish，它是 SwiGLU 的组成部分。

Swish是一个"自门控"激活函数：输入 (x) 乘以其自身的sigmoid σ(x)，它充当一个门，控制有多少输入能够通过。

看看门的行为：

当x非常负时：σ(x) ≈ 0，所以门是关闭的（抑制输出）

当x非常正时：σ(x) ≈ 1，所以门是完全打开的（几乎原样通过输入）

尽管公式稍微复杂一些，

Swish

的行为与

ReLU

非常相似。

Swish比ReLU更好吗？

Swish

被发现比

ReLU

效果更好，但就像深度学习中的许多事情一样我们并不确切知道为什么

Swish

效果更好，不过倒是可以总结出以下的区别：

没有硬梯度截断

看上面的图，主要区别就是它们如何处理负输入：

ReLU：在零处硬截断

当x<0时：输出 = 0 且 梯度 = 0。这就是神经元死亡问题（尽管如前所述，通常可以通过BatchNorm等现代技术来避免）

Swish：平滑、渐进地趋近于零

对于负x：梯度渐近趋近于零，但对于有限值永远不会精确等于零/所以理论上神经元总是可以接收更新（尽管对于非常负的输入，更新可能可以忽略不计）

平滑性

ReLU

在x=0处有不连续性（导数从0跳到1）。

Swish

在任何地方都是无限可微的，这意味着梯度景观是平滑的。这种平滑性是否有助于

Swish

的性能还不是100%清楚但它可能有助于优化

什么是门控线性单元（GLU）？

下面就是

SwiGLU

的另外一个组件。让我们来谈谈 GLU。

其中：

x是输入

W 和 V 是权重矩阵

b和c是偏置向量

⊙ 是逐元素乘法

σ 是sigmoid函数

GLU

使用门控机制在这方面与

Swish

有些相似。而它们区别在于GLU不是对所有特征应用相同的变换（恒等变换）然后用固定函数（sigmoid）进行门控，而是使用两个独立的线性投影：

xW+ b 这只是取输入并对其进行变换。它通常被称为 内容路径

σ(xV + c)：这第二部分说明每个特征的内容应该让多少通过，因此它被称为 门路径

所以GLU

实际上可以被认为是

Swish` 的泛化

逐元素乘法 ⊙ 允许门选择内容的哪些元素可以通过。当 σ(xV + c) 接近0时，门可以完全抑制某些特征，而当 σ(xV + c) 接近1时则完全让其他特征通过。

门控的具体示例

假设我们有一个4维向量 x = [1.0, -0.5, 2.0, 0.3]

GLU对同一个输入应用2个变换：

  1. 通过内容路径对内容进行变换：xW + b。假设它产生 [2.0, -1.5, 3.0, 0.5]1. 第2个变换应该扮演门的角色： σ(xV + c)。假设它产生 [0.9, 0.1, 0.95, 0.05]

GLU输出是它们的逐元素乘积：

GLU output = [2.0 × 0.9, -1.5 × 0.1, 3.0 × 0.95, 0.5 × 0.05] = [1.8, -0.15, 2.85, 0.025]

得到的结果如下：

特征1：内容为正（2.0），门值高（0.9）→ 强烈通过（1.8）

特征2：内容为负（-1.5），门值低（0.1）→ 被阻挡（-0.15）

特征3：内容为正（3.0），门值非常高（0.95）→ 完全通过（2.85）

特征4：内容较小（0.5），门值非常低（0.05）→ 被抑制（0.025）

这样网络学习了复杂的决策规则："对于像x这样的输入，放大特征1和3，但抑制特征2和4。"

那么SwiGLU是什么？

现在我们有了所有的组成部分，

SwiGLU

（Swish门控线性单元）简单地结合了Swish和GLU：

它不是像GLU那样使用sigmoid作为门，而是使用Swish。这就是为什么它被称为 Swish + GLU。

那么公式的每个部分做什么呢？这与GLU的逻辑完全相同，改变的只是门控函数。

  • Swish(xW)：门——决定每个特征有多少可以通过
  • xV：内容——正在传输的实际信息
  • ⊙：逐元素乘法——将门应用于内容

为什么SwiGLU效果这么好？

从经验上看，SwiGLU在LLM中优于其他激活函数（尽管目前还不确定VLM的情况）。但为什么呢？

乘法交互创建特征组合

考虑每种架构计算的内容：

标准FFN（ReLU/GELU）：

output = activation(xW₁) @ W₂

每个输出维度是激活特征的加权和，激活是逐元素应用的——特征在激活内部不会相互交互。

SwiGLU FFN：

output = (Swish(xW) ⊙ xV) @ W₂

逐元素乘法 ⊙ 在两条路径之间创建乘积。如果我们用 g = Swish(xW) 和 c = xV 表示，那么在最终投影之前的输出维度 i 是 gᵢ × cᵢ。

这就是为什么这很重要：gᵢ 和 cᵢ 都是输入特征的线性组合（在Swish之前）。它们的乘积包含像 xⱼ × xₖ 这样的交叉项。网络可以学习 W 和 V，使得某些输入特征组合被放大或抑制。

这类似于为什么注意力机制很强大，注意力计算 softmax(QKᵀ)V，其中 QKᵀ 乘积捕获查询和键特征之间的交互。SwiGLU为FFN带来了类似的乘法表达能力。

为什么不在门中使用sigmoid而是使用Swish？

GLU使用sigmoid：σ(xW) ⊙ xV。sigmoid的问题在于它会饱和。对于大的正或负输入，σ(x) ≈ 1 或 σ(x) ≈ 0，且梯度 ∂σ/∂x ≈ 0，门就会被“冻结”了。

Swish对于正输入不会饱和，它近似线性增长（就像

ReLU

）。这意味着：- 梯度通过门路径流动得更好 - 门可以调节而不仅仅是开/关切换

平滑性

另外就是SwiGLU是无限可微的，这种平滑性可能有助于优化稳定性。

总结

SwiGLU的强大来自于其门控机制和乘法交互。通过将输入分成两条路径并将它们相乘，网络可以学习哪些特征组合是重要的——类似于注意力机制如何通过 QKᵀ捕获交互。

结合Swish的非饱和梯度，这使得SwiGLU对于大型模型特别有效。

https://avoid.overfit.cn/post/3fa28c75fb0b4874aa297defa145ec4a

作者：Safouane Chergui

告别“伪数字化”：AI 正在重塑人才招聘格局
过去十年，HR 领域掀起了信息化与数字化浪潮，ERP 系统引入、自动化流程设计，让招聘、入离职等事务实现了“系统化”。但如今，当绝大多数职场人已习惯与 AI 协同工作时，许多企业的招聘仍停留在“流程电子化”的初级阶段——筛简历依赖关键词，面试凭借主观感觉，低效与错失良才成为常态。

真正的变革源于“生成式 AI”的深度融入。它不再是被动应答的工具，而是能主动洞察、生成问题、辅助决策的智能伙伴，在人才甄选的全新竞赛中，依靠直觉与经验的传统招聘模式正加速瓦解。
传统招聘长期受“低效、主观、成本高”三大顽疾困扰，在激烈的市场竞争中愈发凸显弊端：业务部门急需人才，HR 却深陷海量简历无法高效筛选；面试安排耗时耗力，最终录用决策还可能依赖面试官的“眼缘”。这种不确定性，让企业付出了高昂的显性与隐性成本。
AI 招聘系统的出现，为破解这一困境提供了有效路径。其核心优势集中在“精准可衡量”与“体验人性化”两大维度，重新定义了智能化招聘的标准。
在精准度层面，先进的 AI 面试智能体成为核心引擎，让人才评估告别“凭感觉”的模糊地带。其评估结果通过了严格的效标效度与重测信度心理学检验，能与资深面试官达成高度一致，打分可直接作为关键招聘决策依据。具体来看，其一问多能，一道智能题目可同步评估多项核心胜任力，无缝衔接 HR 初筛与业务复试，使评估效率提升 50% 以上；能根据候选人的回答即时生成针对性追问，精准抓取关键信息，杜绝能力评估遗漏；可自动解析简历，定位关键成就与潜在模糊点，生成递进式提问链，既有效核实信息，也深度挖掘候选人真实潜力；同时覆盖沟通、协作等通用素质，还能针对编程、算法、财务、工程等专业领域精准测评，在解放 HR 的同时，减轻业务面试官初试阶段的重复劳动。
在体验层面，优质的 AI 面试系统突破了传统 AI 面“生硬、机械”的短板，将每一次面试转化为雇主品牌的加分项。系统能精准感知候选人的语速、语调与情绪波动，像专业面试官一样引导候选人放松，充分展现真实能力，避免因紧张导致评价失真；全程无需手动操作“开始/结束”，系统自动识别语音起止，实现如真人交谈般自然的问答流转，沉浸感十足；通过领先的音画同步技术，让虚拟面试官的口型、表情与语音节奏完美匹配，彻底告别“纸片人”式的机械感，赋予交互温度；候选人可随时就职位、团队、文化等问题发起提问，AI 基于企业知识库给予准确、一致的解答，在评估的同时完成高效的雇主价值传递。
当招聘进入智能化深水区，工具的选择直接影响人才竞争的胜负。AI 并非要取代传统招聘逻辑，而是通过技术赋能，构建出更精准、高效、人性化的人才甄选模式，推动招聘行业从“流程电子化”迈向“决策智能化”，为企业在人才战争中赢得先机。

Python的动态类型特质与WebAssembly的静态二进制本质，在系统接口层面形成了天然的张力，而ABI作为两者沟通的底层桥梁，其挑战远非简单的接口适配所能概括。在边缘计算与无服务器场景的实践中，这种张力尤为明显：Python依赖的动态类型推断、垃圾回收机制，与WebAssembly的线性内存模型、静态类型约定在语义层面存在深刻分歧，而ABI作为连接这两种异构体系的关键，必须在类型映射、内存访问、调用约定等核心维度实现无缝衔接，否则便会出现看似兼容实则逻辑断裂的隐性障碍。这种障碍并非表层的功能失效，而是底层语义的错位——当Python的对象模型试图通过ABI穿透到WebAssembly的线性内存时，类型标识的模糊、内存所有权的界定、生命周期的同步，都会成为难以逾越的深层博弈点。比如在物联网设备的边缘计算场景中，Python处理的传感器动态数据流，需要通过ABI传递给Wasm模块进行高效计算，此时Python对象的动态属性可能在转换过程中丢失语义，而Wasm的线性内存无法动态适配对象的伸缩，导致数据结构出现隐性错乱。更隐蔽的是，当Python的垃圾回收机制触发时，可能误回收仍被Wasm模块引用的内存块，而Wasm对内存的手动释放也可能导致Python侧出现悬垂引用，这种跨环境的生命周期不同步，往往在高并发场景下才会暴露为数据一致性问题，每一个细节的疏忽都可能导致整个集成体系的语义崩塌，这种崩塌往往隐藏在正常运行的表象之下，直到特定场景触发才会暴露其底层的不兼容本质。

类型语义的对齐缺失是ABI面临的首要核心挑战，这种缺失并非简单的类型不匹配，而是动态与静态类型体系在ABI层面的语义断层。Python中变量的类型可随时变更，对象的创建与销毁由垃圾回收机制自动管理，而WebAssembly的类型系统则是编译期确定的静态结构，每一个数据的内存布局、大小、对齐方式都在编译阶段固定，这种本质差异使得ABI在进行类型映射时，必须面对语义转换的巨大鸿沟。不同的WebAssembly运行时对同一类型的ABI定义可能存在细微偏差，比如Wasmer与Wasmtime在外部引用类型的枚举命名上存在差异，Wasmer将Python的字符串类型映射为“externref_str”，而Wasmtime则命名为“string_externref”，这种看似微小的分歧，导致Python模块在跨运行时迁移时，接口调用会因类型标识不匹配而出现隐性失效，且这种失效往往难以通过常规测试察觉。更复杂的是，Python的复合类型如字典、列表，其内部结构具有动态伸缩性，字典的键值对可能随时增减，列表的元素类型也可混合存储，而WebAssembly的线性内存要求数据必须以连续块的形式存在，且每个元素的类型与大小必须一致，这就要求ABI构建一套复杂的类型转换逻辑。例如，将Python字典转换为Wasm可识别的结构时，不仅需要将键值对按固定顺序排列为连续内存块，还要额外存储键的哈希值与索引映射，以模拟字典的查找特性，这种转换过程中，类型语义的损耗与失真难以避免——Python字典的无序性在转换后可能变为有序结构，而混合类型的列表则需要额外的类型标记字段，这不仅增加了内存开销，还可能导致某些依赖原生语义的操作出现逻辑偏差，如何在转换中保持类型的完整性与行为一致性，成为ABI设计的核心难点。

内存模型的异构冲突构成了ABI集成的另一重深层障碍，WebAssembly的线性内存与Python的托管内存体系在语义与操作层面存在本质分歧。WebAssembly采用单一连续的线性内存空间，所有数据都存储在这片连续区域中，内存的分配与释放需要严格遵循特定的对齐规则，通常要求数据地址必须是其大小的整数倍，尤其是原子操作对内存对齐的要求更为严苛，任何偏离自然对齐的访问都可能导致CPU指令执行效率骤降，甚至在部分架构下引发隐性的内存访问异常。而Python的内存管理则依赖垃圾回收机制，对象的内存分配由解释器自动处理，内存地址的分配具有随机性，且对象之间可能存在复杂的引用关系，比如循环引用、弱引用等，这种托管式内存模型与WebAssembly的手动内存管理逻辑在ABI层面形成尖锐冲突。当Python对象需要通过ABI传递到WebAssembly环境时，不仅需要将动态分配的对象内存转换为连续的线性内存块，还要处理内存所有权的转移与生命周期的同步——Python的垃圾回收机制无法感知WebAssembly环境中的内存使用状态，可能在Wasm模块仍在访问数据时就回收该内存，而WebAssembly也无法参与Python的内存管理循环，无法主动通知Python侧释放不再需要的对象。在多线程场景下，这种冲突更为突出：Python的全局解释器锁（GIL）限制了内存操作的并发安全性，而Wasm的原子操作需要无锁的内存访问环境，ABI必须设计一套独立的内存协调机制，既要通过引用计数跟踪跨环境的内存使用状态，防止内存泄漏，又要通过内存锁定机制避免野指针访问，还要兼顾跨环境内存访问的性能，避免过度的同步操作导致效率低下，其设计难度远超同构体系下的内存接口。

系统接口的抽象层级差异给ABI带来了难以调和的适配难题，WASI作为WebAssembly的系统接口标准，其设计理念与Python依赖的原生系统接口存在显著的抽象鸿沟。WASI为了追求跨平台可移植性，对传统操作系统的系统调用进行了精简与标准化，仅保留了文件操作、网络通信、内存管理等核心功能，且调用方式采用了基于句柄的抽象设计，与Linux、Windows等原生系统的系统调用在功能覆盖、参数传递方式上存在明显差异。而Python的许多标准库与扩展模块深度依赖于原生系统的完整接口能力，比如Python的os模块提供的进程管理、信号处理功能，在WASI的接口规范中并未完全覆盖，这种差异使得ABI在对接两者时必须面对功能缺失与接口转换的双重挑战。例如，Python的os.fork()函数用于创建子进程，而WASI为了避免跨平台兼容性问题，并未提供对应的进程创建接口，ABI适配层必须通过线程模拟或进程池复用的方式间接实现该功能，这不仅增加了实现复杂度，还可能导致部分依赖进程隔离特性的Python代码出现逻辑偏差。更复杂的是，WASI的版本迭代与实现差异加剧了适配难度，WASI 0.2版本在网络接口中新增了TCP流的非阻塞操作支持，而部分老旧的Wasm运行时仍基于WASI 0.1版本实现，导致Python模块在利用ABI调用网络功能时，出现功能不一致或调用失败的情况。此外，不同运行时对WASI标准的实现也可能存在偏差，比如WasmEdge对文件权限的检查逻辑与Wasmer存在差异，导致Python的文件操作在不同运行时中表现出不同的行为，ABI需要在Python的原生接口期望与WASI的标准化接口之间构建适配层，既要通过功能补全弥补缺失的系统调用，又要通过兼容性适配兼容不同版本与实现的差异，这种适配层的设计不仅需要深入理解两套接口的抽象逻辑，还要具备足够的灵活性以应对生态的快速变化。

工具链的碎片化导致ABI在编译与链接阶段面临一致性难题，Python与WebAssembly的集成依赖多种工具链的协同工作，而不同工具链的编译策略、链接规则存在显著差异，使得ABI的实现难以保持跨工具链的一致性。目前主流的集成工具链包括Emscripten、Pyodide、Wasmer-Python等，每一种工具链都有其独特的编译流程与优化策略：Emscripten侧重于将Python代码编译为Wasm模块，其编译过程会对Python的标准库进行裁剪与适配，可能导致部分依赖原生扩展的模块无法正常工作；Pyodide则是将Python解释器编译为Wasm，通过JavaScript桥接实现与Wasm模块的交互，但其ABI设计过度依赖JavaScript中间层，导致跨环境调用的性能损耗较大；Wasmer-Python直接通过原生绑定实现Python与Wasm运行时的交互，但其对Python版本的兼容性较差，仅支持3.8以上的特定版本。这些工具链的差异在异常处理机制上表现得尤为明显，Python的错误处理模型依赖于异常传播，允许在函数调用栈的任意层级捕获异常并处理，而部分Wasm工具链如Emscripten默认不支持跨模块的异常传播，将Python的异常转换为Wasm的错误码，这就需要ABI在编译阶段进行特殊配置，通过生成额外的异常处理元数据，实现异常信息的跨环境传递，既要满足Python的异常处理需求，又要兼容工具链的限制。另一些工具链在处理稳定ABI时，可能存在链接逻辑的偏差，比如在Windows平台上，即使指定了稳定ABI构建，Emscripten仍会错误地链接到版本特定的Python库文件，导致Python模块失去跨版本兼容性，在Python 3.10与3.11之间切换时出现符号未定义错误。这种工具链层面的差异使得ABI的实现必须针对不同工具链进行适配，而每一种适配都可能引入新的兼容性问题，如何在碎片化的工具链生态中维持ABI的一致性与稳定性，成为集成过程中必须攻克的难题，这不仅需要对工具链的底层逻辑有深入理解，还要设计灵活的适配策略，比如通过条件编译指令适配不同工具链的特性，通过中间层封装屏蔽工具链的差异，以应对各种边缘情况。

ABI的演进与兼容平衡是长期面临的战略挑战，随着Python与WebAssembly生态的快速发展，ABI需要在功能扩展与向后兼容之间找到微妙的平衡。Python的版本迭代速度较快，每一个大版本都会引入新的语言特性与标准库接口，比如Python 3.11新增的异常组特性、3.12优化的类型注解语法，这些新特性往往需要ABI在类型映射、调用约定等层面进行相应调整，才能实现与Wasm模块的无缝集成。而WebAssembly的规范也在持续升级，最新的WebAssembly 2.0标准引入了SIMD扩展指令集、引用类型增强等新特性，这些特性为性能优化提供了更多可能，但也要求ABI进行升级以支持新的指令调用与内存操作模式。然而，ABI的升级必须兼顾已有系统的兼容性，否则会导致基于旧版ABI开发的Wasm模块与Python扩展失效，破坏生态的稳定性。例如，若ABI为支持SIMD指令而修改了数值类型的内存布局，那么基于旧版ABI编译的矩阵运算Wasm模块，在新版本环境中会因类型映射错误而输出错误结果。更复杂的是，不同的Python库与WebAssembly模块可能依赖不同版本的ABI，部分老旧的Python扩展仍依赖于早期的ABI版本，而新开发的Wasm模块则需要使用最新的ABI特性，这种依赖的多样性使得ABI的版本管理变得异常复杂。如何设计一套可演进的ABI架构，既能支持新特性的快速集成，又能通过兼容层保障旧模块的正常运行，成为考验架构设计能力的关键。

GraalPython凭借多语言无缝协同的特性成为技术选型热点，但互操作背后的性能损耗往往隐藏在“无缝”的表象之下。这种损耗并非单一环节的低效，而是跨语言语义转译、语境切换、内存协同等多重因素交织的隐性壁垒——当GraalPython与Java、Rust等语言进行数据交互时，Polyglot API的中间适配、Truffle框架的动态优化延迟、不同语言内存模型的语义冲突，都会在高频调用场景中放大为显著的性能瓶颈。例如在工业物联网设备的实时质检场景中，GraalPython负责处理传感器采集的非结构化动态数据流，完成数据清洗与特征提取后，需将结果传递给Java模块进行业务规则校验，再由Rust模块执行底层算法加速运算，看似流畅的三级协同背后，类型语义的隐性转译、上下文状态的频繁切换，会使单次调用的延迟从微秒级累积至毫秒级，在每秒数十万次的高频调用场景下，直接导致整体系统吞吐量下降三成以上。更值得注意的是，这种瓶颈的隐蔽性极强，在低频次的功能测试中性能差异微乎其微，只有进入大规模数据处理或高并发交互的真实生产场景，深层的协同损耗才会集中爆发，成为制约系统性能上限的隐形枷锁，甚至会让前期针对单一语言的优化策略全部失效。

类型语义转译的隐性开销是互操作面临的核心瓶颈，这种开销源于不同语言类型体系的本质差异与转译过程中的语义损耗。GraalPython的动态类型表征与Java的静态类型谱系、Rust的强类型约束在核心语义上存在天然分歧，而Polyglot API作为转译中介，需在不同类型体系间构建临时映射关系，这种映射不仅涉及数据格式的转换，更包含语义逻辑的适配与补全。例如GraalPython的动态数组可能混合存储整数、字符串、布尔值等多种类型元素，传递给Java时需转译为统一类型的有序集合，转译过程中不仅要逐一对元素进行类型校验与转换，还需对不兼容元素进行语义适配，比如将Python的None值转换为Java的null，将Python的布尔值映射为Java的Boolean类型，这种适配往往需要额外的计算资源与时间开销。更复杂的是，不同语言对同一数据类型的语义定义可能存在偏差，GraalPython的字符串默认采用UTF-8编码且支持动态拼接，而Rust的字节序列更强调内存安全与固定长度，二者在底层存储逻辑上的差异，会导致转译时需进行编码格式的转换与内存空间的重构，高频次下这种转换的累积开销会急剧上升。同时，转译过程中还需维护类型元数据的同步，确保跨语言调用时的数据一致性，这种元数据管理本身也会占用额外的系统资源，比如构建类型映射表、跟踪类型转换记录，这些隐性操作都成为了性能损耗的隐形来源。

语境切换的累积损耗构成了互操作的另一重性能障碍，GraalPython与其他语言的协同需频繁切换执行语境，而语境切换过程中的状态保存、环境重建会产生显著的时间开销。在实时数据处理场景中，GraalPython负责数据预处理，Java负责业务逻辑计算，Rust负责底层算法加速，三者之间的频繁调用会导致执行语境在不同语言 runtime 间反复切换。每次切换都需保存当前语言的执行状态，包括程序计数器的值、寄存器中的临时数据、栈帧中的局部变量等，再加载目标语言的运行环境，初始化上下文配置、恢复目标语言的执行参数，这个过程在微秒级别的单次切换中看似微不足道，但在每秒数万次的高频调用场景下，累积损耗会占据相当比例的系统资源。更关键的是，语境切换会导致CPU缓存失效，CPU的L1、L2缓存原本存储着当前语言的指令与数据，切换后需要重新加载目标语言的指令与数据到缓存中，破坏了缓存的局部性原理，使得后续指令的执行不得不从内存中读取数据，进一步降低了执行效率。此外，不同语言的线程模型差异会加剧切换损耗，GraalPython的协程调度采用轻量级的用户态切换，Java的线程池管理依赖操作系统的内核态调度，Rust的无栈协程则强调零成本的上下文切换，三者在调度机制上的不兼容，会导致跨语言调用时出现调度冲突，需引入额外的同步机制进行协调，比如使用互斥锁或信号量保证线程安全，这无疑又增加了性能开销，让语境切换的损耗雪上加霜。

内存语义协同的冲突是深层性能瓶颈，GraalPython的动态内存调度与其他语言的内存管理机制在语义上存在本质分歧，跨语言数据共享时的内存所有权界定、生命周期同步成为核心难题。GraalPython依赖自身的垃圾回收机制管理内存，对象的创建与释放无需手动干预，垃圾回收器会定期扫描内存空间，回收不再被引用的对象；而Rust采用严格的所有权模型，内存的分配与释放由编译器静态检查，确保每一块内存都有唯一的所有者，避免出现空指针或悬垂引用；Java则通过JVM的垃圾回收机制自动管理内存，其回收策略与GraalPython的GC存在显著差异。三者的内存语义差异导致跨语言数据传递时需进行复杂的内存适配，例如GraalPython的对象传递给Rust时，需将动态分配的内存转换为Rust可识别的所有权模型，这个过程不仅要复制数据到Rust的内存空间，还需构建临时的内存管理代理，通过引用计数的方式跟踪内存的使用状态，确保Rust使用期间内存不被GraalPython的GC回收，使用完毕后及时通知GC释放代理资源。这种适配不仅增加了内存拷贝的开销，还可能导致内存泄漏——当跨语言调用因网络波动或系统异常中断时，内存管理代理可能无法正常销毁，导致部分内存无法被回收，长期运行会使系统可用内存逐渐减少。在数据密集型场景中，大量跨语言数据传递会使这种内存协同开销呈指数级增长，比如处理百万级别的传感器数据时，内存拷贝与代理管理的时间占比可达总执行时间的40%以上，严重影响系统的整体性能。

版本协同的隐性陷阱加剧了互操作的性能波动，GraalVM生态的版本迭代与多语言模块的版本兼容性要求，使得GraalPython在互操作时面临优化失效的风险。GraalVM的版本管理采用严格的语义化版本控制，主版本号的差异可能导致Polyglot API的调用逻辑、Truffle框架的优化策略发生根本性变化，而不同语言模块如Java的polyglot库、Rust的FFI绑定在版本迭代时可能未及时同步适配，导致跨语言调用时出现优化不兼容的问题。例如使用GraalVM 23.0版本运行时调用基于22.0版本开发的Java模块，可能会因Polyglot API的参数传递方式变化，导致JIT编译的跨语言内联优化失效，原本可通过内联减少的调用开销无法实现，单次跨语言调用的耗时增加两倍以上；而低版本的GraalPython对接高版本的Rust模块时，可能因FFI接口的语义变化，导致数据转译过程中出现冗余操作，比如重复进行类型校验、额外生成中间数据结构，这些冗余操作都会显著增加性能损耗。更复杂的是，部分语言模块的版本更新会引入新的内存管理机制或线程调度策略，与GraalPython的原有适配逻辑产生冲突，比如Rust模块升级后采用了新的异步内存分配器，而GraalPython的内存代理机制未同步更新，导致跨语言数据传递时出现内存分配冲突，不得不引入额外的同步锁进行协调，进一步降低了执行效率。这种版本协同的复杂性要求开发者在选型时需严格匹配所有相关模块的版本，而频繁的版本迭代又使得版本维护的成本急剧上升，成为性能优化过程中难以规避的隐性障碍。

动态优化的边界限制是长期存在的性能瓶颈，GraalPython依赖Truffle框架的动态优化能力提升执行效率，但多语言互操作的复杂性使得优化策略难以充分覆盖，导致部分跨语言调用无法获得有效的优化支持。Truffle框架的核心优化手段包括部分评估、跨语言内联、类型特化等，这些优化依赖于对代码执行路径的静态分析与运行时数据收集，而多语言互操作的动态特性往往超出了优化策略的覆盖范围。例如GraalPython调用Java的泛型方法时，由于Java的泛型类型擦除特性，Truffle框架难以在编译期确定具体的类型信息，无法进行精准的类型特化优化，只能采用通用的类型处理逻辑，导致调用开销居高不下；而调用Rust的复杂结构体方法时，因结构体的内存布局与GraalPython的对象模型存在显著差异，部分评估优化无法充分展开，只能依赖runtime的动态适配，增加了执行延迟。此外，多语言调用的路径多样性也会影响优化效果，不同语言的函数调用栈嵌套、参数传递方式的差异，使得Truffle框架难以构建统一的优化模型，比如三级嵌套的跨语言调用，Python调用Java再调用Rust，框架无法对整个调用链进行全局优化，只能对单一环节进行局部优化，优化效果大打折扣。

兄弟们，撸了一个小工具，Netstat Cat 是一款 Windows 桌面应用程序，我说白了，就是 netstat 的 GUI 版本 让 网络活动监控 和 应用程序端口查询变得更加简单。

当然，目前是完全开源且免费使用, 有不能满足的需求或者发现 bug ，欢迎提 issue ，🐶

先放 README 链接：Netstat Cat README @Github

再上图：

亮色主题
暗色主题

支持语义化的结构化查询，比如：

Release 下载地址： https://github.com/XueshiQiao/netstat-cat/releases/

Have fun!

现在挺多人使用两个手机，

  • 一个工作机，上班处理烂事，顺便安装反诈 app 应付检查，安装微信支付宝银行 app ，不能解 bootloader 勉强还算安全；
  • 另一个自用机，平常自己用，游戏娱乐，一般不要求 sim 卡，甚至可以用工作机的热点。

如果生产开源无 sim 卡的手机作为自用机，应该有以下有点：

  • 没有 sim ，不用入网许可，政府方面要求可能会松
  • 没有 sim ，金融相关 app(微信，支付宝，银行）的安全检测可能过不了，导致无法支付，避免丢钱，安全的很。
  • 开源，方便社区自己搞操作系统（ lineageos ），公司开发操作系统的工作都省了！
  • 少了操作系统和 sim 相关模块，成本低，拿下游戏手机的市场。
  • 开源硬件和软件，方便用户 DIY ，方便 root

一个轻量的 Chrome/Edge 扩展，支持自动分类、AI 辅助整理、失效书签检测，以及新标签页导航。基于 Manifest V3 原生实现。

功能简介

  • 自动分类：按规则一键整理书签到对应类别。
  • AI 辅助：支持 OpenAI/DeepSeek（兼容接口），提升分类效果。
  • 失效书签：扫描不可访问链接，支持批量删除或移动；可限定扫描指定文件夹，并可忽略内网/本地地址（127.0.0.1、localhost、10.x、192.168.x、172.16–31.x）。
  • 新标签页导航：在新标签页展示分类导航与常用信息。
  • 书签云同步 / 导出：支持每日自动进行 GitHub 书签备份（可在设置页配置），也可手动创建本地备份导出。
  • 自动归档旧书签：按“最近访问时间”判断，将不常访问的书签移入“归档”文件夹（可设置阈值，默认 180 天；无访问记录时回退按添加时间）。
  • 访问频率统计 / 使用热度分析：记录新标签页的书签访问次数与最近访问时间，支持热门栏目展示与基础使用分析。
  • 右键菜单集成：在网页右键菜单中一键“添加到 TidyMark 并分类”，自动创建并移动到匹配分类文件夹。

安装与版本选择

注意：安装完成后首次打开新标签页，浏览器可能弹出“是否保持由扩展设置的新标签页”的提示（Chrome/Edge）。如果你不需要导航页功能，请选择“拒绝 / 恢复默认”。这不会影响书签整理、分类、备份等核心功能，浏览器新标签页将保持默认样式。

版本

说明：如果不需要「新标签页导航」功能，建议选择“纯书签版”；或在完整版中前往「设置 → 导航设置」保持未开启。

🔗 项目地址
👉 https://github.com/PanHywel/TidyMark

有需要欢迎试用和提建议 🙌

最近总感觉电脑不对劲，卡卡的，今天开机打开任务管理器就发现吃了 22G，我的内存 32G，网上搜了一下，有说超级预读取导致的，有说自动分配虚拟内存导致的，我还没试，只试了一个mdsched.exe（太慢了，没跑完我就关了，实际还是有点用，再开机只有 19%-22%，之前是 72%左右）

image
之前（打开 Chrome，3 个选项卡，部分小软件）

image
运行重启后（打开 Chrome，5 个选项卡，登录 QQNT，部分小软件）

后面再出现问题我再看看，目前先这样吧，内存检测太慢了。



主要以前买了个域名, 一直没想出来搞啥

昨晚 3 点就醒了, 突然想到能不能搞一个工作流式图片处理

你可以选择多个动作, 比如压缩, 改格式, 灰度等

配置好参数, 然后点击执行, 就会依次执行操作, 可以预览结果, 满意就下载就行

目标是做成一个常用免费得工具站, 无登录, 无注册, 图片本地处理, 无上传, 保护隐私

核心处理引擎由 rust 编写, 编译成 wasm 执行, 速度快

链接: https://imageide.com

vibe 时代, 一天上线网站是常事阿

前言

上周写的日志分析工具NginxPulse，截止发文已收获 860 个 star ，感谢大家的支持。

根据反馈来看，这个项目存在着 5 个最大的痛点:

  • 大日志场景下，统计面板的接口查询非常慢（需要 10s+的响应）
  • 不支持密钥访问
  • 不支持 gz 格式的日志解析
  • 不支持单体部署
  • 支持 nginx ，不支持 Caddy

周末花了点时间，把这几个痛点已经全部处理，欢迎大家使用与体验。

项目地址

image-20260118171546774

写在最后

至此，文章就分享完毕了。

我是神奇的程序员，一位前端开发工程师。

如果你对我感兴趣，请移步我的个人网站，进一步了解。

第一次发帖，有点小紧张 x

以前使用 Shoka 主题，但无奈性能感觉跟不上了，再加上自己又是前端开发者，于是写了一个博客主题，感觉功能差不多了打算发一下，鞭策自己更新。

【开源博客】Koharu 一个新的二次元 Astro 博客主题，粉蓝配色为主，加了一点点前端魔法～2

一个萌系 / 二次元 / 粉蓝配色的博客主题，适合 ACG 、前端、手账向个人站，性能优异。

命名灵感来源于 “小春日和”（こはるびより）指的是晚秋到初冬这段时期，持续的一段似春天般温暖的晴天。也就是中文中的 "小阳春"。

博客整体设计灵感来自 Hexo 的 Shoka 主题，用更现代的技术栈打造属于你的个人博客。

  • 基于 Astro，静态输出，加载轻快
  • 萌系 / 二次元 / 粉蓝配色，适合 ACG 、前端、手账向个人站
  • 支持多分类、多标签，但不会强迫你用复杂信息架构
  • 尽可能的减少性能开销
  • 使用 pagefind 实现无后端的全站搜索
  • LQIP （低质量图片占位符），图片加载前显示渐变色占位
  • 评论组件可选 Waline / Giscus / Remark42

已经在 astro 主题商店上架啦～

主题： Koharu | Astro

我的博客： https://blog.cosine.ren

开源在 GitHub - cosZone/astro-koharu: astro-koharu 是一个萌系 / 二次元 / 粉蓝配色的 astro 主题博客，灵感来自 Hexo 的 Shoka 主题，加了很多自己的小巧思，性能优越。

是用爱发电的个人项目，喜欢的话欢迎 star 或者 fork 出去改～

持续迭代中，还有挺多 bug 在改，技术栈也挺激进的，不过我个人用起来很喜欢，毕竟就是照着自己喜欢的风格写的，还有很多小巧思不知道有没有人会探索到～

几篇关于实现过程中的技术解析文章：

功能特性

  • 基于 Astro 5.x，静态站点生成，性能优异
  • 优雅的深色 / 浅色主题切换
  • 基于 Pagefind 的无后端全站搜索
  • 可更换评论系统：支持 Waline（推荐）、Giscus、Remark42 三种评论组件，配置文件一键切换，主题自动跟随
  • 完整的 Markdown 增强功能（GFM、代码高亮、自动目录、Mermaid 图表、Infographic 信息图）
  • 灵活的多级分类与标签系统
  • [可开关] 多系列文章支持（周刊、书摘等自定义系列，支持自定义 URL slug）
  • 响应式设计
  • 草稿与置顶功能
  • 阅读进度条与阅读时间估算
  • 智能目录导航，支持 CSS 计数器自动编号（可按文章关闭）
  • 移动端文章阅读头部（显示当前章节标题、圆形阅读进度、可展开目录）
  • 友链系统与归档页面
  • RSS 订阅支持
  • 支持 LQIP：图片加载前显示渐变色占位，提升视觉体验
  • [可开关] 基于语义相似度的智能文章推荐系统，使用 transformers.js 在本地生成文章嵌入向量，计算文章间的语义相似度
  • [可开关] AI 自动摘要生成，自动生成摘要。
  • [可开关] 圣诞特辑：包含雪花飘落、圣诞配色、圣诞帽装饰、灯串装饰等节日氛围效果
  • 无后端站点公告系统：可通过配置文件管理公告，支持时间控制、多条公告堆叠、自定义颜色、hover 已读
  • 有样式的 RSS 订阅源链接
  • Koharu CLI：交互式命令行工具，支持备份 / 还原、内容生成、备份管理

Koharu CLI

博客自带交互式 CLI 工具，方便管理博客内容：

pnpm koharu              # 交互式主菜单
pnpm koharu backup       # 备份博客内容和配置
pnpm koharu restore      # 从备份恢复
pnpm koharu update       # 更新主题
pnpm koharu generate     # 生成内容资产 (LQIP, 相似度, AI 摘要)
pnpm koharu clean        # 清理旧备份
pnpm koharu list         # 查看所有备份

备份与还原

更新主题

使用 CLI 自动更新主题（会自动备份 → 拉取 → 合并 → 安装依赖）：

# 完整更新流程（默认会先备份）
pnpm koharu update

# 仅检查更新
pnpm koharu update --check

# 跳过备份直接更新
pnpm koharu update --skip-backup

配置说明

博客配置统一使用 config/site.yaml 文件管理，包括：

  • 站点基本信息（标题、副标题、作者等）
  • 社交媒体链接
  • 导航菜单
  • 特色分类和周刊配置
  • 分类映射（中文分类名 → URL slug）
  • 友链列表
  • 公告系统
  • 评论系统（Waline / Giscus / Remark42，推荐使用 Waline）
  • 数据统计（Umami）
  • 圣诞特辑开关

详细配置说明请参考文档。

评论系统切换

在 config/site.yaml 中通过 comment.provider 字段一键切换评论系统：

comment: provider: waline # 'waline' | 'giscus' | 'remark42' | 'none' waline: serverURL: https://your-waline-server.vercel.app # ... 其他配置

推荐使用 Waline：自部署简单、功能丰富（Markdown、表情、邮件通知）、带访问量统计。详细配置请参考完整使用指南。

文档

演示图 1

性能优异：目标是 PC 的全绿，但是随着功能迭代不可避免的需要反复检查！

【开源博客】Koharu 一个新的二次元 Astro 博客主题，粉蓝配色为主，加了一点点前端魔法～1
【开源博客】Koharu 一个新的二次元 Astro 博客主题，粉蓝配色为主，加了一点点前端魔法～3

📌 转载信息
原作者：
cosine_x
转载时间：
2026/1/18 19:23:27

问题：
如何为连接器的参考点附加质量和惯性矩，这些参考点目前只有坐标，没有与任意实体耦合，仅用来设置参考点，模拟运动，我想的是添加一个比较小的质量和惯性，这个质量和惯性，不影响给定的运动和力。应该多大的质量和惯性矩比较好？
做的动力学显式仿真，移动副的推力大概是 2000N，转动副转矩为 159644N.mm，我在仿真中忽略运动副的影响，只考虑弯曲模与管材接触时的弯曲力与反作用力

回答：
Gemini；

ABAQUS 仿真，gemini=deepseek>gpt1


deepseek:

ABAQUS 仿真，gemini=deepseek>gpt3


GPT:

ABAQUS 仿真，gemini=deepseek>gpt4

那我问你，优先不设置啥意思？不设置要是能仿真，我会问你吗？
奇葩 GPT，很常识性的问题都不知道。我怀疑 GPT 没怎么训练过 ABAQUS 的知识。不止 abaqus 仿真，我感觉工程问题，问 GPT 都不怎么样。
ABAQUS 仿真，gemini=deepseek>gpt2

📌 转载信息
原作者：
walixia
转载时间：
2026/1/18 19:17:07

背景

由于鼠鼠我在服务器上没有 sudo 权限，没法使用 github 上提供的方法，而仅仅通过 SSH 反向隧道经常出现连接不稳定、端口假死或断连的情况。经过一番折腾，我找到了基于 Cloudflare Tunnel 的终极解决方案。本文将分享两种配置方法：一种适合临时测试（无域名），另一种适合长期稳定运行（有域名）。

准备工作：本地服务配置

Antigravity-Manager 反代服务远程服务器中的使用方法（无 sudo 权限也可以使用）1

方案一：我没有域名

如果你只是想临时测试一下，或者不想购买域名，可以使用 Cloudflare 提供的免费临时隧道。

步骤：

  1. 下载 Cloudflared 工具。
  2. 在下载目录打开 PowerShell，运行以下命令：
cloudflared.exe tunnel --url http://localhost:8045
  1. 终端会输出一个临时的公网地址，格式如：
    https://random-name.trycloudflare.com
  2. 复制这个地址，去服务器配置即可使用。

方案二：我有自己的域名

如果你有域名（托管在 Cloudflare），我们可以利用 Cloudflare Zero Trust 面板，将本地电脑变成一台 “服务器”，实现开机自启、固定域名且无需保持黑窗口运行。

特点：稳定、专业、后台静默运行。

1. 创建隧道与安装服务

  1. 进入 Cloudflare Zero Trust 面板 → Networks → Manage Tunnels。

    Antigravity-Manager 反代服务远程服务器中的使用方法（无 sudo 权限也可以使用）3

  2. 创建 Tunnel

  3. 在安装界面选择你 Antigravity Tools 所在的操作系统，复制那一长串安装命令进行安装。

  4. 成功提示：Cloudflared agent installed successfully。此时服务已在后台安装，电脑重启也会自动连上。

2. 绑定域名

在你的 tunnel 中

Antigravity-Manager 反代服务远程服务器中的使用方法（无 sudo 权限也可以使用）2

点击 这个 routes 进入配置页面：

  • Subdomain: 填写前缀（如 api）。
  • Domain: 选择你的域名（如 example.xyz）。
  • Service:
  • Type: HTTP
  • URL: 127.0.0.1:8045 (或局域网 IP，或者是你的计算机名，我这里使用的是计算机名，因为我的电脑会经常到处跑)。

保存后，你的 API 地址就是固定的 https://api.example.xyz 了。

避坑指南：解决 524 Timeout 与断连

在使用过程中，我遇到了几个关键问题，这里给出解决方案：

1. 致命的 HTTP 524 Timeout 错误

现象：域名能 ping 通，但请求 API 时卡顿很久，最后报错 524: A timeout occurred。
原因：Windows 默认将 localhost 解析为 IPv6 (::1)，而某些服务只监听 IPv4。Cloudflare 转发请求时 “迷路” 了。
解决：
在 Cloudflare 后台配置 Service URL 时，** 千万不要填 localhost:8045**。

  • 稳妥写法：填 127.0.0.1:8045。
  • 进阶写法：填局域网 IP，如 192.168.1.5:8045。

2. 局域网 IP 变动怎么办？

如果你使用局域网 IP 配置，重启路由器后 IP 可能会变，这也是我目前使用的方法。
解决：

在 Cloudflare Service URL 里填写计算机名，前提是你的计算机名是全网独一无二的？（如 http://My-Desktop:8045），让它通过主机名解析。

服务器端配置示例

最后，在远程 Linux 服务器上，只需要修改 JSON 配置文件中的 Base URL 即可：

{ "env": { "ANTHROPIC_AUTH_TOKEN": "sk-your-key-here", "ANTHROPIC_BASE_URL": "https://api.example.xyz", "ANTHROPIC_MODEL": "claude-sonnet-4-5-thinking" } }

希望能帮助到佬友，有更好的方法大家也可以在下面提出来呀。

📌 转载信息
转载时间：
2026/1/18 19:16:42

各位佬友好！

最近在用 Boss 直聘招人，每天要刷几百个推荐简历，眼睛都看花了。

想筛选特定技能或经历的候选人，官方的筛选功能又不太够用，

找了一大圈全网的脚本基本都是求职者的。

于是自己撸了一个油猴脚本，分享给有同样需求的佬友们。

主要功能

  • 关键词高亮：设置关键词后，简历中出现的关键词会被黄色高亮标记出来

  • 筛选模式：开启后只显示匹配的简历，不匹配的直接隐藏掉

  • OR/AND 匹配：支持 "任意匹配" 和 "全部匹配" 两种模式

    【油猴脚本】Boss 直聘招人端【推荐牛人】页面自定义筛选脚本4

  • 多岗位配置：招多个岗位的佬友有福了，可以保存多套配置，一键切换

    【油猴脚本】Boss 直聘招人端【推荐牛人】页面自定义筛选脚本1

  • 面板可拖拽：控制面板支持拖拽移动，还能吸附到屏幕边缘自动收起

    【油猴脚本】Boss 直聘招人端【推荐牛人】页面自定义筛选脚本2

使用场景举例

比如招运营，想找有小红书经验的，设置关键词小红书，开启筛选模式，瞬间过滤掉不相关的简历，效率翻倍。

再比如招全栈，同时要求 React 和 Node.js，用 AND 模式设置这两个关键词，只显示两个都有的候选人。

安装方法

  1. 先装个油猴插件 (Tampermonkey)
    https://www.tampermonkey.net/
  2. 新建脚本，把代码粘贴进去保存
    【油猴脚本】Boss 直聘招人端【推荐牛人】页面自定义筛选脚本3

    【油猴脚本】Boss 直聘招人端【推荐牛人】页面自定义筛选脚本5

CTRL+S 可以快速保存

【油猴脚本】Boss 直聘招人端【推荐牛人】页面自定义筛选脚本6
  1. 打开 Boss 直聘推荐人才页面，右上角会出现控制面板
  2. 记得启用
    【油猴脚本】Boss 直聘招人端【推荐牛人】页面自定义筛选脚本7

一些说明

  • 脚本只在推荐人才页面 (https://www.zhipin.com/web/chat/recommend) 生效，不影响其他页面
  • 配置保存在浏览器本地存储，不会上传任何数据
  • 代码开源，佬友们可以自行审阅、魔改

后续计划

  • 这个版本我已经用了一段时间了，目前没发现什么新需求了，有需求可以提，我可以顺手帮忙优化

免责声明

Boss 对自动化、插件是禁止使用的，理论上本脚本可以做到 VIP 的筛选效果，但因为非 VIP 每日开聊次数很少，所以我仍然充值了 VIP

因此我会配合 VIP 的筛选 + 本脚本更精准的找到合适的候选人

代码

不想分享到 github 或者 greasyfork 怕有别的问题，所以用附件方式分享

v5.3.0
recommend_filter_v530.7z

欢迎佬友们试用和反馈，有问题直接帖子下面留言就行。

如果觉得有用，点个赞让更多 HR 佬友看到～

📌 转载信息
原作者：
91kevinshi
转载时间：
2026/1/18 19:11:52

今天使用 cc 的时候，我让它帮我总结一下一个 github 上的项目内容，它显示无法访问

分享一下使用 claudecode 无法访问 github 的小问题1


问它怎么解决，它也没提出什么好方案，最后还是 gemini 给我解决的
然后是

解决方案


1. 代理开 tun 模式，最简单无脑的方法
2. 这种问题大概率是你的终端没走梯子，需要在你的终端上配置本地代理（只有当前终端窗口有效）
只要在 PowerShell 中输入以下命令（假设你的代理端口是 7890，请根据

实际情况修改

）：

$Env:http_proxy="http://127.0.0.1:7890" $Env:https_proxy="http://127.0.0.1:7890"

设置好后，再启动 Claude Code，这样它调用 curl 时就能连上 GitHub 了
最后，在分享一个我遇到的另一个问题
如果你使用 Shift+Tab 键，无法切换 plan 模式的话
大概率是 node 版本不支持，改用 Alt+M 就好了
如果佬友们，还有其他问题的话，可以看下这位佬的帖子

📌 转载信息
原作者：
furinayyds1
转载时间：
2026/1/18 19:11:42

适用于旧版的 BPB 面板，早期 BPB 面板漏洞可白嫖节点，长时间没用了，不知道是否还有效，可自行测试，下载 2. BPB 筛选域名.py 后自行打包即可，3 和 4 是配合 1.0 的 Edgetunnel 用的，面板已经全面更新可能不适用了

GitHub - jeffernn/BPB-Panel-Vulnerability-Tool: 旧版 BPB 面板漏洞自动获取节点，优选节点自动上传，自动获取优质优选节点

📌 转载信息
转载时间：
2026/1/18 19:10:43

主要是在使用的时候，发现每个订阅的分组方式都不一样，规则也比较不同。
找了一个可以统一的，复写脚本。
还能添加自定义的规则。
自定义规则在 config [“rules”] 中。

// https://mihomo.party/docs/guide/override/javascript
function main(config) {
  config["proxy-groups"] = [
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/Static.png",
      "include-all": true,
      "exclude-filter": "(?i)GB|Traffic|Expire|Premium|频道|订阅|ISP|流量|到期|重置",
      name: "PROXY",
      type: "select",
      proxies: ["AUTO", "HK AUTO", "SG AUTO", "JP AUTO", "Asia AUTO", "US AUTO"],
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/Urltest.png",
      "include-all": true,
      "exclude-filter": "(?i)GB|Traffic|Expire|Premium|频道|订阅|ISP|流量|到期|重置|[2-9]x|[1-9]0x",
      name: "AUTO",
      type: "url-test",
      interval: 300,
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/OpenAI.png",
      name: "AIGC",
      type: "select",
      proxies: ["SG AUTO", "JP AUTO", "US AUTO"],
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/Telegram.png",
      name: "Telegram",
      type: "select",
      proxies: ["HK AUTO", "SG AUTO", "JP AUTO", "US AUTO"],
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/Google.png",
      name: "Google",
      type: "select",
      proxies: ["HK AUTO", "SG AUTO", "JP AUTO", "US AUTO"],
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/HK.png",
      "include-all": true,
      "exclude-filter": "(?i)GB|Traffic|Expire|Premium|频道|订阅|ISP|流量|到期|重置",
      filter: "(?i)香港|Hong Kong|HK|🇭🇰",
      "exclude-filter": "[2-9]x|[1-9]0x",
      name: "HK AUTO",
      type: "url-test",
      interval: 300,
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/SG.png",
      "include-all": true,
      "exclude-filter": "(?i)GB|Traffic|Expire|Premium|频道|订阅|ISP|流量|到期|重置",
      filter: "(?i)新加坡|Singapore|🇸🇬",
      "exclude-filter": "[2-9]x|[1-9]0x",
      name: "SG AUTO",
      type: "url-test",
      interval: 300,
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/JP.png",
      "include-all": true,
      "exclude-filter": "(?i)GB|Traffic|Expire|Premium|频道|订阅|ISP|流量|到期|重置",
      filter: "(?i)日本|Japan|🇯🇵",
      "exclude-filter": "[2-9]x|[1-9]0x",
      name: "JP AUTO",
      type: "url-test",
      interval: 300,
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/HK.png",
      "include-all": true,
      "exclude-filter": "(?i)GB|Traffic|Expire|Premium|频道|订阅|ISP|流量|到期|重置",
      filter: "(?i)香港|Hong Kong|HK|🇭🇰|(?i)日本|Japan|🇯🇵|(?i)新加坡|Singapore|🇸🇬",
      "exclude-filter": "[2-9]x|[1-9]0x",
      name: "Asia AUTO",
      type: "url-test",
      interval: 300,
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/US.png",
      "include-all": true,
      "exclude-filter": "(?i)GB|Traffic|Expire|Premium|频道|订阅|ISP|流量|到期|重置",
      filter: "(?i)美国|USA|🇺🇸",
      name: "US AUTO",
      "exclude-filter": "[2-9]x|[1-9]0x",
      type: "url-test",
      interval: 300,
    },
    {
      icon: "https://testingcf.jsdelivr.net/gh/Orz-3/mini@master/Color/Global.png",
      "include-all": true,
      "exclude-filter": "(?i)GB|Traffic|Expire|Premium|频道|订阅|ISP|流量|到期|重置",
      proxies: ["AUTO", "HK AUTO", "SG AUTO", "JP AUTO", "Asia AUTO", "US AUTO"],
      name: "GLOBAL",
      type: "select",
    }
  ];
  if (!config['rule-providers']) {
    config['rule-providers'] = {};
  }
  config["rule-providers"] = Object.assign(config["rule-providers"], {
    private: {
      url: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@meta/geo/geosite/private.yaml",
      path: "./ruleset/private.yaml",
      behavior: "domain",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    cn_domain: {
      url: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@meta/geo/geosite/cn.yaml",
      path: "./ruleset/cn_domain.yaml",
      behavior: "domain",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    telegram_domain: {
      url: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@meta/geo/geosite/telegram.yaml",
      path: "./ruleset/telegram_domain.yaml",
      behavior: "domain",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    google_domain: {
      url: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@meta/geo/geosite/google.yaml",
      path: "./ruleset/google_domain.yaml",
      behavior: "domain",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    "geolocation-!cn": {
      url: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@meta/geo/geosite/geolocation-!cn.yaml",
      path: "./ruleset/geolocation-!cn.yaml",
      behavior: "domain",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    cn_ip: {
      url: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@meta/geo/geoip/cn.yaml",
      path: "./ruleset/cn_ip.yaml",
      behavior: "ipcidr",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    telegram_ip: {
      url: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@meta/geo/geoip/telegram.yaml",
      path: "./ruleset/telegram_ip.yaml",
      behavior: "ipcidr",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    google_ip: {
      url: "https://testingcf.jsdelivr.net/gh/MetaCubeX/meta-rules-dat@meta/geo/geoip/google.yaml",
      path: "./ruleset/google_ip.yaml",
      behavior: "ipcidr",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    bing: {
      url: "https://testingcf.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Bing/Bing.yaml",
      path: "./ruleset/bing.yaml",
      behavior: "classical",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    copilot: {
      url: "https://testingcf.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Copilot/Copilot.yaml",
      path: "./ruleset/copilot.yaml",
      behavior: "classical",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    claude: {
      url: "https://testingcf.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Claude/Claude.yaml",
      path: "./ruleset/claude.yaml",
      behavior: "classical",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    bard: {
      url: "https://testingcf.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/BardAI/BardAI.yaml",
      path: "./ruleset/bard.yaml",
      behavior: "classical",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    openai: {
      url: "https://testingcf.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/OpenAI/OpenAI.yaml",
      path: "./ruleset/openai.yaml",
      behavior: "classical",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
    steam: {
      url: "https://testingcf.jsdelivr.net/gh/blackmatrix7/ios_rule_script@master/rule/Clash/Steam/Steam.yaml",
      path: "./ruleset/steam.yaml",
      behavior: "classical",
      interval: 86400,
      format: "yaml",
      type: "http",
    },
  });

  config["rules"] = [
    //------ 自定义
    "IP-CIDR,100.78.0.0/8,DIRECT",
    "DOMAIN-SUFFIX,linux.do,PROXY",
    //------
    "RULE-SET,private,DIRECT",
    "RULE-SET,bing,AIGC",
    "RULE-SET,copilot,AIGC",
    "RULE-SET,bard,AIGC",
    "RULE-SET,openai,AIGC",
    "RULE-SET,claude,AIGC",
    "RULE-SET,steam,PROXY",
    "RULE-SET,telegram_domain,Telegram",
    "RULE-SET,telegram_ip,Telegram",
    "RULE-SET,google_domain,Google",
    "RULE-SET,google_ip,Google",
    "RULE-SET,geolocation-!cn,PROXY",
    "RULE-SET,cn_domain,DIRECT",
    "RULE-SET,cn_ip,DIRECT",
    "MATCH,PROXY",
  ];
  return config;
}

📌 转载信息
转载时间：
2026/1/18 19:09:43

一个纯主观的，从我个人需求出发的一个新的轮子，缝合了站内各位开源佬们的一大堆功能。
这个项目的立项来自于我的上一个帖子：https://linux.do/t/topic/1380214 ，然后现有的各个项目要么功能不足，要么有一些 BUG。
所以这个项目我进行了大量测试，且已经高频使用大概有一周了，才敢端上来。

致谢列表

放在最前面，由衷感谢，提供了很多功能思路，并且节省了开发和验证的成本

  • cc-switch
    是我使用频率最高的工具，快速切 CLI 全局配置、MCP 配置、全局提示词配置非常爽。
    本项目上述功能参考了 cc-switch
  • coding-tool
    会话管理，好用爱用。连 UI 都抄过来了
  • code-switch 和 code-switch-R
    cc-switch 最初没网关，为了解决服务商额度没到刷新时间，需要手动切的问题
    本项目网关功能参考了 code-switch
  • ccg-workflow
    取名灵感

功能预览

看图效率最高啦
【开源】ccg-gateway：多功能代理网关，优雅流转于多服务商 | 支持 Claude + Codex + Gemini1

【开源】ccg-gateway：多功能代理网关，优雅流转于多服务商 | 支持 Claude + Codex + Gemini4

【开源】ccg-gateway：多功能代理网关，优雅流转于多服务商 | 支持 Claude + Codex + Gemini2

【开源】ccg-gateway：多功能代理网关，优雅流转于多服务商 | 支持 Claude + Codex + Gemini5

【开源】ccg-gateway：多功能代理网关，优雅流转于多服务商 | 支持 Claude + Codex + Gemini6

【开源】ccg-gateway：多功能代理网关，优雅流转于多服务商 | 支持 Claude + Codex + Gemini7

【开源】ccg-gateway：多功能代理网关，优雅流转于多服务商 | 支持 Claude + Codex + Gemini9

【开源】ccg-gateway：多功能代理网关，优雅流转于多服务商 | 支持 Claude + Codex + Gemini8
  • 智能路由 - 基于优先级和可用性的自动服务商选择
  • 故障转移 - 服务商状态异常，自动切换备用服务商
  • 模型映射 - 灵活的模型名称映射
  • 实时监控 - 完整的请求日志和统计分析
  • 预设配置 - 一键注入全局配置、MCP、全局提示词等内容

简单的使用场景

1. 网关转发

转发 CLI 的请求到服务商

  • 支持拖拽调整服务商优先级
  • 当前服务商不可用时自动切换到下一个服务商
  • 自动拉黑连续失败 N 次的服务商 M 分钟

使用场景：
小帅订阅了三个服务商：服务商 A 每 4 小时重置额度，服务商 B 每 9 小时重置额度，服务商 C 按量计费。
小帅为了保证可用性和性价比，为服务商 A 配置拉黑时长为 4 小时，为服务商 B 配置拉黑时长为 9 小时，将服务商 C 的拖拽到最后作为兜底。
网关会优先转发请求到服务商 A，服务商 A 不可用再转发到服务商 B，服务商 B 不可用再转发到服务商 C，当服务商 A 恢复后继续使用服务商 A。

2. 模型映射

根据映射规则重命名模型名称，解决服务商模型名称与 CLI 默认模型不一致的问题

  • 支持的通配符：* - 匹配任意数量字符；? - 匹配单个字符

使用场景：
服务商 A 的模型命名是 cc-opus-4.5 ，而其他服务商的模型命名都遵循官方是 claude-opus-4-5-20251101 ，小帅就为服务商 A 配置了模型映射

*opus* -> cc-opus-4.5
*haiku* -> cc-haiku-4.5

这样 CLI 无需任何额外配置，所有请求都能正确转发到服务商。

3. 配置管理

  • CLI 全局配置：为各 CLI 预设全局配置，启用网关时自动注入
  • MCP 配置：支持配置 MCP ，一键应用到各个 CLI
  • 提示词预设：支持配置常用提示词，一键应用到各个 CLI
  • 超时设置：可配置流式和非流式请求的超时时间
  • 备份恢复：支持配置的导出和导入，支持 webdav 备份

4. 请求日志与统计

  • 请求日志：详细记录每个请求的完整信息（请求内容、响应内容、耗时、token 用量等）
  • 系统日志：记录服务商切换、故障、拉黑等系统事件

使用场景：
小帅求知欲强，想知道 CLI 工作时会发送哪些请求，请求的内容是什么。

5. 会话管理

可查看各个 CLI 的所有会话。

使用场景：
小帅求知欲强，想看每个会话 AI 思考了什么内容，调用了什么工具，工具的返回结果是什么。

一些巧思

1. 复制服务商

可能服务商为多个 CLI 都提供了服务，那么重复填也太麻烦了，单独开发复制功能意义也不大。
于是产生了一个可以作为机制的 bug ：小帅先添加任意一个 CLI 的服务商，然后点击编辑，再将弹窗关闭。切换到另外一个 CLI 的配置 Tab ，点击添加服务商。发现原本的内容居然还在，直接保存就好啦。

TODO

  1. 负载均衡：设计是每个会话使用同一个服务商，每个新会话切换一次服务商。但是目前看来各个 CLI 的请求都没有给定当前会话的 ID，还在思考。
  2. 服务商支持官方：比如 codex 走 team 登录的话，转发好像不太能完美适配诶，其他两个没官号，没条件测试。
  3. SKILL 管理：有需求吗。

📌 转载信息
原作者：
mos6
转载时间：
2026/1/18 19:08:04

第一稿，出去吃火锅了…

断断续续研究了将近一天，终于把 cc codex 和 opencode 都迁移到了 wsl 里 了；在这里开个记录帖子，记录下自己遇到的问题以及解决方案，欢迎各位佬友友好交流，分享自己的经验。

1. 迁移动机（废话略多）

  • 最重要的一点，codex 在 windows 上的表现不佳且速度慢；
    在 windows 上使用 codex 的佬友一定经常见到过 codex 的 PowerShell 语法错误… 大量的时间和 token 被浪费于此，尽管在提示词里针对 codex 经常犯错的部分进行了提示，但仍无法有效地解决，根本原因还是 pwsh 的训练数据太少，而 unix 类天生就是大家默认的开发环境，数据多，支持地更好。且在 Linux 上 codex、cc 运行起来也更加丝滑

  • opencode 的 windows 兼容过于垃圾；
    opencode 在爆火之前我就早早的接触过了，然而… 其对 windows 的支持可谓十分之差，经常出现上一个版本还是可以启动，下一个版本就不能启动了，打开 opencode 的 github 你会发现类似的 issue 层出不穷，最经典的就是渲染出错，启动 opencode，出现 opencode [object] [Object]；在经历数次 codex 手动修复让其能够启动后，我受够了。

  • 常用的工具包或插件如 codeagent 和 claude mem 等对于 windows 的支持也很差；
    前者是我使用频率最高的 workflow+skill；而后者我更是从来没有在 windows 上成功启动过，考虑到众多插件都会优先支持 Linux 和 MacOS，我还是迁移的好。

2. windows 已有配置

  • cc switch
    我是 cc switch 的忠实用户，ccs 的伟大无需多言；我用到的核心功能主要是

    1. 多配置切换，供应商 + 全局提示词；我有各家的 coding plan 以及自己手写的多套全局提示词，十分需要 ccs 统一管理；
    [分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录2

    ccs 在当前版本可以指定 wsl 目录，这使得迁移起来没有什么难度，但是我并没有选择使用。

    1. ccs 的代理和统计功能，开启后可以直观地观测自己每天的 token 用量；ccs 的本地代理功能也是此次迁移较为顺利的根本原因
      [分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录1

3. 迁移记录

3.1 基础部分

  1. 安装 codex claude code opencode；过于简单，为了方便，我统一用 npm 了；

  2. 添加供应商配置，这个时候，刚才说过的 ccs 的本地代理功能就派上用场了；只需要把 url 指向 ccs 的代理端口即可，这里以 codex 为例

    [分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录3

    我出于一些考量，并没有选择用 ccs 直接配置，你也可以在这里更改配置目录后用 ccs 进行配置，更加自动
    [分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录4

3.2 问题来了

mcp 迁移，对于一些 npx nvx 或者 remote 类型的 mcp 很简单，都不需要改；

都知道 wsl 好，为什么我迟迟没有迁移打算呢，问题就在于这里，因为个人手搓的小玩意对于 playwright 的依赖程度较高，而 wsl… 配置图形化… 比较麻烦吧，支持地也不好，当然 这些都不是问题。

在调研站里的方案，以及询问 gpt52pro 后，我有了方案 1:

方案 1: WSL2 里跑 Linux Playwright（WSLg）

在 WSL2 里跑 Linux 浏览器（WSLg 出窗口），这个… 需要做不少的前置准备，且最后的效果也不尽人意，我在跑通后遂放弃。

1 首先必须有显示环境（WSLg）

 echo "$DISPLAY" echo "$WAYLAND_DISPLAY" echo "$XDG_RUNTIME_DIR"

2 得有浏览器二进制（Playwright 下载的 Chromium/Firefox/WebKit）


npx playwright install

3 必须有系统依赖（Ubuntu 的一堆 .so）

 # 安装系统依赖 sudo env "PATH=$PATH" npx playwright install-deps

这一套跑完，可以按照站里佬的方案持久化安装 playwright 或者 npx 启动；

它的问题是什么呢？WSLg 的浏览器实在太丑了！包括且不限于

  1. 字体的缺失导致渲染出来的网页相当地丑，你根本无法判断是自己 UI 设计问题还是渲染问题
  2. 启动时候默认一个半截窗口，全屏后不会响应式调整页面大小！这个过于逆天

尤其是 2 是我放弃方案 1 的最直接原因；

而方案 2 是我现在使用的方案，我似乎没有看到有佬提及这个方案来着？有一个佬友给出了类似的 chrome dev mcp 的安装方式，所以我就放上来供佬友参考；

方案 2： Windows 侧 Playwright MCP

基本的原理：

WSL2 (Ubuntu): claude / codex
  |
  v
/mnt/c/Windows/System32/cmd.exe /c npx @playwright/mcp@latest
  |
  v
Windows: Node+npx -> @playwright/mcp -> Playwright -> Browser (Windows GUI)

那么很简单了，以 cc 为例子：

"playwright": { "type": "stdio", "command": "/mnt/c/Windows/System32/cmd.exe", "args": ["/c", "npx", "@playwright/mcp@latest"], "env": {} }

就这么简单

4. 番外部分

4.1 官方订阅问题

当前版本的 ccs 在 codex official oauth 时候不支持本地代理功能，那么如何也让它走统计呢？答案很简单，走 cliproxyapi 这类的反代工具套一层即可，这样子官方订阅也就可以被 ccs 后台统计用量了；

[分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录5

同理，对于 antigravity tool 这类工具，也可以接入到 ccs 里统一参与用量统计；

4.2 opencode 问题

如何让 opencode 也能用上 ccs 的代理功能，其实站里有佬友已经给出解决方案了，以 codex 为例，答案就是覆写 opencode 的 openai 供应商的 base_url 字段，更改其为 ccs 暴露的本地代理端口；

不过我由于日常只有 cc 在用 omo 工作流时候会用到 opencode 的 grok 模型，对 opencode 的研究并不多，当前我发现一个很奇怪的问题，就是 opencode 会请求 gpt-5-nano；这里我还没有找到很好的解决思路。

[分享] from windows to wsl2 我的 cc,codex,opencode 迁移记录6

希望有佬友可以出手！

📌 转载信息
原作者：
FunctorFish
转载时间：
2026/1/18 19:07:52

主要以前买了个域名，一直没想出来搞啥

昨晚 3 点就醒了，突然想到能不能搞一个工作流式图片处理

你可以选择多个动作，比如压缩，改格式，灰度等

配置好参数，然后点击执行，就会依次执行操作，可以预览结果，满意就下载就行

目标是做成一个常用免费得工具站，无登录，无注册，图片本地处理，无上传，保护隐私

核心处理引擎由 rust 编写，编译成 wasm 执行，速度快

链接: https://imageide.com

vibe 时代，一天上线网站是常事阿

vibe 开发了一个图片工具站，无注册登录，供佬友免费使用1

📌 转载信息
原作者：
aizimuji
转载时间：
2026/1/18 19:07:18

记录使用 archinstall 脚本速通安装 Arch Linux 的过程。建议安装前参考 Arch Wiki Installation Guide 以了解基础知识。
如果有遗漏欢迎各位佬补充。

启动 ISO 镜像后，系统会自动登录。在终端输入 archinstall 并回车，启动安装脚本。

Arch Linux 系统安装，使用 archinstall 速通5

脚本启动后会检测网络连接。进入主菜单：

Arch Linux 系统安装，使用 archinstall 速通4

1. 配置镜像仓库 (Mirror)

为了提高下载速度，首先配置镜像源。选择 Mirrors and repositories：

Arch Linux 系统安装，使用 archinstall 速通1

在列表中按 / 键进入搜索模式，输入 China：

Arch Linux 系统安装，使用 archinstall 速通2

按 Tab 或 Enter 勾选 China，勾选后左侧会有 ✗ 标记：

Arch Linux 系统安装，使用 archinstall 速通3

启用多库：

Arch Linux 系统安装，使用 archinstall 速通6
Arch Linux 系统安装，使用 archinstall 速通7

2. 磁盘分区 (Disk Configuration)

在主菜单选择 Disk configuration，进入分区配置：

Arch Linux 系统安装，使用 archinstall 速通9

推荐选择 Use a best-effort default partition layout（使用最佳默认分区布局）：

Arch Linux 系统安装，使用 archinstall 速通8

Arch Linux 系统安装，使用 archinstall 速通10

选择文件系统。推荐使用 btrfs，它支持快照和动态子卷，配合 snapper 使用非常方便：

Arch Linux 系统安装，使用 archinstall 速通11

询问是否为 /home 创建单独的分区，通常选择默认 yes 或者根据个人喜好选择：

Arch Linux 系统安装，使用 archinstall 速通12

询问是否启用压缩，建议选择 yes ：

Arch Linux 系统安装，使用 archinstall 速通13

Btrfs 子卷配置：

Arch Linux 系统安装，使用 archinstall 速通14

确认分区设置：

Arch Linux 系统安装，使用 archinstall 速通15

3. 交换空间 (Swap)

选择 Swap，建议设为 True。脚本可能会询问是否使用 ZRAM，内存较小（<16G）建议开启 ZRAM：

Arch Linux 系统安装，使用 archinstall 速通16

4. 引导加载程序 (Bootloader)

选择 Bootloader。为了支持 Btrfs 快照启动，选择 Grub：

Arch Linux 系统安装，使用 archinstall 速通17

5. 内核选择

选择要安装的内核：

  • linux: 默认稳定版。
  • linux-lts: 长期支持版（推荐勾选，系统挂了可以用这个进）。
  • linux-zen: 桌面优化版。
Arch Linux 系统安装，使用 archinstall 速通18

确认内核选择：

Arch Linux 系统安装，使用 archinstall 速通19

6. 用户设置 (User Account)

设置 Root password（Root 密码）：

选择 User account → Add a user，输入用户名和密码：

Arch Linux 系统安装，使用 archinstall 速通20
Arch Linux 系统安装，使用 archinstall 速通21

重要：务必选择 yes 以赋予该用户 sudo 权限：

Arch Linux 系统安装，使用 archinstall 速通22

7. 桌面环境 (Profile)

选择 Profile，然后选择 Desktop（桌面）：

Arch Linux 系统安装，使用 archinstall 速通23

选择你喜欢的桌面环境（如 KDE, Gnome, Hyprland 等）：

Arch Linux 系统安装，使用 archinstall 速通24

图形驱动

选择 Graphics driver：

  • Intel/AMD 核显或 A 卡：不知道选什么全选就完了 All open-source。
Arch Linux 系统安装，使用 archinstall 速通25

登录管理器

选择 Greeter。通常保持默认即可（例如 KDE 默认使用 SDDM）：

Arch Linux 系统安装，使用 archinstall 速通26

8. 音频服务 (Audio)

选择开启 Bluetooth：

Arch Linux 系统安装，使用 archinstall 速通27

Audio 推荐选择 Pipewire：

Arch Linux 系统安装，使用 archinstall 速通28

9. 网络配置 (Network)

选择 Network configuration：

Arch Linux 系统安装，使用 archinstall 速通29

选择 NetworkManager，它提供了完整的 GUI 管理工具：

Arch Linux 系统安装，使用 archinstall 速通30

10. 时区 (Timezone)

选择 Timezone，按下 / 搜索并选择 Asia/Shanghai：

Arch Linux 系统安装，使用 archinstall 速通31

11. 额外预装包 (Additional Packages)

选择 Additional packages。在此处选择需要在安装时一并下载的软件包名称。

以下清单是推荐的常用工具（包含 Btrfs 管理、输入法、字体、Shell 等）。你可以手动安装这些包：

yay -S base-devel btrfs-assistant dosfstools fcitx5-im fcitx5-rime firejail flatpak git grub-btrfs inotify-tools linux-lts-headers linux-zen-headers noto-fonts noto-fonts-cjk man-db man-pages ntfs-3g pacman-contrib power-profiles-daemon snap-pac snapper stow tlp tlp-rdw ttf-cascadia-code-nerd ttf-dejavu-nerd ttf-jetbrains-mono-nerd zsh zsh-autocomplete zsh-autosuggestions zsh-completions zsh-syntax-highlighting
Arch Linux 系统安装，使用 archinstall 速通32

12. 开始安装

所有配置确认无误后，选择菜单底部的 Install：

Arch Linux 系统安装，使用 archinstall 速通33

按回车确认最终配置 JSON：

Arch Linux 系统安装，使用 archinstall 速通34

系统开始自动安装，请耐心等待：

Arch Linux 系统安装，使用 archinstall 速通35

安装完成后，脚本会询问接下来干嘛。通常选择 reboot 重启电脑。 记得拔掉 USB 安装盘。

恭喜，Arch Linux 安装完成！

📌 转载信息
转载时间：
2026/1/18 19:06:50
  1. 1
  2. ...
  3. 153
  4. 154
  5. 155
  6. 156
  7. 157
  8. 158
  9. 159
  10. ...
  11. 239