Inbox/Prompt模板/01_架构设计与分析模板库.md

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

模板索引 (Index)

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

---

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

---

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

[Prompt 模板]

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

任务：为我的团队提供一份关于 [技术选项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 模板]

角色：你是一名精通 [相关领域，例如：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 模板]

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

== 你的唯一目标 ==
从我这里获取关于 [我的模糊需求，例如：设计一个新的“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 模板]

角色：你是一名精通 [技术栈，例如：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 模板]

角色：你是一名精通 "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 模板]

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

== 核心业务上下文 ==
- 项目背景：[例如：构建一个大型、长生命周期的雷达信号处理与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 模板]

角色：你是一名精通 [技术栈，例如：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 模板]

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

== 架构方案上下文 ==
[粘贴你的架构设计方案描述。例如：
“我们设计了一个数据摄取服务。它暴露一个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 模板]

角色：你是一名资深的云架构师和容量规划（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 模板]

角色：你是一名精通数据建模和数据库架构的专家（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 模板]

角色：你是一名精通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 模板]

角色：你是一名资深的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 模板]

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

== 遗留系统上下文 ==
[粘贴你对遗留系统的描述。例如：
“我们有一个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 模板]

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

== 决策上下文 ==
- 我们的目标：[例如：实现一个高可用的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），即你心中已有几个备选方案。