云原生平台数据处理脚本清晰框架提示词

角色定义
以云原生数据工程师（Cloud-Native Data Engineer）的身份使用此提示词。您的核心目标是将数据处理流程设计为遵循云原生原则的脚本框架——具备高可观测性、弹性伸缩、配置外部化与声明式管理特征，确保脚本在 Kubernetes 等容器化环境中稳定运行，同时便于团队维护与迭代。

适用场景

在云原生平台（如 Kubernetes、OpenShift）上编写 ETL / ELT 数据处理脚本
构建面向流式或批处理的数据清洗、转换、聚合任务
需要同时兼顾脚本清晰度、资源限制、错误恢复与日志审计的团队项目
希望将数据处理脚本与 CI/CD 管道、配置中心、监控告警系统无缝集成


核心提示词
以下提示词可直接复制并用于脚本框架设计或 AI 生成示例代码：

框架结构模板：“采用config → init → process → error_handler → cleanup五阶段结构，每个阶段独立函数，所有配置通过环境变量或 ConfigMap 注入，不硬编码任何路径或凭据。”
可观测性要求：“每个阶段输出结构化 JSON 日志（包含时间戳、级别、阶段名称、处理行数、耗时），并在启动和结束处记录脚本版本与运行参数，同时暴露 Prometheus 指标（如处理记录数、错误数、延迟分布）。”
健壮性约束：“为每个远程调用（API、数据库、对象存储）添加指数退避重试机制（最多 3 次），通过超时控制避免长时间挂起；若超过阈值则输出告警日志并优雅终止进程，不留下中间脏数据。”
资源声明：“在 Kubernetes Job 或 CronJob 中显式设置 requests 与 limits（CPU/内存），并启用 Pod 优雅关闭（preStop hook 等待当前批次完成），避免数据不一致。”


风格方向

清晰度优先：函数职责单一，命名遵循动词_宾语（如extract_from_kafka、transform_to_parquet），注释仅解释异常逻辑而非语法。
云原生风格：配置与代码分离，使用 ConfigMap 管理运行时参数；日志格式遵循 Fluentd / Loki 规范；无状态设计（处理状态由外部存储如 Redis 或数据库持有）。
专业版注释：在文件头部包含维护者、创建日期、输入输出描述、依赖版本声明；关键算法处标注复杂度与容错策略。


构图建议
若需要为脚本可视化设计（如架构图或流程图），请参考以下方向：

主图内容：绘制分阶段流程图——左端为数据源（Kafka / S3），中段为容器内脚本处理流程（五个阶段以横向泳道排列），右端为目标存储（数据湖 / 消息队列），并用不同颜色区分正常流与错误流。
视觉元素：在每一阶段旁标注 Prometheus 指标图标（Gauge 符号）和日志框（JSON 片段气泡）；在底部添加 Kubernetes Pod 资源声明示例（YAML 矩形块）。
色彩方向：使用冷色调（深蓝、青灰、白色）突出专业感；错误流用橙红色虚线标注；日志气泡使用浅黄底色以提升辨识度。
表达方式：采用等宽字体呈现核心代码段，流程图箭头使用实线表示主流程，虚线表示异常回退路径。


细节强化

错误处理链：为每类异常定义独立错误码（如ERR_NET_TIMEOUT），并在日志中输出上下文堆栈；支持发送告警到 Slack / PagerDuty（通过 Webhook 嵌入脚本启动阶段）。
优雅关闭与 checkpoint：在中断信号触发时，将当前处理进度写入外部 checkpoint 文件（如 Redis key），下次启动时自动跳过已处理批次。
依赖锁定：所有 Python / Java 依赖版本通过 Pipfile.lock 或 Maven Shade 插件固化，并定期扫描 CVE。
测试套件注释：每个处理函数需注明对应的单元测试覆盖情况，如“test_transform_to_parquet 覆盖空输入与非法 schema 场景”。


使用建议

将本提示词导入 ChatGPT / Claude 或代码生成工具时，先复制“核心提示词”部分作为初始指令，再根据实际数据源（如 Kafka 集群地址、表结构）修改方括号中的占位符。
建议与团队统一编码规范（如 Google Python Style Guide）配合使用，并在 Git commit message 中标注此框架版本号。
在项目初期先输出一个最小可行脚本，遵循上述五阶段结构，然后逐步添加可观测性与错误恢复逻辑，避免过度设计。
可辅以 Terraform / Helm Chart 模板，将脚本作为容器镜像部署，实现从代码到运行环境的完整云原生流程。