RKit：我常用的 uTools 工具的“轻量替代”

我以前一直用 `uTools`。 说实话，它在我这儿属于那种“装机必备”级别的工具：搜东西、翻译、截图、OCR、剪贴板……一堆日常零碎事，按个热键就能搞定。 但后来 uTools 越来越臃肿，也开始限制插件数量，这我还能忍，毕竟我平时用的插件也不多，最让我绷不住的是：**开始强制登录**了。 我不是说登录就一定不好，我只是很不喜欢“一个本来用来提升效率的小工具”，慢慢变成“需要账号体系才能用”的东西 于是我就去找“uTools 平替”。 我试了 `zTools`，确实和utools差不多，但用了一段时间总觉得有些地方不太对：要么是某个流程不顺手，要么是细节不符合我的习惯。也不是不能用，就是用的时候会忍不住嘀咕一句：“要是这里能这样就好了……” 结果我一想：我每天高频用的功能就那几个，**干脆我自己做一个算了**。 于是就有了 `RKit`。 --- ## RKit 是个啥？一句话 `RKit` 就是一个 **macOS 上的命令面板**(后面也会做 windows)，有点像 Spotlight： 按热键 → 弹出一个小面板 → 执行动作。 我不想做插件市场，也不想做一堆花里胡哨的功能。 我就想把我每天用的那几个能力做得**顺手、够快、够稳定**。 --- ## 它能干啥？就我常用的这几个 我现在最常用的是这些： - `截图`：区域截图 → 自动复制到剪贴板 → 顺手还能进内置编辑器改两笔 - `OCR`：对最近一次截图做文字识别（macOS 自带 `Vision`） - `翻译`：默认 Google GTX（不用 key），也可以配 Deeplx（自己搭个接口那种） - `剪贴板历史`：文本 + 图片，支持置顶/搜索，还能一键暂停采集 10 分钟 - `设置`：语言、热键录制、开机自启动、清理历史这些 你会发现，它就是“uTools 里我真正每天在用的那几个东西”。  --- ## 我做它最在意的点 ### 1）快：要像 Spotlight 那样“按下就出来” 默认热键是： - `Option + Space`：呼出/关闭 - `Esc`：关闭 我希望它是那种你不需要思考的动作： 手指一按，它就出现；你输入，回车，事情结束。 ### 2）别打扰：别把我从当前桌面/当前软件拽走 有些工具的面板会乱跳桌面，或者截图完又把焦点抢回去，这种我很难忍。 RKit 的目标是：**你在哪儿用，它就在哪儿出现**，尽量别干扰你的主工作流。 ### 3）本地优先：默认不联网 我个人比较敏感的一点是： 这种工具一旦开始“强制登录”，我就会下意识担心：我输入的东西、剪贴板、截图，会不会被上传、被统计、被分析？ RKit 的原则很简单： - 默认本地优先 - 只有“翻译”可能要联网（你选的翻译服务决定） --- ## 怎么装？（现在是未签名 ZIP） RKit 目前走的是 **未签名 ZIP** 发布（主打一个快，先让大家用起来）。 ### 安装步骤 1. 从 GitHub Releases 下载 `RKit.app.zip` 2. 解压得到 `RKit.app` 3. 把 `RKit.app` 拖到 `/Applications` 4. 打开运行 ### 如果被 Gatekeeper 拦了（无法打开 / 提示“已损坏”） 先确认你已经把 `RKit.app` 拖到了 `/Applications`，再执行： ```bash xattr -dr com.apple.quarantine /Applications/RKit.app ``` 然后 Finder 里右键 `RKit.app` → `打开`。 --- ## 权限这块：截图一定会要“屏幕录制” 截图功能需要 macOS 的“屏幕录制”权限： `系统设置 → 隐私与安全性 → 屏幕录制 → 勾选 RKit` 这块没啥好绕的，系统规则就是这样。 我能做的就是把引导写清楚、交互做顺，不搞那些“偷偷申请一堆你用不到的权限”。 --- ## 后续计划 我不会把 RKit 做成“全能工具”，我更想把它做成一种**很顺手的日常习惯**： 有什么我高频使用的功能，我会添加进去 也会尽快开发 windows 版本 --- ## 致谢 - Deeplx（DeepLX）：<https://github.com/OwO-Network/DLX> 感谢 DeepLX 开源项目：它使得在自建环境中通过本地 API 方式使用 DeepL 的免费网页翻译成为可能。 我就是使用本地部署的地址：  --- ## 最后 做 RKit 的起点其实很简单： 我只是想要一个“不臃肿、不强制登录、只做我常用功能”的工具。 如果你也跟我一样日常使用这几个工具，欢迎来试试看。 如果遇到什么问题，欢迎随时指出。 如果你觉得项目对你有帮助，欢迎点个Star，感谢！！ 项目地址：[https://github.com/Han-GR/rkit](https://github.com/Han-GR/rkit) 下载地址：[https://github.com/Han-GR/rkit/releases/download/v1.0.1/RKit.zip](https://github.com/Han-GR/rkit/releases/download/v1.0.1/RKit.zip)

codex同时使用官方账号与第三方 API

# Codex 双环境隔离：在同一台 Windows 上同时使用官方账号与第三方 API > 通过 `CODEX_HOME` 隔离 VS Code Stable、VS Code Insiders、ChatGPT Desktop 与 Codex CLI 的账号和 API 环境。 ## 1. 背景 大家好，这是一个简单的用户隔离操作，我在 Windows 上使用 Codex / ChatGPT / VS Code 插件时，遇到了一个需求： 由于plus账号的codex额度太少，5X的pro对于开发时间分布并不均匀的我来说会造成浪费 而且codex的风控让我不敢贸然使用ccswitch来切换账户 所以我希望在同一台电脑上同时保留两套 Codex 环境： - **官方账号环境** - VS Code Stable - ChatGPT Desktop / Codex Desktop - 普通 Codex CLI - 使用 ChatGPT 官方账号 - 走官方订阅额度 - **第三方 API 环境** - VS Code Insiders - 使用第三方 API 中转站 - 使用独立 API Key - 和官方账号完全隔离 - 不影响 Stable、普通 CLI 和 ChatGPT Desktop 一开始我以为只要安装两个 VS Code，或者使用 VS Code Profile，就可以实现账号隔离。实际测试后发现并不是这样。 最终可维护的方案是： > 不依赖 VS Code Profile，也不依赖 Stable / Insiders 天然隔离，而是通过 `CODEX_HOME` 为 Codex 创建独立的本地身份空间。 --- ## 2. 问题现象 ### 2.1 VS Code Profile 不能可靠隔离 Codex 账号 我创建了两个 VS Code Profile： ```text Codex-Official Codex-API ``` 但两个 Profile 中仍然显示同一个 Codex 账号。 这说明： ```text VS Code Profile 只能隔离编辑器设置、扩展列表、UI 状态； 不能可靠隔离 Codex 的认证状态。 ``` ### 2.2 Stable + Insiders 也不是天然隔离 后来我安装了： ```text VS Code Stable VS Code Insiders ``` 但如果不做额外配置，二者仍可能读取同一个默认 Codex 认证目录： ```text C:\Users\<用户名>\.codex ``` 结果就是： ```text Stable 和 Insiders 仍然可能显示同一个 Codex 账号。 ``` ### 2.3 启动脚本中注入代理会引入新的不稳定因素 我为了修复 reconnecting 问题，把代理变量注入 VS Code Insiders 启动脚本： ```powershell HTTP_PROXY=http://127.0.0.1:7897 HTTPS_PROXY=http://127.0.0.1:7897 ALL_PROXY=http://127.0.0.1:7897 ``` 后来出现了大量网络错误： ```text SSL handshake failed ERR_CONNECTION_CLOSED stream disconnected before completion error decoding response body ``` 排查后发现，第三方 API 可以国内直连，因此不应该把代理强行注入到 Insiders 进程中。启动脚本越复杂，后期越难定位问题。 --- ## 3. 最终架构 最终采用的结构是： ```text VS Code Stable / ChatGPT Desktop / 普通 Codex CLI ↓ C:\Users\...\.codex ↓ 官方 ChatGPT 账号 ↓ 官方订阅额度 VS Code Insiders 专用启动器 ↓ CODEX_HOME=C:\Users\...\.codex-insiders-api ↓ 第三方 API Key ↓ 第三方中转站，例如 https://lingsuan.top ``` 核心原则： ```text 官方账号环境和第三方 API 环境必须使用不同的 CODEX_HOME。 ``` --- ## 4. 目录规划 ### 4.1 官方账号目录 ```text C:\Users\...\.codex ``` 用途： ```text 官方 ChatGPT 账号 VS Code Stable ChatGPT Desktop 普通 Codex CLI ``` 这个目录不要动。 ### 4.2 第三方 API 隔离目录 ```text C:\Users\...\.codex-insiders-api ``` 用途： ```text VS Code Insiders 第三方 API 环境 保存 config.toml 和 auth.json ``` ### 4.3 Insiders 独立用户数据目录 ```text C:\Users\...\AppData\Local\VSCode-Insiders-API ``` 用途： ```text 隔离版 VS Code Insiders 的 user-data-dir 隔离 UI 状态、缓存、扩展 globalState ``` ### 4.4 Insiders 独立扩展目录 ```text C:\Users\...\.vscode-insiders-api\extensions ``` 用途： ```text 隔离版 VS Code Insiders 的扩展目录 ``` --- ## 5. Codex 配置文件 ### 5.1 config.toml 文件位置： ```text C:\Users\...\.codex-insiders-api\config.toml ``` 示例配置： ```toml cli_auth_credentials_store = "file" forced_login_method = "api" model_provider = "OpenAI" model = "gpt-5.6-sol" review_model = "gpt-5.6-sol" model_reasoning_effort = "xhigh" disable_response_storage = true network_access = "enabled" windows_wsl_setup_acknowledged = true [model_providers.OpenAI] name = "OpenAI" base_url = "中转站提供网址" wire_api = "responses" requires_openai_auth = true [features] goals = true ``` ### 5.2 关键字段解释 ```toml cli_auth_credentials_store = "file" ``` 表示认证信息保存在当前 `CODEX_HOME` 下的文件中，而不是系统凭据库。 ```toml forced_login_method = "api" ``` 表示这个环境只允许 API Key 登录，避免误用 ChatGPT OAuth 登录。 ```toml model_provider = "OpenAI" ``` 这里的 `OpenAI` 是本地 Provider 名称，不一定代表请求一定发往官方 OpenAI。 ```toml base_url = "中转站提供网址" ``` 表示请求发往第三方中转站。 ```toml wire_api = "responses" ``` 表示使用 Responses API 协议。 ```toml requires_openai_auth = true ``` 表示使用 OpenAI 风格的 Bearer Token，即从 `auth.json` 中读取： ```json { "OPENAI_API_KEY": "..." } ``` --- ## 6. API Key 放在哪里 API Key 不要写进： ```text config.toml 启动脚本 项目代码 README 环境变量 setx ``` 只写在： ```text C:\Users\...\.codex-insiders-api\auth.json ``` 格式： ```json { "OPENAI_API_KEY": "你的第三方 API Key" } ``` --- ## 7. VS Code Insiders 专用启动脚本 文件位置： ```text C:\Users\...\Tools\codex-insiders-api\Start-Codex-Insiders-API.ps1 ``` 脚本内容： ```powershell param( [string]$ProjectPath ) $ErrorActionPreference = "Stop" # 只设置 Codex 隔离目录，不注入代理 $env:CODEX_HOME = "$env:USERPROFILE\.codex-insiders-api" $UserDataDir = "$env:LOCALAPPDATA\VSCode-Insiders-API" $ExtensionsDir = "$env:USERPROFILE\.vscode-insiders-api\extensions" $CandidatePaths = @() $Cmd = Get-Command code-insiders -ErrorAction SilentlyContinue if ($Cmd) { $CandidatePaths += $Cmd.Source } $CandidatePaths += @( "D:\Microsoft VS Code Insiders\Code - Insiders.exe", "$env:LOCALAPPDATA\Programs\Microsoft VS Code Insiders\Code - Insiders.exe", "$env:ProgramFiles\Microsoft VS Code Insiders\Code - Insiders.exe", "${env:ProgramFiles(x86)}\Microsoft VS Code Insiders\Code - Insiders.exe" ) $InsidersExe = $CandidatePaths | Where-Object { $_ -and (Test-Path $_) } | Select-Object -First 1 if (-not $InsidersExe) { throw "未找到 VS Code Insiders 可执行文件。" } $Arguments = @( "--user-data-dir", $UserDataDir, "--extensions-dir", $ExtensionsDir, "--new-window" ) if ($ProjectPath) { if (-not (Test-Path $ProjectPath)) { throw "项目路径不存在：$ProjectPath" } $Arguments += $ProjectPath } Write-Host "Insiders executable: $InsidersExe" Write-Host "" Write-Host "=== Isolated Environment ===" Write-Host "CODEX_HOME = $env:CODEX_HOME" Write-Host "User Data Dir = $UserDataDir" Write-Host "Extensions Dir = $ExtensionsDir" Write-Host "Proxy = disabled" Write-Host "" Start-Process -FilePath $InsidersExe -ArgumentList $Arguments ``` 这个脚本只做三件事： ```text 1. 设置 CODEX_HOME 2. 指定 VS Code user-data-dir 3. 指定 VS Code extensions-dir ``` 不做： ```text HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY setx 注册表修改 ``` --- ## 8. 桌面启动器 文件位置： ```text C:\Users\...\Desktop\Codex Insiders API.cmd ``` 内容： ```bat @echo off powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%USERPROFILE%\Tools\codex-insiders-api\Start-Codex-Insiders-API.ps1" pause ``` 如果想指定项目路径，可以写成： ```bat @echo off powershell.exe -NoProfile -ExecutionPolicy Bypass -File "%USERPROFILE%\Tools\codex-insiders-api\Start-Codex-Insiders-API.ps1" -ProjectPath "C:\Users\...\Desktop\question glm5.2" pause ``` 以后打开第三方 API 版 Insiders，只用这个入口。 不要使用普通的： ```text Visual Studio Code - Insiders.lnk ``` 否则可能不会加载专用 `CODEX_HOME`。 --- ## 9. 验证隔离是否成功 打开隔离版 VS Code Insiders 后，在集成终端执行： ```powershell $env:CODEX_HOME ``` 期望输出： ```text C:\Users\...\.codex-insiders-api ``` 检查代理是否为空： ```powershell $env:HTTP_PROXY $env:HTTPS_PROXY $env:ALL_PROXY ``` 期望为空。 检查配置： ```powershell Get-Content "$env:CODEX_HOME\config.toml" ``` 应看到： ```toml model_provider = "OpenAI" model = "gpt-5.6-sol" review_model = "gpt-5.6-sol" [model_providers.OpenAI] base_url = "https://lingsuan.top" wire_api = "responses" requires_openai_auth = true ``` 不要执行： ```powershell Get-Content "$env:CODEX_HOME\auth.json" ``` 因为里面是 API Key。 只检查是否存在： ```powershell Test-Path "$env:CODEX_HOME\auth.json" ``` --- ## 10. 验证官方环境是否未被影响 打开普通 PowerShell，不要从 Insiders 中打开。 执行： ```powershell $env:CODEX_HOME ``` 期望为空。 这说明普通 Codex CLI 仍然使用默认目录： ```text C:\Users\...\.codex ``` 不要在普通 PowerShell 中执行： ```powershell codex logout ``` 否则可能退出官方账号环境。 --- ## 11. 常见问题排查 ### 11.1 Insiders 仍显示官方账号 原因通常是： ```text 没有通过专用启动器启动 CODEX_HOME 没有生效 ``` 检查： ```powershell $env:CODEX_HOME ``` 必须是： ```text C:\Users\...\.codex-insiders-api ``` ### 11.2 出现 SSL handshake failed 如果看到： ```text SSL handshake failed ERR_CONNECTION_CLOSED ``` 优先检查： ```powershell $env:HTTP_PROXY $env:HTTPS_PROXY $env:ALL_PROXY ``` 如果不为空，说明仍然有代理注入。 最终方案不建议给 Insiders 注入代理，因为第三方 API 可以国内直连。 ### 11.3 出现 stream disconnected / error decoding response body 典型错误： ```text Error running remote compact task: stream disconnected before completion: Transport error: network error error decoding response body ``` 如果启动脚本无代理、`CODEX_HOME` 正确、`config.toml` 正确，那么这通常不是本地配置问题，而是第三方中转站对 Responses API streaming、长上下文、remote compact 场景兼容不稳定。 规避方式： ```text 1. 新建任务窗口，减少上下文长度 2. 不要在一个 Codex 会话里连续塞太多任务 3. 长任务拆成多个小任务 4. 换更稳定的中转站或模型 ``` --- ## 12. 维护原则 ### 12.1 只换 API Key 只改： ```text C:\Users\...\.codex-insiders-api\auth.json ``` 不要动： ```text config.toml 启动脚本 C:\Users\...\.codex ``` ### 12.2 只换模型 只改： ```toml model = "新模型ID" review_model = "新模型ID" ``` ### 12.3 换中转站 才改： ```toml [model_providers.OpenAI] base_url = "新中转站地址" ``` 必要时同步改： ```toml model = "新模型ID" review_model = "新模型ID" ``` --- ## 13. 最终经验总结 ### 13.1 VS Code Profile 不是 Codex 身份隔离边界 Profile 能隔离 UI 和扩展配置，但不能保证隔离 Codex 登录态。 真正可靠的隔离方式是： ```text CODEX_HOME ``` ### 13.2 Stable + Insiders 也不是天然隔离 两个 VS Code 版本可以帮助分离 UI，但如果它们读同一个： ```text C:\Users\...\.codex ``` 那么 Codex 账号仍然可能是同一个。 ### 13.3 启动脚本不要承担过多职责 启动脚本应该只负责： ```text CODEX_HOME user-data-dir extensions-dir ``` 不应该混入： ```text 代理 模型 API Key 业务项目配置 ``` 否则后期非常难排查。 ### 13.4 第三方中转的最大风险是 Streaming 兼容性 短请求能成功，不代表长任务、remote compact、上下文压缩也一定稳定。 如果总是在： ```text remote compact task stream disconnected error decoding response body ``` 阶段失败，优先怀疑中转站对 Responses API streaming 的兼容性。 --- ## 14. 最终推荐结构 ```text 官方环境： C:\Users\...\.codex → ChatGPT 官方账号 → Stable / Desktop / 普通 CLI 第三方 API 环境： C:\Users\...\.codex-insiders-api → 第三方 API Key → VS Code Insiders 专用启动器 启动脚本： 只设置 CODEX_HOME / user-data-dir / extensions-dir config.toml： 管理供应商、模型、base_url、wire_api auth.json： 只保存 API Key ``` 一句话总结： > 在同一台 Windows 电脑上同时使用 Codex 官方账号和第三方 API，真正可维护的方案不是切账号，而是用 `CODEX_HOME` 创建两个互不共享的 Codex 本地身份空间。 希望对大家有所帮助

GitHub 每周精选｜2026 W25

GitHub 上每天都会冒出很多新项目。 大多数我都会看过就忘。 有些看起来很酷，但装完就吃灰。 还有一些，会让我真的想留下来继续折腾。 我想把这些项目记录下来。 不追求“最火”。 只记录那些： 让我真正想装下来试试的东西。 --- ### 1. 人味 skill 项目名：renwei-writing GitHub 仓库地址： https://github.com/orange2ai/renwei-writing **这是继 web-access 之后，我基本上天天会使用的 skill，目前还不到 1k 的 star，暂时算是不温不火的状态** 从这个仓库名称也基本可以猜到这个仓库的作用到底是什么了，没错就是输出的时候更有人味 这里我没有单独去做一个用和不用这个 skill 输出的文本的实验了，因为自从用了这个 skill 之后，就基本没有在创作的时候不用这个 skill 了 如果你是一名创作者的话，这个 skill 大抵会让你爱不释手的 **虽然这个 skill 的效果确实很不错，但对于输出的内容并不能做到真正的全部使用，还是需要人的创作指导的，要不人味依然不会很高** ### 2. andrej-karpathy-skills 项目名：andrej-karpathy-skills GitHub 仓库地址： https://github.com/multica-ai/andrej-karpathy-skills Andrej Karpathy 在 26 年的 1 月发了一条推特，来聊了聊过去几周大量使用Claude编程的一些零散想法，**有 770 万次浏览量**，推特链接如下： https://x.com/karpathy/status/2015883857489522876 这里也简单介绍一下 Andrej Karpathy 的背景 Andrej Karpathy 是 AI 研究者与工程实践者，**OpenAI 创始团队成员之一**，后担任 Tesla Autopilot 视觉方向负责人 --- 在这条推特当中，Andrej Karpathy 聊到了现在 AI 智能体在编码时的一些问题，这里我还是觉得直接放原文会好一些，相信这也是大家在用 AI 智能体编码时多多少少会遇到的一个问题  为了解决上面的问题，就有这个仓库，ndrej-karpathy-skills 做的事情，就是把以上问题压缩成 4 条规则（**以下不是完整的 skill 内容**）： 1. 编码前先思考：不要默默假设，有歧义就说出来 2. 简洁优先：能 50 行解决，就不要写成 200 行 3. 精准修改：只动和当前任务有关的地方，不顺手重构 4. 目标驱动执行：不要只说“修一下”，而是定义可验证的成功标准 优先是很轻，可以直接将这个 skill 安装到 AI Agent 当中，或者直接写进 CLAUDE.md 或者 AGENTS.md 都是可以的，可以一定程度上解决上面的问题 **缺点也是比较明显的，它不是强约束**，它不会像类型系统、测试、lint 那样硬性拦住错误，能减少犯错的概率，但并不能杜绝错误的发生 比如关于 "编码前先思考" 这点，用 superpower 的效果会更好 --- 至于使用人群的话，如果你打算用 AI 认真写代码，那么值得一试，它做了一件很朴素的事情：**AI coding 的下一步，不只是让模型更会写代码，也要让模型少乱写代码**  ### 3. guizang-social-card-skill 项目名：guizang-social-card-skill GitHub 仓库地址： https://github.com/op7418/guizang-social-card-skill 藏师傅的新作品，之前也有推荐过藏师傅的 PPT skill，感兴趣的话可以点击下面的链接去看一下 https://zhuanlan.zhihu.com/p/2040526006285509057 优点有如下几个： 第一：延续上次 guizang-ppt-skill 的两种风格，审美起点更高 不是让你从零调字体、颜色、间距，而是先给你一套有约束的视觉语言。这个约束反而是好事，因为大多数内容图做丑，不是因为自由不够，而是因为自由太多 第二：适合长文拆图 说成大白话就是为文章配图，将一片文章拆成 5 到 9 张小红书卡片，它能从结构、标题、重点句、截图排布这些地方一起处理，不只是做一张封面 第三：修改成本低 最初的产物是单文件 HTML，再用 Playwright 渲染成 PNG。HTML 和 CSS 都能继续改，出问题也能查，不像很多在线设计工具，最后只剩一个不可控的导出结果 当然我也需要说一说局限性，原配的 skill 主要是生成小红书和公众号内容的，这两个平台的图片比例为 3:4 和 21:9，**对于 4:3 和 16:9 比例的支持稍微差一些**，我第一次在生成 16:9 的配图时出现了配图模糊的情况，后续在原配的基础上进行一些改进，顺利的解决了这个问题，这一点有必要告诉大家  ### 4. agent-skills 项目名：agent-skills GitHub 仓库地址： https://github.com/addyosmani/agent-skills 区别于很多 "角色大全" 式的 skill 合集，产品、运营、设计、销售、法务、数据分析都来一点，看起来很全 agent-skills 的重心收得很窄，基本围绕软件开发这条线展开：**从需求澄清、写规格、拆任务，到编码、测试、调试、代码审查、安全、性能、CI/CD、发布、监控和迁移废弃** 所以它更像是把一个资深工程团队的日常习惯拆开，写成 AI coding agent 可以照着执行的工作流 里面不只是“你是一个前端工程师”这种角色设定，还会告诉agent：什么时候该写 spec，什么时候该停下来补测试，什么时候该做安全检查，什么时候该考虑回滚和可观测性等等  ### 5. whisper 项目名：whisper GitHub 仓库地址： https://github.com/openai/whisper 如果单说功能的话，这个仓库的功能是极其简单的： 将视频 / 音频转换成文字稿 而且这个文字稿也不是完美的。**它不会顺手帮你清理语气词，不会自动帮你删除重复表达，对一些专业名词、人名、品牌名的识别也不总是稳定。**你如果拿它的结果直接发出去，往往还是要自己再校对一遍 对于做字幕，没有剪映方便 对于视频会议的转写也没有腾讯会议、飞书会议方便 对于只是偶尔转一段采访或者播客，现在市面上也有很多现成工具能做，比如 TurboScribe、Riverside、VEED、Otter、Notta，中文场景里还有飞书妙记、通义听悟这类产品，很多都比它更省事 --- 那我为什么还想要来推荐这个仓库呢？ 第一点是，**它足够便宜**，准确点说，是几乎没有使用门槛上的持续成本 很多在线转写产品表面上能免费试，但真正想长期用，要么限制分钟数，要么限制文件大小，要么导出字幕和全文稿时开始收费 Whisper 不一样。环境装好、模型下载好之后，它就是一个可以一直放在你电脑上的本地工具。你不用反复算时长，也不用担心哪天平台把免费额度收紧 第二点是，**它是本地可控的** 你的视频、录音、采访、会议材料，不需要上传到第三方网站。这个差别平时不明显，但一旦素材涉及客户、内部沟通、未发布内容、个人隐私，你就会知道“本地处理”这四个字有多值钱。很多产品更方便，但方便的代价就是文件先出去；Whisper 不是。 第三点是，它虽然简单，但它简单得很像一个基座 很多成品工具解决的是“给你一个结果”，Whisper 解决的是“把音频转文字这一步，变成你自己手里的一项能力” 你可以拿它输出 .txt、.srt、.vtt、.json，然后继续接自己的工作流：字幕、归档、摘要、检索、内容拆条、AI 总结，后面怎么接都行 这也是它和剪映、飞书会议、腾讯会议这类工具最大的差异点。那些工具是成品，目标是让普通用户少折腾；Whisper 是底层能力，目标是让你自己决定后面怎么用 它的优点说白了就三个：免费、本地、通用 它的缺点也很明确：不够傻瓜、不够省心、结果不够干净、后处理要靠自己 --- 所以它并不是一个适合所有人的仓库 如果你只是想偶尔给视频加字幕，剪映更合适 如果你主要是开会并且想自动生成纪要，腾讯会议、飞书会议更合适。 如果你不想碰命令行，也不想自己管模型和环境，那各种在线转写网站也更合适 --- 但如果你属于下面这几类人，Whisper 就很值得看一眼： 你经常要处理录音、播客、口播、采访、课程、会议素材； 你在意隐私，不想把文件上传到第三方平台； 你想把“音频转文字”这一步沉淀成一个长期可用的本地能力； 或者你是开发者，后面还想接字幕、摘要、检索、自动化流程 对这些人来说，Whisper 的价值不在于它做得比所有产品都更好，而在于它把最基础、也最关键的一步，稳定地交回到了你自己手里。 如果要给它一句比较准确的定位，我会更愿意这么说： **Whisper 不是最好用的视频转文字产品，但它是很值得拥有的本地转写底座**  --- 最后： 后面肯定还会继续遇到： 让我真正想装下来试试的项目。 这个系列也会继续更新下去。

Codex Plus会员现阶段靠谱的氪金教程

### 写在前面：为什么要氪金 Codex Plus？ 这篇教程适合想和我一样，准备用 Codex 做一些练习项目来强化 **vibe coding** 技能的同学。在 vibe coding 练手的时候，最怕的就是对 token 消耗有焦虑，打断学习的道心。用上官方纯净、无套路的 Codex，才是我认为比较高效的解法。 **核心建议：** 不要总想着蹭免费额度，打个比方氪金648和买一个正版3A游戏的钱花在Codex上,足够你用一段时间搞好几个Vibe Coding项目了，甚至有机会助你找到工作拿到心仪的Offer，这样看这笔自我提升的投资绝对划算。实测也是Codex的额度足够学习Vibe Coding和做一些赋能中小项目用了。  --- ### 注册与验证避坑指南 OpenAI 体系（包含 ChatGPT 和 Codex）对注册的地区有严格限制，这里提供一个目前最稳的接码方案： * **接码建议：** 注册时推荐使用 **Vietnam的 xuni号码**。这是目前实测下来过 ChatGPT 手机验证最方便、成功率最高的途径。 * **虚拟号码网站：** 首选5sim，Vietnam号码一个0.1刀左右，网站上充个10RMB 备用最佳。 ### 费用预算与充值渠道 * **官方费用：** 20 刀 / 月（一般代充高于这个价，低于20刀懂得都懂） * **氪金方式（懒人版）：** 推荐直接在**某宝找靠谱的店铺**协助解决支付问题（如代充或购买正规的虚拟信用卡）。挑选时注意多看评价和店铺信誉，切忌贪小便宜购买低价黑卡，以免导致账号被封禁。店铺一定要承诺保30天使用，对话留据。对方一般会加wx帮你做单子，那头有额外费用的话你就说是以某宝订单为准防一手套路。 * **最佳氪金方案：** 有能力正规银行注册一张可以国际支付的VISA那更稳了，付款认准OpenAI官方。我后续会开一张国际支付能力副卡，专门充AI相关的工具，省得和某宝商家斗智斗勇了。 * **验收方式：** 侧边栏左下角出现剩余用量说明会员成功激活，当然你还需要亲自对话试一轮才能真正完成验收（最好是你vibe coding项目测试各模型真实能力，和免费额度部分作对比，防止一开始拿到降智模型）。  ### 日常使用必备环境 * **网络要求：** **使用时科学上网必备**。 * **注意事项：** 建议使用固定且纯净的节点，不要频繁切换国家和地区，以防触发系统的安全风控。保持网络环境的稳定，才能让你的 vibe coding 体验丝滑无卡顿。最好注册好ChatGPT账号，再去搞氪金plus会员的事。我个人已经成功用了半个月，才来分享这套使用方案的，早知道注册个VISA再搞了。

llm-wiki：把 AI 会话沉淀成可长期复用的本地知识库

> 开源地址：[https://github.com/fengguanghuai/llm-wiki](https://github.com/fengguanghuai/llm-wiki) > 关键词：AI Agent、长期记忆、知识库、Claude Code、Codex CLI、Gemini CLI、Markdown、Python CLI ## 一、为什么需要 llm-wiki 过去一段时间，越来越多开发者开始把 Claude Code、Codex CLI、Gemini CLI 等 AI Agent 融入日常研发流程。它们能帮我们读代码、改代码、排查问题、整理文档，甚至在多仓库、多工具链之间协作。 但实际用久了之后，会遇到一个很明显的问题： > AI 会话很多，真正可复用的经验却很容易散落在历史记录里。 比如： - 某个 adapter 当时为什么这样解析会话文件？ - 某次 sync 输出文件为什么发生覆盖，后来是怎么修复的？ - 某个 CLI 命令的参数和目录约定在哪里说明过？ - 某个项目设计决策能不能被不同 AI Agent 共享？ 如果每次都让 AI 从零开始问、从零开始读、从零开始猜，长期来看会浪费大量上下文成本。 `llm-wiki` 的目标就是解决这个问题：**把多个 AI Agent 的会话记录和人工精选笔记，沉淀成一份本地 Markdown 知识库，让它成为可检索、可维护、可迁移、可长期复用的项目记忆。** ## 二、项目简介 `llm-wiki` 是一个本地 Python CLI 工具，命令名是 `pel`。 它可以把 Claude Code、Codex CLI、Gemini CLI 等工具产生的本地会话记录转换为 Markdown，并按照 `raw/`、`wiki/`、`inbox/`、`concepts/`、`entities/` 等目录约定组织起来。 项目特点很克制： - **本地优先**：知识库就是一堆 Markdown 文件，没有数据库绑定。 - **零第三方运行依赖**：Python 3.11+ 标准库实现，不依赖 Node.js、不强制虚拟环境、不需要额外服务。 - **显式沉淀**：不是黑盒自动总结，而是 `capture → inbox → promote` 的可控流程。 - **多 Agent 共享**：Codex、Claude Code 等可以通过同一个 `SKILL.md` 指向同一个 wiki 根目录。 - **可追溯**：原始会话放在 `raw/`，长期结论放在 `wiki/`，修订写入 `log.md`。 一句话概括： > llm-wiki 不是另一个笔记软件，而是一个面向 AI Agent 时代的本地长期记忆层。  ## 三、它解决的核心问题 ### 1. AI 会话历史难复用 AI Agent 的会话记录往往保存在各自工具目录里，比如： - Claude Code：`~/.claude/projects/*/*.jsonl` - Codex CLI：`~/.codex/sessions/`、`~/.codex/archived_sessions/` - Gemini CLI：`~/.gemini/tmp/` 这些文件对工具自己有用，但对人来说并不适合直接阅读，也不方便跨工具检索。 `llm-wiki sync` 会把它们转换成统一的 Markdown： ```bash pel sync ``` 转换后，会话会进入： ```text raw/sessions/<adapter>/ ``` 比如： ```text raw/sessions/claude_code/ raw/sessions/codex_cli/ raw/sessions/gemini_cli/ ``` 这样原始证据就被保留下来了。 ### 2. 原始记录和长期知识混在一起 会话记录很长，里面有命令输出、工具调用、尝试过程、上下文噪音。它们适合作为证据，但不适合作为最终知识。 所以 `llm-wiki` 把知识库分成两层： ```text raw/ # 原始素材，只读证据层 wiki/ # 长期沉淀，可维护知识层 ``` 你可以先把一条结论捕获到 inbox： ```bash pel capture "Claude Code 子会话输出文件名应优先使用源文件 stem，避免多个 agent-*.jsonl 因父 sessionId 相同而互相覆盖。" ``` 再把它提升到长期页面： ```bash pel inbox pel promote <inbox-note> --to memory ``` 也可以提升到不同类型的知识页： ```bash pel promote <inbox-note> --to concept pel promote <inbox-note> --to entity pel promote <inbox-note> --to project pel promote <inbox-note> --to synthesis ``` 这套流程的好处是：**原始材料保留，长期结论可控。** ### 3. 多个 AI Agent 无法共享记忆 很多人会同时使用多个 AI 工具，比如： - Codex 负责代码修改 - Claude Code 负责复杂阅读和重构 - Gemini CLI 用来辅助分析 如果每个工具都有一套自己的历史和记忆，最终会变成“多个孤岛”。 `llm-wiki` 的设计是：所有 Agent 共享一个中心 wiki。 初始化时可以加上： ```bash python -m pelib.cli init --wiki-root "../LLM-WIKI Vault" --title "My LLM Wiki" --link-agents ``` 它会生成共享 skill，并链接到： ```text ~/.codex/skills/llm-wiki ~/.claude/skills/llm-wiki ``` 这样 Codex 和 Claude Code 看到的是同一份知识库，而不是各自复制一份。 ## 四、目录结构设计 初始化后，wiki 根目录大致如下： ```text <wiki_root>/ ├── CLAUDE.md ├── AGENTS.md ├── raw/ │ └── sessions/ ├── wiki/ │ ├── index.md │ ├── MEMORY.md │ ├── log.md │ ├── inbox/ │ ├── concepts/ │ ├── entities/ │ ├── projects/ │ ├── syntheses/ │ └── playbooks/ ├── site/ └── outputs/queries/ ``` 几个核心目录的定位： | 目录 | 作用 | |---|---| | `raw/` | 原始素材和会话转换结果，尽量只读 | | `wiki/MEMORY.md` | 长期记忆的简短结论 | | `wiki/inbox/` | 临时捕获，等待整理 | | `wiki/concepts/` | 可复用概念，例如“Session Adapter 输出命名策略” | | `wiki/entities/` | 实体页，例如某个系统、工具、模型、项目 | | `wiki/projects/` | 项目专题 | | `wiki/syntheses/` | 综合分析和阶段性总结 | | `wiki/log.md` | 操作与修订日志 | 这个结构有一个很重要的原则： > raw 保留证据，wiki 沉淀判断，log 记录变化。 ## 五、快速开始 ### 1. 克隆项目 ```bash git clone https://github.com/fengguanghuai/llm-wiki.git cd llm-wiki ``` ### 2. 初始化知识库 ```bash python -m pelib.cli init --wiki-root "../LLM-WIKI Vault" --title "My LLM Wiki" ``` 如果希望自动为 Codex / Claude Code 创建共享 skill 链接： ```bash python -m pelib.cli init --wiki-root "../LLM-WIKI Vault" --title "My LLM Wiki" --link-agents ``` 在 Windows 上，如果创建符号链接遇到权限限制，可以先不加 `--link-agents`，后续手动配置或以管理员权限处理链接。 ### 3. 查看状态 ```bash python -m pelib.cli status python -m pelib.cli doctor ``` `status` 用来看当前项目指向哪个 wiki 根目录，`doctor` 用来检查必要文件是否存在。 ### 4. 同步历史会话 先 dry-run： ```bash python -m pelib.cli sync --dry-run ``` 确认没有问题后正式同步： ```bash python -m pelib.cli sync ``` 也可以只同步某个 adapter： ```bash python -m pelib.cli sync --adapter claude_code python -m pelib.cli sync --adapter codex_cli python -m pelib.cli sync --adapter gemini_cli ``` ### 5. 捕获和沉淀结论 ```bash python -m pelib.cli capture "这是一条值得长期复用的工程经验" python -m pelib.cli inbox python -m pelib.cli promote <inbox-note> --to memory ``` ### 6. 检索知识库 ```bash python -m pelib.cli query "adapter 输出冲突" python -m pelib.cli query "capture promote" python -m pelib.cli query "旧知识库迁移" ``` ### 7. 修正知识并留痕 如果你手动修改了某个页面，可以追加一条修订记录： ```bash python -m pelib.cli correct "wiki/MEMORY.md" "修正了某条结论的适用范围" ``` ## 六、命令速查 | 命令 | 说明 | |---|---| | `init` | 初始化配置、wiki 骨架和共享 skill | | `status` | 查看项目配置和 Agent 链接状态 | | `doctor` | 检查 wiki 根目录、AGENTS.md、CLAUDE.md、shared skill | | `write-skill` | 重新渲染共享 SKILL.md | | `link-agents` | 将 shared skill 链接到 Codex / Claude Code | | `sync` | 同步本机 AI 会话到 raw/sessions | | `capture` | 捕获一条待整理结论 | | `inbox` | 查看待整理结论 | | `promote` | 将 inbox 内容提升到长期页面 | | `promote-batch` | 批量提升 inbox 内容 | | `query` | 检索长期知识页 | | `correct` | 记录人工修订日志 | | `adapters` | 查看已注册 adapter | ## 七、适合哪些场景 ### 1. 开源项目的设计决策沉淀 比如一个工具项目会持续出现这类问题： - CLI 命令为什么这样设计 - adapter 如何兼容不同工具的会话格式 - raw 和 wiki 两层目录为什么要分开 - Windows 下符号链接失败时如何处理 - 同步时如何避免重复转换和输出覆盖 - 旧知识库迁移时哪些内容应保留 这些内容很多不会自然出现在 README 里，但它们会影响后续维护和贡献者理解。 `llm-wiki` 适合把这些设计背景沉淀下来，后续让 AI 先查项目记忆，再参与代码修改或文档补充。 ### 2. 多 AI 工具协作 如果你同时用 Codex、Claude Code、Gemini CLI，`llm-wiki` 可以作为它们共享的本地记忆层。 一个 Agent 今天沉淀的知识，另一个 Agent 明天可以读取。 ### 3. 需要本地化和可控性的知识库 相比云端知识库，`llm-wiki` 更适合对本地可控性有要求的场景： - Markdown 文件可直接查看 - Git 可版本管理 - Obsidian 等工具可直接打开 - 不绑定某个 SaaS 平台 - 不依赖数据库迁移 ## 八、设计取舍 `llm-wiki` 没有把目标做成“大而全”的知识管理平台，而是选择了几个很明确的取舍。 ### 1. 不做黑盒记忆 它不会偷偷把所有会话总结成某种不可见的向量库，而是把过程暴露出来： ```text capture → inbox → promote ``` 你知道哪些内容被沉淀了，也可以随时修改。 ### 2. 不绑定数据库 知识库就是 Markdown 文件。 这意味着： - 可以直接 grep - 可以用 Git 做版本管理 - 可以用 Obsidian 打开 - 可以被任意 AI Agent 读取 ### 3. 不追求复杂依赖 项目使用 Python 3.11+ 标准库实现，运行依赖尽量保持为零。 这对本地工具很重要：越少依赖，越容易长期维护。 ## 九、一个项目相关案例 下面用 `llm-wiki` 项目本身举一个例子：在重新同步历史会话时，发现 Claude Code 和 Gemini CLI 的部分会话会输出到同一个 Markdown 文件，导致后写入的内容覆盖先写入的内容。 第一步，同步会话： ```bash pel sync ``` 第二步，把问题和修复结论捕获下来： ```bash pel capture "Session adapter 生成输出路径时，不能只依赖事件里的 sessionId；遇到子会话或同 sessionId 多文件时，应优先使用源文件 stem 保证输出唯一。" ``` 第三步，提升为概念页： ```bash pel inbox pel promote <note> --to concept --title "Session Adapter 输出命名策略" ``` 以后再维护同步逻辑时，就可以： ```bash pel query "输出命名策略" ``` 或者让 AI Agent 先读取 `llm-wiki`，再结合当前 adapter 代码和测试做判断。 这样，一次修复就不只是一次提交，而会变成可复用的项目维护知识。 ## 十、当前版本定位 当前项目更像是一个面向开发者和小团队的本地知识库基础设施，重点解决： - 会话历史归档 - 多 Agent 共享记忆 - 显式知识沉淀 - Markdown 化长期维护 - 本地优先和可迁移 它不是为了替代 Obsidian、语雀、Notion 这类笔记工具，而是更偏向于成为 AI Agent 的“工作记忆底座”。 如果你已经在日常研发里大量使用 AI Agent，那么 `llm-wiki` 可以帮你把这些碎片化会话变成长期资产。 ## 十一、总结 AI Agent 能提升单次任务效率，但真正的长期收益来自知识复用。 `llm-wiki` 做的事情很朴素： - 把会话留下来 - 把结论挑出来 - 把知识组织好 - 让不同 Agent 都能读 - 让历史经验能被下一次任务复用 对于经常使用 AI 辅助研发的人来说，这类本地长期记忆工具会越来越重要。 项目地址： [https://github.com/fengguanghuai/llm-wiki](https://github.com/fengguanghuai/llm-wiki) 欢迎试用、提 issue，也欢迎根据自己的工作流改造。

12款IDEA插件：让开发从“头秃”到“真香”

同样写接口改 SQL，别人六点下班，你熬夜改 bug，差距大多在开发工具。整理自用一年、无鸡肋的 12 款插件，汉化、AI 编码、MyBatis、Nacos、SQL 优化全覆盖，新手老手闭眼装。  今天给大家整理**12款实测封神、装机必备、零鸡肋**的IDEA插件，全是Java后端刚需，装上直接告别重复搬砖、改错漏错、调试抓狂，新手老手通用，看完直接无脑安装！ ------ ## 1. Chinese（中文汉化插件） 新手福音、强迫症必备！ 刚用IDEA的小伙伴，看着满屏英文菜单、设置面板直接头大，找个功能找半天。这款插件一键全局汉化，菜单、设置、弹窗全部变成中文，零基础也能秒懂IDEA所有功能。 不用再百度“IDEA某个功能在哪里”，彻底告别英文盲区，专注写代码就完事！ ## 2. MyBatisX（MyBatis终极神器） 做Java开发不用它，纯属自讨苦吃！ 专门拯救MyBatis开发的神仙插件，支持Mapper接口和XML文件**双向一键跳转**，不用手动翻文件找SQL。还能自动生成CRUD代码、数据库实体类，适配MyBatis-Plus，写数据库代码效率直接翻倍。 杜绝手写重复代码，告别XML和接口对应错乱的低级bug！ ## 3. Lombok（代码减负天花板） 谁不装Lombok，谁就活该多写几百行垃圾代码！ 项目必备刚需插件，一个注解搞定所有模板代码。`@Data`自动生成get/set、toString，`@Slf4j`直接注入日志对象，不用手动创建、不用重复编写。 彻底清空实体类冗余代码，代码整洁度拉满，项目观感直接提升一个档次！ ## 4. Translation（程序员专属翻译官） 告别复制粘贴浏览器翻译！ 开发时遇到英文报错、陌生注释、源码英文文档，选中内容一键秒翻。不用切屏、不用暂停开发，内置多翻译引擎，精准适配代码专业词汇。 再也不用因为看不懂英文报错原地卡壳，新手学习源码、排查bug神器！ ## 5. Apifox（接口开发一站式工具） 彻底告别Postman来回切换！ IDEA内直接搞定接口调试、参数校验、接口文档生成。写完接口直接在当前窗口测试，自动识别项目所有接口，无需手动录入地址参数。 接口开发、联调、文档撰写一步到位，前后端联调效率直接拉满，摸鱼时间又变多了！ ## 6. CCCui（代码颜值治愈插件） 写代码也要有仪式感！ 专治IDEA原生界面单调枯燥，优化代码配色、界面样式、光标效果，让密密麻麻的代码瞬间变得清爽耐看。 长期敲代码眼睛不疲劳，颜值与实用并存，颜值党程序员必装！ ## 7. Qoder CN（国产AI编程助手） 新手编程的“贴身师傅”！ 本土化AI代码助手，适配国内开发场景，支持中文指令。一键生成代码、解释复杂逻辑、优化冗余代码、修复报错bug。 遇到不会写的逻辑、看不懂的旧代码，直接问它，不用到处搜博客、问同事，自学、开发两不误！ ## 8. Qoder（全能AI编码工具） 专业级AI代码辅助，效率开挂神器！ 区别于纯国产版本，功能更全面，支持代码补全、算法生成、单元测试编写、代码重构。编码过程中实时智能提示，预判你的代码逻辑。 减少80%手动编码量，老手提速、新手避坑，适配所有Java开发场景！ ## 9. PawSQL（SQL优化救命神器） 专治SQL卡顿、慢查询、索引垃圾！ 很多项目卡顿、线上超时，全是SQL写得烂！这款插件一键解析SQL执行计划，自动检测慢查询、冗余索引、不合理语句。 智能给出优化方案、索引推荐、SQL重写建议，不用自己死磕EXPLAIN，小白也能写出企业级高性能SQL！ ## 10. GitToolBox（Git摸鱼管理神器） 告别频繁打开Git窗口、命令行敲指令！ 直接在代码行内显示提交人、提交时间、commit备注，一眼就能知道这段代码是谁写的、什么时候改的。支持一键拉取、提交、推送、分支切换。 排查代码问题、追溯版本变更超级方便，团队协作必备，再也不用背锅不明bug！ ## 11. Nacos Configuration（Nacos开发专属） 微服务开发刚需，告别浏览器来回切Nacos控制台！ 支持在IDEA内直接查看、编辑、刷新、发布Nacos配置，多命名空间、多分组自由切换。修改配置无需打开网页，修改后实时生效，适配SpringCloud微服务项目。 微服务开发者必装，省去80%的Nacos操作时间！ ## 12. MyBatisCodeHelperPro（MyBatis增强终极版） MyBatis开发天花板插件，比常规工具更全能！ 支持SQL自动补全、Mapper代码生成、批量增删改查生成、字段映射提示，还能自动校验SQL语法错误，提前规避线上SQL异常。 配合MyBatisX使用，双向加持，彻底解放双手，数据库开发全程躺赢！ ------ ## 最后总结 这12款插件没有任何花架子，**全是Java后端开发刚需、实测好用、装机常驻**！ 涵盖：汉化适配、代码减负、AI辅助、SQL优化、接口调试、微服务配置、团队协作、MyBatis开发全场景。 装上这套插件，告别低效搬砖、减少bug、节省大量摸鱼时间，开发效率直接甩开同行一大截！ 建议直接全部安装，适配所有SpringBoot、微服务、CRUD项目！#IDEA 插件 #Java 后端 #开发工具 #MyBatis #程序员干货 # 效率神器 #SQL 优化 #Nacos #编程技巧 #AI 编程

有了 web-access，Codex 才真正开始 "会上网"

你在用 Codex、Claude Code 等 AI Agent 时，是不是也会遇到这样的情况： **想访问很多网站的信息却无法访问，显示权限有限，比如公众号、知乎、推特、小红书等平台的数据都是无法访问的** 这对于信息收集效率产生了很大的影响，需要花费额外的精力来解决这些事情，比如写爬虫去爬取数据，但一些平台是有很强的反爬虫机制的，花时间写了爬虫，最后的抓取的结果也无法得到保障，这实在是太难受了 那么有没有一个工具可以解决这些问题呢？ 有的，这就是本期要介绍的工具——web-access 仓库地址如下： https://github.com/eze-is/web-access ### 功能 & 安装 这个 skill 可以实现什么功能呢？ **简单来说，你通过 Chrome 可以访问什么内容，那么 AI Agent 通过这个 skill 就能够访问什么内容** 比如上面所访问不到的公众号，B站上的内容，以及需要需要登录访问、付费访问的内容就都可以访问了 安装的话，也是极其的简单，只需要和 Codex 这样说就可以了 ``` 帮我安装这个 skill：https://github.com/eze-is/web-access ``` 支持 Chrome 和 Edge，在你想用的浏览器地址栏打开对应 inspect 页面，然后勾选上 "允许远程调试就可以了"，在设置完毕之后推荐重启一下浏览器 Chrome： ``` chrome://inspect/#remote-debugging ``` Edge： ``` edge://inspect/#remote-debugging ```  之后在调用的时候在 Chrome 会有这样一个弹窗，点击允许就可以正常调用这个 skill 了  在可以正常调用这个 skill 之后，和大家分享一下我的几个使用场景来抛砖引玉哈，我们现在开始 ### 更为广泛的信息搜集 通过 web-access 可以让 Codex 的信息搜集范围得到一个极大的扩展，所以这时如果你有什么想要搜索的信息，又觉得单纯使用大模型的搜索结果不是很理想，那么就可以来试一试 比如我最近在做自己的作品集网站，想找设计感的网站，就直接和这样和 Codex 说即可： ``` 请你调用 web-access 来调研有设计感的网站，最好是贴近于程序员个人作品集的那种，筛选出 20 个给我，以表格的形式输出 ``` **这个提示词只是一个参考，关于 "设计感" 是完全可以更加详细的展开的，限定更清晰的话，检索的结果一般也是越好的** 最终我选择的是这个网站作为主要的参考： https://jackiezhang.co.za/ （这个网站有很多精彩的小交互，从一张图片当中是体现不出来，所以很推荐亲自去访问一下这个网站体验一下）  ### GitHub 仓库快速扫盲 我是一个 「每周 GitHub 精选」系列的，这意味着我需要去体验大量的 GitHub 仓库，经过筛选之后才能将我觉得不错的仓库推荐给大家 在没有这个 skill 之后我，我是需要自己去浏览一个仓库的 README.md 来有一个大致的认知，然后按照 README.md 的指导进行操作的，这样就很花时间 现在我只需要这样和 Codex 说就可以了： ``` 请你调用 web-access 来访问这个仓库，并输出如下的内容： 1.这个仓库的大致功能是什么 2.这个仓鼠属于哪一种类型，是一个 skill、还是一个在线访问的网站、还是一个教程文档，亦或者是一个 CLI、巴拉巴拉（不同的类型我后续会有不同的处理方式，在这里就不展开了，总之就是让达到一个快速扫盲并体验的效果） 3.如果仓库需要安装环境，那么你直接来完成环境的安装 4.跑通这个仓库的最小闭环的步骤是什么 ``` 后续我应该会出一期如何快速扫盲 GitHub 仓库的内容，但目前还是在打磨当中，目前的版本还是很粗糙的 ### 阅读官方文档 作为一名合格的程序员，几乎是一定要和官方文档打交道的，但很多官方文档都是英文的，当然可以通过一些浏览器助手，比如豆包浏览器的豆包来对文档进行翻译，和内容的提问，但效果嘛，我是觉得有些不尽人意的 我的做法依然是会用豆包浏览器的翻译功能，这点我确实觉得做的很好，比使用免费版本的沉浸式翻译插件是要好用的 然后把对应官方文档的网址提供给 Codex，让其作为自己的小助手，是比直接用豆包好上不少的，一方面是因为豆包的幻觉是比较强的，Codex 我用的是 GPT 5.5 的模型，幻觉要低很多； 另一方面，豆包在内容检索上基本就会局限于单一网页的内容，而 Codex 会根据需要检索更多的内容以此来更好的回答问题 如果有小伙伴是做学术方向的，我想是是可以作为参考的 ### 邪修 前面是有提到有了 web-access 之后就可以访问已经付费的网站了嘛，所以如果你需要完成一个项目，且这个项目是有教程的，**最好是文字教程哈**，那么你就可以实现半天就完成简历上的项目板块，至少是在看起来还算是有模有样的 来具体举个例子，这里我们拿编程某航作为例子，**其他的知识付费的平台也都是可以的**，比如某马程序员、尚某谷 我们可以这样和 Codex 说： ``` 请你调用 web-access 来访问这个网站，这个网站是一个项目的文字教程，请你按照这个文字教程来完成这个项目的这一小节，网址：×× ``` 我实测过，一个文字教程当中除了部署上线的部分，其他的基本都可以让 Codex 来直接完成，所以如果时间确实紧张，且需要有项目的话，就可以采用这个邪修法子 更加建议的还是把网址告诉 Codex 之后，在自己做项目的时候遇到不会的内容让其作为辅导 **毕竟单纯的项目有了，但是一个项目到底是怎么做出来的，为什么要这样做，取舍在哪里等等这些内容都是需要自己亲身做过项目才能回答出来的，通过这个邪修的方法并不能提高你的实际能力，所以大家谨慎使用**  以上我自己使用 web-access 的常用场景基本就分享完了，相信肯定还有很多场景是我没有挖掘出来的，如果可以的话，欢迎大家分享一下是如何 web-access 的~ --- 最后： AI 工具很多。 但真正能进入日常工作流、 并且长期留下来的， 其实很少。 这个系列会继续记录： 那些真正进入我工作流的 AI 工具、Skill 与自动化方案。

试用下最近很火的阿里云秒悟

第一感觉：前端写的很漂亮，但是后端真不咋地，而且出错概率很大，稍微复杂一点的逻辑没法一次性实现，bug也不会修  我的提示词：  本意是想一步到位让它帮忙写一个前后端+云数据库的小项目，但是就是跑不通，按钮点击没反应，表单无法提交，让它修改几次就陷入了无限循环 所以我干脆就让它不要调用数据库了，直接使用localstorage来实现数据交互，后端我自己用cursor手搓算了 页面确实写的还可以，就当39块钱买了一个专门写前端的工具了，还是有点贵啊 项目地址：https://vvjwl20drk99.meoo.info/#/ 

MacBook Air 配置咨询 我目前用的是2020款的MacBook Air M1 8G+512 开Codex+IDEA+几十个网页 就会提醒应用程序内存不足，让强制关一些程序 想换一台26年新款的MacBook Air M5 在纠结内存16G还是24G？ 16G够吗？怕16G会出现卡顿，24G有一点点超预算，有经验的小伙伴可以给个建议~😊

微信读书 skill 上手后，我终于不用在书海里乱翻了

你在阅读的时候是否也会遇到这些问题？ - 不知道读什么书 - 想要分析自己的阅读情况，却无从下手 - 读过一些内容，但在想找的时候却找不到 那么最近新出的微信读书 skill 大概率会帮助你，下面我们开始吧 ### 安装和配置 首先微信读书 skill 对应的链接如下： https://weread.qq.com/r/weread-skills 安装很简单直接把 "复制 Skill 安装指令" 的内容给任意一个能给支持 Skill 的 AI Agent 即可，我用的是 Codex ``` npx skills add Tencent/WeChatReading -g ``` 配置的话和 Codex 这样说一下就会去自行安装了 ``` 这是 API Key：××，请自动完成配置和授权 ``` 到这里恭喜你成功的安装和配置好微信读书 skill 了  ### 基础功能 对于基础功能以表格的形式进行呈现，但我觉得这样肯定是不够的，因为这些功能摆在你面前，大抵依然不知道如何解决文章最开始的问题，所以这个表格的意义就是大概了解一下微信读书 skill 支持哪些功能即可，接着我们进入痛点解决的部分  ### 可视化阅读统计 如果你想要把自己的阅读统计做成可视化的版本，那么我会向你推荐这个 GitHub 仓库，地址如下： https://github.com/yaojingang/yao-open-skills/tree/main/skills/yao-weread-skill 最终呈现的内容不只是 "阅读统计"，更加准确的说是一份 "微信读书个人可视化报告"，这份报告的内容比较多，截图是截不过来的，就只展现其中的一个部分了，我大概是 24 年十一月底开始用微信读书的，现在大概 288h，算是一个平均的时长吧  在这份可视化报告当中你可以看到这些内容，内容比较多，依然以表格的形式呈现吧，我个人体感是比微信读书的年度总结更加详细的   ### 能想起来一点但不多 你是不是也遇到过这种情况，之前有读过一些内容，但只有一个模糊的印象，遇到一些事情，想要找到原来看过这部分内容，通过微信读书的基础搜索功能却搜索不到 这种时候，传统的读书方式就会很无力。记忆是散的，笔记是散的，书也是散的，最后只能在一堆信息里反复翻找，越找越确定自己记错了 比如我之前看过一篇克服拖延症的方法，但具体是哪一本、哪一章、哪一句，已经完全想不起来了，只有 "我好像在某本书里看到过解决拖延的方法" 这个模糊的印象，那能不能找到呢？ 答案是大概率可以的，你可以将刚才模糊的想法 Codex，然后通过调用微信读书 skill，来实现范围的缩小，从模糊的关键词变成候选书，再从候选书缩小到章节，最后定位到自己所需要的内容 它并没有让你成为一个过目不忘的人，但确实能让你在已经忘掉大半的情况下，仍然有机会通过一点点残存的记忆找到自己所需要的内容 ### 定制化の阅读 李继刚老师在前天的 「人生周报」当中有分享这样一个 "章节阅读"：  于是我就比较好奇，想要自己去实现一下，其中的难点就在于 "当天所有的对话内容"，所以就有了下面的追问（还打错字了hh...），那这样实现起来就简单很多了，大家感兴趣的话，可以也用这个思路去试一试，大概率会有惊喜╰(*°▽°*)╯呢  --- 最后： AI 工具很多。 但真正能进入日常工作流、 并且长期留下来的， 其实很少。 这个系列会继续记录： 那些最后没有被我删掉的 AI 工具。