429 lines
21 KiB
Markdown
429 lines
21 KiB
Markdown
#### F. 类别六：“从0到1”（创造与生成） (Creation & Scaffolding)
|
||
|
||
**模板索引 (Index)**
|
||
|
||
| 模板ID | 核心用途 | 使用场景 / 关键词 |
|
||
| :--- | :--- | :--- |
|
||
| **F-1: 模块与服务创建** | | |
|
||
| **[`F1`](#F1)** | 自然语言项目初始化 | 项目脚手架, 目录结构, CMake初始化 |
|
||
| **[`F2`](#F2)** | 基于设计文档模块脚手架 | TDD解析, 接口/实现骨架, Stub生成 |
|
||
| **[`F3`](#F3)** | MVP/服务原型生成 | gRPC/REST原型, 服务器+客户端, 构建脚本 |
|
||
| **F-2: 任务与功能实现** | | |
|
||
| **[`F4`](#F4)** | 跨文件特性实现 | 接口+实现+测试联动, 纵向切片 |
|
||
| **[`F5`](#F5)** | 新模块测试套件生成 | gtest/gmock, Fixture, Mock依赖 |
|
||
| **F-3: 基础设施与环境创建** | | |
|
||
| **[`F6`](#F6)** | 基础设施即代码(IaC)生成 | Dockerfile, compose, CI配置 |
|
||
| **[`F7`](#F7)** | 适配层/绑定代码生成 | pybind11, 头文件解析, API绑定 |
|
||
|
||
-----
|
||
|
||
**子类别 F-1: 模块与服务创建 (Module & Service Scaffolding)**
|
||
|
||
<a id="F1"></a>
|
||
|
||
-----
|
||
|
||
**模板名称：** `F1: 基于自然语言的项目工作区初始化`
|
||
**适用场景：** `D4 (Agent)` 模式。项目启动的“第0步”。将一个高层级的自然语言想法（“我要做一个XX项目”）直接转化为一个标准化的、包含目录结构和基础配置文件的工作区。
|
||
**内嵌原则：** `[原则二：任务解构]` (D4)、`[原则八：决定论]`、`[原则五：上下文即燃料]`。
|
||
|
||
**[Prompt 模板]**
|
||
|
||
```txt
|
||
角色：你是一个项目脚手架生成机器人（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` 模板则负责在结构中填充内容。
|
||
|
||
<a id="F2"></a>
|
||
|
||
-----
|
||
|
||
**模板名称：** `F2: 基于设计文档的模块脚手架生成`
|
||
**适用场景：** `D4 (Agent)` 模式。在项目结构（F1）已存在后，根据详细的TDD（技术设计文档）自动生成一个新模块所需的全部C++文件骨架。
|
||
**内嵌原则：** `[原则二：任务解构]` (D4)、`[原则五：上下文即燃料]` (设计文档是核心)、`[原则七：结构化输出]`。
|
||
|
||
**[Prompt 模板]**
|
||
|
||
```txt
|
||
角色：你是一个“技术设计文档到代码”（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生成脚手架的质量。
|
||
|
||
<a id="F3"></a>
|
||
|
||
-----
|
||
|
||
**模板名称：** `F3: [Agent模板] 最小可行产品(MVP)/服务原型生成`
|
||
**适用场景：** `D4 (Agent)` 模式。用于快速启动一个特定技术栈（如gRPC, REST API）的“最小可行”（MVP）服务，生成所有必需的文件（API定义、服务器、客户端、构建脚本）。
|
||
**内嵌原则：** `[原则二：任务解构]` (D4)、`[原则七：结构化输出]`、`[原则五：上下文即燃料]`。
|
||
|
||
**[Prompt 模板]**
|
||
|
||
```txt
|
||
角色：你是一名精通 [技术栈, 例如：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)**
|
||
|
||
<a id="F4"></a>
|
||
|
||
-----
|
||
|
||
**模板名称：** `F4: 跨文件特性实现`
|
||
**适用场景：** `D4 (Agent)` 模式。实现一个“纵向特性”（Vertical Feature Slice），该特性需要**同时修改**多个现有的、不同角色的文件（如接口、实现、测试）。
|
||
**内嵌原则：** `[原则二：任务解构]` (D4，核心)、`[原则八：决定论]`。
|
||
|
||
**[Prompt 模板]**
|
||
|
||
```txt
|
||
角色：你是一个遵循指令的自动化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的执行成功率越高。
|
||
|
||
<a id="F5"></a>
|
||
|
||
-----
|
||
|
||
**模板名称：** `F5: 新模块的“测试套件”生成`
|
||
**适用场景：** `D4 (Agent)` 模式。在模块（如 `NewModule.h`）的核心功能已定义后，用于自动创建配套的、包含 `gtest` 和 `gmock` 的完整测试文件（`_test.cpp`）。
|
||
**内嵌原则：** `[原则二：任务解构]` (D4)、`[原则七：结构化输出]`、`[原则五：上下文即燃料]`。
|
||
|
||
**[Prompt 模板]**
|
||
|
||
```txt
|
||
角色：你是一名精通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)**
|
||
|
||
<a id="F6"></a>
|
||
|
||
-----
|
||
|
||
**模板名称：** `F6: [Agent模板] 基础设施即代码(IaC)生成` (原F5)
|
||
**适用场景：** `D4 (Agent)` 模式。为现有的C++ CMake项目自动生成DevOps/IaC（基础设施即代码）所需的环境配置文件，如 `Dockerfile`, `docker-compose.yml`, `.gitlab-ci.yml`。
|
||
**内嵌原则：** `[原则二：任务解构]` (D4)、`[原则七：结构化输出]`、`[原则五：上下文即燃料]`。
|
||
|
||
**[Prompt 模板]**
|
||
|
||
```txt
|
||
角色：你是一名精通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脚本。
|
||
|
||
<a id="F7"></a>
|
||
|
||
-----
|
||
|
||
**模板名称：** `F7: 适配层/绑定代码生成`
|
||
**适用场景：** `D4 (Agent)` 模式。连接不同语言或系统。自动解析一个C++头文件，并生成“适配层”或“绑定”（Binding）代码，使其能被另一种语言（如Python）调用。
|
||
**内嵌原则：** `[原则二：任务解构]` (D4)、`[原则五：上下文即燃料]` (头文件)、`[原则七：结构化输出]`。
|
||
|
||
**[Prompt 模板]**
|
||
|
||
```txt
|
||
角色：你是一名精通 [绑定技术, 例如：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的能力高度依赖于其对特定绑定技术的训练深度。
|
||
|
||
-----
|