周五晚上照例把 GitHub trending 刷了一遍这周 W35 的榜单比前几周有意思不少awesome-gpt-image-2直接冲到了趋势榜第一说明图像生成方向的玩法确实在不断迭代紧接着是Archify一个把“架构图”和“可核验”绑定的工程工具再往后是Codex CLI和Claude Code两个命令行 AI 编程助手前者在讨论本地模型接入后者依然是平时问得最多的工具之一。这篇文章就把这四个方向挨个拆开说聊清楚它们各自解决什么问题、适合什么样的人用以及围绕它们我看到的实操细节和踩坑经验。不管你是做 AI 应用、后端架构还是日常写业务代码这期内容里应该都能找到能直接拿去用的东西。1. awesome-gpt-image-2图像提示工程的一次大盘点awesome-gpt-image-2登顶这件事多少有点意料之中。GPT 系列图像模型出来后网上每天都有大量新 prompt 玩法、风格实验和工作流分享但信息太零散新手想系统学习往往不知道从哪下手。这个仓库做的事情很简单把散落在 X、Reddit、个人博客里的提示词案例、风格关键词、参数调整经验集中整理按应用场景分类组织成一份清单。1.1 这类 awesome 仓库为什么值得订阅很多人觉得 awesome 系列就是“收藏夹”收藏完再也不看。但优秀的 awesome 仓库其实是“行业风向标”尤其像这种紧跟大模型的资源列表它的更新节奏往往能反应真实使用者的关注点。比如这周登顶后我翻了一遍里面有几类内容非常有参考价值高质量提示词模板例如“产品摄影风格单一主体 材质描述 光线方向 镜头焦距”这类可以直接套用的结构。风格实验案例把插画风、胶片感、3D 渲染风、微缩模型风放在同一张对比图里告诉你描述语差异对结果的影响。参数调节笔记比如output_format、quality、size这些参数在不同场景下的组合。多轮迭代工作流生成初版后如何通过修改局部描述语做二次优化而不是全部推倒重来。对不熟悉图像生成的人来说这份列表能减少大量试错成本。最典型的例子是 prompt 里“风格浓度”的把握直接写“一张赛博朋克风格的城市夜景”和写“一张雨夜霓虹灯下的城市街道主色调为青色与品红背景有全息广告牌浅景深”出来的结果完全是两个量级前者容易生成概念化的套图后者才更像一个经过构思的画面。1.2 从仓库清单里提炼出的 prompt 结构我在实际用图像模型时总结出一个比较稳定的 prompt 结构跟仓库里很多案例的思路一致主体 环境 风格 光线 构图 细节参数。举个例子如果想生成一张用于博客封面的“机械键盘俯拍图”可以这样写一条机械键盘放在深色胡桃木桌面上键帽为米白与橙色点缀 逆光从左侧打来右侧有柔和补光俯拍视角浅景深 背景虚化中有台灯和咖啡杯产品摄影风格高分辨率细节清晰你会发现这里没用什么夸张的形容词更多是在描述物理关系光线方向、视角、物件之间的位置。图像模型的底层逻辑是“理解场景”而不是“理解形容词”所以可验证的具体描述永远优于抽象的情绪词。这类经验正好就是 awesome 仓库里大家反复在强调的核心。有一个容易忽略的点是同一段 prompt 在模型升级后可能需要重新调。比如尺寸参数从 1024 改成 2048或模型对文字渲染的准确度提升后可以对画面里的“文字内容”提出更多要求。订阅这类仓库的另一个好处就是能及时看到社区对新版本模型的反应。2. Archify架构图从“画得好看”到“可核验”Archify在热词里被反复提到“怎么用”说明很多人注意到它了但还没弄明白它的定位。简单说它把架构图从“给人看的描述”变成了“可以对着代码检查的规格说明”。你在 Archify 里定义好系统组件关系后它能基于代码仓库的结构、配置文件、部署清单去做校验发现架构图和真实实现之间的漂移。2.1 架构图核验到底在解决什么问题做过一段时间系统设计的同学应该都有这种感觉架构图最怕的不是画错而是画完之后没人维护三个月后图上画的系统和线上跑的已经不是一回事了。团队协作时新成员看图理解系统结果图里的服务已经拆成两个模块数据流向也变了这种误导比没有图更危险。Archify 的思路是把架构图当作一种“可执行的文档”。它类似编译器之于代码你把代码和架构声明都交给它它来判断两边是否一致。如果某个仓库里新增了一个对外接口但架构图没更新它会给出告警如果代码里移除了某个异步消息队列但图上还挂着这个队列它也会标出来。这种“配置漂移检测”的思路并不新鲜基础设施领域早就有类似工具但把同样的理念用在架构图上确实解决了一个很实际的问题AI 辅助编码普及以后代码变更速度越来越快架构文档跟不上代码速度的矛盾会越来越突出。2.2 Archify 的典型使用套路根据我看到的资料和日常经验可以把 Archify 的用法理解成三个步骤在项目里用声明文件描述系统结构比如服务名、依赖关系、数据存储、对外 API。接入仓库的 CI 流程让 Archify 在每次提交或者 MR 时自动跑一遍检查。根据输出的差异报告决定是更新架构图还是调整代码结构。举个例子你可以在仓库根目录建一个类似archify.yaml的配置声明一个简单的订单服务结构services: order-service: api: [POST /orders, GET /orders/{id}] dependencies: [user-service, payment-service] storage: [postgres:orders] payment-service: api: [POST /payments] dependencies: [user-service]Archify 会扫描代码里路由定义、服务调用关系、数据库访问配置然后和这份声明做比对。如果代码里新增了一条DELETE /orders/{id}路由而声明文件里没有它就会提示“代码中存在未声明的 API 接口”。这套机制对中大型团队的价值很明显架构评审不用再靠人肉看代码MR 阶段就能自动暴露架构层面的偏差。对小型项目来说它的价值更多在于养成“代码、配置、文档同步变更”的习惯。需要提醒的是这类工具的核验能力取决于它能解析多少种代码和框架。刚开始用的时候不要追求一步到位建议先从“API 路由核验”或“依赖关系核验”这种单项能力入手跑通之后再逐步扩大检查范围。2.3 核验结果如何融入日常工作流不少人对“架构图可核验”的第一反应是那我得花时间画图还得学配置是不是增加了负担实际用下来我的体感是它反而减少了开会扯皮的时间。以前架构评审会上大量时间浪费在“这张图是不是最新的”上现在打开报告直接看差异点就行。我建议的使用方式是架构图继续用你习惯的工具画Archify 只负责对账。它就像一个自动巡检员平时不打扰你只有代码和声明不一致时才出声。配合定时任务每周跑一次检查把结果发到团队群里大家知会一声就够了。3. Codex CLI把智能编码助手搬回本地Codex CLI是这周榜单里另一个讨论度很高的项目热词里同时出现了“codex cli 使用教程”“codex cli 接入 llm”“codex cli 和桌面版对比”这些搜索说明有人已经在生产环境里认真评估它了。我是它的重度用户之一这里说说我的真实使用体验。3.1 Codex CLI 解决了什么痛点桌面版 AI 编程助手通常以 IDE 插件形态存在功能丰富但有几个绕不开的限制网络波动时容易断连、代码上下文上传量大时响应慢、私有化部署场景下很难直接接入内部模型。Codex CLI 的思路是把编程助手做成一个运行在终端里的命令行工具核心操作是你在仓库目录里输入指令CLI 读取本地代码通过模型处理后给出修改建议或直接执行命令。对我这种平时习惯用终端的人CLI 形态的吸引力在于“离代码更近”。它直接在本地文件系统上下文里工作不依赖 IDE 的索引机制也不受插件生态约束。而且 CLI 天然适合脚本化你可以把一次代码审查、一次批量重构写成固定命令反复执行。3.2 安装和基础配置Codex CLI 的安装方式在官方文档里写得很清楚主流的两种是通过 npm 或者包管理器安装。以 npm 为例npm install -g openai/codex装完之后在项目目录里运行codex就能进入交互界面。首次使用会引导你配置 API 凭据也可以选择把 CLI 指向自定义模型端点这一点对团队私有化部署非常关键。我推荐的配置项有两个一个是模型选择一个是自动审批策略。刚开始用的时候务必把自动执行命令的权限关掉等确认 CLI 对项目结构足够理解之后再放开。配置文件的写法通常类似这样{ model: gpt-5-codex, auto_approve: false, workspace: [/path/to/repo/src] }这里的auto_approve就是那个关键的开关false表示每个可能改动文件的操作都需要你确认true则是让 CLI 自主执行。我见过不少人在配置阶段图省事直接开true结果 CLI 把测试文件批量删掉的事故所以这里务必谨慎。3.3 “unable to locate the codex cli binary”问题解析热词里反复出现“unable to locate the codex cli binary. set codex cli path or ensure the elec...”这条报错属于 CLI 接入桌面端或编辑器扩展时非常典型的路径定位问题。含义是某个依赖 CLI 的图形界面程序找不到可执行的 codex 二进制文件。排查思路其实很简单按顺序检查三个地方CLI 是否真的装上了。在终端直接运行codex --version如果提示命令不存在说明安装环节出了问题。检查 npm 全局 bin 目录是否在 PATH 环境变量里。npm 全局包的 bin 目录一般可以通过npm prefix -g查出来确认它被加入了 PATH。在桌面端或编辑器的配置里显式指定 codex 路径。比如在配置文件中设置codex_cli_path指向二进制的绝对位置。从实际操作看第三条最常见。图形界面程序启动时的环境变量往往和终端不完全一致所以显式指定路径是最稳妥的做法。3.4 接入本地模型的实际体验热词里“codex cli 接入 llm”搜索量很高说明很多人在尝试让 CLI 流向本地模型。我试过通过配置base_url指向本地推理服务的方式把 Codex CLI 接入自建端点。这个方法不算复杂就是要先起一个兼容 API 协议的推理服务再把 CLI 的端点配置指过去。接入之后的体感差异很明显本地模型的响应速度受显卡性能影响大代码推理的准确率目前还是和头部云端模型有差距。但优势在于数据不出内网对敏感代码场景来说足够了。如果你也想走这条路建议先从代码补全、测试生成这类低风险任务开始跑别一上来就让它做大范围重构。我会做一张表把 CLI 和桌面版的区别直观列出来方便大家决策对比维度Codex CLI桌面版/AI 编程助手插件运行环境终端IDE 内嵌面板上下文获取方式读取本地文件与命令输出依赖 IDE 索引和打开的文件扩展性可脚本化、可接入 CI受插件 API 限制对私有模型的支持通过端点配置可灵活接入取决于插件是否开放配置适用场景批量任务、脚本化开发、远程环境边写边改的交互式编程两者不冲突我现在桌面版用来做日常编码CLI 则用来做批量重构和定时任务互相补充。4. Claude Code命令行里的结对搭档Claude Code这周也是高频词搜索里既有“claude code 安装”“claude code 使用教程”也有“claude code cc switch ollama”这种组合玩法。我对它的评价是Claude Code 可能是目前把“自然语言描述 → 执行结果”这条链路做得最顺的命令行工具之一适合那些不喜欢被 IDE 绑定、想用对话方式完成开发操作的开发者。4.1 安装与登录的完整流程Claude Code 的安装同样走 npm 最方便命令是npm install -g anthropic-ai/claude-code安装完成后运行claude命令行会进入引导模式引导过程会要求你完成账号认证。这一步有几个注意事项安装前确认 Node.js 版本满足要求版本太旧可能导致启动失败。首次登录需要在终端打开一个认证链接认证完成后凭据会保存在本地。公司网络如果有额外的认证代理CLI 默认是读系统代理设置的不需要额外配置。认证完成后在任意项目目录运行claude它会创建会话读取当前目录的文件并等待你的指令。这个“当前目录就是项目上下文”的设计很关键你在哪个目录启动它就默认以哪个目录为工作范围。所以建议为每个项目单独开终端避免跨项目误操作。4.2 在 VSCode 里配置 Claude Code把 Claude Code 和 VSCode 配合使用是目前讨论度很高的组合。严格说 Claude Code 是 CLIVSCode 是编辑器两者的“配置”指的是让终端里的claude命令可以直接在 VSCode 的集成终端里运行同时把 VSCode 打开的文件夹作为项目上下文。这个配置过程不算配置只是把两个工具接力起来。我在实际使用中会做三件事VSCode 集成终端里直接调用claude这样看到的代码、报错、终端的输出天然就是同一个项目。用 VSCode 的文件对比功能处理 Claude Code 改过的代码。CLI 改完文件后在源代码管理里能直接看到 diff精细化调整很方便。把常用的审查指令存成 shell 脚本或 Claude Code 的会话记录减少重复打字。给新手的建议是第一周先只让它做“解释代码”“生成单测”“查日志报错”这类的只读或低风险操作等熟悉了它的行为特点再逐步放权让它做批量修改。4.3 Claude Code 搭配 CC Switch 和 Ollama 的组合玩法热词里有“claude code cc switch ollama”这个组合本质上是把 Claude Code 的前端交互能力和本地模型的后端推理能力连接起来。CC Switch 类的工具一般负责管理多个“API 端点配置”让客户端可以在不同模型服务之间快速切换Ollama 则是本地模型运行工具负责加载和提供模型接口。配置思路大致是先在 Ollama 里拉取一个代码能力较强的模型并确认本机 API 服务启动正常。用 CC Switch 添加一个指向http://localhost:11434的自定义供应商配置。在 Claude Code 的配置里把模型来源指向 CC Switch 管理的这个本地端点。启动后先把任务难度降到最低验证链路是否连通。这里要泼一盆冷水本地模型的代码能力目前和顶级云端模型还有差距尤其复杂重构和多文件协作场景差距更明显。这个组合更适合两类人一类是隐私敏感、必须内网离线开发的团队另一类是本地开发学习、想了解模型推理机制的技术爱好者。追求效率的话该用云端模型还是用云端模型。4.4 限额和频率问题的处理热词里有一条“your limits are temporarily boosted. your weekly claude code limit is 50% higher”说的是使用额度被临时提升的提示。这类额度提示是服务方的常规运营策略不是故障。遇到这类提示唯一的正解是合理安排每周的任务节奏把高优任务排在配额充足的时段同时考虑用本地模型承接低风险任务减轻额度压力。不要想着绕过或破解限额这在任何服务条款下都是禁区。实际使用中我也养成了一个习惯每天收工前把当天的会话记录导出标注哪些指令有效、哪些描述有歧义。这样既能作为自己提示词优化的素材也能在续会话时给 Claude Code 一个更清晰的工作状态。5. 四个工具横向对比我该怎么选四个项目放在一起看其实分属不同赛道但很容易被刚接触的人搞混。这里做一个横向对比方便根据自身情况选型工具核心定位适用人群上手难度awesome-gpt-image-2图像 prompt 资源库内容创作者、设计相关开发低Archify架构图与代码一致性校验后端团队、架构师中Codex CLI可本地化接入的终端编程助手熟悉命令行的开发者中Claude Code对话式编程 CLI 工具想摆脱 IDE 束缚的开发者中低日常开发建议如果你想给自己找一个主力 AI 编程工具Codex CLI 和 Claude Code 可以都装上花两天时间分别用一用看哪个更符合你描述需求的方式。做架构设计或维护老系统时重点评估 Archify。至于内容生成和配图需求awesome-gpt-image-2值得长期关注即使不搞图像创作也能从里面学到不少提示词方法论迁移到文本模型上也适用。6. 写在后面这周榜单给我的一点体会每周刷榜单最大的感受是工具迭代速度远超文档更新速度。不管是图像生成的 prompt 编排还是 CLI 编程助手的本地化接入新玩法出来之后往往要社区自己摸索一阵子官方文档才慢慢补上。这也是为什么 awesome 类仓库和周刊这类内容会持续有人看——它们承担了一部分“非官方转译”的功能把零散经验汇总成可快速消费的信息。对我来说本周最值得动手试的是 Archify 的核验思路。以前做架构评审时最累的就是让人肉去对比设计文档和代码实现现在既然工具能把这件事自动化那团队的工作重心就能转移到“如何定义合理的架构规则”上这比画一张精美的图有价值得多。另外多说一句安装这些 CLI 工具时如果遇到网络连接不稳定的情况不要频繁重试同一个源先检查本机环境配置是否完整。很多所谓“装不上”的问题其实不是工具本身的问题而是系统环境里缺失了依赖。放慢节奏逐项排查比反复重装有效得多。这周榜单就先聊到这里如果你对哪个工具的具体用法有疑问欢迎在评论里交流。