普通视图

发现新文章,点击刷新页面。
昨天 — 2025年9月8日首页

使用 github workflow 的 actions/setup-node 工作流,安装 pnpm 失败的 bug

作者 ruanCat
2025年9月8日 18:28

使用 github workflow 的 actions/setup-node 工作流,安装 pnpm 失败的 bug

在 github workflow 中,我们经常用 actions/setup-nodepnpm/action-setup 这两个工作流,来完成流水线安装 node 环境,并准备包管理器的需求。

我的工作流写法如下:

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: 检出分支
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: 安装pnpm
        uses: pnpm/action-setup@v4
        with:
          run_install: true

      - name: 安装node
        uses: actions/setup-node@v4
        with:
          node-version: 22.14.0
          cache: "pnpm"

这段写法产生了以下故障,这里只截取一小部分:

/home/runner/setup-pnpm/node_modules/.bin/pnpm store path --silent
/home/runner/setup-pnpm/node_modules/.bin/store/v10
Error: Dependencies lock file is not found in /home/runner/work/*** . Supported file patterns: pnpm-lock.yaml

问题起因

因为 actions/setup-node 工作流会默认检索项目内已经存在的包依赖锁文件,所以在查询包锁文件时,找不到就报错了。

如图所示:

2025-09-08-17-40-53

具体缘由见以下文档所述:

按照官网文档,我应该提交 pnpm-lock.yaml 锁文件。

个人开发习惯导致必须另辟蹊径

由于我的开发习惯,是不上传任何包锁文件的。我不喜欢上传巨大的,频繁变更的,自动生成的文件到 git 仓库,所以在工作流场景下,自然是无法提供任何包锁文件的。

类似的情况还有在 vercel 流水线部署项目时,vercel 会根据是否存在包锁文件来决定包管理器的版本号。比如我的项目在根目录内不提供任何 pnpm-lock.yamlvercel 就使用了低版本的 pnpm6,而不是我在 packageManager 内配置的最新版 pnpm。不提供 pnpm-lock.yaml 锁文件确实容易给流水线环境带来误导。

但是我的场景下,肯定不能提交锁文件。在使用 taze 实现高强度依赖升级的情况下,依赖锁文件会频繁更新,其提交到仓库的意义不大。

临时性解决方案

在设置 pnpm 缓存前,先安装依赖,生成 pnpm-lock.yaml ,避免 actions/setup-node 出现识别故障。

更新后的工作流文件如下:

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: 检出分支
        uses: actions/checkout@v4
        with:
          fetch-depth: 0

      - name: 安装pnpm
        uses: pnpm/action-setup@v4
        with:
          run_install: true

      - name: 安装依赖(尝试生成lockfile)
        run: pnpm install --frozen-lockfile

      - name: 安装node
        uses: actions/setup-node@v4
        with:
          node-version: 22.14.0
          cache: "pnpm"
昨天以前首页

什么是 OKLCH 颜色?

2025年9月5日 09:01

本篇依然来自于我们的 《前端周刊》 项目!

由团队成员 掘金安东尼 翻译,欢迎大家 进群 持续追踪全球最新前端资讯!!

原文:jakub.kr/components/…

OKLCH 是一种较新的颜色模型,设计目标是感知均匀(perceptually uniform) 。换句话说,它能够更贴近人类视觉的感受来表示颜色,让我们在使用和调整颜色时更加顺手、直观。

image.png

颜色模型

在理解 OKLCH 与其他颜色模型的区别之前,我们需要先弄清一些基本概念。

颜色模型就是一种“描述颜色的系统”。常见的有 RGB、HSL、LCH、OKLCH 等。不同模型决定了颜色能否容易地被理解、操作和思考。

image.png


色域(Gamut)

色域就像是一个“活动范围”,定义了某个模型下能表现的所有颜色。常见的色域有:

  • sRGB —— 网页默认色域
  • Display-P3 —— 现代设备常用的广色域

色域对比示意图(CIE 1931 xy 色度图):

image.png

需要注意的是,颜色空间不仅仅定义色域,还包括白点、传递函数等更多参数。为了简化,这里就不展开了。


结构(Structure)

和 LCH 类似,OKLCH 由三个值组成:

  • Lightness(亮度) :控制明暗,范围 0–1 或 0%–100%。
  • Chroma(彩度) :控制颜色的强度,类似饱和度。
  • Hue(色相) :控制色调,范围 0–360°。

image.png

区别在于:OKLCH 基于 OKLab 颜色空间,而 LCH 基于 CIELAB。


一致的亮度(Consistent Brightness)

假设你想设计几个不同颜色的按钮。传统模型(如 HSL)通常需要一个个手动调整才能看起来协调。

而在 OKLCH 中,你只需要保持 相同的亮度和彩度,只改色相,就能生成一组感知上一致的颜色。

image.png

相比之下,用 HSL 做同样的事,结果往往不均匀:有的太亮、有的太暗、有的颜色跳出来、有的又显得沉闷。

这正是 OKLCH 的最大优势之一 —— 轻松创建感知均匀的调色板


可预测的明暗变化(Predictable Shades)

如果只调整亮度,OKLCH 可以生成一系列有条理的色阶,而不会像 HSL 那样发生色相漂移。

OKLCH 与 HSL 的色阶对比:

image.png

在 HSL 中,浅蓝会飘向紫色,深蓝则会发灰。OKLCH 则始终保持“蓝色”感。


渐变(Gradients)

OKLCH 渐变的生成逻辑与传统不同。传统渐变是基于 RGB 通道计算的,常常会出现暗沉的中点或亮度不均的问题。

sRGB / OKLab / OKLCH 渐变对比图:

image.png

在 OKLCH 中,渐变的计算基于亮度、彩度和色相,因此过渡更自然。但这也带来一个副作用:渐变可能出现你没定义过的中间颜色,因为色相是一个环形参数,路径可能绕弯。

image.png

为避免这种情况,许多工具选择用 OKLab 来生成渐变,它的插值更线性,更稳定。


色域支持(Color Space Support)

sRGB 色域的限制在于,它无法覆盖现代屏幕能显示的全部颜色。而 OKLCH 可以直接书写 Display-P3 色域的颜色。

sRGB 与 Display-P3 对比:

image.png

  • 如果你的设备支持 Display-P3,你会看到右边的颜色比左边更鲜艳。
  • 如果设备只支持 sRGB,浏览器会把超出部分映射回 sRGB,显示结果接近。

灰色在两者中没有区别。


最大彩度(Maximum Chroma)

OKLCH 理论上可以定义超出任何现实屏幕的颜色。

例如:

oklch(0.7 0.4 40)

这个颜色彩度极高,数学上成立,但所有实际显示器都无法完整呈现。它会被“裁剪”或映射到最接近的可显示颜色。

因此,我们需要一个“最大彩度”的概念:它会根据亮度、色相和色域,计算出设备所能显示的极限值。


浏览器支持与回退方案

OKLCH 定义在 CSS Color Module Level 4 中,目前大多数现代浏览器都支持。

但在一些老旧浏览器中可能不兼容。这时,可以通过 @supports 添加回退方案:

@layer base {
  :root {
    /* sRGB 颜色 */
    --color-gray-100: #fcfcfc;

    @supports (color: oklch(0 0 0)) {
      /* OKLCH 颜色 */
      --color-gray-100: oklch(0.991 0 0);
    }
  }
}

如果浏览器支持,就用 OKLCH;不支持,就用 sRGB。


工具:oklch.fyi

我还做了一个小工具 oklch.fyi,可以:

  • 生成 OKLCH 调色板
  • 把你现有的 CSS 变量转换为 OKLCH
  • 帮助更直观地探索这个模型

image.png


小结

点评:以前的颜色模型像是老旧的地铁地图,表面上线路对齐,但实际走起来,有的站很近、有的很远,比例不准,导致颜色数值改一点,肉眼感觉却差很多。

OKLCH 就像是按真实比例绘制的导航地图,每一步都和人眼的感受匹配:亮度就是亮度,色相就是色相,不会跑偏。

背后技术就是 OKLab 感知均匀色彩空间,它用数学方法模拟人眼对颜色的敏感度,修正了老模型的不均匀性。

这 4 个牛逼 GitHub 开源项目,太优质了。

作者 逛逛GitHub
2025年9月6日 12:47

01、高质量数据集整理

这个开源项目,从 11 年前就开始维护,现在已经获得 65K 的 Star 了。

图片

它把整个互联网上开源的数据集都搜罗过来了,大部分都是主题明确、质量较高的公开数据集。

这个大合集最棒的地方在于它按主题分类。

图片

无论是全球历史作物产量、人类基因组计划数据、金融经济、地理信息,还是社交媒体、交通出行,甚至游戏和体育统计,你都能找到对应的分类。

图片图片

里面列出的数据集大多可以免费使用,有些需要额外授权的,也标注出来了。

开源地址:https://github.com/awesomedata/awesome-public-datasets

02、解读 K 线图的开源模型

Kronos 是首个面向金融市场的解读 K 线图基础模型。由清华大学与微软亚洲研究院(MSRA)的研究团队联合开源

图片

开源地址:https://github.com/shiyu-coder/Kronos

它分析股票、加密货币等资产的K线数据,包含开盘价、最高价、最低价、收盘价及成交量,预测未来价格走势。

模型训练数据覆盖全球 45+ 交易所,能适应金融数据特有的高波动性和噪声。

这个模型专为金融设计,与通用时序模型不同,Kronos 首创 两阶段处理框架

  • 智能分词器:将连续的K线数据转化为离散的「金融词汇」。
  • 预测大模型:基于Transformer架构,从历史数据中学习规律,预测未来走势。

图片仅需 4 行代码 即可加载模型,输入历史 K 线数据后自动输出预测结果。而且开源项目提供一个 Demo, 这是一个实时的 BTC/USDT 的预测仪表盘,根据这个开源模型的计算结果,来预测未来走势。有点意思嗷。不知道准不准,明天看看。图片

03、实时语音转录

WhisperLiveKit 是一个完全在你自己电脑上运行的 实时语音转文字工具

图片

它不同于普通的录音转文字软件需要你录完再处理,它能一边听你说话,一边就把文字显示出来,几乎没有延迟,还能分清谁在说。

所有处理都在你自己的电脑上进行,你的语音数据不需要上传到任何云端服务器,隐私性更好。

开源地址:https://github.com/QuentinFuxa/WhisperLiveKit

它采用了2025年最新的语音技术(如 SimulStreaming ),专门解决实时转写时常见的断词、上下文丢失等问题,让结果更准确流畅。

而且它自带了一个简单的网页界面和一个后台服务。安装好后,启动服务,打开浏览器就能直接使用,不需要复杂的配置。

04、开源的 Agent 工具箱

Youtu-agent 可以帮助你轻松构建、运行和评估 Agent 的工具箱。

让它分析一份数据表格、从网上搜集资料写报告、或者帮你整理电脑里杂乱的文件,这些 Youtu-agent 都能做到。

开源地址:https://github.com/Tencent/Youtu-agent

它基于开源的大模型,如 DeepSeek-V3 系列来做出强大的智能体功能。

在一些公认的智能体能力测试上(如 WebWalkerQA 和 GAIA)取得了非常不错的成绩(70% 多的成功率),证明了开源模型也能胜任复杂任务。这避免了依赖昂贵或不开源模型(如 Claude 或 GPT)的成本和限制。

图片

Gitee 与 GitHub 仓库同步:从手动操作到自动化部署

作者 袋鱼不重
2025年9月4日 18:16

总共有三种方式,可以根据自身需求进行选择:

同步方案 操作复杂度 同步效率 适用场景 优点 缺点
手动同步 偶尔更新(每周 1-2 次) 无需额外配置,灵活可控 频繁同步时繁琐,易遗漏
脚本自动化 频繁更新(每日多次) 一键操作,本地可控,支持双向 需要本地执行,依赖脚本
平台工具同步 实时联动(推送到一个平台后自动同步另一个) 无需本地操作,实时性强 Gitee 仅支持单向,GitHub Actions 需配置 Secrets

准备工作

在开始同步前,需要确保你已完成以下基础配置,避免后续操作中出现权限问题:

  1. 创建仓库:分别在 GitHub 和 Gitee 上创建同名仓库(建议仓库名、分支名保持一致,如默认分支都用 main),如果已有仓库可跳过此步。
  2. 配置 Git 身份:确保本地 Git 已配置用户名和邮箱(与平台账户关联),执行以下命令检查:
git config --global user.name  # 查看用户名
git config --global user.email  # 查看邮箱
# 若未配置,执行以下命令设置
git config --global user.name "你的用户名"
git config --global user.email "你的邮箱"
  1. 权限验证:推荐使用 SSH 密钥验证(避免每次推送输入密码),分别在 GitHub 和 Gitee 上添加本地 SSH 公钥:
    • 生成 SSH 密钥(若未生成):ssh-keygen -t ed25519 -C "你的邮箱"(一路回车即可)。
  1. -t ed25519: 指定使用 ED25519 算法,这是 GitHub 当前推荐的、更安全、性能更好的算法。
  2. -C "...": 为您的密钥添加一个注释,通常使用您的邮箱地址以便识别。
  3. 运行命令后,终端会问两个问题。直接按回车Enter,接受默认设置。
    1. 问题一:Enter file in which to save the key (/c/Users/kjy/.ssh/id_ed25519):
      1. 询问您想把密钥文件保存在哪里,括号里的是默认路径
      2. Created directory '/c/Users/kjy/.ssh'.
    2. 问题二:Enter passphrase for "/c/Users/kjy/.ssh/id_ed25519" (empty for no passphrase):
      1. 询问是否要为这个密钥设置一个额外的密码(私钥密码)。这是一个可选的安全增强措施。
      2. 为了简化流程,可直接按下 Enter 键,表示不设置密码
      3. 之后会要求再次输入以确认,请再按一次 Enter 键

复制公钥:cat ~/.ssh/id_ed25519.pub(Windows 路径为 C:\Users\你的用户名\.ssh\id_ed25519.pub)。

  1. 终端会显示一长串以 ssh-ed25519... 开头,并以您的邮箱地址结尾的文本。这就是您的公钥。
  2. 用鼠标完整地复制这一整串文本

在 GitHub/Gitee 平台的「个人设置 → SSH 密钥」中粘贴公钥,完成添加。

  1. 回到浏览器,打开 GitHub SSH 密钥设置页面。github.com/settings/ke…
  2. 点击 New SSH key (新建 SSH 密钥)。
  3. 在 Title (标题) 栏中,给它起一个名字(例如:“我的Windows电脑”)。
  4. 在 Key (密钥) 文本框中,粘贴您刚刚复制的那一长串公钥。
  5. 点击 Add SSH key (添加 SSH 密钥)。

  1. Gitee 一样的操作,添加SSH公钥。gitee.com/profile/ssh…

方式一:手动同步(适用个人小项目、更新频率低)

如果你的仓库更新频率低(如每周 1-2 次),手动同步足够简单高效,核心思路是「给本地仓库添加两个远程地址,分别推送代码」。

步骤1:关联两个远程仓库

首先将本地仓库与 GitHub、Gitee 仓库关联(若本地无仓库,需先克隆任一平台仓库):

  1. 克隆仓库(本地无代码时):

先克隆 GitHub 仓库到本地(也可克隆 Gitee,后续添加另一个远程即可):

git clone git@github.com:你的用户名/你的仓库名.git  # SSH 地址
# 或 HTTPS 地址:git clone https://github.com/你的用户名/你的仓库名.git
cd 你的仓库名  # 进入仓库目录
  1. 添加第二个远程地址:\ 查看当前已关联的远程仓库,确认是否已有目标平台地址:
git remote -v  # 输出类似:origin  git@github.com:xxx/xxx.git (fetch)

若缺少 Gitee 地址,执行以下命令添加(远程名可自定义,建议用 github 和 gitee 区分):

# 添加 Gitee 远程(SSH 地址,也可替换为 HTTPS 地址)
git remote add gitee git@gitee.com:你的用户名/你的仓库名.git
# 若需添加 GitHub 远程(本地克隆的是 Gitee 仓库时)
git remote add github git@github.com:你的用户名/你的仓库名.git

再次执行 git remote -v,若看到 github 和 gitee 两个远程地址,说明关联成功。

步骤2:手动推送代码到两个平台

当本地代码有更新时,按以下流程同步到两个仓库:

  1. 提交本地更改
git add .  # 添加所有更改(也可指定文件,如 git add README.md)
git commit -m "feat: 新增同步说明文档"  # 填写有意义的提交信息
  1. 分别推送到 GitHub 和 Gitee
# 推送到 GitHub 的 main 分支
git push github main
# 推送到 Gitee 的 main 分支
git push gitee main

若推送成功,打开两个平台的仓库页面,即可看到代码已同步。

注意:如果远程分支有更新(如他人提交),需先拉取最新代码再推送,避免冲突:

git pull github main # 拉取 GitHub 最新代码

git pull gitee main # 拉取 Gitee 最新代码

方式二:脚本自动化同步(适用频繁更新,每日多次)

如果你的仓库每天需要多次同步,手动执行 push 命令会很繁琐。此时可以写一个 Shell 脚本,将「提交 + 双平台推送」打包成一条命令,一键完成同步。

  1. 在仓库根目录下新建脚本文件 <font style="color:rgba(0, 0, 0, 0.8);">sync_repos.sh</font>(文件名可自定义),粘贴以下内容:
#!/bin/bash
# 功能:自动提交本地更改,并同步到 GitHub 和 Gitee 仓库
# 使用方法:./sync_repos.sh "你的提交信息"

# 1. 检查是否传入提交信息
if [ $# -eq 0 ]; then
    echo "❌ 请提供提交信息!例如:./sync_repos.sh 'fix: 修复登录bug'"
    exit 1  # 退出脚本,状态码1表示错误
fi

# 2. 添加所有本地更改
echo "🔍 正在添加本地更改..."
git add .
if [ $? -ne 0 ]; then  # $? 表示上一条命令的执行结果,0为成功
    echo "❌ 添加更改失败,请检查本地文件状态!"
    exit 1
fi

# 3. 提交更改(使用传入的参数作为提交信息)
echo "📝 正在提交更改,信息:$1"
git commit -m "$1"
if [ $? -ne 0 ]; then
    echo "❌ 提交失败!可能没有需要提交的更改(git status 查看)。"
    exit 1
fi

# 4. 推送到 GitHub
echo "🚀 正在推送到 GitHub..."
git push
if [ $? -eq 0 ]; then
    echo "✅ GitHub 推送成功!"
else
    echo "❌ GitHub 推送失败,请检查网络或权限!"
    exit 1
fi

# 5. 推送到 Gitee
echo "🚀 正在推送到 Gitee..."
git push gitee
if [ $? -eq 0 ]; then
    echo "✅ Gitee 推送成功!"
else
    echo "❌ Gitee 推送失败,请检查网络或权限!"
    exit 1
fi

# 6. 同步完成
echo "🎉 所有仓库同步完成!"

注意根据实际推送命令进行调整,例如想要推送到指定分支main,给github远程地址设定了别名为github:

# 4. 推送到 GitHub
echo "🚀 正在推送到 GitHub..."
git push github main
if [ $? -eq 0 ]; then
    echo "✅ GitHub 推送成功!"
else
    echo "❌ GitHub 推送失败,请检查网络或权限!"
    exit 1
fi
  1. 给脚本添加执行权限(仅首次需要)

Linux/Unix系统:

chmod +x sync_repos.sh

# 后续每次需要同步时,只需在仓库目录下执行:
./sync_repos.sh "你的提交信息"  # 例如:./sync_repos.sh "docs: 更新同步脚本说明"

windows系统有以下两种方式:

(1)需要使用 git bash 来执行

chmod +x sync_repos.sh

后续每次需要同步时,只需在仓库目录下执行:

./sync_repos.sh "你的提交信息"  # 例如:./sync_repos.sh "docs: 更新同步脚本说明"

(2)使用 Windows 批处理文件:.bat

@echo off
REM Auto commit and sync to GitHub and Gitee repositories
REM Usage: sync_repos.bat "your commit message"

REM 1. Check if commit message is provided
if "%~1"=="" (
    echo [ERROR] Please provide commit message! Example: sync_repos.bat "fix: login bug"
    exit /b 1
)

REM 2. Add all local changes
echo [INFO] Adding local changes...
git add .
if errorlevel 1 (
    echo [ERROR] Failed to add changes! Please check local file status!
    exit /b 1
)

REM 3. Commit changes
echo [INFO] Committing changes with message: %*
git commit -m %*
if errorlevel 1 (
    echo [WARNING] No changes to commit, continuing with push...
)

REM 4. Push to GitHub
echo [INFO] Pushing to GitHub...
git push
if errorlevel 1 (
    echo [ERROR] GitHub push failed! Please check network or permissions!
    exit /b 1
) else (
    echo [SUCCESS] GitHub push successful!
)

REM 5. Push to Gitee
echo [INFO] Pushing to Gitee...
git push gitee
if errorlevel 1 (
    echo [ERROR] Gitee push failed! Please check network or permissions!
    exit /b 1
) else (
    echo [SUCCESS] Gitee push successful!
)

REM 6. Sync completed
echo [SUCCESS] All repositories synced successfully!

后续每次需要同步时,只需在仓库目录下执行:

sync_repos.bat "你的提交信息"

脚本会自动完成「添加更改→提交→推送到 GitHub→推送到 Gitee」,并输出每一步的结果,失败时会提示原因。

方式三:平台工具同步(适合实时联动场景)

如果需要「推送到一个平台后,另一个平台自动同步」(如推送到 GitHub 后,Gitee 自动更新),可以利用平台自带的工具或第三方服务实现,无需本地操作。

方案 1:Gitee 自带「GitHub 同步」功能

Gitee 提供了一键同步 GitHub 仓库的功能,适合以 GitHub 为主要仓库、Gitee 为镜像的场景。

操作步骤:

  1. 两种方式
    1. 【每次都需要重新输入账号和令牌】进入 Gitee 仓库页面,点击 管理 -> 功能设置 -> 同步 -> 保存。保存后会发现仓库名上多了个刷新按钮

点击顶部导航栏的「同步」按钮(若未关联 GitHub,需先授权)。

出现 TIP 提示,拉取成功

在 github 获取个人令牌步骤:

  1. 在Github中点击头像,找到setting选项,在左侧找到Develpoer settings选项
  2. 在左侧找到Personal access tokens–>Tokens(classic)–>Generate new token–>Generate new token(classic)

  1. 生成的令牌只展示一次,记得复制保存,刷新页面后就无法再次查看令牌了(只能重新生成令牌)
  1. 进入 Gitee 仓库页面,点击 管理 -> 仓库镜像管理 -> 添加镜像 -> 授权操作 -> 选择镜像方向 -> 添加 -> 点击更新按钮,手动更新 仓库镜像管理 ( Gitee <-> Github 双向同步) - Gitee.com

方案 2:GitHub Actions 自动同步到 Gitee

GitHub Actions 是 GitHub 自带的自动化工具,可以配置「当代码推送到 GitHub 后,自动同步到 Gitee」,实现双向同步的效果(若推送到 Gitee 后需同步到 GitHub,可在 Gitee 配置「WebHook + 自定义服务」,但步骤较复杂,此处重点讲 GitHub → Gitee)。

操作步骤:

  1. 生成 SSH 密钥对(若已生成,可跳过):

执行 ssh-keygen -t ed25519 -C "你的邮箱",一路回车,生成 id_ed25519(私钥)和 id_ed25519.pub(公钥)。

# 获取私钥
cat ~/.ssh/id_ed25519
# 获取公钥
cat ~/.ssh/id_ed25519.pub
  1. 将公钥添加到 Gitee:
    1. 复制公钥内容:cat ~/.ssh/id_ed25519.pub。
    2. 进入 Gitee 「个人设置 → SSH 密钥」,粘贴公钥,备注填写「GitHub Actions Sync」,点击「确定」。
  2. 将私钥添加到 GitHub Secrets:
    1. 进入 GitHub 仓库页面,点击「Settings → Secrets and variables → Actions → New repository secret」。

2. 「Name」填写 GITEE_RSA_PRIVATE_KEY(必须与后续配置文件中的变量名一致),「Secret」粘贴 id_ed25519(私钥)的内容,点击「Add secret」。注意,这里的私钥复制全,包括 -----BEGIN OPENSSH PRIVATE KEY----- 和 -----END OPENSSH PRIVATE KEY-----

  1. 创建 GitHub Actions 工作流配置文件:
    1. 在本地仓库根目录下,新建目录 .github/workflows(若不存在)。
    2. 在该目录下新建文件 sync-to-gitee.yml,粘贴以下内容:
name: Sync GitHub to Gitee  # 工作流名称

# 触发条件:当代码推送到 GitHub 的 main 分支时触发
on:
  push:
    branches: [ main ]  # 可修改为你的默认分支,如 master

# 工作流任务
jobs:
  sync:
    runs-on: ubuntu-latest  # 运行环境(Ubuntu 系统)
    steps:
      # 步骤1:拉取 GitHub 仓库代码
      - name: Checkout GitHub code
        uses: actions/checkout@v4  # 使用官方的代码拉取动作
        with:
          fetch-depth: 0  # 拉取所有历史记录,避免缺失提交
      
      # 步骤2:将代码同步到 Gitee
      - name: Sync to Gitee
        uses: wearerequired/git-mirror-action@v1  # 使用第三方同步动作
        env:
          # 从 GitHub Secrets 中获取私钥
          SSH_PRIVATE_KEY: ${{ secrets.GITEE_RSA_PRIVATE_KEY }}
        with:
          # 源仓库(GitHub)地址(SSH 格式)
          source-repo: git@github.com:你的用户名/你的仓库名.git
          # 目标仓库(Gitee)地址(SSH 格式)
          destination-repo: git@gitee.com:你的用户名/你的仓库名.git
5. 将配置文件提交并推送到 GitHub:
git add .github/workflows/sync-to-gitee.yml
git commit -m "ci: 添加 GitHub Actions 同步到 Gitee 的工作流"
git push github main
  1. 验证同步效果:
    1. 推送到 GitHub 后,进入 GitHub 仓库页面,点击「Actions」,查看工作流是否运行成功(绿色对勾表示成功)。
    2. 若成功,打开 Gitee 仓库页面,即可看到代码已自动同步。

附录

# 刷新 DNS 缓存
# Windows
ipconfig /flushdns
# macOS
sudo killall -HUP mDNSResponder
# Linux
sudo systemctl restart network-manager

零一开源|前沿技术周刊 #12

作者 kymjs张涛
2025年8月20日 09:22

前沿技术周刊 是一份专注于技术生态的周刊,每周更新。本周刊深入挖掘高质量技术内容,为开发者提供持续的知识更新与技术洞察。

订阅渠道:【零一开源】、 【掘金】、 【RSS


大厂在做什么

美团智能头盔作为专为外卖骑手打造的智能安全装备,具备蓝牙通话、戴盔识别、智能语音助手、碰撞摔倒监控等功能,核心软件功能围绕如何通过主动安全和被动安全相结合的方式有效保护骑手。 本期分享主要介绍智能头盔骑行通话质量、智能语音助手、碰撞摔倒监控三项软件能力。其中“骑行通话质量和智能语音助手”降低骑手操作手机导致的“分心”,帮助骑手“防患于未然”。“碰撞摔倒监控”最大限度的保护骑手、快速的感知事故和触发救治。
在数字内容井喷的时代,移动端已成为视频创作的重要阵地,而视频编辑页作为创作工具的核心场景,不仅为创作者提供了丰富的表达手段和创意平台,更是提升视频制作的效率。通过直观的操作界面和丰富的功能集成,用户可以轻松地将素材、音频、特效及文字等进行融合,创造出独具风格、彰显个性的作品。
如今,AI 编程工具正在重塑软件开发,其核心目标直指“开发民主化”。它们不再仅仅是补全代码片段的助手,而是能理解自然语言需求、生成可运行代码框架、甚至参与系统设计的“协作者”。这一背景下,越来越多的企业开始对外发布相关产品,美团便是其中之一。
兄弟们,刚点开这篇《2025 Google 开发者大会主旨演讲精华汇总》,结果微信提示“环境异常”,得验证才能看… 估计是链接被拦截了?暂时没法扒拉具体内容,等能进去了再瞅瞅。不过按往年套路,大概率是AI开发工具更新、云原生新特性、Android/iOS跨端方案这些硬货,可能还有TensorFlow或Flutter的新版本?回头内容正常了再补个详细的,现在只能说——等我验证完再给你们同步干货!
高德终端技术团队进行开源项目仓库代码升级期间,由于主版本跨度大,代码量更新变化也很大,过往在低版本上的经验知识不足以支持升级,如果依赖个人读懂整体仓库代码耗时过长。为研发提效,使用了阿里内部代码平台工具,发现暂不能满足一些定制化的知识问答,同时使用上也存在一些限制,外部类似deepwiki工具又存在代码安全问题,因此,基于code RAG和code Agent技术开发了研发提效工具,一定程度上满足了对仓库代码的定制理解,查询和修改需求。
从最初仅支持面向编译时的小程序端解决方案,到如今拥有支持多种前端框架和 UI 库的强大能力;从单一的构建工具,到通过开放生态为开发者提供 Webpack、Vite、ESBuild 等丰富的工具选择,让团队能够定制专属的研发流程;从专注小程序开发,到覆盖各大小程序平台以及 Web、iOS、Android、HarmonyOS 等移动端场景——Taro 的每一步成长都离不开社区的力量。
最近,我们上线了一个新能力:支持将部分中文视频翻译为外语的原声风格配音。也就是说,观众现在可以听到“这个人用另一种语言在说话”,但他的声音、语气、节奏,甚至个性表达都和原片几乎一致,不再是那种传统配音里千篇一律的“代言人声线”,而是像本人亲自讲外语一样自然。这背后,其实是一整套跨模态、多语言协同生成系统的能力升级。
在现代播放器架构中,音频后处理已不仅是锦上添花的功能,而是构建差异化听觉体验的关键组件。尤其在多样化的播放场景(手机外放、耳机、电视音响等)下,通过定制化的音效增强手段,有效提升听感表现已成为基础能力之一。

码圈新闻

这两天在上海世博展览馆举行的 2025 世界人工智能大会(WAIC)热度相当高,上到央媒下到朋友圈不断看到,甚至总理李强、双奖(诺贝尔/图灵)得主辛顿都在开幕式出现,影响力爆表。 周末去逛了一天,AI 的落地场景之多令人咋舌,看完以后我给之前的好几个点子都划上了删除线。还是得多出来看看大厂/新秀公司都在做什么,避免做类似的事情。 这篇文章按照类别记录一下印象比较深刻的产品。
刚刷完2025 Google开发者大会的客户端内容,给咱3年+的老哥们捋捋重点。 Android 15是重头戏:后台任务管理收紧了,得注意`WorkManager`新的电量阈值限制,不然应用可能被系统强杀;UI渲染加了硬件加速新接口,复杂列表滑动能再提10-15帧,对电商、社交类应用挺香。 开发工具方面,Android Studio Hedgehog直接集成了AI代码诊断,写`Compose`时会自动提示重组优化点,试了下比之前手动查省事儿多了。Flutter 4.0也放了大招,原生代码互调延迟降了40%,混编项目终于不用再纠结性能损耗了。 哦对了,跨平台布局`Jetpack Multiwindow`支持更完善了,平板/折叠屏适配能少写一半适配代码。暂时就这些干货,后台优化和Flutter新特性建议优先上手,其他的可以先放收藏夹吃灰~
今日,亚马逊云科技首次上线 OpenAI 开放权重模型,向数百万亚马逊云科技客户开放。客户现可通过 Amazon Bedrock 和 Amazon SageMaker AI 使用 OpenAI 开放权重模型,实现将先进的开放权重模型与全球最广泛云服务的深度集成。
世界机器人大会已经走过10年,回看以前的新闻和产品,此刻站在场馆里大概只有一个感慨:机器人发展太迅速了!
北京时间8月8日凌晨1时,OpenAI举行了长达1个多小时的线上发布会,正式推出了GPT-5。与此前的模型更新直播时间短且主要由研发人员发布相比,GPT-5的发布明显规格更高,不仅发布时间长、细节多,而且OpenAI首席执行官山姆·奥特曼也现身发布会现场。

深度技术

这篇文章我瞅着是讲Android底层的,主要扒了ART虚拟机加载Dex的整个流程,从Dex文件解析到内存映射、类加载这些关键步骤都拆得挺细。重点是结合脱壳场景,分析了加载过程里哪些节点能当通用脱壳点——比如某个钩子函数的调用时机、内存中Dex原始数据的暴露时刻。对咱们这种搞Android逆向或底层开发的来说,理清ART Dex加载逻辑,找脱壳点就有章法了,实操性挺强,值得细品。
在AI技术迅猛发展的今天,如何与大型语言模型高效“对话”已成为释放其潜力的关键。本文深入探讨了提示词工程(Prompt Engineering)这一新兴领域,系统解析了从基础概念到高级技巧的完整知识体系,并结合“淘宝XX业务数科Agent”和科研论文深度学习两大实战案例,揭示了高质量提示词如何将AI从“工具”升级为“智能协作者”。无论你是初学者还是实践者,都能从中掌握让AI真正为你所用的核心方法论。
Cursor 是近来大火的 coding agent 工具,凭借其深度集成的智能代码生成、上下文感知和对话式编程体验,极大地提升了开发效率,成为众多工程师日常开发的得力帮手。作为 Cursor 的付费用户,我已将其作为主力编码工具,每天在实际项目中频繁使用。只有真正深入使用,才能切身感受到它所带来的编程体验的神奇之处。在这个过程中,我也对其背后的技术实现产生了浓厚兴趣,本文试图通过一系列实验,深入分析 Cursor 在后台与大模型之间的通信机制,探寻 Cursor 智能能力背后的底层思想与设计原理。
多模态大语言模型(Multimodal Large Language Model)是指能够处理和融合多种不同类型数据(如文本、图像、音频、视频等)的大型人工智能模型。此类模型通常基于深度学习技术,能够理解和生成多种模态的数据,从而在各种复杂的应用场景中表现出强大的能力。
在构建RAG(检索增强生成)系统时,文本分块质量直接影响知识检索精度与LLM输出效果。本文将深入解析五种分块策略的工程实现与优化方案。文中还会放一些技术文档,方便大家更好的理解RAG中常见的技术点。

新技术介绍

迄今为止最大的Compose更新带来了原生自动填充, 智能动画以及让构建Android用户界面如同魔法般轻松的功能
兄弟,你发的这篇Flutter 3.35更新的文章内容好像有点小状况啊——页面显示“环境异常”,得先验证才能看具体内容。我这刷了半天,也没瞅见更新了啥新特性、优化了哪些性能。要不你先去把验证搞定,把正经的更新内容放出来?等内容齐了,我再帮你扒拉扒拉这版3.35到底香不香~
TheRouter 是由货拉拉技术开源的,可同时用于 Android/iOS/HarmonyOS 模块化开发的一整套解决方案框架。Android 支持 KSP、支持 AGP8,iOS 支持 OC/Swift,不仅能对常规的模块依赖解耦、页面跳转,同时提供了模块化过程中常见问题的解决办法。例如:完美解决了模块化开发后由于组件内无法获取 Application 生命周期与业务流程,造成每次初始化与关联依赖调用都需要跨模块修改代码的问题,是目前业界最领先的移动端路由框架。
随着AI时代的到来,各类AI工具层出不穷,业界都在探索一套完整的AI加成的提效方案,我们团队基于自身特色,利用起团队沉淀好的历史知识库,落地了一套深度结合AI的工作流,用AI武装研发团队,实现研发效率的提升。

博客推荐

兄弟,你给的这篇文章内容好像有点问题啊。标题写着《适配 16KB 页面大小:提升应用性能并为用户提供更流畅的应用体验》,但正文全是微信环境异常的提示,什么“完成验证后继续访问”“小程序赞”“在看”之类的,根本瞅不见正经内容。这样我没法帮你总结摘要啊,估计是复制的时候出岔子了?要不你检查下内容是不是漏了,或者重新发下正文?等你弄好我再帮你扒拉扒拉~
兄弟们,刚瞅了眼你发的《深入浅出Android的Context机制》,内容咋全是微信验证、点赞那些玩意儿?正文好像没显示出来啊。不过Context这东西咱老安卓开发肯定熟,简单说就是个“万能管家”——访问资源、启动Activity/Fragment、调系统服务(比如LayoutInflater、NotificationManager)都得靠它。最容易踩坑的就是Context的生命周期:Application Context全局单例,跟着应用走;Activity Context跟页面生命周期绑定,用完就没。要是拿Activity Context搞个静态单例,页面关了还被占着,内存泄漏妥妥的。平时记着:长生命周期的对象(比如单例、Handler)别用Activity Context,能用Application Context就用,准没错。等你文章内容正常了再细扒,先记住这几点避坑~
一般来说ArkWeb作为鸿蒙的Web容器,性能是够用的。但是针对网页的前置处理条件较多,例如涉及到DNS,大量的资源下载,网页和动画渲染等。作为重度依赖资源链的容器,当某个资源还没ok,就会很容易出现白屏,卡端,长时间loading这些影响用户体验的问题。

GitHub 一周推荐

阿里开源最新文生图模型

关于我们

零一开源】 是一个 文章开源项目 的分享站,有写博客开源项目的也欢迎来提供投递。 每周会搜集、整理当前的新技术、新文章,欢迎大家订阅。

[奸笑]

❌
❌