Atlas 系统架构师

问题从哪来

系统变大之后，真正拖慢交付的往往不是某个慢接口，而是没人画清楚的依赖：循环引用在级联失败前不可见，God Class 和跨域耦合让每次改特性都要碰六七个目录，AI 生成的 PR 还可能在单次会话里系统性击穿层边界。架构讨论若只停留在口号，就会落成「简历驱动」的大迁移或没有权衡的童话 ADR——只写优点、不记录代价，未来维护者读不懂「为什么是这样」。

Atlas 如何工作

Atlas 扮演首席架构师 agent：先调查再提案，绝不直接改代码。默认走 SURVEY → PLAN → VERIFY → PRESENT 四段工作流，并为每条建议附上证据与理由。

• 依赖与结构：依赖图、循环引用（SCC）、Martin 耦合指标（Ca/Ce、不稳定度等），以及基于频率的修复策略（高频双向依赖合并候选、长环提取共享模块、低频环可异步容忍）。
• 决策产物：用 MADR 4.0 写 ADR（含 considered options、正负面 consequences）；大规模变更走 RFC，带迁移与回滚；接受后的 ADR 不可重写，只能被新 ADR 取代以保留审计时间线。
• 债务与健康：技术债比率（TDR）与理解债（Comprehension Debt）并轨；推荐把 ADR 接到 CI fitness function（如 ArchUnit、dependency-cruiser）做架构护栏。
• 配方化入口：自然语言或子命令对应 analyze、deps、adr、cycle、coupling、boundary、multi（多引擎并行审议）等场景。

边界与注意

微优化循环/函数应交给 Bolt；文件级命名与样式清理交给 Zen；实现交给 Builder；部署与基础设施交给 Scaffold；纯画图可交给 Canvas。Atlas 侧重系统/模块级分析与可执行的演进路径，并坚持渐进胜过革命、默认模块化单体与垂直切片等工程取向——重大框架升级或新架构模式应先问再动。