企业官网建设流程全解析

最近社区里这一轮 AI 工具链折腾，比之前几轮要实用不少。模型端有 DeepSeek-V4-Flash 这样主打快速响应的 API 服务，入口端有 Antigravity CLI 这类直接把代码任务交给智能体的命令行工具，设备端还有 oh my pi 这种面向树莓派的配置管理工具。很多人已经不再满足于单独玩某一个模型，而是把“终端入口 + 模型 API + 设备管理”串成一条完整链路。这篇文章就围绕这四个关键词，整理一份能直接照着做的联调操作笔记。

这里主要解决两件事。第一，把 DeepSeek-V4-Flash 接入 Antigravity CLI 这类工具时，哪些配置必须一次配对，尤其是模型名和 thinking mode 的处理。第二，一个非常典型的 400 报错——“thinking mode 下 reasoning_content 必须回传给 API”，到底是怎么产生的、怎么定位、怎么修复。除此之外，文章还会覆盖多模型切换、批量任务、树莓派设备管理和常见问题排查。

如果你平时主要在终端里写代码，想把 DeepSeek、GLM、GPT 这类模型统一接进一套 CLI 工作流，或者手里有一台树莓派和一堆自动化脚本要管理，这篇可以直接收藏照着做。前期的原则只有一条：先用最小请求验证，再放大到批量任务，不要一上来就做复杂的参数调试。

1. 这套 AI 工具链组合是干什么的

先说整体结构。这套组合不是一个单一项目，而是四个独立组件拼出来的工作流：

• Antigravity CLI是任务入口，负责接收你的自然语言指令，拆解成可执行的代码任务，然后调用后端模型。
• DeepSeek-V4-Flash是代码任务的主力模型，主打快速响应和低成本，适合补全、解释、生成单元测试、批量小任务。
• GPT-5.6 Luna做对照验证，在同一个 CLI 里切换到 Luna 模型，可以对比同一批任务在不同模型下的输出质量。
• oh my pi负责设备侧，从命名看大概率是面向树莓派的环境配置和部署工具，用来把写好的脚本发布到边缘设备上。

四个组件串起来之后，链路大致是这样：在电脑终端里向 Antigravity CLI 下指令，CLI 把请求转发到模型 API，拿到结果后写入项目代码，最后由 oh my pi 把代码或脚本部署到树莓派。整条链路看起来很顺，但实际调试时，问题往往出在“中间这一层协议转换”上。

CLI 工具说话的方式和模型服务商 API 的格式不一定完全一致。比如 Codex 协议里有/responses端点，而 DeepSeek 兼容接口可能同时提供/responses和/chat/completions两类端点。中间一旦字段对应不上，就会出现 400、模型不存在、或者 reasoning_content 必须回传这类报错。

下表是四个组件的定位速览：

这套组合真正值得深入研究的，不是单个模型的提示词技巧，而是 API 兼容层和异常处理。这也是下文会花最多篇幅的地方。

2. 核心能力速览与适用边界

在动手之前，先用一张表把能力边界理清楚，避免期望值放得太高。

从实际使用角度看，这个组合适合三类人。

第一类是重度终端用户。你平时用 Copilot、Codex、Cursor 这类工具，现在想换到开箱即用的 CLI 工作流，并且希望同一个工具里能切换 DeepSeek、GLM、GPT 多个模型。第二类是自动化脚本爱好者。你想每天批量跑一批代码审查、生成单元测试、补注释，然后把结果保存成结构化文件，这套链路可以做到。第三类是树莓派玩家。你在树莓派上跑着若干服务，需要一个命令行工具统一管理初始化、依赖安装和部署脚本。

不适合什么场景也要说清楚。如果你需要的是图形界面、可视化调试、别人已经把工作流封装好的“一键产物”，这套东西对你来说门槛偏高。它更适合愿意看日志、愿意改配置的开发者。另外，如果本身没有树莓派，也没有边缘设备管理需求，oh my pi 这部分可以先跳过，不影响前面模型接入的学习。

使用边界方面，有几个硬性提醒：所有模型 API 的调用都要在合法授权范围内进行；密钥不要硬编码进仓库；涉及人脸、声音、版权素材的生成任务，必须确认授权；批量任务不要对第三方服务造成超限压力，建议设置合理的并发和重试策略。

3. 环境准备与前置条件

开始之前，先把环境检查一遍。这里给一份通用清单，具体版本以你使用的工具仓库要求为准。

3.1 操作系统与基础环境

• Linux 或 macOS 作为主力环境，Windows 用户可以开 WSL。
• Python 3.10 以上，用于跑 API 调用脚本。
• Node.js 18 以上，部分 CLI 工具依赖 npm 安装。
• Git，用于拉取配置模板或管理脚本。
• 一个能访问模型 API 的网络环境，需要能正常连接到你配置的 API 端点。

所有工具统一遵循一个原则：先确认本机已经装好了依赖，再执行安装命令。很多排查到最后都发现，不是配置写错，而是 Node 版本太低或者 Python 环境没激活。

3.2 API 密钥与端点信息

需要准备好以下信息，建议直接写进环境变量：

export DEEPSEEK_API_KEY="你的密钥" export DEEPSEEK_BASE_URL="https://api.example.com/v1" export OPENAI_API_KEY="你的密钥"

这里有两个容易忽视的点。第一，不同供应商的密钥要分开管理，不要混用。第二，base_url 必须和模型名配套，某些端点只支持deepseek-v4-pro和deepseek-v4-flash两个模型名，换一个端点可能就不认了。

3.3 树莓派前置条件

如果要用 oh my pi 管理树莓派，额外准备：

• 树莓派能通过 SSH 访问，本机和树莓派在同一网络或已经配置好内网穿透。
• 树莓派上已经烧录好系统镜像，能正常启动。
• 记录当前用户、IP、端口信息，部署脚本需要用到。

一个合理的检查顺序是：先在本机跑通 API 最小请求，再配置 CLI 工具，最后再尝试把脚本部署到树莓派。如果顺序反过来，容易把 API 问题和设备问题混在一起，排错效率很低。

4. Antigravity CLI 安装与模型供应商配置

4.1 安装 CLI

Antigravity CLI 这类工具通常有三种安装方式：npm 全局安装、Homebrew 安装、官方安装脚本。具体选哪种，以项目 README 为准。下面给出的是通用模板，需要把工具名替换成你实际使用的包名：

# 方式一：npm 全局安装 npm install -g @antigravity/cli # 方式二：Homebrew 安装（macOS / Linux） brew install antigravity # 方式三：官方安装脚本，执行前先检查脚本内容 curl -fsSL https://example.com/install.sh | bash

第三种方式风险较高，建议先把脚本下载下来，确认内容没问题再执行，或者直接用包管理器安装。

4.2 配置模型供应商

安装完成之后，核心工作是把 DeepSeek-V4-Flash 配置成默认模型。配置文件通常长这样，字段名以你的 CLI 实际版本为准：

# antigravity 配置示意，字段名请按实际版本调整 model_providers: deepseek: base_url: "https://api.example.com/v1" api_key_env: "DEEPSEEK_API_KEY" default_model: "deepseek-v4-flash" supported_models: - "deepseek-v4-pro" - "deepseek-v4-flash" openai: base_url: "https://api.example.com/v1" api_key_env: "OPENAI_API_KEY" default_model: "gpt-5.6-luna"

配置完成之后，先别急着跑复杂任务。执行一条最简单的命令验证 CLI 能不能正常唤起模型，例如让 CLI 解释一段三行代码。如果这一步失败，后续所有工作都会被阻塞。

从这里开始，你会频繁看到下面两类问题：一类是模型名写错，比如把deepseek-v4-flash写成了deepseek-v4-flash带空格，或者写成deepseek-v4-Flash大小写不对；另一类是协议字段不匹配，CLI 发出的请求体和模型服务商要求的格式不一致。

判断配置是否成功的标准很简单：CLI 能收到模型返回的文本，日志里没有 400、401、404 等错误码。如果还是报错，优先检查环境变量有没有加载、base_url 有没有写对、模型名是否在支持列表里。

5. DeepSeek-V4-Flash API 调用验证与 thinking mode 排错

这一节是全文的核心。DeepSeek-V4-Flash 这类模型本身并不难调用，难点在 thinking mode 下的多轮交互。先用最小请求验证基础能力，再延伸到多轮请求和错误修复。

5.1 最小 API 调用示例

先写一个最简单的 Python 请求，验证密钥和模型名是否可用：

import os import requests api_key = os.environ["DEEPSEEK_API_KEY"] base_url = os.environ.get("DEEPSEEK_BASE_URL", "https://api.example.com/v1") resp = requests.post( f"{base_url}/responses", headers={"Authorization": f"Bearer {api_key}"}, json={ "model": "deepseek-v4-flash", "input": "用 Python 写一个快速排序", }, timeout=120, ) print(resp.status_code) print(resp.json())

这里用/responses端点，是因为 Codex 和 Antigravity 这类工具走的是 Responses 协议。如果你接的是 Chat Completions 协议，把路径换成/chat/completions，请求体里用messages数组，效果是一样的。

这段代码能正常返回 200，说明密钥、base_url、模型名三个核心配置都是对的。如果返回 400，接下来就要进入排错环节。

5.2 经典 400 报错：reasoning_content 必须回传

社区里传播度很广的一条报错日志长这样：

cc switch local proxy failed while handling codex endpoint /responses. provider: deepseek; model: deepseek-v4-flash; upstream_status: http 400; cause: the `reasoning_content` in the thinking mode must be passed back to the api.

逐段拆解一下。

问题本质出在多轮对话。模型开启了 thinking mode 后，第一轮返回除了正常答案文本，还会附带一份思考过程内容，也就是reasoning_content。到了第二轮请求，模型服务要求你把这部分内容一并提交上去，否则它会认为上下文不完整，直接返回 400。

5.3 正确的多轮请求体

修复方案就一句话：把多轮消息全部保留，并且把上一轮响应里的reasoning_content原样带回。请求体格式大致如下，具体字段名以 API 文档为准：

{ "model": "deepseek-v4-flash", "thinking": { "type": "enabled" }, "input": [ { "role": "user", "content": "用 Python 写一个快速排序" }, { "role": "assistant", "content": "下面是快速排序实现，核心思路是选基准元素，递归划分左右区间。", "reasoning_content": "用户需要快速排序，我先给出基础实现，再解释时间复杂度和边界条件。" }, { "role": "user", "content": "改成降序" } ] }

写成 Python 代码是这样：

import os import requests api_key = os.environ["DEEPSEEK_API_KEY"] base_url = os.environ.get("DEEPSEEK_BASE_URL", "https://api.example.com/v1") model = "deepseek-v4-flash" messages = [ {"role": "user", "content": "用 Python 写一个快速排序"} ] resp = requests.post( f"{base_url}/responses", headers={"Authorization": f"Bearer {api_key}"}, json={"model": model, "input": messages}, timeout=120, ) data = resp.json() print("第一轮状态码:", resp.status_code) # 判断返回结构里是否包含 reasoning_content，保存下来下一轮原样传回 assistant_msg = { "role": "assistant", "content": data.get("output_text", ""), } if "reasoning_content" in data: assistant_msg["reasoning_content"] = data["reasoning_content"] messages.append(assistant_msg) messages.append({"role": "user", "content": "改成降序"}) resp2 = requests.post( f"{base_url}/responses", headers={"Authorization": f"Bearer {api_key}"}, json={"model": model, "input": messages}, timeout=120, ) print("第二轮状态码:", resp2.status_code) print(resp2.json())

判断成功的标准：第一轮返回 200，第二轮继续返回 200，且第二次输出正确实现了降序排序。如果第二轮带上了reasoning_content还是报同样的 400，说明你的协议字段名和服务端不匹配，需要查 API 文档确认reasoning_content是放在消息体顶层还是消息对象内部。另外，如果你用的是本地请求转发层，比如自定义的网关服务，还要检查网关是否把reasoning_content字段完整透传，很多转发层会自作主张丢弃未知字段，正好把这部分内容丢掉。

6. 多模型切换与批量任务接入

6.1 同一套 CLI 里切换模型

模型接入验证通过之后，下一步就是多模型切换。Antigravity CLI 这类工具一般允许你在配置里定义多个 provider，然后在运行时通过参数指定模型。

# 使用 DeepSeek-V4-Flash antigravity run --provider deepseek --model deepseek-v4-flash "解释这段代码" # 使用 GPT-5.6 Luna 做对照 antigravity run --provider openai --model gpt-5.6-luna "解释这段代码" # 如果配置了 GLM antigravity run --provider zhipu --model glm-5.2 "解释这段代码"

切换模型不只是换个名字。每个模型的上下文长度、输出格式、是否支持 thinking mode 都可能不一样。建议把常用的几组模型参数固化到配置文件里，避免每次启动都手写一长串参数。

6.2 DeepSeek-V4-Flash、GPT-5.6 Luna 和 GLM 5.2 写代码怎么选

社区里经常有人问“deepseek-v4-flash 和 glm5.2 写代码推荐哪个”。这个问题没有标准答案，因为选型取决于你的任务形态。这里给一个可操作的判断思路：

• 高频、轻量的代码任务，比如补全、加注释、生成单测、批量解释代码，优先选 DeepSeek-V4-Flash 这类快速模型，响应快、成本低。
• 复杂任务，比如大型重构、架构设计、长文件理解，优先选推理能力更强的 Pro 型号或专门强化 reasoning 的模型。
• 如果拿不准，建一个小型评测集，找 10 到 20 条你日常工作里真实遇到的任务，分别让多个模型跑一遍，对比输出质量和耗时。
• 除了模型本身，还要看 API 稳定性、限流策略、上下文长度和定价。一个模型单次效果再好，如果频繁限流，在批量任务里也是麻烦。

最重要的原则是：不要只看模型名，要以你自己的任务集为基准。别人觉得好用，不一定适配你的代码库。

6.3 批量任务脚本参考

多模型切换完成后，可以开始批量任务。批量任务的核心设计有三个点：超时控制、失败重试、结果落盘。下面是一个通用脚本模板：

import json import time from pathlib import Path import requests api_key = "your-api-key" # 建议改用环境变量读取 tasks = [ "解释下面函数的时间复杂度: def fib(n): return n if n < 2 else fib(n-1)+fib(n-2)", "为下面的 Python 函数补充单元测试: def add(a, b): return a + b", "把这段同步代码改成异步实现: import time; time.sleep(1)", ] results = [] for idx, task in enumerate(tasks, 1): for attempt in range(3): try: resp = requests.post( "https://api.example.com/v1/responses", headers={"Authorization": f"Bearer {api_key}"}, json={ "model": "deepseek-v4-flash", "input": task, }, timeout=120, ) resp.raise_for_status() results.append(resp.json()) print(f"[OK] task {idx} / attempt {attempt + 1}") break except Exception as e: print(f"[RETRY] task {idx} / attempt {attempt + 1}: {e}") time.sleep(2 ** attempt) else: print(f"[FAIL] task {idx}，连续 3 次失败") output_path = Path("results.jsonl") output_path.write_text( "\n".join(json.dumps(r, ensure_ascii=False) for r in results), encoding="utf-8", ) print(f"结果已写入 {output_path}")

这个脚本用指数退避做重试，第一次失败等 2 秒，第二次失败等 4 秒，第三次失败等 8 秒。任务全部结束后，结果统一写入 JSONL 文件，便于后续分析。真正跑批量任务时，建议把任务列表放到文本文件或数据库里，避免一次堆太多内容导致上下文超限。

7. oh my pi 树莓派设备管理与资源占用观察

模型和 API 这层跑通之后，最后一步是把成果部署到设备端。oh my pi 这类工具的价值，就是省掉手动 SSH 登录、手动装依赖、手动改 systemd 服务的重复操作。

7.1 树莓派初始化流程参考

如果 oh my pi 是一个交互式命令行工具，典型的使用流程大致如下，具体命令以仓库 README 为准：

# 假设安装脚本入口是 setup.sh bash setup.sh # 假设工具提供了初始化子命令 oh-my-pi init # 安装指定版本的 Python oh-my-pi install-python --version 3.11 # 部署配置或者服务 oh-my-pi deploy --config ./pi-config.yml

第一次使用时，建议先在树莓派本机上跑一遍 help 命令，确认有哪些子命令，再决定初始化流程。不要直接照抄别人的操作步骤，树莓派系统版本和硬件型号差异很大。

部署完成后，可以从两个层面验证是否成功：进程层面看服务有没有正常运行，端口层面看外部能不能访问。常见做法是把服务注册成 systemd 单元，开机自启，崩溃自动重启。

7.2 资源占用怎么看

整个工具链的资源占用，分成三块来看。

本地命令行工具