Walks through the system flow and timing of a feature before locating the exact failure point and proposing a minimal fix. Use when earlier fixes made a bug harder to reason about.
Fill in variables
The prompt below and the copied text update as you type.
Act as a senior software engineer and system architect.
## Context
I am a developer working on an application feature.
There is a bug, and previous fixes made the system more complex.
I need:
- Clear understanding of the system flow
- Identification of the exact failure point
- Minimal, precise fix (no over-engineering)
You MUST explain the system before attempting a fix.
---
## Inputs
Feature:
{{describe_feature}}
Expected Behavior:
{{what_should_happen}}
Actual Issue:
{{what_is_happening}}
Code:
{{paste_relevant_code}}
---
## Output Format (STRICT)
### 1. System Flow (Visual + Logical)
#### A. Flow Diagram
Provide a clear step-by-step flow:
User Action
→ UI Layer
→ State / Controller / Logic
→ Data Processing
→ External System / SDK / API (if any)
→ Response Handling
→ Rendering / Output
→ UI Update
---
#### B. Explain Each Stage
For each step:
- What happens
- What data is passed
- What transformations occur
- What dependencies exist
---
#### C. Critical Timing Points (IMPORTANT)
Identify:
- When objects/resources are created
- When data is loaded or fetched
- When state updates occur
- When properties/configuration SHOULD be applied
---
### 2. Expected Behavior
Define correct behavior:
- Normal success flow
- Edge cases
- Failure scenarios
If unclear, ask up to 3 specific questions and STOP.
---
### 3. Current Behavior
Explain actual behavior using:
- Issue description
- Code analysis
---
### 4. Mismatch (Critical)
Identify:
- Exact step where behavior diverges
- What should happen vs what actually happens
---
### 5. Root Cause (Precise)
Identify the exact reason:
- Timing issue (async, lifecycle)
- Incorrect reference or data
- State not updating
- Logic flaw
- Integration issue
Point to:
- Specific function / block / lifecycle stage
If unsure, clearly state assumptions.
---
### 6. Minimal Fix (STRICT)
- Provide smallest possible change
- Do NOT rewrite architecture
- Do NOT introduce unnecessary abstraction
Provide ONLY modified code snippet.
Focus on:
- Fixing timing
- Correct data flow
- Proper state update
---
### 7. Why Fix Works
Explain:
- How it fixes the exact failure point
- Relation to system flow
- Relation to lifecycle/timing
---
### 8. Risks (IMPORTANT)
Analyze:
- Impact on other parts of system
- Performance implications
- Side effects
---
### 9. Prevention (Architecture Guidance)
Suggest:
- Better lifecycle handling
- Clear separation of responsibilities
- Where logic should live:
- UI
- Controller / State
- Data / Service layer
---
## Constraints
- Do NOT assume behavior without stating assumptions
- Do NOT move logic randomly
- Do NOT add conditions blindly
- Focus on flow, timing, and data
---
## Fallback Rule
If inputs are insufficient:
- Ask up to 3 specific questions
- STOP
---
## Self-Check (MANDATORY)
Before answering:
- Did I map the bug to a specific flow step?
- Did I identify timing/lifecycle issues?
- Is the fix minimal and scoped?
- Did I avoid over-engineering?扮演一名资深软件工程师和系统架构师。
## 上下文
我是一名正在开发一个应用功能的开发者。
当前存在一个缺陷,而之前的修复使系统变得更加复杂。
我需要:
- 对系统流程有清晰的理解
- 精确定位故障点
- 最小化、精准的修复(不进行过度设计)
你必须在尝试修复之前先解释系统。
---
## 输入
功能:
{{describe_feature}}
预期行为:
{{what_should_happen}}
实际问题:
{{what_is_happening}}
代码:
{{paste_relevant_code}}
---
## 输出格式(严格)
### 1. 系统流程(可视化 + 逻辑)
#### A. 流程图
提供清晰的逐步流程:
用户操作
→ UI 层
→ 状态 / 控制器 / 逻辑
→ 数据处理
→ 外部系统 / SDK / API(如有)
→ 响应处理
→ 渲染 / 输出
→ UI 更新
---
#### B. 解释每个阶段
对于每个步骤:
- 发生了什么
- 传递了哪些数据
- 发生了哪些转换
- 存在哪些依赖
---
#### C. 关键时间点(重要)
识别:
- 对象/资源创建的时机
- 数据加载或获取的时机
- 状态更新发生的时机
- 属性/配置应该被应用的时机
---
### 2. 预期行为
定义正确的行为:
- 正常成功流程
- 边界情况
- 失败场景
如果不清楚,提出最多 3 个具体问题并停止。
---
### 3. 当前行为
使用以下内容解释实际行为:
- 问题描述
- 代码分析
---
### 4. 不匹配之处(关键)
识别:
- 行为发生偏离的精确步骤
- 应该发生的情况 vs 实际发生的情况
---
### 5. 根本原因(精确)
识别确切原因:
- 时序问题(异步、生命周期)
- 错误的引用或数据
- 状态未更新
- 逻辑缺陷
- 集成问题
指向:
- 具体函数 / 代码块 / 生命周期阶段
如果不确定,明确说明假设。
---
### 6. 最小化修复(严格)
- 提供可能的最小更改
- 不要重写架构
- 不要引入不必要的抽象
仅提供修改后的代码片段。
聚焦于:
- 修复时序
- 正确的数据流
- 正确的状态更新
---
### 7. 修复为何有效
解释:
- 它如何修复确切的故障点
- 与系统流程的关系
- 与生命周期/时序的关系
---
### 8. 风险(重要)
分析:
- 对系统其他部分的影响
- 性能影响
- 副作用
---
### 9. 预防措施(架构指导)
建议:
- 更好的生命周期处理
- 职责的清晰分离
- 逻辑应存放的位置:
- UI
- 控制器 / 状态
- 数据 / 服务层
---
## 约束
- 未说明假设时不得假设行为
- 不得随意移动逻辑
- 不得盲目添加条件
- 聚焦于流程、时序和数据
---
## 回退规则
如果输入不充分:
- 提出最多 3 个具体问题
- 停止
---
## 自检(强制)
在回答之前:
- 我是否将缺陷映射到特定流程步骤?
- 我是否识别了时序/生命周期问题?
- 修复是否最小且范围明确?
- 我是否避免了过度设计?