编程开发 编辑复核
重构边界与依赖地图
在不改变可观察行为的前提下梳理模块职责、调用关系、迁移顺序和可回滚切点。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名代码架构评审员。请先读取真实调用关系和测试证据，再划分重构边界，不要因为文件看起来很大就直接拆分。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 当前职责、入口、依赖和外部可观察行为
2. 高耦合点、隐式契约和测试缺口
3. 每批重构的最小范围和兼容层
4. 回归、性能和数据风险
5. 每批的验收、监控和回滚切点
输入变量：
- 目标模块（{{module}}）：提供目录、入口和主要调用方。
- 兼容性要求（{{behavior}}）：列出 URL、字段、事件和用户行为。
- 现有测试（{{tests}}）：提供测试文件、覆盖范围和失败记录。
- 发布限制（{{constraints}}）：说明分支、发布时间和回滚能力。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先画依赖和行为，再讨论目录结构。
- 重构批次要能独立构建、测试和回滚。
WHEN IT FITS
适用判断
适合这些情况
- 模块职责已经混乱，需要先看清依赖关系再动。
- 重构范围可能很大，需要划出这次改到哪为止。
- 你能提供模块结构和主要的调用关系。
换个做法更好
- 你要规划的是一次功能改动：用《代码改动影响面与执行计划》。
- 重构范围只有一个文件：直接改。
- 模块还在频繁加功能：等稳定下来再重构，否则边改边冲突。
FAILURE MODES
常见翻车与修正
- 模型画出的依赖关系和实际不符。
模型看不到完整代码。把实际的 import 关系或依赖分析结果粘进输入，要求所有依赖都有出处。
- 重构方案要求一次性改完所有模块。
大爆炸式重构风险高。要求拆成可以独立合并的阶段，每阶段结束时系统都能正常工作。
- 只说了新结构长什么样，没说怎么从现状过渡。
要求给出过渡方案：新旧结构如何并存、什么时候切换、老代码何时删除。
ACCEPTANCE
怎么判断输出合格
- 依赖关系有实际出处，不是模型推测。
- 重构拆成了可独立合并的阶段。
- 有新旧并存的过渡方案和老代码清理时间。
- 明确划出了这次不动的部分，范围有边界。
SAFETY BOUNDARY
使用边界
- 模型看不到完整代码库，它标出的依赖关系可能有遗漏；动手前用工具做一次真实的调用链检索。
- 重构范围要能拆成可独立发布的小步，大规模一次性重构的回滚成本极高。