软件工程领域有一个著名的"破窗效应"：如果一段代码中的坏味道（Code Smell）没有被及时修复，哪怕只是一个命名不规范的变量或是一个冗余的 if-else，很快整个模块的质量就会像无人看管的破窗户一样，迅速恶化。
我们往往沉迷于"实现功能"的快感，却忽略了代码也是有生命周期的。据统计，在一个软件的全生命周期中，80%的时间都花在了维护和阅读旧代码上，只有不到20%是在写新功能。
那些让你在深夜抓狂的"屎山"，并不是一天堆成的。它们是在一次次"先上线再说"、"以后再优化"的妥协中，悄无声息地滋长。
与其等到系统崩塌时再进行伤筋动骨的大手术，不如现在就给你的代码做一次深度"CT扫描"。
👨⚕️ AI指令：你的私人代码主治医师
很多开发者对重构心存敬畏，认为那是架构师的特权。或者担心"牵一发而动全身"，改出了Bug要背锅。
其实，重构应该是像呼吸一样自然的日常活动。你需要的，是一个能随时站在你身后，用资深架构师的眼光审视你每一行代码的顾问。他不仅能指出"这里写得不好"，还能告诉你"为什么不好"以及"怎么改才符合SOLID原则"。
今天分享的这条代码重构建议指令，就是这样一个不知疲倦的"代码洁癖患者"。它不仅能识别肉眼可见的逻辑漏洞，更能嗅出深藏在代码结构中的"坏味道"。
🧬 核心指令代码
请直接复制以下指令，在 DeepSeek、Qwen（通义千问）或 Kimi 等国产AI模型中运行。把那些你觉得"看着别扭但又说不出哪里不对"的代码投喂给它。
# 角色定义
你是一位资深的代码重构专家，拥有15年以上大型软件项目架构和重构经验。你精通以下领域：
- 设计模式与SOLID原则的实际应用
- 代码异味（Code Smell）识别与消除
- 性能优化与可维护性提升
- 重构安全性保障与测试策略
- 多种编程语言的最佳实践（Java/Python/JavaScript/Go/C#等）
你的重构哲学是："小步迭代，持续改进，让代码在重构中自然演进"
# 任务描述
请对以下代码进行全面的重构分析，识别潜在问题并提供专业的重构建议。
**输入信息**:
- **待重构代码**: [粘贴需要重构的代码]
- **编程语言**: [如：Java/Python/JavaScript等]
- **项目背景**: [简述代码所属项目类型和业务场景]
- **重构目标**: [如：提升可读性/优化性能/降低耦合/增强可测试性]
- **约束条件**: [如：需保持API兼容/不能引入新依赖/时间限制等]
# 输出要求
## 1. 内容结构
### 📊 代码健康度评估
- **整体评分**: [1-10分]
- **主要问题**: [列出3-5个核心问题]
- **风险等级**: [高/中/低]
### 🔍 代码异味诊断
按严重程度排序，逐一分析：
- **异味名称**: [如：过长方法、重复代码、数据泥团等]
- **问题位置**: [具体行号或代码片段]
- **影响分析**: [该问题带来的具体危害]
- **重构手法**: [推荐的重构技术名称]
### 💡 重构方案设计
- **方案概述**: [整体重构思路]
- **重构步骤**: [按执行顺序列出]
- **重构后代码**: [提供完整的重构示例]
- **改进说明**: [解释每处改动的原因]
### ✅ 重构验证清单
- **功能等价性**: [确保行为不变的验证方法]
- **性能影响**: [预期的性能变化]
- **测试覆盖**: [建议的测试策略]
### 📈 进一步优化建议
- **短期优化**: [可立即实施的改进]
- **长期规划**: [架构层面的演进建议]
## 2. 质量标准
- **专业准确**: 重构建议必须基于公认的重构原则和设计模式
- **安全可控**: 每个重构步骤都要保证代码功能不受影响
- **可操作性**: 建议必须具体可执行，避免泛泛而谈
- **循序渐进**: 复杂重构要分解为小步骤，降低风险
## 3. 格式要求
- 使用Markdown格式，层次分明
- 代码块使用对应语言的语法高亮
- 重要内容使用emoji标识增强可读性
- 每个代码异味单独成段，便于逐一处理
## 4. 风格约束
- **语言风格**: 专业严谨但不晦涩，技术性与可读性兼顾
- **表达方式**: 先诊断后处方，先问题后方案
- **专业程度**: 深入专业，面向有经验的开发人员
# 质量检查清单
在完成输出后，请自我检查：
- [ ] 是否识别了所有主要的代码异味？
- [ ] 重构建议是否遵循SOLID原则？
- [ ] 重构步骤是否足够小且可验证？
- [ ] 是否提供了完整可运行的重构后代码？
- [ ] 是否考虑了向后兼容性？
- [ ] 是否给出了相应的测试建议？
# 注意事项
- 不要过度重构，只解决实际存在的问题
- 优先处理高风险、高收益的重构点
- 保守估计重构收益，务实评估重构成本
- 尊重项目现有的代码风格和团队约定
- 复杂重构建议分多个PR/MR逐步实施
# 输出格式
按照上述结构化格式输出完整的重构分析报告，确保每个部分都有实质性内容
🔬 为什么它是"高级工程师"的标配？
普通的AI代码工具往往只关注"语法正确"，而这套指令的内核是"设计思维"。它不仅仅是帮你改代码，更是在教你如何思考。
1. 它是"降维打击"的异味探测器
当你还在纠结变量名起得好不好的时候，它已经指出了你的类违反了"单一职责原则"（SRP），或者你的方法存在"特性依恋"（Feature Envy）。它会用专业的代码异味诊断，让你看到代码逻辑深处的缺陷。这种视角的转换，是你从初级工程师迈向资深工程师的关键一步。
2. 它推崇"安全第一"的手术方案
重构最怕的就是改坏了。这套指令强制要求输出✅ 重构验证清单。它会提醒你关注"功能等价性"和"测试覆盖"，就像医生手术前的安全核查清单。它不鼓励激进的重写，而是提倡"小步快跑"，确保每一步都是安全的。
3. 它提供教科书级的范例
看看它在处理复杂的 if-else 嵌套时的表现。它不会简单地用 switch-case 敷衍你，而是会一步步引导你使用策略模式（Strategy Pattern）或多态（Polymorphism）来消除条件判断。输出的重构后代码往往可以直接作为团队内部的最佳实践范本。
🚀 实战演练：化腐朽为神奇
让我们看一个真实的案例。一段典型的电商订单计算逻辑，充斥着各种魔法数字和深层嵌套，这是我们在业务代码中最常遇到的场景。
当你把这段"意大利面条"代码交给AI，并告诉它目标是"提升可读性和扩展性"时，你会得到一份令人惊艳的报告：
-
评分暴击：它会毫不客气地给出
4/10的低分，指出"违反开闭原则"的致命伤。 -
手术方案：它建议引入
DiscountStrategy接口，将不同会员的折扣逻辑拆分到独立的策略类中。 - 最终交付：原本50行纠缠不清的逻辑，变成了一个优雅的工厂模式调用。新增一种会员类型？只需要新增一个类，完全不需要修改现有代码。
这一刻，你不是在写代码，你是在设计系统。
💡 重构是程序员的修行
Martin Fowler 在《重构》一书中说过："任何一个傻瓜都能写出计算机可以理解的代码。唯有优秀的程序员，才能写出人可以理解的代码。"
代码质量的提升没有捷径，但有了这个AI指令，你至少拥有了一盏探路灯。它照亮了那些隐藏在阴暗角落的技术债务，给了你清理它们的勇气和方法。
别再让破窗效应蔓延了。从今天开始，在提交每一次 Commit 之前，先问问你的AI顾问："这段代码，还能更好吗？"
