kimi需先执行诊断报告，再基于坏味道选择策略或工厂模式重构，最后验证接口契约与边界测试；三步缺一不可，否则易误用设计模式。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你想在不破坏现有功能的前提下，把一个没有注释、命名混乱、if-else嵌套三层的Java订单处理类改造成可读、可测、易扩展的结构，Kimi能直接给出带设计模式的重构方案，但前提是Prompt必须精准锚定问题域和约束边界。
第一步：用诊断型Prompt让Kimi看清“病灶”
打开Kimi对话框，粘贴以下完整Prompt（注意保留三引号）：
"""你是一位有12年Java架构经验的重构专家，正在审查一段遗留订单处理逻辑。请严格按以下步骤执行：
① 先指出代码中3个最严重的代码坏味道（如发散式变化、过长函数、数据泥团），标注具体行号或上下文片段；
② 对每个坏味道，说明它导致的可维护性风险（例如：新增一种支付方式需修改5个类）；
③ 不生成任何代码，只输出结构化诊断报告。
待分析代码：
```java
public class OrderProcessor {
public void handle(Order order) {
if (order.getType().equals("NORMAL")) {
// 20行库存校验+扣减逻辑
} else if (order.getType().equals("PREMIUM")) {
// 25行VIP库存校验+扣减+积分叠加逻辑
} else if (order.getType().equals("GIFT")) {
// 18行赠品逻辑+免运费判断
}
// 后续统一发货、通知、日志
}
}
```"""
这一步必须做，否则Kimi会跳过诊断直接给泛泛而谈的“建议”。【不跳过诊断，就避免把策略模式错误套用到本该用状态模式的场景】
第二步：用契约型Prompt驱动设计模式落地
拿到诊断报告后，复制其中第一条坏味道（比如“重复的库存校验逻辑分散在3个if分支中”），构造新Prompt：
方法一：策略模式精准注入
“基于以下约束，为OrderProcessor中的库存校验环节设计策略模式：
- 新增接口StockCheckStrategy，定义check(StockContext context)方法；
- 为NORMAL/PREMIUM/GIFT各实现一个策略类，复用原有校验逻辑但剥离if分支；
- 修改OrderProcessor.handle()，通过Map
- 保持原有public方法签名不变，不新增外部依赖。”
方法二：工厂模式兜底兼容
“若项目不允许引入新接口，请改用静态工厂模式：
① 创建StockCheckerFactory类，含public static StockChecker getChecker(String type)；
② 工厂内部仍用if-else，但仅限工厂类内；
③ OrderProcessor中只调用factory.getChecker(type).check(context)，彻底移除原分支。”
两种方法都要求Kimi输出完整可编译的Java代码，且每段代码前标注“// ✅ 可直接粘贴到src/main/java下”。
第三步：用验证型Prompt封住回归漏洞
将Kimi生成的策略接口代码复制过来，追加验证指令：
第一步：确认契约完整性
“检查StockCheckStrategy接口是否遗漏了必需方法：getPriority()用于排序、supportsType(String)用于运行时匹配、getFallback()用于降级——若缺失任一方法，请补全并说明理由。”
第二步：触发边界测试生成
“为StockCheckStrategy接口生成JUnit 5测试类，覆盖：
① NORMAL策略对null context抛IllegalArgumentException；
② PREMIUM策略在库存不足时返回StockNotAvailableException；
③ GIFT策略对非赠品类订单返回UnsupportedOperationException。”
这一步生成的测试用例必须包含@DisplayName中文描述，且每个@Test方法体不超过4行——太长的测试本身就成了新的坏味道。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
