文档
为什么需要多模型适配器
不同模型的训练语料、对齐方式和推理范式都不同，因此 Prompt 与 Skill 的最佳写法也截然不同。把同一份提示词直接丢给 Claude、GPT、Gemini、DeepSeek-R1、Kimi 等模型，往往只有其中一个能发挥最佳效果，其他要么降智，要么格式不稳定。
核心差异来源
| 差异维度 | 说明 |
|---|---|
| 训练数据分布 | Anthropic 用大量 XML 风格资料，Claude 对标签结构特别敏感；OpenAI 偏 Markdown 指令 |
| 对齐方式 | RLHF / DPO / Constitutional AI 等不同，对「越严格越好」还是「越简洁越好」的偏好不同 |
| 推理范式 | 原生推理模型（o1 / R1 / QwQ）自己输出 CoT，外部再加「一步步思考」反而 降低质量 |
| 上下文容量 | Kimi / Gemini 超长上下文 → 直接内联整份资料；Claude → 渐进披露更好 |
| 工具协议 | Anthropic tool_use / OpenAI function calling / Google function_declarations / 国内平台 DSL 各不相同 |
| 语言偏好 | 国产模型对中文直叙理解更好；国外模型 Markdown+英文指令最可靠 |
一份 Prompt 走天下的代价
很多团队在切换模型时踩过的坑：
- 给 Claude 写的 XML Prompt 直接丢给 GPT → 输出质量下降，结构不稳定
- 给 GPT 写的「Let's think step by step」Prompt 丢给 o1 / R1 → 推理模型被「带偏」，浪费推理算力
- 给 Claude 准备的渐进披露 Skill 丢给 Kimi → Kimi 长上下文能力被浪费
- 中文 Prompt 不加翻译给 Gemini → 效果显著劣于英文等价版本
- 国产工作流平台（扣子 / 百炼 / 千帆）需要 DAG 结构 → 单份 Prompt 无法直接落地
CAUTION
跨模型「勉强能跑」≠「发挥最佳」。真正工程化的 Prompt / Skill 必须针对每个模型做差异化渲染。
PromptMan 的解决方案
PromptMan 提供了一套「Canonical Skill Spec + 模型 Adapter」的适配器系统：
01
中间语义层（Canonical Spec）
用与厂商无关的结构描述身份、目标、步骤、输入、输出、约束、示例、工具
02
Adapter 渲染层
每个主流模型（Claude / GPT / Gemini / Qwen / DeepSeek / Kimi / GLM / ERNIE / Doubao + 各自推理模型）都有独立 Adapter，按其最佳实践产出 Prompt / Skill
03
统一入口
提供 renderSkill(spec, family) 与 REST API，一份 Spec 可一次性渲染到全部模型
04
Playground
访问 /adapters 在浏览器里实时对比 12 种模型的渲染结果