每次到周五下午，我都会把 GitHub Trending 拉出来，把当周涨幅最猛、讨论最集中的仓库过一遍。2026 年第 35 周这期，信息量确实比平时大：awesome-gpt-image-2 直接登顶，Archify 把“架构图可核验”这件事从前沿概念变成了可落地工具，Codex CLI 和 Claude Code 两个 AI 编程 Agent 又同时往前迈了一大步。如果你也是那种“收藏了几百个仓库但真正用起来的没几个”的开发者，这一期值得认真看。
这篇周刊不只是报菜名式列项目，我会把每个仓库解决什么问题、原理是什么、上手怎么操作、有哪些坑，全部拆开讲清楚。涉及 AI 编程 Agent 的部分，我会直接给出安装命令、配置项和报错排查清单。即使你之前完全没接触过这些工具，跟着文章走一遍也能跑起来。
1. 本期榜单速览：四个方向，一条主线
1.1 2026W35 趋势项目快评
先快速过一遍本期核心项目，方便你判断先从哪个下手。我按“一句话定位、适用人群、上手成本”三个维度列了个表：
| 项目 | 一句话定位 | 典型使用场景 | 上手成本 |
|---|---|---|---|
| awesome-gpt-image-2 | GPT 图像生成方向精选资源聚合仓库 | 找提示词模板、API 封装、商业案例、评测基准 | 极低，阅读为主 |
| Archify | 让架构图与实际代码保持一致的核验工具 | 微服务治理、架构评审、CI 质量门禁 | 中等，需要配置规则 |
| Codex CLI | OpenAI Codex 的本地命令行 Agent | 本地仓库多步编码任务、跑测试、生成 patch | 较低，npm 安装即可 |
| Claude Code | Anthropic 出品的终端编程 Agent | 大型代码库理解、重构、跨文件修改 | 较低，npm 安装即可 |
这四个项目看着方向不同，但放在一起看，我能明显感觉到一条主线：AI 编程工具正在从“网页对话框”走向“本地开发环境”。awesome-gpt-image-2 登顶说明图像生成的应用层资源正在快速沉淀；Archify 走红说明大家在用 AI 写代码之后，开始担心架构约束被破坏；Codex CLI 和 Claude Code 则是把 Agent 的能力直接塞进了终端。
1.2 榜单背后：AI 工具链正在“本地化”
很多读者可能没注意到，这一周的热点关键词其实是“本地”。Codex CLI 的卖点是代码在本地执行、指令在本地跑；Claude Code 默认就在终端里操作文件系统；Archify 做架构核验，也是要在本地代码库上做静态分析。
这种本地化趋势背后有一个非常实际的诉求：之前用云端 IDE 或网页版 AI 编程工具，代码要传到云端才能跑，涉及私有仓库、内网依赖、公司安全策略时非常不方便。本地化 Agent 把代码读取、命令执行、文件修改都放在开发机里，只有模型推理请求会发到云端，灵活性高了很多。我自己的体验是，很多不适合贴到网页对话框里的内部项目代码，用 CLI 版 Agent 反而能安全地做改造。
不过要提醒一句，“本地化”不等于“离线”。Codex CLI 和 Claude Code 的核心模型推理依然在云端服务器完成，只是代码分析、编辑、命令执行发生在本地。对这一点心里要有数，涉及核心机密代码时，还是先确认公司安全策略允许。
2. awesome-gpt-image-2：为什么一个资源清单能登顶
2.1 这个仓库解决什么问题
一个 awesome 列表能冲到 Trending 第一，说明背后对应的技术方向正处于爆发期。awesome-gpt-image-2 聚焦的是 GPT 系列模型的原生图像生成能力，也就是不经过传统扩散模型流程，直接用自回归方式生成图片的那条技术路线。它的优势非常明显：文字渲染准确、能理解复杂构图指令、多轮对话中可以直接修改上一张图。
这个仓库真正的价值在于把分散的信息聚拢了。官方文档更新频繁，第三方工具和开源复刻项目层出不穷，社区提示词和商业案例分散在 X、Reddit、Discord 里，单独去找效率极低。awesome-gpt-image-2 把这些内容按类型整理好，包括提示词模板、API 封装库、评测基准、开源复刻项目、商业化产品案例、版权与合规指南，基本做到了“一个仓库解决信息过载”。
我翻了一遍，最值得重点看的是两个分类：提示词模板和评测基准。提示词模板能直接抄作业，评测基准则能帮你判断各种封装方案的差异，避免被营销话术带着走。
2.2 高效读完一个 awesome 项目的方法
很多人看到 awesome 列表第一反应是 star，然后就没有然后了。这类仓库并不是让你从头到尾通读的，它更像一本索引。我的习惯是先看 README 的目录结构，找到当前最需要的那个分类，直接跳转。
接下来看维护活跃度。一个 awesome 列表如果三个月没更新，里面的资源大概率已经失效。可以看最近 commit 时间、contributor 数量，以及 issue 里有没有人反馈“某个链接已经 404”。维护越频繁，可信度越高。
最后是交叉验证。列表里提到的关键工具，我会去项目主页看 star 数、最近 release 时间、README 质量，再决定要不要进一步研究。这个筛选流程通常 20 分钟就能完成，比盲目下载试用高效得多。
2.3 实操建议：把列表变成自己的工作台
我个人不建议把 awesome-gpt-image-2 整个 clone 到本地，直接用浏览器看 GitHub 网页版就够了。但如果你频繁搜索里面的内容，可以把它 fork 一份，按自己的项目需求添加注释和标签，维护一份私人版的资源索引。
另外，这类仓库对内容贡献者很友好。如果你在实际使用中发现了高质量提示词模板、或者某个好用的 API 封装，完全可以提 PR 补充进去。给 awesome 类仓库贡献内容，是参与开源社区成本最低的方式之一，也算给自己在社区里留下记录。
3. Archify：让架构图真正“可核验”
3.1 可核验架构的思路拆解
传统开发流程里，架构图是画给人看的，代码是写给机器跑的，两者之间的偏差只能靠人工 review 发现。时间一长，架构图就成了“墙上的装饰画”，和实际代码完全对不上。Archify 的思路是把架构图变成一种“可执行的规范”。
具体做法是：用声明式的方式描述系统应有的组件、依赖关系、边界约束，然后通过静态分析扫描代码里的模块引用、函数调用、服务间通信、配置文件等，动态生成实际架构模型。最后把“预期架构”和“实际架构”做比对，输出差异报告。简单说，就是把架构评审从“靠人眼”变成“靠工具”。
这套思路的价值在微服务架构里体现得最明显。多人协作、频繁迭代时，很容易出现“服务 A 不该调用服务 B，但某次改动偷偷引了 B 的 SDK”的情况。人工 review 不一定每次都能发现，但 Archify 这种自动化核验可以在每次提交时都检查一遍，发现违规直接拦截。
3.2 Archify 的落地流程与 CI 集成
Archify 的使用流程大致分四步：安装 CLI、配置架构规范、运行校验、接入 CI。安装方面，Archify 提供 npm 包和二进制两种方式。我测试时用的是 npm 全局安装，Node.js 20 以上版本可以直接跑：
npm install -g archify archify --version安装完成后的核心工作是写配置文件。Archify 支持从常见架构描述格式导入预期架构，也可以用它自己的 DSL 定义。我的习惯是用 DSL 直接定义关键依赖边界，因为最简洁也最好维护。下面是一个简化版的配置示例：
project: order-system version: 1 architecture: components: - name: web-app - name: api-gateway - name: order-service - name: payment-service - name: postgres allowed_edges: - from: web-app to: api-gateway - from: api-gateway to: order-service - from: order-service to: postgres forbidden_edges: - from: web-app to: order-service - from: payment-service to: web-app配好后运行校验命令：
archify verify --config archify.yaml --source .它会扫描当前代码库，输出实际依赖关系与预期架构的差异，列出违规调用链。第一次跑的时候通常会有一些“误报”，需要逐个确认后加入忽略列表。
CI 集成是 Archify 的灵魂。我把它作为 GitHub Actions 中的一个检查步骤，每次 PR 自动跑一遍。配置大致是这样的：
- name: Run Archify run: archify verify --config archify.yaml --source . continue-on-error: false一旦有人写了跨越架构边界的代码，PR 检查直接红掉，评审人就知道要去关注哪块了。这个机制比任何 review 约定都硬核。
3.3 使用中的抗噪与维护技巧
Archify 用起来最需要警惕的是“误报疲劳”。项目初期，架构规则往往不完整，跑一次出一堆问题，团队很容易直接把整个文件禁用。我的建议是先把最核心的几条硬约束配置好，比如“网关不能绕过”“数据访问只能通过 DAO 层”，再把次要规则逐步放开。规则少而精，团队才能坚持用下去。
另外，架构规范本身也要纳入代码评审。业务重构经常导致架构变化，如果规则文件不跟着更新，Archify 会反过来阻碍开发。我会把架构配置文件的变更视为架构决策变更，必须单独说明原因。这样才能保证工具是团队的朋友，而不是敌人。
4. Codex CLI 本地化：从云端 IDE 到终端工作流
4.1 Codex 与 Codex CLI 怎么选
先解决很多人的疑问：Codex 和 Codex CLI 到底有什么区别，哪个更好用。
Codex 是 OpenAI 推出的云端编程助手，通常在网页端或 IDE 插件里使用，适合快速问答和小范围修改。它的优势是零配置，打开就能用，但代码如果要保留在本地，就需要反复复制粘贴，体验很割裂。
Codex CLI 则是把同一个底层模型能力搬到了本地终端。你可以直接指定任务，比如“给 parsing 模块补单元测试”，它会自己读代码、生成修改、执行测试、输出 patch。整个过程都在本地 Git 仓库里完成，你能看到每一步改动。
我的判断标准很简单：日常小改动用 Codex 网页版就行，省心；真正要改一个模块、跑一轮测试、生成完整 patch 的时候，用 Codex CLI。它更像是给开发者配了一个能随时调用的本地“结对程序员”。
4.2 安装、认证与首次运行
Codex CLI 的安装依赖 Node.js 20 以上版本，推荐用 npm 全局安装：
npm install -g @openai/codex codex --versionLinux 用户装完后如果提示找不到命令，通常是 npm 全局 bin 目录没进 PATH。检查一下当前用户目录下的~/.local/bin或 Node 安装目录，手动加一下：
export PATH="$HOME/.local/bin:$PATH"认证方式有两种：一是登录 ChatGPT 账号，复用订阅额度；二是配置 OpenAI API Key，按 token 计费。我用的是 API Key，因为可以在多个项目里分别控制成本。把 Key 写到环境变量即可：
export OPENAI_API_KEY="sk-xxxx"首次运行先找一个测试仓库试水：
codex "给当前项目添加一个 CHANGELOG.md，列出最近三次改动的摘要"它会先分析仓库结构，再生成 diff，最后由你确认是否应用。这一步的交互体验比我想象中好，关键改动都看得很清楚。默认命令执行在沙箱环境里，防止 Agent 误操作破坏系统；如果你信任当前任务，可以放宽沙箱策略，但我的建议是保持默认，谨慎最重要。
4.3 实战场景与 superpowers 技能包
Codex CLI 最擅长的场景是“多步编码任务”。比如我让它“把订单服务里的同步通知改成异步消息”，它能自己找到通知发送代码、改成投递到消息队列、补单元测试、更新相关配置文件。这类任务放在以前至少得半天时间，现在十几分钟就能拿到一个可 review 的 patch。
最近社区里很火的“superpowers”技能包本质上是一套增强提示词和工具脚本，目的是让 Codex CLI 在复杂任务中的表现更稳定。安装方式通常是把技能包目录挂到 Codex CLI 的配置里，或者在项目里加一份技能描述文件，让 Agent 遇到特定场景时调用对应的提示词。我用下来的感受是：它对“大型仓库理解”“多文件协调修改”这类任务确实有提升，但对小任务反而会增加额外指令开销。如果不是经常处理复杂重构，第一版先用官方默认配置就足够了。
4.4 高频报错排查记录
这里直接整理一份我在使用中遇到的报错速查表，遇到问题可以对照处理：
| 报错信息 | 可能原因 | 解决办法 |
|---|---|---|
| unable to locate the codex cli binary or required runtime components | IDE 插件找不到 codex 可执行文件，一般是 PATH 没配对 | 确认which codex有输出，没有则把 npm 全局目录加入 PATH，重启 IDE |
| module not found: openai | Node.js 版本过低，npm 依赖安装失败 | 升级 Node.js 到 20+，重新npm install -g @openai/codex |
| authentication failed | API Key 失效或权限不足 | 检查OPENAI_API_KEY环境变量，重新生成 Key |
| command execution is not allowed in sandbox | 当前任务需要非白名单命令，沙箱拒绝执行 | 为命令添加白名单，或在该任务上使用更宽松的沙箱策略 |
| git repository not found | 在非 Git 目录运行，部分能力受限 | 用codex --skip-git-repo-check跳过检查，或先git init |
遇到问题先看 PATH，再看版本，最后看认证，能解决 80% 的情况。
5. Claude Code 实战：安装、VSCode 集成与限额解读
5.1 安装与首次启动
Claude Code 是 Anthropic 的终端编程 Agent，定位和 Codex CLI 很像，但在代码库级理解和多文件重构上表现更突出。安装同样走 npm：
npm install -g @anthropic-ai/claude-code claude --versionWindows 用户也可以用官方提供的原生安装包，不过实测下来 npm 方式最简单，node 20 以上都能装。认证方式也是两种：登录 Claude 订阅账号，或者用 Anthropic API Key。建议按使用场景区分：个人开发用订阅账号就够，团队自动化场景用 API Key 方便配额管理。
首次启动后，在当前项目目录直接输入：
claude它会进入交互式对话界面，你可以在里面要求它“解释这个项目是干什么的”“找到库存扣减的并发问题”等等。Claude Code 对大型代码库的结构理解能力很强，提问后它会先自己阅读相关文件，再给出分析和修改建议，而不是像普通对话那样直接答一个泛泛的解决方案。
5.2 在 VSCode 里把 Claude Code 用顺
很多人问“VSCode 里怎么配置 Claude Code”。实际上 Claude Code 本身就是终端程序，直接在 VSCode 内置终端里运行就能用，不需要额外插件。之所以有人觉得要配置，是因为 VSCode 集成终端的环境变量可能和系统终端不一样，导致某些命令找不到。
我的做法是在 VSCode 里打开项目目录，然后用快捷键调出终端，输入claude启动。这样它能直接看到当前打开的项目，修改完代码，VSCode 左侧的源代码管理面板也会实时显示改动。配合 VSCode 的 diff 视图，Agent 改完的东西你能像 review 同事代码一样逐行确认。
如果你需要更丰富的面板操作，可以考虑装官方插件。但我个人的建议是：先用内置终端跑两周，确定它确实能融入你的工作流，再考虑装插件升级体验，避免过早堆工具。
5.3 接入 DeepSeek 等第三方模型
Claude Code 很吸引人的一点是它支持通过环境变量切换到兼容 Anthropic 协议的第三方模型端点。操作方法不复杂，设置ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN两个环境变量后再启动即可。
以接入 DeepSeek 为例（前提是服务商开放了兼容端点），配置如下：
export ANTHROPIC_BASE_URL="https://api.deepseek.com/anthropic" export ANTHROPIC_AUTH_TOKEN="sk-xxxx" claude这样 Claude Code 的 UI 和终端体验不变，但底层模型换成了其他服务商，成本可能低不少。需要注意的是，第三方模型的能力和官方 Claude 不完全一致，尤其复杂任务规划和工具调用上会有差距。我的实测感受是：简单代码生成和解释用第三方模型性价比很高，大型重构还是要切回官方模型才稳。切换前务必先确认服务商的兼容端点和计费规则。
5.4 周限额与提示解读
用 Claude Code 订阅账号登录后，会看到类似“Your limits are temporarily boosted. Your weekly Claude Code limit is 50% higher”的提示。很多人在社区里问这是不是报错，这里统一说明：这不是警告，是系统通知你本周额度被临时提升了 50%，通常是官方活动或新用户福利，正常使用即可，无需处理。
真正需要留意的是超额提示，也就是当周额度用完时的拦截通知。这时候要么等下周额度刷新，要么切换到 API Key 按量付费。我的经验是，如果是高强度工作，建议直接准备一个 API Key 作为兜底，别在活多的时候被额度卡住。
还有一个安全提醒：Claude Code 有权限直接修改文件、执行命令。强烈建议在独立 Git 分支上使用，每次 Agent 改完先看 diff，确认没问题再提交合并。我见过有人在主分支上直接让 Agent 跑重构，结果改乱了只能手动回滚，那酸爽不值得体验。
6. GitHub 访问与下载的日常问题处理
6.1 看着像“打不开”的三类情况
聊完几个项目，必须回应一下很多读者问过的实际问题：GitHub 有时候打开慢、克隆仓库超时、release 文件下载到一半断掉。这些现象在网络环境不理想的地区很常见，但并不一定都是“网站挂了”，很多时候是以下三类原因造成的。
第一类是 DNS 解析异常，浏览器提示“无法访问此网站”，但手机流量访问却能打开。第二类是克隆大仓库超时，尤其是带大量历史提交的仓库，传输体积大，网络稍微波动就断。第三类是 release 下载速度极不稳定，几十 MB 的文件下到一半就失败。搞清楚现象背后的原因，才有对应的处理思路。
6.2 不用折腾也能改善体验的常规操作
先说几条完全合规、不涉及任何特殊工具的操作。遇到网站打不开，第一步应该尝试刷新本机 DNS 缓存，改用一个公共 DNS 再访问。Windows 上清缓存命令是ipconfig /flushdns，macOS 是sudo dscacheutil -flushcache。公共 DNS 可以用国内服务商提供的 223.5.5.5、119.29.29.29 这类地址，改完再访问，很多偶发性打不开就解决了。
克隆仓库超时的问题，可以按场景处理：如果只需要最新代码做阅读或测试，用浅克隆参数只拉取最新提交：
git clone --depth 1 https://github.com/owner/repo.git如果是下载 release 里的二进制文件很慢，优先用官方 GitHub 命令行工具gh：
gh release download v1.0.0 --repo owner/repo --pattern "*.tar.gz"gh走的是官方 API，成功率通常比浏览器直接下载高。另外可以把大仓库拆分成子模块拉取，或者选在低峰时段重试几次，我对这种“笨办法”的评价是：多数时候比折腾复杂方案更管用。
6.3 镜像与第三方下载的底线原则
社区里经常有人讨论第三方镜像和下载站点，我的态度是：可以作为临时应急手段，但不要作为长期依赖。部分镜像站会同步热门仓库快照，下载速度确实不错，但这意味着你拿到的可能不是实时代码，而且第三方同步渠道的安全性和完整性需要自己承担风险。对于关键项目，我一定会用git fsck或者核对 commit hash 之后才放心。
这里给出几条底线原则：第一，能用官方渠道就用官方渠道，多试几次、换换时段都比第三方可靠。第二，不要在任何第三方站点输入账号密码或敏感 token，身份信息泄露的风险不值得省那几分钟。第三，涉及公司商业代码时，一律走公司内网或官方私有仓库方案，不通过任何外部中间渠道拉取。
7. 每周刷 GitHub 的个人工作流建议
7.1 我的一小时 weekly review 流程
这期周刊能看到最后的人，应该也是真心想从 GitHub 里提炼价值的。分享一个我坚持了很久的工作流：每周五下午固定留一小时做 GitHub weekly review，不贪多，只做四件事。
第一件，花十分钟扫一遍 Trending 和星标增长最快的仓库，记录下和当前技术栈相关的项目。第二件，选一个最值得深挖的项目看 README、架构设计和最近 commit，判断它解决的实际问题。第三件，把自己感兴趣的项目加入一个专门的 search list，方便月底统一回顾。第四件，挑一个已经跑起来的小项目，实际读一部分源码，哪怕只是理解一个核心函数。
这样做的好处是“输入”和“输出”平衡：既保持了对行业动态的敏感度，又不会陷入收藏夹吃灰的循环。我用这套方式筛过的项目中，最后真正进入生产环境的有两个，都是先通过 weekly review 发现，再花时间评估引入的。
7.2 从“看过”到“沉淀成自己的弹药库”
“看过”和“会用”之间差着一次实操。我对每个值得研究的项目，都会做三件事：fork 一份代码，做 patch 级分析了解关键实现；写一个 demo 跑通核心功能，记录踩坑过程；把使用心得和适合场景写进个人笔记，形成自己的技术弹药库。
弹药库积累多了之后，遇到新需求的第一反应不是搜索引擎，而是“这个场景我是不是在某次 review 里见过类似的实现”。这种联想能力只能靠时间和积累换，没有任何捷径。本期提到的 awesome-gpt-image-2、Archify、Codex CLI、Claude Code，都可以作为这一周弹药库的第一批入库内容。
最后分享一个我自己的小习惯：每周挑一个还没被大众注意到的冷门工具项目，动手用一次，然后写下“它解决了一个什么问题、如果永生维护我会怎么做”。这类练习能逼着你去理解工具背后对问题的抽象方式，比单纯追热点收获大得多。GitHub 上的好项目是刷不完的，能沉淀下来变成自己能力的东西，才是真正属于你的。