好久没在周报里一次性看到四个这么有代表性的项目同时上榜了。2026 年第 35 周的 GitHub 趋势榜被 awesome-gpt-image-2、Archify、Codex CLI、Claude Code 四个项目占了大半屏评论区里问得最多的从「GPT 画图怎么接 API」到「Codex CLI binary 找不到怎么解决」再到「Claude Code 在 VSCode 里怎么配」基本把这一轮 AI 开发者工具的痛点全问了一遍。这篇就把这四个项目逐个拆开讲清楚它们解决什么问题、背后是什么原理、怎么装怎么用最后把搜得最多的报错和坑整理成一份速查表。不管你是刚接触 AI 编程的新人还是已经在用 Agent 写生产的老人这周的内容都值得花十分钟过一遍。1. 榜单速览四个项目背后的一条主线1.1 表面是四个项目实际上是两条赛道这周榜单放在一起看特别有意思。awesome-gpt-image-2 是资源聚合仓库Archify 是工程工具Codex CLI 和 Claude Code 是 AI 编程 Agent。表面上是四个不相关的项目但背后是一个共同的信号AI 能力正在从「网页对话框」往「本地终端」和「工程化流程」迁移。gpt-image-2 登顶说明内容生产侧的 AI 需求已经从「玩一玩」变成「认认真真投入到生产流程里」。大家不再满足于网页里生成一张图而是需要提示词库、API 封装、批量处理、质量评估这一整套配套。awesome-gpt-image-2 这种清单仓库能登顶不是说整理清单的人技术多牛而是说明这个生态已经大到需要有人来做导航了。Archify 的走红则是工程侧的需求爆发。过去画架构图靠人肉维护代码一改图就过期Archify 做的事情简单说就是「让架构图和代码永远对得上」。这个需求在微服务泛滥、AI 生成代码越来越多之后变得异常刚需。1.2 哪类人群这周必须关注内容创作者和设计师awesome-gpt-image-2 能帮你们省去大量试错时间提示词、模型参数、后处理工具一站式找齐。后端开发和架构师Archify 适合用来给老项目做架构梳理也适合在 Code Review 时快速核验改动是否符合既有架构。全栈和 AI 应用开发者Codex CLI 和 Claude Code 都是可以直接进日常开发流的工具配置好之后效率提升非常明显。我自己这一周的实际感受是Codex CLI 和 Claude Code 已经在某种程度上取代了我原来「手动查文档 复制粘贴」的低效循环而 Archify 则在项目交接时帮我省了整整一个下午的口头讲解。下面一个个说。2. awesome-gpt-image-2 登顶一份资源清单凭什么拿第一2.1 仓库里到底收录了什么awesome-gpt-image-2 这个名字的套路大家都熟awesome 系列就是「该领域最全资源导航」的代名词。这个仓库能在一周内冲到趋势榜第一核心原因是 gpt-image-2 这个模型发布之后生态里的碎片信息实在太散了。仓库本身收录的内容大致可以分成五块模型能力与官方文档整理。包括 gpt-image-2 的官方 API 参数、计费方式、尺寸规格、内容审核策略等于把散落在官方文档里的关键信息重新组织了一遍。提示词工程资源。收集了大量经过验证的提示词模板从电商产品图、写实人像到风格化插画分门别类整理好了。社区开源工具和封装库。比如非官方 SDK、批量生成脚本、图像编辑工作流还有跟 ComfyUI 之类的节点集成方案。评测与对比数据。包括 gpt-image-2 和其他主流出图模型在指令遵循、文字渲染、复杂场景等维度的对比。实际案例集。很多开发者把自己跑通的项目案例连同完整代码放进去这部分价值最高相当于免费的教学样本。我觉得这类仓库真正的含金量在第四和第五块。模型文档随时可以看官方但「别人怎么用、踩过什么坑」这种经验性信息是官方文档永远给不了的。2.2 gpt-image-2 的能力边界与参数选择既然榜单主角是这个模型那就多讲几句。作为 gpt-image-1 的下一代gpt-image-2 的提升集中在几个方向上更高分辨率的输出、更稳的文字渲染、更强的多轮编辑能力以及更准确的指令遵循。实际用下来我最常调的三个参数是 size、quality 和 moderation。size 直接决定出图分辨率和 tile 数量如果只是做配图没必要一上来就拉满最大尺寸成本和速度都不划算。quality 对应 low/medium/high 三档我个人的经验是「先 low 出草稿、确认构图后再 high 出成图」这个流程能省不少 token。moderation 参数控制审核强度生产环境建议保留默认的严格档不然出图内容出问题责任是落在自己头上的。这里有一个特别容易踩的坑很多人拿着 gpt-image-1 的代码直接换模型名以为 gpt-image-2 就是无缝升级。实际上两个版本在响应格式上有差异尤其是在图像返回方式上新版默认返回 base64 字符串而不是 URL你原来的「取 url 直接展示」的逻辑就会失效。升级前先花十分钟看一下官方迁移文档能省下半天排查时间。2.3 落地从清单到一条可复用的出图流程仓库里内容再全最终还是要落到自己的生产流程里。我基于这份清单搭过一套最小可用的出图脚本核心流程是这样的import openai import base64 client openai.OpenAI() resp client.images.generate( modelgpt-image-2, prompt电商场景白色背景无线耳机产品图左侧45度角柔和阴影超写实, size1536x1024, qualityhigh, n1, ) # 新版默认返回 base64需要自己解码保存 img_data base64.b64decode(resp.data[0].b64_json) with open(output.png, wb) as f: f.write(img_data)这套流程配合仓库里的提示词案例基本能覆盖大多数内容生产需求。如果你的场景是批量出图建议再加上一层异步队列和失败重试因为高分辨率出图接口的响应时间波动很大同步调用在批处理场景下会非常难受。注意生产环境接 gpt-image-2 一定要把内容审核和输出格式校验写在业务逻辑里不要指望模型自己保证输出合规这是我在踩过坑之后最想提醒的一句。3. Archify架构图可核验是怎么做到的3.1 架构图老过期的病根在哪先聊一个大家都有共鸣的问题为什么架构图几乎永远在过期原因其实很简单。代码是持续演进的而架构图是某个时间点的快照靠人肉去同步这两个东西的成本极高。尤其是微服务架构下服务拆分、接口变动、依赖关系调整每天都在发生架构图更新永远赶不上代码变化。更麻烦的是很多团队的架构图还分散在 Notion、Confluence、飞书文档里格式不统一版本对不上连「哪张是最新的」都说不清楚。这个问题在 AI 编程普及之后变得更严重了。Agent 批量生成代码的速度远快于人工维护文档的速度架构漂移的速度也跟着翻倍。Archify 这周能上趋势榜本质上就是踩中了这个痛点。3.2 Archify 是怎么实现「可核验」的Archify 的核心思路不是「画一张更好看的架构图」而是「让架构图可以从代码里持续生成和核验」。它做的事情分成三步第一步是代码解析。Archify 会扫描整个仓库通过 AST 解析和依赖分析建立起代码实体之间的关系图包括模块、服务、接口调用、数据流、外部依赖等等。第二步是架构图生成。基于解析结果自动生成架构图和架构文档支持常见的图表格式。这一步解决的是「从无到有」的问题老项目哪怕没有任何现成架构文档也能几分钟内生成一版基础架构图。第三步是关键也就是「可核验」。Archify 会持续对比代码实际结构和新生成的架构图一旦发现代码改动导致架构偏离就会标记出具体的 drift比如「某个模块新增了对另一个模块的依赖但文档没更新」。这个机制相当于给架构图加了 CI 检查让架构图从「静态快照」变成了「活的文档」。3.3 实操怎么把 Archify 用进日常开发我自己用得最多的场景有三个。第一个是接手老项目先让它扫一遍生成全局架构图比自己读代码猜结构快多了。第二个是准备架构评审材料把自动生成的架构图作为讨论基础再人工补充业务语义材料质量比纯手绘高不少。第三个是 Code Review 辅助提交 MR 时让 Archify 对比这次改动对架构的影响专门抓那些改了代码但没改文档的 MR。这里还要提一个这周热词里反复出现的 Archify Skill。Archify 官方提供了 Skill 形式的集成可以装进 Claude Code 或者支持 Skill 机制的 Agent 环境里。装完之后你在对话里直接问「当前用户模块依赖了哪些外部服务」「把订单服务的调用链画出来」Agent 会基于 Archify 生成的架构数据来回答而不是靠自己的想象瞎编。这个组合的价值在于它让 AI 编程助手第一次在架构层面有了「记忆」而不是每一次对话都重新猜项目结构。实操心得Archify 对单体老项目的解析效果通常好于超大型微服务仓库因为后者往往会因为依赖过深出现遗漏。遇到超大仓库建议按模块分批次扫描最后再在文档层合并效果比一把梭强很多。4. Codex CLI 本地化把编程 Agent 塞进终端4.1 Codex CLI 到底是什么Codex CLI 是 OpenAI 推出的开源 AI 编程 Agent跑在本地终端里。它跟网页版 ChatGPT 的 Codex 最大的区别在于「本地化」代码库在你本地文件系统上Agent 的执行循环跑在你本地它可以直接读写文件、执行命令、运行测试而不是在云端沙箱里隔着一层操作。这意味着两件事。第一你的代码不需要上传到云端沙箱对很多公司来说这是合规上的硬要求。第二Agent 跟你用的是同一套本地环境它能看到你本地安装的依赖、你配置的环境变量、你本地跑的服务上下文比云端版本完整得多。Codex CLI 提供了两种主要交互模式一种是交互式的对话模式适合边聊边改另一种是 exec 模式适合在 CI 或者脚本里调用直接给任务拿结果。配合沙箱机制它执行命令的权限可以分级控制默认会拦截高危操作需要你手动确认。4.2 安装与登录安装这件事这周被问了无数次其实就两条路任选一条。# 方式一npm 全局安装 npm install -g openai/codex # 方式二Homebrew 安装 brew install codex # 验证安装 codex --version装完之后首次使用需要登录。默认方式是浏览器 OAuth 登录 ChatGPT 账号登录成功后凭证保存在本地配置里。如果你用的是 API Key 计费也可以在初始化配置里填 API Key。配置文件的默认位置是 ~/.codex/config.toml一些高级参数比如模型选择、沙箱级别、审批模式都在这里配置。这里提醒一句无论用哪种方式安装装完之后都要开一个新的终端窗口再执行 codex不然命令行可能拿不到刚写入的 PATH 环境变量。这个坑看起来很小实际遇到的人特别多。4.3 高频报错unable to locate the codex cli binary这周热词里出现频率最高的报错之一就是 ChatGPT 桌面版或者 Codex IDE 里出现的 Unable to locate the Codex CLI binary。这句话的官方完整版本后面还有一句Set CODEX_CLI_PATH or ensure the Electron app has access to it。这个报错的本质是桌面端应用Electron 架构想调用本地安装的 codex 可执行文件但找不到它在哪。原因通常是桌面应用启动时读不到你 shell 里的 PATH 配置尤其是你用 npm 全局安装、而 npm 的全局目录不在系统默认 PATH 里的情况非常常见。解决办法很简单把 codex 可执行文件的绝对路径通过环境变量告诉桌面应用# macOS / Linux export CODEX_CLI_PATH$(which codex) # 确认一下路径存在 echo $CODEX_CLI_PATH # Windows PowerShell $env:CODEX_CLI_PATH (Get-Command codex).Source设置完之后重启桌面应用再试。如果 which codex 找不到路径说明你安装位置比较特殊可以用 npm prefix -g 查出 npm 全局目录再手动拼出完整路径。注意环境变量设置方式不同适用的场景也不同。在终端里 export 只对当前会话生效想让桌面应用稳定识别建议写到 shell 配置文件比如 ~/.zshrc里或者直接配置系统级环境变量否则重启终端之后又白设了。4.4 进阶让 Codex CLI 接入其他模型Codex CLI 之所以受欢迎除了本身好用之外还有一个重要原因是它对第三方模型开放。通过设置环境变量可以让 Codex CLI 的 Agent 框架接入其他大模型比较常见的玩法是接一些开源模型或者本地模型export LLM_API_KEYyour_api_key_here export LLM_MODELyour-model-name codex如果目标模型服务兼容 OpenAI 的接口协议一般只要配置 API Key 和模型名就能跑起来。这个设计思路很好它把「Agent 的执行框架」和「底层模型」解耦了你可以在不改变开发流程的前提下随时切换不同的模型来对比效果。不过要提醒一句Codex CLI 的 Agent 框架里有很多针对具体模型能力做的适配换模型之后工具调用的稳定性、指令遵循的准确度可能会有明显变化。我自己试过的经验是换成非默认模型后执行复杂多步骤任务的成功率会下降简单任务反而没问题。所以我的建议是日常开发用默认模型省钱或者特殊场景再用第三方模型。5. Claude Code 从安装到上手的完整流程5.1 两种安装方式我推荐哪一种Claude Code 是 Anthropic 的命令行编程 Agent这周相关的搜索量同样很大。安装方式主要有两种npm 安装和原生安装脚本。# 方式一npm 全局安装推荐 npm install -g anthropic-ai/claude-code # 方式二官方原生安装脚本 curl -fsSL https://claude.ai/install.sh | bash我自己的习惯是用 npm 安装因为后续升级比较统一直接 npm update 就能搞定。用原生脚本安装的朋友升级通常是执行 claude update 让工具自己更新两条路径都行选一条稳定走下去就好。安装完成后先做两件事运行 claude --version 确认版本然后运行 claude 进入交互界面。第一次进交互界面之前会引导你完成登录。5.2 登录、授权与订阅那些事Claude Code 的登录方式取决于你的付费模式。如果你有 Claude 的 Pro 或 Max 订阅可以直接走 OAuth 登录用订阅额度来计费不需要单独申请 API Key。如果你是走 Anthropic API 计费在环境变量里配置 ANTHROPIC_API_KEY 即可。这周热词里有一个很典型的报错Your organization has disabled Claude subscription access for Claude Code。这个报错的意思是你所在的 Claude 组织在管理后台里关闭了 Claude Code 的订阅访问权限。遇到这个情况个人用户需要联系组织管理员在设置里把 Claude Code 的访问开关打开如果是自己独立账号出现这个问题检查一下账号所属的组织配置。如果急着用可以用 API Key 方式绕过订阅限制但要注意费用是单独按量计费的。另外提醒一句Claude Code 的授权跟机器绑定逻辑比较严格换新电脑需要重新登录一次。有人喜欢把整个用户目录拷到新机器上用结果发现授权失效这是正常的重新走一遍 claude login 就行。5.3 在 VSCode 里配置 Claude Code这周搜「vscode 配置 claude code」的人特别多说明大家已经不满足于纯终端操作了。Claude Code 官方提供了 VSCode 插件安装入口在扩展市场里直接在扩展栏搜 Claude Code for VS Code 就能找到。安装之后通过命令面板执行 Claude: Sign In 完成登录然后就可以在编辑器里直接和 Claude 对话、选择代码让它修改、查看 diff 并应用更改。我个人的体验是插件模式最适合做「局部重构」类任务比如选中一个函数让它优化、让它给当前文件补测试这种场景下上下文直接在编辑器里比切换到终端再描述一遍要自然得多。插件模式的一个常用技巧是在对话中通过 符号引用工作区文件让 Claude 在理解和修改时精确聚焦到指定文件而不是让它自己猜。尤其是大仓库里明确指定文件能显著减少幻觉。5.4 用 CC Switch 接本地模型这周还有一个高频组合是 Claude Code CC Switch Ollama。CC Switch 是一个用来切换 Claude Code 后端模型配置的开源工具通过修改 Claude Code 的环境变量如 ANTHROPIC_BASE_URL 和 ANTHROPIC_AUTH_TOKEN让你在不改 Claude Code 本身的情况下把请求路由到其他兼容接口的模型服务。最常见的玩法是接 Ollama 本地模型。安装 Ollama 并拉取一个模型之后在 CC Switch 里新增一个配置地址填本机的 Ollama 服务地址认证 Token 随便填一个占位符模型名填你本地拉取的模型。切换之后Claude Code 的请求就会发到本地模型上。这样做的最大价值是隐私和成本代码不出本机也不消耗云端 token 费用。想法是好的但实际体验跟云端模型差距还是很明显。我用本地小参数模型跑过实际任务简单代码补全和解释还行复杂一点的架构设计或者多文件改动基本达不到可用标准。建议把本地模型定位成「实验」和「离线兜底」主力开发还是走官方模型。6. Codex CLI 和 Claude Code 到底怎么选6.1 先看一张对比表很多人会纠结 Codex CLI 和 Claude Code 选哪个我的答案是两个都装按场景切换。先看核心差异维度Codex CLIClaude Code出品方OpenAIAnthropic安装方式npm / Homebrewnpm / 原生脚本登录方式ChatGPT 账号 / API KeyClaude 账号 / API Key主要模型GPT 系列模型Claude 系列第三方模型接入环境变量较开放通过 CC Switch / 环境变量沙箱与审批内置沙箱分级审批自带权限确认体系典型强项代码生成、重构、批量脚本长上下文理解、复杂任务规划从能力侧来说Codex CLI 在代码生成和补全类任务上表现强Claude Code 在需要长期理解和多文件协同的任务上更稳。数据只有一边永远是不够的实际开发里往往是混合着用。6.2 我这一周的实际组合工作流分享一个我这周实际在跑的工作流算是把两个工具的组合价值讲具体一点第一步需求拆解用 Claude Code。因为它上下文窗口大适合把 PRD、接口文档、现有代码一次性塞进去梳理出完整的改动清单。第二步具体实现用 Codex CLI。改动清单确定后让 Codex CLI 在本地逐文件实现它能直接读本地环境、跑测试验证也快。第三步架构影响交给 Archify。改动完成后跑一遍 Archify确认这次改动没有破坏既有模块边界和依赖关系。第四步最终 Review 回归 Claude Code。把 diff 和测试结果交给它从整体视角检查遗漏和潜在问题。这个流程不一定适合所有人但思路是通用的让每个工具做它最强的那件事而不是指望一个工具包办所有需求。7. 高频问题与避坑速查7.1 环境变量相关问得最多的还是环境变量问题整理成速查表报错提示原因解决方案Unable to locate the Codex CLI binary桌面应用找不到 codex 可执行文件设置 CODEX_CLI_PATH 为 codex 绝对路径claude: command not foundnpm 全局目录不在 PATH检查 npm prefix -g配置 PATH 后重开终端401 / authentication failed凭证失效或未登录重新执行 codex login / claude loginLLM environment variables not set未配置第三方模型的 Key 和模型名配置 LLM_API_KEY 和 LLM_MODEL环境变量是这些问题里最常见的根因排查顺序建议是先确认命令本身能不能找到再确认凭证是否有效最后才考虑是不是配置写错了。别一上来就重装浪费时间。7.2 订阅与组织策略相关这周出现了很多订阅相关报错除了前面提到的 Claude Code 组织禁用之外还有两类常见情况一类是订阅额度用完了报错会提示 billing 或 limit exceeded这种没有捷径要么等额度刷新要么切 API Key 计费。另一类是组织策略限制比如管理员只允许特定成员使用 Claude Code这种必须找管理员处理个人折腾没用。Codex CLI 这边也类似如果登录的是组织账号而组织管理员关闭了 Codex 功能同样会遇到权限类报错。统一建议是先用个人账号确认工具本身可用排除工具问题后再去排查组织策略这个顺序能省大量时间。7.3 安装失败与网络问题安装失败是另一个高频话题。我遇到的安装失败大多数是环境问题而不是工具本身的问题。排查思路如下第一步确认基础环境正常。node -v 和 npm -v 能正常输出该升级的版本先升级老版本 Node 装新工具经常出各种诡异问题。第二步检查 npm registry 配置。如果之前改过 registry先确认配置是否指向了可用地址必要时可以临时切回官方默认源再试一次。第三步权限问题。Linux 和 macOS 上用 npm 全局安装偶尔会遇到 EACCES 权限报错这是 npm 全局目录权限不足导致的不要直接 sudo 硬扛正确做法是用 nvm 这类版本管理工具把 Node 装到用户目录下从根上解决问题。最后说一个我踩过很多次的坑装完 CLI 工具、配好所有环境变量之后一定要开一个全新的终端窗口再跑。旧终端窗口里的环境变量是旧的PATH 也是旧的看起来配置全对跑起来全错。写在最后这周榜单给我最大的感受是AI 开发工具终于开始务实地卷「工程化」了。资源清单帮你减少信息差架构核验帮你守住代码边界终端 Agent 帮你把想法变成改动而本地化和模型可切换则给了团队更多自主权。最后再分享一个我自己的习惯不管换什么新工具第一周我都会刻意用真实项目去压一遍遇到报错不急着搜答案先自己把排查链路走通。这四个项目我都这么压过事实证明动手踩过的坑比看一百篇教程都管用。祝各位这周玩得开心。