Day 01 · LLM 开放平台 Go 后端建立工作台

今日验收

DONE MEANS

GOAL

把入口变成固定路径

今天只做一件事：为 LLM 开放平台后端建立一个 workbench.md 或同等笔记。它不是资料收藏夹，而是你排查、开发、上线时最先打开的工作台。

CHECK

完成标准

6 类入口都填了至少 1 个真实链接或路径；至少有 3 条日志查询模板、3 个核心表或配置入口；做过 1 次 20 分钟模拟排查，并留下结论。

今天的判断标准很朴素：下一次有人问「这个请求为什么失败」，你能在 2 分钟内打开工单、接口定义、日志查询、监控面板、数据库只读入口和代码入口。

1. 为什么先建工作台

WHY

LLM 开放平台后端的日常问题通常横跨多处：API 鉴权、模型路由、上游供应商、流式响应、计费落库、配额限流、日志和监控。你如果只盯着代码，很容易漏掉「请求在代码外面已经失败」这种情况。

LESS SEARCHING

减少找入口

把文档、日志、监控、数据库、仓库路径固定下来，降低每次切上下文的成本。

FASTER DEBUG

形成排查动线

从 request_id 到日志，再到监控、数据和代码，不再凭感觉跳来跳去。

BETTER AI

让 AI 吃到上下文

当你能稳定提供日志片段、代码路径和表结构，AI 才能帮你做有效分析。

2. 六类入口清单

6 ENTRIES

入口	应该记录什么	LLM 平台重点	最低完成标准
需求文档	当前迭代、工单系统、需求模板、负责人、验收方式。	区分用户可见能力、管理后台能力、内部运营能力。	能 1 次点击打开当前迭代需求。
接口文档	OpenAPI、Swagger、Postman、curl 示例、错误码文档。	关注 `model`、`stream`、tools、metadata、错误码和幂等字段。	能复制 1 条可运行请求样例。
日志	日志平台链接、常用查询、字段含义、时间范围规则。	固定 request_id、tenant_id、model、provider、status、error_code。	准备 3 条常用查询模板。
监控	API 延迟、错误率、上游状态、token 用量、成本、限流命中。	把平台问题分成入口层、路由层、上游层、计费层。	能打开 1 个请求链路核心面板。
数据库	只读库入口、核心表、常用 SQL、字段说明、数据保留周期。	关注请求记录、账单、配额、模型配置、供应商配置、API key。	列出 3 个核心表或配置入口。
代码仓库	服务入口、配置文件、测试命令、CI、部署、回滚说明。	能找到 API handler、service、provider adapter、billing、rate limit。	能在本地跑起服务或单测。

这张表不追求完整。先填「每天真的会用」的入口，之后在排查中遇到新入口再补。

3. 建一个工作入口清单

WORKBENCH.MD

在你的笔记软件、仓库文档或个人目录里创建 workbench.md。下面这份模板可以直接复制，今天只要求每一类填到能用，不要求一次整理得很漂亮。

# LLM 平台后端工作台

## 需求入口
- 当前迭代：填写真实链接
- 需求模板：填写真实链接
- 需求负责人：填写姓名或群组

## 接口入口
- OpenAPI / Swagger：填写真实链接
- Postman / curl：填写真实链接或文件路径
- 错误码文档：填写真实链接

## 日志入口
- 日志平台：填写真实链接
- 常用查询：
  request_id = 
  tenant_id = 
  model = 
  provider = 
  error_code = 

## 监控入口
- API 延迟：填写真实链接
- 错误率：填写真实链接
- 上游供应商：填写真实链接
- token / cost：填写真实链接
- 限流命中：填写真实链接

## 数据库入口
- 只读库：填写真实链接或连接说明
- 核心表：
  api_requests
  usage_records
  model_routes
  provider_configs
  api_keys
- 常用 SQL：填写文件路径或片段

## 代码入口
- 仓库：填写真实链接
- 服务启动：填写命令
- 单测命令：填写命令
- CI / 部署：填写真实链接
- 回滚说明：填写真实链接

建议放在你每天最容易打开的位置。如果团队允许，放在项目仓库的个人 notes 目录；如果不方便提交内部链接，就放在本地笔记里。关键是能被你自己稳定复用。

4. 做一次 20 分钟模拟排查

DRILL

用一个模拟场景验证你的工作台是否真的可用：用户反馈「调用模型接口偶发 500」或「流式响应中断」。今天不要求找到真实根因，只要求你能按固定动线走完一遍。

从工单或需求里拿到 request_id、tenant_id、model、发生时间。

打开日志平台，按 request_id 查询入口日志和上游调用日志。

打开监控，看同一时间段错误率、延迟、限流和上游状态。

打开只读库，确认请求记录、账单记录、配额状态是否一致。

定位代码入口，找到 handler、service、provider adapter。

写下事实、猜测、待确认项和下一步动作，不直接拍脑袋下结论。

# 模拟排查记录

场景：调用模型接口偶发 500 或流式响应中断
时间范围：填写开始时间到结束时间
request_id：填写样例 request_id
tenant_id：填写样例 tenant_id
model：填写模型名
provider：填写供应商名

已知事实：
- 入口层是否收到请求：
- 上游是否返回错误：
- 是否命中限流或配额：
- 数据库是否写入请求记录：
- 账单记录是否生成：

可能原因：
- 入口参数错误：
- 上游供应商异常：
- 流式连接中断：
- 超时设置过短：
- 计费或配额状态异常：

下一步：
- 需要补充的日志：
- 需要查看的代码路径：
- 需要找谁确认：

检查点	看什么	结论写法
日志	入口状态码、上游状态码、错误码、耗时、request_id 是否贯通。	「入口收到请求，上游返回 5xx，待确认供应商状态。」
监控	错误率是否局部上升，是否集中在某个模型、租户或供应商。	「错误集中在 provider A，不是全平台异常。」
数据库	请求记录、用量记录、配额状态、账单状态是否一致。	「请求已落库，但 usage 未生成，计费链路待确认。」
代码	超时、重试、流式 flush、错误转换、defer 清理。	「代码路径定位到 provider adapter，下一步看超时配置。」

5. 用 AI 做排查助手

PROMPT

AI 最适合帮你整理事实、列分支、提醒遗漏。不要让它在证据不足时直接给根因。你要给它 request_id、日志片段、监控描述、代码路径，然后要求它把「事实」和「猜测」分开。

你是 LLM 开放平台 Go 后端排查助手。

我会给你 request_id、日志片段、监控截图描述、相关代码路径。
请帮我整理：
1. 已知事实
2. 可能原因
3. 下一步排查
4. 需要补充的信息

要求：
- 不要直接下结论。
- 没有证据的地方标记为「待确认」。
- 优先关注超时、重试、流式中断、限流、配额、计费、上游供应商状态。
- 如果日志字段不足，请告诉我应该补哪些字段。

GOOD INPUT

喂给 AI 的信息

request_id、tenant_id、model、provider
入口日志和上游调用日志
监控异常时间段描述
相关 handler、service、adapter 路径

BAD INPUT

不要这样问

「接口 500 是什么原因」
「帮我看看哪里坏了」
只贴一段日志，不给时间和 request_id
让 AI 在没证据时写最终结论

6. 今日验收清单

CHECKLIST

需求文档、接口文档、日志、监控、数据库、代码仓库 6 类入口都填了至少 1 个真实链接或路径。
日志入口里有至少 3 条可复制查询模板，包含 request_id、tenant_id、model 或 provider。
数据库入口里列出至少 3 个核心表、配置项或只读查询路径。
代码入口里写清楚服务启动、单测命令、handler、service、provider adapter 的位置。
完成 1 次 20 分钟模拟排查，并写下已知事实、可能原因、待确认项和下一步。
把 AI 排查提示词放进你的工作台，之后遇到真实问题时可以直接复用。

Day 01 结束时，你不需要变得更懂 LLM。你只需要把工作现场整理到自己能快速进入。明天会在这个工作台上继续做任务卡模板，把需求拆成可以交付的后端动作。