这周五晚上照例刷了一遍 GitHub TrendingW35 这一期组合挺有意思榜首是 awesome-gpt-image-2 这样的资源清单后面跟着 Archify、Codex CLI、Claude Code 这几个和 AI 开发绑得很紧的工具。单独看是四个项目放一起看就是一条线——大家已经不满足于让 AI生成一个东西而是开始把 AI 当作可管理的工程资产图像生成需要整理过的资源入口架构图要求能被自动核验写代码的智能代理直接跑在本地终端里。这篇文章就把这四件事逐个拆开讲透包括它们解决了什么问题、怎么用起来、以及我实际踩过的坑。适合正在跟 AI 编程工具、AI 图片生成流程打交道或者想在团队里引入架构治理的开发者。文章里凡是涉及具体配置的地方我都尽量给到可以直接复制去改的命令和文件示例。1. 本期榜单为什么又是资源清单类项目屠榜先说榜单位置。W35 这一期Trending 榜的头部呈现出典型的少数大项目长尾结构热度集中在这四个项目身上。按我这周跟踪到的数据大致情况可以这样概括仓库/工具本周热度状态核心能力典型使用者awesome-gpt-image-2趋势榜第一GPT 图像生成资源大全覆盖提示词、模型权重、API 工具链设计师、内容创作者、后端开发者Archify榜内前列架构图生成与一致性核验支持 Skill 接入架构师、后端、DevOpsCodex CLI持续高热OpenAI 的终端编程代理可配置多模型、多环境全栈、脚本自动化爱好者Claude Code持续高热Anthropic 的终端编程代理可对接 Ollama 等本地模型全栈、有本地数据安全需求的团队1.1 本周仓库热度变化速览我按时间线整理了一下这周的趋势发现热度峰值集中在周三到周五。awesome-gpt-image-2 是周中就爬到了第一Archify 则是随着一个架构漂移检测的演示视频被转发周四下午开始冲榜。Codex CLI 和 Claude Code 没有特别大的版本跳跃但一直保持在各自领域的前列属于那种每天都有新用户在搜索安装教程的状态。把热词搜索量摊开来看Codex CLI 相关的unable to locate the codex cli binary、Claude Code 相关的claude code cc switch ollama都是这周搜索量突然涨起来的关键词。说明很多人不是在看热闹而是真的在安装、折腾、报错、找解决方案。1.2 awesome 类仓库持续登顶的底层逻辑很多人会疑惑一个资源清单凭什么能压过一堆真刀真枪写代码的项目我这两年的体感是这类 awesome 仓库登顶的频率越来越高背后其实是信息过载。以 GPT 图像生成为例基础模型就那么两三个但围绕它们的第三方工具、微调权重、提示词工程技巧、一键部署脚本可能已经成百上千。用户真正缺的不是生成能力而是选择能力——面对一堆相似的工具你根本不知道哪个值得花时间试。awesome 清单解决的就是这个问题它先帮你把整块领域地图画出来标出哪些是主干道哪些是死胡同。对新人来说这份地图比任何单个工具都值钱。另外GitHub 的趋势算法对短时间内的 star 增长非常敏感。一个整理得当的 awesome 仓库一旦被推到 HN、Reddit 或者国内技术社区star 会产生很陡的脉冲式增长。相比之下一个常规功能迭代的代码项目很难在三天内获得同等量级的关注。1.3 榜单热度不等于长期价值但我得提醒一句Trending 榜本质是热度快照不是质量评分。上榜首不代表它适合你也不代表它的 API 稳定。我见过不少一周前屠榜的项目一个月后就停止维护了。所以看到这周的榜单我们应该多做一步——先搞清楚它解决的是不是你手头的问题再决定要不要细看。接下来这几个章节我就是按这个思路去拆解每一项的。2. awesome-gpt-image-2AI 图像生成的资源地图长什么样2.1 这份清单到底装了什么awesome-gpt-image-2 能登顶首先因为它分类做得够细。我把它打开通读了一遍里面不是简单堆链接而是按照一个真正要干活的人的使用路径来组织的分类收录内容举例适合谁官方文档与说明API 文档、模型卡、计费说明、限制说明从零开始的开发者提示词案例库人物一致性、商品图、文字海报、漫画分镜等设计师、内容创作者开源模型与权重微调权重、LoRA、量化版算法工程师、本地部署玩家API 与工具链Python/Node SDK、批量生成脚本、一键部署方案后端、自动化工程师产品与落地案例电商图、游戏素材、营销物料的实际用法产品、运营评测与基准文字渲染准确率、人脸一致性、多轮编辑效果采购决策、模型选型它把模型本身和怎么用模型分得很清楚。GPT-image-2 这类模型的难点从来不在能不能生成,而在怎么稳定地生成想要的东西。特别是人物一致性和文字渲染这两道坎卡住了很多人。清单里专门把这两个方向的高质量提示词单独拉出来做案例是在帮用户跳过大量试错成本。2.2 从清单到工作流怎么用它快速产出可发布图片我按照清单里的路径在本地跑通了一条完整的出图工作流整体思路可以复用从提示词案例库挑 3 个和你场景最接近的样本不要自己凭空写。GPT 图像模型的提示词极其依赖细节凭空写的效果远不如改别人的成熟模板。把样本里的主体描述换成你的目标内容。比如商品图模板你只需要替换产品属性、拍摄背景、镜头角度这三块其他结构保持不动。生成时固定一个 seed 值。这对系列化出图特别重要——你想微调某个细节如果没有固定 seed前后两张图的主体可能会完全跑偏让你分不清是提示词的问题还是随机性的问题。生成后做一轮后处理。AI 直接出的图通常都有小瑕疵比如边缘发虚、文字有轻微错位。我的习惯是先用原图做一次 inpainting 修复关键区域再加一倍超分最后才进素材库。把成功的提示词和对应 seed 记下来。只记成功路径不记失败路径过两周再翻出来你会发现这条记录就是最低成本的团队资产。2.3 除了看清单它本身也是一个开源协作样本awesome 清单有意思的地方在于它不只是一份静态文档而是一个持续演化的社区节点。如果你想给它贡献内容流程和给普通代码仓库提 PR 是一样的先 fork然后在对应分类下追加链接最后提交 PR 等待维护者 review。有几个约定需要提前摸清新的链接通常要按字母序插入不能堆在末尾链接必须指向真正可用的项目不能是画饼性质的仓库维护者会要求附上一句话说明为什么值得收录。只放链接不放理由的 PR大概率会被打回。我的经验是在往 awesome 仓库提 PR 之前先跑一遍它的 README 和 CONTRIBUTING 文件这两份东西会把门槛和风格写得很清楚。你花十分钟遵守规则比被反复要求修改省下几个小时。3. Archify把架构图从画给人看变成机器可核验3.1 可核验到底在核验什么Archify 这周能火核心就在可核验这三个字上。传统的架构图工具比如 draw.io、Excalidraw本质是画布——你画了什么就是什么图和真实代码之间没有契约关系。Archify 走的是另一条路。它会把代码库解析成一个结构化的架构模型里面包含组件、依赖、接口这些实体然后让图和模型一一对应。所谓可核验说白了你随时可以运行一次检查它会告诉你代码里的实际依赖关系和你描述/绘制的架构是否一致。常见的检查场景有三类规则校验比如domain 层不能 import infrastructure 层的包这种约束写成规则以后每次改动都能自动跑。漂移检查让README 里描述的架构和代码库当前实际状态做对比输出的差异就是架构漂移的清单。依赖体检循环依赖、扇出过高、入口混乱这类结构性问题本质上是可以自动查的。听上去很像 Java 生态里的 ArchUnit但 Archify 想做的是更加通用、和语言解耦的一套东西。从这周社区传回的消息和仓库 README 来看它对主流语言的支持偏多实际覆盖情况建议以仓库文档为准。3.2 一个在 Trae 里跑通 Archify Skill 的完整例子不少人搜archify 怎么用其实是想在 IDE 里让它跑起来。我在 Trae 里试了一遍流程不算复杂但有几个细节值得记录。首先Archify 提供了 Skill 包可以装进支持 Agent Skill 的工具里使用。在 Trae 里你需要先把 Skill 资源下载到本机然后在会话里让它加载。装好之后我在项目根目录发起了第一次探测让 Agent 先对整个仓库做一次结构扫描生成初步的架构模型然后让它把 README 里声称的分层架构和扫描结果做对比最后把差异部分整理成一份漂移报告。这一步非常直观它会指出controller 层实际上依赖了 repository 的实现类但文档里写的是应该依赖接口。这种话人工审查要翻半天代码才能确认工具几秒钟就给出来了。如果你需要导出架构图Archify 会把模型渲染成一段图描述文本复制到支持图渲染的编辑器里就能看到依赖关系。这个过程本身就是可核验的高光时刻——图是从模型生成的不是手绘的所以它一定和当前检查到的代码真实结构一致。3.3 落地到 CI让架构漂移在合并请求前就被发现单机跑跑没意思真正的价值是把 Archify 接进 CI让每一次 pull request 都自动做一次架构体检。我在 GitHub Actions 里的做法是加一个独立 jobname: arch-check on: pull_request: types: [opened, synchronize] jobs: arch: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Run Archify validation run: | archify validate \ --baseline .arch/baseline.json \ --threshold warn这里有个关键参数是--threshold。架构漂移不可能吞刀切——偶尔的小越界可以接受全量禁止反而会让团队放弃这个工具。我建议把它设置成 warn只把 error 级别的破坏当作拦截条件。连续跑两周之后把 warn 清一遍再考虑收紧阈值。有一点必须说明具体命令名和参数格式会随 Archify 版本变化我这里的示例是本周社区里通用的写法。真正配置时先跑一次archify validate --help确认。4. Codex CLI 本地化安装、配置和那个经典报错4.1 先分清 Codex CLI 和 Codex 桌面版的区别这周的热词里有一条codex 和 codex cli 哪个更好用每次开源项目有 CLI 和桌面版两个形态时都会被反复问。我的答案取决于你要做什么维度Codex CLICodex 桌面版使用界面终端交互图形界面适用场景命令行自动化、脚本集成、习惯终端的用户图形化审查、长会话管理配置位置~/.codex/config.toml独立配置界面可编程性支持非交互式执行适合 CI弱一些资源占用低高如果你是一个重度终端用户或者想把编程代理接进自己写的脚本CLI 是不二之选如果你需要并行管理多个项目的会话状态桌面版会更顺手。两边的核心是同一套 agent 引擎配置文件也有很多共用所以并不存在必须二选一。4.2 本地安装与最小可用配置Codex CLI 的安装入口是 npm 官方包需要本地有 Node.js 18 以上版本npm install -g openai/codex装完先确认命令能跑codex --version然后做登录二选一codex login # 或设置环境变量 export OPENAI_API_KEYsk-...国内用户扫一眼登录页踩坑率很高的点都是 PATH 问题这在下一小节单独说。拿到权限之后在项目目录直接敲codex它就会读当前目录作为工作上下文。个人建议第一次跑之前先把~/.codex/config.toml写清楚最少包含模型选择和默认行为model gpt-5.2-codex model_provider openai temperature 0.2temperature一定要调。默认偏高时agent 写出的代码会显得特别发散经常自作主张加一堆没用的 abstraction。编程任务我一般压在 0.2复杂逻辑 0.1只有让它写测试用例或注释的时候才放到 0.5 以上。4.3 unable to locate the codex cli binary 排查实录这周搜这个词的人特别多完整报错通常长这样ChatGPT failed to start. unable to locate the codex cli binary. set codex cli path or ensure the elec...第一次遇到这个报错时我的第一反应是是不是没装好于是打开终端跑codex --version发现版本正常。这就开始不对劲了终端能找到为什么 GUI 找不到原因藏在环境变量里。桌面应用在 macOS 上从 Finder 启动时继承的 PATH 是/usr/bin:/bin:/usr/sbin:/sbin这种精简集合你的 npm 全局目录根本不在里面。终端里能用是因为 shell 的 rc 文件把~/.npm-global/bin或/opt/homebrew/bin加进了 PATH。排查链路是这样的先在终端确认二进制真实路径which codex我这里是/home/ubuntu/.npm-global/bin/codex。注意如果用了 nvm 或 volta 这类版本管理器路径里会带上版本目录这种路径换版本就会失效不建议写死到 GUI 里。因为报错提示明确说set codex cli path所以最简单的办法是把which codex的完整路径填回 GUI 的自定义 Path 设置里或者设置环境变量CODEX_CLI_PATH。如果你想让整个用户会话都能稳定找到在 macOS 上可以用launchctl setenv PATH $PATH但请注意这只是把当前的 PATH 注入到后续 GUI 启动的进程里不一定对已在运行的应用立即生效改完最好重启对应的桌面应用。Windows 上还有另一个坑。npm 装完的命令在C:\Users\名字\AppData\Roaming\npm\codex.cmd但部分 GUI 查找的是codex.exe对.cmd格式不认。如果你在 Windows 上报这个错优先查一下是不是这个原因必要时改成直接指向原生安装的二进制。4.4 本地用得顺的几个配置技巧Codex CLI 的价值不在会写代码而在能在命令行里被自动化调用。项目记忆用AGENTS.md。这个文件放在项目根目录写清项目结构、构建命令、代码风格agent 每次会话都会读。这其实比任何全局配置文件都重要。非交互执行用codex exec。脚本里可以指定读文件、改代码、跑测试这类任务非常适合接 CI。具体命令参数以codex exec --help为准。注意 sandbox 模式。它通常分为只读、工作区可写、完全访问三档。我第一次跑的时候图省事选了完全访问结果 agent 自作主张去改了一些不该碰的全局配置。后来老老实实从只读开始需要改代码再升级到工作区可写。综合来说本地化的核心是把 agent 的运行边界收敛到一个项目目录内让它的行为可预期、可复现。5. Claude Code 玩出花从官方用法到 CC Switch 接 Ollama5.1 安装与第一次会话的注意事项Claude Code 的安装同样是 npm 官方包npm install -g anthropic-ai/claude-code如果你不想依赖 Node 环境官方也提供了独立安装脚本具体入口见仓库 README托管在内网环境的机器会很实用。装完直接在项目目录执行claude它会先要求登录授权然后扫描当前仓库。第一次会话时有两个容易被忽略的点应该主动建一个CLAUDE.md哪怕只写三行——项目是什么、用什么构建、代码放哪里。早期版本没有这个文件也能跑但你会发现 agent 经常失忆反复问一些你已经讲过的问题。这个文件就是它的长期记忆。大型仓库第一次进入会比较慢因为要建索引。别急着打断等它把文件结构扫完后续响应才能实用。5.2 用 CC Switch 把 Claude Code 接到本地 Ollama这周很多人在搜claude code cc switch ollama这个组合的诉求很简单不想把代码发给第三方 API想把 agent 指向本地模型。CC Switch 是一个开源工具作用是给 Claude Code 切换服务提供商。和我常用的本地模型链路配合步骤如下先装 Ollama把支持工具调用的模型拉下来比如qwen2.5-coder或llama3.1系列ollama pull qwen2.5-coder:32b安装 CC Switch在其中添加一个本地 Ollama providerbase URL 填http://localhost:11434重启 Claude Code用/model命令切换到本地 provider之后会话请求就会发到你的本地模型。这组方案的优势是数据不出机器适合处理不能出内网边界的业务代码。但本地模型的能力天花板明显低于云端模型特别是复杂多文件重构时手感和实时响应都会下降。我的用法是把本地链路留给读代码、写注释、生成测试骨架这类高并发低风险任务真正需要深度重构时不逞强切回官方 API。5.3 限额提示与团队协作的应对姿势这周不少用户遇到了类似your limits are temporarily boosted. your weekly claude code limit is 50% higher than usual的提示。第一次看到这个提示容易慌以为账号出问题了。其实它是在告诉你本周的临时配额已经被提升当前用量在提升后额度里占了多少。不用把它当成警告把它当成仪表盘。我的应对方式是大任务拆小避免一个长会话长时间占着配额不放。善用--resume恢复会话减少重复输入上下文造成的浪费。如果需要更高配额直接用 API key 走付费链路按量计费行为更可控。团队协作时把CLAUDE.md和 skill 纳入仓库版本管理。这样每个成员拿到的上下文一致agent 的行为才不会出现个人风格差异。5.4 VS Code 远程环境的坑另一个高频搜索是此远程计算机上未安装 codex cli或类似提示。这其实是远程开发场景的通病你在本地装了 Claude Code然后通过 VS Code Remote-SSH 连到一台服务器在远程终端里执行claude结果提示找不到命令。原因很直白远程机器上没有装 Node 和 Claude Code。VS Code 的远程插件只是把编辑器界面挪到远端的窗口但 CLI 还是要在远程环境里安装。排查顺序在远程终端确认 Node 版本如果没装先装。在远程环境重跑npm install -g anthropic-ai/claude-code。确认远程的 PATH 包含了 npm 全局目录必要时写成绝对路径。如果你用的 WSL情况类似——在 Windows 那边装的 CLIWSL 里面是完全隔离开的。这个知识点虽然基础但每周搜这个词的人真不少说明最基础的坑往往最普遍。6. 周刊外的顺手动几个让日常开发更顺的组合6.1 Claude Code Archify Skill 的组合用法这周 Archify 提供了可安装到 Claude Code 的 Skill两套工具合在一起是挺完整的体感Claude Code 负责理解和修改代码Archify 负责告诉你改完之后架构是否还立得住。实际操作时我会在重构之前先跑一次 Archify 扫描拿到架构漂移清单然后把这个清单作为上下文交给 Claude Code基于这份漂移报告把 controller 对 repository 实现类的直接依赖改成通过接口调用。这样的任务说明agent 的效率比裸给一句帮我重构一下高出很多因为它的目标从模糊变明确了。6.2 Hexo 博客部署到 GitHub Pages 的正确姿势如果在热词里看到hexo 部署到 github以为是凑热闹那说明你没建过博客。我见过太多人在本机装好 Hexo然后卡在怎么让 GitHub Pages 自动更新这一步。推荐的做法是仓库开一个分支存构建产物用 GitHub Actions 在每次 push 到主分支时自动构建并部署。核心 workflow大致是name: deploy on: push: branches: [main] jobs: build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - uses: actions/setup-nodev4 with: node-version: 20 - run: npm ci - run: npm run build - uses: peaceiris/actions-gh-pagesv4 with: github_token: ${{ secrets.GITHUB_TOKEN }} publish_dir: ./public这里核心的 GITHUB_TOKEN 是 Actions 内置的不需要你去个人设置里生成额外 token省了很多配置功夫。推一次代码几十秒之后博客就更新了。6.3 网页打不开、clone 很慢几个官方侧的绕开思路最后一趴说点这周很多人搜GitHub 上不去git clone 太慢时真正能用的官方思路。如果只是要下载单个文件直接访问https://raw.githubusercontent.com/用户名/仓库/分支/路径/文件名浏览器就能打开不用进网页。如果你需要的只有一个仓库的某个版本用gh命令行工具加浅克隆参数能省掉大量无效传输gh repo clone owner/repo -- --depth 1公开仓库的 raw 文件也可以经由 jsDelivr 这类公开 CDN 访问规则是https://cdn.jsdelivr.net/gh/用户名/仓库分支/路径/文件这个对静态资源的稳定加载很有效。如果你所在网络环境下普通 SSH 的 22 端口不稳定GitHub 官方支持走 443 端口的 SSH。在~/.ssh/config里加这一段就能生效Host github.com HostName ssh.github.com Port 443 User git想要一瞬间打开一个仓库而不是漫长的 clone可以直接用 GitHub Codespaces 在浏览器里启动云开发环境这也是官方能力。以上这些都属于 GitHub 出品的正常用法单纯在网络波动、命令行操作受限时帮你换个姿势把事做完。按我的经验从这里面挑一两种固定下来比临时搜各种七拐八拐的办法省心得多。最后再说一个小细节这周我把 Codex 和 Claude Code 的配置文件都整理进了自己的 dotfiles 仓库换新机器时十分钟就能恢复环境。这个经验我觉得比记任何教程都管用——工具再多能让你稳定复现的配置才算数。