多语言站点运维脚本编写清晰框架提示词

角色定义与任务定位

请以“多语言站点运维脚本架构师”的身份，运用此框架。你的核心目标是：为支持多语言（如中、英、日等）的网站或应用系统，设计并编写出结构清晰、可维护性强、能高效处理国际化（i18n）相关运维任务（如部署、监控、日志分析、数据备份与同步等）的自动化脚本方案。

适用场景

• 为多语言站点编写自动化部署脚本，需处理不同语言包的同步与更新。
• 设计跨区域服务器的日志收集与分析脚本，需区分和关联各语言版本的日志信息。
• 创建用于监控多语言站点内容一致性与可用性的巡检脚本。
• 开发用于处理多语言数据库备份、迁移或数据清洗的运维工具脚本。
• 构建统一的多语言配置文件（如JSON、YAML）生成与管理脚本框架。

核心提示词

以下提示词组合可直接或稍作修改后，用于生成脚本代码或详细设计：

• 编写一个Python/Bash脚本，用于自动从版本控制系统（如Git）拉取最新多语言资源文件（如 .po/.json），并部署到指定服务器的对应目录，需包含错误回滚机制。
• 设计一个日志分析脚本框架，能够按语言标签（如 `lang=en`）过滤Nginx/Apache访问日志，并统计各语言页面的错误率（5xx状态码）和访问延迟百分位数。
• 创建一个运维脚本，定期检查多语言站点所有语言版本（en, zh-CN, ja-JP）中关键API端点的健康状态，并将结果输出为结构化的JSON报告，包含响应时间、状态码和内容校验结果。
• 开发一个用于同步多语言数据库表内容的脚本，确保基础表（如产品信息）的更新能准确、原子性地同步到各语言翻译表，并记录同步日志。
• 实现一个多语言配置管理脚本，支持通过命令行参数指定目标语言，动态生成或验证对应环境的配置文件（如数据库连接字符串、第三方服务密钥）。

风格方向

• 代码风格：强调模块化、函数化。主逻辑清晰，将语言处理、错误处理、日志记录等功能分离为独立函数或模块。
• 文档风格：脚本内包含清晰的注释，说明各模块功能、参数含义以及多语言相关的处理逻辑。可生成配套的README，说明运行环境、依赖及多语言配置方法。
• 输出风格：脚本输出应结构化（如JSON、CSV）、可读性强，明确标注所涉及的语言代码、操作状态和时间戳。错误信息应包含可识别的语言上下文。

构图建议

此处的“构图”指脚本代码或设计文档的结构布局：

• 分层结构：采用“配置层 -> 核心逻辑层 -> 输出层”的结构。配置层集中管理语言列表、路径映射等；核心逻辑层处理业务；输出层格式化结果。
• 逻辑流程图：在文档中，建议用文字或伪代码描述关键流程，如：“读取配置 -> 遍历语言列表 -> 针对每种语言执行特定任务 -> 汇总结果 -> 错误处理与通知”。
• 目录/文件组织：提示生成适合多语言脚本的目录结构建议，例如：`scripts/`（主脚本）、`config/`（各语言配置文件）、`lib/`（通用函数库）、`logs/`（分语言或按日期存储的日志）。

细节强化

• 字符编码与处理：强制在脚本中明确指定UTF-8编码，以妥善处理中文、日文等非ASCII字符。提示注意文件读写、网络请求时的编码设置。
• 时区与本地化：在涉及时间戳的脚本中，考虑各语言区域可能对应的不同时区，建议使用UTC时间进行内部存储和计算，输出时可按需转换。
• 错误处理与重试：针对网络请求、文件操作等可能因区域网络环境失败的操作，设计包含指数退避算法的重试机制，并在错误日志中记录失败操作对应的语言标识。
• 敏感信息过滤：提示在日志或输出中，自动过滤或脱敏可能包含在多语言配置中的密钥、令牌等敏感信息。
• 可配置化：强调将语言列表、服务器地址、路径前缀等变量提取为外部配置文件或命令行参数，避免硬编码，提升脚本的复用性。

使用建议

• 在使用核心提示词生成具体脚本前，先用自然语言明确你的具体运维场景、涉及的语言种类以及期望的自动化程度。
• 将生成的脚本框架视为初稿，务必在测试环境中用真实的多语言数据流进行验证，重点测试边界情况（如某语言资源文件缺失、网络超时）。
• 结合“细节强化”中的要点，检查并完善生成脚本的健壮性，特别是异常处理和日志记录部分。
• 此框架同样适用于指导编写PowerShell、Go等其他语言的运维脚本，只需在核心提示词中指定对应语言即可。
• 对于复杂项目，建议按模块分步生成和集成，例如先完成核心逻辑，再补充配置管理和错误处理模块。