cps-develop-docs/.github/prompts/p4-core-business-code.prompt.md

agent, description

agent	description
agent	用于生成核心业务代码（分层实现）；关键词：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 和格式化响应)