一、 通用提示词模板（直接套用）
需求：
1. 目标：【比如：让这段代码解耦/支持多种策略/符合开闭原则/提升可读性】
2. 现有代码：【粘贴你的完整代码片段，包括相关类、方法、成员变量】
3. 业务背景：【这段代码的作用？核心逻辑是啥？比如"过滤指定队列并修改推荐项权重，用于联调场景"】
4. 约束条件：【比如：不能新增init方法/依赖Protobuf/需要兼容现有框架注解/@Parameter变量不能改】
5. 设计偏好：【比如：优先用策略模式/希望用枚举管理策略/不要引入过多第三方依赖】
请帮我重构这段代码，要求：
- 符合单一职责、开闭原则
- 命名规范，代码自解释
- 增加必要注释，说明设计思路
- 保留原有功能，不引入bug二、 针对你这次「队列修改策略」场景的示例提示词
（可以直接参考这个写法，替换成你的新需求）
需求：
1. 目标：重构队列过滤+调权的代码，支持「只过滤、只调权、过滤+调权」三种策略，提升可扩展性，后续能快速加新策略
2. 现有代码：【粘贴你的 RenderProcessorV2 类 + apply 方法 + ModificationContext 类】
3. 业务背景：这段代码是推荐系统的联调逻辑，需要根据配置的 targetQueues 保留指定队列，同时把队列内的 RecommendItem 权重设为固定值
4. 约束条件：
- 不能新增 init 方法，变量通过 @Parameter 注入
- 依赖 Protobuf 的 Builder，不能修改原有的 fillBroadwayReply 方法
- 要兼容多线程场景，懒加载策略实例
5. 设计偏好：
- 用枚举定义策略类型
- 用策略模式解耦不同操作逻辑
- 命名要贴近业务，不要用 debug 这类技术术语
请帮我重构代码，要求：
- 符合单一职责，过滤和调权逻辑分离
- 策略可动态切换，新增策略无需修改原有代码
- 代码结构清晰，类和方法职责明确
- 给出重构前后的对比和设计思路说明三、 写提示词的关键技巧
-
代码给全，别只给片段
比如你这次的
apply方法，要带上ModificationContext的结构、RecommendItems的定义，否则我可能会假设不存在的方法（比如getQueueId），导致重构后的代码无法直接用。 -
约束说死，避免返工
比如「没有 init 方法」「不能改 @Parameter 变量」「依赖 Guava 的 CollectionUtils」这些硬性条件，一定要提前说，否则重构方案可能不符合你的项目规范。
-
目标要具体，别写"优化代码"
模糊的需求会得到模糊的结果。把「优化」拆成 「解耦」「支持多策略」「提升可读性」「方便测试」 这类具体目标，我才能精准发力。
-
可以指定设计模式
如果你有偏好（比如这次的策略模式），直接说「优先用策略模式」，我会在这个方向上深化；如果不确定，也可以说「请推荐合适的设计模式」。
四、 进阶：让重构更贴合团队规范
如果你的团队有代码规范（比如命名风格、注释要求、依赖限制），也可以加在提示词里：
额外要求：
- 类名用 UpperCamelCase，方法名用 lowerCamelCase
- 注释只写"为什么这么做"，不写"做了什么"
- 禁止使用 Lombok，所有成员变量手动写 getter/setter