diff --git a/Prompt模板/01_架构设计与分析模板库.md b/Prompt模板/01_架构设计与分析模板库.md
new file mode 100644
index 0000000..2f80d84
--- /dev/null
+++ b/Prompt模板/01_架构设计与分析模板库.md
@@ -0,0 +1,596 @@
+#### 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)**
+
+
+
+-----
+
+**模板名称：** `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的分析质量与此强相关（原则五）。
+ - `[对比维度]`：可根据实际需求增删，维度越具体，分析越深入。
+
+
+
+-----
+
+**模板名称：** `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需要计算“什么”。
+
+
+
+-----
+
+**模板名称：** `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)**
+
+
+-----
+
+**模板名称：** `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）。
+ - `[评审点]`：在评审时，提供你最关心的审查维度。
+
+
+
+-----
+
+**模板名称：** `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的布局和分组。
+
+
+
+-----
+
+**模板名称：** `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`。
+ - `[分析维度]`：可根据需求增删。
+
+
+
+-----
+
+**模板名称：** `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”，这是拓扑设计的核心依据。
+
+
+
+-----
+
+**模板名称：** `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“分析所有安全威胁”。
+
+
+
+-----
+
+**模板名称：** `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)**
+
+
+-----
+
+**模板名称：** `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将其选型“落地”为具体实现，避免空谈。
+
+
+
+-----
+
+**模板名称：** `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的核心产出。
+
+
+
+-----
+
+**模板名称：** `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)**
+
+
+-----
+
+**模板名称：** `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提供的不是一个“推倒重来”的方案，而是一个可执行的、渐进的计划。
+
+
+
+-----
+
+**模板名称：** `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），即你心中已有几个备选方案。
diff --git a/Prompt模板/02_代码实现与重构模板库.md b/Prompt模板/02_代码实现与重构模板库.md
new file mode 100644
index 0000000..f18024f
--- /dev/null
+++ b/Prompt模板/02_代码实现与重构模板库.md
@@ -0,0 +1,595 @@
+#### B. 类别二：代码实现与重构 (Implementation & Refactoring)
+
+**模板索引 (Index)**
+
+| 模板ID | 核心用途 | 使用场景 / 关键词 |
+| :--- | :--- | :--- |
+| **B-1: 环境配置与脚手架** | | |
+| **[`B1`](#B1)** | 构建系统与依赖配置 | CMake, 依赖管理, 构建脚本 |
+| **[`B2`](#B2)** | 类/模块脚手架生成 | 头/源骨架, Doxygen, OOP |
+| **B-2: 核心功能实现** | | |
+| **[`B3`](#B3)** | 规格到代码实现 | 需求转代码, 伪代码, 算法实现 |
+| **[`B4`](#B4)** | 串行代码并行化 | C++->CUDA, Kernel转换, 并行优化 |
+| **[`B5`](#B5)** | 复杂API/SDK集成 | MWE示例, 第三方库, 初始化/释放 |
+| **[`B6`](#B6)** | 防御性编码（接口依赖未就绪） | Stub, TODO, 假设注释, 接口占位 |
+| **B-3: 性能优化与重构** | | |
+| **[`B7`](#B7)** | 代码重构与现代化 | 智能指针, 模式重构, C++17/20 |
+| **[`B8`](#B8)** | 性能瓶颈分析与优化 | 热点函数, 复杂度, 优化策略 |
+| **[`B9`](#B9)** | CUDA Kernel 性能调优 | 显存访问, Occupancy, Warp |
+| **B-4: 健壮性与并发安全** | | |
+| **[`B10`](#B10)** | 错误处理与异常安全 | RAII, std::expected, 异常策略 |
+| **[`B11`](#B11)** | 并发安全分析与实现 | Data Race, mutex/atomic, 线程安全 |
+| **[`B12`](#B12)** | 日志与可观测性注入 | spdlog, tracing, 入口/出口日志 |
+| **[`B13`](#B13)** | 跨语言代码转译 | MATLAB->C++, Python->C++, 代码迁移 |
+
+**子类别 B-1: 环境配置与脚手架 (Setup & Scaffolding)**
+
+
+
+-----
+
+**模板名称：** `B1: 构建系统与依赖配置`
+**适用场景：** 在项目或模块初始化的第一步，需要为C++/CUDA项目生成一个健壮、可维护的`CMakeLists.txt`构建脚本。
+**内嵌原则：** `[原则七：结构化输出]` (输出必须是CMake代码), `[原则五：上下文即燃料]` (项目需求是关键)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通现代CMake (3.15+) 和C++/CUDA项目构建的专家。
+
+任务：请为我的新项目/模块生成一个 `CMakeLists.txt` 文件。
+
+== 项目需求 ==
+1. 项目名称：[例如：RadarProcessor]
+2. 目标类型：[例如：动态链接库 (SHARED Library) / 静态链接库 (STATIC Library) / 可执行文件 (Executable)]
+3. 目标名称：[例如：libRadarProcessor / radar_app]
+4. 源文件：[例如：src/*.cpp, src/cuda/*.cu] (可以使用通配符)
+5. C++ 标准：[例如：17]
+6. (可选) CUDA 标准：[例如：11]
+7. 依赖库 (使用 find_package)：
+ - [依赖1, 例如：Boost 1.80 REQUIRED COMPONENTS system thread]
+ - [依赖2, 例如：CUDA 12.0 REQUIRED]
+ - [依赖3, 例如：OpenCV 4 REQUIRED]
+8. (可选) 包含目录 (Include Directories)：[例如：include/, ${Boost_INCLUDE_DIRS}]
+9. (可选) 链接库 (Link Libraries)：[例如：${Boost_LIBRARIES}, ${CUDA_LIBRARIES}, ${OpenCV_LIBS}]
+
+== 输出要求 ==
+- 生成一个完整、格式良好、包含必要注释的 CMakeLists.txt 文件。
+- 必须使用现代CMake的最佳实践（例如，使用 target_link_libraries, target_include_directories）。
+```
+
+**填充指南：**
+
+ - `[项目需求]` 各项：**必须**根据你的实际项目情况进行精确填充。依赖库的查找方式（如 `find_package` 的 `COMPONENTS`）需要特别注意。
+ - **使用指南：** 此模板生成的是基础配置。对于更复杂的构建（如条件编译、安装规则），可以在此基础上应用 `[原则一：敏捷提示]` 进行迭代式求精。
+
+
+
+-----
+
+**模板名称：** `B2: 类/模块脚手架生成`
+**适用场景：** 根据LLD（低层设计）或接口定义，快速生成C++类或模块的`.h`（头文件）和`.cpp`（源文件）骨架，包含必要的成员、方法声明/定义以及Doxygen注释模板，减少重复性劳动。
+**内嵌原则：** `[原则七：结构化输出]` (输出必须是C++代码), `[原则五：上下文即燃料]` (设计是关键)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通现代C++ (例如 C++17) 和面向对象设计的软件工程师，熟悉Doxygen注释规范。
+
+任务：请为我生成一个C++类的完整脚手架（.h 和 .cpp 文件）。
+
+== 类设计规格 ==
+1. 类名：[例如：DataProcessor]
+2. (可选) 继承：[例如：public IProcessor]
+3. (可选) 命名空间：[例如：namespace radar::processing { ... }]
+4. 头文件 (.h) 要求：
+ - 包含必要的 #include (基于继承和成员类型猜测)。
+ - 包含类的声明。
+ - 包含 [构造函数/析构函数声明，例如：显式默认构造函数、虚析构函数]。
+ - 包含 [成员变量声明，例如：private: std::vector buffer_;]。
+ - 包含 [成员函数声明，例如：public: bool process(const InputData& data) override;]。
+ - **必须**为类、构造/析构函数、成员变量、成员函数添加Doxygen注释模板（包含 @brief, @param, @return 等）。
+5. 源文件 (.cpp) 要求：
+ - 包含必要的 #include。
+ - 包含所有成员函数的空实现（stub implementation），返回默认值（如false, 0, nullptr）。
+ - **必须**在实现上方包含对应的Doxygen注释。
+
+== 输出要求 ==
+* 分别提供 .h 文件和 .cpp 文件的完整内容，使用Markdown代码块包裹。
+```
+
+**填充指南：**
+
+ - `[类设计规格]` 各项：**必须**根据你的LLD进行填充。特别是继承关系和需要实现的成员函数列表。
+ - **使用指南：** 此模板旨在生成“骨架”。AI生成的空实现仅为占位符，需要工程师后续填充具体逻辑。Doxygen注释也需要工程师补充详细描述。
+
+-----
+
+**子类别 B-2: 核心功能实现 (Core Feature Implementation)**
+
+
+
+-----
+
+**模板名称：** `B3: 从“规格”到“代码”`
+**适用场景：** 这是最通用的“新需求开发”模板，用于将任何形式的清晰“规格”描述（Specification）——无论是数学公式、伪代码、Jira票据描述、还是自然语言步骤——转化为具体的工程代码。
+**内嵌原则：** `[原则五：上下文即燃料]` (规格质量决定代码质量), `[原则二：玻璃盒心态]` (可选：要求解释复杂逻辑), `[原则七：结构化输出]` (输出代码)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通 [目标语言，例如：C++17] 和 [相关领域，例如：信号处理算法] 的专家。
+
+任务：基于以下“规格”，请实现 [目标功能，例如：CFAR检测算法] 的核心逻辑。
+
+== 规格 (Specification) ==
+[粘贴你的规格描述。可以是：
+1. 数学公式 (LaTeX 格式)
+2. 伪代码 (如 2.3.1 中的 CFAR 伪代码)
+3. 清晰的自然语言步骤描述
+4. Jira Ticket / Requirement 文档片段
+]
+
+== 实现约束 ==
+1. 目标语言：[例如：C++17]
+2. (可选) 依赖库：[例如：必须使用 std::vector, 禁止使用 Boost]
+3. (可选) 性能要求：[例如：代码必须高效，避免不必要的内存分配]
+4. (可选) 健壮性要求：[例如：必须健壮地处理边界条件/错误输入]
+5. (可选) 接口要求：[例如：请将实现封装在一个函数/类中，函数签名/类定义如下：...]
+
+== 输出要求 ==
+- 提供 [目标语言] 的完整、可编译的代码实现。
+- (可选) 请在关键逻辑处添加必要的注释。
+- (可选, 应用玻璃盒原则) 如果算法复杂，请简要解释你的实现思路或关键步骤。
+```
+
+**填充指南：**
+
+ - `[目标语言]` 和 `[相关领域]`：明确AI的角色。
+ - `[规格]`：**这是核心燃料。** 规格越清晰、无歧义，AI生成的代码越符合预期。
+ - `[实现约束]`：用于精确控制AI的输出。例如，指定接口可以确保AI生成的代码能直接集成到你的项目中。
+
+
+
+-----
+
+**模板名称：** `B4: 串行代码并行化 (C++ -> CUDA)`
+**适用场景：** 解决团队核心痛点（痛点2）。用于将已在CPU上验证的、计算密集的C++串行算法（通常是循环），安全、高效地迁移为CUDA Kernel，并理解其并行化逻辑。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入C++代码), `[原则二：玻璃盒心态]` (强制解释并行化逻辑), `[原则七：结构化输出]` (输出CUDA代码)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通CUDA C++ (例如 CUDA 12.0) 和并行计算优化（特别是针对NVIDIA GPU）的专家。
+
+任务：请将以下C++串行代码改写为高性能的CUDA Global Kernel函数。
+
+== C++ 串行代码上下文 ==
+// [粘贴你的C++串行代码，例如 2.2.3 中的pulse_compression_cpu 函数]
+// 必须包含函数签名和核心逻辑实现。
+// 最好包含关于输入/输出数据规模的注释。
+
+== CUDA Kernel 要求 ==
+1. Kernel函数名：[例如：pulse\_compression\_kernel]
+2. 性能优化：
+ - [优化点1，例如：必须正确处理数据边界]
+ - [优化点2，例如：必须使用 Shared Memory 缓存 [某数据]，以减少 Global Memory 访问]
+ - (可选) [优化点3，例如：考虑使用 [某CUDA特性，如 warp intrinsics]]
+3. 启动配置建议：请为 Grid 和 Block 的维度划分提供一个合理的启动配置建议（基于假设的数据规模）。
+4. **解释要求 (玻璃盒原则)：**
+ - 请解释你为什么选择这样的 Grid/Block 划分。
+ - 请解释 [优化点2] (例如 Shared Memory) 的使用如何提升性能。
+ - 请在代码关键位置（如同步点 __syncthreads()）添加注释解释其必要性。
+
+== 输出要求 ==
+ - 提供完整的 CUDA Kernel 函数定义 (__global__ void ...)。
+ - 提供启动配置建议。
+ - 提供上述要求的解释。
+```
+
+**填充指南：**
+
+ - `[C++ 串行代码上下文]`：提供完整的、可工作的C++代码片段。
+ - `[CUDA Kernel 要求]`：**明确告知AI你的性能目标**。例如，显式要求使用Shared Memory，比让AI自己猜测效果更好。
+ - `[解释要求]`：**强制要求AI解释其并行化策略**，这是确保你理解并能维护该CUDA代码的关键（玻璃盒原则）。
+
+
+
+-----
+
+**模板名称：** `B5: 复杂API/SDK集成`
+**适用场景：** 当你需要在一个新项目中使用一个不熟悉的第三方库或SDK（如 `libtorch`, `cuFFT`, `gRPC Client`, `AWS SDK`）时，快速获取一个“最小可用示例”（Minimal Working Example, MWE），以理解其基本用法（初始化、核心调用、资源释放）。
+**内嵌原则：** `[原则五：上下文即燃料]` (指定库和目标任务), `[原则六：示例优先]` (AI生成示例), `[原则七：结构化输出]` (输出代码)。
+
+**[Prompt 模板]**
+```txt
+角色：你是一名精通 [目标库/SDK，例如：cuFFT v11.0] 和 [目标语言，例如：C++17] 的专家。
+
+任务：请为我生成一个使用 [目标库/SDK] 完成 [具体任务，例如：执行一个1D复数到复数的FFT变换] 的最小可用示例 (MWE) 代码。
+
+== 代码要求 ==
+1. 语言：[例如：C++17]
+2. 必须包含所有必要的 #include 语句。
+3. 必须展示：
+ - [步骤1，例如：如何正确初始化cuFFT Plan (cufftPlan1d)]
+ - [步骤2，例如：如何在GPU上分配输入/输出缓冲区 (cudaMalloc)]
+ - [步骤3，例如：如何将数据从CPU拷贝到GPU (cudaMemcpy HostToDevice)]
+ - [步骤4，例如：如何执行核心函数调用 (cufftExecC2C)]
+ - [步骤5，例如：如何将结果从GPU拷贝回CPU (cudaMemcpy DeviceToHost)]
+ - [步骤6，例如：如何进行必要的错误检查 (检查CUDA API返回值)]
+ - [步骤7，例如：如何释放所有分配的资源 (cufftDestroy, cudaFree)]
+4. 代码应尽可能简洁，只包含完成 [具体任务] 所必需的步骤。
+5. 请添加必要的注释解释关键步骤。
+
+== 输出要求 ==
+- 提供一个完整的、可直接编译（假设依赖已安装）的 [目标语言] 代码文件。
+```
+
+**填充指南：**
+
+ - `[目标库/SDK]`：**越精确越好**，最好包含版本号。
+ - `[目标语言]`：明确语言。
+ - `[具体任务]`：**明确告知AI你想用这个库做什么**。任务越具体，示例越有用。
+ - `[步骤1-7]`：列出你认为必须包含的关键步骤，指导AI生成完整的流程。
+
+
+
+-----
+
+**模板名称：** `B6: 面向接口的防御性编码`
+**适用场景：** 对应痛点4。当你正在实现模块A，而它依赖的模块B（通过接口 `IModuleB`）尚未完成时，用于强制AI生成包含明确假设、TODO标记和存根（Stub）的代码，严禁其“幻觉”出模块B的具体实现。
+**内嵌原则：** `[原则五：上下文即燃料]` (注入“模块B未完成”的元信息), `[原则七：结构化输出]` (强制特定的注释和存根格式)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通“面向接口设计”和“防御性编码”的C++专家。
+
+== 上下文 ==
+- 我正在编写 [模块A，例如：DataProcessor 类]。
+- [模块A] 依赖于 [接口B，例如：IDataSource 接口]。
+- 关键元信息： [接口B] 的具体实现类 目前尚未完成。
+
+== 任务 ==
+请为我编写 [模块A] 中的 [某个函数/方法，例如：process() 方法] 的实现。
+该方法需要调用 [接口B] 的 [某个方法，例如：getData(int id)]。
+
+== 黄金法则 (必须严格遵守) ==
+当你编写的代码需要调用 [接口B] 的方法时：
+1. 严禁“幻想” 或编造 [接口B] 实现类的任何内部逻辑。
+2. 你必须在调用的地方，按顺序插入以下三项内容：
+ - (a) 假设注释： // ASSUMPTION: 假设 [接口B] 的 [某个方法] 将返回 [预期行为/类型]。
+ - (b) TODO标记： // TODO ([模块B负责人姓名/Ticket号]): 待 [接口B] 实现完成后，此处需要解开注释/移除存根并正式耦合。
+ - (c) 占位符/存根： auto result = dataSource->getData(id); // <--- STUB: 返回模拟数据或注释掉
+
+== 开始吧 ==
+请根据以下需求，编写 [某个函数/方法] 的实现：
+[粘贴你的需求描述，例如：“process() 方法需要根据输入的id，调用dataSource->getData(id) 获取原始数据，然后...”]
+```
+
+**填充指南：**
+
+ - `[模块A]`, `[接口B]`, `[某个函数/方法]`：替换为你的具体名称。
+ - `[关键元信息]`：明确告知AI依赖未完成。
+ - `[黄金法则]`：**这是此模板的核心**。它提供了一个清晰的“替代模式”，阻止AI进行“幻觉补全”。
+ - `(a), (b), (c)` 中的占位符：根据实际情况填写，特别是TODO标记应指向负责人或关联的Jira Ticket。
+
+-----
+
+**子类别 B-3: 性能优化与重构 (Optimization & Refactoring)**
+
+
+
+-----
+
+**模板名称：** `B7: 代码重构与现代化`
+**适用场景：** 当需要对现有代码进行现代化改造（如 `C++98 -> C++17`）、应用设计模式（如 将`if-else`重构为策略模式）、或简化复杂函数（如 提取方法）以提高可读性、可维护性时。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入旧代码), `[原则七：结构化输出]` (输出新代码), `[原则二：玻璃盒心态]` (要求解释改动)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通现代C++ (例如 C++17/20) 和代码重构（Refactoring）模式的专家。
+
+任务：请将以下“遗留代码”重构为更现代化、更清晰、更易维护的版本。
+
+== 遗留代码 (Legacy Code) ==
+// [粘贴你需要重构的C++代码片段]
+// 最好包含必要的上下文注释，例如它属于哪个类/模块。
+
+== 重构要求 ==
+1. 目标C++标准：[例如：C++17]
+2. 核心重构指令：[例如：
+ - 将所有裸指针（new/delete）替换为智能指针（std::unique\_ptr 或 std::shared\_ptr）。
+ - 将所有手动索引for循环改为范围for循环。
+ - 将这个长函数分解为多个职责单一的小函数（应用Extract Method模式）。
+ - 将这个复杂的if-else/switch语句重构为[某个设计模式，例如：策略模式或工厂模式]。
+ ]
+3. 保持功能等价性（Functionally Equivalent）。
+4. 提高代码的可读性和可维护性。
+
+== 输出要求 ==
+1. 提供重构后的完整代码片段。
+2. **必须**简要说明你所做的关键改动及其理由（玻璃盒原则）。
+```
+
+**填充指南：**
+
+ - `[遗留代码]`：提供清晰的代码片段。
+ - `[核心重构指令]`：**这是关键**。你必须明确告知AI你期望的“重构目标”或“应用的模式”。指令越具体，结果越好。不要只说“请优化它”。
+ - `[目标C++标准]`：明确标准。
+
+
+
+-----
+
+**模板名称：** `B8: 性能瓶颈分析与优化`
+**适用场景：** 当通过性能剖析（Profiling）确定某段代码（“热点函数”）是性能瓶颈时，用于分析瓶颈原因（如 算法复杂度、内存访问模式）并获取优化建议。
+**内嵌原则：** `[原则二：玻璃盒心态]` (强制分析复杂度、瓶颈), `[原则五：上下文即燃料]` (输入热点代码), `[原则七：结构化输出]` (输出优化代码和分析)。
+
+**[Prompt 模板]**
+```txt
+角色：你是一名C++性能优化专家，精通算法、数据结构和底层系统（如缓存、内存）。
+
+任务：请分析并优化以下被确定为性能瓶颈的C++“热点函数”。
+
+== 热点函数代码 ==
+// [粘贴你的热点函数代码]
+// 最好包含关于输入数据规模和调用频率的注释。
+
+== 分析与优化要求 ==
+1. 复杂度分析： 请分析此函数的时间复杂度（Big-O notation）和空间复杂度。
+2. 瓶颈识别： 请指出这段代码的主要性能瓶颈在哪里？（例如：算法本身低效？循环内内存分配？缓存未命中？数据结构选择不当？）
+3. 优化建议： 请提供一个优化后的C++版本。
+4. 优化说明： 必须解释你的优化策略及其预期效果（玻璃盒原则）。
+
+== 输出要求 ==
+1. 复杂度分析结果。
+2. 瓶颈识别说明。
+3. 优化后的代码。
+4. 优化说明。
+```
+
+**填充指南：**
+
+ - `[热点函数代码]`：提供代码，并尽可能附带性能上下文（如 “此函数每秒调用1万次，输入向量大小可达10万”）。
+ - **使用指南：** 此模板侧重于CPU侧代码。对于GPU Kernel，应使用 `B9` 模板。
+
+
+
+-----
+
+**模板名称：** `B9: CUDA Kernel 性能调优`
+**适用场景：** `B8` 的GPU特化版。当需要对一个已有的CUDA Kernel进行深度性能分析和优化时，用于识别GPU特有的瓶颈（如 显存访问、线程束发散、占用率低）。
+**内嵌原则：** `[原则二：玻璃盒心态]` (强制分析GPU瓶颈), `[原则五：上下文即燃料]` (输入Kernel代码), `[原则八：自我批判]` (AI扮演HPC专家审查)。
+
+**[Prompt 模板]**
+```txt
+角色：你是一名顶级的CUDA性能优化专家（HPC工程师），精通NVIDIA GPU架构（如 Ampere/Hopper）。
+
+任务：请严格审查并优化以下CUDA Kernel代码的性能。
+
+== CUDA Kernel 代码 ==
+// [粘贴你的CUDA Kernel代码 (__global__ void ...)]
+// 最好包含关于启动配置 (Grid/Block大小) 和目标GPU型号的注释。
+
+== 性能审查与优化要求 ==
+请扮演“性能评审专家”，从以下GPU特定角度进行分析：
+1. 显存访问模式 (Memory Access Patterns)：
+ - Global Memory：是否存在非合并访问（Non-Coalesced Access）？如何改进？
+ - Shared Memory：是否存在岸冲突（Bank Conflicts）？如何规避？
+ - L1/L2 Cache：利用率如何？
+2. 计算与指令 (Compute & Instructions)：
+ - 线程束发散（Warp Divergence）：是否存在？如何减少？
+ - 指令吞吐（Instruction Throughput）：是否存在瓶颈（如 __syncthreads() 过多）？
+ - 特殊单元利用：是否可以利用 Tensor Cores 或其他专用单元？
+3. 占用率 (Occupancy)：
+ - 当前代码的理论占用率如何？（基于Block大小、寄存器使用量、共享内存使用量）
+ - 是否存在优化空间以提高占用率？
+
+== 输出要求 ==
+1. 针对上述3个方面的详细性能分析报告。
+2. 提供一个优化后的CUDA Kernel代码版本。
+3. 必须解释你所做的每一项关键优化及其背后的GPU架构原理（玻璃盒原则）。
+```
+
+**填充指南：**
+
+ - `[CUDA Kernel 代码]`：提供完整的Kernel实现。
+ - `[启动配置/GPU型号]`：提供这些信息有助于AI进行更精确的占用率和性能分析。
+ - **使用指南：** 这是D2模板中最复杂的一种。AI的回答质量高度依赖于其训练数据中CUDA优化的深度。建议结合NVIDIA Nsight Compute等工具进行验证。
+
+-----
+
+**子类别 B-4: 健壮性与并发安全 (Robustness & Concurrency)**
+
+
+
+-----
+
+**模板名称：** `B10: 错误处理与异常安全`
+**适用场景：** 当需要为一个仅实现了“理想路径”（Happy Path）的函数或类，添加健壮的错误处理逻辑，或者需要将C风格的错误码处理重构为现代C++的异常安全（RAII）或 `std::expected` 模式时。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入原代码), `[原则七：结构化输出]` (输出健壮代码), `[原则六：示例优先]` (可选：提供期望的错误处理模式示例)。
+
+**[Prompt 模板]**
+```txt
+角色：你是一名精通C++错误处理和异常安全（Exception Safety）设计的专家。
+
+任务：请为以下C++代码添加健壮的错误处理逻辑，或将其错误处理模式重构为 [目标模式]。
+
+== 原始代码 (仅Happy Path) ==
+// [粘贴你的原始C++代码片段]
+// 例如，一个包含 fopen, malloc, 或可能失败的外部调用的函数。
+FILE* open_and_process(const char* filename) {
+ FILE* fp = fopen(filename, "r");
+ // 假设此处没有检查 fp 是否为 NULL
+ // ... 其他处理 ...
+ return fp; // 假设调用者负责 fclose
+}
+
+== 错误处理要求 ==
+1. 目标模式：[例如：C++异常 (throw/catch), std::expected\ (C++23), 返回错误码 (int/enum), RAII (Resource Acquisition Is Initialization)]
+2. 必须处理 [潜在错误点1，例如：fopen 返回 NULL 的情况]。
+3. 必须处理 [潜在错误点2，例如：malloc 返回 NULL 的情况]。
+4. (对于RAII/异常) 必须确保资源（如文件句柄、内存）在错误发生时被正确释放（无泄漏）。
+
+== (可选) 期望的错误处理风格示例 (✅) ==
+// [粘贴一个你期望的错误处理风格的代码片段]
+
+== 输出要求 ==
+1. 提供添加/重构了错误处理逻辑后的完整代码。
+2. 简要说明你采用的错误处理策略。
+```
+
+**填充指南：**
+
+ - `[原始代码]`：提供代码。
+ - `[目标模式]`：**明确告知AI你期望的错误处理范式**。这是最重要的输入。
+ - `[潜在错误点]`：列出你已知的、需要处理的错误源。
+ - `[期望风格示例]`：可选，但强烈推荐（原则六）。提供一个示例能极大提高AI输出的风格一致性。
+
+
+
+-----
+
+**模板名称：** `B11: 并发安全分析与实现`
+**适用场景：** 针对新架构的多线程痛点。用于审查一个C++类或函数，分析其在多线程环境下的安全性，并自动添加必要的同步机制（如 `mutex`, `atomic`）。
+**内嵌原则：** `[原则二：玻璃盒心态]` (强制分析竞态条件), `[原则五：上下文即燃料]` (输入代码), `[原则七：结构化输出]` (输出线程安全代码和分析)。
+
+**[Prompt 模板]**
+```txt
+角色：你是一名精通C++并发编程（Multithreading）和内存模型（Memory Model）的专家。
+
+任务：请严格审查以下C++代码在多线程环境下的安全性，并将其修改为线程安全版本。
+
+== 待审查的代码 ==
+// [粘贴你的C++类或函数代码]
+// 例如，一个包含被多个方法读写的成员变量的类。
+class Counter {
+public:
+ void increment() { count_++; }
+ int get() const { return count_; }
+private:
+ int count_ = 0; // 风险点：非原子操作
+};
+
+== 并发安全要求 ==
+1. 分析： 请识别代码中所有潜在的“数据竞争”（Data Races）或“竞态条件”（Race Conditions）。明确指出哪些变量或操作在并发访问下是不安全的。
+2. 修复： 请提供一个线程安全（Thread-Safe）的版本。
+3. 同步机制选择： 请优先使用 [偏好的机制，例如：std::mutex / std::atomic / std::shared\_mutex]。
+4. 性能考量： (可选) 在保证线程安全的前提下，尽量减少锁的粒度或使用无锁（Lock-Free）技术（如果适用且安全）。
+
+== 输出要求 ==
+1. 并发安全问题的分析报告。
+2. 修复后的线程安全代码。
+3. 简要说明你选择的同步机制及其理由。
+```
+
+**填充指南：**
+
+ - `[待审查的代码]`：提供代码。
+ - `[偏好的机制]`：指定你团队倾向使用的同步原语，可以提高一致性。
+ - `[性能考量]`：可选。如果你对性能有极致要求，可以加入此项，但AI提供无锁代码的可靠性需要仔细验证。
+
+
+
+-----
+
+**模板名称：** `B12: 日志与可观测性代码注入`
+**适用场景：** 自动化软件开发中的重复性劳动。用于为指定函数或类的所有关键路径（入口、出口、错误分支）自动注入符合团队规范的日志或分布式跟踪代码。
+**内嵌原则：** `[原则七：结构化输出]` (输出注入代码), `[原则五：上下文即燃料]` (输入原代码和规范)。
+
+**[Prompt 模板]**
+```txt
+角色：你是一名熟悉 [日志库/跟踪库，例如：spdlog/OpenTelemetry C++] 和代码自动生成的工具开发者。
+
+任务：请为以下C++函数自动注入 [日志/跟踪] 代码。
+
+== 原始函数代码 ==
+// [粘贴你的原始C++函数代码]
+bool processData(const Input& input, Output& output) {
+ if (!input.isValid()) {
+ // 需要注入错误日志
+ return false;
+ }
+ // 需要注入入口日志/Trace Span开始
+
+ auto result = externalCall(input);
+ if (result.hasError()) {
+ // 需要注入外部调用错误日志
+ return false;
+ }
+
+ output = result.data;
+ // 需要注入出口日志/Trace Span结束
+ return true;
+}
+
+== 注入规范 ==
+1. 日志库/跟踪库：[例如：spdlog]
+2. 日志级别：[例如：入口/出口使用 info, 错误使用 error]
+3. 日志格式：[例如：必须包含函数名、输入参数的关键值、返回值/错误信息]
+4. (可选) 跟踪要求：[例如：在函数入口创建名为 "processData" 的 Span, 在所有出口结束 Span, 并在错误时设置 Span 状态为 Error]
+
+== 输出要求 ==
+ - 提供注入了 [日志/跟踪] 代码后的完整函数实现。
+ - 不要修改原始的业务逻辑。
+```
+
+**填充指南：**
+
+ - `[日志库/跟踪库]`：明确指定你团队使用的库。
+ - `[注入规范]`：**越详细越好**。提供你团队的日志格式、级别约定、跟踪要求等，AI才能生成符合规范的代码。
+
+
+
+-----
+
+**模板名称：** `B13: 跨语言代码转译`
+**适用场景：** 在算法预研或迁移阶段，需要将一种语言（通常是原型语言如 `MATLAB`, `Python/Numpy`）的代码逻辑，翻译为目标生产语言（如 `C++`, `CUDA`）。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入源语言代码), `[原则七：结构化输出]` (输出目标语言代码), `[原则二：玻璃盒心态]` (要求标注语言差异)。
+
+**[Prompt 模板]**
+```txt
+角色：你是一名精通 [源语言，例如：MATLAB] 和 [目标语言，例如：C++17 / CUDA] 的专家，擅长算法代码迁移。
+
+任务：请将以下 [源语言] 代码翻译为等效的 [目标语言] 代码。
+
+== 源语言代码 ([例如：MATLAB]) ==
+% [粘贴你的源语言代码片段]
+% 例如，一段包含矩阵运算、循环的MATLAB函数
+function output = process_signal(input_signal, filter_coeffs)
+ n = length(input_signal);
+ m = length(filter_coeffs);
+ output = zeros(1, n);
+ for i = 1:n
+ sum_val = 0;
+ for j = 1:m
+ if (i - j + 1 > 0)
+ sum_val = sum_val + input_signal(i - j + 1) * filter_coeffs(j);
+ end
+ end
+ output(i) = sum_val;
+ end
+end
+
+== 翻译要求 ==
+1. 目标语言：[例如：C++17]
+2. (可选) 目标库：[例如：请使用 Eigen 库处理矩阵/向量运算]
+3. 功能等价性： 翻译后的代码逻辑必须与源语言代码完全等价。
+4. 语言差异标注 (玻璃盒原则)： 必须在翻译后的代码中，使用注释明确标注出 [源语言] 和 [目标语言] 之间的关键差异点，例如：
+ - 数组索引的起始值（1-based vs 0-based）。
+ - 内存管理方式（自动 vs 手动/RAII）。
+ - 向量化操作的等效实现。
+
+== 输出要求 ==
+ - 提供完整的、功能等价的 [目标语言] 代码实现。
+ - 包含上述要求的语言差异标注注释。
+```
+
+**填充指南：**
+
+ - `[源语言]` 和 `[目标语言]`：明确指定。
+ - `[源语言代码]`：提供代码。
+ - `[目标库]`：如果目标语言依赖特定库（如 C++ 的 Eigen），请明确指出。
+ - `[语言差异标注]`：**这是此模板的核心价值**。强制AI标注差异，能帮助工程师避免因语言习惯不同而引入的 subtle bug。
diff --git a/Prompt模板/03_审查与质量保障模板库.md b/Prompt模板/03_审查与质量保障模板库.md
new file mode 100644
index 0000000..e2679b7
--- /dev/null
+++ b/Prompt模板/03_审查与质量保障模板库.md
@@ -0,0 +1,727 @@
+#### C. 类别三：代码审查与质量保障 (QA & Review)
+
+**模板索引 (Index)**
+
+| 模板ID | 核心用途 | 使用场景 / 关键词 |
+| :--- | :--- | :--- |
+| **C-1: 静态理解与逻辑分析** | | |
+| **[`C1`](#C1)** | 复杂逻辑解释 | __syncthreads, 模板元编程, 位运算, 正则解析 |
+| **[`C2`](#C2)** | 依赖与调用链分析 | include依赖, Call Graph, Mermaid |
+| **[`C3`](#C3)** | 接口与实现一致性审查 | 派生类签名校验, const/noexcept, 覆盖完整性 |
+| **C-2: 验证与测试用例生成** | | |
+| **[`C4`](#C4)** | 单元测试生成 | gtest脚手架, Happy/Edge, 异常测试 |
+| **[`C5`](#C5)** | 边界条件增强 | Edge cases, 负路径, 完备性检查 |
+| **[`C6`](#C6)** | 模拟数据/桩函数生成 | gmock, Mock类, 样例数据 |
+| **[`C7`](#C7)** | 集成/E2E测试脚本 | gRPC/REST脚本, 端到端验证 |
+| **C-3: 风险、安全与并发审查** | | |
+| **[`C8`](#C8)** | 潜在Bug与逻辑审查 | 逻辑缺陷, 资源泄漏, 越界 |
+| **[`C9`](#C9)** | 并发安全专项审查 | Data Race, 共享状态, mutex |
+| **[`C10`](#C10)** | 错误处理路径审查 | 资源释放, 返回值健壮性 |
+| **[`C11`](#C11)** | 安全漏洞专项审查 | 缓冲区溢出, 格式化字符串, 注入风险 |
+| **C-4: 迭代与代码评审** | | |
+| **[`C12`](#C12)** | 方案自我批判 | 缺陷/陷阱识别, 改进建议 |
+| **[`C13`](#C13)** | 可读性与规范评审 | 命名/风格/全局状态, 重构建议 |
+
+-----
+
+**子类别 C-1: 静态理解与逻辑分析 (Static Understanding & Analysis)**
+
+
+
+-----
+
+**模板名称：** `C1: 复杂逻辑解释`
+**适用场景：** `原则二：玻璃盒` 的核心应用。用于深入理解一个复杂的、难以读懂的代码块。例如：`2.2.4` 中的 `__syncthreads` 工作原理、C++模板元编程（TMP）、复杂的位运算技巧、或晦涩的正则表达式。
+**内嵌原则：** `[原则二：玻璃盒心态]` (核心), `[原则五：上下文即燃料]` (输入代码是关键)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通 [相关领域，例如：CUDA C++ / C++20 模板元编程 / POSIX并发] 的专家和技术导师。
+
+任务：请向我（一名有经验但非此领域专家的工程师）深入、清晰地解释以下代码片段。
+
+== 待解释的代码 ==
+[粘贴你无法理解的复杂代码片段。例如：
+__global__ void myKernel(...) {
+ // ...
+ extern __shared__ float s_data[];
+ s_data[threadIdx.x] = ...;
+ __syncthreads(); // <-- 重点解释这个
+ // ...
+}
+]
+
+== 解释要求 (玻璃盒原则) ==
+请严格按照以下结构回答：
+1. 核心功能 (What)： 这段代码（或特定行 [例如：__syncthreads()]） 的主要目的是什么？
+2. 工作原理 (How)： 它在技术/时序上是如何实现这一目的的？（请分步骤说明）
+3. 设计动机 (Why)： 为什么作者选择用这种（看起来很复杂）的方式来实现？它解决了什么性能/逻辑问题？
+4. 风险与“反面教材” (What If)： 如果 [例如：删除 __syncthreads() / 替换为其他实现]，会导致什么具体的错误或性能退化？（这是关键）
+```
+
+**填充指南：**
+
+ - `[相关领域]`：明确告知AI需要扮演的专家角色，例如 `CUDA C++`, `C++20 Concepts`, `Boost.Asio`。
+ - `[待解释的代码]`：粘贴你希望理解的代码。
+ - `[解释要求]`：**这是此模板的核心**。通过`What/How/Why/What If`结构，强制AI提供“深度、可操作”的解释，而非停留在表面的“它是一个同步原语”这种废话上（玻璃盒原则）。
+
+
+
+-----
+
+**模板名称：** `C2: 代码依赖与调用链分析`
+**适用场景：** 在进行重构、优化或接手遗留模块（痛点3）之前，需要快速理解其内部结构和外部依赖，绘制“架构地图”。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入文件是关键), `[原则七：结构化输出]` (强制输出结构化列表或图)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通C++代码静态分析的工具开发者。
+
+任务：请分析以下C++模块的源代码，并提供一份结构化的依赖和调用链报告。
+
+== 模块上下文 ==
+[粘贴你需要分析的代码，可以是一个.h文件、一个.cpp文件，或两者的组合]
+// 例如：
+// --- MyProcessor.h ---
+#include
+#include "IReader.h" // 外部依赖
+#include "utils/common.h" // 内部依赖
+
+class MyProcessor {
+public:
+ bool runPipeline(const Config& cfg);
+private:
+ void loadData(int id);
+ bool processBlock(std...);
+ IReader* reader_;
+};
+
+// --- MyProcessor.cpp ---
+#include "MyProcessor.h"
+#include // 外部依赖
+
+bool MyProcessor::runPipeline(const Config& cfg) {
+ if (!cfg.isValid) return false;
+ loadData(cfg.id); // 内部调用1
+ processBlock(...); // 内部调用2
+ return true;
+}
+// ... (其他实现) ...
+
+== 分析与输出要求 ==
+请严格按照以下格式输出：
+1. 外部依赖 (External Includes)：
+ - [例如：, , "IReader.h"]
+2. 内部依赖 (Internal Includes)：
+ - [例如："utils/common.h"]
+3. 调用链分析 (Call Graph)：
+ - 请为 [目标公共函数，例如：runPipeline] 生成一个调用链（直到私有函数）。
+ - (可选) 请使用Mermaid (graph TD) 格式展示。
+ - (示例) runPipeline --> loadData; runPipeline --> processBlock;
+```
+
+**填充指南：**
+
+ - `[模块上下文]`：粘贴你希望分析的源代码。代码越完整，分析越准确。
+ - `[目标公共函数]`：明确指定你希望分析的调用链入口点。
+ - **使用指南：** 此模板用于快速、静态地理解代码结构。对于大型复杂项目，AI的分析可能需要与IDE的“Find All References”功能结合使用。
+
+
+
+-----
+
+**模板名称：** `C3: 接口与实现一致性审查`
+**适用场景：** 在面向接口编程（痛点4）或代码审查（痛点3）时，确保一个实现类（Concrete Class）严格、完整地遵守了其接口（Interface）的约定。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入接口和实现), `[原则七：结构化输出]` (输出审查报告)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名严格的C++编译器和代码审查专家。
+
+任务：请严格审查以下 [实现类] 是否100%符合 [接口] 的定义和规范。
+
+== 接口定义 (.h) ==
+[粘贴接口的头文件内容，例如：IProcessor.h]
+// IProcessor.h
+class IProcessor {
+public:
+ virtual ~IProcessor() = default;
+ virtual bool initialize(const Config& cfg) = 0;
+ virtual int process(float* data) noexcept = 0;
+ virtual Status getStatus() const = 0;
+};
+
+== 实现类 (.h / .cpp) ==
+[粘贴实现类的头文件或源文件内容，例如：GpuProcessor.h]
+// GpuProcessor.h
+#include "IProcessor.h"
+class GpuProcessor : public IProcessor {
+public:
+ // 缺失 virtual 析构函数
+ bool initialize(Config& cfg); // 错误：Config 应该是 const&
+ int process(float* data); // 错误：缺失 noexcept
+ // 错误：缺失 getStatus() 的 const 实现
+};
+
+== 审查要求 ==
+请识别 [实现类] 中所有违反 [接口] 约定的地方，并以结构化列表形式返回：
+1. 缺失的实现： [例如：GpuProcessor 必须实现 getStatus() const]
+2. 签名不匹配： [例如：initialize() 的参数类型与接口不匹配 (应该是 const Config&)]
+3. 限定符不匹配 (const/noexcept)： [例如：process() 缺失了 noexcept 限定符]
+4. 其他违反（如析构函数）： [例如：GpuProcessor 缺少虚析构函数，可能导致内存泄漏]
+```
+
+**填充指南：**
+
+ - `[接口定义]`：提供基类（接口）的完整定义。
+ - `[实现类]`：提供派生类（实现）的定义。
+ - **使用指南：** 这是确保“面向接口编程”正确性的关键工具，能自动化捕获C++编译器可能（或可能不会）警告的微妙差异（如`noexcept`）。
+
+-----
+
+**子类别 C-2: 验证与测试用例生成 (Verification & Test Case Generation)**
+
+
+
+-----
+
+**模板名称：** `C4: 单元测试生成`
+**适用场景：** `2.4.2` 的核心模板。用于为新编写的函数或模块快速生成单元测试（Unit Test）的“脚手架”，解决工程师不愿写测试的痛点。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入原函数), `[原则七：结构化输出]` (输出gtest代码)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通C++和Google Test (gtest) 框架的软件质量保障（QA）工程师。
+
+任务：请为以下C++函数/类生成一套完整的gtest单元测试脚手架。
+
+== 待测试的代码 ==
+[粘贴你的函数签名或完整实现，例如：]
+#include
+#include
+
+// 函数：安全地将字符串转换为整数
+int stringToInt(const std::string& str) {
+ if (str.empty()) {
+ throw std::invalid_argument("Input string is empty");
+ }
+ try {
+ return std::stoi(str);
+ } catch (const std::exception& e) {
+ throw; // 重新抛出
+ }
+}
+
+== 测试要求 ==
+1. 测试框架：[例如：gtest]
+2. 必须包含必要的 #include (包括 "gtest/gtest.h" 和被测代码的头文件)。
+3. 必须包含一个 "Happy Path"（正常路径）测试用例 (例如：输入 "123")。
+4. 必须包含至少两个 "Negative Path" / "Edge Case"（异常/边界）测试用例 (例如：输入 "abc", 输入 "")。
+5. 对于预期抛出异常的测试，必须使用 EXPECT_THROW 宏。
+6. 提供完整的、可直接编译的 .cpp 测试文件内容。
+```
+
+**填充指南：**
+
+ - `[待测试的代码]`：提供代码。代码越完整（包含实现），AI生成的负面测试用例越准确。
+ - `[测试框架]`：明确指定，如 `gtest`, `pytest` (Python), `JUnit` (Java)。
+ - **使用指南：** AI生成的测试仅为“脚手架”，工程师必须审查其断言（Assertions）的正确性，并补充AI未能覆盖的业务逻辑边界。
+
+
+
+-----
+
+**模板名称：** `C5: 测试用例“边界条件”增强`
+**适用场景：** 对抗工程师“只写Happy Path”的惰性（痛点6）。当你已有一个（或AI刚生成）仅覆盖正常路径的测试时，使用此模板强制AI进行“批判性思考”，补充所有被忽略的边界条件。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入原测试), `[原则八：自我批判]` (AI扮演评审专家), `[原则六：示例优先]` (原测试作为示例)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名资深的、吹毛求疵的QA专家，擅长识别代码中的边界条件（Edge Cases）。
+
+任务：我已经为 [函数名] 编写了“Happy Path”测试。请严格审查此测试，并为其补充一套“完备的边界条件”测试用例。
+
+== 待测试的函数签名 ==
+[例如：std::vector movingAverage(const std::vector& data, int windowSize);]
+
+== 我已有的 "Happy Path" 测试 (✅) ==
+[粘贴你已有的简单测试代码]
+TEST(MovingAverageTest, HandlesNormalInput) {
+ std::vector data = {1.0, 2.0, 3.0, 4.0, 5.0};
+ int windowSize = 3;
+ std::vector result = movingAverage(data, windowSize);
+ // 假设结果是 {2.0, 3.0, 4.0} (简化)
+ EXPECT_EQ(result.size(), 3);
+ EXPECT_NEAR(result[0], 2.0, 0.001);
+}
+
+== 增强要求 (❌ 遗漏的) ==
+请为 [函数名] 补充以下所有被遗漏的、关键的边界条件测试：
+1. [边界1，例如：输入空的 std::vector (data.empty())]
+2. [边界2，例如：windowSize 为 0 或 负数]
+3. [边界3，例如：windowSize 大于 data.size()]
+4. [边界4，例如：windowSize 为 1]
+5. (可选) [边界5，例如：data 中包含 NaN 或 Inf 值]
+
+== 输出要求 ==
+ - 仅提供新生成的、用于覆盖上述边界条件的gtest TEST(...) 代码块。
+```
+
+**填充指南：**
+
+ - `[待测试的函数签名]`：提供函数签名，帮助AI理解上下文。
+ - `[我已有的 "Happy Path" 测试]`：提供一个示例（原则六），AI会模仿其风格。
+ - `[增强要求]`：明确列出你希望AI覆盖的边界类型。
+
+
+
+-----
+
+**模板名称：** `C6: 模拟数据/桩函数生成`
+**适用场景：** 在编写单元测试时（尤其是针对复杂数据结构或依赖接口的模块），手动创建模拟数据（Mock Data）或桩函数（Mock/Stub）非常繁琐。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入数据结构/接口), `[原则七：结构化输出]` (输出gmock代码或数据)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通 [框架，例如：gtest/gmock] 的测试工程师。
+
+任务：请为我生成 [目标：Mock类 / 模拟数据]。
+
+== 上下文 ==
+[粘贴你需要模拟的接口定义或数据结构定义]
+// 例如 (二选一)：
+// [上下文A：gmock]
+class IDataReader {
+public:
+ virtual ~IDataReader() = default;
+ virtual std::vector readData(int id) = 0;
+ virtual bool writeConfig(const Config& cfg) = 0;
+};
+
+// [上下文B：模拟数据]
+struct RadarTrack {
+ int track_id;
+ double x, y, z;
+ double vx, vy, vz;
+ std::string status;
+};
+
+== 生成要求 ==
+
+[任务A：生成 gmock 类 (基于上下文A)]
+1. 目标：为 IDataReader 接口生成一个完整的 gmock 类 MockDataReader。
+2. 必须包含所有 MOCK_METHOD 宏。
+
+[任务B：生成模拟数据 (基于上下文B)]
+1. 目标：生成一个C++代码片段，用于创建一个 std::vector。
+2. 要求：向量中必须包含 [数量，例如：5] 个示例对象，每个对象的数据必须是随机但合理的（例如，id递增，status为"active"或"lost"）。
+
+== 输出要求 ==
+- 提供完整的、可直接复制粘贴的C++代码块。
+```
+
+**填充指南：**
+
+ - `[上下文]`：**必须提供。** AI需要知道接口或`struct`的定义才能生成代码。
+ - `[任务A/B]`：**使用时请二选一**，删除你不需要的那个任务。
+ - `[数量]`：在生成数据时，指定你需要多少示例。
+
+
+
+-----
+
+**模板名称：** `C7: 集成/E2E测试脚本生成`
+**适用场景：** 当模块开发完成并暴露API（如gRPC或REST）后，需要快速编写一个“黑盒”测试脚本，从外部验证其端到端（E2E）功能是否符合预期。
+**内嵌原则：** `[原则五：上下文即燃料]` (输入API定义), `[原则七：结构化输出]` (输出脚本代码)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通 [语言/工具，例如：Python (grpcio) / Shell (grpcurl)] 的自动化测试工程师。
+
+任务：请为以下 [API类型，例如：gRPC服务] 编写一个端到端（E2E）测试脚本。
+
+== API 定义 ==
+[粘贴你的API定义，例如 .proto 文件内容]
+syntax = "proto3";
+package radar.api;
+
+service TrackService {
+ // 创建一个新航迹
+ rpc CreateTrack (CreateTrackRequest) returns (TrackResponse);
+ // 获取一个航迹
+ rpc GetTrack (GetTrackRequest) returns (TrackResponse);
+}
+
+message CreateTrackRequest {
+ int32 id = 1;
+ double x = 2;
+ double y = 3;
+}
+message GetTrackRequest {
+ int32 id = 1;
+}
+message TrackResponse {
+ int32 id = 1;
+ double x = 2;
+ double y = 3;
+}
+
+== 测试场景要求 ==
+脚本必须在 [语言/工具] 中实现以下E2E测试流程：
+1. [例如：Python] 导入必要的库 (如 grpcio)。
+2. [例如：Python] 创建一个到 localhost:50051 的 gRPC 通道。
+3. 步骤1 (创建)： 调用 CreateTrack RPC，创建一个 ID=101, x=1.2, y=3.4 的航迹。
+4. 步骤2 (验证)： 立即调用 GetTrack RPC，查询 ID=101。
+5. 步骤3 (断言)： 必须检查 GetTrack 返回的响应，确保其 x, y 值与创建时一致。
+6. 打印“测试通过”或“测试失败”的结论。
+
+== 输出要求 ==
+ - 提供完整的、可直接执行的 [语言/工具] 脚本代码。
+```
+
+**填充指南：**
+
+ - `[语言/工具]`：明确指定你希望用什么来测试，例如 `Python (grpcio)`, `Shell (grpcurl)`, `Python (requests)` (用于REST)。
+ - `[API 定义]`：提供`.proto`, `OpenAPI yaml` 或 API的文字描述。
+ - `[测试场景要求]`：**这是核心**。清晰描述你希望脚本执行的“步骤”，AI会将其翻译为代码。
+
+-----
+
+**子类别 C-3: 风险、安全与并发审查 (Risk, Security & Falsification)**
+
+
+
+-----
+
+**模板名称：** `C8: 潜在Bug与逻辑审查`
+**适用场景：** `2.4.6` 的核心模板。在代码审查（Code Review）阶段，利用AI作为“AI审查员”，自动扫描代码中常见的、容易被忽视的逻辑错误或风险。
+**内嵌原则：** `[原则八：自我批判]` (AI扮演评审专家), `[原则五：上下文即燃料]` (输入代码), `[原则七：结构化输出]` (输出结构化报告)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名资深的C++代码审查（Code Review）专家，尤其擅长发现内存安全和逻辑漏洞。
+
+任务：请严格审查以下C++代码，找出所有潜在的Bug、逻辑错误或未定义行为。
+
+== 待审查的代码 ==
+[粘贴你怀疑存在问题，或刚编写完成的C++代码片段]
+// 示例：一个包含多种常见错误的代码
+void process_array(int* data, int size) {
+ if (data = nullptr) { // 错误1：赋值而非比较
+ return;
+ }
+
+ for (int i = 0; i <= size; i++) { // 错误2：off-by-one 越界
+ if (size > 10) {
+ int* temp_buffer = new int[size]; // 错误3：资源泄漏
+ // ... (do something with temp_buffer) ...
+ if (data[i] > 100) {
+ // ...
+ }
+ }
+ }
+ // 错误3：temp_buffer 在循环结束后未被 delete[]
+}
+
+== 审查重点 ==
+1. 逻辑错误： 检查 if 判断（如 == 写成 =）、循环条件（如 off-by-one 错误）。
+2. 内存访问： 检查是否存在数组越界、空指针解引用（nullptr dereference）。
+3. 资源泄漏： 检查是否有 new/malloc/fopen 之后，在所有路径（包括异常路径）上都忘记 delete/free/fclose？
+
+== 输出要求 ==
+请严格按照“缺陷报告”的格式返回，逐条列出：
+ - [缺陷 1]： (例如：潜在的空指针赋值)
+ - [风险]： (例如：if (data = nullptr) 永远为false，且修改了入参指针)
+ - [修复建议]： (例如：应改为 if (data == nullptr))
+-----
+ - [缺陷 2]： (例如：循环条件越界)
+ - [风险]： (例如：i <= size 导致访问 data[size]，数组越界)
+ - [修复建议]： (例如：应改为 for (int i = 0; i < size; i++))
+-----
+ - [缺陷 3]： ...
+```
+
+**填充指南：**
+
+ - `[待审查的代码]`：提供你希望AI进行审查的代码片段。
+ - `[审查重点]`：你可以根据代码的特点，调整AI的审查优先级。
+ - **使用指南：** 此模板是`原则八：自我批判`的绝佳实践，在你自己（或AI）完成编码后，立即使用此模板进行交叉检查。
+
+
+
+-----
+
+**模板名称：** `C9: 并发安全专项审查`
+**适用场景：** 针对团队新架构（多线程服务器）的核心痛点（痛点2、痛点3）。在代码审查期间，专门用于分析一个类在多线程环境下的数据竞争（Data Races）风险。
+**内嵌原则：** `[原则二：玻璃盒心态]` (强制分析竞态条件), `[原则五：上下文即燃料]` (输入类定义), `[原则七：结构化输出]` (输出报告)。
+
+**[Prompt 模板]**
+
+```txt
+角色：你是一名精通C++17/20并发编程（Multithreading）和内存模型（Memory Model）的专家。
+
+任务：请严格审查以下C++类在多线程环境下的安全性。
+
+== 待审查的类定义 ==
+[粘贴你的C++类定义，包括.h和.cpp的相关方法]
+// 示例：一个线程不安全的计数器
+#include