重构代码如何写提示词

一、 通用提示词模板（直接套用）

需求：
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 这类技术术语

请帮我重构代码，要求：
- 符合单一职责，过滤和调权逻辑分离
- 策略可动态切换，新增策略无需修改原有代码
- 代码结构清晰，类和方法职责明确
- 给出重构前后的对比和设计思路说明

三、 写提示词的关键技巧

1. 代码给全，别只给片段

   比如你这次的 apply 方法，要带上 ModificationContext 的结构、RecommendItems 的定义，否则我可能会假设不存在的方法（比如 getQueueId），导致重构后的代码无法直接用。

2. 约束说死，避免返工

   比如「没有 init 方法」「不能改 @Parameter 变量」「依赖 Guava 的 CollectionUtils」这些硬性条件，一定要提前说，否则重构方案可能不符合你的项目规范。

3. 目标要具体，别写"优化代码"

   模糊的需求会得到模糊的结果。把「优化」拆成 「解耦」「支持多策略」「提升可读性」「方便测试」 这类具体目标，我才能精准发力。

4. 可以指定设计模式

   如果你有偏好（比如这次的策略模式），直接说「优先用策略模式」，我会在这个方向上深化；如果不确定，也可以说「请推荐合适的设计模式」。

四、 进阶：让重构更贴合团队规范

如果你的团队有代码规范（比如命名风格、注释要求、依赖限制），也可以加在提示词里：

额外要求：

• 类名用 UpperCamelCase，方法名用 lowerCamelCase
• 注释只写"为什么这么做"，不写"做了什么"
• 禁止使用 Lombok，所有成员变量手动写 getter/setter