又到周五Github周刊2026W35正式出炉。本周榜单看点非常集中awesome-gpt-image-2 直接冲上榜首Archify 靠“架构图可核验”这个点引起了不少架构师讨论Codex CLI 和 Claude Code 则继续霸占检索热词榜。整周翻完 Trending、几个技术 newsletter 和国内外讨论串我最大的感受是大家不再满足于“能用”而是开始追问“怎么用好、怎么接入自己的工作流”。这篇周刊总结我就按这个思路来写——不只报菜名尽量把每个项目背后的使用场景、安装坑和实操路径都讲清楚方便你直接拿去参考。1. 本周榜单里的几个硬信号1.1 榜首为什么是 awesome-gpt-image-2本周 GitHub Trending 的榜首被 awesome-gpt-image-2 拿走这个项目听起来像是一个普通的 awesome 列表但仔细看内容会发现它踩中的是当下最热的一个需求GPT Image 2 出来后大家手里有工具但不会用。我在项目仓库里翻了一圈它主要收录的是提示词模板、风格化示例、参数组合技巧、常见失败案例这几类内容。跟早期那些只放几张生成效果图的“作品集”不同这个项目把每个示例的完整提示词、模型设置、后处理方式都贴了出来等于直接把作业摆在你面前你只要照着改关键词就能做出接近的效果。为什么它会在这周登顶我分析有两个原因。第一GPT Image 2 的文本渲染能力和指令跟随能力提升非常明显很多设计师第一次感受到“用图片模型做排版物料”是可行的因此迫切需要一套系统性的用法总结。第二这个项目把零散在 Twitter、Reddit、B 站上的玩法做了归档形成了一个“查字典式”的资源库对新手非常友好。所以它上榜不是因为技术难度高而是因为信息密度高、开箱即用。在工具爆发期整理本身就有巨大的价值这是本周最能反映社区风向的信号。1.2 CLI 工具集体回潮另一个明显的信号是Codex CLI、Claude Code 这两个终端编程工具在热搜词里占据了大量位置。可能有人觉得 CLI 不是早就有了吗怎么现在又火一遍实际原因是这段时间桌面端产品在推进过程中遇到了不少限制而 CLI 版本把 AI 编码助手的核心能力拉回到了本地终端配合 Git、编辑器、第三方模型接入自由度比桌面版高出一大截。从热搜词里也能看出大家在搜什么“codex cli和桌面版对比”“codex cli接入llm”“claude code安装教程”“vscode配置claude code”“claude code cc switch ollama”。这已经不仅仅是“怎么装”的问题而是怎么把 CLI 工具变成日常开发的一部分。我会在第四、第五部分专门拆解这两条线。1.3 架构工具开始“左移”Archify 第三次出现在周刊相关的热词里而且这周伴随的关键词是“架构图可核验”“archify怎么用”“archify怎么用在trae”。我理解它的核心卖点是架构图不再是画完就过期的 PPT 插图而是可以被代码仓库反推、校验、持续更新的一等公民。过去我们画架构图靠的是 Visio、draw.io、PlantUML画完就扔进文档库等代码重构三四轮之后图跟实际系统已经完全对不上号。Archify 这类工具想解决的就是这个从代码里提取真实的模块关系、接口调用、数据流再跟你画的架构图做 diff告诉你哪里不一致。这个思路不能说多新奇但做成产品并出现在 Trending 上说明市场已经开始认可“架构治理”这个方向。第三部分我会展开讲它到底能干什么、不能干什么。2. awesome-gpt-image-2一个能直接“抄作业”的图片提示词库2.1 它到底收录了什么先帮没点进去的朋友省流。这个仓库的结构大致分几块基础提示词语法讲解 GPT Image 2 的提示词结构包括主体描述、风格修饰、画幅比例、细节强化等每一段都配了对比图。风格库按场景分类比如产品摄影、UI 设计稿、像素风、3D 渲染、水墨风、赛博朋克每种风格都有 2-3 组可直接复制的完整提示词。文本渲染专题专门讲怎么让模型生成准确的中英文字比如如何用引号包裹文字、如何指定字体风格、如何避免拼写错乱。错误案例与修正这是我觉得最有价值的部分。作者把自己翻车的情况比如文字重复、手指变形、物体数量不对连同当时用的提示词和调整后的提示词都放在一起读者能直观看到“改了什么参数之后效果变了”。它的定位更像一本实践手册而不是单纯的资源导航。我建议你把仓库克隆下来按风格库一个个试试完再回来看错误案例这样最容易建立起对模型能力的直觉。2.2 几个值得玩的提示词套路我实际跑了一轮挑几个效果最稳、实用性最强的套路分享。第一是**“贴纸风格 精准文字”**。思路是在提示词里明确写出“sticker design, white border, bold text overlay”然后把你想要文字放到最后并用双引号包起来。这个组合适合做表情包、社媒配图成功率在我的测试里接近八成。第二是**“三视图产品图”**。提示词里写明“three views: front, side, back, white background, studio lighting”GPT Image 2 对空间关系的理解比前代好很多能直接生成像样的产品展示图。如果你做电商或硬件项目这个套路能省掉不少渲染时间。第三是**“文本排版模拟”**。比如你想快速预览一个海报标题可以把版式描述写详细指定“left-aligned, large serif font, minimal composition, lots of negative space”。它生成的图虽然不能当最终工程文件用但当作灵感板完全够格。需要注意的是这些套路不是百分之百稳定同一组提示词换一次 seed 效果可能差异很大。我的经验是先固定主体描述再调风格词最后再改细节词一次只改一个变量不然很难定位是哪个词影响了结果。2.3 二度融合图片模型与多模态工作流这个仓库还有一个隐藏价值它的大量示例默认你不只使用单一图片模型。比如有一些 workflow 会用 GPT Image 2 生成基础图然后拖进其他工具做局部重绘、放大、抠图再回到编辑器里做排版。我自己比较常用的流程是先用 awesome-gpt-image-2 里的风格模板生成一张底图转成 base64 喂给多模态模型分析构图再根据建议微调提示词重新生成。这听起来有点绕但实际比手动一遍遍试提示词高效很多。原因在于多模态模型能“看见”图片它会告诉你“左上角太空、主体太靠下、文字对比度不够”你把这些反馈翻译成修改指令再回到图片模型里迭代方向感会强很多。如果你已经玩腻了单张生成可以试试这个组合玩法。它才是这个仓库登顶背后真正代表的工作流趋势。3. Archify架构图从“画出来”变成“验一遍”3.1 “可核验”到底是什么意思Archify 如果只看官方介绍很容易被绕晕。我用自己的话翻译一下它把你的架构图变成一个“可运行的测试用例”。传统架构图的用法是“画给人看”Archify 的理想用法是“画给机器检查”。它会从你的代码仓库里提取实际的模块依赖关系、服务调用关系、数据流向然后与你画的架构图做对比。如果代码里已经不存在某个模块或者新增了图上没有的服务Archify 就会在对应节点上打上不一致标记。这样带来的直接价值是架构评审不再靠嘴争。以前讨论“这里到底是不是单点”“这个模块该不该拆”各说各话现在直接看 diff代码跟图不一致的地方就是风险点。实际使用时它的工作流一般是初始化项目 - 扫描仓库 - 生成当前实际架构图谱 - 导入你画的架构图 - 输出差异报告。对于几十个服务的微服务项目这个能力尤其有用因为人脑根本记不住所有服务间的真实调用关系更不用说在评审时同步更新文档。3.2 在 Trae 和编辑器里怎么用热搜词里很多人问“archify怎么用在trae”说明不少用户是在 AI 编程工具里接触到它的。我看了下目前社区的用法比较主流的接入方式有三种作为独立 CLI 使用在项目根目录执行扫描命令生成报告文件再把报告贴给 AI 助手或者写进 PR Description。这种方式最通用不需要依赖特定编辑器。通过 Skill 机制接入 TraeTrae 支持把外部工具封装成 skill让 AI 在你提问时自动调用 Archify 的扫描命令。你需要写好 skill 配置把命令、参数、输出格式描述清楚剩下的就交给 AI 编排。通过 MCP 服务接入如果 Archify 提供了 Model Context Protocol 服务可以在支持 MCP 的编辑器里直接调用让 AI 在对话框里实时获取架构差异。我的建议是先别急着上 skill 或 MCP先用 CLI 手动跑几次熟悉它输出的数据结构和误报概率再决定要不要自动化。工具一旦自动化误报会被放大容易让你对结果失去信任。3.3 适合什么团队不适合什么团队说得更直白一点Archify 适合的是有明确模块边界、做了接口规范约束、代码规模已经大到人脑无法维护架构文档的团队。在这些场景里它能成为架构治理的守门人每次 MR 跑一遍比 Code Review 时肉眼检查靠谱得多。反过来说如果你的项目还在快速原型期模块边界一天一变架构文档本身就没有保持更新的意义那引入 Archify 纯属给自己找麻烦。另外如果你的代码仓库没有清晰的模块结构、依赖关系混乱扫描出来的实际架构图会非常吓人但这不是工具的问题而是项目现状的如实反映。我个人判断是Archify 这类“可核验架构”会成为未来架构治理的基础设施之一。它真正改变的不是画图方式而是架构评审的论证方式。4. Codex CLI本地化 Agent 的实操路径和那个常见报错4.1 CLI 与桌面版的差异最近“codex cli和桌面版对比”这个热搜词涨得很快我结合自己的使用经验聊一下两者的差别。桌面版提供的是图形界面适合展示会话上下文、可视化 diff、逐步确认修改CLI 版则把能力封装成终端命令适合在脚本里调用、配合 Git hooks、嵌入编辑器终端。我日常更倾向于用 CLI 版原因是它更容易被“编程化”。比如我可以写一个脚本循环处理多个仓库的 issue或者把 Codex 的输出接到 CI 流程里做自动化修复建议。这些在桌面版里很难做到。而且 CLI 版可以直接从 stdin 读入内容、往 stdout 输出结果跟其他 shell 工具的组合能力非常强。需要提醒的是CLI 定位和桌面端不是互相替代而是互补。桌面版适合你坐在电脑前一步步交互CLI 版适合把它当作一个可编程的编码助手嵌进工具链。4.2 接入第三方 LLM 的方法很多想要尝试 Codex CLI 的用户并不想绑定单一模型供应商这时候就涉及“接入 LLM”的需求。搜索热度里大量出现“codex cli 接入llm”和“deepseek hermes github”这类词实际上就是大家在找怎么配置自定义模型端点。根据社区目前的做法Codex CLI 通常支持通过配置文件指定 OpenAI 兼容接口。你可以在配置里声明base_url、api_key、model等字段然后把它们指向本地或云端的 OpenAI 兼容服务。比如你本地跑了一个支持 OpenAI 协议的服务地址是http://localhost:11434/v1就可以把 base_url 指向这个地址。我试过接入不同模型后的效果差异模型能力直接决定了 Codex 的代码修改质量。如果你只是测试流程用轻量模型没问题但如果是正经写功能、改重构建议还是接能力强的模型否则代码审查成本反而更高。另外不同模型对 tool calling 的支持程度不一样如果 Codex 里的函数调用频繁出错优先检查你接入的模型是否完整支持 OpenAI 工具调用协议。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...还有一条类似的“unable to locate the codex cli binary. set codex cli path or ensure the eletron…”。我一看就知道这是 ChatGPT 桌面端在启动时找不到 Codex CLI 二进制文件导致的。这个问题的本质是桌面端把 Codex CLI 作为一个外部依赖来调用如果你从来没有单独安装过 CLI或者安装了但路径不在系统 PATH 里桌面端就启动不了 Codex 功能。排查链路我建议按下面几步走先确认 CLI 是否安装在终端里执行codex --version。如果提示命令不存在先去安装 CLI 本体比如通过官方安装脚本或包管理器。确认安装路径如果安装了还是报同样的错执行which codex或where codex看返回的路径。桌面端往往需要知道这个具体路径。在桌面端设置里指定路径报错信息已经提示了你可以在 ChatGPT 桌面端的设置项里找到类似Codex CLI Path的选项把上一步找到的二进制绝对路径填进去。重启桌面端改完设置后完全退出应用再启动不要只关窗口因为进程可能还在后台缓存旧配置。检查权限问题如果你用的是 macOS注意终端应用是否有完整磁盘访问权限个别路径读取失败也会导致“unable to locate”的假象。如果按这个链路走完还没解决再考虑是不是环境变量加载问题比如你配置 PATH 的文件是~/.zshrc但桌面端是以 GUI 应用启动的未必会加载 shell 的环境变量。这时最省事的做法就是直接在桌面端设置里把绝对路径写死绕开 PATH 解析。5. Claude Code从安装、VSCode 联调到限流提示5.1 安装与基础配置Claude Code 的安装流程这周搜索量非常大很多人在问“claude code安装”“claude code下载”。我在这里把常见路径完整捋一遍。安装本身不复杂官方提供了 npm 包和原生安装两种方式。如果你本机有 Node.js 环境直接在终端执行安装命令装完后运行claude进行初始化。初始化过程中它会要求你登录账号、选择默认模型、确认使用协议。很多人卡在安装后无法运行常见原因有三个Node.js 版本太低、终端没有重启导致 PATH 未刷新、公司网络把安装源挡住了。前两个好解决第三个的话可以尝试切换到国内 npm 镜像源再安装很多排查帖验证过这种方法有效。基础配置层面我建议你重点做三件事在项目根目录建好配置文件把permissions里的操作白名单控制好避免 Claude 在执行文件读写时频繁弹确认框。设置好allowedTools只开放你信任的命令比如Read、Edit、Grep、Bash中的只读命令需要执行写入或删除命令时再手动放行。如果需要走公司内部的模型网关在环境变量里配置 API endpoint 和密钥不要写死在 shell history 里。配置完成之后建议先在一个小仓库里跑一遍“修一个 bug 写一个测试”的完整流程确认 Claude 能正确读文件、修改代码、执行测试命令再放到真实项目里使用。直接上大项目的话上下文和权限问题会让你怀疑人生。5.2 CC Switch Ollama 本地模型组合这次热搜里有一组特别有意思的词“claude code cc switch ollama”。这其实是社区玩家在折腾“把 Claude Code 的模型后端切换成本地模型”的玩法。CC Switch 是一个切换 Claude Code 配置的工具它可以在不同模型供应商配置之间快速切换Ollama 则负责在本地跑开源模型。这套组合的典型用法是日常轻量任务切到 Ollama 本地模型不消耗 API 额度复杂任务再切回官方 Claude 模型保证能力上限。切换之后你的开发环境和交互逻辑不变变的只是底层模型。我实际验证下来的体验是本地模型在代码编辑、单元测试生成这类任务上表现还不错但在复杂多文件重构、深层 bug 定位上跟官方模型差距仍然明显。所以这套组合更适合作为“省流方案”而不是完全替代。另外要注意本地模型的上下文窗口通常较小大仓库的代码塞进去很快会撑爆需要你自己做好上下文裁剪。配置时有个小坑CC Switch 切换后Claude Code 可能不会立刻读取新配置。建议在切换后重启终端会话或者手动清掉缓存目录里的旧会话否则你以为是本地模型在跑实际上还在走旧的 API 配置。5.3 本周高频报错与限流提示这周很多人在讨论一条限流提示“your limits are temporarily boosted. your weekly claude code limit is 50% hi...”。这条提示的准确含义是你的账户本周用量限额被临时提升过但提示显示的可能是当前用量已经达到本周额度的 50%。遇到这种提示不要慌它不一定是报错只是通知你额度快用完了。常见的处理方式有三种暂停重活把大批量的代码重构、批量文件修改任务拆散到下周再跑避免单周额度耗尽。切换到本地模型如果配置好了 CC Switch Ollama可以直接切到本地模型继续轻度任务把官方额度留给关键时刻。降低单次任务规模把大任务拆成多个小对话每个对话的任务颗粒度变小整体消耗反而更低因为上下文被更高效地利用。另外如果你在 VSCode 里用 Claude Code 插件时遇到连接问题先检查是不是扩展版本和 CLI 版本不匹配。我就踩过这个坑VSCode 扩展更新之后CLI 还是旧版结果插件一直报失败把 CLI 升级到同一版本后才正常。6. 国内开发者绕不开的 GitHub 访问问题6.1 访问慢与打不开的实际原因这周热搜词里“github打不开”“github官网进不去”“github下载速度太慢”占了很大篇幅。这几乎是国内开发者绕不开的问题。很多人以为是网络环境的问题但实际上更多是 CDN 调度、DNS 解析、特定地区出口线路不稳定导致的。这类问题并不存在什么一劳永逸的“魔法”解决方案只能通过合理的工具组合降低影响。我在周刊里专门把这个问题列出来是因为它直接影响前面所有工具的使用体验。像 codex CLI、Claude Code、awesome-gpt-image-2 这类项目安装和更新都依赖 clone 或下载 release 文件如果 GitHub 访问不畅整个工作流都会卡在第一步。6.2 镜像站和下载加速服务怎么选目前社区常用的提速手段主要是镜像站和下载加速服务它们解决的是不同层面的问题。镜像站适合浏览代码、阅读文档、小规模克隆公开仓库。你只需要把github.com域名替换为镜像地址大部分操作体验差别不大。但镜像站通常同步不及时冷门仓库可能会缺失而且不要在上面登录账号、提交代码隐私和安全风险不可控。下载加速服务适合拉取 release 大文件比如打包好的 CLI 二进制、模型文件。这类服务常见的有 ghproxy 这种开源中转方案以及各类静态加速 CDN。它们的基本原理是帮你从 GitHub 官方地址拉取文件后再通过更快的线路转交给你。使用时直接把 release 下载链接拼到加速服务后面就行。我自己的选择建议是浏览仓库和发 PR用官方源为主偶尔通过镜像看代码。克隆较大仓库优先用git clone加单分支、浅克隆参数减少传输量。下载 release 文件使用加速服务把releases/download链接替换成加速地址。频繁同步仓库在 Gitee 等国内代码托管平台建一个镜像仓库利用平台自身的同步功能定时拉取更新。6.3 通过 Git 配置改善下载体验的小技巧除了镜像站和加速服务还可以通过调整 Git 本身的配置来降低下载失败的概率。下面几个配置是社区里被反复验证过有效的# 浅克隆最新一次提交适合只读代码的情况 git clone --depth 1 https://github.com/user/repo.git # 如果后续需要补全历史再执行 git fetch --unshallow # 调整压缩与缓存参数 git config --global core.compression 9 git config --global http.postBuffer 524288000这些参数的作用分别是浅克隆减少历史提交传输量压缩率提高降低网络传输压力postBuffer 增大避免大文件提交时出现“RPC failed”错误。还有一个很多人忽略的点不要在克隆过程中频繁 CtrlC。Git 本身有断点续传的能力如果你中途打断留下的.git目录数据不完整下次继续时会比从头开始更慢。正确做法是让它跑完或者一开始就用浅克隆减少耗时。另外一个跟速度无关但影响体验的点如果你只是偶尔看一下某个文件不用git clone直接使用 GitHub 的 raw 文件域名或者镜像站的 raw 加速链接速度会快很多。很多 CLI 安装脚本都支持通过 raw 链接直接执行不必把整个仓库拉到本地。这一周的周刊项目看起来花团锦簇但拆解开无非是三条线图片生成进入“系统化用法整理”阶段、AI 编程工具进入“本地化配置与实践”阶段、架构治理开始拥抱“可验证”思路。awesome-gpt-image-2 的价值在于让你从别人的实践中快速起飞Codex CLI 和 Claude Code 的价值在于把 AI 编程助手真正嵌进你的终端和编辑器Archify 则在提醒我们架构图不应该是个装饰品。我的建议很简单别贪多挑一个方向装好工具在本周的小项目里先跑通这比收藏一百个仓库有用得多。