结构化云原生平台代码重构建议提示词

角色定义与任务定位

请以“云原生架构顾问”或“资深后端工程师”的身份，针对一个具体的、待优化的云原生平台代码库，进行深度分析与规划。你的核心目标是：生成一份结构清晰、可操作性强、兼顾技术先进性与落地可行性的代码重构建议文档，用以指导开发团队进行系统性改造，提升平台的弹性、可观测性与部署效率。

适用场景

• 为遗留单体应用向微服务或服务网格架构迁移提供分阶段重构方案。
• 优化现有云原生服务，改善其配置管理、服务发现、弹性设计。
• 编写技术方案文档，用于立项评审、团队任务分解或知识传承。
• 针对特定技术债（如硬编码、脆弱的集成点、落后的监控）提出专项整改建议。

核心提示词

以下提示词组合可直接或稍作修改后，用于生成详细的重构建议内容：

• “分析当前 [具体模块，如：订单服务] 的代码结构，指出其与十二要素应用原则的背离点，并提出具体的代码重构和配置外部化方案。”
• “为提升系统可观测性，设计一套覆盖指标（Metrics）、日志（Logs）、链路追踪（Traces）的代码植入点建议，并给出关键代码片段示例。”
• “评估现有服务间通信方式（如：REST over HTTP），论证将其重构为 gRPC 或异步消息模式（如使用 Kafka）的利弊、适用场景及迁移路径。”
• “提出将容器内硬编码的配置和密钥，重构为使用 ConfigMap 和 Secrets 并与 [具体配置中心，如：Consul] 集成的详细步骤和代码变更示例。”
• “针对部署流程，编写将基于 Shell 脚本的部署重构为 GitOps 模式（使用 Argo CD）的实施方案，包括目录结构设计和关键配置文件。”

风格方向

• 技术文档风格：采用客观、严谨、条理清晰的书面语，避免口语化。使用标准的软件工程术语。
• 问题驱动结构：采用“现状问题 -> 重构目标 -> 具体方案 -> 预期收益 -> 风险评估”的逻辑链条进行组织。
• 代码与图示结合：在描述重构点时，应倾向于提供伪代码、差异对比（diff）或清晰的架构流程图描述，而非纯理论论述。

构图建议

（此处的“构图”指文档内容的结构布局与信息组织方式）

• 分层叙述：从宏观架构图到具体代码层，逐层深入。先描述服务拓扑变化，再深入到 API 接口，最后到关键类/函数。
• 对比陈列：将“重构前”与“重构后”的代码片段、配置方式或数据流进行并列对比，直观展示改进点。
• 清单式要点：对于重构步骤、检查项、依赖更新清单，使用编号或项目符号列表，确保可执行性。

细节强化

• 引入具体技术栈：在建议中明确提及如 Kubernetes、Docker、Istio、Prometheus、Jaeger、Fluentd 等具体组件的集成方式。
• 量化收益：尽可能将收益量化，例如：“预计通过引入连接池，数据库查询延迟降低 30%”；“通过配置外部化，环境部署准备时间从 1 小时缩短至 5 分钟”。
• 关注非功能性需求：强化对安全性（Secrets 管理）、可维护性（代码注释、文档）、成本（资源请求/限制优化）等方面的建议。
• 提供回滚方案：每一个重大的重构步骤，都应附带简要的回滚或应急方案，体现方案的完整性。

使用建议

• 将上述“核心提示词”作为思考起点或直接输入给 AI 文本生成工具，以获取初步的详细内容草稿。
• 生成内容后，请务必结合真实项目上下文，填充具体的命名空间、服务名、镜像仓库地址等实际参数。
• 建议按“优先级（高/中/低）”和“实施阶段（一期/二期）”对生成的重构建议进行分类和排序，形成路线图。
• 最终输出物应为 Markdown 或 Confluence 等格式的正式文档，包含清晰的标题层级和必要的图表说明。