场景一、出现bug解决后我们需要进行根因分析归纳总结,沉淀为技术方案如出现json解析bug要总结可用提示词:针对json解析我所做出的修改出一版技术方案,从bug日志复现、问题定位、技术方案、验证可行性、最后测试以及修改文件清单这几个流程写一套我做出的优化md文档,命名失败重试接口json解析优化.md,放在导入失败回滚方案这个目录下场景二、单元测试相关提示词1. 针对我们的类或方法给出单元测试技术方案的提示词:完整版提示词(仅作为参考,有选择性的借鉴使用,不推荐,提示词太长):单个类/方法 单元测试技术方案生成提示词后端标准 【通用标准版直接复制使用】 你现在是资深后端测试架构师请根据我提供的 Java 类/方法源码输出一份完整、专业、可落地的《单元测试技术方案》。 方案需要针对当前类/方法量身定制不要通用套话必须包含以下全部章节 1. 被测模块概述 - 当前类/方法职责、业务定位 - 核心输入、核心输出 - 依赖的外部服务、数据库、第三方接口、缓存、MQ - 当前方法核心逻辑链路梳理 2. 测试难点与风险点分析 - 哪些外部依赖需要 Mock - 哪些分支容易漏测 - 存在的边界场景、异常场景、并发风险 - 事务、重试、幂等、JSON解析、特殊字符风险 3. 测试整体设计思路 - 采用的测试策略全量分支覆盖/场景覆盖/边界覆盖 - Mock 方案哪些依赖使用 MockitoBean / Mockito 模拟 - 数据构造方案、入参构造策略 - 不启动完整Spring容器、轻量化单元测试原则 4. 完整测试用例设计必须全覆盖 包含三大类场景逐条列出 - 正常场景正常入参、正常流程、正常返回 - 异常场景空参数、非法参数、第三方异常、接口超时、返回空、失败回调 - 边界场景极值、空集合、超长文本、特殊字符、JSON破损、重试触发条件 每条用例包含用例名称、测试场景、入参构造、Mock行为、预期结果、校验点。 5. 关键逻辑专项测试方案 根据当前方法自动识别专项 - 重试机制测试方案 - 事务回滚测试方案 - JSON解析容错测试方案 - 数据兜底/默认值测试方案 - 分支条件全覆盖测试方案 6. 测试编码实现方案 - 测试类注解声明 - 需要Mock的依赖清单 - 核心方法单元测试代码结构 - 断言策略返回值、异常、日志、交互次数 7. 已知问题兼容方案 - 废弃注解警告兼容MockBean / 过时API - JSON特殊字符、单引号、换行符容错 - 缓存、上下文、会话干扰规避 8. 测试覆盖结论与质量保障说明 --- 【强制输出约束】 1. 禁止套话全部针对我提供的 具体代码逻辑 生成 2. 所有用例必须 可落地、可直接编写代码 3. 输出结构正式、技术化可直接作为技术方案文档提测/评审 4. 自动识别当前方法的重试、异常、JSON、数据库、向量、文件导入等业务特性针对性设计用例。 --- 【你的项目专属增强后缀固定追加】 本项目为 SpringBoot3.5 JUnit5 Mockito 环境单元测试优先使用 MockitoBean废弃API仅做警告不做报错拦截需要重点覆盖 JSON 破损容错、重试失败场景、数据库向量数据占位逻辑、异常数据兜底恢复场景。日常高频使用提示词(很短,推荐,能覆盖我们需要的核心内容即可,可自己添加其他需要的内容):结合下方某类某方法的Java 代码输出单元测试方案包含模块职责、待测场景、Mock 策略、测试用例、落地要点。 注意只生成增量模式的,不需要全量模式。最后,禁止读取不必要的文件,若要读取需要经过我同意。最后md文档放在此目录下: 功能设计思路/pgVector批处理策略/增量模式测试2. 人工审阅确定好单元测试技术方案的可行性后,提供提示词让ai编写代码:严格按照已定单元测试方案XX单元测试方案名编写 JUnit5Mockito 可运行单元测试代码做好异常断言、Mock 逻辑。 禁止编写任何多余的扩展代码,禁止读取任何不相关的文件。3. 针对我们已经写完的单元测试代码进行归纳总结的提示词:请根据我提供的XX测试类(替换为你的单元测试测试类名称)的Java 单元测试代码生成一份简洁规范的单元测试技术文档。包含测试模块说明、技术栈、测试设计思路、核心用例、异常覆盖情况、测试问题总结、最终测试结论。文档正式、结构化、适合归档复盘。4. 专项增强提示词适配你的项目场景向量、重试、MQ、单元测试本次单元测试为向量知识库业务测试请重点总结重试机制测试、异常熔断测试、第三方 Embedding 接口 Mock 测试、数据入库占位逻辑、JSON 解析容错、数据库向量字段处理、异常数据兜底逻辑。场景二、单元测试提示词自身开发实际应用总结1. 极简提示词适合个人做demo项目,无需复杂单元测试方案直接写代码为XX类写出单元测试 位置: 测试类在tools包下。 约束: 1. 要求覆盖边界、正常、异常、判空等场景。 2. 在单元测试类上方简易列出所有测试场景表格状实际写出来对于一些简单的类效果还可以尤其这个表格状深得我心非常清晰简易的描述出当前单元测试类覆盖的所有情况便于快速查阅有无遗漏情况。所以这个约束条件我们可以扩充到自己的单元测试提示词约束库中。2. 单元测试约束条件(个人实际使用,不断扩充中)为XX类写出单元测试 位置: 测试类写在tools包下。 技术栈: 使用Junit单元测试框架优先使用mock隔离外部网络真实接口仅少量集成测试。 参考: XX单元测试类 约束: // 通用约束 1. 类上均使用SpringbootTest注解 2. 测试的工具类都要使用Resource进行依赖注入禁止手动new 工具类 3. 要求做最小化读取只定位并阅读我点名的参考类 WebSearchTool以及查看 src/main/resources/ToolCalling设计方案 目录下已有的方案文档格式这是为了后续方案能对齐风格不涉及全盘扫描 4.单元测试加上DisplayName类名和每个测试方法填写业务场景中文描述方便看测试报告。 // 覆盖场景约束 1. 要求覆盖边界、正常、异常、判空、合法性、超时等场景。要求覆盖待测试类中的所有分支。 2. 在单元测试类上方简易列出所有测试场景表格状 3. 第三方接口异常如超时、401鉴权失败、限流、无搜索结果 4. 单元测试类中每种场景之间用 “// XX场景 ”分隔开,如“// 正常场景 ”3. 目前效果最好的极简单元测试提示词(不断更新迭代覆盖之前版本)为PDFGenerationTool类写出单元测试 位置: 测试类写在tools包下。 技术栈: 使用Junit单元测试框架优先使用mock隔离外部网络真实接口仅少量集成测试。 参考: TerminalOperationToolTest单元测试类 约束: 1. 类上均使用SpringbootTest注解 2. 测试的工具类都要使用Resource进行依赖注入禁止手动new 工具类 3. 要求做最小化读取只定位并阅读我点名的参考类这是为了后续方案能对齐风格不涉及全盘扫描 4. 单元测试加上DisplayName类名和每个测试方法填写业务场景中文描述方便看测试报告。 覆盖场景约束: 1. 要求覆盖边界、正常、异常、判空、合法性、超时等场景。 2. 在单元测试类上方简易列出所有测试场景表格状 3. 第三方接口异常若存在则写,不存在不写如超时、401鉴权失败、限流、无搜索结果 4. 单元测试类中每种场景之间用 “// XX场景 ”分隔开,如“// 正常场景 ”提醒一下只要你VibeCoding开发完新的功能类后进行codereview发现逻辑分支没有问题,那么检查一下你若要进行单元测试需要哪些流程转换的关键步骤信息,来帮助你判断你这个结果的过程是否与你单元测试当前方法想要的测试关键节点数据一样最后的结果是否一样。说人话就是,你的类中的关键步骤的log日志写好了,那么我们VibeCoding完单元测试以后,甚至可以直接相信AI直接按照当前方法测了什么来观察日志信息,只要关键过程流程转换信息对的上没有问题结果也没问题,基本测试不会出错,甚至你不用看代码。但这个只适合很着急自己做小demo用,生产开发环境在公司还是要最后进行一下codereview的。场景三、开发新功能相关提示词VibeCoding 提示词模板VibeCoding 核心思路写清楚业务背景、需求、约束、技术栈、已有代码、输出规范让 AI 直接产出可落地技术方案 代码减少来回拉扯。使用小技巧VibeCoding 体验提升先方案后代码先用模板 1 拿方案你确认逻辑没问题再用模板 2 生成代码不要一上来直接写代码。约束一定要带上把你踩过的坑写进提示词比如禁止手动 new SpringBean、不要 lombok、ConfigurationProperties 规范避免 AI 产出错误代码。贴参考代码像你的 WebSearchTool可以直接粘贴给 AI 当做参考实现。单元测试强制要求输出写完直接跑减少线上 bug。注意仅作为参考模板主要学习格式并根据自己的实际项目进行润色填充最重要的是AI经常理解不清楚漏掉的点一定要写进踩坑提示里面禁止AI犯错来回拉扯提高时间成本。①生成技术方案plaintext角色SpringBoot Java后端AI Agent工具开发。 项目AI Agent工具调用服务使用ConfigurationProperties读取yml配置密钥走环境变量Bean交给Spring管理禁止手动new带注解的Bean。 需求【写你的功能需求】 约束 1.yml横杠命名Java驼峰密钥用${ENV_NAME:} 2.工具类加Component禁止手动new 3.不用lombok手写get/set 输出先输出技术方案需求拆解、yml配置、类设计、风险点不要直接写完整代码。②生成业务代码方案确认后用plaintext角色SpringBoot后端输出可直接复制运行完整代码。 项目AI Agent工具调用ConfigurationProperties绑定yml密钥环境变量Bean交给Spring禁止手动new。 确认方案【粘贴方案要点】 参考WebSearchTool联网搜索工具类 约束 1.ConfigurationProperties嵌套静态内部类 2.Component注册Bean禁止手动new 3.手写get/set不使用lombok 4.附带Junit5 SpringBootTest单元测试关键注释 输出完整Java类yml片段。③新增 Tool 工具专用plaintext角色AI Agent工具开发。 项目SpringBoot Agent工具全部工具为Spring BeanConfigurationProperties读配置禁止手动new。 工具名【XXXTool】 功能【工具能力入参出参】 yml配置 tools: xxx-api: api-key: ${XXX_API_KEY:} 参考WebSearchToolComponent、Resource注入配置、PostConstruct初始化、对外业务方法、junit5测试 输出配置类追加代码、yml片段、Tool完整类、单元测试、踩坑清单。④排错调试plaintext现象【bug现象】 相关代码【贴代码】 yml【贴yml】 已排查【已经确认过的点】 输出根因、修复完整代码、验证步骤、规避坑点。场景三、开发实际应用测试个人实际开发使用真实测试过1. 开发提示词角色SpringBoot Java后端AI Agent工具开发。 项目AI Agent工具调用服务Bean交给Spring管理禁止手动new带注解的Bean。 需求开发网页抓取工具调用写在包名tools下,工具类命名为WebScrapingTool。使用jsoup库实现网页抓取功能。 约束 1.工具类加Component禁止手动new 2.必须进行入参校验以及各种返回值的判空校验防止发起网页请求资源浪费以及NPE异常报错。 参考WebSearchTool 输出先输出技术方案需求拆解类设计、风险点不要直接写完整代码。 技术方案存储位置: src/main/resources/ToolCalling设计方案。必须我同意后才可以存储到指定位置。2. 待优化约束1. 若有需要,做好超时、重试逻辑兜底、异常处理 2. 生产环境下需要的log日志进行必要的填充,便于定位错误,使用Slf4j注解。3. 实际我们只使用1中的提示词产生的技术方案如下(效果尚可):# WebScrapingTool 网页抓取工具 — 技术方案 v2jsoup 版 状态已批准 日期2026-08-18 参考类com.jingdong.ai_super_love_agent.tools.WebSearchTool ## 约束回顾 1. Bean 交给 Spring 管理工具类加 Component禁止手动 new 带注解的 Bean 2. 必须进行入参校验以及各种返回值的判空校验防止发起网页请求资源浪费以及 NPE 异常报错 3. 使用 jsoup 库实现网页抓取功能 ## 一、需求拆解 | # | 子需求 | 说明 | |---|--------|------| | 1 | 引入 jsoup 依赖 | pom.xml 新增 org.jsoup:jsoup:1.23.1 | | 2 | 工具注册 | Component 交给 Spring 管理方法加 Tool ToolParam返回 String风格对齐 WebSearchTool | | 3 | **入参校验** | url 判空 协议校验仅 http/https非法入参**直接返回错误提示不发起请求**防止浪费资源 | | 4 | jsoup 抓取 | Jsoup.connect(url) 设置超时、UA、maxBodySize解析为 Document | | 5 | **返回值判空** | Document、title()、body()、body().text() 逐级判空全链路防 NPE | | 6 | 异常兜底 | 统一 catch失败返回 Error scraping url: xxx 字符串不抛异常对齐 WebSearchTool | | 7 | 单元测试 | 轻量测试不启动 Spring 容器只验证基本功能 | ## 二、类设计 tools/WebScrapingTool.java ├── ComponentSpring 管理禁止手动 new ├── 常量 │ ├── TIMEOUT_MS 10_000 // 连接读取超时 │ ├── MAX_BODY_SIZE 2MB // jsoup 下载体积上限防超大页面 │ ├── MAX_TEXT_LENGTH 5000 // 返回给大模型的文本截断长度 │ └── USER_AGENT // 常规浏览器 UA降低被反爬概率 │ ├── Tool scrapeWebPage(ToolParam url) : String │ │ 执行链路校验前置任一失败立即返回不浪费请求 │ ├── ① StringUtils.isEmpty(url) → 空参直接返回错误提示 │ ├── ② isValidUrl(url) 协议白名单校验 → 非法协议直接返回错误提示 │ ├── ③ Jsoup.connect(url).timeout().userAgent().maxBodySize().get() │ ├── ④ document null 判空 → 返回错误提示 │ ├── ⑤ doc.title() / doc.body() 判空 → body 为空返回页面内容为空提示 │ ├── ⑥ body.text() 判空 拼接 title → 截断至 MAX_TEXT_LENGTH 返回 │ └── ⑦ catch Exception → 返回 Error scraping url: e.getMessage() │ └── private boolean isValidUrl(String url) // 协议白名单http/https **判空清单对应约束2** | 判空点 | 不判空的后果 | |--------|------------| | url 空/非法 | 白白发起请求、IllegalArgumentException | | Document null | NPE | | doc.title() null | 拼接出 null 脏数据 | | doc.body() null | .text() 直接 NPE部分页面无 body 标签 | | body.text() 空串 | 返回无意义空内容LLM 误判 | ## 三、风险点 | 风险 | 影响 | 应对 | |------|------|------| | JS 动态渲染页面SPA | jsoup 不执行 JS只拿到静态 HTML | 接受限制返回已抓取内容不引入浏览器内核 | | 反爬 403 / 验证码页 | 抓取失败 | 设置浏览器 UAHttpStatusException 单独捕获返回明确状态码提示 | | 超大页面 | OOM / token 爆炸 | maxBodySize(2MB) 下载层限流 MAX_TEXT_LENGTH 返回层截断 | | 请求挂起 | 阻塞工具调用链 | timeout(10s) | | 二进制内容图片/PDF 链接 | 解析出乱码 | jsoup 默认对非 HTML 抛 UnsupportedMimeTypeException单独捕获返回提示 | | SSRFLLM 被诱导传内网地址 | 探测内网 | 本期做协议白名单内网 IP 黑名单列入后续增强 | | 编码乱码 | 中文乱码 | jsoup 根据响应头/meta 自动识别 charset | | 恶意 HTML 注入 | jsoup 仅解析不执行脚本且返回纯文本 | 风险低body().text() 天然剥离标签 | ## 四、交付物清单 1. pom.xml 新增 jsoup 1.23.1 依赖 2. src/main/java/com/jingdong/ai_super_love_agent/tools/WebScrapingTool.java 3. src/test/java/com/jingdong/ai_super_love_agent/tools/WebScrapingToolTest.java仅基本功能校验类用例不发真实网络请求 ## 五、参数默认值已确认 | 参数 | 值 | |------|-----| | 超时 | 10s | | 下载体积上限 | 2MB | | 返回文本截断长度 | 5000 字符 |然后claude 直接经过我同意存储技术方案.md后,直接开始写代码了,虽然一次过了但是这是不可控的点。故需优化提示词:在1中的提示词末尾应该说明: 经过我同意存储技术方案后,必须再次询问我是否允许你开始写代码我同意你才可以继续。另外,在测试中也有踩坑点,在写完功能开发代码后顺手将单元测试代码补全了,且没有事先生成单元测试技术方案,不太严谨。最后,写完单元测试没有在类上使用SpringbootTest注解且没有使用Resource注入网页抓取工具类,直接new对象,这个我们需要在单元测试提示词中增加对应约束,保证我们代码规范的统一。故关于单元测试的提示词修复如下:在1 生成技术方案 中的提示词中: 移除关于单元测试的要求。 在后续的单元测试约束中添加 1. 类上均使用SpringbootTest注解 2. 测试的工具类都要使用Resource进行依赖注入禁止手动new 工具类由此可见我们踩的坑都可以作为下次的约束条件,我们的约束条件也是不断更新并且增加的,有助于减少模型的不确定性。4. 修复后整体的生成技术方案的提示词(暂时包含单元测试):角色SpringBoot Java后端AI Agent工具开发。 项目AI Agent工具调用服务Bean交给Spring管理禁止手动new带注解的Bean。 需求开发网页抓取工具调用写在包名tools下,工具类命名为WebScrapingTool。使用jsoup库实现网页抓取功能。 约束 1.工具类加Component禁止手动new 2.必须进行入参校验以及各种返回值的判空校验防止发起网页请求资源浪费以及NPE异常报错。 3. 若有需要,做好超时、重试逻辑兜底、异常处理 4. 生产环境下需要的log日志进行必要的填充,便于定位错误,使用Slf4j注解。 单元测试约束 1. 类上均使用SpringbootTest注解 2. 测试的工具类都要使用Resource进行依赖注入禁止手动new 工具类 参考WebSearchTool 输出先输出技术方案需求拆解类设计、风险点不要直接写完整代码。 技术方案存储位置: src/main/resources/ToolCalling设计方案。必须我同意后才可以存储到指定位置。 注意: 经过我同意存储技术方案后,必须再次询问我是否允许你开始写代码我同意你才可以继续。场景三、历史踩坑点全部沉淀到提示词约束条件中(不断扩充)注意!这个是我们实际开发中踩的坑的历史积累,有助于让我们开发变得越来越精准明确,符合我们项目架构和代码风格,我们应把历史踩坑点全部填入约束条件中,等到实际使用时再有选择的提取部分约束条件贴合我们的实际需求。1. 生成开发新需求的技术方案的约束条件(不断更新)约束: // 通用约束 1. 必须进行入参校验以及各种返回值的判空校验防止发起网页请求资源浪费以及NPE异常报错。判空使用hutool工具类中的Util工具如CollectionUtilhutool没有则尝试springframework中的工具类。 2. 若有需要,做好超时、重试逻辑兜底、异常处理 3. 生产环境下需要的log日志进行必要的填充,便于定位错误,使用Slf4j注解。 4. 添加必要的注释便于其他人理解代码中关键步骤也要进行注释说明分清楚步骤如① 入参校验 ② 构建进程等 5. 禁止输出任何与单元测试相关的内容单元测试后续单独处理 6. 要求做最小化读取只定位并阅读我点名的参考类 WebSearchTool以及查看 src/main/resources/ToolCalling设计方案 目录下已有的方案文档格式这是为了后续方案能对齐风格不涉及全盘扫描 // 具体的实际项目约束 1. 具体需求实现的固定规范,如: 工具类加Component禁止手动new // 项目规范 1. 当前类中的辅助方法必须用 // helper methods 与主逻辑方法进行隔离。
