#### A. 类别一：架构设计与分析 (Architecture & Design)

**模板索引 (Index)**

| 模板ID | 核心用途 | 使用场景 / 关键词 |
| :--- | :--- | :--- |
| **A-1: 需求与约束** | | |
| **[`A1`](#A1)** | 技术方案对比 | `gRPC vs REST`, `CUDA vs OpenCL`, `Kafka vs RabbitMQ`, 选型报告 |
| **[`A2`](#A2)** | NFR（非功能性）验证 | 瓶颈计算, 性能估算, 延迟验证, `PCIe`, 带宽, 信封计算 |
| **[`A3`](#A3)** | 需求澄清 (苏格拉底) | 需求模糊, 启动新模块, 收集约束, 提问模式 |
| **A-2: 高层架构 (HLD)** | | |
| **[`A4`](#A4)** | API 接口设计与评审 | `gRPC`, `REST`, `.proto`, `OpenAPI`, 接口定义, 评审 |
| **[`A5`](#A5)** | 流程/架构图生成 | `Mermaid`, `PlantUML`, 文本转图表, 数据流图, 序列图 |
| **[`A6`](#A6)** | 体系架构模式选型 | `微服务 vs 单体`, `事件驱动`, `CQRS`, 架构选型 |
| **[`A7`](#A7)** | 部署拓扑设计 | `Kubernetes`, `AWS`, `私有化`, 高可用 (HA), 部署图 |
| **[`A8`](#A8)** | 技术风险与威胁建模 | `STRIDE`, `DREAD`, 风险分析, 安全审查, 架构证伪 |
| **[`A9`](#A9)** | 成本与资源估算 | 容量规划, 成本模型, `TCO`, 资源预估, `AWS 估价` |
| **A-3: 低层设计 (LLD)** | | |
| **[`A10`](#A10)** | 数据模型/数据库选型 | `SQL vs NoSQL`, `时序数据库`, `Schema设计`, `CREATE TABLE` |
| **[`A11`](#A11)** | 组件间交互模式 | `同步 vs 异步`, `共享内存`, `gRPC vs 消息队列`, 接口契约 |
| **[`A12`](#A12)** | 系统级策略设计 | 错误处理, 日志规范, 重试策略, 幂等性, 横切关注点 |
| **A-4: 评审与迭代** | | |
| **[`A13`](#A13)** | 遗留系统重构 | 架构评审, 现代化, 绞杀者模式, 增量重构 |
| **[`A14`](#A14)** | 多方案优劣对比 | Pros/Cons, 决策矩阵, 方案对比 |

-----

**子类别 A-1: 需求与约束分析 (Discovery & Requirement)**

<a id="A1"></a>

-----

**模板名称：** `A1: 技术方案对比`
**适用场景：** 在架构设计（HLD）早期，当面临多个技术选项（如 `CUDA vs. OpenCL`, `gRPC vs. REST`, `Kafka vs. RabbitMQ`）时，需要一份客观、全面、且基于团队特定需求的对比分析报告。
**内嵌原则：** `[原则七：结构化输出]` (强制使用Markdown表格), `[原则五：上下文即燃料]` (依赖用户提供的精确需求), `[原则二：玻璃盒心态]` (要求AI列出分析依据)。

**[Prompt 模板]**

```txt
角色：你是一名精通 [领域，例如：异构计算/分布式系统] 的资深系统架构师。

任务：为我的团队提供一份关于 [技术选项A] 与 [技术选项B] 的技术选型对比报告。

== 核心业务上下文 ==
我们的核心需求是：
1.  [关键需求1，例如：极低延迟 (L_latency <= 100μs)]
2.  [关键需求2，例如：海量并行运算]
3.  [团队现状，例如：团队有C++基础，但GPU经验为零]
4.  [其他关键约束，例如：成本预算、部署环境等]

== 分析维度 ==
你必须从以下维度进行分析，并以Markdown表格形式呈现：
1.  [对比维度1，例如：性能与延迟]：(必须结合我们的[关键需求1]进行分析)
2.  [对比维度2，例如：开发复杂度与学习曲线]：(必须结合我们的[团队现状]进行分析)
3.  [对比维度3，例如：生态系统与维护成本]
4.  [对比维度4，例如：可扩展性与弹性]

== 最终交付 ==
1.  Markdown对比表格。
2.  基于上述所有分析的、明确的最终选型建议，并详细说明推荐理由。
```

**填充指南：**

  - `[领域]`：替换为AI需要扮演的专家角色，如“分布式系统”、“高性能计算”。
  - `[技术选项A/B]`：替换为具体技术，如 `gRPC` vs `RESTful API`。
  - `[核心业务上下文]`：**此部分至关重要**。必须提供清晰、量化的需求（NFRs）和团队现状，AI的分析质量与此强相关（原则五）。
  - `[对比维度]`：可根据实际需求增删，维度越具体，分析越深入。

<a id="A2"></a>

-----

**模板名称：** `A2: 非功能性需求（NFR）验证`
**适用场景：** 在架构设计早期，用于对关键的非功能性需求（NFR）进行“信封背面计算”（Back-of-the-envelope calculation），以快速验证架构假设的可行性（如 `2.2.2` 的PCIe瓶颈分析）。
**内嵌原则：** `[原则二：玻璃盒心态]` (强制要求展示计算步骤), `[原则五：上下文即燃料]` (所有计算依赖精确的上下文输入)。

**[Prompt 模板]**

```txt
角色：你是一名精通 [相关领域，例如：HPC/网络/数据库] 的性能分析专家。

== 架构上下文 ==
1.  [组件A，例如：x86 CPU (Host)]
2.  [组件B，例如：NVIDIA GPU (Device)]
3.  [连接方式，例如：PCIe Gen 4.0 (x16通道)]
4.  [数据流描述，例如：一个 256 MB 的数据块]

== 待验证的NFR（非功能性需求）==
* [关键指标，例如：端到端延迟 L_latency <= 100μs]

== 任务 ==
基于上述上下文，请对 [待分析的瓶颈，例如：PCIe数据传输延迟] 进行量化计算：

1.  计算 [组件/连接] 的理论峰值 [指标，例如：带宽 (GB/s)]。（请列出基准值）
2.  计算处理 [数据流描述] 所需的理论最小 [指标，例如：延迟 (μs)]。
3.  分析结论： 基于你的计算结果，分析 [待分析的瓶颈] 是否会突破我们的 [关键指标] 预算，或构成系统性能瓶颈。
4.  必须展示你的所有计算步骤和引用的公式/基准值。
```

**填充指南：**

  - `[相关领域]`：替换为AI需要扮演的专家角色。
  - `[架构上下文]`：必须提供所有相关的、**量化**的参数。
  - `[待验证的NFR]`：明确指出你的性能红线。
  - `[待分析的瓶颈]`：明确告知AI需要计算“什么”。

<a id="A3"></a>

-----

**模板名称：** `A3: 需求澄清与约束分析 (Socratic Mode)`
**适用场景：** 对应痛点3。当接到一个模糊的新需求（如“做一个日志模块”），在开始设计（HLD）之前，用于暴露工程师的思维盲点、强制AI收集完整上下文。
**内嵌原则：** `[原则三：苏格拉底模式]` (核心), `[痛点3：苏格拉底模式的非持久性]` (使用“状态机”模式解决)。

**[Prompt 模板]**

```txt
角色：你现在是一个“资深系统需求分析师”，不是一个“解决方案生成器”。

== 你的唯一目标 ==
从我这里获取关于 [我的模糊需求，例如：设计一个新的“XX”模块] 的完整、无歧义的需求规格。

== 你的行动循环（状态机） ==
1.  [提问] 你向我提出一组（不多于5个）最关键的问题，以收集必要信息。
2.  [等待] 我会回答你。
3.  [审查] 你必须审查我的回答。
4.  [循环/退出]
    - IF（信息不全）： 如果我的回答缺少关键信息（例如：性能、并发、数据、安全等约束），你必须回到[提问]状态，并只能向我追问缺失的特定信息。
    - IF（信息完整）： 只有当你确认所有NFR都已明确，你才能退出循环，并回复“需求收集完整，已准备好进行下一步设计。”

== 关键约束 ==
* 严禁在信息收集完整之前，提供任何解决方案、代码或设计建议。
* 如果你追问了3次，我仍然没有提供A，你应停止并报告：“我缺少A信息，无法继续。”

开始吧：
我的任务是 [我的模糊需求，例如：“我需要为我们的雷达系统设计一个日志模块”] 。
请开始你的[提问]。
```

**填充指南：**

  - `[我的模糊需求]`：替换为你接到的原始、模糊的任务描述。
  - **使用指南：** 工程师的角色是“回答者”。此模板的核心是“强制AI追问”。如果AI在中途“放弃”并提供了方案，请立即提醒它：“你违反了‘关键约束’，请继续提问。”

-----

**子类别 A-2: 高层架构设计 (High-Level Design)**
<a id="A4"></a>

-----

**模板名称：** `A4: API 接口设计与评审`
**适用场景：**

1.  **设计 (Creation):** 当你需要为新模块或服务从零开始设计一个健壮的、可扩展的API时（如 `gRPC`, `RESTful OpenAPI`）。
2.  **评审 (Review):** 当你有一个已存在的API定义（如 `.proto`, `yaml` 或 `.h` 文件），需要AI扮演评审专家，分析其设计缺陷。
    **内嵌原则：** `[原则七：结构化输出]` (强制生成代码/Schema), `[原则八：自我批判]` (在评审模式下), `[原则五：上下文即燃料]` (必须提供业务需求)。

**[Prompt 模板]**

```txt
角色：你是一名精通 [技术栈，例如：gRPC/RESTful API] 和 [领域，例如：C++高性能服务] 的系统架构师。

== 核心业务上下文 ==
* 模块/服务名称：[例如：RadarTrackService]
* 核心功能：[例如：负责接收、查询和管理雷达航迹数据]
* 关键NFRs：[例如：查询QPS高，写入延迟低，接口必须强类型]

== 任务 (二选一) ==

[任务A：设计新接口]
1.  请为该服务设计一套 [技术栈，例如：gRPC (.proto)] 接口。
2.  必须包含 [功能点1，例如：一个 CreateTrack RPC]。
3.  必须包含 [功能点2，例如：一个 GetTrackByID RPC]。
4.  设计必须考虑 [关键设计点，例如：幂等性、错误处理]。
5.  交付 [技术栈] 的完整代码定义。

[任务B：评审现有接口]
1.  这是我现有的接口定义：[粘贴你的.proto/OpenAPI yaml/.h文件内容]
2.  请严格审查此设计，识别所有潜在的设计缺陷。
3.  审查重点：
    - [评审点1，例如：API的健壮性/错误处理（Error Handling）]
    - [评审点2，例如：接口的幂等性（Idempotency）]
    - [评审点3，例如：命名规范与一致性]
    - [评审点4，例如：是否易于扩展（Extensibility）]
4.  以结构化列表形式返回 [缺陷]、[风险] 和 [修改建议]。
```

**填充指南：**

  - `[技术栈]`：明确指定，如 `gRPC (.proto)` 或 `RESTful API (OpenAPI 3.1 Spec)`。
  - `[领域]`：明确AI的专业背景。
  - `[核心业务上下文]`：必须提供，AI的设计质量依赖于此。
  - `[任务 (二选一)]`：使用时，请删除你不用的那个任务（A或B）。
  - `[评审点]`：在评审时，提供你最关心的审查维度。

<a id="A5"></a>

-----

**模板名称：** `A5: 流程/架构图生成`
**适用场景：** 在架构设计或文档编写时，需要将非结构化的文本描述（如会议纪要、设计思路）快速转换为结构化的、可维护的“代码图”（Diagrams as Code）。
**内嵌原则：** `[原则七：结构化输出]` (输出必须是代码), `[原则五：上下文即燃料]` (输入是文本描述)。

**[Prompt 模板]**

```txt
角色：你是一名精通 "Diagrams as Code" 工具的系统架构师。

任务：请将以下非结构化的“流程描述”，严格转换为 [图表工具] 语法的代码。

== 流程描述 ==
[粘贴你的流程描述文本。例如：
“数据首先进入ADC进行采样，采样后的I/Q数据被送到FPGA进行数字下变频和滤波。FPGA处理完的数据通过PCIe总线发送给CPU。CPU端的接收服务（Receiver Service）负责数据包的解包和重组，然后将数据块（Data Block）放入一个共享内存队列。GPU端的信号处理流水线（Signal Processing Pipeline）从队列中获取数据，依次执行脉冲压缩、多普勒处理（FFT），最后进行CFAR检测并输出目标列表。”
]

== 输出约束 ==
1.  图表工具：[例如：Mermaid]
2.  图表类型：[例如：Flowchart (graph TD)]
3.  (可选) 视觉要求：[例如：请将FPGA、CPU、GPU相关的组件分别放入不同的子图(subgraph)中]
4.  严禁返回除 [图表工具] 代码块之外的任何解释性文字。
```

**填充指南：**

  - `[流程描述]`：**描述越清晰，AI的布局越准确。**
  - `[图表工具]`：明确指定，如 `Mermaid` 或 `PlantUML`。
  - `[图表类型]`：明确指定，如 `Flowchart (graph TD)`, `Sequence Diagram`, `Component Diagram` 等。
  - `[视觉要求]`：可选，但非常有用。你可以用它来指导AI的布局和分组。

<a id="A6"></a>

-----

**模板名称：** `A6: 体系架构模式选型`
**适用场景：** 在HLD（高层设计）阶段，当面临（如 微服务 vs. 模块化单体）等根本性的架构模式抉择时，需要AI辅助分析不同模式在特定业务场景下的优劣。
**内嵌原则：** `[原则七：结构化输出]` (强制表格), `[原则五：上下文即燃料]` (业务场景是关键), `[原则二：玻璃盒心态]` (解释依据)。

**[Prompt 模板]**

```txt
角色：你是一名资深的企业架构师，精通各种软件架构模式。

== 核心业务上下文 ==
- 项目背景：[例如：构建一个大型、长生命周期的雷达信号处理与C2系统]
- 业务特征：[例如：包含多个独立的、功能复杂的领域（如：波形生成、信号处理、数据显示、航迹管理）]
- 团队结构：[例如：多个（~5个）小型、跨职能的开发团队]
- 关键NFRs：[例如：不同模块的可靠性（SLA）要求不同；信号处理模块需要独立扩展]

== 任务 ==
请对比 [架构模式A，例如：微服务架构] 与 [架构模式B，例如：模块化的单体架构] 在上述核心业务上下文中的适用性。

== 分析维度 (必须以此为准) ==
1.  性能与延迟 (Performance & Latency)
2.  可扩展性与弹性 (Scalability & Resilience)
3.  开发复杂度 (Development Complexity)
4.  团队认知负荷 (Team Cognitive Load) (必须结合[团队结构]分析)
5.  运维复杂度 (Operational Complexity)
6.  故障隔离能力 (Fault Isolation)

== 最终交付 ==
1.  一个包含上述所有维度的、详细的Markdown对比表格。
2.  一个明确的选型建议，并详细阐述其为什么最适合我们的[业务特征]和[团队结构]。
```

**填充指南：**

  - `[核心业务上下文]`：必须提供。AI的选型质量100%取决于你对业务和团队的描述是否准确。
  - `[架构模式A/B]`：替换为具体模式，如 `事件驱动架构` vs. `请求-响应架构`，`分层架构` vs. `CQRS`。
  - `[分析维度]`：可根据需求增删。

<a id="A7"></a>

-----

**模板名称：** `A7: 部署拓扑设计`
**适用场景：** 当HLD（高层设计）完成后，需要为系统设计一个满足特定NFR（特别是HA、DR、成本）的部署架构。
**内嵌原则：** `[原则五：上下文即燃料]` (NFR是设计的唯一依据), `[原则七：结构化输出]` (返回结构化列表)。

**[Prompt 模板]**

```txt
角色：你是一名精通 [技术栈，例如：Kubernetes/AWS] 的DevOps架构师（SRE）。

== 架构与NFRs（非功能性需求）==
- 系统架构：[例如：一个由 3个微服务 + 1个GPU密集型处理服务 + 1个PostgreSQL数据库 组成的C++系统]
- 部署环境：[例如：私有化数据中心（On-premise）的裸金属服务器]
- 关键NFR 1 (HA)：[例如：必须实现高可用性，能容忍单台服务器物理故障]
- 关键NFR 2 (Scalability)：[例如：GPU密集型服务必须能独立、水平扩展]
- 关键NFR 3 (Cost)：[例如：成本受限，优先利用现有硬件]

== 任务 ==
基于上述所有约束，请为该系统设计一个推荐的部署拓扑。

== 最终交付 ==
请结构化地返回以下信息：
1.  推荐的编排技术： [例如：K3s (轻量级Kubernetes), Docker Swarm, 或 纯Systemd管理] 并说明选择理由。
2.  核心组件拓扑：
    - (例如) 接入层：[如何实现，例如：使用Nginx/HAProxy做L4负载均衡和健康检查]
    - (例如) 无状态服务(3个)：[如何部署，例如：作为K8s Deployment, 副本数=3]
    - (例如) GPU密集型服务：[如何部署，例如：使用K8s的NVIDIA Device Plugin, 部署为DaemonSet或特定NodePool]
    - (例如) 数据库(PostgreSQL)：[如何部署，例如：使用Patroni/Stolon构建主从复制（HA）集群]
3.  关键风险： 指出此拓扑方案的一个主要风险点或运维难点。
```

**填充指南：**

  - `[技术栈]`：明确AI的专业背景，如 `Kubernetes`, `AWS`, `Azure` 或 `边缘计算`。
  - `[架构与NFRs]`：**必须提供。** 尤其是“部署环境”（公有云/私有化/边缘）和“NFRs”，这是拓扑设计的核心依据。

<a id="A8"></a>

-----

**模板名称：** `A8: 技术风险与威胁建模`
**适用场景：** 对一个已提出的架构设计方案（HLD或LLD）进行“证伪”和“压力测试”，主动识别其设计盲点、技术风险和安全威胁。
**内嵌原则：** `[原则八：自我批判]` (AI扮演评审专家), `[原则二：玻璃盒心态]` (强制AI分析)。

**[Prompt 模板]**

```txt
角色：你是一名资深的、吹毛求疵的首席工程师，精通技术风险识别和安全威胁建模。

== 架构方案上下文 ==
[粘贴你的架构设计方案描述。例如：
“我们设计了一个数据摄取服务。它暴露一个gRPC API (IngestData) 接收数据，数据首先被写入Kafka集群（TopicA），然后由一个GPU消费者（ConsumerA）订阅TopicA，进行处理后，将结果写入PostgreSQL数据库。”
]

== 任务 ==
请严格审查以上架构方案，从“技术风险”和“安全威胁”两个维度进行分析。

== 交付1：技术风险分析 ==
请识别此架构中潜在的技术风险（非安全类），至少包括：
1.  [风险1，例如：单点故障 (SPOF)]
2.  [风险2，例如：性能瓶颈]
3.  [风险3，例如：可扩展性限制]
(对每一项，请说明风险点和可能的缓解措施)

== 交付2：安全威胁建模 (STRIDE) ==
请使用 STRIDE 模型，分析此架构（特别是gRPC API和Kafka）的潜在安全威胁：
1.  Spoofing (仿冒)：
2.  Tampering (篡改)：
3.  Repudiation (否认)：
4.  Information Disclosure (信息泄露)：
5.  Denial of Service (拒绝服务)：
6.  Elevation of Privilege (权限提升)：
(对每一项，请分析可能的攻击向量和缓解措施)
```

**填充指南：**

  - `[架构方案上下文]`：**必须提供。** 描述越详细（组件、协议、数据流），AI分析越精确。
  - `[STRIDE]`：你也可以替换为 `DREAD` 或其他威胁建模框架，或者直接让AI“分析所有安全威胁”。

<a id="A9"></a>

-----

**模板名称：** `A9: 成本与资源估算`
**适用场景：** 在架构设计或预算规划阶段，需要对一个架构方案进行（通常是粗略的）硬件或云资源需求估算。
**内嵌原则：** `[原则二：玻璃盒心态]` (强制AI展示其估算依据), `[原则五：上下文即燃料]` (估算依赖于负载输入)。

**[Prompt 模板]**

```txt
角色：你是一名资深的云架构师和容量规划（Capacity Planning）专家。

== 架构方案 ==
[粘贴你的架构设计方案，例如：
1.  gRPC网关服务 (C++)
2.  GPU信号处理服务 (CUDA C++)
3.  PostgreSQL数据库 (用于元数据)
]

== 预估负载（NFRs）==
1.  [指标1，例如：并发请求数: 1000 QPS (峰值)]
2.  [指标2，例如：日处理数据量: 10TB/day]
3.  [指标3，例如：GPU处理时延: < 50ms per block]
4.  [指标4，例如：数据保留周期: 30天]

== 任务 ==
基于上述架构和预估负载，请为我估算部署此系统（以满足NFRs）所需的核心资源。

== 交付（结构化列表） ==
请返回一个估算列表，并必须说明你的估算依据（Rationale）：
1.  GPU处理服务：
    - (估算) GPU型号/数量：[例如：NVIDIA T4 / A100，xx卡]
    - (估算) 显存(VRAM)：[xx GB]
    - (估算) 服务器RAM：[xx GB]
    - (Rationale)：[解释你为什么这么估算，例如：基于[指标3]和[指标2]...]
2.  gRPC网关服务：
    - (估算) CPU核数/RAM：[xx vCPU / xx GB]
    - (Rationale)：[解释，例如：基于[指标1]处理网络I/O...]
3.  PostgreSQL数据库：
    - (估算) 存储空间：[xx TB]
    - (Rationale)：[解释，例如：基于[指标4]...]
```

**填充指南：**

  - `[预估负载（NFRs）]`：**估算质量的唯一依据。** 你提供的数字越精确，AI的估算越有价值。如果缺少数据，AI的回答也会是“幻觉”。
  - `[Rationale]`：强制AI解释其计算过程，这是“玻璃盒”原则的体现，能让你判断它的估算是否合理。

-----


**子类别 A-3: 低层模块设计 (Low-Level Design)**
<a id="A10"></a>

-----

**模板名称：** `A10: 数据模型与数据库选型`
**适用场景：** 在LLD（低层设计）阶段，需要为特定数据（如：雷达航迹、I/Q原始数据、配置参数）设计存储Schema，并对比不同数据库技术（如 时序库 vs. 关系库 vs. 缓存）的适用性。
**内嵌原则：** `[原则七：结构化输出]` (强制Schema和表格), `[原则五：上下文即燃料]` (数据特征是关键), `[原则二：玻璃盒心态]` (解释依据)。

**[Prompt 模板]**

```txt
角色：你是一名精通数据建模和数据库架构的专家（DBA）。

== 数据特征与业务上下文 ==
1.  数据类型：[例如：雷达目标航迹数据]
2.  核心实体与字段：[例如：Track (TrackID, x, y, z, vx, vy, vz, timestamp)]
3.  主要读操作：[例如：高频的“按时间范围”和“按TrackID”查询]
4.  主要写操作：[例如：高并发、持续的“追加写入”（Append-only）]
5.  数据量/增长率：[例如：每天新增 1 亿条航迹点]
6.  一致性要求：[例如：最终一致性即可]

== 任务 ==
基于上述特征，请完成以下工作：
1.  技术选型： 对比 [技术A, 例如：时序数据库 InfluxDB] 和 [技术B, 例如：关系型 PostgreSQL] 在此场景下的优劣（以Markdown表格呈现）。
2.  选型建议： 给出明确的选型推荐及理由。
3.  Schema设计： 基于你的推荐，为 [核心实体] 设计一个推荐的数据模型或Schema（例如：InfluxDB的Line Protocol, 或PostgreSQL的CREATE TABLE语句）。
```

**填充指南：**

  - `[数据特征与业务上下文]`：**此部分至关重要**。你对读/写操作、数据量、一致性要求的描述，将直接决定AI的选型质量。
  - `[技术A/B]`：明确你正在纠结的选项。
  - `[Schema设计]`：此项强制AI将其选型“落地”为具体实现，避免空谈。

<a id="A11"></a>

-----

**模板名称：** `A11: 组件间交互模式定义`
**适用场景：** 在LLD（低层设计）阶段，需要明确定义两个模块（如 模块A 和 模块B）之间的通信机制和数据契约（Data Contract）。
**内嵌原则：** `[原则七：结构化输出]` (强制.proto或API定义), `[原则五：上下文即燃料]` (交互需求是关键)。

**[Prompt 模板]**

```txt
角色：你是一名精通C++和分布式系统设计的软件架构师。

== 交互上下文 ==
* 发送方 (Caller)：[例如：模块A (RadarControlService)]
* 接收方 (Callee)：[例如：模块B (GpuProcessingService)]
* 交互内容：[例如：模块A需要向模块B下发“处理配置参数”]
* 关键NFRs：
    1.  [NFR 1, 例如：低延迟（< 1ms）]
    2.  [NFR 2, 例如：强类型校验，防止配置错误]
    3.  [NFR 3, 例如：需要支持异步调用]

== 任务 ==
1.  模式对比： 基于上述NFRs，对比 [模式A, 例如：同步gRPC] 和 [模式B, 例如：异步消息队列 (Kafka)] 的优劣（Markdown表格）。
2.  模式推荐： 给出明确的推荐及理由。
3.  接口定义： 基于你的推荐（假设推荐gRPC），请为 [交互内容] 设计一个 [接口定义文件，例如：.proto] 文件，包含必要的服务和消息定义。
```

**填充指南：**

  - `[交互上下文]`：必须清晰定义谁调用谁、干什么、有什么要求。
  - `[模式A/B]`：替换为具体的交互模式，如 `共享内存` vs. `gRPC`，`RESTful` vs. `WebSocket`。
  - `[接口定义文件]`：强制AI生成“数据契约”，这是LLD的核心产出。

<a id="A12"></a>

-----

**模板名称：** `A12: 系统级策略设计`
**适用场景：** 在LLD（低层设计）阶段，用于设计跨多个模块的“横切关注点”（Cross-Cutting Concerns），如日志、错误处理、重试等，以确保系统行为一致性。
**内嵌原则：** `[原则六：示例优先]` (提供示例), `[原则七：结构化输出]` (输出规范)。

**[Prompt 模板]**

```txt
角色：你是一名资深的C++首席工程师，负责制定团队的工程规范。

任务：请为我们的系统设计一个统一的 [策略名称，例如：错误处理策略]。

== 策略要求 ==
1.  背景：[例如：我们的系统是基于现代C++20构建的，但混合了部分C库]
2.  目标：[例如：统一C++层和C库层的错误，提供清晰的、可被上游服务消费的错误信息]
3.  禁止：[例如：禁止使用裸错误码（Magic Numbers），尽量避免过度使用异常（Exceptions）]

== 交付产出 ==
1.  推荐的策略： [例如：推荐使用 std::expected (C++23) 或类似的 Either Monad]
2.  设计理由： 为什么此策略优于 [其他方案，例如：纯异常 或 纯错误码]？
3.  代码示例 (✅)： 提供一个“最佳实践”的代码示例，展示函数应如何返回错误。
4.  代码示例 (❌)： 提供一个“反模式”的代码示例，展示应避免的写法。
5.  规范定义： 提供一份简短的Markdown规范，供团队成员遵守。
```

**填充指南：**

  - `[策略名称]`：替换为你需要设计的策略，如 `日志记录规范`, `分布式跟踪策略`, `幂等性实现策略`, `断路器设计`。
  - `[策略要求]`：提供你对该策略的约束和目标。
  - `[代码示例 ✅/❌]`：这是“示例优先”原则的应用，强制AI提供清晰的“Do / Don't”指南。

-----

-----

**子类别 A-4: 评审与迭代 (Review & Iteration)**
<a id="A13"></a>

-----

**模板名称：** `A13: 现有架构评审与重构建议`
**适用场景：** 当需要接手或重构一个遗留系统时，用于快速分析其架构现状、识别核心痛点，并提出一个可行的、渐进式的重构方案。
**内嵌原则：** `[原则八：自我批判]` (AI扮演评审委员会), `[原则五：上下文即燃料]` (现状描述是关键), `[原则二：玻璃盒心态]` (分析问题根源)。

**[Prompt 模板]**

```txt
角色：你是一个由多名资深架构师组成的“架构评审委员会”。

== 遗留系统上下文 ==
[粘贴你对遗留系统的描述。例如：
“我们有一个C++单体应用（LegacySystem），它有20万行代码。所有模块（数据采集、信号处理、界面显示）都耦合在同一个进程中。
核心痛点：
1. 编译时间极长（> 30分钟）。
2. 信号处理模块（高CPU）和界面显示（低CPU）无法独立扩展。
3. 任何小修改都可能导致全局不稳定，测试回归成本极高。”
]

== 任务 ==
请基于上述上下文，对该遗留系统进行架构评审。

== 交付（结构化报告） ==
1.  核心问题诊断 (Diagnosis)：
    - (AI分析) [例如：1. 高度耦合（Coupling）；2. 缺乏清晰的模块边界...]
2.  长期重构目标 (Target State)：
    - (AI建议) [例如：建议演进为“模块化单体”或“微服务”架构]
3.  渐进式重构方案 (Incremental Plan)：
    - (AI建议) [例如：推荐采用“绞杀者无花果模式”（Strangler Fig Pattern）。
    - 步骤1：[例如：在单体应用前部署一个“反向代理”（Proxy）...]
    - 步骤2：[例如：将第一个模块（如“界面显示”）拆分为新服务，由Proxy路由...]
    - 步骤3：[...]]
4.  主要风险： 指出此重构方案的最大风险。
```

**填充指南：**

  - `[遗留系统上下文]`：**必须提供。** 描述越详细，尤其是“核心痛点”越清晰，AI的诊断和建议越有价值。
  - `[渐进式重构方案]`：这是此模板的核心。它要求AI提供的不是一个“推倒重来”的方案，而是一个可执行的、渐进的计划。

<a id="A14"></a>

-----

**模板名称：** `A14: 多方案优劣对比 (Pros/Cons Analysis)`
**适用场景：** 一个通用的“决策辅助”模板。当工程师在多个（已知的）选项之间犹豫不决时，用于代替（或补充）`A1`模板，快速获取一份无偏见的、结构化的对比矩阵。
**内嵌原则：** `[原则七：结构化输出]` (强制表格), `[原则五：上下文即燃料]` (选项和场景是关键)。

**[Prompt 模板]**

```txt
角色：你是一名客观、严谨的技术分析师。

== 决策上下文 ==
- 我们的目标：[例如：实现一个高可用的PostgreSQL数据库]
- 我们的约束：[例如：部署在私有化K8s集群上]

== 待评估的选项 ==
- 选项A：[例如：使用 Patroni (基于Etcd/Consul)]
- 选项B：[例如：使用 Stolon (基于Etcd/Consul)]
- 选项C：[例如：使用云厂商（如AWS）的RDS Operator]

== 任务 ==
1.  请为我生成一个详细的Markdown对比表格，比较上述三个选项。
2.  对比维度必须包括：
    - [维度1，例如：架构复杂度]
    - [维度2，例如：社区活跃度/成熟度]
    - [维度3，例如：自动故障切换（Auto-Failover）能力]
    - [维度4，例如：与K8s的集成度]
3.  根据我们的 [约束]，给出每个选项的“推荐指数”（例如：高/中/低）并说明理由。
```

**填充指南：**

  - `[待评估的选项]`：由工程师（你）提供。
  - `[对比维度]`：由工程师（你）提供。
  - **使用指南：** 此模板与`A1`的区别在于，`A1`更侧重于“技术选型”（从0到1），而`A14`更侧重于“方案决策”（从1到N），即你心中已有几个备选方案。