利用 AI 提示词快速定位程序异常堆栈

2.2 错误定位的核心痛点（Prompt 需解决的问题）

开发者在手动定位错误时，常面临以下问题，而这些正是 Prompt 设计需针对性解决的目标：

2.3 错误定位 Prompt 的核心目标

一个高质量的错误定位 Prompt，需实现以下 3 个核心目标，确保模型输出具备实用性、精准性、可操作性：

1. 信息提取：从混乱的堆栈日志中，自动提取异常类型、错误位置、关键调用链路；
2. 根因推测：结合代码上下文（如函数功能、输入数据），推测 2-3 个最可能的错误根因（避免泛泛而谈）；
3. 行动指南：给出 step-by-step 的排查步骤，甚至生成调试代码片段（如打印关键变量、添加日志）。

三、错误定位 Prompt 的设计框架：从基础到进阶

错误定位 Prompt 的设计需遵循'信息引导 + 约束输出 + 场景补充'的逻辑，根据开发者的经验水平（新手/资深）、错误场景（单体/微服务），分为'基础模板'和'进阶模板'两类。

3.1 基础模板：面向新手，覆盖单一语言/单体应用

基础模板适用于单体应用、单一语言（如 Python/Java）、无复杂上下文的错误场景，核心是'降低输入门槛'——开发者只需粘贴堆栈日志，模型即可输出结构化的定位建议。

基础模板结构（通用版）

# 角色与任务
你是一位资深软件开发调试助手，擅长 [指定语言，如 Python/Java/JavaScript] 的错误定位。请基于我提供的异常堆栈日志，完成以下任务：

# 输入信息
异常堆栈日志：
[此处粘贴完整的异常堆栈日志]

# 输出要求（严格按以下结构输出，不要遗漏）
1. 异常核心信息提取：
   - 异常类型：[如 IndexError/NullPointerException]
   - 错误消息：[复制堆栈中的错误描述]
   - 错误位置：文件路径：[如 user_manage.py]，行号：[如 25]
   - 关键调用链路（仅保留业务代码，过滤框架底层代码）：[按'文件行号→函数名'格式列出，如：main.py 第 18 行→get_user_info → user_manage.py 第 25 行→return users[index]]
2. 可能的错误根因（列出 2-3 个最可能的原因，结合代码逻辑推测）：
   - 根因 1：[如'传入的 index=5 超过列表 users 的长度（假设 users 仅包含 3 个元素），导致索引越界']
   - 根因 2：[如'函数 get_user_info 未对输入的 index 进行合法性校验（如未判断 index 是否小于 len(users)）']
   - 根因 3：[如'列表 users 初始化时数据缺失，实际长度为 0，导致任何 index 都越界']
3. 排查步骤（step-by-step，从简单到复杂）：
   Step 1：[如'打开错误位置文件 user_manage.py 第 25 行，查看 users 列表的定义与赋值逻辑，确认 users 的实际长度']
   Step 2：[如'检查调用 get_user_info 函数的位置（main.py 第 18 行），确认传入的 index 值是否合理（如是否大于等于 0 且小于 len(users)）']
   Step 3：[如'在 get_user_info 函数中添加日志，打印调用时的 index 值和 users 列表内容，重新运行程序验证根因']
4. 调试代码片段（可选，若适用）：
   [生成可直接插入的调试代码，如打印变量、添加校验逻辑]

基础模板实战案例（Python 索引越界错误）

开发者输入（堆栈日志）

Traceback (most recent call last):
  File "user_manage.py", line 25, in get_user_info
    return users[index]
  File "main.py", line 18, in <module>
    user = get_user_info(5)
IndexError: list index out of range

模型输出（基于基础模板）

1. 异常核心信息提取：
   • 异常类型：IndexError（列表索引越界）
   • 错误消息：list index out of range
   • 错误位置：文件路径：user_manage.py，行号：25
   • 关键调用链路（仅保留业务代码）：main.py 第 18 行→get_user_info → user_manage.py 第 25 行→return users[index]
2. 可能的错误根因：
   • 根因 1：传入的 index=5 超过列表 users 的实际长度（推测 users 列表长度≤4，如仅存储了 4 个用户数据），导致索引越界。
   • 根因 2：函数 get_user_info 未对输入参数 index 进行合法性校验（如未判断 index 是否在 [0, len(users)-1] 范围内），直接使用参数访问列表。
   • 根因 3：列表 users 在初始化时未成功加载数据（如从数据库查询用户失败，返回空列表），此时任何 index 都会触发越界错误。
3. 排查步骤： Step 1：打开 user_manage.py 文件，定位第 25 行，查看 users 列表的定义位置（如是否在函数内初始化，或从其他函数/文件传入），打印 len(users) 确认列表实际长度。 Step 2：跳转至 main.py 第 18 行，检查调用 get_user_info 时传入的 index=5 是否合理（如是否应为动态获取的用户 ID，而非固定值 5；是否存在计算错误，如 index=user_id-1 但 user_id=6 时导致 index=5）。 Step 3：在 get_user_info 函数开头添加调试日志：print(f"当前 index: {index}, users 列表长度：{len(users)}, users 内容：{users}")，重新运行程序，观察日志输出确认根因。
4. 调试代码片段：

# 优化后的 get_user_info 函数（添加参数校验与调试日志）
def get_user_info(index):
    # 调试日志：打印关键变量
    print(f"调试信息 - index: {index}, users 长度：{len(users)}, users: {users}")
    # 参数合法性校验
    if not isinstance(index, int):
        raise TypeError("index 必须为整数")
    if index < 0 or index >= len(users):
        raise ValueError(f"index 超出有效范围，当前 users 列表长度为{len(users)}，有效 index 范围：0~{len(users)-1}")
    return users[index]

3.2 进阶模板：面向资深开发者，覆盖跨服务/复杂场景

进阶模板适用于微服务、分布式应用、多语言混合架构的复杂错误场景，核心是'补充上下文信息'——要求开发者提供更多维度的输入（如调用链路、配置参数、输入数据），引导模型进行'关联分析'，定位跨服务或非代码层面的根因（如配置错误、数据库连接失败）。

进阶模板结构（微服务版）

# 角色与任务
你是一位微服务架构调试专家，擅长分析跨服务调用中的错误根因，熟悉 [指定技术栈，如 Spring Cloud/Dubbo + MySQL + Redis]。请基于我提供的'异常堆栈 + 调用链路 + 上下文信息'，完成深度错误定位。

# 输入信息（请开发者按以下格式补充，缺一不可）
1. 异常堆栈日志（当前服务的完整堆栈）：
[此处粘贴当前服务的异常堆栈]
2. 跨服务调用链路（如 APM 工具记录的链路，格式：调用方服务→被调用方服务→接口名）：
[如：用户服务（user-service）→ 订单服务（order-service）→ /api/order/create（POST）]
3. 上下文补充：
   - 输入数据（当前接口的请求参数，脱敏处理）：[如：{"userId": "12345", "productId": "P001", "quantity": -1}]
   - 相关配置（如数据库连接、Redis 地址、第三方接口地址）：[如：MySQL 地址：jdbc:mysql://192.168.1.100:3306/order_db；Redis 地址：192.168.1.101:6379]
   - 异常发生时间与频率：[如：2024-05-20 14:30 首次发生，之后每 10 分钟触发一次；仅当 quantity 为负数时触发]

# 输出要求（严格按以下结构，需包含跨服务排查点）
1. 异常核心信息提取（含跨服务关联）：
   - 异常类型与错误消息：[如 SQLIntegrityConstraintViolationException: Column 'quantity' cannot be null]
   - 错误位置（当前服务）：文件：[如 OrderController.java]，行号：[如 48]，方法：[如 createOrder]
   - 跨服务调用链路梳理：[按'服务→接口→参数传递'格式，标注可能的异常传递点，如：user-service→order-service:/api/order/create（传递参数 quantity=-1）→ order-service 调用 MySQL 插入订单（quantity 字段不允许负数）]
2. 多维度根因分析（分'代码层''配置层''依赖层'）：
   - 代码层根因：[如'order-service 的 OrderController 未对 quantity 参数进行合法性校验（允许负数），导致插入 MySQL 时触发字段约束错误']
   - 配置层根因（可选）：[如'MySQL 的 order 表中 quantity 字段未设置默认值，且未显式标注 NOT NULL，但业务逻辑要求该字段必须为正数，配置与业务不匹配']
   - 依赖层根因（可选）：[如'user-service 在调用 order-service 时，未过滤非法的 quantity 值（如用户前端传入负数时未拦截），导致错误向下传递']
3. 跨服务排查步骤（按'当前服务→上游服务→依赖服务'顺序）：
   Step 1：排查当前服务（order-service）：
      - 打开 OrderController.java 第 48 行，查看 createOrder 方法是否对 quantity 参数进行校验（如是否判断 quantity > 0）；
      - 检查 OrderMapper.xml 中插入订单的 SQL 语句，确认 quantity 字段是否有约束（如 CHECK(quantity > 0)）。
   Step 2：排查上游服务（user-service）：
      - 找到 user-service 调用 order-service 的代码（如 OrderFeignClient.java），查看是否有参数校验逻辑（如是否过滤 quantity ≤ 0 的请求）；
      - 查看 user-service 的前端接口（如/user/createOrder）是否有前端校验（如禁止输入负数），是否存在前端校验被绕过的情况（如直接调用 API）。
   Step 3：排查依赖服务（MySQL）：
      - 登录 MySQL 的 order_db 数据库，执行 `DESC order;` 查看 quantity 字段的约束（如是否为 INT NOT NULL，是否有 CHECK 约束）；
      - 执行 `SELECT * FROM order WHERE quantity < 0;` 确认是否存在历史非法数据，判断是否为偶发还是批量问题。
4. 解决方案与优化建议（含跨服务协同）：
   - 短期修复：[如'在 order-service 的 createOrder 方法中添加 quantity 参数校验（quantity > 0），抛出 IllegalArgumentException 并返回 400 错误；在 user-service 的 Feign 调用前补充相同校验，双重拦截非法参数']
   - 长期优化：[如'使用 Spring Cloud Gateway 统一拦截所有请求，添加通用参数校验规则；在 MySQL 表中为 quantity 字段添加 CHECK(quantity > 0) 约束，从数据库层兜底；接入 APM 工具（如 SkyWalking），设置异常告警触发阈值']

进阶模板实战案例（微服务订单创建错误）

开发者输入（完整上下文）

1. 异常堆栈日志（order-service）：

org.springframework.dao.DataIntegrityViolationException: ### Error updating database. Cause: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Check constraint 'order_quantity_check' violated for table 'order'
### The error may exist in com/order/mapper/OrderMapper.xml
### The error may involve com.order.mapper.OrderMapper.insert-Inline
### The error occurred while setting parameters
### SQL: INSERT INTO order (user_id, product_id, quantity, create_time) VALUES (?, ?, ?, ?)
### Cause: com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Check constraint 'order_quantity_check' violated for table 'order'; SQL []; Data truncation: Check constraint 'order_quantity_check' violated for table 'order'; nested exception is com.mysql.cj.jdbc.exceptions.MysqlDataTruncation: Data truncation: Check constraint 'order_quantity_check' violated for table 'order'
at org.springframework.jdbc.support.SQLStateSQLExceptionTranslator.doTranslate(SQLStateSQLExceptionTranslator.java:104)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:70)
at org.springframework.jdbc.support.AbstractFallbackSQLExceptionTranslator.translate(AbstractFallbackSQLExceptionTranslator.java:79)
at org.mybatis.spring.MyBatisExceptionTranslator.translateExceptionIfPossible(MyBatisExceptionTranslator.java:91)
at org.mybatis.spring.SqlSessionTemplate$SqlSessionInterceptor.invoke(SqlSessionTemplate.java:441)
at jdk.proxy2/jdk.proxy2.$Proxy85.insert(Unknown Source)
at org.mybatis.spring.SqlSessionTemplate.insert(SqlSessionTemplate.java:272)
at com.order.service.impl.OrderServiceImpl.createOrder(OrderServiceImpl.java:65) # 错误位置
at com.order.controller.OrderController.createOrder(OrderController.java:48)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)...（框架代码省略）

2. 跨服务调用链路： user-service（用户服务）→ order-service（订单服务）→ /api/order/create（POST 接口）
3. 上下文补充：
   • 输入数据：{"userId": "12345", "productId": "P001", "quantity": -2, "createTime": "2024-05-20 14:30:00"}
   • 相关配置：MySQL 地址：jdbc:mysql://192.168.1.100:3306/order_db；order 表的 quantity 字段约束：quantity INT NOT NULL CHECK (quantity > 0)
   • 异常发生时间与频率：2024-05-20 14:30 首次发生，截至 15:00 共触发 5 次，均为 quantity 为负数的请求。

模型输出（基于进阶模板）

1. 异常核心信息提取（含跨服务关联）：
   • 异常类型与错误消息：DataIntegrityViolationException（数据完整性约束异常），根因：MySQL 的 order_quantity_check 约束被违反（quantity 字段需>0）
   • 错误位置（当前服务）：文件：OrderServiceImpl.java，行号：65，方法：createOrder；Controller 层位置：OrderController.java 第 48 行，方法：createOrder
   • 跨服务调用链路梳理：user-service→order-service:/api/order/create（传递参数 quantity=-2）→ order-service 的 OrderServiceImpl 第 65 行调用 MyBatis 插入订单→ MySQL 执行 INSERT 语句时触发 CHECK 约束（quantity>0），抛出异常。
2. 多维度根因分析：
   • 代码层根因：order-service 的 OrderController 和 OrderServiceImpl 均未对 quantity 参数进行合法性校验（未判断 quantity>0），直接将负数参数传递至 MyBatis，触发 MySQL 约束错误；同时，user-service 在调用 order-service 前也未拦截 quantity=-2 的非法参数，导致错误向下传递。
   • 配置层根因：MySQL 的 order 表虽设置了 CHECK(quantity>0) 约束，但该约束属于'兜底措施'，未在应用层（order-service/user-service）提前拦截，导致异常需通过数据库层抛出，增加排查链路长度。
   • 依赖层根因：前端页面（用户服务的下单页面）可能未添加 quantity 的输入校验（如禁止输入负数），或校验被绕过（如用户通过 Postman 直接调用 user-service 的接口传入负数），导致非法参数进入服务链路。
3. 跨服务排查步骤： Step 1：排查当前服务（order-service）： - 打开 OrderController.java 第 48 行，查看 createOrder 方法的参数接收逻辑，确认是否使用 JSR-380 校验注解（如@Min(1)）对 quantity 进行校验； - 打开 OrderServiceImpl.java 第 65 行，查看是否在调用 mapper.insert 前对 quantity 进行业务校验（如 if (quantity <= 0) throw new IllegalArgumentException("订单数量必须为正数")）； - 检查 OrderMapper.xml 中的 INSERT 语句，确认是否有额外的参数过滤逻辑（如 quantity = IF(#{quantity} > 0, #{quantity}, NULL)，但 NULL 会触发 NOT NULL 约束，非最优解）。 Step 2：排查上游服务（user-service）： - 找到 user-service 中调用 order-service 的 Feign 客户端（如 OrderFeignClient.java），查看调用 createOrder 接口时是否有参数校验（如 Assert.isTrue(quantity > 0, "订单数量不能为负数")）； - 查看 user-service 的前端接口（如/UserOrderController 的 createOrder 方法），确认是否添加@Min(1) 注解或手动校验，判断是否存在前端校验缺失导致非法参数传入。 Step 3：排查依赖服务（MySQL 与前端）： - 登录 192.168.1.100 的 order_db 数据库，执行 SELECT * FROM order WHERE quantity <= 0;，确认是否存在历史非法数据（若有，需排查之前的校验漏洞）； - 访问 user-service 的下单页面，尝试输入 quantity=-2 并提交，观察是否有前端提示（如'数量必须大于 0'），判断是否存在前端校验被绕过的情况（如直接调用 API）。
4. 解决方案与优化建议（含跨服务协同）：
   • 短期修复：
     1. 在 order-service 的 OrderController.createOrder 方法的 quantity 参数上添加 @Min(value = 1, message = "订单数量必须为正数（≥1）")，并在全局异常处理器中捕获 MethodArgumentNotValidException，返回 400 错误与提示信息；
     2. 在 user-service 的 Feign 调用前添加参数校验：if (quantity <= 0) throw new BadRequestException("订单数量不能为负数");，双重拦截非法参数；
     3. 临时屏蔽 quantity=-2 的请求：在 Spring Cloud Gateway 中添加路由过滤器，拦截所有 quantity≤0 的/create 请求，直接返回 400 错误。
   • 长期优化：
     1. 统一校验标准：在微服务架构中引入'公共校验组件'，定义 quantity、userId 等通用参数的校验规则（如 quantity≥1、userId 不为空），所有服务依赖该组件，避免重复开发；
     2. 数据库层强化：为 order 表的 quantity 字段添加更明确的错误提示，如 CHECK (quantity > 0) COMMENT '订单数量必须为正数'，便于快速识别约束含义；
     3. 监控与告警：在 APM 工具（如 SkyWalking）中为 DataIntegrityViolationException 设置告警规则（如 10 分钟内触发 3 次则发送邮件/钉钉告警），并关联调用链路信息，便于快速定位；
     4. 前端与后端双重校验：要求所有输入参数在前端（如 Vue/React）和后端（服务层）均进行校验，前端拦截常规错误，后端兜底异常，形成'双重保障'。

四、不同语言/场景的错误定位 Prompt 适配技巧

不同编程语言的异常堆栈格式、错误类型命名存在差异（如 Java 的 NullPointerException vs Python 的 AttributeError），不同场景（如前端 JS 错误、后端数据库错误）的排查重点也不同。需根据具体场景调整 Prompt 的'语言特性'与'输出侧重点'。

4.1 多语言适配：Java、Python、JavaScript 差异调整

1. Java 场景：突出'异常链'与'框架层级过滤'

Java 堆栈常包含大量框架代码（如 Spring、MyBatis），Prompt 需明确'过滤框架无关调用'，同时关注'异常链'（如 DataIntegrityViolationException 的根因是 MysqlDataTruncation）。

Java 专属 Prompt 片段：

# 语言特性适配
- 请识别异常链中的'根异常'（如被 cause 包裹的 MysqlDataTruncation、NullPointerException），优先基于根异常分析根因；
- 过滤框架底层代码调用（如 org.springframework.*、org.mybatis.*、java.base.*包下的调用），仅保留业务代码（如 com.xxx.service、com.xxx.controller 包下的调用）；
- 若涉及 Spring Boot 框架，请额外分析是否为'配置错误'（如 application.yml 中的数据库连接地址错误）或'依赖冲突'（如 jar 包版本不兼容）。

2. Python 场景：关注'模块导入'与'第三方库错误'

Python 错误常涉及模块导入（如 ModuleNotFoundError）、第三方库使用（如 pandas 的 KeyError），Prompt 需引导模型分析'依赖安装'与'库版本兼容性'。

Python 专属 Prompt 片段：

# 语言特性适配
- 若异常类型为 ModuleNotFoundError，请优先分析'是否已安装该模块'（如 `pip list | grep 模块名`）及'Python 环境是否正确'（如虚拟环境未激活）；
- 若涉及第三方库（如 pandas、requests），请推测是否为'库版本不兼容'（如 pandas 1.0 与 2.0 的 API 差异），并建议查看库的官方文档确认用法；
- 若为装饰器、生成器相关错误（如 StopIteration），请结合 Python 语法特性分析（如生成器未正确 yield 值）。

3. JavaScript（前端/Node.js）场景：区分'语法错误'与'运行时错误'

JS 错误分为语法错误（如 SyntaxError: Unexpected token '{'）和运行时错误（如 TypeError: Cannot read property 'name' of undefined），前端场景还需关注'DOM 操作''异步请求'（如 Axios 404 错误）。

JavaScript 专属 Prompt 片段：

# 语言特性适配（区分前端/Node.js）
- 若为前端场景（含浏览器控制台错误）：
  1. 若涉及 DOM 操作（如 document.getElementById），请分析'DOM 元素是否存在'（如元素未加载完成就执行操作，需添加 DOMContentLoaded 事件监听）；
  2. 若为异步请求错误（如 AxiosError），请分析'请求 URL 是否正确''跨域配置是否缺失''响应状态码含义'（如 401 未授权、404 接口不存在）。
- 若为 Node.js 场景：
  1. 若涉及文件操作（如 fs.readFile），请分析'文件路径是否正确'（相对路径 vs 绝对路径）、'文件权限是否足够'；
  2. 若为 EventEmitter 相关错误（如'error'事件未监听），请建议添加 `emitter.on('error', (err) => console.error(err))` 避免程序崩溃。

4.2 特殊场景适配：数据库错误、分布式链路错误

1. 数据库错误场景（MySQL、PostgreSQL、MongoDB）

数据库错误的根因常涉及'SQL 语法''字段约束''连接配置'，Prompt 需引导模型分析 SQL 语句与数据库配置的匹配性。

数据库错误专属 Prompt 片段：

# 数据库场景适配
- 若为 SQL 语法错误（如 SQLSyntaxError）：
  1. 请检查 SQL 语句的'关键字拼写'（如 SELECT 写成 SELEC）、'括号/引号配对'（如字符串未闭合）、'表名/字段名大小写'（如 MySQL 默认不区分大小写，但 Linux 环境下可能区分）；
  2. 若使用 ORM 框架（如 MyBatis、Hibernate），请分析 XML 映射文件中的 SQL 是否存在语法错误（如#{参数名}是否正确，是否多写逗号）。
- 若为连接错误（如 SQLTransientConnectionException）：
  1. 请检查数据库'连接地址、端口、用户名、密码'是否正确（如 application.yml 中的配置）；
  2. 分析'数据库是否启动''网络是否可达'（如 ping 数据库 IP、telnet 端口）、'连接池配置是否合理'（如最大连接数不足导致连接超时）。
- 若为 NoSQL 数据库（如 MongoDB）：
  1. 若为 Bson 语法错误，请检查查询条件是否符合 MongoDB 语法（如使用$gt 而非>）；
  2. 若为集合不存在错误，请分析'是否未创建集合'或'集合名拼写错误'。

2. 分布式链路错误场景（微服务、分布式事务）

分布式错误的根因常涉及'服务间通信''分布式事务一致性''服务可用性'，Prompt 需引导模型分析'上游服务状态''网络链路''事务回滚情况'。

分布式链路专属 Prompt 片段：

# 分布式场景适配
- 请结合 APM 调用链路（如 SkyWalking、Zipkin）分析以下点：
  1. 上游服务是否正常返回（如 user-service 是否返回 200，是否存在超时）；
  2. 服务间通信协议是否存在问题（如 Dubbo 调用的序列化方式不兼容，HTTP 调用的 Content-Type 不匹配）；
  3. 分布式事务是否触发回滚（如 Seata 事务未提交，导致数据不一致）。
- 若涉及消息队列（如 RabbitMQ、Kafka）：
  1. 分析'消息是否成功发送''消费者是否正常消费'（如队列堆积、消费者抛出异常导致消息重发）；
  2. 检查'消息序列化/反序列化是否正确'（如 JSON 格式错误，导致消费者无法解析）。

五、错误定位 Prompt 的输出优化：避免泛泛而谈，提升实用性

即使使用上述模板，模型仍可能输出'泛泛而谈'的建议（如'检查代码是否有错误'）。需通过'约束输出细节''添加负面清单''示例引导'三个技巧，提升输出的精准性与可操作性。

5.1 技巧 1：约束输出细节——要求'具体到文件/行号/代码片段'

在 Prompt 的输出要求中，明确'禁止模糊表述'，强制模型结合输入的堆栈信息，输出具体的文件路径、行号，甚至推测可能的代码片段。

反例（泛泛而谈）： '请检查 quantity 参数的校验逻辑，确保其为正数。'

正例（具体细节）： '请检查 order-service 的 OrderController.java 第 48 行，确认是否在 createOrder 方法的 quantity 参数上添加了@Min(1) 注解；若未添加，请补充该注解，并在全局异常处理器中捕获 MethodArgumentNotValidException，返回'订单数量必须为正数'的提示。'

Prompt 约束语句：

# 输出细节约束
- 所有排查步骤必须'具体到文件路径、行号、方法名'，禁止使用'某个文件''某段代码'等模糊表述；
- 根因分析需结合输入的'异常堆栈 + 上下文信息'，禁止输出与当前场景无关的通用建议（如'检查代码是否有语法错误'）；
- 调试代码片段需可直接运行（如包含完整的函数定义、导入语句），并标注'需替换的变量'（如 `[请替换为实际的数据库连接池配置]`）。

5.2 技巧 2：添加负面清单——明确'禁止输出的内容'

提前在 Prompt 中列出'禁止输出的内容'，避免模型输出无用信息（如基础语法讲解、与场景无关的知识点），聚焦错误定位本身。

负面清单示例：

# 输出负面清单（禁止包含以下内容）
1. 禁止讲解基础编程语言语法（如'Java 的 try-catch 语句用法''Python 的列表定义方式'）；
2. 禁止输出与当前错误无关的通用开发规范（如'代码缩进应使用 4 个空格''变量命名应使用驼峰式'）；
3. 禁止使用过于学术化的表述（如'该异常属于运行时异常，继承自 RuntimeException'），需用通俗语言解释，并直接关联解决方案；
4. 禁止推荐未经验证的工具或框架（如'建议使用 XXX 调试工具'，除非该工具与当前错误定位直接相关且为行业通用工具）。

5.3 技巧 3：示例引导——给模型'正确输出的参考案例'

若模型对复杂场景的输出仍不理想，可在 Prompt 中添加'正确输出示例'，让模型参考示例的结构与细节程度，生成更符合预期的内容。

示例引导片段（Java 空指针错误）：

# 正确输出示例参考（仅为格式与细节参考，非当前问题答案）
假设输入堆栈为：
java.lang.NullPointerException: Cannot invoke "com.user.entity.User.getName()" because "user" is null
at com.user.service.UserServiceImpl.getUserName(UserServiceImpl.java:32)
at com.user.controller.UserController.getUserName(UserController.java:20)

正确输出参考（根因分析部分）：
- 根因 1：UserServiceImpl.java 第 32 行调用 user.getName() 时，user 对象为 null，推测'获取 user 对象的逻辑存在漏洞'（如从数据库查询 user 时返回 null，未处理该情况）；
- 根因 2：UserController.java 第 20 行调用 UserServiceImpl.getUserName 时，传入的 user 对象为 null（如前端未传递 user_id，导致查询不到 user）。

请参考上述示例的细节程度，分析当前问题的根因，确保每个根因都关联具体的文件、行号与代码逻辑。

六、章节总结与课后练习

6.1 章节总结

本章系统讲解了错误定位 Prompt 的设计与应用，核心要点可归纳为：

1. 基础认知：异常堆栈是错误定位的核心证据，需提取'异常类型、错误位置、调用链路'三大信息；
2. 模板设计：基础模板面向单体应用/新手，侧重'结构化输出'；进阶模板面向微服务/资深开发者，侧重'跨服务关联分析'；
3. 场景适配：根据语言（Java/Python/JS）、场景（数据库/分布式）调整 Prompt 的'语言特性'与'排查重点'；
4. 输出优化：通过'约束细节、负面清单、示例引导'，避免模型输出泛泛而谈，提升建议的可操作性。

掌握错误定位 Prompt 的设计技巧，能让开发者将大语言模型转化为'专属调试助手'，大幅减少排查错误的时间，尤其在面对陌生项目或复杂架构时，效果更为显著。

6.2 课后练习

练习 1：Python 字典键不存在错误（基础场景）

任务：基于以下异常堆栈，使用'基础模板'设计 Prompt，并生成模型输出（需包含异常提取、根因分析、排查步骤、调试代码）。

输入堆栈日志：

Traceback (most recent call last):
  File "product_manage.py", line 38, in get_product_price
    return product["price"] # 尝试获取字典中不存在的"price"键
  File "main.py", line 22, in <module>
    price = get_product_price({"id": "P001", "name": "手机"})
KeyError: 'price'

练习 2：Java 微服务数据库连接错误（进阶场景）

任务：基于以下上下文信息，使用'进阶模板'设计 Prompt，并生成模型输出（需包含跨服务排查、多维度根因分析）。

输入信息：

1. 异常堆栈日志（product-service）：

org.springframework.jdbc.CannotGetJdbcConnectionException: Failed to obtain JDBC Connection; nested exception is com.mysql.cj.jdbc.exceptions.CommunicationsException: Communications link failure
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:83)
at org.mybatis.spring.transaction.SpringManagedTransaction.openConnection(SpringManagedTransaction.java:80)
at org.mybatis.spring.transaction.SpringManagedTransaction.getConnection(SpringManagedTransaction.java:67)
at com.product.service.impl.ProductServiceImpl.getProductById(ProductServiceImpl.java:42) # 错误位置
...（框架代码省略）

2. 跨服务调用链路： api-gateway（网关）→ product-service（商品服务）→ /api/product/getById（GET 接口，参数 id=P001）
3. 上下文补充：
   • 输入数据：请求 URL：http://localhost:8080/api/product/getById?id=P001，请求方法：GET；
   • 相关配置：product-service 的 application.yml 中数据库配置：spring.datasource.url: jdbc:mysql://192.168.1.200:3306/product_db?useSSL=false，用户名：root，密码：123456；
   • 异常发生情况：所有调用 product-service 的请求均触发该错误，重启服务后仍无法解决；其他服务（如 user-service）可正常连接 MySQL（地址：192.168.1.100:3306）。

练习 3：前端 JavaScript 异步请求错误（场景适配）

任务：基于以下前端错误信息，设计'JavaScript 前端专属 Prompt'，并生成模型输出（需包含 DOM 操作、异步请求排查）。

输入信息：

1. 浏览器控制台错误：

Uncaught (in promise) AxiosError: Request failed with status code 404
at settle (axios.min.js:1:14975)
at XMLHttpRequest.onloadend (axios.min.js:1:13512)
at getProductDetail (productDetail.js:15) # 错误位置
at HTMLButtonElement.onclick (productDetail.html:28) # 触发事件

2. 上下文补充：
   • 操作步骤：用户在 productDetail.html 页面点击'查看商品详情'按钮（id="getDetailBtn"），触发 onclick 事件调用 getProductDetail 函数；
   • 后端服务信息：后端商品服务的正确接口地址为 /api/product/getDetail（非 /api/product/detail），服务已启动，端口 8080。

相关代码（productDetail.js 第 15 行）：

async function getProductDetail(){
    const productId = document.getElementById("productId").value;
    const response = await axios.get("/api/product/detail", {
        params: { id: productId }
    }); // 第 15 行
    console.log(response.data);
}

6.3 练习参考答案（思路点拨）

练习 1 参考答案思路

1. 异常核心信息提取：
   • 异常类型：KeyError（字典键不存在）；
   • 错误位置：product_manage.py 第 38 行，get_product_price 函数；
   • 关键调用链路：main.py 第 22 行→get_product_price（传入字典{"id":"P001","name":"手机"}）→ product_manage.py 第 38 行→return product["price"]。
2. 根因分析：
   • 根因 1：传入的 product 字典仅包含"id"和"name"键，无"price"键，导致获取时抛出 KeyError；
   • 根因 2：get_product_price 函数未判断"price"键是否存在（如未使用 product.get("price") 或"price" in product），直接访问键。
3. 排查步骤：
   • Step 1：检查 main.py 第 22 行，确认传入的 product 字典是否应包含"price"键（如是否遗漏从数据库查询 price 字段）；
   • Step 2：在 product_manage.py 第 38 行前添加键存在性判断，如 if "price" not in product: raise KeyError("product 字典缺少'price'键")。
4. 调试代码：

def get_product_price(product):
    # 检查键是否存在
    if not isinstance(product, dict):
        raise TypeError("product 必须为字典类型")
    if "price" not in product:
        raise KeyError(f"product 字典缺少'price'键，当前键列表：{list(product.keys())}")
    return product["price"]
# 调用时补充 price 键
price = get_product_price({"id":"P001","name":"手机","price":3999})

练习 2 参考答案思路

1. 异常核心信息提取：
   • 异常类型：CannotGetJdbcConnectionException（无法获取 JDBC 连接），根因：CommunicationsException（通信链路失败）；
   • 跨服务链路：api-gateway→product-service:/api/product/getById→ product-service 连接 MySQL（192.168.1.200:3306）失败。
2. 多维度根因分析：
   • 代码层根因：无（连接错误非代码逻辑问题）；
   • 配置层根因：product-service 的 MySQL 地址配置错误（192.168.1.200:3306），而其他服务（如 user-service）使用 192.168.1.100:3306 可正常连接，推测地址写错；
   • 依赖层根因：192.168.1.200 的 MySQL 未启动、端口被占用，或网络防火墙禁止 product-service 访问该地址。
3. 排查步骤：
   • Step 1：检查 product-service 的 application.yml，确认 MySQL 地址是否应为 192.168.1.100:3306（与 user-service 一致）；
   • Step 2：在 product-service 服务器上执行 ping 192.168.1.200 和 telnet 192.168.1.200 3306，确认网络是否可达；
   • Step 3：登录 192.168.1.200 服务器，执行 systemctl status mysqld 确认 MySQL 是否启动，若未启动则执行 systemctl start mysqld。
4. 解决方案：
   • 修改 application.yml 的 MySQL 地址为 jdbc:mysql://192.168.1.100:3306/product_db?useSSL=false，重启 product-service；
   • 在生产环境中，将数据库地址配置为配置中心（如 Nacos）的动态配置，避免硬编码错误。

练习 3 参考答案思路

1. 异常核心信息提取：
   • 异常类型：AxiosError（404 Not Found）；
   • 错误位置：productDetail.js 第 15 行，getProductDetail 函数（Axios GET 请求）；
   • 触发链路：productDetail.html 第 28 行（按钮 onclick 事件）→ getProductDetail → 调用 Axios 请求 /api/product/detail→ 404 错误。
2. 根因分析：
   • 根因 1：Axios 请求的接口地址错误（/api/product/detail），后端正确地址为 /api/product/getDetail，导致 404；
   • 根因 2：未处理 Axios 请求的 Promise 异常（如未使用 try-catch 或.catch()），导致'Uncaught (in promise)'错误；
   • 根因 3：未验证 productId 是否为空（如用户未输入 id 直接点击按钮，可能导致后端接口参数缺失，但当前错误核心是地址错误）。
3. 排查步骤：
   • Step 1：打开浏览器'网络'面板（F12），查看 GET 请求的'请求 URL'，确认是否为 http://localhost:8080/api/product/detail?id=xxx，对比后端正确地址；
   • Step 2：修改 productDetail.js 第 15 行的接口地址为 /api/product/getDetail，重新测试；
   • Step 3：在 getProductDetail 函数中添加 try-catch 捕获 Promise 异常，避免控制台报错。
4. 调试代码：

async function getProductDetail(){
    try{
        const productId = document.getElementById("productId").value;
        // 1. 验证 productId 是否为空
        if(!productId){
            alert("请输入商品 ID");
            return;
        }
        // 2. 修正接口地址为正确的/getDetail
        const response = await axios.get("/api/product/getDetail", {
            params: { id: productId }
        });
        console.log(response.data);
    }catch(error){
        // 3. 捕获并处理异常
        if(error.response){
            // 服务器返回错误（如 404、500）
            alert(`请求错误：${error.response.status} - ${error.response.statusText}`);
        }else if(error.request){
            // 无响应（如网络错误）
            alert("网络错误，无法连接服务器");
        }else{
            // 请求发送前的错误（如参数错误）
            alert(`请求失败：${error.message}`);
        }
    }
}
// 优化：使用 addEventListener 绑定事件，而非 HTML onclick（更符合前端最佳实践）
document.getElementById("getDetailBtn").addEventListener("click", getProductDetail);