周末照例把 GitHub Trending 从周榜单刷了一遍，这周信息量确实大：awesome-gpt-image-2 在 2026 年第 35 周直接登顶，图像生成生态从“能出图”正式进入“工具链整理期”；Archify 用“可核验架构图”这个概念引起了我的注意，装完实测后觉得它对于团队文档维护是有解法价值的；Codex CLI 继续深耕本地化，越来越像一个标准的终端 AI 工作站；Claude Code 则已经卷到 VSCode 配置、cc-switch 切换、Ollama 本地模型全套齐活了。
这篇文章就按这 4 个方向逐个拆：每个工具是什么、解决什么问题、怎么装怎么用、有哪些我踩过或见过的坑。我尽量只写自己验证过或看到足够多可靠反馈的内容，方便你对照着直接上手。
1. 本周榜首：awesome-gpt-image-2 为什么能登顶
1.1 这份精选列表到底整理了什么
awesome-gpt-image-2 的本质是一个资源聚合仓库，把 GPT Image 2 生态里能直接用、值得研究的项目都做了分类整理。和所有 awesome 系列一样，它不产出代码，而是做地图。但这个地图一上榜就冲到周榜第一，说明大家对“GPT Image 2 出来后我该用什么”这个问题，已经迫切到需要一份标准答案了。
我翻了它的目录结构，主要覆盖了这么几个区域：官方 API 与文档入口、非官方客户端与桌面应用、命令行工具、Web 应用模板、Prompt 示例库、特定行业落地案例（电商、漫画、PPT、UI 设计稿），以及模型微调和评估工具。其中比较有价值的是 Prompt 示例库和行业案例两部分。GPT Image 2 这种模型，很多人上手后发现自己不会用，不是因为模型不行，而是不知道“它能精确渲染文字”“能做局部编辑”“能一次输出多张变体”这些关键能力。示例库就是用来解决这个信息差的。
如果你平时就靠 GitHub Trending 追热点，看到一个 awesome 列表登顶，第一反应不能只是“收藏”，要理解背后的技术语境。GPT Image 2 最核心的升级在三个方向：一是文字渲染精度大幅提升，海报、logo、截图里的文字不再乱码；二是对多指令的理解更稳，可以一句话里同时指定构图、色彩、风格、内容；三是局部重绘能力，这对于设计工作流非常重要。这些能力把 AI 生图从“出个概念图”推进到了“直接进生产流程”，所以才会有一大批工程化工具涌现。
1.2 榜首背后的信号：图像生成进入“工业化”阶段
一个 awesome 类仓库登上周榜第一，我认为至少释放了三个信号。第一，生态规模已经大到一个人或者一个小团队无法追踪全部进展，必须有社区整理的“地图”作为入口；第二，说明这个领域的新用户正在大规模涌入，他们大多是工程师、产品经理、设计师，而非底层研究人员，大家要的是“拿到就用的工具”；第三，也说明 GPT Image 2 生态已经从模型本身扩散到了周边设施，包括计费、合规、缓存、批量生成这些企业级问题。
这对开发者的实际意义在于，想靠“收藏某个 awesome 仓库”来建立技术壁垒已经不够了，更重要的是从列表里筛出真正适合自己的项目，快速跑通一条最小工作流。我自己一般会优先看三个指标：仓库最近一年有没有活跃提交、README 里是否给出明确的适用场景、示例是否丰富。很多项目 star 很高但长期不维护，真到用的时候就会发现 API 已经变了，反而浪费时间。
1.3 怎么高效用这份 awesome 列表
我的建议是不要从头读到尾。你打开 README 之后，先做一道选择题：你是想用现成产品，还是想基于 API 开发？如果你想用现成产品，直接去“客户端与应用”分类里挑 star 最高、截图最完整的项目；如果你想做集成，去“API 与开发工具”分类，看 SDK 和多语言示例。比如接入微信机器人、Slack 机器人、飞书机器人这类场景，社区早就有封装好的模板，不必从零写调用逻辑。
然后要特别注意列表里标注的“Deprecated”或“Archived”条目。GPT Image 2 迭代非常快，很多早期项目在模型版本更新后已经失效，仓库维护者会打上标记。看到这类条目，不要因为它出现位置靠前就觉得它权威，直接跳过就行。最后，交叉检索一下：你在 awesome 列表里看到的某个项目，去 GitHub 上看 issues 数量和最近 commit 时间。如果 issues 堆了几百个且长期无人回复，再亮眼的 README 也要谨慎采用。
2. Archify：架构图从“画”变成“验”
2.1 为什么“可核验”这个特性值得关注
Archify 是本周另一个让我眼前一亮的项目。说白了，它做的事情是：直接分析你的代码仓库，自动生成架构图，并且保证这张图是真实可核验的。传统团队画架构图，用的是手绘、Visio、draw.io，画完那一刻基本就注定了它会慢慢失真。代码每天都在改，图却很难同步更新，半年之后新人照着图去理解系统，大概率会被带偏。Archify 换了个思路，它把“架构图”当作静态分析的产物，而不是人为维护的文档，代码变了，重新生成一次，图就回到真实状态。
这一点单独看好像没什么，但如果你把它和 AI 编程工具放在一起，价值就出来了。Claude Code、Codex CLI 这类 Agent 越来越强，但它们默认没有“项目全局架构”的概念，容易在局部任务里做出违背原有设计的改动。如果先让 Archify 生成一张可核验的架构图，再把图的上下文喂给 Agent，AI 就能在做决策前理解模块边界、依赖方向、核心链路。
“可核验”的底气来自工具底层的静态分析能力。Archify 会扫描项目的 AST、模块依赖、文件目录、导出关系，把这些信息组装成一张“图数据”，而不是一张普通的 PNG 图片。所以你可以对它做结构化查询，比如问“哪些模块依赖了数据库层”“当前最大的循环依赖在哪里”，这在传统架构图工具里是做不到的。从我的使用体验来看，这种“图数据 + 查询”的模式，才是它最值得长期依赖的部分。
2.2 Archify 的两种核心用法
实际使用中，我主要用到两种模式。第一种是完整扫描生成架构图，适合你刚接手一个老项目、或者想在一个大仓库里快速建立全局认知时使用。操作路径一般是：安装 CLI 工具，进入项目根目录，运行对应的 inspect 或 map 命令，工具会自动分析并输出架构图文件。生成之后，你可以用浏览器打开可视化页面，用缩放和点击查看不同模块之间的依赖关系。
第二种是交互式查询，你可以在终端里直接提问，比如“payment 模块的对外依赖有哪些”，Archify 会结合它扫描到的图数据给出答案。这种方式比翻代码高效得多，特别适合在 Code Review 之前快速验证一个改动的波及面。我个人还有个习惯，会把 Archify 的扫描结果放入项目的 docs/architecture 目录，作为“架构基线”提交到仓库里。这样每个开发者在改动之前，都能先看到当前系统长什么样，而不是凭记忆瞎猜。
2.3 把 Archify 当成“Skill”塞给 AI 编程助手
如果你用 Claude Code，可以更进一步。Archify 支持把自身能力封装成一个 Skill，挂载到 Claude Code 的配置目录下。这样你在终端里向 Claude Code 提需求时，它可以自动调用 Archify 去分析代码结构，从而给出更符合项目现状的方案。我从实际使用来看，遇到大规模重构、跨模块改造、接口迁移这类任务时，挂载了 Archify 之后，Agent 给出的方案质量有肉眼可见的提升。
挂载的基本步骤是：先在 Archify 项目里找到它给出的 Skill 配置示例，确认你的 Claude Code 版本支持 Skills 目录，然后把对应的 skill 文件放到.claude/skills/archify/下面。通常还需要在依赖工具的命令行路径配置里指定 Archify 可执行文件的地址。Linux 和 macOS 上比较简单，全局安装后直接写在配置里就行。Windows 用户要注意，路径中的反斜杠要处理好，否则 Agent 调用时会因为转义问题找不到命令。
2.4 在 Trae / IDE 里用 Archify 的注意点
有朋友问我 Archify 怎么用在 Trae 这类 AI IDE 里。我的经验是：不要在插件市场里干等官方插件，直接在 IDE 的终端里用命令行，这才是兼容性最好的方式。你可以把 Archify 生成架构图、查询结果的命令配置成 IDE 自定义任务，或者写进项目的 Makefile / npm scripts 中。这样无论是本地 IDE 还是 CI 环境，都能复用同一套命令。
需要注意的一个坑是，Archify 对 monorepo 的支持目前还是靠仓库根目录的配置文件来识别各个子包。如果项目里存在多个独立应用，最好在根目录统一配置扫描范围，否则默认扫描可能会把你框架自带的代码也纳进来，生成的架构图会非常“脏”。我第一次跑的时候就把 node_modules 之外的一堆配置文件扫进来了，后来在配置里明确排除了构建产物目录和测试目录，图才干净许多。
3. Codex CLI 本地化：把终端变成你的 AI 工作站
3.1 Codex CLI 本地化的含义和场景
Codex CLI 是 OpenAI 推出的终端 AI 编码工具，从 2025 年最开始只能配合官方云端模型使用，到现在已经逐步开放了“本地化”的能力。所谓本地化，核心包含两层：第一层是 CLI 本身在本地运行，代码不会自动上传到某个图形化 Web 环境，只有经过你确认的上下文会发给模型；第二层是模型提供商可以自由配置，你可以接入本地运行的 Ollama、DeepSeek、或者任何兼容 OpenAI API 的服务。这意味着 Codex CLI 不再绑定 OpenAI 账户，你可以只拿它当一个“终端 Agent 框架”来用。
这个变化对两类用户很有价值。一类是隐私敏感型开发者，公司代码不能随便出内网，但又想享受 AI 编码助手带来的效率提升，那就配一个本地模型或者内网模型网关；另一类是多模型用户，今天想用 GPT 来写复杂逻辑，明天想用便宜模型跑批量格式化，切换模型只是改一下配置文件的事情，不需要安装多个工具。
3.2 安装与系统路径配置
安装 Codex CLI 最常规的方式是通过 npm 全局安装。要求 Node.js 版本至少在 18 以上，太老的环境会直接报错。安装命令很简单：
npm install -g @openai/codex codex --versionmacOS 和 Linux 下如果遇到权限问题，通常是在 npm 全局目录没有写权限，加上sudo即可，但我不推荐长期用 sudo 跑 npm，最好把 npm 全局路径调整到当前用户目录下。Windows 上安装之后，如果终端提示找不到 codex 命令，多半是 npm 的全局 bin 目录没有加入 PATH。默认位置一般在%APPDATA%\npm，把它加进系统环境变量后重新打开终端就好了。
安装成功之后，需要先做认证。如果你准备用官方模型：
codex login命令会打开浏览器完成 OAuth 登录。如果你更习惯用 API Key，也可以直接设置环境变量：
export OPENAI_API_KEY=你的key建议把 KEY 的读取写进 shell 配置文件或者 secrets 管理工具，不要硬编码到项目里。Codex CLI 的主要配置文件默认放在~/.codex/config.toml，项目目录下也可以放一个.codex/config.toml做局部覆盖。我习惯在全局配置里写默认模型，在项目配置里覆盖 provider 和温度等参数，这样切换项目连参数都不一样，互不干扰。
3.3 自由接入第三方 LLM
本地化的重头戏是接第三方模型。Codex CLI 的配置模型用 TOML 定义，你可以声明多个 model_provider，然后在 model 字段里用provider/model-name的格式引用。思路大概长这样：
model = "deepseek/deepseek-chat" [model_providers.deepseek] name = "DeepSeek" base_url = "https://api.deepseek.com/v1" env_key = "DEEPSEEK_API_KEY" wire_api = "chat"不同 provider 的字段名以官方文档为准，但核心思路是一样的：base_url 指向兼容 OpenAI 规范的 API 地址，env_key 是该服务的密钥环境变量名，wire_api 指定用 chat 还是 responses 协议。如果你用的是 Ollama 本地模型，base_url 一般是http://localhost:11434/v1，env_key 可以随便填一个占位符，因为本地模型通常不需要鉴权。
这里要特别提醒，不要一上来就在生产环境里把最核心的代码任务交给本地小模型。模型越大或者参数量越足，工具调用的稳定性才好，小模型跑 Codex CLI 的多步骤任务时经常“一步错、步步错”，看起来省了 API 费，实际浪费了大量调试时间。建议拿本地模型做代码格式化、写单元测试、生成 commit message 这类结构化任务，把复杂重构和架构设计留给更强的大模型。
3.4 高频报错排查：unable to locate the codex cli binary
最近论坛上出现频率最高的一个报错是：
unable to locate the codex cli binary. set codex cli path or ensure the element is in your PATH这个报错通常出现在 VSCode 插件或者 ChatGPT 桌面版调用 Codex CLI 的时候，而不是你在终端里手动运行codex的时候。原因也很简单：图形界面程序启动时继承的环境变量，和你终端里看到的环境变量不一定相同。尤其是 macOS 上通过 Finder 启动的应用，不会读取 shell 的.zshrc配置，导致 PATH 里明明有 codex，应用却就是找不到。
排查步骤我给你列一下：
- 先在终端里执行
which codex，确认输出不是空。 - 执行
echo $PATH，看看 npm 全局 bin 目录是否在列表中。 - 重启 VSCode 或桌面版应用，某些程序只在启动时读取一次环境变量。
- 如果还是不行，在插件的设置项里手动指定 codex 可执行文件的绝对路径。
- Windows 用户注意检查
%APPDATA%\npm是否在系统 PATH 中。
还有一个常见场景是 SSH 远程开发。你在本地装好了 Codex CLI，但 VSCode Remote-SSH 连接之后，远程机器上根本没装这个二进制文件，于是报错里会带一句“this remote computer does not have codex cli installed”。这个不是 bug，是你需要在远程机器上也执行一遍安装命令。要是企业内网机器装不了 npm 包，可以考虑把 codex 的二进制作为项目依赖提交到内部制品库里。
3.5 桌面版和 CLI 版怎么选
现在 Codex 有桌面版（带图形界面）和纯 CLI 版两种形态。桌面版的好处是你能看到一个类似 IDE 的操作界面，改动文件时会展示 diff，对不熟悉命令行的人更友好；CLI 版的好处是轻量、可脚本化、适合跑在 CI 或远程服务器上。我自己主力用 CLI，因为日常操作都已经在终端里完成了，再开一个图形界面反而割裂；但当我要做一个涉及十几个文件的大规模重构时，我会打开桌面版，因为它能看到每个文件改前改后的对照，审核起来更放心。这不是取舍题，而是按任务类型选工具的问题。
4. Claude Code：终端里的主力 Agent 与它的全家桶配置
4.1 Claude Code 是什么，适合哪些人用
Claude Code 是 Anthropic 官方的终端 AI 编程 Agent，与 Codex CLI 定位类似，但在社区口碑上更偏向“能真正在大型代码库里持续干活”。它可以在终端里直接读取和编辑多个文件、执行 shell 命令、调用 git 操作、按你给出的目标规划多步任务。相比纯粹的代码补全工具，它更像一个“干活的实习生”：你给它一个明确目标，它会自己去读代码、找线索、做改动、跑测试，然后给你交一份 diff。
适合使用 Claude Code 的人，我认为有三类。第一类是维护老项目的开发者，仓库底层逻辑复杂，需要 Agent 先理解再动手；第二类是写测试和重构任务多的开发者，这类重复性高、上下文切换成本大的工作，Claude Code 的执行效率比我手动做要稳定得多；第三类是想搭“AI 工作流”的人，因为 Claude Code 支持 Skills、支持 subagents、支持外部工具调用，灵活度足够高，能把自己平时的操作习惯沉淀成配置。
4.2 安装与认证
安装 Claude Code 同样走 npm 全局安装。命令是：
npm install -g @anthropic-ai/claude-codeAnthropic 官方现在也提供原生安装脚本，Linux/macOS 上执行：
curl -fsSL https://claude.ai/install.sh | bash安装之后先看版本：
claude --version能正常输出版本号，说明 PATH 没问题。首次运行直接敲claude，它会引导你做登录认证。如果你是订阅用户，可以在浏览器里授权；如果你是 API 用户，则需要设置ANTHROPIC_API_KEY环境变量。这里有个小坑：有些团队会把ANTHROPIC_API_KEY写在项目根目录的.env文件里，但 Claude Code 默认不会自动加载这个文件，除非你手动 source，否则终端里始终读不到 KEY，会导致认证一直失败。
4.3 在 VSCode 里配置 Claude Code
VSCode 用户想用 Claude Code，首先安装官方扩展，然后要确保终端里的claude命令可用。扩展本质上是在调用你本地安装的 CLI，所以如果终端里claude --version都不通，扩展里再怎么设置也没用。另外，如果你是通过 VSCode Remote-SSH 打开远程项目，一定要在远程机器上也安装 Claude Code，不然就会遇到“远程计算机上未安装 codex cli”的同款问题。
配置扩展时，我会把 claude 可执行文件的绝对路径直接写进扩展设置里，避免系统 PATH 在不同环境下不一致。在 VSCode 的命令面板里可以找到相关设置项，填入claude的绝对路径（macOS 可以用which claude查看，Windows 用where claude）。设置完成后，重启 VSCode，在侧边栏打开 Claude Code 面板，就能在图形界面里看到任务进度和文件改动列表。
4.4 cc-switch 与 Ollama：本地切换模型的组合拳
Claude Code 本身默认只连 Anthropic 官方 API，但在实际使用中，很多人会同时拥有多个账号、多个 API Key、甚至希望临时接一个本地模型跑任务。cc-switch 这个社区工具就是为了解决这个痛点出现的。它可以帮你维护多套 Claude Code 配置，需要切换时执行一条命令，它就会把~/.claude下的配置文件替换成你选的另一套，省去了手动修改环境变量和配置文件的麻烦。
如果你想把 Claude Code 接到本地 Ollama 上，思路和 Codex CLI 类似：在配置里增加一个本地模型的 provider，让 Claude Code 通过 OpenAI 兼容接口访问http://localhost:11434/v1。目前 Ollama 上能跑的工具调用模型里，Hermes 系列表现不错，配合 Claude Code 做简单的文件操作和代码生成够用。组合使用 cc-switch 和 Ollama 的典型场景是：把“隐私敏感的小任务”分流到本地模型，把“复杂度高但可以上云的任务”指向官方 API，cc-switch 负责快速切换，Ollama 负责本地兜底。
4.5 使用限额的规则和应对
Claude Code 在重度使用时会触发限额提示，有一种提示我见过很多次，原文类似“Your limits are temporarily boosted. Your weekly Claude Code limit is 50% higher than usual”。这个不是报错，而是好消息：说明你当前的每周配额被临时提升了 50%，Anthropic 会根据当时的服务负载动态调整额度。但如果你频繁看到“limit reached”之类的提示，说明你确实用满了配额。
应对策略我分三层。第一层是优化用法：把大任务拆成小任务，让 Agent 每次都带着明确目标运行，减少无意义的上下文消耗；第二层是配置层：通过 cc-switch 切换到另一个有额度的账号或者 API Key；第三层是降级：把一些不敏感、结构化的任务交给本地 Ollama 模型，把宝贵的云端额度留给真正需要强模型的任务。我自己还会用claude /usage查看当前用量，每周末做一次复盘，看看额度都花在哪些类型的任务上，以此调整下一周的分工。
5. 组合起来看：本周边缘工具的趋势信号
5.1 从“单模型绑定”到“多模型路由”
把 Codex CLI 和 Claude Code 放在一起看，能非常明显地感受到一个趋势：终端 AI 编码工具正在从“某一家模型的专属客户端”变成“多模型路由网关”。Codex CLI 的 model_provider 机制，Claude Code 的 provider 自定义能力，本质上都是在做同一件事：把模型和能力解耦。对你来说，意味着以后切换模型就像切换 npm 源或者 DNS 一样简单，不再被一个厂商绑定。
这种变化对个人开发者和中小企业尤其有利。过去你想在不同模型之间做对比，要同时订阅多家 API，还得在不同工具之间来回切换；现在只要维护好一套 CLI 配置，把多个 provider 声明在里面，随时按任务类型选择模型。我自己的配置文件里现在有四五个 provider，有官方模型、有第三方 API、有本地 Ollama，日常用的最多的是“官方强模型负责架构，三方的便宜模型负责格式化”这种搭配。
5.2 文档、架构与代码的一致性
Archify 的出现，让我明显地感觉到开发者工具正在解决一个很实际的问题：文档和代码的漂移。AI 写代码的能力越强，这个问题就越突出——因为代码生成速度太快，如果没有架构约束，仓库很快会变成一团乱麻。Archify 的可核验架构图，本质上就是在约束“AI 可以自由发挥的边界”。代码只要变了，架构图就能重新生成并指出变化；架构评审时不再依赖某个人“记得住”系统全貌，而是交给工具去核对。
把这个逻辑放到更大的场景里，你会发现文档、架构、代码三者的一致性，正在成为 AI 原生开发模式的基础设施。过去我们靠人肉 Review 来保证一致性，效率低、漏检率高；现在至少架构层面可以自动化核验了，这是非常扎实的一步。接下来如果单元测试覆盖、API 文档生成也能做到类似的自动核验，整个软件工程的“可信度”会上一个大台阶。
5.3 终端工具的本地化与隐私意义
Codex CLI 和 Claude Code 都在强调“本地运行”，这不只是技术偏好，更是隐私与合规层面的必然要求。一个终端工具如果完全依赖云端，那企业代码就等于默认交给了第三方；而本地化之后，你可以自己决定哪些代码发给模型、哪些留在本地。搭配 Ollama 这类本地推理工具，你甚至可以做到完全离线开发。
我建议每个团队在引入这些工具之前，先明确自己的数据边界：哪些项目允许发送给云模型，哪些必须在本地处理？然后基于这个边界设计配置模板，让团队成员默认跑在合规的配置上。工具本身没有立场，但用的人必须有策略。Archify 的本地静态分析、Ollama 的本地推理、Claude Code 和 Codex CLI 的灵活 provider 配置，正好组合出一个兼顾效率与隐私的开发环境。
5.4 生态整理期的入场策略
awesome-gpt-image-2 登顶这件事，结合 Archify、Codex CLI、Claude Code 的热度一起看，我判断 2026 年的 AI 开发者工具已经进入了一个“生态整理期”。新模型还在出，但更值得关注的已经不是模型本身，而是围绕模型长出来的工具链、最佳实践、社区标准。awesome 列表的上榜，本质上是社区在给后来者画地图。
对大多数开发者来说，现在入场成本其实很低。工具免费、文档丰富、社区讨论活跃，你随便挑一个方向深入进去，都能拿到早期红利。但要注意别陷入“工具焦虑”的陷阱：今天装了 Codex CLI，明天试了 Claude Code，后天看看 Archify，结果一个都没深入用。我的建议反而是做减法，挑一个你当前最痛的点，比如“架构看不懂”就用 Archify；“测试写不完”就用 Claude Code；“不想交 API 费”就研究 Codex CLI 接本地模型，把一个工具用熟，再横向扩展。
最后再分享一个我自己的习惯：每周周刊刷完之后，我不会只收藏，而是会挑 1 到 2 个项目实际装一遍，跑一个和自己业务相关的 demo。本周这 4 个项目我都实际用过，最让我感觉“值回时间”的是把 Archify 的架构图集成到 Claude Code 的 Skill 里，老项目的修改效率提升非常明显。工具的组合价值，往往比你单独使用任何一个都要大。希望这篇周刊拆解，能让你少走点弯路。