Category: 实用教程

  • 这个东西我不太想说,但它真的能解决我的 API token 焦虑

    最近习惯 vibe coding 的盆友肯定会有这样的焦虑,不管是用 CC、OpenCode等coding agent,还是养龙虾:

    💸 API 额度烧得太快了,快到有点离谱

    尤其是这种场景:

    • 长对话 Agent(多轮上下文)
    • tool calling
    • prompt 调优 + debug
    • 类似“龙虾对话”这种长上下文聊天

    基本状态就是:

    一边跑 demo,一边看 token 余额心跳加速


    然后最近我发现一个比较“野”的方案:

    直接把 Gemini 的 Web 对话包一层,变成 OpenAI API 来用

    仓库在这:

    👉 https://github.com/Sophomoresty/gemini-web2api


    ⚙️ 它是怎么工作的(很简单)

    本质就一句话:

    用 Gemini 网页版 + cookie 登录 → 模拟请求 → 转 OpenAI API

    正常你写代码的 agent 调用的还是 OpenAI 那套,但底层模型其实换成了 Gemini Web。


    🚀 怎么部署(直接上手)

    1️⃣ 启动服务

    git clone https://github.com/Sophomoresty/gemini-web2api
    cd gemini-web2api
    python gemini_web2api.py

    Base URL默认地址:

    http://localhost:8081/v1

    2️⃣ OpenAI SDK 调用

    from openai import OpenAI
    
    client = OpenAI(
        base_url="http://localhost:8081/v1",
        api_key="sk-anything"
    )
    
    resp = client.chat.completions.create(
        model="gemini-3.5-flash",
        messages=[
            {"role": "user", "content": "写一个贪吃蛇游戏"}
        ]
    )
    
    print(resp.choices[0].message.content)

    3️⃣ curl 测试

    看能不能正常返回,有返回说明部署成功了

    curl http://localhost:8081/v1/chat/completions \
      -H "Content-Type: application/json" \
      -H "Authorization: Bearer sk-your-key" \
      -d '{"model":"gemini-3.5-flash","messages":[{"role":"user","content":"Hello!"}]}'

    4️⃣ 配置文件

    可以参考 config.example.json,创一个config.json文件,可对这些参数做修改

    field value
    Base URL http://localhost:8081/v1
    API Key 随便自己创
    Model gemini默认模型

    🍪 gemini-3.1-pro:Cookie 怎么拿(核心步骤)

    要稳定跑 gemini-3.1-pro 的话,就需要靠 cookie。

    1️⃣ 登录 Gemini

    打开:

    👉 https://gemini.google.com

    用 Google 账号登录(前提需要有pro订阅)


    2️⃣ 打开开发者工具

    F12 → Application → Cookies:

    https://gemini.google.com

    3️⃣ 复制这些字段

    重点:

    • SID
    • HSID
    • SSID
    • APISID
    • SAPISID
    • __Secure-1PSID

    4️⃣ 写成 cookie.txt

    创建一个cookie.txt文件,按下面填空即可

    SID=xxx; HSID=xxx; SSID=xxx; APISID=xxx; SAPISID=xxx; __Secure-1PSID=xxx

    5️⃣ 启动时加载

    python gemini_web2api.py --cookie-file cookie.txt

    ⚠️ 需要注意的点

    这个方案本质是 Web 层模拟,所以:

    • ❌ 不稳定(Google 改页面可能直接失效)
    • ❌ gemini-3.1-pro 模型依赖 cookie
    • ❌ 有风控 / 限流
    • ❌ 不适合生产级依赖

    但它的定位也很清晰:

    👉 本地开发 / Agent 实验非常合适


    🧠 我自己的使用方式

    现在基本是这样用的, picoclaw 机器上跑这个服务,整体体验是“飞起”的, coding agent替换base url跟api无脑蹬:

    直接随便跑,不心疼 token


    🚀 最后说一句

    账号被封得不偿失,目前自己用用还算安全的。所以虽然可以但不建议去做中转。

  • 快速上手百度Apollo开发的一点经验之谈

    本文

    主要面向由ROS快速转向CyberRT框架的开发者,是一份QuickStart手册。因为是从ROS出发,所以需要读者具备一定的ROS基础。

    预备知识

    1. Linux
    2. ROS
    3. C++

    简而言之,会Linux命令行操作,熟悉ROS框架,了解基本C++类对象语法。

    CyberRT v.s. ROS

    CyberRT是参考ROS开发的,所以将他们联系起来看,会比较好地理解和上手apollo的开发。

    基本概念

    首先我们来看下两者在开发相关的一些主要概念上的异同。

    CyberRT ROS Description
    component package 组件/包,都是构建项目的最小单元
    node node 节点,一个组件/包里可包含多个节点
    channel topic 通道/话题名,用于节点间通信,一个节点可包含多个通道/话题
    message message 消息名,定义了数据传输的格式,一个通道/话题对应一种消息
    Reader/Writer Subscriber/Publisher 读写器/发布订阅器,都是实现节点通信的具体接口

    另外 Services 与 Parameters 等概念也类似,因为Service/Client通信模型用的少就不赘述了。

    工程目录

    了解以上概念后,现在我们从两者的工程目录来看,就比较清晰了。

    CyberRT ROS Description
    conf config 配置文件
    dag/launch launch 启动文件
    proto msg 消息文件
    nodes 源码文件
    BUILD CMakeLists.txt 编译文件
    test* test 测试文件

    注: 其中是CyberRT一个组件目录中一些具体节点名,ROS中把他们都放在一个目录nodes里了

    熟悉ROS的朋友可以很明显看出两者其实非常类似,差异主要有这两点:

    1. Apollo引入了google的protobuf取代了ROS原有的msg消息定义
    2. Apollo采用Bazel编译工具来管理C++依赖环境,而不是Cmake

    所以从一个ROS开发者切换到CyberRT下,需要简单了解下google的gflags、glog、gtest以及protobuf用法,还有就是Bazel的基本语法,为此我在本文最后梳理了一份参考资料供大家阅读。

    开发工具

    最后在开发工具上,Apollo其实也准备了许多ROS中比较常用的工具。因为开发必然会用到,所以我也简单提下。

    CyberRT ROS Description
    cyber_visualizer Rviz 用于消息的可视化
    cyber_monitor rostopic/rqt 查看实时消息数据
    cyber_recorder rosbag 录制/回放消息数据

    参考资料

    1. 官方关于CyberRT的README,其中 ‘Quickstart’、 ‘API’ 与 ‘DeveloperTools’ 这三个是必看,也最好跟着做下,可以很快的了解CyberRT框架。
    2. google关于protobuf的Guide,其中’Defining A Message Type’这段内容是必读的,其他消息嵌套等用法可以等用到了再来查阅。

      另外我们可以结合apollo开放平台文档里的’数据格式’那栏内容来加深我们对Apollo消息格式的理解。
    3. 关于gflags的简介,这篇说明是比较简俗的,内容不多可以看完。
    4. 关于glog的简介 ,可以先简单浏览下。日志输出在后期调试还是比较重要的,完整的说明到时用到了,可在google的github仓库里找到glog的README细看。
    5. gtest的入门手册,其中’Googletest Primer’必看,其他内容可到时再查。
  • Autoware调试心得-astar_avoid的避障实现

    简介

    网上有关 astar_avoid 模块的源码分析挺多的,我这里就不对它用到的 AStar 算法做过多赘述了。不过知道它的实现原理跟实际调试还是存在很大出入,因为 AStar 算法在实际应用时需要跟Autoware的其他模块所结合,为此了解其实际避障逻辑尤为重要,这也是本文的由来。

    准备工作

    1. 实车或仿真环境
    2. 已部署成功 Autoware
    3. 一个可被检测到的障碍物

    避障逻辑

    因为我看到 astar_avoid 模块里的源码用到了有限状态机(Finite State Machine)来应对各种可能遇到的环境,所以我就以期望的避障状态出发绘制了下面两张时序图。

    成功避障

    下图是我们最期望看到的,一次成功的避障会经历的各个状态的切换过程。
    [wppa type=”photo” photo=”86″]

    没有避障

    而实际调试中没有避障成功的话,那就大概率是卡在下图的某一环节里了。
    [wppa type=”photo” photo=”87″]

    这两图放一起应该很清晰就能认识 astar_avoid 模块的避障逻辑了。