去年接手一个"死亡项目"——延期8个月，需求变更47次，核心开发走了3个。复盘时我发现一个致命问题：从立项到开发，没有任何一个环节用架构图做需求聚焦。
今天从开发视角，拆解架构图如何在技术设计的三个关键节点建立聚焦机制。
一、节点一：需求澄清——用图消灭"一句话需求"
开发最怕的需求描述："加个用户画像功能""优化一下查询性能""支持多端同步"。
没有架构图的需求澄清，是语义博弈；有架构图的需求澄清，是空间定位。
聚焦方法：需求"三问落图"
每个需求必须回答：
- 落哪？ 在架构图的哪个模块、哪一层、哪个接口？
- 动谁？ 输入变不变？输出变不变？依赖方感知不感知？
- 多大？ 单模块内改动？跨模块调用？还是新建模块？
案例解析："优化查询性能"的聚焦过程
原始需求：商品列表页加载慢，要求优化。
未聚焦的开发： 加缓存、加索引、加分页，各改各的，结果缓存和索引策略冲突，分页逻辑和前端对不上。
聚焦后的开发：
第一步：落图定位
- 商品列表页 → 展示层 → 调用商品服务 → 查询商品库
- 慢的原因：商品服务做了N+1查询（图上标出：服务层到数据层有循环箭头）
第二步：聚焦方案
- 方案A（聚焦查询）：在数据层加批量查询接口，服务层改循环为批量（改动1个模块）
- 方案B（聚焦架构）：引入商品缓存层，服务层先读缓存（改动2个模块，需考虑一致性）
- 方案C（聚焦流程）：展示层做异步加载，先出骨架屏（改动1个模块，体验不同）
第三步：图上标注
- 选方案A，图上用绿色标注"批量查询接口"，红色标注"原循环查询（废弃）"
- 同时标注"缓存层（二期考虑）"虚线框
结果： 改动范围清晰，代码review时对着图检查"是否只动了标注区域"，回归测试聚焦"批量接口的边界情况"。
二、节点二：方案设计——用图防止"过度设计"和"设计不足"
过度设计的根源： 看不到边界，以为要兼容所有未来场景。 设计不足的根源： 看不到依赖，以为改动只影响眼前模块。
聚焦方法："影响半径"可视化
在图上以需求落点为圆心，画三层影响圈：
- 内圈（必改）： 落点模块本身
- 中圈（评估）： 直接依赖的模块，需判断接口是否兼容
- 外圈（知晓）： 间接依赖的模块，需确认是否有副作用
案例：微服务拆分中的"用户服务"剥离
需求：从单体中剥离用户服务。
未聚焦的设计： 只画"用户服务"模块，标注CRUD接口。上线后发现：
- 订单模块调用用户服务查地址，但新服务没提供这个接口
- 营销模块调用用户服务查标签，但新服务返回格式变了
- 管理后台直接连用户表，绕过了服务层
聚焦后的设计：
第一步：落图标影响圈
- 内圈：用户服务（新建）
- 中圈：订单服务、营销服务、认证服务（接口依赖）
- 外圈：管理后台、数据报表、定时任务（可能直连数据库）
第二步：逐层聚焦
- 内圈：定义用户服务边界——只处理"用户核心属性"，地址、标签由各自域管理
- 中圈：订单服务原调用"用户地址" → 改为调用"地址服务"，用户服务不感知
- 外圈：管理后台直连数据库 → 图上标红"技术债"，本期不改但纳入监控
结果： 用户服务按时上线，中圈模块平滑迁移，外圈技术债有图可查。
三、节点三：技术债管理——用图聚焦"还哪笔债"
技术债越积越多时，常见的错误是"全面重构"——风险高、周期长、业务等不起。
聚焦方法：图上"债点"优先级排序
在架构图上标注所有已知技术债，按两个维度评分：
- 痛苦指数： 当前开发被这个债拖累的频率（1-5）
- 修复成本： 图上影响圈的大小（内圈=1，中圈=3，外圈=5）
案例： legacy系统的5个技术债
聚焦结论： 先还"数据库无索引"（分最低，收益最快），再处理"单体耦合"和"缓存策略"（分中等，需规划），"API网关"和"日志"（分最高，但收益周期长）纳入长期规划。
这张图让技术债从"感觉很多"变成"先还哪笔"。
四、可复用的聚焦流程配置
我团队现在的技术设计流程： 需求澄清 → 架构落点 → 影响圈分析 → 方案聚焦 → 图上标注 → 代码实现 → 图码对齐review ↑___________________________________________________________↓ （迭代更新）
关键检查点：
- 需求澄清后：必须有"落点确认单"（模块+接口+改动类型）
- 方案设计后：必须有"影响圈图"（三层圈+风险标注）
- 代码review时：必须对照图检查"是否只改了标注区域"
五、工具边界
团队在用 Arch 快速出草图验证落点，但有个铁律：AI生成的图必须经过"三问落图"才能进入设计。工具帮你快速试错，聚焦的判断必须来自对业务的理解。
