一、一则快讯引爆AI圈

6月4日早晨6点，财联社推送的一条简短快讯震动业界：“OpenAI 据悉正计划将 Codex 与 ChatGPT 合并。”不过四十多字，却让整个技术社区沸腾起来。为什么？因为在48小时前的深夜，OpenAI才刚举办了一场面向企业的专题直播，发布了Codex三项重磅更新——角色插件、Sites建站工具和Annotations精确批注。外界原以为这只是一轮普通的版本迭代，直到直播尾声，联合创始人兼CEO Sam Altman突然揭开底牌：

Codex将在数周之内，整体融入ChatGPT。

这不是在ChatGPT里新增一个入口那么简单。这意味着三条原本各自独立的产品线——ChatGPT（对话）、Codex（任务执行）、Atlas浏览器（环境感知）——将被熔铸为一款桌面超级应用。届时，近10亿ChatGPT存量用户将可以直接在统一界面中启用完整的AI办公能力。

二、三个月前的备忘录：Code Red警报

时间拨回2026年3月19日。CNBC独家报道，OpenAI应用副总裁Fidji Simo发出内部备忘录，宣布ChatGPT桌面版、Codex编程平台与Atlas AI浏览器将整合成一款统一的桌面超级应用。一位女发言人随后证实该计划，并强调：“新超级应用将让内部团队协同更紧密，也将帮助研究部门更快把成果转变为产品。”联合创始人Greg Brockman亲自督战。

然而外界并不清楚，这次整合的急迫性早已到了窒息的程度。

代号“Code Red”

2026年初，Anthropic旗下的Claude Code正以令人难以置信的速度蚕食开发者市场：

54%的市场份额。Claude Code一度独占了AI编程工具的半壁江山，远超GitHub Copilot和Cursor。更致命的是，Anthropic在2026年Q1录得48亿美元营收，Q2预测高达109亿美元——几乎一个季度就翻一番，估值逼近万亿美元，势头有望压过OpenAI。OpenAI随即拉响了内部的“Code Red”警报。

三月时的Codex：仅160万周活

据虎嗅报道，合并计划启动之时，Codex的周活跃用户数仅有大约160万。作为2026年2月才推出桌面客户端的产品，这个增速并不算差，但和Claude Code的差距令人焦虑。而且OpenAI面临一个更深层的困境：用户不知道该选哪个产品。

“企业最迫切的需要是把所有产品和服务融合成统一的内部工作流。”Sam Altman在6月2日的直播中这样说道。此前，ChatGPT负责闲聊，Codex处理编程，Atlas负责浏览网页——三者互不联通，上下文断裂，用户时常困惑“这个任务该点开哪一个”。合并是唯一的出路，而Code Red的压力让必然变成了刻不容缓。

三、90天极速冲刺：从160万到500万周活

随后90天里，OpenAI以惊人的速度推进Codex能力建设和用户增长：

四月：补齐基础能力

• 内置浏览器正式上线
• 开放计算机操作（Computer Use）能力
• SSH远程连接功能
• 代码审查大幅增强

五月：拓宽使用场景

• 移动端App上线，手机变为远程遥控器
• Appshots截图功能问世
• 目标模式（Goals）支持长时间任务
• 锁屏状态下也可远程控制
• Chrome扩展程序发布

6月2日：直播三连更与合并官宣

• 六个角色专属插件，覆盖62款应用、110项技能
• Sites一键建站
• Annotations精准批注
• 正式宣布与ChatGPT合并

增长数据如下：

PR 提交两分钟后，AI 即可返回一份全面的代码审查报告。这并非遥远的未来，而是今天就能落地的实践。

还在为每个 PR 手动审查代码而烦恼？还在犹豫是否要把仓库权限交给第三方 AI 审查工具？本文将带领你用 OpenCode 与 GitHub Actions 构建一条完全自主可控的 AI 代码审查流水线——无需交出仓库权限，不绑定任何平台，边际成本几乎为零。

为何要在 CI 中引入 AI 代码审查

传统持续集成与交付的局限性

传统的 CI/CD 管道已经解决了自动编译、自动测试和自动部署等问题，但在代码审查环节，大多数团队依然依赖人工。

典型的人工审查流程：  

开发者提交 PR → 等待同事空闲 → 同事粗略浏览 → LGTM → 合并  
                  ↑                          ↑  
            时间成本高                 质量无法保证

传统 CI 在代码审查方面存在明显的短板：

AI 辅助审查带来的价值

AI 代码审查并非要取代人工，而是充当一道 7×24 小时在线、标准统一的第一道质量关卡：

引入 AI 审查之后：  

开发者提交 PR → AI 立即审查（< 2 分钟）→ 自动评论反馈 → 人工最终决策 → 合并  
                   ↑                               ↑  
            即时响应，全天候                  开发者提前修复问题

AI 审查能够做到：

在AI大模型快速迭代的今天，如何不花一分钱就能用上当前最主流的国产开源模型？OpenCode Zen 给出了一份令人惊喜的答案。这篇文章将为你详细展示 OpenCode Zen 免费模型的实际能力，并通过 CC Switch 工具手把手教你完成接入，让 Claude Code 即刻调用这些强大模型。

前段时间我们曾深入评测过 OpenCode 编程套餐，那次体验已经证明，5美元的 OpenCode Go 套餐确实汇聚了市面上所有能打的国产开源模型，性价比直接拉满。然而没想到的是，OpenCode Zen 还藏着更大的福利——多个完全免费的模型接口，覆盖了 DeepSeek、小米、NVIDIA、MiniMax 等一线厂商，而且全部是已测试验证的聚合接口，可用性和响应质量都有保障。

一、OpenCode Zen 免费模型清单

这些模型均为各家最新的版本，覆盖了轻量高速与强性能的不同需求，你能不花一分钱就享用前沿的AI能力，确实让人直呼“这波真香”。

接下来是核心内容，我会用最清晰的步骤教你通过 CC Switch 工具，将这些免费模型接入到 Claude Code 中使用。

二、接入 OpenCode Zen 免费模型的详细教程

1. 获取 OpenCode API 密钥

首先登录 OpenCode 平台，进入 Zen 页面后，系统会自动生成一个 API 密钥。你只需直接复制保存即可，整个过程几乎零门槛。

OpenHuman 究竟是个怎样的存在？

OpenHuman 是一款开源的智能体助手，它的使命是深度融入你的数字日常——默认以隐私为先，开箱即用，并且威力强大到足以取代一堆零散且互不相通的 AI 工具。截至发文时间，从 2 月中旬上线到 5 月下旬这短短三个月内，OpenHuman 已在 GitHub 上揽获超过 24k stars。

大多数 AI Agent 一启动就要面对“冷开场”——你必须花上几天乃至数周向其灌输数据与上下文，它们才能开始发挥价值。而 OpenHuman 彻底颠覆了这一局面：只需关联你的各类账号，几分钟之内，Agent 就能完整压缩你的收件箱、日历、代码仓库、文档与消息记录。这得益于三大协同运转的架构支柱：Memory Tree 将所有已关联数据浓缩成精炼的 Markdown 文档；Auto-Fetch 以 20 分钟为周期循环同步你的账号信息；TokenJuice 则在任何数据进入大模型之前，先经过压缩层处理。最终的结果是，你从第一句对话开始，它就真正地“认识”你。

官网 / 安装入口：tinyhumans.ai/openhuman

桌面截图

八大核心特色功能

OpenHuman功能概览

1. 桌面优先，原生体验，开箱即用
拥有完整的桌面图形化界面（基于 Tauri + Rust + Electron 技术栈），安装后几分钟内就能跑起一个可用的智能体，完全不需要在终端里配置繁琐的 config。桌面还配有会说话、能感知周边环境的吉祥物，它可作为真实参与者加入 Google Meet 会议，并支持口型同步。即使你停止输入，它也会在后台持续思考。

2. 118+ 第三方集成，一键 OAuth
内置 Gmail、Notion、GitHub、Slack、Stripe、Calendar、Drive、Linear、Jira 等超过 118 个集成项，只需点击 OAuth 授权即可搞定，无需手动去配置 API Key。每一个连接都以类型化工具的形式暴露给 agent。

3. Auto-Fetch 自动拉取
每 20 分钟自治遍历所有活跃连接，将新数据拉入记忆树。你完全不需要写任何提示词或轮询逻辑，每天早上 agent 就已经为你准备好了当天的上下文。

最近，海外开发者圈子里疯传一个项目——上线仅四天就在GitHub上收割了5万颗星，涨势凶猛得让人想起年初那款席卷全网的现象级工具。

夸张，却真实。

这个项目叫 Odysseus，背后的作者既不是传统人工智能公司，也不是哪家大厂的实验室，而是那个粉丝量级破亿的网红 PewDiePie。

起初，我以为它不过又是一个本地版的ChatGPT。毕竟现在这类项目满地都是，把大模型接过来，套层聊天界面，就推给用户。

然而真正跑起来之后，我才发现它最有意思的地方根本不在对话本身。

它更像是一间运行在你电脑里的AI工作室，或者说，是一个高度个人化的AI操作系统的早期形态。

换个角度去看，甚至可以把这里理解为AI Agent进化的第二条路径。

它把「本地部署大模型」这件事的门槛，压低了整整一个数量级。

怎么理解这一点呢？

太多人并不是不想运行本地模型，而是在第一步就被劝退了。

打开 Hugging Face，迎面而来的是 7B、8B、14B、32B、70B 这样的模型代号；再往下翻，又冒出 GGUF、Q4、Q5、FP8、AWQ 等一系列术语。你还得搞清自己显卡的显存大小、内存够不够用、该选 Ollama 还是 llama.cpp、是否要上 vLLM，模型下载完后该怎么部署，部署好之后又如何接入聊天界面……

明明只是想在自己的电脑上跑一个AI模型，结果还没触碰到真正的功能，就先被一堆黑话暴击了一遍。

Odysseus 最关键的地方，就扎在了这里。

它内建了一个名为 Cookbook 的功能模块，会先对你的硬件环境做一次扫描，看清你的CPU、内存、显卡、显存大概处于什么层级，然后主动推荐适合这台机器安装的模型。

也就是说，它并不指望用户自己去揣测「我的电脑到底跑不跑得动8B」。它先替你过滤一遍：哪些模型比较契合你的配置，哪些模型可能太大拖不动，哪些版本更适合在本地部署。

接下来，你可以直接从Hugging Face 拉取模型，把它们下载到本地，再一键部署起来。

这个环节尤为关键。

因为在以前，本地模型最难的，从来不是「有没有模型」，而是「很多人根本弄不清自己到底能用哪个模型」。看到密密麻麻的参数就退缩的人比比皆是。但Odysseus想要实现的，正是把模型选择、下载、部署和调用这整条链路，都收纳进同一个工作台。

所以，这不单单是递给你一个聊天框，而是先为你推倒本地AI面前最高的那堵墙：你的电脑到底能跑什么。

当然，它也并不只服务于本地模型。

你同样可以接入 OpenAI、OpenRouter、Deepseek 这类云端 API。也就是说，轻量的、涉及隐私的任务，你可以尽量放在本地处理；遇到复杂的、需要更强模型的任务，随时切到云端大模型。

这才触达了它真正的精彩之处：并不是让用户在本地和云端之间做二选一的单选题，而是给你一个统一的AI工作台，由你自己来决定，什么数据留在本地，什么需求交给云端。

看到这一步，肯定有人立刻会问：那为什么不直接用 Codex？

这个问题得讲清楚。

如今的Codex已经进化成龙虾的升级版（注：此处指年初的某爆款项目），它所具备的 Computer use 能力已经能完成大量操作——看屏幕、点按钮、输入文字、调动你电脑上的各类应用。让它打开软件、检查网页、复现界面上的问题，几乎都能通过Computer use来搞定。

所以，如果你只是想要一个强大无比的AI操作员，Codex 当然非常强大。

但 Odysseus 和 Codex 本就是两个完全不同的事物。

Codex 更像是 OpenAI 提供的一位高级AI执行代理。它的强项在于模型能力、任务执行、代码理解、桌面操作和自动化。你把一个目标扔给它，它就能为你完成。

而 Odysseus 更像是一个构筑在你本地的AI中控台。它的关注点不在于能不能替你点鼠标，而是你的模型、你的数据、你的文档、你的记忆、你的工具，是否能尽量保留在你自己的环境里。

这恰恰是两者最根本的区别。

眼下上网最让人头疼的未必是带宽不够，而是无处不在的广告和追踪探针。网页刚打开，广告位抢先渲染；点开一个 App，后台就冒出一连串数据上报请求；家中的手机、电脑、平板乃至电视盒子，都可能在你不经意间悄悄访问各类统计、跟踪和广告域名。

这次我们就在 NAS 上搭建一个“广告橡皮擦”——Pi-hole，把冲浪体验变得干净利落。

同类方案中，AdGuard Home 和 OxiDNS 也很出色，界面更现代，部署同样便捷，完全可以根据个人偏好选择。

Pi-hole 简介

项目在 GitHub 上的完整名称是 pi-hole/docker-pi-hole，搜索即可找到。

Pi-hole 是一款开源的网络级广告拦截工具，并非浏览器扩展或手机应用，而是一个部署在局域网内的 DNS 过滤服务。只要把终端设备的 DNS 指向 Pi-hole，从理论上说，局域网内所有设备都能享受到过滤效果。

其工作逻辑大致如下：

很多人可能会首先想到：这类 DNS 服务是否最好直接装到路由器里？其实，部署在路由器上并非必需。假如你的路由器性能足够、系统开放且支持 Docker，那么放在路由器里当然顺畅。但现实是，大量家用路由器并不具备这些条件。Pi-hole 的资源消耗很低，在 NAS 上运行后，只需让全屋设备将 DNS 指向这台 NAS 上运行的 Pi-hole，所有设备就都能一道受益。

当然，NAS 需要保持 24 小时开机，以确保服务始终在线。

核心特点

• 一次部署，全家受益：只要在路由器上将 DNS 指向 Pi-hole，局域网内所有设备就会统一通过它解析，无需在每台终端上单独设置。
• 新设备“零”配置：部署完成后，只需在路由器的 DHCP 设置中把 DNS 改为 Pi-hole 的 IP，此后新连上 Wi-Fi 的设备都会自动使用该 DNS。
• 图形化管理面板：自带 Web 管理界面，可直观查看拦截记录、每台设备的请求数量、拦截频率等信息。
• Docker 化部署：官方提供 Docker 镜像，部署灵活、资源开销小。

上手部署

本文以威联通 NAS 为例，采用 Docker Compose 方式进行部署。下面给出完整配置，你可以根据自己的环境适当裁剪：

Redis 在分布式锁、限流等场景中的应用大家已经聊得很多了。
今天聚焦另一个高频使用场景——「分布式缓存」，并结合用户登录模块来深入拆解实现细节。

假设公司有一款日活百万的 App，用户登录成功后获得一个 token，后续所有 HTTP 接口访问都需在请求头中携带该 token。
业界标准方案非常简单：登录成功后，直接将用户状态（Token + 核心信息）整体写入 Redis。后续每个请求带着 Token 进来，服务端直接查 Redis 进行校验，毫秒级响应，既快又稳。

✿一、具体业务流程

1. 发放令牌：用户输入账号密码登录成功，服务端现场生成唯一 Token。
2. 写入 Redis：将 Token 和对应的用户关键信息存入 Redis，并设置过期时间（此处采用 7 天）。
3. 客户端保管：Token 返回给 App，App 自行存储本地（如 LocalStorage 等）。
4. 携带令牌访问：App 所有后续接口请求，均在 Header 中带上该 Token。
5. 拦截器校验：服务端拦截器获取 Token 后直接查询 Redis。查到则放行，查不到直接返回 401。

✿二、核心代码

技术栈采用 Spring Boot + RedisTemplate。为直观展示，Token 使用 UUID 生成。
实际项目中也可选择 JWT，但注销逻辑仍需借助 Redis 黑名单，各方案都有各自的取舍。

1、登录成功后生成 Token 并写入缓存

import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Service;
import javax.annotation.Resource;
import java.util.UUID;
import java.util.concurrent.TimeUnit;

/**
 * 认证服务 - 负责发放"通行证"
 */
@Service
public class AuthService {

    @Resource
    private RedisTemplate<String, Object> redisTemplate;

    @Resource
    private UserService userService;

    public LoginResult login(String phone, String password) {
        // 1. 校验用户身份
        User user = userService.findByPhone(phone);
        if (user == null) {
            throw new RuntimeException("用户不存在");
        }

        // 密码必须使用 BCrypt 算法比对，切忌明文存储或自行编写加密逻辑，这是血的教训
        if (!user.getPassword().equals(encryptPassword(password))) {
            throw new RuntimeException("密码错误");
        }

        // 2. 生成 Token，添加 APP_ 前缀便于运维在 Redis 中快速识别
        String token = "APP_" + UUID.randomUUID().toString().replace("-", "");

        // 3. 构建缓存对象，仅存储最核心信息，越轻量越好
        LoginCacheUser cacheUser = new LoginCacheUser();
        cacheUser.setUserId(user.getId());
        cacheUser.setPhone(user.getPhone());
        cacheUser.setNickname(user.getNickname());

        // 4. 写入 Redis，Key 命名需规范，便于后续清理与管理
        // 格式：app:login:token:{token}，有效期 90 天，具体天数可配置到 Apollo
        String redisKey = "app:login:token:" + token;
        redisTemplate.opsForValue().set(redisKey, cacheUser, 90, TimeUnit.DAYS);

        // 5. 返回给前端
        LoginResult result = new LoginResult();
        result.setToken(token);
        result.setUserInfo(new UserVo(user));
        return result;
    }
}

2、拦截器逻辑

App 端发起请求时，会在 Header 中携带 Token，例如：X-Auth-Token: APP_xxxxxxx。

一、短信限流背景

在企业业务中，许多场景都依赖短信发送。例如，用户注册或登录流程中，短信验证码是确保安全验证的核心环节。因此，涉及企业成本的关键环节必须全面考虑异常情况，否则可能造成严重经济损失。

短信服务成本较高，必须实施限流措施，防止恶意刷量：

1. 恶意攻击者利用脚本高频调用短信接口，导致短信费用急剧上涨。
2. 业务安全风险：验证码可能被暴力破解，威胁用户账号安全。
3. 服务资源过度消耗：大量无效请求会快速耗尽系统资源。

曾有一家电商平台在上线初期就遭遇此类攻击，当日短信费用飙升至正常水平的10倍以上。

二、核心代码实现

1. 限流配置类

@Component
@ConfigurationProperties(prefix = "sms.rate-limit")
@Data
public class RateLimitConfig {
    // 手机号频率限制：60秒内仅1次
    private long phoneInterval = 60;
    private int phoneMaxAttempts = 1;

    // IP总量限制：24小时内不超过100次
    private long ipInterval = 24 * 60 * 60;
    private int ipMaxAttempts = 100;
}

2. Redis限流服务

整个Service可直接复用，通用性强。

@Service
@Slf4j
public class SmsRateLimitService {

    @Autowired
    private RedisTemplate<String, Object> redisTemplate;

    @Autowired
    private RateLimitConfig rateLimitConfig;

    private static final String PHONE_PREFIX = "sms:phone:";
    private static final String IP_PREFIX = "sms:ip:";
    private static final String GLOBAL_KEY = "sms:global";

    /**
     * 检查是否允许发送短信
     */
    public RateLimitResult checkRateLimit(String phoneNumber, String clientIp) {
        RateLimitResult result = new RateLimitResult();

        // 检查手机号频率限制
        if (!checkPhoneLimit(phoneNumber)) {
            result.setAllowed(false);
            result.setMessage("操作过于频繁，请60秒后再试");
            return result;
        }

        // 检查IP总量限制
        if (!checkIpLimit(clientIp)) {
            result.setAllowed(false);
            result.setMessage("今日发送次数已达上限");
            return result;
        }

        result.setAllowed(true);
        return result;
    }

    /**
     * 手机号频率限流检查
     */
    private boolean checkPhoneLimit(String phoneNumber) {
        String key = PHONE_PREFIX + phoneNumber;
        return checkAndIncrement(key, rateLimitConfig.getPhoneInterval(),
                               rateLimitConfig.getPhoneMaxAttempts());
    }

    /**
     * IP总量限流检查
     */
    private boolean checkIpLimit(String clientIp) {
        String key = IP_PREFIX + clientIp;
        return checkAndIncrement(key, rateLimitConfig.getIpInterval(),
                               rateLimitConfig.getIpMaxAttempts());
    }

    /**
     * 通用的Redis限流检查方法
     * 使用Lua脚本保证原子性操作，避免并发问题
     *
     * @param key Redis键
     * @param interval 时间间隔（秒），在此时间窗口内进行限流计数
     * @param maxAttempts 最大允许尝试次数，超过次数则触发限流
     */
    private boolean checkAndIncrement(String key, long interval, int maxAttempts) {
        try {
            // 采用Lua脚本确保原子性
            String luaScript =
                "local current = redis.call('get', KEYS[1]) " +
                "if current and tonumber(current) >= tonumber(ARGV[1]) then " +
                "    return 0 " +
                "else " +
                "    redis.call('incr', KEYS[1]) " +
                "    if tonumber(current) == 0 then " +
                "        redis.call('expire', KEYS[1], ARGV[2]) " +
                "    end " +
                "    return 1 " +
                "end";

            RedisScript<Long> script = RedisScript.of(luaScript, Long.class);
            Long result = redisTemplate.execute(script,
                Collections.singletonList(key),
                maxAttempts, interval);

            return result != null && result == 1;
        } catch (Exception e) {
            log.error("Redis限流检查异常, key: {}", key, e);
            // Redis异常时，为保障主流程可用，默认放行
            return true;
        }
    }

}

3. 业务服务层

@Service
@Slf4j
public class SmsService {

    @Autowired
    private SmsRateLimitService rateLimitService;

    @Autowired
    private SmsProvider smsProvider;

    /**
     * 发送短信验证码
     */
    public SendSmsResult sendVerificationCode(String phoneNumber, String clientIp) {
        // 1. 限流检查
        RateLimitResult limitResult = rateLimitService.checkRateLimit(phoneNumber, clientIp);
        if (!limitResult.isAllowed()) {
            log.warn("短信发送被限流, phone: {}, ip: {}, reason: {}",
                    phoneNumber, clientIp, limitResult.getMessage());
            return SendSmsResult.fail(limitResult.getMessage());
        }

        // 2. 生成验证码
        String verificationCode = generateVerificationCode();

        try {
            // 3. 调用短信服务商API
            boolean sendResult = smsProvider.sendSms(phoneNumber,
                "您的验证码是：" + verificationCode + "，5分钟内有效");

           // 其他业务操作
        } catch (Exception e) {
            log.error("短信发送异常, phone: {}", phoneNumber, e);
            return SendSmsResult.fail("系统异常，请稍后重试");
        }
    }

    private String generateVerificationCode() {
        // 生成6位随机数字验证码
        Random random = new Random();
        return String.format("%06d", random.nextInt(1000000));
    }

    private void saveVerificationCode(String phoneNumber, String code) {
        String key = "sms:code:" + phoneNumber;
        redisTemplate.opsForValue().set(key, code, 5, TimeUnit.MINUTES);
    }
}

该方案已在多个生产环境稳定运行，日均处理百万级短信发送请求，有力保障了系统的稳定与安全。

Java 开发者长期受困于效率低下的编程工具——将 Spring Boot 与 OpenCode 结合，开发效率可以获得质的飞跃。在阅读完前 9 篇教程后，你已经全面掌握了 OpenCode 的功能。现在，让我们用一个完整的 Spring Boot 微服务项目，把所有知识串联起来——从项目初始化到 Docker 容器化部署，全程使用 OpenCode 辅助完成。

本章目标

我们将使用 OpenCode 构建一个用户订单管理微服务，包含以下技术栈：Spring Boot 3.3 + JDK 17，JPA 数据持久化（MySQL），RESTful API（CRUD + 分页查询），JWT 认证与权限控制，全局异常处理，以及 Docker 容器化部署。在整个过程中，你会看到如何逐步向 OpenCode 下达指令，并观察它如何辅助完成工作。

一、项目初始化

1.1 创建项目结构

在终端打开工作目录并启动 OpenCode，然后发出指令：

你：请帮我创建一个 Spring Boot 3.3 微服务项目，项目名为 user-order-service，采用 JDK 17 和 Maven 构建。要求生成标准的包结构，包含 controller、service、repository、model、dto、config、security 七个包。

OpenCode 随即生成如下目录结构：

user-order-service/
├── pom.xml
├── src/
│   └── main/
│       ├── java/com/example/userorderservice/
│       │   ├── controller/
│       │   ├── service/
│       │   ├── repository/
│       │   ├── model/
│       │   ├── dto/
│       │   ├── config/
│       │   └── security/
│       └── resources/
│           └── application.yml

1.2 /init 生成 AGENTS.md

你：请运行 /init 为项目生成 AGENTS.md

OpenCode 会分析项目结构并生成 AGENTS.md：

借助 Claude Code 或 Cursor 写代码，效率确实高到飞起。但真正深入用过一阵子的人，大概率都撞上过同一个痛点：Token 烧得飞快。尤其在中大型项目里，随口问一句“这个登录流程怎么串联起来的”，AI 就会翻遍整个仓库，反复读取几十个文件，一轮查询就能烧掉六位数 Token。

月末打开 API 账单的那一刻，心情可谓五味杂陈。

最近，我在 GitHub 上发现了开源项目 CodeGraph，上线没几天就冲进 Trending 榜，Star 数一路暴涨。

它的定位非常直接：为代码库构建一张知识图谱，让 AI 编程工具不再靠蛮力翻找文件，而是像翻字典一样精准定位。

原理并不难理解。

过去问 AI 一个架构问题，它得先全局搜索关键词，然后依次打开相关文件读完，再判断哪个是入口、哪些是被调用的辅助函数。一套流程走下来，可能动辄几十步。

引入 CodeGraph 之后，AI 直接查询图谱，一次性拿到完整的调用链和符号关系。几十步被压缩到一两步，Token 自然省下来了。

官方在 7 个真实开源项目上，用 Claude Opus 4.7 做了对比测试，每个问题跑 4 次取中位数。

结果相当可观：平均费用降低 35%，Token 消耗减少 59%，响应速度提升 49%，工具调用次数锐减 70%。

具体到某些项目上，差异更为惊人。比如在 VS Code 这种拥有上万文件的项目中，Token 直接减少 73%；而在 Tokio（Rust 异步运行时）上，费用节省了 52%。

这组数据是借助 claude -p 进行无头测试得出的，WITH 和 WITHOUT 两个对照组使用相同的问题、相同的代码，模型自带的 Read/Grep/Bash 能力全部保留，唯一的变量就是是否开启 CodeGraph 的 MCP 服务器。