关于 architect-backend
面向多种后端技术栈的架构 Skill，供 Agent 检查代码库并规划或实施渐进式改动。它强调依据现有约束做决策，并保留合理的既有设计。
主要功能
- 01识别后端技术栈与结构
- 02重构前评估现有架构
- 03依据证据规划渐进式改动
- 04保留 API 与部署行为
- 05提供测试、迁移和回滚指导
适用场景
- 01重构前审查现有后端
- 02为新产品规划后端
- 03兼顾兼容性地调整服务边界
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/architect-backend确认已加载。
附带文件agents/openai.yamlreferences/architecture-guide.md
详细介绍
后端架构
可使用任何后端生态系统，包括 JavaScript/TypeScript、Python、Go、Java/Kotlin、C#/.NET、PHP、Ruby、Rust、Elixir、C/C++、Swift 服务端框架、无服务器函数及其他技术栈。不要默认采用 Node.js、Express、REST、关系型数据库或任何特定的目录结构。
首先：检测后端
在推荐架构或编写代码之前，检查完整的仓库。通过检查清单文件、源代码根目录、服务端或处理程序、路由或传输方式、领域逻辑、持久化、迁移、身份验证、配置、后台任务、集成、测试、部署文件和运维工具，判断是否已存在后端。
- 如果已存在后端，识别其语言和版本、框架/运行时、架构风格、包管理/构建工具、API 或消息接口、数据库/数据访问方式、模块边界、约定、测试、部署、可观测性以及已知的兼容性限制。保留现有的良好选择。
- 如果不存在后端，检查相关产品和需求，然后从头设计最精简且合适的后端，采用项目已选定的技术，或与用户明确选定的技术。
- 如果仓库包含多个服务，在提出共享变更或系统范围的变更之前，分别处理各个服务及其契约。
现有后端评估
进行重大重构之前，请说明：
- 当前结构 —— 请求、消息、任务、数据和依赖当前如何流转。
- 应保留的内容 —— 值得保留的合理选择和约定。
- 应更改的内容 —— 有仓库证据支持的具体问题。
- 建议的目标架构 —— 能解决这些问题的最精简架构。
- 更新路径 —— 按顺序渐进推进的步骤，并说明兼容性、迁移、测试、部署和回滚注意事项。
除非证据和用户目标确有需要，否则不要重写整个后端、引入新框架、拆分为微服务或强行采用时髦架构。如果用户要求实施，先简要给出评估，再按更新路径执行。
工作流
- 梳理入口、请求/消息/任务流、状态变更、依赖和外部契约。
- 识别所有权、耦合、内聚、重复、循环依赖、职责错位、扩展限制和运维缺口。
- 根据实际约束选择架构：团队规模、领域复杂度、流量、一致性、延迟、安全性、部署方式和预期变更。
- 选择满足请求的最小变更。结合现有风格，并仅在适当情况下考虑模块化单体、分层/MVC、功能模块、六边形/端口与适配器、事件驱动系统、无服务器架构或服务。
- 根据技术栈和问题需要分离传输、业务规则、数据访问、验证和序列化；避免没有价值的形式化分层。
- 渐进实施，并保留公共 API、消息、数据和部署行为，除非已批准破坏性变更。
- 如果契约或持久化数据发生变更，添加或更新迁移、兼容性和回滚处理。
- 运行该生态系统相关的格式化工具、检查工具/静态分析、编译器/类型检查器、单元/集成测试和构建。
- 汇报最终结构、决策、验证结果、迁移状态和剩余风险。
防护原则
- 集中管理配置，并在启动时验证必需的环境变量。
- 不要将机密信息放入源代码、日志和响应中。
- 在系统边界处进行验证，并根据经过验证的服务端上下文确定身份或授权。
- 将数据库和集成细节限制在明确的边界内。
- 除非代码确实得到复用，否则不要创建通用共享模块。
- 仅在抽象能够降低当前复杂度或支持具体扩展时才添加抽象。
- 保持命名、导入、文件扩展名、框架模式、工具链和运行时兼容性与代码库一致。
- 对许多新产品，优先采用模块化单体，除非独立部署或扩展边界已有充分依据。
- 将分布式系统、队列、缓存和微服务视为运维承诺，而不是默认的文件夹组织工具。
详细指南
当任务需要文件夹模板、特定框架示例、API 和数据库规则、身份验证或支付结构、审查清单或完整的架构建议时，请阅读 references/architecture-guide.md。按标题搜索该文件，仅加载当前任务相关的部分。
输出
首先说明是否发现现有后端。对于现有系统，请概述当前结构和安全的更新路径。对于新系统，请说明所选架构及其适用原因。区分已观察到的问题与可选改进。对于实现，请列出已更改的文件、兼容性或迁移工作，以及已执行的验证。