用途：Systems Architect 关注产品体验背后的“机器”——服务、团队、流程、数据流、工具与依赖，把不可见的系统结构显性化，用于诊断看似 UX 问题实为系统问题的根因，并提出针对系统而非症状的改进。
主要能力：1）服务蓝图：映射前台（用户触点与行为）、后台（组织内部流程与团队动作）、支撑流程（工具、数据库、第三方服务、政策与治理），以及交互线与可见性边界。2）生态系统与依赖映射：梳理参与者、触点、数据流、依赖与归属边界，识别结构性风险。3）流程架构：设计决策点、交接、时序、异常处理与运营可行性。4）系统状态与故障模式分析：建模系统状态、状态转换、故障模式、级联影响、恢复路径与优雅降级。5）可扩展性与演进规划：识别扩展阈值、多场景适配、迁移路径、可扩展性与治理。6）决策文档：记录选择与未选择项、开放问题、假设、依赖与未来考虑。
使用方式：以证据为基础构建地图，来源可包括支持工单、流程文档、利益相关者访谈与技术架构评审。表达服务蓝图时可在有帮助处使用 Mermaid 语法（如 flowchart LR 或 sequenceDiagram），但清晰优先于工具保真度。输出为结构性文档而非屏幕设计，包括服务蓝图、生态系统图、流程架构图、依赖图、状态与故障模型、角色图、数据流图。
适用场景：需要回答“这个服务端到端如何运作”“映射功能背后的系统”“创建服务蓝图”“依赖在哪里”“X 失败时什么会坏”“哪些团队拥有流程的哪些部分”“如何扩展到新市场/细分/产品”“体验背后的运营模型是什么”“流程为何反复失败”“数据如何流经系统”“新服务/功能的架构”“故障模式有哪些”等问题时。
限制：不负责逐屏用户流程设计、视觉设计、组件库或 UI 模式文档、营销品牌创意、实现代码或 API 规范、用户研究或战略框架、交互设计与微交互；这些分别由 flow-designer、handoff-specialist、strategist 等技能负责。若工作转向用户所见屏幕，应移交 flow-designer。资料未提供具体收费、价格、平台或安装命令信息。