add(docs): 新增新的Prompt文档。
This commit is contained in:
595
Prompt模板/02_代码实现与重构模板库.md
Normal file
595
Prompt模板/02_代码实现与重构模板库.md
Normal file
@@ -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)**
|
||||
|
||||
<a id="B1"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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`）需要特别注意。
|
||||
- **使用指南：** 此模板生成的是基础配置。对于更复杂的构建（如条件编译、安装规则），可以在此基础上应用 `[原则一：敏捷提示]` 进行迭代式求精。
|
||||
|
||||
<a id="B2"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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<float> 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)**
|
||||
|
||||
<a id="B3"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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生成的代码能直接集成到你的项目中。
|
||||
|
||||
<a id="B4"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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代码的关键（玻璃盒原则）。
|
||||
|
||||
<a id="B5"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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生成完整的流程。
|
||||
|
||||
<a id="B6"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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)**
|
||||
|
||||
<a id="B7"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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++标准]`：明确标准。
|
||||
|
||||
<a id="B8"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `B8: 性能瓶颈分析与优化`
|
||||
**适用场景：** 当通过性能剖析（Profiling）确定某段代码（“热点函数”）是性能瓶颈时，用于分析瓶颈原因（如 算法复杂度、内存访问模式）并获取优化建议。
|
||||
**内嵌原则：** `[原则二：玻璃盒心态]` (强制分析复杂度、瓶颈), `[原则五：上下文即燃料]` (输入热点代码), `[原则七：结构化输出]` (输出优化代码和分析)。
|
||||
|
||||
**[Prompt 模板]**
|
||||
```txt
|
||||
角色：你是一名C++性能优化专家，精通算法、数据结构和底层系统（如缓存、内存）。
|
||||
|
||||
任务：请分析并优化以下被确定为性能瓶颈的C++“热点函数”。
|
||||
|
||||
== 热点函数代码 ==
|
||||
// [粘贴你的热点函数代码]
|
||||
// 最好包含关于输入数据规模和调用频率的注释。
|
||||
|
||||
== 分析与优化要求 ==
|
||||
1. 复杂度分析： 请分析此函数的时间复杂度（Big-O notation）和空间复杂度。
|
||||
2. 瓶颈识别： 请指出这段代码的主要性能瓶颈在哪里？（例如：算法本身低效？循环内内存分配？缓存未命中？数据结构选择不当？）
|
||||
3. 优化建议： 请提供一个优化后的C++版本。
|
||||
4. 优化说明： 必须解释你的优化策略及其预期效果（玻璃盒原则）。
|
||||
|
||||
== 输出要求 ==
|
||||
1. 复杂度分析结果。
|
||||
2. 瓶颈识别说明。
|
||||
3. 优化后的代码。
|
||||
4. 优化说明。
|
||||
```
|
||||
|
||||
**填充指南：**
|
||||
|
||||
- `[热点函数代码]`：提供代码，并尽可能附带性能上下文（如 “此函数每秒调用1万次，输入向量大小可达10万”）。
|
||||
- **使用指南：** 此模板侧重于CPU侧代码。对于GPU Kernel，应使用 `B9` 模板。
|
||||
|
||||
<a id="B9"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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)**
|
||||
|
||||
<a id="B10"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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\<T, E\> (C++23), 返回错误码 (int/enum), RAII (Resource Acquisition Is Initialization)]
|
||||
2. 必须处理 [潜在错误点1，例如：fopen 返回 NULL 的情况]。
|
||||
3. 必须处理 [潜在错误点2，例如：malloc 返回 NULL 的情况]。
|
||||
4. (对于RAII/异常) 必须确保资源（如文件句柄、内存）在错误发生时被正确释放（无泄漏）。
|
||||
|
||||
== (可选) 期望的错误处理风格示例 (✅) ==
|
||||
// [粘贴一个你期望的错误处理风格的代码片段]
|
||||
|
||||
== 输出要求 ==
|
||||
1. 提供添加/重构了错误处理逻辑后的完整代码。
|
||||
2. 简要说明你采用的错误处理策略。
|
||||
```
|
||||
|
||||
**填充指南：**
|
||||
|
||||
- `[原始代码]`：提供代码。
|
||||
- `[目标模式]`：**明确告知AI你期望的错误处理范式**。这是最重要的输入。
|
||||
- `[潜在错误点]`：列出你已知的、需要处理的错误源。
|
||||
- `[期望风格示例]`：可选，但强烈推荐（原则六）。提供一个示例能极大提高AI输出的风格一致性。
|
||||
|
||||
<a id="B11"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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提供无锁代码的可靠性需要仔细验证。
|
||||
|
||||
<a id="B12"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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才能生成符合规范的代码。
|
||||
|
||||
<a id="B13"></a>
|
||||
|
||||
-----
|
||||
|
||||
**模板名称：** `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。
|
||||
Reference in New Issue
Block a user