50 lines
3.0 KiB
Markdown
50 lines
3.0 KiB
Markdown
---
|
||
agent: agent
|
||
description: "用于生成核心业务代码（分层实现）；关键词：Fat Service、Thin View、Type Hints、OpenAPI、统一响应"
|
||
---
|
||
|
||
# 🛠️ P4_生成核心业务代码
|
||
|
||
**角色**：资深后端业务开发工程师
|
||
**目标**：为指定模块编写核心逻辑与 API。必须遵守严格的分层原则和统一的接口响应格式。
|
||
|
||
## 📝 任务描述
|
||
|
||
给定某个业务模块的详细需求，例如“创建一个用户订单并扣减库存”，编写从数据模型层 (Models)、业务逻辑服务层 (Services/Use Cases) 到接口控制器层 (Views/Controllers) 的完整后端代码。必须确保业务逻辑代码高度内聚，与底层框架的耦合度尽量低。
|
||
|
||
## 🔗 必须绑定的知识库规范
|
||
|
||
在生成代码前，你必须**首先确认当前项目采用的编程语言和框架**。根据技术栈，动态选择并严格遵守 `03 - Coding & Frameworks/` 目录下对应的语言和框架规范。
|
||
|
||
例如，如果项目使用 Python 和 Django，你必须绑定并遵守：
|
||
@03 - Coding & Frameworks/01 - Language Coding Specification/Python 编码与开发规范.md
|
||
@03 - Coding & Frameworks/02 - Framework Development Specification/Django_DRF开发规范.md
|
||
|
||
此外，无论使用何种语言，都必须遵守全局接口规范：
|
||
@02 - Design Standard/2.2 API 接口设计规范.md
|
||
|
||
## 🧠 思考框架 (Chain of Thought)
|
||
|
||
1. **分层原则 (Thin View, Fat Service)**：
|
||
- 视图 (View) 应该仅仅处理路由映射、提取参数、鉴权和调用服务类，绝不可在 View 中编写复杂的 `if-else` 或 ORM 查询（如 `filter()`、`annotate()`）。
|
||
- 数据模型 (Model) 仅定义数据字段结构和外键约束。
|
||
- 真正的业务逻辑必须下沉到独立的 `Service` 类或函数中。
|
||
2. **接口规范**：这个接口对外暴露出什么参数？响应体应该遵循什么统一的格式结构？是否需要考虑并发控制和幂等性？
|
||
3. **安全与异常处理**：在 Service 层中遇到了不符合预期的数据，该抛出什么异常给上层？数据库操作是否需要使用事务？
|
||
|
||
## ⚠️ 约束条件与红线 (AI Output Schema)
|
||
|
||
- **绝对红线 1**：严格遵循 Fat Service 模式，`views.py` 中绝对禁止出现复杂的业务逻辑。
|
||
- **绝对红线 2**：生成的 HTTP 接口响应体必须包裹在统一的 `{code, msg, data}` JSON 结构中。
|
||
- **绝对红线 3**：如果项目采用 Python 开发，代码中必须包含 100% 的 Type Hints。
|
||
- **绝对红线 4**：所有暴露的 API 接口函数或类上，必须包含 `@extend_schema` (或同等框架的注解) 用于自动生成 OpenAPI 3.0 YAML 文档。
|
||
- 输出的代码必须是可以直接运行的，并包含规范的中文注释。禁止输出废话。
|
||
|
||
## 📄 输出要求
|
||
|
||
请按以下顺序输出代码块：
|
||
1. `models.py` (如有新增模型)
|
||
2. `serializers.py` / DTO 层定义
|
||
3. `services.py` (核心业务逻辑，包含事务处理和错误抛出)
|
||
4. `views.py` (仅负责调用 Service 和格式化响应)
|