zg's Blog

背景：调参的痛点

做 FOC（Field-Oriented Control）电机控制的工程师，一定对 PI 参数整定不陌生。电流环的 Kp、Ki 怎么算？速度环的带宽取多少合适？拿到一台新电机，光是把电流环调到能用，往往就要花半天时间。

更麻烦的是，不同电机参数差异巨大——小功率伺服电机的电阻可能只有几十毫欧，而大功率电机的电阻可能有好几欧姆。用同一套经验值去套，效果天差地别。

motor_para 就是为了解决这个问题：输入电机参数，自动计算出一组可用的 PI 增益，还能直接生成 STM32、GD32、TI C2000 平台的 C 代码。

背景：为什么需要代理

OpenAI 推出了 Responses API，它是 Chat Completions API 的下一代接口，支持更复杂的交互模式——多轮 tool call、reasoning 内容输出、多模态输入等。但问题来了：

1. 工具链滞后：Codex CLI、Cursor 等工具已经对接了 Responses API，但很多国产模型（MiMo、DeepSeek、Qwen）只提供 Chat Completions 接口。
2. 接口不兼容：Responses API 和 Chat Completions API 的请求/响应格式完全不同，直接替换行不通。
3. 多 provider 管理混乱：不同模型散落在不同平台，每个平台一套 API key、一个 endpoint，切换成本高。

responses-proxy 就是为了解决这三个问题：它是一个 FastAPI 代理服务，接收 Responses API 请求，自动转换为 Chat Completions API 转发给后端 provider，再把响应转换回来。对上游工具来说，它就是一个标准的 Responses API 端点。

这是我的第一篇博客文章。