AI 开发者基础设施：先做可组合的小工具的重点在于把前置条件、操作顺序和容易误判的地方分清楚。

AI 开发者基础设施：先做可组合的小工具

一、基础设施不一定要从平台开始

很多团队谈 AI 开发者基础设施，第一反应是做一个大平台：Prompt 管理、评测、模型网关、日志、成本、Agent 编排全都有。愿景很好，但建设周期长，用户学习成本高。更实用的路径，是先做可组合的小工具。

小工具可以是 Prompt 评测 CLI、模型调用日志中间件、token 成本统计库、结构化输出校验器、简单的 RAG 数据集管理器。每个工具解决一个明确问题，组合起来形成基础设施。少即是多，不是少做事，而是每件事边界清楚。

二、工具链结构：小工具拼成工作流

可组合工具要遵循几个原则：输入输出清晰、支持 CLI 和 API、配置可版本化、日志可读、失败可解释。不要一上来就强绑定某个 UI。开发者基础设施首先服务开发者，命令行和配置文件往往更高效。

工具之间可以通过 JSON、YAML 或标准文件约定连接。比如评测 CLI 输出统一报告，成本工具读取调用日志，文档工具读取同一份模型配置。接口简单，生态才容易长出来。

三、配置示例：工具共享模型配置

下面是一份简单模型配置。

models:default:provider:"openai-compatible"base_url:"https://api.example.com/v1"timeout_ms:20000evaluation:dataset:"./eval/support.jsonl"output:"./reports/support-eval.json"

这种配置可以被多个工具复用。评测工具用它跑样本，网关用它路由模型，文档工具用它生成说明。配置是基础设施的骨架，别把关键参数散落在代码里。

版本化也很重要。评测结果要记录模型配置版本，否则下次复盘不知道用了哪个供应商和参数。AI 工具链里，配置漂移是很常见的隐形 bug。

四、落地路径：先服务一个真实团队

基础设施不要闭门造车。先找一个真实团队，把他们最痛的环节工具化。比如客服 Prompt 经常回归，就先做评测；模型费用看不清，就先做成本报表。需求来自真实痛点，工具才有生命力。

文档和示例要跟上。小工具如果需要读源码才能用，就失去了轻量优势。每个工具至少有一个最小示例、常见错误和退出码说明。

最后，允许替换。可组合基础设施的好处是某个工具不好用，可以换掉，不影响全部系统。大平台一旦错了，迁移很重；小工具错了，改起来轻。

小工具也要有统一约定。日志字段、退出码、配置路径、报告格式尽量一致，否则组合时会出现一堆胶水代码。轻量不是各写各的，轻量也需要秩序。

对于团队内部推广，可以先做模板仓库。新项目复制模板后，自动拥有评测脚本、模型配置、调用日志和成本统计。基础设施最好的状态，是开发者几乎不用想就能用起来。

工具成熟后再考虑 UI。很多基础设施一开始就做后台页面，反而拖慢核心能力。先让 CLI 和配置稳定，再给常用视图加界面，节奏更稳。

每个小工具都要有退出码约定。CI 需要知道哪些失败应该阻塞，哪些只是警告。比如评测分数低于阈值返回 1，生成报告成功但有退化返回 2。机器可读的结果，是工具链能自动化的前提。

还要避免工具之间隐式依赖。一个工具需要另一个工具的输出，就在文档和配置里写清楚，不要靠目录里“刚好有个文件”。可组合的前提，是契约透明。

五、总结

AI 开发者基础设施可以从可组合小工具开始。每个工具解决一个明确问题，输入输出稳定，配置可版本化，文档可运行。先服务真实痛点，再逐步拼成平台。