ailearneryang Requirements To Architecture
目标
该技能用于把需求文档稳定转换为架构文档，重点不是"写一篇大而全的说明文"，而是输出可以直接指导设计评审、接口设计和后续开发分层的架构结果。
何时使用
- 已有 PRD、需求规格说明书、
requirements/requirements_spec.md、功能清单或需求评审纪要，需要产出架构文档。 - 已有旧版架构文档，需要根据新增需求补全、重写或收口。
- 需要把业务需求映射为模块、接口、数据模型、部署拓扑和运行约束。
- 需要为 Android、IVI、车机、座舱域、中后台平台或通用业务系统给出务实的架构方案。
输入
执行前优先收集以下输入，缺一项时允许做显式假设：
- 需求主文档：例如
requirements/requirements_spec.md、PRD、需求规格说明书。 - 已有架构或设计文档：例如
design/architecture.md、design/api_design.md、design/data_model.md。 - 领域约束与基准文档：例如企业架构规范、平台约束、合规要求。
- 交付约束：运行环境、团队规模、周期、上线方式、兼容性要求。
默认输出
- 主输出优先写入用户指定路径。
- 若未指定路径，优先选择仓库既有命名约定：
design/architecture.md。 - 若用户同时要求接口与数据设计，可在此基础上继续补充
design/api_design.md与design/data_model.md，但主任务仍以架构文档为中心。 - 当补充
design/api_design.md与design/data_model.md时，必须与主架构文档保持术语、模块边界、状态机、错误码和集成边界一致，不能各写一套。 - 主架构文档优先基于
./assets/architecture-template.md组织结构；API 设计文档优先基于./assets/api-design-template.md；数据模型设计文档优先基于./assets/data-model-template.md。
执行步骤
- 读取需求与现有上下文。
- 提炼业务目标、FR、NFR、风险、假设与限制。
- 选择合适的架构模式并说明备选方案取舍。
- 完成系统上下文、模块、数据流、部署和关键动态行为设计。
- 按模板分别补齐架构、API、数据模型三份文档的结构化章节。
- 落实模块职责、接口约束、安全、可观测性、部署和演进策略。
- 使用模板自检是否缺失关键章节，如有缺口继续修订。
Android / IVI / 座舱专项规则
- 分层必须清晰，UI、Domain、Data、System Adapter 的依赖方向明确。
- 若同时存在轻量接口调用与大文件传输，必须给出双通道隔离策略。
- 安装、下载、升级、卸载等状态必须定义单一事实来源，避免前台状态臆造。
- 必须补充车辆状态、登录态、网络状态、存储空间、权限和后台运行限制的拦截设计。
- 必须给出启动耗时、内存、CPU、稳定性、恢复能力等资源预算或目标。
需求追溯标注规则
- 行内追溯使用纯文本括号格式，例如
（FR-001）或[FR-001]，不能使用 Markdown 引用链接语法（即不能写成[FR-001][FR-001]或在文末定义[FR-001]: ../requirements/...）。 - 文档末尾禁止出现任何形如
[FR-xxx]: path或[NFR-xxx]: path的链接定义块。 - 需求编号仅作为行内文本标注，不需要可点击链接。
输出质量要求
- 每个关键设计决策都应能追溯到需求、约束或风险。
- 文档应兼顾静态结构与动态行为，避免只有分层图没有运行链路。
- 架构方案必须能支撑后续 API 设计、数据模型设计、测试策略和代码结构。
- 若需求存在信息缺口，要显式写入"假设与限制"，不能静默忽略。