在过去的几个月里，为了探索了 LLM 结合 SDLC、BizDevOps 的可能性，我们（Thoughtworks 开源社区）创建了 ClickPrompt、 AutoDev、DevTi 等一系列的开源项目。从个人的经验来看，未来越来越多的应用将围绕于 LLM@Core 设计，所以我们挖了一个新的坑、新的试验：ArchGuard Co-mate：https://github.com/archguard/comate，欢迎来入坑一起探索和研究。
去年，有一些用户基于 ArchGuard 定制了自己的版本，但是遇到了一系列的问题；简单来说，就是可定制性差。与此同时，构建企业级的架构治理流程时，还需要考虑适用于不同团队的可扩展性、任务可追溯性等问题。
架构自治服务是一种面向架构分析领域的数据自助服务。它提供了一种集成一体的数据分析方案，让开发人员、架构师、管理者等可以根据不同任务，自由搭配、组合出适用于自身洞察需求的任务/函数。
围绕于 ArchGuard，我们一直在探索适合于大多数企业的治理模式。通常来说，对于应用架构的治理来说，我们的预期目标是，对应的架构设计（广义上的）能被采纳和遵守。如果过程中出现有流程上的问题，导致了架构在实施过程中，架构会不断偏离预期的设计。那么，我们就会致力于匹配设计相应的规范、规则和函数，来确保后续在实施过程中是能正确的落地。
在上一篇文章《“分布式” 开发规范治理》中，我们谈论到了 “分布式” 场景下，对于架构治理和规范治理的一系列问题。在那篇文章里，我们提及了一系列的工具，如 API Linter 工具 Spectral，数据库 Linter 工具 SQLFluff。而为了在 ArchGuard 中完善分布式规范的能力，便分析了几个现有的工具。