场景一、出现bug解决后我们需要进行根因分析归纳总结,沉淀为技术方案
如出现json解析bug要总结可用提示词:
针对json解析我所做出的修改出一版技术方案,从bug日志复现、问题定位、技术方案、验证可行性、最后测试以及修改文件清单这几个流程写一套我做出的优化md文档,命名"失败重试接口json解析优化.md",放在导入失败回滚方案这个目录下场景二、单元测试相关提示词
1. 针对我们的类或方法给出单元测试技术方案的提示词:
-
完整版提示词(仅作为参考,有选择性的借鉴使用,不推荐,提示词太长):
单个类/方法 单元测试技术方案生成提示词（后端标准）
【通用标准版｜直接复制使用】
你现在是资深后端测试架构师，请根据我提供的 Java 类/方法源码，输出一份完整、专业、可落地的《单元测试技术方案》。
方案需要针对当前类/方法量身定制，不要通用套话，必须包含以下全部章节：- 被测模块概述
- 当前类/方法职责、业务定位
- 核心输入、核心输出
- 依赖的外部服务、数据库、第三方接口、缓存、MQ
- 当前方法核心逻辑链路梳理
- 测试难点与风险点分析
- 哪些外部依赖需要 Mock
- 哪些分支容易漏测
- 存在的边界场景、异常场景、并发风险
- 事务、重试、幂等、JSON解析、特殊字符风险
- 测试整体设计思路
- 采用的测试策略（全量分支覆盖/场景覆盖/边界覆盖）
- Mock 方案：哪些依赖使用 @MockitoBean / Mockito 模拟
- 数据构造方案、入参构造策略
- 不启动完整Spring容器、轻量化单元测试原则
- 完整测试用例设计（必须全覆盖）
包含三大类场景，逐条列出：
- 正常场景：正常入参、正常流程、正常返回
- 异常场景：空参数、非法参数、第三方异常、接口超时、返回空、失败回调
- 边界场景：极值、空集合、超长文本、特殊字符、JSON破损、重试触发条件
每条用例包含：用例名称、测试场景、入参构造、Mock行为、预期结果、校验点。
- 关键逻辑专项测试方案
根据当前方法自动识别专项：
- 重试机制测试方案
- 事务回滚测试方案
- JSON解析容错测试方案
- 数据兜底/默认值测试方案
- 分支条件全覆盖测试方案
- 测试编码实现方案
- 测试类注解声明
- 需要Mock的依赖清单
- 核心方法单元测试代码结构
- 断言策略（返回值、异常、日志、交互次数）
- 已知问题兼容方案
- 废弃注解警告兼容（@MockBean / 过时API）
- JSON特殊字符、单引号、换行符容错
- 缓存、上下文、会话干扰规避
- 测试覆盖结论与质量保障说明
【强制输出约束】
- 禁止套话，全部针对我提供的 具体代码逻辑 生成；
- 所有用例必须 可落地、可直接编写代码；
- 输出结构正式、技术化，可直接作为技术方案文档提测/评审；
- 自动识别当前方法的：重试、异常、JSON、数据库、向量、文件导入等业务特性针对性设计用例。
【你的项目专属增强后缀（固定追加）】
本项目为 SpringBoot3.5 + JUnit5 + Mockito 环境，单元测试优先使用 @MockitoBean，废弃API仅做警告不做报错拦截，需要重点覆盖 JSON 破损容错、重试失败场景、数据库向量数据占位逻辑、异常数据兜底恢复场景。 -
日常高频使用提示词 (很短,推荐,能覆盖我们需要的核心内容即可,可自己添加其他需要的内容):
结合下方某类某方法的Java 代码，输出单元测试方案，包含模块职责、待测场景、Mock 策略、测试用例、落地要点。
注意只生成增量模式的,不需要全量模式。最后,禁止读取不必要的文件,若要读取需要经过我同意。最后md文档放在此目录下: 功能设计思路/pgVector批处理策略/增量模式测试
2. 人工审阅确定好单元测试技术方案的可行性后,提供提示词让ai编写代码:
严格按照已定单元测试方案XX单元测试方案名，编写 JUnit5+Mockito 可运行单元测试代码，做好异常断言、Mock 逻辑。
禁止编写任何多余的扩展代码,禁止读取任何不相关的文件。3. 针对我们已经写完的单元测试代码进行归纳总结的提示词:
请根据我提供的XX测试类(替换为你的单元测试测试类名称)的Java 单元测试代码，生成一份简洁规范的单元测试技术文档。包含：测试模块说明、技术栈、测试设计思路、核心用例、异常覆盖情况、测试问题总结、最终测试结论。文档正式、结构化、适合归档复盘。4. 专项增强提示词（适配你的项目场景：向量、重试、MQ、单元测试）
本次单元测试为向量知识库业务测试，请重点总结：重试机制测试、异常熔断测试、第三方 Embedding 接口 Mock 测试、数据入库占位逻辑、JSON 解析容错、数据库向量字段处理、异常数据兜底逻辑。