多语言站点API文档生成高阶版提示词

角色定义与任务定位

请以“多语言技术文档架构师”的身份，运用本提示词方案。您的核心目标是：系统化地生成或优化一套适用于多语言站点的API接口文档，确保其技术准确性、多语言一致性及开发者友好的阅读体验，最终服务于全球化产品的技术集成与开发者社区建设。

适用场景

• 为支持多语言的新产品API创建初始版本文档框架。
• 将现有单一语言API文档扩展并适配至多个语言版本。
• 统一不同团队或不同时期产出的API文档风格与结构。
• 生成用于自动化文档流水线（如结合Swagger、Redoc）的标准化内容源。

核心提示词

（以下为可直接复制、组合使用的提示词模块，请根据实际情况填充`{变量}`）

• 基础指令：生成一份关于`{API名称}`的RESTful API文档，需包含概述、认证方式、端点列表、请求/响应示例、状态码及错误处理。
• 多语言指令：基于上述中文文档结构，生成其`{目标语言，如英文、日文}`翻译版本，确保技术术语准确且符合当地开发者阅读习惯。
• 版本控制指令：在文档头部清晰标注版本号`{v1.2.0}`，并列出与上一版本`{v1.1.0}`相比的主要变更点。
• 交互式指令：为每个API端点提供可在线测试的`curl`命令示例，并注明`{BaseURL}`和必要的`{Header}`信息。

风格方向

• 专业严谨：采用技术文档的标准语态，避免口语化和营销词汇，定义清晰，无歧义。
• 统一规范：全文档保持术语、标题层级、代码块格式、配色（如成功用绿色，错误用红色）的高度一致。
• 简洁清晰：段落精炼，善用列表和表格呈现复杂参数，避免大段密集文字。
• 国际化友好：为所有语言版本预留相同的插图位置、代码示例和交互组件占位符，确保UI布局不受文本长度影响。

构图建议（信息架构）

• 顶部导航：固定显示语言选择器、文档版本下拉菜单和全局搜索框。
• 左侧树状目录：按功能模块组织API，支持展开/折叠，当前阅读位置高亮。
• 中部主内容区：采用三栏式布局——第一栏为API描述与参数说明，第二栏为请求/响应示例（支持多语言切换），第三栏为在线测试面板。
• 页脚：包含版权信息、反馈入口及链接到SDK下载和社区支持页面。

细节强化

• 代码高亮：请求与响应示例必须根据语言（JSON、Python、Java等）进行语法高亮。
• 状态码可视化：使用带颜色背景的徽章（Badge）直观区分2xx、4xx、5xx等状态码。
• 参数必填标识：对必填（Required）和可选（Optional）参数使用醒目的图标或颜色标签进行区分。
• 多语言术语库：建立并引用核心术语对照表（如“端点”-“Endpoint”-“エンドポイント”），确保翻译一致性。
• 版本差异对比：使用删除线（~~旧内容~~）和背景色突出显示新增或修改的字段。

使用建议

• 将“核心提示词”中的模块化指令输入到您的AI文档辅助工具或大语言模型中，分步骤生成内容，再进行人工校准与术语统一。
• 首先完成一个语言版本（建议英文或中文）作为“源语言文档”，并冻结其结构，再以此为基础进行其他语言版本的翻译与适配。
• 强烈建议将生成的文档Markdown或YAML文件纳入版本控制系统（如Git），与代码库同步管理。
• 在“细节强化”部分提到的可视化元素，需在前端展示时通过CSS或文档生成器主题实现，提示词中应明确标注这些元素的意图。
• 定期使用本提示词方案复查文档，更新过期内容，保持其作为“唯一可信源”的权威性。