---
description: 改代码前先列清单待确认；跨模块影响须预警；小问题最小改动、不大重构
alwaysApply: true
---

# 协作与改动范围

## 动手前须先列清单、等确认

在**编写或应用补丁之前**，先用简短条目列出拟改动，等用户明确确认（或调整）后再改。清单建议包含：

- **目标**：一句话说明要解决什么  
- **将改动的文件**：路径 + 每处大概做什么（一行即可）  
- **可见行为变化**（若有）  
- **风险/影响面**（配置、部署、数据库、种子数据、公共 API 等）  
- **本轮明确不做的事**（范围边界）

用户未确认前，不默认执行大范围修改。

## 跨模块影响：先预警，再执行

在改动**某一功能模块**（如「S1 产销协同」看板、某条业务路由、共享组件/接口）时，若判断改动会**波及其它功能模块**（如共用 `kanbanData`、统一查询工具、布局组件、后端公共接口、菜单种子等），必须：

1. **明确写出「跨模块影响」小节**，列出：会影响**哪个模块**、可能影响**哪类能力**（页面、接口、筛选、导航、数据口径等）。  
2. **在用户就此做出决策（接受 / 缩小范围 / 拆分任务）之前，不执行**会牵连其它模块的修改。

示例：改 S1 时若会动到 S6 共用的请求层或公共看板组件，须说明「本次会影响 S6 生产执行的 xxx（如：同一套基础查询参数、同一 API）」，待确认后再改。

## 小问题：最小改动，不大重构

- 修小 bug、小交互、小样式时：**只做必要修改**，避免顺手重构、扩框架、改全局架构。  
- 若存在**更大方案**（抽公共组件、换目录结构、动框架/中间件/全局配置等）：**单独给出建议 + 利弊 + 可选方案**，由用户决策；**不默认替用户上大改**。  
- 非必要不动：种子数据、Docker/Nginx 全局配置、多模块牵连，除非用户确认或不做会明显错误/不安全。