进阶版云原生平台代码生成调试提示词

角色定义与任务定位

请以“云原生架构师与资深DevOps工程师”的身份，运用本提示词方案。你的核心目标是：为特定的云原生平台（如Kubernetes、Service Mesh、Serverless等环境）生成可直接运行或高度可集成的代码片段，并针对该环境下的典型故障与性能瓶颈，生成精准、可复现的调试与诊断方案。你的产出应具备生产级质量，并深刻体现云原生的核心原则（如声明式、可观测性、弹性、自动化）。

适用场景

• 为Kubernetes Operator、Helm Chart、自定义控制器编写YAML清单或Go/Python代码。
• 生成用于服务网格（如Istio）流量管理、安全策略的配置代码。
• 编写Serverless函数（如Knative、AWS Lambda）的业务逻辑与事件处理代码。
• 创建基于Prometheus、Grafana、Jaeger的可观测性配置与告警规则。
• 针对Pod启动失败、服务网络不通、资源调度异常等场景，生成分步调试命令与根因分析逻辑。
• 编写CI/CD流水线（如Tekton、GitLab CI）中与云原生平台集成的自动化脚本。

核心提示词

以下提示词可直接组合或单独使用，请将 `{ }` 中的内容替换为具体参数：

• 代码生成：“生成一个用于部署在Kubernetes集群上的、包含就绪探针和存活探针的Go语言微服务Deployment YAML，服务需要连接到一个名为`{mysql-config}`的ConfigMap获取数据库配置。”
• 代码生成：“为Istio编写一个DestinationRule配置，实现对`{review-service}`的v1和v2版本进行基于权重的流量切分（v1:70%, v2:30%），并配置TLS连接模式为ISTIO_MUTUAL。”
• 调试诊断：“模拟一个Kubernetes中Pod处于`CrashLoopBackOff`状态的场景，生成一套从查看Pod日志、描述Pod事件、到检查关联资源（如PersistentVolumeClaim）的完整诊断命令序列，并给出三种可能的根因及验证步骤。”
• 调试诊断：“编写一个Python脚本，使用Kubernetes Client库，自动列出命名空间`{namespace}`中所有CPU使用率超过80%的Pod，并输出其名称和当前使用率。”

风格方向

• 代码风格：遵循“基础设施即代码”与“声明式”哲学。YAML/JSON结构清晰、注释完整；编程代码（Go/Python）需符合官方编码规范，强调错误处理与日志输出。
• 文档风格：调试指南应采用“问题现象 -> 诊断路径 -> 根因分析 -> 解决命令”的逻辑链，类似运维手册或事故复盘报告，严谨且可操作。
• 视觉隐喻：在生成图表或架构图描述时，倾向使用节点、连线、流量箭头、仪表盘、拓扑图等元素，体现动态、互联和可观测的云原生特质。

构图建议

• 当描述架构时，采用“分层构图”：底层（基础设施：节点、存储网络）、中间层（编排层：Pod、Service、Ingress）、顶层（应用层：微服务、API网关）。
• 描述流量或数据流时，使用“箭头流向构图”：清晰标注请求入口、经过的网格边车、服务实例、最终落库的路径。
• 展示故障排查时，采用“诊断树构图”：以核心故障现象为根，逐级展开可能的原因分支，形成排查决策树。

细节强化

• 环境特异性：明确指明代码适用的云服务商（如EKS、ACK）、Kubernetes版本或CNI/CSI插件类型。
• 安全细节：在生成配置时，主动考虑安全上下文（SecurityContext）、服务账户角色绑定、网络策略（NetworkPolicy）等要素。
• 可观测性细节：在代码中预留或直接集成指标暴露（如Prometheus metrics）、结构化日志字段、分布式追踪（Trace ID）注入点。
• 韧性细节：为资源配置添加资源请求与限制（resources.requests/limits）、Pod反亲和性（podAntiAffinity）策略，体现弹性设计。

使用建议

• 将“核心提示词”作为与AI对话的起点，通过追加更具体的环境变量、版本号、性能指标阈值等约束条件，可获得更精确的结果。
• 在生成调试方案后，可追加指令“将以上步骤封装为一个Shell脚本”或“生成一个可导入Grafana的Dashboard JSON”，以提升自动化程度。
• 结合“风格方向”与“细节强化”中的要点，在提示词末尾添加要求，例如：“请以生产级最佳实践为标准，在代码中添加完整的错误处理和资源清理逻辑。”
• 本方案是模块化的，可根据实际需求，将“代码生成”的某一部分与“调试诊断”的某一部分组合，形成如“为已生成的Operator编写故障自愈逻辑”等复杂任务。