很多技术问题不是 AI 不会答，而是上下文一开始就被切碎了。
尤其在企业后台、动态表单、权限控制、接口联调这类项目里，一个 bug 往往不是单点错误，而是一条链路上的状态变化：事件触发、字段配置、接口返回、watcher、computed、渲染逻辑、权限规则，任何一环缺失，AI 都容易走偏。
这篇文章不是泛泛而谈“如何写 Prompt”，而是基于真实协作场景，整理一套更适合前端排障和复杂业务系统维护的提问方法。
你的典型工作场景
从提问内容来看，你主要面对的是企业后台和低代码表单编排类项目。常见关键词包括：
| 维度 | 判断 | 说明 |
|---|---|---|
| 技术栈 | Vue2、iView、vxe-table、Webpack | 常见于存量后台系统和复杂表单页面 |
| 业务类型 | 动态表单、工作流、字段权限、导入预览 | 问题通常横跨配置、渲染和接口数据 |
| 工作角色 | 中级偏上前端，接近核心维护者 | 能提供接口响应、复现路径、字段配置和控制台日志 |
| 问题偏好 | 偏具体实例，不偏抽象设计 | 贴真实数据后，AI 的回答质量会明显上升 |
| 核心目标 | 快速定位、少走弯路、代码别乱改 | 更关心修复效率，而不是概念解释 |
这类项目最难的地方在于：表面上是一个页面 bug，背后可能是“表单引擎/编排器”的状态流问题。
所以，好的提问不只是描述现象，而是帮助 AI 建立一条可以验证的链路。
现在最容易浪费时间的地方
1. 现象给得早，数据给得晚
很多请求一开始会这样描述：
页面卡死了，控制台也有报错，什么问题导致的？
这能说明问题严重，但还不够让 AI 判断根因。AI 往往会先猜递归、自引用、watcher 循环、重复请求这些常见原因。
更有效的写法是：
复现路径：
1. 进入某页面
2. 选择字段 A
3. 切换配置 B 后页面卡死
卡死前最后一条日志：
...
Network 表现：
接口 X 重复请求约 N 次 / 没有重复请求 / 接口已返回
已排除：
- 接口已正常返回
- buildInputFieldTree 耗时约 5ms
- 不是自引用字段导致这样 AI 会少走很多猜测路径。
2. “优化”“完善”“解决”太大
“优化一下”“完善一下逻辑”“和 uploadFiles 保持一致”这类说法很常见，但它们没有验收标准。
AI 可能会做风格性重构，也可能扩大修改范围，最后反而把原有逻辑改坏。
可以把模糊动词改成明确约束：
目标：
Signature 在 Excel 预览中与 UploadFiles 的错误展示逻辑一致。
验收：
- 有图片时显示图片
- validateResult[原始 code] 有值时显示错误
- 不猜测其它接口返回结构
- 只修改 data-preview.vue这比“帮我优化一下”更容易得到稳定结果。
3. 纠错发生在 AI 猜错之后
你很擅长在 AI 走偏后纠正它，例如说明“这个只是示例”“不是自引用的问题”。这很有价值，但如果关键事实太晚出现，前几轮成本就已经浪费了。
提问时尽量一次性给出三类样例：
| 样例类型 | 作用 |
|---|---|
| 最小输入样例 | 让 AI 知道真实数据结构 |
| 错误输出样例 | 让 AI 知道当前问题在哪里 |
| 正确输出样例 | 让 AI 知道最终验收标准 |
对复杂业务逻辑来说，样例比一大段抽象描述更可靠。
更适合复杂 bug 的提问方式
复杂 bug 不要只问“哪里错了”，可以先让 AI 建立模型。
例如：
请先梳理这个问题涉及的文件、数据流和触发链路，暂时不要改代码。
请按这个结构输出：
1. 入口事件是什么
2. 哪些 watcher / computed / 方法会被触发
3. 哪些接口会被调用
4. 哪些字段会影响渲染
5. 当前最可能的 3 个根因
6. 每个根因需要什么证据验证当你确认它对系统理解没有偏差后，再让它进入实现：
按方案 2 实现。
约束：
- 不要大重构
- 保持现有代码风格
- 不改接口结构
- 修改前先说明会改哪些文件
- 最后列出 3 个验证场景这能把 AI 从“猜答案”拉回“按证据排障”。
认知盲区：不要过早补丁化
在表单引擎类代码里，“特殊处理一下这两个字符”“这个字段单独判断一下”很诱人，因为它通常能立刻止血。
但这类补丁很容易越补越脆。
更好的问法是让 AI 同时给出三层方案：
请分别给出：
1. 根因层修复：从数据模型或解析逻辑上修
2. 兼容层修复：兼容旧数据或历史异常输入
3. 临时补丁：最小改动止血
请说明每种方案的风险、影响范围和验证方式。这样你仍然可以选择临时补丁，但会清楚知道它是不是在埋债。
提问前的 3 个自检问题
每次向 AI 提复杂问题前，可以先问自己这 3 个问题：
| 自检问题 | 应该补充的内容 |
|---|---|
| 环境是什么？ | 技术栈、相关文件、是否需要读项目约定、是否禁止执行某些命令 |
| 期望输出是什么？ | 修代码、只分析、加日志、给方案对比，不要混在一起 |
| 我已经尝试了什么？ | 已排除项、日志、接口样例、复现步骤 |
这三个问题能显著减少 AI 的误判。
专属提问模板
以后遇到复杂前端 bug，可以直接套用下面这个模板：
### 背景
项目：Vue2 + iView。
限制：不要 npm run build。
是否需要先读 AGENTS.md：是 / 否。
### 目标
我希望你：修复代码 / 只分析原因 / 加调试日志 / 给方案对比。
### 涉及文件
- `path/to/file.vue`
- `path/to/util.js`
### 当前表现
具体描述页面现象、报错、Network 表现、控制台日志。
### 复现步骤
1.
2.
3.
### 输入数据 / 接口样例
贴最小 JSON，不贴无关的大对象。
### 期望行为
正例 1：
正例 2：
反例：
### 已排除 / 已尝试
例如：
- 接口已返回
- 构建字段树耗时 5ms
- 不是自引用限制
### 修改约束
- 不要大重构
- 保持现有风格
- 只改指定文件
- 修改前先说明改动点
- 最后列出验证点如果问题很复杂，可以在末尾追加一句：
请反问我 3 个可能影响结论的边界条件，并标注哪个最可能导致返工。这句话很有用。它会逼 AI 主动暴露不确定性，而不是假装上下文已经足够。
最该改变的 3 个习惯
- 不要先给“现象 + 情绪强度”，后给“最小复现数据”。先给数据，AI 才能少猜。
- 少用“优化、完善、解决”这类大词，多给验收标准和修改边界。
- 不要等 AI 出错后才补关键事实。把接口样例、已排除项、触发时机提前，会直接提高协作效率。
真正高质量的 Prompt，不是把话写得很长，而是把问题的边界、证据和验收标准放在正确的位置。
当你从“描述现象”升级到“描述系统状态变化”，AI 才更像一个靠谱的协作者，而不是一个只能猜测的回答机器。