Refine compass and ruler overlay

communication-guidelines.md

@@ -0,0 +1,96 @@
+# 沟通协作建议
+
+这份文档用于约定后续在 UI 微调、交互细改、规则补充时，怎样沟通最有效，减少来回修改。
+
+## 1. 需求描述的推荐格式
+
+后续尽量按下面 4 个点描述需求：
+
+### 改动对象
+明确指出这次只改什么。
+
+例如：
+- 比例尺和指北针顶部数字之间的距离
+- 某个按钮的高亮状态
+- 某条提示文案
+
+### 不要改
+明确指出哪些相邻元素不要动。
+
+例如：
+- 不要改顶部数字和小箭头之间的距离
+- 不要动比例尺刻度算法
+- 不要改地图引擎逻辑
+
+### 目标效果
+说明你想达到什么视觉或交互结果。
+
+例如：
+- 更靠近一点
+- 改成 4 到 5 像素的空隙
+- 只在可点击时高亮
+
+### 验证标准
+说明你用什么标准判断“改对了”。
+
+例如：
+- 看起来贴近，但不要重叠
+- 指北针仍然盖住比例尺
+- 缩放时要实时变化，不要手势结束后再跳
+
+## 2. 推荐的需求表达模板
+
+可以直接按这个模板发：
+
+```text
+改动对象：
+不要改：
+目标：
+验证标准：
+```
+
+例如：
+
+```text
+改动对象：比例尺和顶部角度数字之间的距离
+不要改：顶部角度数字和小箭头之间的距离
+目标：再近一点
+验证标准：看起来大约 4~5px，不重叠
+```
+
+## 3. 为什么这样最有效
+
+很多来回修改，通常不是功能做不了，而是：
+
+- 一次需求里混了两层甚至三层改动
+- 没说清楚“哪块不要动”
+- 验收标准只有感觉，没有边界
+
+一旦把“改什么”和“不要改什么”拆开，误改概率会明显下降。
+
+## 4. 开发执行的约定
+
+后续默认按下面方式执行：
+
+- 先复述这次只改哪一层
+- 真实执行时只改这一层
+- 不顺手带改别的部分
+- 改完明确说明：
+  - 改了什么
+  - 没改什么
+
+## 5. 最适合哪些场景
+
+这套方式尤其适合：
+
+- UI 间距微调
+- 按钮状态和图标切换
+- HUD 显示调整
+- 地图表现修正
+- 规则字段补充
+
+## 6. 一句话原则
+
+后续最有效的协作方式是：
+
+**需求把边界说死，修改一次只动一层。**