最近在梳理微服务架构治理方案时接触到 tt-a1i 与 archify 这一组工具链。很多团队在早期评估阶段容易卡住不清楚它们和常规代码扫描工具有什么区别也不知道部署后要接入哪些数据、如何配置规则、怎么把结果落到日常研发流程里。本文基于我实际调研和试点落地的过程整理了一份完整的实操笔记从概念定位、环境部署、基础配置到针对一个示例订单系统完成架构分析并给出常见报错排查思路和工程化落地建议。如果你是后端开发、架构师或者负责 DevOps 的同学这篇文章可以帮你快速建立一套可复用的接入方法论。1. 背景为什么架构治理需要专门的工具随着微服务架构的普及系统复杂度的增长速度往往远超团队的预期。刚开始可能只有几个服务彼此通过 REST API 通信结构清晰但当服务数量增长到几十个、上百个之后很多问题就会逐渐暴露出来服务之间的调用关系变得难以梳理没有人能说清楚某个核心业务链路到底依赖了多少个下游服务。模块边界被不断突破本该独立的领域模块开始互相引用内部类导致耦合越来越重。循环依赖反复出现A 服务调用 B 服务B 服务又反过来调用 A 服务任何一个接口变更都可能引发连锁故障。技术债缺乏量化手段老旧接口、废弃表、重复代码长期存在但没人知道哪些地方风险最高、最应该优先重构。在传统研发流程中这些问题通常依赖架构师人工评审、代码走查和文档维护。但人工方式有一个天然瓶颈架构是持续演进的而人脑对大规模依赖关系的记忆和判断能力有限。代码评审只能覆盖“变更点”很难评估“变更影响面”文档则往往在项目上线后就开始与实际代码脱节。这时候就需要一类专门面向架构治理的工具把代码结构、依赖关系、接口契约、运行指标等信息统一采集起来再做可视化分析和规则校验。tt-a1i / archify 正是这一类工具。它不等同于 SonarQube 这类代码静态检查工具也不等同于 SkyWalking 这类链路监控系统而是处于两者之间的“架构分析层”既关注代码级的依赖关系又关注服务级的调用拓扑帮助团队回答“系统当前真实架构是什么样”“是否偏离了目标架构”“哪些地方需要优先治理”。从实际落地场景来看这类工具最典型的应用时机有三个一是新项目启动时作为架构基线工具持续校验代码演进二是存量系统治理时先扫描现状识别高风险区域三是每次架构评审前用数据代替主观经验让评审更有依据。2. 核心概念tt-a1i 与 archify 分别是什么第一次接触 tt-a1i 和 archify 两个名字时很容易混淆。这里先梳理一下我对这两个名称的理解以及它们的定位差异。2.1 从命名理解两个名称的关系tt-a1i 看起来更像一个内部项目代号或者工具链名称tt 可能是 team/tech/tool 的缩写a1i 可以理解成“面向架构的 AI 辅助能力”强调的是智能化分析方向。而 archify 是 architecture 与 -fy 的组合直译就是“让架构变得可被分析、可被治理”更像对外发布的产品名或模块名。在同一套工具链中通常建议这样理解它们的关系tt-a1i 是整体的项目方案archify 是其中负责“架构分析与治理”的核心模块。也就是说你对外宣传时可能看到 archify 这个名字但底层数据采集、规则引擎、可视化面板等能力的集合又被团队统称为 tt-a1i。不同版本、不同团队对这两个名称的使用方式可能不同因此接入之前先看一遍官方 README 或产品文档中的术语说明能避免不少误会。2.2 工具的核心能力边界从能力边界来看tt-a1i / archify 这类架构治理工具通常覆盖四个层面第一个层面是代码与依赖采集。工具会分析指定项目中的包、类、接口、方法之间的调用关系生成代码级依赖图。对于 Java 项目会识别 Maven/Gradle 模块之间的依赖识别 jar 包和本地模块的引用关系对于微服务项目还能通过 HTTP 客户端、Feign、RestTemplate、Dubbo 等常用框架识别服务间调用。第二个层面是架构可视化。采集到的数据会聚合成不同层级的视图包括服务调用拓扑、模块依赖图、包依赖图、类依赖图。这种分层视图非常关键因为不同角色的关注点不同架构师关注服务级拓扑开发负责人关注模块级依赖一线开发关注包和类级别的耦合。第三个层面是规则校验。工具允许你预先定义架构规范比如“Controller 不允许直接调用 Mapper”“订单模块不能依赖支付模块的 internal 包”“禁止循环依赖”然后在每次扫描时自动检查违反规则则输出问题列表。这一能力实际上是把架构评审从“人治”变成了“规则自动化校验”。第四个层面是趋势分析。历史扫描结果被记录后可以观察架构指标的变化趋势比如循环依赖数量是上升还是下降、核心模块的扇入扇出是否恶化、依赖深度是否持续增加。这个能力对于技术债治理尤为重要因为它能回答“我们之前的重构是否真的有效”。2.3 典型应用场景基于上面的能力tt-a1i / archify 在真实项目里可以覆盖以下场景新服务上线前架构基线检查在 CI 流水线中增加一个 archify scan 步骤扫描结果不通过就不允许合并代码。存量系统架构梳理一个运行了五六年的老系统团队换过好几拨没人说得清服务间依赖关系。用工具扫描后自动生成拓扑图。模块化改造把单体应用拆分为多个业务模块时用规则校验来确保模块间只能通过定义好的接口通信。微服务拆分评估分析当前单体内的调用边界找出天然的拆分点避免凭感觉拆服务。技术债盘点与跟踪对每个服务输出架构健康分定位耦合最严重、最需要治理的模块。2.4 与其他工具的差异为了更清楚地理解 tt-a1i / archify有必要把它和几类常见工具做个对比。工具类型代表方向核心关注点和 archify 的区别代码静态检查SonarQube、Checkstyle、ESLint代码规范、Bug 模式、重复代码archify 更关注跨模块/跨服务的架构依赖关系架构测试框架ArchUnit在单元测试中校验包依赖规则archify 通常提供独立服务端和可视化不局限于测试阶段链路监控SkyWalking、Zipkin、Jaeger运行时调用链、性能指标archify 偏静态架构分析两者可以互补使用容器/云资源管理Kubernetes、Terraform部署、扩容、资源编排不属于同一层面但部署 archify 本身可能依赖这些基础设施这里要强调一点工具之间不是替代关系。比如 ArchUnit 适合在代码仓库内通过测试断言来强制约束依赖规则而 archify 这类独立工具更适合在更大范围、跨多个代码仓库的场景下做聚合分析和可视化。3. 环境准备与部署方式我们先把环境跑起来。由于 tt-a1i / archify 可能有多种部署形态本文以最典型、也最容易上手的 Docker Compose 方式为例目的是帮你快速在本地环境中完成一次全链路验证。3.1 环境清单建议准备以下基础环境操作系统LinuxCentOS 7 / Ubuntu 20.04、macOS 均可Windows 也可以通过 Docker Desktop 运行但路径挂载和脚本兼容性需要额外注意。Docker 与 Docker ComposeDocker 20.10Docker Compose v2 以上。资源要求最低 4 核 CPU、8GB 内存数据量较大的项目建议 8 核 16GB。目标分析项目一个 Maven 或 Gradle 构建的 Java 项目或者 Node.js 项目具体支持的生态以工具文档为准。JDK部分采集器可能要求本机具备 JDK 11用于执行类文件解析。如果你使用的是 Windows建议通过 WSL2 安装 Docker Desktop避免文件目录权限和路径分隔符导致的问题。此外解析大型项目时会产生较多临时文件建议给 Docker 数据目录预留至少 20GB 可用空间。3.2 快速部署方式这里给出一个 docker-compose.yml 示例。注意不同版本的 archify 镜像名、端口、环境变量可能存在差异请在官方文档中确认后再填入下面的模板。version: 3.8 services: archify-server: # 以官方镜像为准这里仅展示部署形态 image: archify/archify-server:latest container_name: archify-server restart: unless-stopped ports: - 8080:8080 environment: - ARCHIFY_DB_URLjdbc:mysql://archify-mysql:3306/archify?useUnicodetruecharacterEncodingutf8 - ARCHIFY_DB_USERarchify - ARCHIFY_DB_PASSWORDarchify123 - ARCHIFY_STORAGE/data/archify volumes: - archify-data:/data/archify depends_on: - archify-mysql archify-mysql: image: mysql:8.0 container_name: archify-mysql restart: unless-stopped environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: archify MYSQL_USER: archify MYSQL_PASSWORD: archify123 volumes: - archify-mysql-data:/var/lib/mysql ports: - 3306:3306 volumes: archify-data: archify-mysql-data:这个配置里做了几件事启动一个 archify-server 服务暴露 8080 端口用户可以直接通过浏览器访问 Web 控制台。启动一个 MySQL 8.0 实例作为元数据库存放项目、扫描记录、规则配置等数据。通过depends_on保证 MySQL 先启动但注意这只保证容器启动顺序不代表 MySQL 已经就绪。如果服务启动时连接数据库失败通常重启一次即可解决。保存为 docker-compose.yml 后执行docker compose up -d然后查看日志确认服务是否正常启动docker compose logs -f archify-server当日志中出现类似started successfully或Server started的输出时说明服务已经启动。3.3 验证服务是否启动成功打开浏览器访问http://localhost:8080。正常情况下会看到登录页面或初始化引导页面。首次使用时通常需要创建一个管理员账号请牢记账号密码并妥善保管。如果页面无法访问优先按以下顺序排查检查容器是否处于 running 状态docker compose ps查看日志中是否存在异常堆栈确认 8080 端口未被占用netstat -tunlp | grep 8080确认防火墙或安全组是否放行了该端口到这里服务端的部署就算完成了。下一步是让工具认识你的项目。4. 基础配置与首次分析服务端部署好之后需要配置需要分析的项目。这里涉及两个部分一是在 Web 控制台或配置文件中添加项目信息二是在项目代码目录中编写扫描配置文件。4.1 配置结构说明以常见的 Java 项目为例建议在最外层目录创建一个.archify.yml配置文件。它的作用类似于.gitignore和.eslintrc告诉工具应该扫描哪些代码、忽略哪些目录、执行哪些架构规则。下面是一个典型的配置示例project: name: order-service language: java build-tool: maven scan: base-package: com.example.order exclude: - **/target/** - **/generated/** - **/test/** include: - **/*.java rules: - id: R001 name: no-controller-repository level: error description: Controller 不允许直接注入 Repository - id: R002 name: no-cycle-dependency level: error description: 模块之间不允许存在循环依赖 - id: R003 name: forbid-internal-package-import level: warning description: 禁止跨模块引用 internal 包中的类这个配置文件包含核心的两大块project.scan定义扫描范围和过滤条件rules定义架构规则。配置之后工具会在扫描时自动把这个项目的源代码和依赖信息上传到 archify-server由服务端进行解析和聚合。4.2 配置项作用说明先看project.scan部分base-package指定从哪个 Java 包开始扫描。一般来说项目的根包是最合理的起点。exclude排除不需要分析的目录。target是构建产物generated是自动生成代码test是测试代码这些通常不会纳入架构分析范围。include限定参与分析的文件类型。对于 Java 项目就是**/*.java。再来看rules部分。每条规则由四个字段组成id规则唯一标识用于在报告中对问题定位。name规则的可读名称会显示在扫描结果页面。level问题级别。error级别会阻塞构建或导致扫描不通过warning级别只记录提醒不阻塞流程。description问题描述方便开发人员快速理解规则含义。对于「Controller 不允许直接注入 Repository」这条规则它背后反映的是分层架构约束。传统 MVC 架构中Controller 属于表现层Repository 属于数据访问层中间隔着 Service 层。如果 Controller 直接操作 Repository分层约束就被破坏了后续在 Service 层加入事务、缓存、权限控制时都会受到影响。4.3 首次运行分析配置写好后在项目根目录执行扫描命令。不同的接入方式命令有所不同下面是一个通用示例archify scan --config .archify.yml --project order-service --server http://localhost:8080 --token YOUR_ACCESS_TOKEN其中--config指向刚才创建的配置文件。--project指定项目名称。--server是 archify-server 的地址。--token是调用服务端 API 所需的安全令牌一般可以在 Web 控制台的个人中心生成。如果工具内置了命令行客户端也可以先执行archify login登录后再直接运行archify scan。扫描过程会经历几个阶段本地代码解析分析源文件中的包声明、import 语句、类继承关系。构建依赖解析读取 Maven 的pom.xml或 Gradle 的build.gradle生成模块依赖列表。数据上传将解析结果发送到服务端。服务端聚合分析将本次扫描结果与历史数据、规则库进行比对。输出报告生成问题列表、架构图和健康评分。首次扫描的耗时取决于项目规模。一个中等规模的微服务几十个模块、几千个类通常在几分钟内可以完成。扫描完成后Web 控制台会展示类似下面的摘要信息扫描类数量1234生成依赖边5678 条规则命中数12 条其中 error 2 条warning 10 条循环依赖数3 个架构健康分82 分满分 100到这里一次最基础的分析流程就闭环了。接下来我们通过一个更完整的实战场景看一下怎么把工具真正用起来。5. 完整实战订单系统的架构分析为了更直观地展示 tt-a1i / archify 的实战价值我准备了一个模拟的订单系统场景。这个场景包含一个常见的微服务项目结构和几个典型的架构问题包括复杂的模块依赖、Controller 绕过 Service 直接访问 Repository以及两个模块之间的循环依赖。下面我们从头走一遍完整分析流程。5.1 示例项目结构假设项目是一个 Maven 多模块工程目录结构如下order-system/ ├── pom.xml ├── .archify.yml ├── order-api/ │ └── src/main/java/com/example/order/api/ │ └── OrderController.java ├── order-service/ │ └── src/main/java/com/example/order/service/ │ ├── OrderService.java │ ├── OrderServiceImpl.java │ └── impl/ │ └── OrderDetailServiceImpl.java ├── order-dao/ │ └── src/main/java/com/example/order/dao/ │ ├── OrderRepository.java │ └── impl/ │ └── OrderRepositoryImpl.java └── order-common/ └── src/main/java/com/example/order/common/ └── utils/ └── OrderNoGenerator.java在这个结构里order-api 是对外暴露接口的 Web 模块order-service 是业务逻辑模块order-dao 是数据访问模块order-common 是公共工具模块。理想情况下依赖关系应该是order-api → order-service → order-dao ↓ order-common也就是说order-service 可以依赖 order-dao 和 order-commonorder-api 只依赖 order-service 和 order-commonorder-dao 和 order-common 是底层模块不应该反向依赖上层模块。5.2 编写分析配置针对上述项目编写.archify.yml。project: name: order-system language: java build-tool: maven scan: base-package: com.example.order exclude: - **/target/** - **/generated/** include: - **/*.java rules: # 规则 1Controller 不能直接访问 Repository - id: R001 name: no-controller-repository level: error description: Controller 层不允许直接注入 Repository # 规则 2禁止模块循环依赖 - id: R002 name: no-cycle-dependency level: error description: 业务模块之间不允许存在循环依赖 # 规则 3order-api 不允许依赖 order-dao - id: R003 name: api-layer-isolation level: error description: order-api 模块不允许直接依赖 order-dao 模块这里把规则级别都设置为 error是为了让问题在扫描阶段直接暴露出来方便演示。实际项目中建议新规则先用 warning 观察一段时间再逐步升级为 error。5.3 执行分析与结果解读运行扫描命令archify scan --config .archify.yml --project order-system --server http://localhost:8080 --token YOUR_ACCESS_TOKEN扫描结束后控制台输出大致如下Scan completed. Classes scanned: 8 Dependency edges: 23 Rule violations: [error] R001 - OrderController directly depends on OrderRepository (order-api - order-dao) [error] R002 - Cycle detected: order-service - order-common - order-service [error] R003 - order-api depends on order-dao三条规则全部命中说明当前项目确实存在架构问题。下面逐一分析。首先是 R001。代码中OrderController直接注入了OrderRepository绕过了OrderService。这种写法在功能上线初期往往能“省事”但后续如果需要在保存订单时增加库存扣减、优惠券核销、消息发送等逻辑就要到处修改。正确做法是在 Service 层封装完整的业务操作Controller 只负责参数解析和结果返回。其次是 R002。order-service依赖了order-common而order-common中又有代码反向依赖了order-service形成循环依赖。循环依赖的隐患在于模块之间的编译顺序会互相牵制且任何一个模块的变化都可能同时影响对方系统复杂度呈现非线性增长。最后是 R003。order-api作为 Web 层直接依赖了数据访问层。这说明 Web 层已经渗透到了持久化层分层边界被破坏。5.4 修复示例针对上述问题做一轮最小修复。第一步把OrderController中对OrderRepository的直接注入改为注入OrderService将数据访问逻辑收敛到 Service 层。// 文件路径order-api/src/main/java/com/example/order/api/OrderController.java RestController RequestMapping(/order) public class OrderController { private final OrderService orderService; public OrderController(OrderService orderService) { this.orderService orderService; } GetMapping(/{id}) public Order getOrder(PathVariable Long id) { // 只保留 Web 层职责真正的数据访问在 Service 层完成 return orderService.findOrderById(id); } }第二步处理order-common对order-service的反向依赖。通常的做法是判断这个反向依赖是否存在“必要且合理”的场景。如果是无意义的便捷方法引用直接移除或者下沉到更合适的模块如果确实需要说明公共模块的职责划分有问题可能需要把公共部分抽取到更底层的基础模块。修复之后重新执行扫描三条规则应被清零。此时架构健康分会明显提升。这一步体现了架构治理工具的价值它会快速暴露你可能一直忽略的风险同时把问题精确到具体的类和方法大大降低沟通成本。6. 常见问题与排查思路在实际使用过程中最容易遇到的几类问题如下按频率从高到低整理。建议收藏遇到类似报错时直接对照排查。问题现象常见原因解决思路扫描时提示无法连接服务端服务端未启动、防火墙拦截、网络不通检查docker compose ps和端口连通性确认--server地址是否正确扫描结果为空没有任何代码被发现base-package 配置错误或构建工具信息不准检查项目根包名与配置是否一致确认 build-tool 是 maven 还是 gradle依赖关系图和预期不符排除了太多目录或者没有正确解析构建配置先移除 exclude 试试确认 pom.xml / build.gradle 是否完整MySQL 连接失败导致服务无法启动数据库未就绪或密码不匹配查看服务日志重启 archify-server统一环境变量密码规则大量误报规则表达式过于宽泛未排除框架自动生成的代码细化规则范围将 generated、test 目录加入 exclude扫描时间过长项目规模大且未排除无关注目录优化 exclude拆分扫描范围按模块分批扫描命令找不到 archify未安装命令行客户端或 PATH 未配置将执行文件所在目录加入 PATH或使用./archify方式执行再展开一个典型场景如果你在 Jenkins 或 GitLab CI 中运行扫描经常会遇到“本地能跑CI 里扫描不到代码”的问题。这通常是因为 CI 的 workspace 里只拉取了代码仓库但没有执行依赖安装构建配置解析阶段失败。解决办法是在扫描前先执行一次依赖构建比如 Maven 项目执行mvn -q -DskipTests package或者 Gradle 项目执行gradle assemble -x test然后再运行 archify scan。还有一个容易被忽略的点如果项目使用的是 Java 17 及以上版本而 archify 的解析器默认按 Java 11 处理可能会在解析某些语法时产生警告。这时需要在配置文件中显式指定java.version: 17让解析器使用正确级别的语法规则。7. 工程化落地最佳实践工具安装好、跑通一次之后更大的挑战是把它真正融入到研发流程中。如果只是偶尔手动扫描价值会大打折扣。以下是我在实际落地过程中总结的几条工程化建议。7.1 分阶段接入不要一步到位第一次接入时不要把大量历史代码一次性纳入强校验。建议分三步走。第一阶段只做“现状扫描”。把项目接入 archify不开启任何阻塞性规则先让工具把所有依赖关系和架构视图生成出来团队熟悉工具输出。第二阶段开启“建议规则”。把常见的分层约束、循环依赖规则设为 warning观察一段时间评估误报率和团队接受度也可以慢慢积累符合自身架构风格的规则库。第三阶段启用“强制校验”。选择少量高置信度的规则设为 error嵌入 CI 流程作为合并请求的准入条件。后续再逐步扩展。这个节奏的关键在于优先关注高价值的极少数规则而不是把规则数量作为目标。即使只有三条硬性规则只要能和业务架构匹配也比一百条没人看的规则有意义。7.2 规则定制要与业务架构对齐不同公司、不同项目的架构风格差异很大。比如有些团队采用 DDD 分层会严格限制 Controller 层和 Infrastructure 层的依赖方向有些团队采用简单的三层架构规则相对宽松。最佳实践是让架构师牵头把“目标架构规范”转化为一套可执行的规则清单而不是照搬默认模板。在规则定制时还要注意异常场景。允许某些模块之间经过审批后的特殊依赖可以通过规则白名单或 ignore 配置显式豁免并记录豁免原因和责任人。这样既保持规则的严肃性又保留了必要的灵活性。7.3 与 CI/CD 集成推荐在合并请求阶段运行架构扫描而不是等到主干构建才检查。在 GitLab CI 中可以在.gitlab-ci.yml中加入如下模板architecture-scan: stage: test script: - mvn -q -DskipTests package - archify scan --config .archify.yml --project order-system --server ${ARCHIFY_SERVER} --token ${ARCHIFY_TOKEN} only: - merge_requests在 GitHub Actions 中也可以写一个类似的 workflow。关键点有几个在扫描前确保依赖已经构建完成。将ARCHIFY_SERVER和ARCHIFY_TOKEN放到 CI 的变量配置中不要硬编码到仓库里。如果在多模块仓库中每个子模块可以与各自的.archify.yml关联避免所有模块用同一套扫描规则。7.4 权限、安全与数据管理架构分析结果本质上属于企业内部的核心技术资产包含服务清单、依赖关系、潜在脆弱点。因此需要注意几点为不同角色分配最小权限普通开发只读自己的项目和扫描结果架构师和负责人拥有规则管理权限。访问令牌定期轮换使用自动生成的 token 而非个人密码。如果在私有化环境部署确保 archify-server 的数据库、对象存储都位于内网不暴露到公网。定期备份 MySQL 数据卷防止元数据丢失。涉及安全类规则比如识别敏感接口暴露时结果列表设置访问审计严格限制导出权限。7.5 性能优化与大规模仓库策略对于大型代码仓库一次全量扫描可能在时间和资源上都不可接受。这时可以采取以下策略按构建模块拆分扫描比如order-api、order-service分开执行再在服务端聚合依赖关系。使用增量扫描只分析变更集涉及的模块但需要注意增量扫描无法生成完整的全局依赖图适合高频快速校验不适合定期全量盘点。提高扫描频率但缩小范围每次合并请求扫描变更模块每周执行一次全量扫描。在大型项目上尽量将 archify-server 部署在与代码仓库或构建集群同一机房/区域减小网络延迟。7.6 让架构扫描结果真正被使用最后也是最重要的一条经验架构扫描结果如果不能进入团队日常协作流程就注定会被遗忘。建议在关键项目的 README 中放一个 archify 架构健康分徽章每次合并请求页面显示扫码结果。当健康分波动时责任模块的负责人能收到通知并需要在规定时间内解释原因或提交整改计划。架构治理不是一次性项目而是一个持续运营的工程实践。8. 总结与进一步学习通过这篇文章你应该已经对 tt-a1i / archify 有了一个比较完整的认识知道它解决什么问题明白它和代码扫描、链路监控的区别能在本地完成部署能把一个普通项目接入扫描还能看懂扫描报告中常见的架构问题。更重要的是你掌握了一套可复用的工程化落地方法——从分阶段接入、规则定制到 CI/CD 集成和安全规范。如果你正准备在团队中引入这类工具我的建议非常具体先不要追求大而全。挑一个中等规模、团队配合度较高的服务用两周时间完成现状扫描和规则试点每周回顾一次扫描结果收集团队反馈再决定是否扩展到全部门。这个过程中重点关注三个问题规则是否贴合真实架构、误报率是否在可接受范围、团队是否愿意按扫描结果修改代码。如果这三个问题都通过再大面积推广就有了扎实基础。下一步你可以继续学习的方向包括深入理解依赖分析引擎的解析原理特别是字节码分析对不同语言特性的支持研究如何把架构分析结果与运行时可观测数据调用链、错误率、延迟关联起来形成更立体的系统画像以及探索在微服务拆分、遗留系统现代化等大型改造项目中如何用架构治理工具辅助决策而不仅仅作为事后检查手段。技术实践本身并不复杂真正有价值的是把工具纳入团队长期的工程文化中。建议现在就找一个你负责或熟悉的服务部署一套 archify跑一次扫描看看你的系统在架构图上是什么样子。通常第一次看到真实依赖图时你会发现系统远比想象中复杂而这种“被看见”本身就是架构治理的第一步。