#### 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 #include class UserStats { public: void incrementLogin(const std::string& user) { // 风险点1：对 map 的并发写 login_counts_[user]++; } int getLoginCount(const std::string& user) { // 风险点2：对 map 的并发读 auto it = login_counts_.find(user); if (it != login_counts_.end()) { return it->second; } return 0; } private: // 风险点3：共享状态 std::map login_counts_; }; == 审查要求 == 1. 识别共享状态： 找出所有被多个public方法（或线程）并发读/写的成员变量。 2. 分析竞态条件 (Race Conditions)： 明确指出哪些操作组合（如 incrementLogin 与 incrementLogin，或 incrementLogin 与 getLoginCount）会在此共享状态上导致数据竞争。 3. 修复建议： 提供一个线程安全（Thread-Safe）的修复版本。 4. 同步机制： 请使用 [偏好的机制，例如：std::mutex / std::shared\_mutex] 来保护共享状态。 == 输出要求 == 1. 共享状态分析： [例如：login_counts_ 是被 incrementLogin (写) 和 getLoginCount (读) 并发访问的共享状态] 2. 竞态条件分析： [例如：当两个线程同时调用 incrementLogin 时，map::operator[] 和 int++ 操作非原子，会导致计数丢失或map结构损坏...] 3. 修复后的代码： (提供添加了 std::mutex 和 std::lock_guard 的线程安全版本) ``` **填充指南：** - `[待审查的类定义]`：提供完整的类代码，AI需要看到所有访问成员变量的方法。 - `[偏好的机制]`：指定团队技术栈（如 `std::mutex`），确保修复方案的风格一致。 - **使用指南：** 这是新架构下Code Review的**必选动作**。 ----- **模板名称：** `C10: 错误处理路径审查` **适用场景：** 确保代码的健壮性。用于审查一个函数是否正确、完整地处理了所有可能的失败路径，防止“静默失败”（Silently Failing）。 **内嵌原则：** `[原则二：玻璃盒心态]` (强制分析所有路径), `[原则五：上下文即燃料]` (输入代码), `[原则七：结构化输出]` (输出报告)。 **[Prompt 模板]** ```txt 角色：你是一名精通防御性编程（Defensive Programming）和C++异常安全的专家。 任务：请严格审查以下函数的“错误处理路径”是否健壮和完备。 == 待审查的函数 == [粘贴你的函数代码，特别是包含C风格API、外部调用或资源分配的代码] // 示例：一个错误处理不完备的函数 bool load_config_file(const char* path) { FILE* fp = fopen(path, "r"); // 风险1：未检查 fopen 的返回值 char buffer[1024]; size_t read_bytes = fread(buffer, 1, 1024, fp); // 风险2：未检查 fread 的返回值 (是否读到预期大小) if (read_bytes > 0) { // ... (process buffer) ... } // 风险3：未在所有路径（如此处）调用 fclose(fp) return true; // 风险4：无论成功失败，永远返回 true } == 审查要求 == 请识别此函数中所有缺失或不正确的错误处理路径： 1. 资源分配/打开： 是否正确检查了（如 fopen, malloc, new）的返回值（如 nullptr）？ 2. 外部调用： 是否正确检查了（如 fread, send, external_api()）的返回值或错误码？ 3. 资源释放 (RAII)： 是否确保资源（如 FILE*, 内存）在函数的所有出口（包括错误出口）都被正确释放（无泄漏）？ 4. 函数返回值： 函数的返回值是否能准确反映其执行结果（成功/失败）？ == 输出要求 == 请逐条列出发现的“错误处理缺陷”及其“修复建议”。 - [缺陷 1]： (例如：未检查 fopen 返回值) - [风险]： (如果 path 不存在，fp 为 NULL，后续 fread 将导致段错误) - [修复建议]： (例如：if (fp == nullptr) { return false; }) ----- - [缺陷 2]： ... ``` **填充指南：** - `[待审查的函数]`：提供代码。 - **使用指南：** 此模板对于审查与C库（需要手动资源管理）或网络（总会失败）交互的代码至关重要。 ----- **模板名称：** `C11: 安全漏洞专项审查` **适用场景：** 在代码提交前进行安全左移（Shift-Left Security）。用于审查代码是否存在C/C++中常见（且高风险）的安全漏洞。 **内嵌原则：** `[原则八：自我批判]` (AI扮演安全专家), `[原则五：上下文即燃料]` (输入代码), `[原则七：结构化输出]` (输出漏洞报告)。 **[Prompt 模板]** ```txt 角色：你是一名C/C++应用安全专家（AppSec），精通CWE和OWASP Top 10。 任务：请严格审查以下C/C++代码，查找常见的安全漏洞。 == 待审查的代码 == [粘贴你的C/C++代码片段，特别是处理用户输入、文件或网络数据的部分] // 示例：包含多个漏洞的代码 void handle_user_request(const char* user_input, int user_id) { // 漏洞1：缓冲区溢出 char buffer[100]; strcpy(buffer, user_input); // 漏洞2：格式化字符串 printf(buffer); // 漏洞3：SQL注入 (示例) std::string query = "SELECT * FROM users WHERE id = " + std::to_string(user_id); // ... (execute query) ... } == 审查重点 (CWE) == 请重点关注（但不限于）以下高风险漏洞： 1. 缓冲区溢出 (Buffer Overflow)： (例如：strcpy, sprintf, gets) 2. 格式化字符串 (Format String)： (例如：printf(user_input)) 3. 整数溢出 (Integer Overflow)： (例如：int size = len1 + len2;) 4. SQL注入 (SQL Injection)： (如果代码涉及构建SQL查询) 5. 命令注入 (Command Injection)： (如果代码涉及调用 system() 或 popen()) == 输出要求 == 请按照CWE（通用缺陷枚举）的格式，逐条列出发现的漏洞： - [漏洞 1]： (例如：CWE-120: 缓冲区溢出) - [位置]： (例如：strcpy(buffer, user_input);) - [风险]： (例如：user_input 可能长于100字节，导致栈溢出，可能允许远程代码执行) - [修复建议]： (例如：使用 strncpy 或更好的 std::string) ----- - [漏洞 2]： ... ``` **填充指南：** - `[待审查的代码]`：提供代码，尤其是处理“不可信输入”的代码。 - **使用指南：** AI是出色的模式匹配器，非常擅长发现这类有明显“特征”（如`strcpy`）的安全漏洞。 ----- **子类别 C-4: 迭代与代码评审 (Iteration & Feedback)** ----- **模板名称：** `C12: 方案的自我批判` **适用场景：** `原则五：自我批判` 的通用实现。用于对抗AI的“惰性实现”（痛点6）和“上下文惯性”（痛点1）。在你（或AI）给出一个初步方案后，强制AI切换角色，对该方案进行压力测试。 **内嵌原则：** `[原则五：自我批判]` (核心), `[原则一：敏捷提示]` (迭代式求精)。 **[Prompt 模板]** ```txt 角色：(情景切换) 很好，你刚才提供的 [方案/代码] 是一个不错的初稿。 现在，请你完全忘记你“乐于助人”的助手角色。 新角色：你是一名资深的、吹毛求疵的、且极其注重“健壮性”和“性能”的首席架构评审专家。 任务：请严格审查你刚才提供的 [方案/代码]，找出其中至少 [数量，例如：3] 个潜在的设计缺陷、性能陷阱、隐藏的假设或未处理的边界条件。 == 交付要求 == 请逐条列出： 1. [缺陷 1]： (例如：并发不安全) 2. [分析]： (例如：你提供的方案在多线程环境下存在竞态条件...) 3. [改进建议]： (例如：应使用 std::mutex...) ----- 1. [缺陷 2]： (例如：性能陷阱) 2. [分析]： (例如：在循环内部分配内存...) 3. [改进建议]： (例如：应在循环外预分配...) ``` **填充指南：** - **使用指南：** 这是一个“对话式”模板，在你对AI的（或你自己的）上一个回答不完全满意时使用。 - `[方案/代码]`：替换为你正在讨论的主题，如 “API设计”、“CUDA Kernel实现”。 - `[数量]`：指定一个具体数字，可以迫使AI更深入地思考。 ----- **模板名称：** `C13: 代码可读性与规范性评审` **适用场景：** 自动化Code Review中关于“代码风格”的重复性劳动（痛点3）。用于确保代码符合团队规范，提高可读性和可维护性。 **内嵌原则：** `[原则六：示例优先]` (可选：提供规范), `[原则七：结构化输出]` (输出评审意见)。 **[Prompt 模板]** ```txt 角色：你是一名资深的C++工程师，是 [团队/规范，例如：Google C++ Style Guide] 的坚定执行者。 任务：请审查以下代码的“可读性”、“可维护性”和“代码风格”。 == 待审查的代码 == [粘贴你需要评审的代码片段，例如：命名不规范、函数过长的代码] // 示例：风格糟糕的代码 #include // 全局变量 std::vector g_vec; // 命名模糊，函数名大写 bool Process(int x, int y) { if (x > y) { // 魔法数字 int temp = x; // 变量名无意义 x = y; y = temp; } // ... (省略了50行其他逻辑) ... g_vec.push_back(y); // 依赖全局状态 return true; } == 审查重点 == 1. 命名规范： (例如：变量名、函数名、类名是否清晰且符合 [规范]？) 2. 函数长度/职责： (例如：函数是否过长？是否违反了“单一职责原则”？) 3. 注释： (例如：注释是否缺失？是否注释了“Why”？) 4. 复杂度： (例如：是否存在过深的嵌套（if/for）？) 5. 反模式： (例如：是否使用了“魔法数字”？是否滥用全局变量？) == (可选) 我们的风格规范 (示例优先) == - [例如：函数命名使用 lower_snake_case()] - [例如：成员变量使用 m_suffix_] - [例如：严禁使用全局变量] == 输出要求 == 请逐条返回“风格问题”和“重构建议”。 - [问题 1]： (例如：违反命名规范) - [建议]： (例如：函数 Process 应改为 process_data。变量 temp 应改为 lower_bound。) ----- - [问题 2]： (例如：滥用全局变量) - [建议]： (例如：g_vec 应作为参数传入或作为类成员，移除全局状态。) ----- - [问题 3]： ... ``` **填充指南：** - `[团队/规范]`：明确告知AI应遵循的风格，如 `Google Style`, `LLVM Style`。 - `[我们的风格规范]`：**强烈推荐**。通过 `原则六：示例优先` 提供你团队的具体规范，AI的评审会精确得多。