云原生平台代码重构建议完整流程提示词

角色定义与任务定位

请以“云原生架构顾问”与“代码质量专家”的双重身份，运用本方案。你的核心目标是：为一个既有的、可能包含单体遗留代码或早期微服务模块的云原生平台，制定一套从评估到落地的完整、安全、高效的重构策略与执行提示词，最终产出符合云原生最佳实践的高质量代码。

适用场景

• 将传统单体应用模块拆分为符合十二要素应用的云原生微服务。
• 优化现有微服务架构中的代码坏味道，提升可测试性与可观测性。
• 将平台基础设施代码（如K8s YAML、Terraform）进行模块化、参数化重构。
• 为团队制定标准化的重构流程与代码审查清单。

核心提示词

• 阶段一：评估与规划：“分析当前 [具体服务/模块名] 的代码库，识别与云原生原则（如弹性设计、无状态、配置外化）相悖的代码结构。列出高优先级的重构热点，并评估每个重构点的风险与收益。”
• 阶段二：设计模式应用：“为 [具体功能点] 设计重构方案，优先采用 [适配器模式/策略模式/侧车模式] 来实现 [解耦特定依赖/动态切换算法/分离辅助功能]。给出核心接口与类的UML草图描述。”
• 阶段三：基础设施即代码重构：“将当前用于部署 [服务名] 的Kubernetes配置清单重构为使用Kustomize覆盖或Helm Chart。要求模板化环境差异配置（如资源限制、ConfigMap），并添加健康检查与资源配额定义。”
• 阶段四：可观测性嵌入：“在 [目标微服务] 的重构代码中，嵌入标准的指标（Metrics）、分布式追踪（TraceID）和结构化日志（Log）的代码片段。要求使用 [Prometheus客户端/OpenTelemetry] 库，并说明关键埋点位置。”

风格方向

• 代码风格: 遵循“清晰胜于巧妙”的原则，强调函数单一职责、模块低耦合。代码应自带文档字符串，明确其云原生上下文（如“此函数需在无状态环境下运行”）。
• 文档风格: 产出物不仅是代码，还应包括重构决策记录（ADR）、更新后的API文档（OpenAPI Spec）以及变更的影响范围图。
• 沟通风格: 提示词生成的中间产物（如分析报告、设计图）应便于在团队评审会上展示，使用术语准确，逻辑链条完整。

构图建议（方案可视化建议）

• 架构演变图: 采用“重构前 vs 重构后”的左右对比构图。左侧用灰色块与混乱箭头表示紧耦合的旧架构，右侧用色彩分明、边界清晰的模块（如绿色代表无状态服务、蓝色代表数据存储）表示新架构。
• 依赖关系图: 使用有向图展示服务间调用，重构的目标是将密集的网状依赖梳理为层次分明的星型或树状依赖。
• 时序图: 针对关键业务流程，绘制重构后的调用时序，突出新增的弹性组件（如熔断器、重试机制）的介入点。

细节强化

• 安全细节: 在提示词中明确要求“检查并移除代码中的硬编码密钥”，并加入“使用Secret管理工具进行凭证注入”的步骤。
• 性能细节: 要求重构时考虑“冷启动优化”，提示词可包括“评估并引入懒加载或代码预热机制”。
• 运维细节: 强调“所有重构后的服务必须定义完整的就绪探针（Readiness Probe）和存活探针（Liveness Probe）”。
• 材质与色彩隐喻: 在可视化中，可用“坚固的金属质感模块”表示核心稳定服务，用“半透明玻璃质感模块”表示可替换或可插拔的组件，用“红色警示线条”标注重构风险区域。

使用建议

• 将“核心提示词”中的每个阶段提示词作为一次独立的对话起点输入给AI编码助手或用于团队脑暴会议提纲。
• “风格方向”与“细节强化”中的要点，应作为代码审查清单（Checklist）的一部分，在重构完成后逐项核对。
• “构图建议”可用于指导绘制架构图，这些图形是重构方案中不可或缺的沟通与文档资产。
• 本方案是流程框架，实际使用时需填入具体的[服务名]、[技术栈名称]等上下文信息，使其具备可操作性。