一、一个真实的技术债务案例
我们团队维护着一个6年的老系统，代码量80万行，需求文档堆了3个文件夹。
去年接了一个"简单"需求：在用户下单时增加风控校验。
开发估了5天。上线后，支付成功率暴跌15%。
排查发现：风控服务调用了用户中心的查询接口，而这个接口在高峰期被购物车服务大量占用，形成了级联阻塞。
根本问题：需求文档写了"调用风控服务"，但没写"风控服务依赖用户中心"，更没写"用户中心的容量瓶颈"。
文字无法表达依赖关系，但架构图可以。
二、架构图作为"技术债务探测器"
我开始在需求阶段强制引入架构图，发现了三个反直觉的规律：
1. 依赖越深，图越要画
老系统最怕"暗依赖"——你以为只改A，其实触发了B、C、D。
现在我的习惯：任何需求必须先画"影响范围架构图"，用不同颜色标注：
- 绿色：直接修改点
- 黄色：依赖调用点
- 红色：潜在风险点
这张图让暗依赖显性化。过去半年，因依赖遗漏导致的线上故障下降70%。
2. 评审架构图，比评审代码便宜100倍
代码评审发现问题，改起来成本是1。 架构评审发现问题，改起来成本是0.01——因为还没写代码。
我们现在的流程：需求评审→架构评审→技术方案→代码实现。 架构评审不通过，不准进技术方案。
3. 架构图是跨团队契约
微服务架构下，最痛苦的是"接口变更"。
我们的解法：服务提供方出架构图，消费方确认。图上的箭头就是契约，变更必须双方评审。
这张图比任何接口文档都管用——因为文档会过时，但图是讨论的基础，每次变更都要重新看图。
三、可复用的配置思路
我把这套方法抽象成一个"轻量级架构治理框架"：
# 需求阶段检查清单
需求澄清:
- 业务架构图: 明确问题域边界
- 干系人确认: 业务方在图上签字
技术设计:
- 系统架构图: 模块交互关系
- 风险标注: 红色虚线框标"待确认"
评审阶段:
- 非技术可读性测试: 让产品经理讲一遍图
- 影响范围确认: 黄色标注所有依赖点
维护阶段:
- 架构图版本化: 与代码同仓库
- 变更先改图: 图不对，代码一定不对
四、跨领域迁移：从代码到售前
这套"图驱动"的方法论，我迁移到了售前场景：
以前写解决方案，先写50页Word。现在先画3张架构图：
- 现状痛点图：让客户看到"你懂我"
- 目标架构图：让客户看到"你能解决"
- 演进路线图：让客户看到"风险可控"
签单率提升了40%。
五、工具实践
我用 Arch做快速草图，支持对话式修改，边聊边调。30秒出图，主要是把脑力花在"思考"而不是"画图"上。
你遇到过类似问题吗？ 需求看似简单，一改就炸——评论区说说你的技术债务治理经验。
标签： #架构设计 #技术债务 #微服务治理 #需求工程 #DevOps实践 #代码质量
