系统架构师副驾

它解决什么问题

架构设计文档的难点不在于写文档本身，而在于把 PRD 中的业务语言，转译成一套分层清晰、选型有据、边界明确的技术架构，并且能经受后续详细设计阶段的一致性检验。实际团队中，这部分工作往往依赖资深架构师的经验口头传承：模块为什么这样拆、接口为什么暴露成这样、部署为什么是这个拓扑，这些决策理由很少被完整记录。一旦架构师抽不出时间，详细设计就容易偏离基线，等到代码写完再补救，成本已经发生。

@user_15292d5a/yjkj-sa-copilot（SA Copilot Agent）就是针对这个断点设计的辅助角色。它把自己定位为有经验的系统架构师，但明确是辅助生成角色，最终决策权仍在真实的架构师手里。

它如何工作

它把架构工作拆成四个可通过 MCP 工具分别调用的子技能：sa_architecture_design、sa_api_design、sa_deployment_guide、sa_detailed_design_review。

• 系统技术架构总体设计：输入 PRD 与概念模型，按七个阶段渐进输出总体架构、分层架构、模块分解、接口架构、数据架构、部署架构和非功能架构，并附带 Mermaid 架构图与备选方案。
• 系统边界接口设计：把系统当作整体，分别定义对外暴露的接口、调用的外部接口和支撑边界的关键内部接口，分八个阶段输出边界接口设计文档。
• 部署实施指南：以架构设计规格书为基线，按需独立调用环境规划、CI/CD、监控日志、回滚与容灾四个子模块。
• 详细设计评审：对照架构规格书和 BA 业务资产，从架构一致性和需求覆盖完整性两个维度审查场景级详细设计，给出明确结论（Pass / Conditionally Pass / Fail）。

调用方式上有几个工程细节值得注意。每个子技能的第一次工具调用必须传 context='{"stage":"init"}'，服务端会返回一个路径确认 [ASK]，Agent 把问题转给用户、拿到回复后，第二次调用才能传真实的阶段参数，并在消息前加上 Base path: {path}，不能跳过 init。服务端在首次 MCP 响应中会注入 [PROTOCOL v=1.0]...[/PROTOCOL] 协议块，涵盖文档持久化、自动续跑、长任务等待、超时重试等机制，客户端解析缓存后在后续 context 里带上 proto":"1.0" 完成握手。这意味着它不是一个单轮问答工具，而是一个需要客户端正确配合的长流程编排服务。

适用边界

几个硬性约束写在行为规范里：不写业务代码，不设计 UI 视觉，不替代 BA 澄清需求，不替代真实架构师做最终决策。所有设计必须以 BA 或产品经理产出的业务资产为驱动，不得虚构业务需求逻辑或数据实体。遇到不确定的技术方案，必须标注为 To Be Verified，不能给出绝对的选型断言。因此它适合的场景很明确：PRD 已确认、需要产出标准化架构文档，或详细设计已成型、需要一次专业评审。如果需求本身还没收敛，直接用它反而会得到一份看起来很完整但地基是假设的文档。