调试工作流先看清系统,再修复故障
提示词主题

文本 · 通用对话模型

按系统流程定位功能缺陷

引导模型从用户操作到界面更新完整梳理系统链路,精确定位故障分歧点,并提出范围最小、避免过度设计的修复方案。

Prompt

请作为一名资深软件工程师和系统架构师。

## 背景
我是一名正在开发应用功能的开发者。

系统存在一个错误,而之前的修复使系统变得更加复杂。

我需要:
- 清晰理解系统流程
- 找出确切的故障点
- 最小且精准的修复(不要过度工程化)

您必须先解释系统,然后再尝试修复。

---

## 输入

功能:
${describe_feature}

预期行为:
${what_should_happen}

实际问题:
${what_is_happening}

代码:
${paste_relevant_code}

---

## 输出格式(严格)

### 1. 系统流程(可视化 + 逻辑)

#### A. 流程图
提供清晰的逐步流程:

用户操作  
→ UI层  
→ 状态 / 控制器 / 逻辑  
→ 数据处理  
→ 外部系统 / SDK / API(如有)  
→ 响应处理  
→ 渲染 / 输出  
→ UI更新  

---

#### B. 解释每个阶段
对于每一步:
- 发生了什么
- 传递了哪些数据
- 进行了哪些转换
- 存在哪些依赖关系

---

#### C. 关键时间点(重要)
确定:
- 对象/资源何时创建
- 数据何时加载或获取
- 状态何时更新
- 属性/配置何时应该应用

---

### 2. 预期行为
定义正确行为:
- 正常成功流程
- 边界情况
- 失败场景

如果不清楚,请提出最多3个具体问题并停止。

---

### 3. 当前行为
使用以下内容解释实际行为:
- 问题描述
- 代码分析

---

### 4. 不匹配(关键)
确定:
- 行为发生偏离的确切步骤
- 应该发生什么,以及实际发生了什么

---

### 5. 根本原因(精准)
确定确切原因:
- 时序问题(异步、生命周期)
- 引用或数据错误
- 状态未更新
- 逻辑缺陷
- 集成问题

指出:
- 具体函数 / 代码块 / 生命周期阶段

如果不确定,请明确说明假设。

---

### 6. 最小修复(严格)
- 提供尽可能小的改动
- 不要重写架构
- 不要引入不必要的抽象

只提供修改后的代码片段。

重点关注:
- 修复时序
- 正确的数据流
- 正确的状态更新

---

### 7. 修复为何有效
解释:
- 它如何修复确切的故障点
- 与系统流程的关系
- 与生命周期/时序的关系

---

### 8. 风险(重要)
分析:
- 对系统其他部分的影响
- 对性能的影响
- 副作用

---

### 9. 预防(架构指导)
建议:
- 更好的生命周期处理
- 明确的职责分离
- 逻辑应位于何处:
  - UI
  - 控制器 / 状态
  - 数据 / 服务层

---

## 约束
- 不要在未说明假设的情况下假定行为
- 不要随意移动逻辑
- 不要盲目添加条件
- 聚焦于流程、时序和数据

---

## 备用规则
如果输入不足:
- 提出最多3个具体问题
- 停止

---

## 自检(必须)
回答前:
- 我是否将错误映射到了具体流程步骤?
- 我是否识别出时序/生命周期问题?
- 修复是否最小且范围明确?
- 我是否避免了过度工程化?

使用建议

使用建议:填入功能、预期行为、实际问题和相关代码;如果信息不足,允许模型先提出最多三个针对性问题,再继续分析。

信息

类型
文本
模型
通用对话模型
许可
CC0-1.0

反馈这条内容