| 123456789101112131415161718192021222324252627282930313233 |
- ---
- description: 改代码前先列清单待确认；跨模块影响须预警；小问题最小改动、不大重构
- alwaysApply: true
- ---
- # 协作与改动范围
- ## 动手前须先列清单、等确认
- 在**编写或应用补丁之前**，先用简短条目列出拟改动，等用户明确确认（或调整）后再改。清单建议包含：
- - **目标**：一句话说明要解决什么
- - **将改动的文件**：路径 + 每处大概做什么（一行即可）
- - **可见行为变化**（若有）
- - **风险/影响面**（配置、部署、数据库、种子数据、公共 API 等）
- - **本轮明确不做的事**（范围边界）
- 用户未确认前，不默认执行大范围修改。
- ## 跨模块影响：先预警，再执行
- 在改动**某一功能模块**（如「S1 产销协同」看板、某条业务路由、共享组件/接口）时，若判断改动会**波及其它功能模块**（如共用 `kanbanData`、统一查询工具、布局组件、后端公共接口、菜单种子等），必须：
- 1. **明确写出「跨模块影响」小节**，列出：会影响**哪个模块**、可能影响**哪类能力**（页面、接口、筛选、导航、数据口径等）。
- 2. **在用户就此做出决策（接受 / 缩小范围 / 拆分任务）之前，不执行**会牵连其它模块的修改。
- 示例：改 S1 时若会动到 S6 共用的请求层或公共看板组件，须说明「本次会影响 S6 生产执行的 xxx（如：同一套基础查询参数、同一 API）」，待确认后再改。
- ## 小问题：最小改动，不大重构
- - 修小 bug、小交互、小样式时：**只做必要修改**，避免顺手重构、扩框架、改全局架构。
- - 若存在**更大方案**（抽公共组件、换目录结构、动框架/中间件/全局配置等）：**单独给出建议 + 利弊 + 可选方案**，由用户决策；**不默认替用户上大改**。
- - 非必要不动：种子数据、Docker/Nginx 全局配置、多模块牵连，除非用户确认或不做会明显错误/不安全。
|
