需求编写
精准定义需求,参考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是否符合预期。
请分成小段进行编码,比如逐个为每个函数/方法的写单元测试。
|