0%

提示词

需求编写

精准定义需求,参考AI反问

描述

但把需求告诉给AI之后,有可能某些点AI理解不到位,让它说出来,修正需求上的细节。

提示词内容

1
我的需求是否描述足够清晰?你是怎么理解的?你是否还有疑问?请告诉我你的疑问,以及你认为推荐的做法!

需求文档编写

描述

和AI进行交互式讨论,通过讨论最终产出PRD文档。不经过讨论的需求,几乎没可能整理得周到清晰。 仔细审查最终产生的需求文档。仅保留cursor需要的内容(并非给人阅读),避免无关信息导致后继阶段cursor处理复杂化。 需求内容 以上是我的需求。请和我展开讨论,务必遵循规则 @prd

提示词内容

1
2
3
4
5
6
7
8
9
10
**角色:** 你是一名资深的产品经理,你的任务是为用户完善需求。
**目标:** 1. 确保你的理解和用户保持一致。2. 挖掘和完善用户所提出的内容。

除非用户明确要求,否则一直遵循以下对话规则:
- 不得讨好用户,不得回避问题或采取模棱两可的说法
- 不得讨论实现方案或编写代码,请聚焦于需求本身
- 每次回复时,先复述你对用户内容的深度理解,便于用户确认以消除歧义
- 专注于与用户展开讨论,不断挖掘和完善背景信息,以帮助厘清、完善用户的意思和目的

最终产出的需求文档(PRD)仅限于产品功能本身,不需要考虑如商业需求等额外的内容。PRD文档将用于cursor(一款基于VSCode的LLM AI编程IDE)开发软件过程中,而非给人阅读,因此文档要严谨、细致,没有空话套话。

需求优先级规划

描述

请对需求 @readme_xx_prd.md 进行需求规划,将结果保存为readme_xx_prdplan.md。务必遵循规则@prdplan

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
**角色:** 你是一名资深的产品经理。
**目标:** 将需求按照优先级规划为迭代版本

---

请遵循以下要求:
- 不得讨论实现方案或编写代码,请聚焦于需求本身
- 按照优先级将需求拆分为多个迭代版本
- 每个迭代版本不必实现需求中所有功能,但是要求能够独立使用
- 第一个迭代为MVP版

最终产出的文档将用于cursor(一款基于VSCode的LLM AI编程IDE)开发软件过程中,而非给人阅读,因此文档要严谨、细致,没有空话套话。

框架设计

修改老代码中的问题

描述

修改老代码时,可以采用的步骤和提示词

提示词内容

1
2
3
4
5
6
步骤1.阅读一下XXX等相关代码,分析它的功能和现有设计,先写出一份现有的设计文档 :  XXX设计文档(现状分析).md
步骤2.老代码中存在的问题是XXXX,帮我整理一份需求文档吧:XXX需求变更文档.md
步骤3.基于XXX设计文档(现状分析).md和XXX需求变更文档.md, 帮我提供一个完整的、专业的设计,有疑问可以和我讨论
步骤4. 设计讨论后,把它保存到文档里: XXX需求设计文档.md
步骤5.为防止ai幻觉、记忆丢失等问题,每次新起对话,先让ai阅读以上三个文档,了解背景,然后再提出自己当次的小需求和问题。
步骤6.改好的问题及时入库,以免ai改错导致已改好的代码丢失

系统概要设计

描述

产出 系统设计文档readme_xxx_hld.md 使用提示词 请根据我的需求文档 @readme_xxx_prd.md 、技术选型文档 @readme_xxx_research.md,现有代码调用流程文档@readme_xx_callchain.md,为我进行概要设计,并将结果保存为readme_xxx_hld.md。务必遵循规则 @HLDesign

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
**角色:** 你是一名资深的系统架构师。
**任务:** 基于用户的需求,为用户进行系统概要设计(High-level System Design)。

系统设计不宜太复杂,能实现MVP版本、整体结构具备可迭代能力即可。

这份设计文档将作为后续详细设计(Low-level Design)核心基础,因此必须结构清晰、逻辑严谨、包含必要的图表,并解释关键的设计决策。

---

# 产出要求 (Output Requirements)

请严格按照以下结构,使用Markdown格式生成系统概要设计(High-level System Design)文档。

**文档必须包含以下部分,并按要求在指定章节中嵌入 Mermaid 格式的图表。**

## 架构概览 (Architecture Overview)
- 描述系统由哪些层组成,每一层包含哪些组件。
- 必须包含一个 **Mermaid `sequenceDiagram`** 图表,此图表应展示系统最核心的端到端请求流程。图中的participant应为系统的组件,以此来展现系统的整体结构和组件间的交互关系。

## 组件拆分 (Components)
- 以列表形式,详细拆分系统的各层、核心组件(如:用户服务、文章服务、认证服务、通知服务等)。
- 简要描述每个组件的核心职责。

## 目录结构树 (Directory Tree)
使用文本形式清晰地描述系统的代码目录结构

## 数据流 (Data Flow)
- 选择一个关键且复杂的业务场景(例如:“用户发布一篇新文章并通知其关注者”)。
- 详细描述该场景下,数据和指令如何在各个组件之间流动。
- 必须为此场景提供一个 **Mermaid `sequenceDiagram`** 图表,清晰地展示组件间的交互时序。

## 数据模型设计 (Data Model Design)
- 为核心业务实体设计初步的数据 Schema。
- 必须提供一个 **Mermaid `erDiagram`** (实体关系图),清晰地展示主要数据实体及其之间的关系(如:users, articles, comments, likes 表以及它们的主键、外键关系)。

## API接口定义 (API Definitions)
- 逐一定义出关键的对外提供功能的API端点。
- 请包含请求方法、简要说明。

## 关键决策的依据 (Rationale for Key Decisions)
针对文档中做出的几个关键技术或架构决策,提供详细的解释和和依据

详细设计(LLD)文档

描述

产出 详细设计文档readme_xx_lld.md。 使用示例: 请根据需求文档 @readme_xx_prd.md 、系统设计文档 @readme_xx_hld.md,现有代码调用流程文档@readme_xx_callchain.md,为我进行详细设计,将结果保存为 readme_xx_lld.md。完成后等待我审核。务必遵循规则@LLDesign

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
**角色:** 你是一名资深的软件工程师,你的任务是为用户进行详细设计(Low-Level Design)。
**目标:** 这份详细设计文档需要足够详尽,以便cursor(一款基于VSCode的LLM AI编程IDE)可以依据此文档进行编码开发。
设计不宜太复杂,能实现MVP版本、具备可迭代能力即可。

# 产出要求
优先复用现有代码。
请严格按照以下结构,使用Markdown格式生成详细设计(LLD)文档。

## 项目结构与总体设计 (Project Structure & Overall Design)

## 目录结构树 (Directory Tree)
在文档的最开始,使用文本形式清晰地展示整个目录。

## 整体逻辑和交互时序图 (Overall Logic & Sequence Diagram)
- 描述核心工作流程。
- 提供一个**Mermaid `sequenceDiagram`**,展示为完成一个典型请求,例如说明`main.py`, `services.py`, `providers.py` 等文件是如何协作的,以及调用时传递的参数和返回值。

## 数据库表结构深化 (Detailed Database Schema)
- 提供完整的SQL DDL语句。
- 明确字段类型、约束和必要索引。
- 如果系统不涉及数据表,忽略本节

## 配置项 (Configuration)
- 列出运行所需的所有环境变量或配置文件参数。
- 如果系统不涉配置项,忽略本节

## 模块化文件详解 (File-by-File Breakdown)

(此部分将根据目录树,逐一展开描述其中的每一个代码文件)
## 涉及到的文件详解 (File-by-File Breakdown)
对于每一个代码文件,提供以下信息:
### <文件相对路径>
a. 文件用途说明
b. 文件内容概览 (类与函数)
c. 文件内类图 (Mermaid `classDiagram`) *(若存在类)*
对于每个函数/方法,提供以下信息:
#### 函数/方法详解
- 逐一说明输入参数
- 输出
- 实现步骤和要点 (伪代码或文字描述)

技术选型

描述

产出: 技术选型文档 readme_xx_research.md 用示例: 需求内容 以上是我的需求。请为我进行技术调研,将结果保存为readme_xx_research.md。务必遵循规则 @research

提示词内容

1
2
3
4
你的角色是资深技术选型顾问,熟悉各种被广泛使用的技术框架和组件,善于调研并选择最佳实践。

以上是我的需求。请你根据需求,为我推荐和讨论技术选型。选型内容包含开发框架、关键组件,请提出不同的方案供我选择讨论。优先考虑被开源社区或者google等著名互联网公司广泛使用的方案。
仅进行技术选型讨论,不要进行系统设计、详细设计等其它讨论。

代码编写

使用公共库

描述

在生成代码的时候,尽量使用cf_public\core下面公共库

提示词内容

1
在生成代码的时候,尽量使用cf_public\core下面公共库

功能和代码重构

描述

制定渐进式小步迭代计划 重构要在保障代码功能不变的情况下,让代码结构变得更合理。因此不宜把性能优化、改bug之类的任务和重构任务同步做。 重点是制定渐进式小步迭代计划,例如: 在和AI讨论完毕厘清重构需求之后

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
## 渐进式添加新功能指导原则

在添加新功能的过程中,请严格遵循以下指导原则:

1. **功能识别与模块化**:
- 明确识别新功能所涉及的**核心业务逻辑**和**用户交互点**。
- 基于新功能的职责和逻辑边界,进行**模块化设计**,以便于未来的维护和扩展。
- **优先复用现有功能**和模块,避免重复造轮子。对于需要修改或扩展的现有模块,请评估其对新功能的影响。

2. **渐进式功能开发与集成**:
- 将新功能分解为**可管理的、小步骤的开发任务**。每个小步骤都应能独立完成并进行验证。
- **关键要求**:每完成一小步开发后,必须确保整个应用程序能够成功启动并保持可运行状态。同时,应用程序应能(部分地)展示出由这一小步开发所带来的新功能效果或变化。
- 在开始对新功能进行实际开发前,请简要说明你计划采取的**渐进式开发步骤**,包括如何逐步集成到现有系统中。

3. **采用分层的模块化策略**:
- 在添加新功能时,请注意进行**适度的模块化处理**。确保新添加的每个代码文件不超过**500行**。
- 避免过度细化,在满足行数限制的前提下,避免将文件或模块拆分得过小或功能过于琐碎。力求使每个模块/文件承载相对完整且有意义的功能。
- 将不同模块归纳到不同的层。将新功能涉及的业务逻辑、数据访问和用户界面等部分归纳到各自的层级,保持清晰的职责分离。将程序入口点视为最顶层。

4. **执行计划与确认**:
- 在正式开始任何代码修改之前,请先提交一份你的**新功能开发计划**。这份计划应包括:
* 对新功能的**初步分解**和**模块化设想**。
* 对**受影响的现有模块**以及可能进行的**适配或扩展**的说明。
* 你计划的**渐进式开发与集成步骤**。每个步骤的应包括参考信息,如codebase中已有代码、其它API等等。
- 我将在审阅此计划后,给予你执行的确认或调整建议。

请确保你的每一步操作都清晰、有条理,并优先保证代码在功能添加过程中的**稳定性和可验证性**。

当你不确定如何提问时

描述

当你不确定如何提问时

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1. 让AI帮你澄清需求  
输入:"我是Vue开发者,需要做一个移动端H5的扫码支付功能,
当前遇到两个问题:
1. 在iOS微信环境中调用相机经常失败
2. 用户扫完码后页面卡在加载状态
请问如果要解决这些问题,我应该提供哪些具体信息?"

预期输出:
- 微信JS-SDK初始化代码片段
- 支付回调的日志示例
- 网络环境检测方法

2. 业务逻辑分解模板
[扫码支付全流程分解]
1. 生成订单 → "用AI生成订单号生成工具函数"
2. 渲染二维码 → "生成带logo的canvas二维码组件"
3. 状态监听 → "编写轮询接口的Composition API"
4. 结果展示 → "生成支付成功/失败的动效组件"

代码编写基本提示词

描述

请根据需求文档 @readme_xx_prd.md、详细设计文档 @readme_xx_lld.md, 渐进式小步迭代编码步骤文档 @readme_xx_codingplan.md,为我完成步骤……。务必遵循规则 @coding

提示词内容

1
2
3
4
5
6
7
8
9
10
11
**角色:** 你是一名资深的软件工程师。
**目标:** 完成用户指定的编码要求,编写的代码**稳定且可验证**。

**要求**
- 仅仅完成用户指定的步骤,完成后等待用户审核、验证,不得自作主张写后继步骤。
- 编码前先对已有代码进行分析,对受影响的现有代码文件进行说明,并给出**依据**。
- 遵循fail-fast原则:掩盖错误比错误本身更加危险,避免使用类似`try-except`语句吞没异常。
- 进行**适度的模块化处理**,确保每个代码文件不超过**500行**。
- 优先**复用已有代码**
- 低层模块不得调用高层模块
- 除了入口(如main.py)和web层(如web api层),其它层不得引入web框架(如fastapi)模块

探讨方案的提问技巧

描述

在写代码之前,确认方案阶段

提示词内容

1
2
3
4
5
6
7
8
9
1. 需要先与我讨论核心思路和实现方向。
2. 与我一起确认方案的细节和我的具体需求。
3. 只有在我们对方案达成共识之后,才能进入编码阶段。

4. 充分研究和分析现有代码,以了解系统的现有能力和限制。
5. 从最简单、最直接的解决方案开始考虑。
6. 避免提出不必要的复杂设计。
7. 评估方案并明确指出其中存在的潜在风险。
8.有任何疑问都可以向我提出

渐进式小步迭代编码

描述

使用方法:请根据需求文档 @readme_xx_prd.md 、详细设计文档 @readme_xx_lld.md,现有代码调用流程文档@readme_xx_callchain.md,为我制定开发步骤,将结果保存为 readme_xx_codingplan.md。务必遵循规则@codingplan

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
**角色:** 你是一名资深的软件工程师,你的任务是为用户制定**渐进式小步迭代**编码步骤。
**目标:** 编码步骤文档中每一步操作都清晰、易于编码,保证每一步**稳定性和可验证性**。cursor(一款基于VSCode的LLM AI编程IDE)可以依据此文档进行编码开发,每一步完成后监督者可以立刻运行验证。

---

以下为渐进式小步迭代编码说明,以确保代码的可控性、稳定性和可验证性:
1. **拆分出独立且完整的小步骤**
- 拆分成可独立完成的小步骤,每个小步骤都应能独立完成、可验证,必须确保整个应用程序能够成功启动并保持可运行状态。同时,应用程序应能(部分地)展示出由这一小步开发所带来的新功能效果或变化。
- 每个步骤即一次小而完整的迭代。
- 每次小步迭代功能可以不全,但是必须确保程序可运行、可验证。
2. **采用模块化策略**
- 请注意进行**适度的模块化处理**。确保新添加的每个代码文件不超过**500行**。
- 避免过度细化,在满足行数限制的前提下,避免将文件或模块拆分得过小或功能过于琐碎。力求使每个模块/文件承载相对完整且有意义的功能。

---

仅制定开发步骤,完成后等待用户审核,不得自作主张进行后继编码。
# 产出要求
- 使用文本形式清晰地描述代码目录结构。
- 对**受影响的现有模块**以及可能进行的**适配或扩展**的说明。
- 各个编码步骤优先**复用已有代码**。
- 逐一列出**渐进式小步迭代式开发与集成步骤**。

渐进式提问技巧

描述

1
2
3
4
5
6
第一轮:请给我一个Vue3的扫码支付页面基础模板  
第二轮:增加以下功能:
- 微信/支付宝双渠道二维码切换
- 15秒自动刷新二维码的倒计时动画
- 调用手机相机的权限检测逻辑
第三轮:根据用户地理位置自动推荐支付渠道(国内优先微信,海外优先支付宝)

代码军规 rule

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
代码军规:
1 指针必须进行有效性判断(判空)
2 除0必须判断
3 禁止使用魔数
4 必须防范数组、内存越界
5 类成员变量、局部变量必须初始化
6 所有编写的代码必须用单步调试的方法确保跑到每一逻辑分支
7 禁止使用不安全的CRT函数--_s后缀的函数也不能使用,需要使用微软提供的Safe函数,比如StringCchCopy
8 多线程数据访问必须保证读写安全
9 必须确保资源正确释放(内存、句柄)
10 释放dll前需确保线程都已执行完成
11 提交SVN/GIT代码,必须认真检查没一行代码。
12 禁止在UI线程中进行耗时操作(例如:网络请求)
13 导出接口只能使用基础数据类型作为参数(例如:int、float、char*,禁止使用std::string\CString\std::vector等复杂数据类型)
14 互斥锁只锁数据,千万不要因为偷懒锁大段代码,扩大锁的范围。

代码规范 rule

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
代码规范:
1. 函数单一职责
2. 函数不超过50行
3. 圈复杂度不超过10(if/while/for/case/catch/三元运算符)
4. 禁用magic number
5. 命名具备自释性
6. 嵌套层数不超过三层
7. 函数参数不超过7个
8. 单一抽象层原则
9. 一行代码一件事
10. 一变量一含义
11. 函数的大括号,按照Windows代码规范,必须换行出现

Bug修复

修复Bug,避免出现幻觉

描述

使用示例,直接copy异常现象输出贴给它,然后:请为我分析上述问题。务必遵循规则@hitbug

提示词内容

1
重新读取涉及到的代码,分析原因,给出依据,并进一步分析这个原因的影响范围。请提出不同的解决方案等待用户审查,不得自作主张直接修复。

AI 分析c++ dump崩溃信息

提示词内容

1
2
3
4
5
6
7
8
分析以下新崩溃:(@崩溃信息异常堆栈完整信息.txt【由dubadumper.exe自动生成】)
0.角色:** 你是一名资深的c++工程师,擅长对崩溃dump进行详细定位和分析
1.先分析崩溃的本质性原因,在一步一步指定我解决崩溃问题。
2.先给出原因分析,不着急改代码,跟我讨论完成后再进行修改
3.这是一个老项目有很多无用目录,请根据@ai_knowledge_grapth 来进行正确目录的搜索和定位
4.请自行解决和验证编译问题,若需要编译项目,请参考docs/BUILD_README.md
5.不要用try catch当做解决方案
6.以上崩溃为线上崩溃,是偶现崩溃,需要更系统的解决方案,而不是判空处理

角色定位,拒绝假设

描述

让ai深度结合当前项目信息,不要给出假设的思路。

提示词内容

1
你现在开始是一个电脑端安全软件专家,你的一切行为都应该以当前项目的上下文为依据,不要假设,也不要推断。如果你缺乏足够的信息,可以询问我。

让AI通过git,崩溃解决方案总结出适合指导AI解决崩溃的方案

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
当前大型c++项目跨度时间非常长,线上有大概4%的崩溃,我们经过一周的时间的解决崩溃后,想总结一些通用的经验,用来快速指导AI编辑器或者大模型分析dump中的一些原则和经验,
根据原则,经验,项目特点来快速解决崩溃。可以参考的资料有:
A.请review下当下分支下解决崩溃的40条git提交记录,来分析解决崩溃的方式方法。
B.我们非常注重崩溃找到本质问题来解决问题,而不是简单判空和try catch解决问题。
C.我们一般提供给大模型的提示如下:
“分析下新崩溃:
0.角色:** 你是一名资深的c++工程师,擅长对崩溃dump进行详细定位和分析
1.若发现现在代码与异常堆栈行号不对,请用git查看之前匹配版本(对应的崩溃分析文件名有对应的日期,比如ddrivergenius.exe_2025.6.10.591_f5f81_6f95d94.txt,2025.6.10就是为日期)
2.先分析崩溃的本质性原因,在一步一步指定我解决崩溃问题。
3.先给出原因分析,不着急改代码,跟我讨论完成后再进行修改
4.这是一个老项目有很多无用目录,请根据@ai_knowledge_grapth 来进行正确目录的搜索和定位
5.请自行解决和验证编译问题,若需要编译项目,请参考docs/BUILD_README.md
6.不要用try catch当做解决方案
7.以上崩溃为线上崩溃,是偶现崩溃,需要更系统的解决方案,而不是判空处理
8.请代码为准绳,不要用“可能,猜测”的方式读取代码。有代码请给出代码路径信息。”

D.一般分析完一个dump,我们会建立一个md文档来描述这个问题和讨论对应的解决方案。参考:docs\dumpsfix
E.整个项目的知识图谱的入口在 docs\AI_KNOWLEDGE_GRAPH.md
F.一些线上崩溃dump,用wingdb分析出崩溃堆栈的样例在:dumpme\tempdir\dubadumper

我们的目标如何在AI编辑器,ai大模型的协作下,快速解决线上崩溃,希望能够有比正常工程师10倍以上的效率提升。
请仔细分析当前项目和对应的参考资料。如果有不清楚与我讨论,并且与我一起寻找最佳的解决方案。

代码分析

分析现有代码(项目级别)

描述

分析入口代码开始的调用链。 请以@xx.py为起始代码,分析整个调用链,保存为readme_xx_callchain.md 。务必遵循规则@parsecallchain。

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
你的任务是,从入口代码开始分析出完整的代码调用链。不仅仅分析入口文件本身,请依序追踪调用链涉及到的代码文件、配置文件,输出其核心业务逻辑的**调用链信息**。调用链由节点组成,一个调用节点可以是codebase中的一个函数、一个类的方法。

由于涉及代码较多,请你对照下述产出结构,拆分成多个步骤逐步执行。
错误做法:将调用链涉及到的所有文件分析出结果,才将结果写入文档。
正确做法:每分析完一个节点,立刻调用工具将结果写入文档。

你必须在每个步骤完成之后**复述产出要求**,因为你总是忘记产出要求。你的复述以“我将在每个步骤完成之后复述产出要求:”开头。

# 产出要求

请按照以下结构,使用Markdown格式生成详细的调用链说明。
## 调用链

逐一为每个节点提供以下信息,**仅关注重要的函数/方法调用**:
### 节点(以函数/类方法命名节点)
所在代码文件相对路径
用途
逐一说明输入参数
输出说明

## 整体用途
详述调用链的整体用途

## 目录结构
调用链涉及到的文件及其所属的目录结构

## 调用时序图
生成mermaid sequenceDiagram格式的时序图。participant为**文件相对路径**,展示为完成一个典型请求,以及调用时传递的参数和返回值。

## 分析单个文件

描述

请分析@xx.py,保存为readme_xx_api.md 。务必遵循规则@parsecode 。

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
仅分析代码,勿提出任何方案建议。
为避免代码太多导致问题,请你将每个函数/方法作为一个处理步骤,拆分成多个步骤来完成任务。
错误做法:将整个文件分析出结果,才将结果写入文档。
正确做法:每分析完一个函数/方法,立刻调用工具将结果写入文档。

---

你必须在每个步骤完成之后**复述产出要求**,因为你总是忘记产出要求。你的复述以“我将在每个步骤完成之后复述产出要求:”开头。

**产出要求**
请按照以下结构,使用Markdown格式生成详细的说明。

# <文件名称>

## 类/方法/函数详解

逐一对每个类提供以下信息:
### <类名>
逐一对每个类方法提供以下信息:
#### <类方法>
- 用途
- 逐一说明输入参数
- 输出
- 实现要点 (伪代码或文字描述)

#### 类用途
类用途和使用场景说明

逐一对每个函数提供以下信息:
### <函数名>
- 用途
- 逐一说明输入参数
- 输出
- 实现要点 (伪代码或文字描述)

## 文件用途
1. 代码用途概述
2. 使用场景和流程

## 文件内类图
Mermaid `classDiagram`格式。如果不存在类或者只有一个类,请忽略本节。

## 调用时序图
mermaid sequenceDiagram格式描述调用流程。如果有多个启动入口,请创建多个时序图。

让AI Reivew代码

提示词内容

1
好的,现在问题基本都解决了,接下来我们要准备提测了,我已经将代码加到了到git 暂存区,请你将暂存区的修改输出到一个临时文件,然后review这个文件

AI创建提测文档

描述

提示词内容

1
我们提测前还需要编写以测试者为阅读对象的提测文档,请你参考 [以前我们自己写的提测文档],也写一份 [一般是我们的提测文档标题] 的提测文档,并保存为MD格式,相关的图片和构建路径等你无法提供的内容可以备注留空,我将会补全。

代码审核

代码审核(python)

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
请review代码:
存在哪些问题/bug?
是否遵循clean code原则?
函数职责是否独立且单一?
是否有无效的变量、导入包、注释、代码?
是否遵循fail-fast原则,不使用try-except隐匿异常?
是否未在`.py`文件顶部import依赖项?

如果有,请逐一列出,勿改代码。按以下格式输出:
## 函数x
问题
...
## 函数x
问题

代码测试

单元测试(python)

描述

使用示例: 请读取并分析代码 @xxx.py,然后为它写单元测试。务必遵循规则@unittest

提示词内容

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
单元测试重点关注关键功能的测试,要求:
1. **测试用例**:专注于构建测试用例。为关键函数/方法提供测试用例,不必面面俱到,避免测试用例太复杂。
测试用例优先以易于理解的Table-Driven Tests形式呈现,例如:

class TestMath(unittest.TestCase):
def test_multiply(self):
# Table-Driven Test cases
test_cases = [
(2, 3, 6), # 正常情况
(-1, 5, -5), # 负数测试
(0, 10, 0), # 零值测试
]
for a, b, expected in test_cases:
got = multiply(a, b)
self.assertEqual(got, expected, f"{a}*{b}应得{expected},实际得到{got}")

2. **依赖处理策略**:除非用户明确要求,否则不得对被测试代码进行mock, 应直接调用依赖。
3. **测试框架**:Python的unittest单元测试框架。不得创建setUp方法,让测试代码跟随测试用例,便于阅读。
4. **命名**:测试文件与被测试文件在同一个目录下,命名为test_*.py。
5. 不得使用类似`try-except`语句吞没异常。
6. 如果被测的类为AI Model并且输出包含张量,仅测试model的输出shape是否符合预期。

请分成小段进行编码,比如逐个为每个函数/方法的写单元测试。
-------------本文结束感谢您的阅读-------------