Inbox/Prompt模板/06_Agent创造与生成模板库.md

F. 类别六：“从0到1”（创造与生成） (Creation & Scaffolding)

模板索引 (Index)

模板ID	核心用途	使用场景 / 关键词
F-1: 模块与服务创建
F1	自然语言项目初始化	项目脚手架, 目录结构, CMake初始化
F2	基于设计文档模块脚手架	TDD解析, 接口/实现骨架, Stub生成
F3	MVP/服务原型生成	gRPC/REST原型, 服务器+客户端, 构建脚本
F-2: 任务与功能实现
F4	跨文件特性实现	接口+实现+测试联动, 纵向切片
F5	新模块测试套件生成	gtest/gmock, Fixture, Mock依赖
F-3: 基础设施与环境创建
F6	基础设施即代码(IaC)生成	Dockerfile, compose, CI配置
F7	适配层/绑定代码生成	pybind11, 头文件解析, API绑定

---

子类别 F-1: 模块与服务创建 (Module & Service Scaffolding)

---

模板名称： F1: 基于自然语言的项目工作区初始化 适用场景： D4 (Agent) 模式。项目启动的“第0步”。将一个高层级的自然语言想法（“我要做一个XX项目”）直接转化为一个标准化的、包含目录结构和基础配置文件的工作区。 内嵌原则： [原则二：任务解构] (D4)、[原则八：决定论]、[原则五：上下文即燃料]。

[Prompt 模板]

角色：你是一个项目脚手架生成机器人（Project Scaffolding Bot）。

任务：请根据我的“项目描述”，在 @workspace 中初始化一个全新的项目结构。

== 项目描述 ==
1.  项目名称 (Project Name)： [例如：RadarSignalSimulator]
2.  核心语言 (Language)： [例如：C++]
3.  构建系统 (Build System)： [例如：CMake (现代C++17标准)]
4.  项目类型 (Type)： [例如：可执行程序 (Executable)]
5.  (可选) 核心依赖： [例如：Boost, gtest (用于测试)]

== 执行计划 (Execution Plan) ==
1.  创建根目录： 在 @workspace 中创建 [项目名称] 根目录。
2.  创建目录结构 (Directory Structure)：
    - 在 [项目名称]/ 下创建 src/ (用于源代码)
    - 在 [项目名称]/ 下创建 include/ (用于头文件)
    - 在 [项目名称]/ 下创建 tests/ (用于测试)
    - 在 [项目名称]/ 下创建 docs/ (用于文档)
    - 在 [项目名称]/ 下创建 scripts/ (用于辅助脚本)
3.  生成 .gitignore：
    - 在 [项目名称]/ 根目录创建 .gitignore 文件。
    - 必须填入适用于 [语言] 和 [构建系统] 的标准模板内容 (例如：忽略 build/, *.o, *.exe, *.out)。
4.  生成 README.md：
    - 在 [项目名称]/ 根目录创建 README.md。
    - 必须包含一级标题 #[项目名称] 和“快速上手”章节的占位符。
5.  生成构建系统骨架 (Build System Scaffolding)：
    - 在 [项目名称]/ 根目录创建 CMakeLists.txt。
    - 必须包含：cmake_minimum_required, project(...), set(CMAKE_CXX_STANDARD 17), add_executable(...), 以及 find_package (针对 [核心依赖]) 的占位符。
    - (可选) 在 [项目名称]/tests/ 下创建 CMakeLists.txt (用于 gtest)。
6.  生成“Hello World”骨架：
    - 创建 [项目名称]/src/main.cpp。
    - 必须包含一个最小可运行的 main 函数 (例如：打印 "Hello, [项目名称]!")。

== 最终约束 ==
- 严格按照上述计划创建目录和文件，严禁添加任何未提及的文件。
- 生成的文件内容必须是健壮的、遵循最佳实践的“骨架”代码。

填充指南：

• [项目描述]：这是核心燃料。用户必须提供清晰的项目名称、语言和构建系统，Agent才能生成匹配的脚手架。
• 使用指南： 这是“从0到0.1”的模板，它负责建立结构，后续的 F2 或 F3 模板则负责在结构中填充内容。

---

模板名称： F2: 基于设计文档的模块脚手架生成 适用场景： D4 (Agent) 模式。在项目结构（F1）已存在后，根据详细的TDD（技术设计文档）自动生成一个新模块所需的全部C++文件骨架。 内嵌原则： [原则二：任务解构] (D4)、[原则五：上下文即燃料] (设计文档是核心)、[原则七：结构化输出]。

[Prompt 模板]

角色：你是一个“技术设计文档到代码”（TDD-to-Code）的生成引擎。

任务：请严格按照我提供的 [设计文档] (例如 @file:docs/Logger.md)，在 @workspace 中生成对应C++模块的完整文件脚手架。

== 执行上下文 ==
1.  工作区： @workspace
2.  设计文档 (必须在调用时提供)： [例如：@file:docs/Logger.md]
3.  目标根目录 (Target Root)： [例如：@dir:src/modules/]

== 执行计划 (Execution Plan) ==
1.  读取 (Read)： 打开并深度解析 [设计文档]。
2.  提取实体 (Extract)： 从文档中提取 [模块名] (例如：Logger), [接口/基类] (例如：ILogger), 以及 [实现类] (例如：FileLogger, ConsoleLogger, LoggerManager)。
3.  创建目录： 在 [目标根目录] 下创建 [模块名] 目录 (例如：src/modules/Logger/)。
4.  循环生成文件 (Loop & Generate)：
    - (a) 对于 [接口/基类] (例如 ILogger)：
        - 创建 [模块名]/[接口名].h 文件。
        - 必须包含：头文件保护 (#pragma once 或 #ifndef)。
        - 必须包含：[设计文档] 中定义的所有纯虚函数 (例如 virtual void log(...) = 0;)。
        - 必须包含：Doxygen 注释骨架 (@brief, @param, @return)。
    - (b) 对于 [实现类] (例如 FileLogger)：
        - 创建 [模块名]/[类名].h 文件。
        - 必须包含：头文件保护。
        - 必须 public 继承自 [接口名] (例如 class FileLogger : public ILogger)。
        - 必须声明 [设计文档] 中定义的所有成员函数（添加 override）和私有成员变量。
        - 必须添加 Doxygen 注释骨架。
    - (c) 对于 [实现类] (例如 FileLogger)：
        - 创建 [模块名]/[类名].cpp 文件。
        - 必须 include 对应的 .h 文件。
        - 必须为所有成员函数生成“桩函数”（Stub）实现。
        - 桩实现规范： 必须包含 // TODO: Implement [函数名] 注释，并返回一个默认值（如 void, true, nullptr）。

== 最终约束 ==
- 生成的文件必须严格匹配 [设计文档] 中定义的类名、继承关系和函数签名。
- 所有生成的 .h 和 .cpp 文件都必须包含 Doxygen 注释骨架。

填充指南：

• 使用指南： 用户必须在调用时提供 @workspace 和设计文档的路径 (@file:...)。
• [设计文档]：这份文档的质量（是否清晰、无歧义）直接决定了Agent生成脚手架的质量。

---

模板名称： F3: [Agent模板] 最小可行产品(MVP)/服务原型生成 适用场景： D4 (Agent) 模式。用于快速启动一个特定技术栈（如gRPC, REST API）的“最小可行”（MVP）服务，生成所有必需的文件（API定义、服务器、客户端、构建脚本）。 内嵌原则： [原则二：任务解构] (D4)、[原则七：结构化输出]、[原则五：上下文即燃料]。

[Prompt 模板]

角色：你是一名精通 [技术栈, 例如：gRPC 和 C++ CMake] 的全栈原型工程师。

任务：请在 @workspace 中为我生成一个 [技术栈] 的最小可行产品（MVP）服务原型。

== 原型需求 ==
1.  服务名称 (Service Name)： [例如：RadarConfigService]
2.  技术栈 (Tech Stack)： [例如：gRPC (C++)]
3.  核心功能 (Core RPC)： [例如：定义一个 SetConfig RPC]
4.  RPC 请求 (Request)： [例如：ConfigData (包含 int32 param1, float param2)]
5.  RPC 响应 (Response)： [例如：ConfigResponse (包含 bool success)]

== 执行计划 (Execution Plan) ==
请在 @workspace 根目录下创建并填充以下文件：

1.  文件 1：API 定义 (例如 [服务名称].proto)
    - 必须包含：syntax = "proto3";, package ...;
    - 必须定义：service [服务名称]。
    - 必须包含：rpc [核心功能]([RPC 请求]) returns ([RPC 响应]);
    - 必须定义：message [RPC 请求] 和 message [RPC 响应] 的结构。
2.  文件 2：服务器实现 (例如 server.cpp)
    - 必须包含：gRPC 和 .proto 生成的 .h 文件。
    - 必须实现：[服务名称]ServiceImpl 类，继承自 [服务名称]::Service。
    - 必须实现：[核心功能] 方法的桩函数（返回一个默认的 [RPC 响应]）。
    - 必须包含：main() 函数，用于启动 gRPC 服务器并监听 [端口, 例如：0.0.0.0:50051]。
3.  文件 3：客户端示例 (例如 client.cpp)
    - 必须包含：gRPC 和 .proto 生成的 .h 文件。
    - 必须包含：main() 函数。
    - 必须展示：如何创建 Channel、创建 Stub、组装 [RPC 请求]、调用 [核心功能] RPC，并打印 [RPC 响应]。
4.  文件 4：构建脚本 (例如 CMakeLists.txt)
    - 必须包含：find_package(gRPC REQUIRED), find_package(Protobuf REQUIRED)。
    - 必须包含：用于编译 .proto 文件的 protobuf_generate_- 规则。
    - 必须包含：add_executable(server server.cpp ...) 和 add_executable(client client.cpp ...)。
    - 必须包含：target_link_libraries (链接 gRPC, Protobuf 等)。

== 最终约束 ==
- 生成的所有文件必须是相互关联、可编译、可运行的（假设依赖已安装）。
- 所有桩函数必须包含 // TODO: Add business logic here 注释。

填充指南：

• [原型需求]：这是核心燃料。用户必须清晰定义服务名称、技术栈和至少一个核心功能（如RPC）的输入输出。
• [技术栈]：此模板可适配多种技术，如 REST API (FastAPI, Python) 或 gRPC (Go)，只需修改提示中的技术栈名称和 [执行计划] 中的文件名及库即可。

---

子类别 F-2: 任务与功能实现 (Feature & Task Implementation)

---

模板名称： F4: 跨文件特性实现 适用场景： D4 (Agent) 模式。实现一个“纵向特性”（Vertical Feature Slice），该特性需要同时修改多个现有的、不同角色的文件（如接口、实现、测试）。 内嵌原则： [原则二：任务解构] (D4，核心)、[原则八：决定论]。

[Prompt 模板]

角色：你是一个遵循指令的自动化C++特性实现Agent。

任务：请严格按照以下“特性实现执行计划”，在 @workspace 中修改现有文件以实现新功能。

== 特性名称 ==
- [例如：添加“重置”功能到所有处理器]

== 执行计划 (Execution Plan) ==
你必须严格按照以下顺序和规范，修改指定的文件：

Step 1：修改 [接口文件]
- 文件： [例如：@file:src/interfaces/IProcessor.h]
- 动作： 在 IProcessor 接口中，添加一个新的纯虚函数：
    [粘贴新接口签名，例如：virtual void reset() = 0;]

Step 2：修改 [实现类A]
- 文件： [例如：@file:src/cpu/CpuProcessor.h]
- 动作： 在 CpuProcessor 类的 public 部分添加方法声明：
    [粘贴派生类声明，例如：void reset() override;]
- 文件： [例如：@file:src/cpu/CpuProcessor.cpp]
- 动作： 在文件末尾添加桩函数实现：
    [粘贴桩函数实现，例如：
    void CpuProcessor::reset() {
        // TODO: Implement reset logic for CPU
        m_internal_state = 0; // 示例逻辑
    }
    ]

Step 3：修改 [实现类B]
- 文件： [例如：@file:src/gpu/GpuProcessor.h]
- 动作： 在 GpuProcessor 类的 public 部分添加方法声明：
    [粘贴派生类声明，例如：void reset() override;]
- 文件： [例如：@file:src/gpu/GpuProcessor.cpp]
- 动作： 在文件末尾添加桩函数实现：
    [粘贴桩函数实现，例如：
    void GpuProcessor::reset() {
        // TODO: Implement reset logic for GPU
        // (e.g., reset CUDA buffers)
    }
    ]

Step 4：修改 [测试文件]
- 文件： [例如：@file:tests/ProcessorTest.cpp]
- 动作： 添加一个新的gtest测试用例骨架：
    [粘贴测试用例骨架，例如：
    TEST(ProcessorTest, ResetFunction) {
        // TODO: Write test for reset()
        // CpuProcessor cpu;
        // cpu.reset();
        // EXPECT_EQ(cpu.getState(), 0);
    }
    ]

== 最终约束 ==
- 原子性： 必须按顺序完成所有步骤。
- 精确性： 严禁修改任何 [执行计划] 中未明确提及的文件或代码行。

填充指南：

• 使用指南： 这是D4 Agent的“高级”用法。工程师（用户）扮演“架构师”，负责将特性“解构”为[执行计划]。Agent（AI）扮演“执行者”。
• [执行计划]：这是核心燃料。工程师提供的步骤越详细、越精确（包括粘贴目标代码），Agent的执行成功率越高。

---

模板名称： F5: 新模块的“测试套件”生成 适用场景： D4 (Agent) 模式。在模块（如 NewModule.h）的核心功能已定义后，用于自动创建配套的、包含 gtest 和 gmock 的完整测试文件（_test.cpp）。 内嵌原则： [原则二：任务解构] (D4)、[原则七：结构化输出]、[原则五：上下文即燃料]。

[Prompt 模板]

角色：你是一名精通C++ gtest 和 gmock 框架的自动化QA工程师。

任务：请为我提供的 [目标头文件] 自动生成一个完整的gtest测试套件文件。

== 执行上下文 ==
1.  工作区： @workspace
2.  目标头文件 (Source of Truth)： [例如：@file:src/modules/NewModule.h]
3.  测试文件输出路径： [例如：@file:tests/NewModule_test.cpp]

== 执行计划 (Execution Plan) ==
1.  读取 (Read)： 打开并深度解析 [目标头文件]。
2.  分析 (Analyze)：
    - (a) 识别目标类名（例如 NewModule）。
    - (b) 识别所有 public 方法（例如 methodA, methodB）。
    - (c) 识别构造函数中的依赖（例如 IDependencyA- dep），这些是需要Mock的目标。
3.  创建测试文件 (Create)： 创建 [测试文件输出路径]。
4.  生成文件内容 (Generate)：
    - (a) Includes： 必须包含 gtest/gtest.h, gmock/gmock.h, 以及 [目标头文件]。
    - (b) Mock 类生成：
        - 针对 [分析] (c) 中识别的每一个依赖（例如 IDependencyA）：
        - 生成 Mock[依赖名] 类 (例如 class MockDependencyA : public IDependencyA { ... })。
        - 必须使用 MOCK_METHOD 宏为所有接口方法生成Mock。
    - (c) Test Fixture 生成：
        - 生成 class [模块名]Test : public ::testing::Test { ... }。
        - 必须在 SetUp() 方法中初始化Mock对象和被测类 [模块名]。
    - (d) 测试用例 (Test Cases) 生成：
        - 针对 [分析] (b) 中识别的每一个 public 方法：
        - 至少生成一个 TEST_F([模块名]Test, [方法名]_HappyPath) 骨架。
        - 至少生成一个 TEST_F([模块名]Test, [方法名]_EdgeCase) 骨架。
        - 骨架要求： 必须包含 // Arrange, // Act, // Assert 三段式注释，并添加 // TODO: ... 占位符。

== 最终约束 ==
- 必须自动识别依赖并生成 gmock 类。
- 必须为所有 public 方法生成测试用例骨架。

填充指南：

• 使用指南： 用户调用时必须提供 @workspace 和 @file:[目标头文件] 的路径。
• [目标头文件]：Agent将解析此文件以确定要测试什么和要Mock什么。

---

子类别 F-3: 基础设施与环境创建 (Infrastructure & Environment)

---

模板名称： F6: [Agent模板] 基础设施即代码(IaC)生成 (原F5) 适用场景： D4 (Agent) 模式。为现有的C++ CMake项目自动生成DevOps/IaC（基础设施即代码）所需的环境配置文件，如 Dockerfile, docker-compose.yml, .gitlab-ci.yml。 内嵌原则： [原则二：任务解构] (D4)、[原则七：结构化输出]、[原则五：上下文即燃料]。

[Prompt 模板]

角色：你是一名精通DevOps、容器化（Docker）和CI/CD（GitLab CI）的SRE工程师。

任务：请为我当前的C++ CMake项目（在 @workspace 中）生成一套标准化的IaC（基础设施即代码）配置文件。

== 项目上下文 ==
1.  项目类型： [例如：C++ CMake 项目]
2.  构建命令 (Build)： [例如：cmake .. && make -j]
3.  测试命令 (Test)： [例如：ctest] 或 [./build/run_tests]
4.  最终产物 (Artifact)： [例如：./build/my_app] (可执行文件)

== 执行计划 (Execution Plan) ==
请在 @workspace 根目录创建并填充以下文件：

1.  文件 1：Dockerfile (用于生产/部署)
    - 规范： 必须使用“多阶段构建”（Multi-Stage Build）。
    - (a) builder 阶段：
        - FROM [基础镜像, 例如：ubuntu:22.04]
        - WORKDIR /build
        - COPY . .
        - RUN [安装依赖, 例如：apt-get install cmake build-essential ...]
        - RUN [构建命令]
    - (b) final 阶段：
        - FROM [轻量级镜像, 例如：ubuntu:22.04-slim]
        - COPY --from=builder /build/[最终产物] /app/
        - ENTRYPOINT ["/app/[最终产物]"]
2.  文件 2：docker-compose.yml (用于本地开发/测试)
    - 规范： 定义一个服务（例如 dev）。
    - 必须包含 build: . (使用 Dockerfile)。
    - 必须包含 volumes: [.:/app] (挂载本地代码以实现热重载/开发)。
    - (可选) 覆盖 command: 以进行调试。
3.  文件 3：.gitlab-ci.yml (用于CI/CD)
    - 规范： 必须定义 stages: [build, test]。
    - (a) build_job：
        - stage: build
        - script: [安装依赖] 和 [构建命令]
        - artifacts: paths: [[最终产物]] (保存构建产物)
    - (b) test_job：
        - stage: test
        - dependencies: [build_job] (依赖构建)
        - script: [测试命令]

== 最终约束 ==
- 生成的配置文件必须语法正确，并遵循 [项目上下文] 中提供的命令和路径。

填充指南：

• [项目上下文]：这是核心燃料。用户必须提供构建、测试命令和最终产物的路径，AI才能生成正确的IaC脚本。

---

模板名称： F7: 适配层/绑定代码生成 适用场景： D4 (Agent) 模式。连接不同语言或系统。自动解析一个C++头文件，并生成“适配层”或“绑定”（Binding）代码，使其能被另一种语言（如Python）调用。 内嵌原则： [原则二：任务解构] (D4)、[原则五：上下文即燃料] (头文件)、[原则七：结构化输出]。

[Prompt 模板]

角色：你是一名精通 [绑定技术, 例如：pybind11] 和C++ API绑定的专家。

任务：请为我提供的 [目标头文件]，自动生成 [绑定技术] 的C++绑定（wrapper）代码。

== 执行上下文 ==
1.  工作区： @workspace
2.  目标头文件 (Source of Truth)： [例如：@file:src/libProcessor.h]
3.  绑定技术 (Tech)： [例如：pybind11]
4.  Python 模块名 (Module Name)： [例如：radar_processor_py]
5.  输出文件 (Output)： [例如：@file:bindings/py_bindings.cpp]

== 执行计划 (Execution Plan) ==
1.  读取 (Read)： 打开并深度解析 [目标头文件]。
2.  分析 (Analyze)：
    - (a) 识别所有 public class [ClassName]。
    - (b) 识别 [ClassName] 的所有 public 构造函数。
    - (c) 识别 [ClassName] 的所有 public 成员函数（包括重载）。
    - (d) (可选) 识别 public enum。
3.  创建绑定文件 (Create)： 创建 [输出文件]。
4.  生成文件内容 (Generate)：
    - (a) Includes： 必须包含 [绑定技术].h (例如 pybind11/pybind11.h) 和 [目标头文件]。
    - (b) 模块定义宏： 必须生成 [宏, 例如：PYBIND11_MODULE([Python 模块名], m)] { ... }。
    - (c) 类绑定 (Class Binding)：
        - 在宏内部，为 [分析] (a) 中识别的 [ClassName] 生成 py::class_... 定义。
        - (d) 构造函数绑定： 为 [分析] (b) 中识别的每个构造函数生成 .def(py::init<...>());。
        - (e) 方法绑定： 为 [分析] (c) 中识别的每个成员函数生成 .def("[python_name]", &[ClassName]::[method_name])。
        - (f) (可选) 重载处理： 必须使用 py::overload_cast 来处理C++中的函数重载。
        - (g) (可选) Enum 绑定： 为 [分析] (d) 中的 enum 生成 py::enum_ 绑定。

== 最终约束 ==
- 必须自动解析C++头文件并绑定所有 public 接口。
- 必须正确处理C++函数重载（这是最关键的风险点）。
- 生成的 .cpp 文件必须是语法正确的 [绑定技术] 代码。

填充指南：

• 使用指南： 用户调用时必须提供 @workspace、@file:[目标头文件] 以及 [绑定技术]。
• [绑定技术]：例如 pybind11, cffi (生成C头文件), JNI (生成Java JNI样板代码)。AI的能力高度依赖于其对特定绑定技术的训练深度。

---