2025 年，模型接口越来越多，但个人工具并不需要同时绑定很多 SDK。我做了一次轻量化尝试：在业务代码和模型服务之间增加一个很薄的适配层，只约定输入、输出和错误格式。

只保留真正需要的接口

适配层只做三件事：接收消息列表、选择模型、返回文本和用量信息。它不保存会话，也不把供应商特有的字段泄漏到业务代码中。这样更换服务商时，只需要替换适配层，而不是重写整个工具。

def ask(messages, model="small-fast"):
    response = client.responses.create(
        model=model,
        input=messages,
        timeout=30,
    )
    return {
        "text": response.output_text,
        "usage": response.usage,
    }

真实项目里还需要处理超时、限流和重试。重试只针对明确的临时错误，并设置上限；如果请求已经产生费用，就不能无条件重复发送。

把日志做成能回答问题的东西

我只记录请求时间、模型名、耗时、状态码和 token 数，不记录完整提示词或敏感内容。发生问题时，这些字段足以判断是网络慢、服务拒绝，还是输入本身太大。日志的目标是帮助排错，而不是把所有数据都复制一份。

低配服务器上的取舍

适配层可以用一个很小的 Python 或 Go 服务运行，也可以在静态站点之外单独部署。博客本身不需要调用 AI 才能展示，因此把两者拆开后，即使接口服务暂时停止，文章页面仍然可以正常访问。

这次实践让我更确定一件事：个人项目的“智能化”不应以堆叠组件为起点。先把边界、超时、日志和成本控制做好，剩下的能力才有稳定的落脚点。