修 bug 一半时间花在复现上。好的复现 Prompt 要缩输入、隔环境、固化失败状态，并输出能让下一个开发者跑通的 step。“星期二就坏”不是复现。
适合哪些场景
处理工单的工程师、做事故响应的 SRE、给 OSS 提 issue 的独立开发、被告知”我们复现不出来”的人。
什么时候不建议这样写 Prompt
已知问题先搜文档，别上来就用。错误日志 / stack 都没看就用 AI——它没法复现你都没读过的问题。
Prompt 结构公式
每个复现 Prompt 都要带这六个要素：
- 角色：让 AI 扮演谁（Release Captain / QA Lead / SRE / staff 工程师）。
- 上下文：仓库 / 框架 / 运行时 / 分支 / diff / 失败日志。
- 目标：一个具体可交付物——checklist、计划、测试文件、review 笔记、根因、ticket 列表。
- 限制：AI 不能做什么（别自动修、别静默改写、别瞎猜版本号）。
- 输出格式：编号清单、markdown 表格、JSON schema、unified diff、可直接运行的代码。
- 示例 / 信号：1-2 条”好输出”示例，或者说明什么是糟糕输出。
这套 Prompt 适合用在哪
- 把模糊用户报错变成确定性复现
- 隔离环境相关 bug（“我电脑上能跑”）
- 把 bug 单变成失败测试
- 在不泄漏私有数据的前提下给 OSS 复现
- 用 diff bisect 找出错的 commit
12 个可直接复制的 Prompt 模板
1. 模糊报错 → 最小复现
You are a senior engineer. User report: "{userReport}". App / version: "{appContext}". Generate a 5-step minimal repro: (1) preconditions, (2) exact actions, (3) expected result, (4) actual result, (5) environment. If a step is ambiguous, list 1-2 clarifying questions instead of guessing.可替换变量： userReport, appContext
2. 缩到最小失败输入
Here is a failing input: {input}. Reduce it to the smallest input that still triggers the bug. Bisect by halving fields / lines / chars. Show each step and whether it still fails. Stop when removing one more character makes it pass. Output the minimal failing input verbatim.可替换变量： input
3. 复现转失败测试
Convert this repro into a single failing test in {framework}. Name: `repro: <bug-title>`. The test should: (a) fail on the current code, (b) be self-contained (no shared fixtures), (c) include a comment with the ticket URL and one-line root-cause hypothesis. Don't write the fix.可替换变量： framework：jest / pytest / go test
4. 环境差异比对
A bug reproduces in production but not locally. List 12 env differences to check: (1) Node / runtime version, (2) env vars, (3) DB version, (4) timezone, (5) locale, (6) browser version (if FE), (7) memory limit, (8) feature flags, (9) data shape (real vs seed), (10) CDN / cache layer, (11) auth tokens, (12) clock skew. For each: how to compare quickly.5. Heisenbug 隔离
This bug appears intermittently. Distinguish: (a) flake from real bug, (b) race condition vs eventual consistency, (c) ordering issue vs timing issue. For each, propose ONE experiment to confirm. Stop at the first experiment that yields signal — don't run all four.6. git bisect 计划
Bug exists at HEAD but not at {oldSha}. Plan a `git bisect`: (1) what command to use as the test, (2) how to mark good / bad without false positives (e.g., re-install deps), (3) commits to skip (merge commits, lockfile-only changes), (4) the suspect commit's likely cause.可替换变量： oldSha 已知好的 commit
7. 仅浏览器复现
Bug shows in Chrome 120 mobile but not desktop. Generate a Playwright script that: (1) launches mobile emulator, (2) reproduces the bug, (3) takes screenshot at the failing step, (4) outputs the console + network log to a file. Keep it ≤ 30 lines.8. 并发复现
Suspected race condition in `{functionName}`. Write a stress repro: (1) spin up N concurrent callers, (2) shared state to mutate, (3) assertion that fails if the race happens, (4) print first failing iteration. Don't use `sleep` to force the race — use real concurrent calls.可替换变量： functionName
9. 不泄漏数据的复现
提到公开 issue / OSS / Stack Overflow 时用。
Convert this internal repro into a public-safe version: (1) Replace real names / IDs / emails with realistic placeholders, (2) Strip secrets, (3) Keep the failing structure intact, (4) Make it a single runnable file (no internal imports). Output the public file + a one-line note on what was redacted.10. 复现稳定性自检
Run this repro 10 times in your head: which step is least deterministic? Identify (a) the source of variability, (b) how to pin it (seed, fixed time, fixed input). Output the patched repro plus a one-line confidence note ("now deterministic" / "still 1-in-N flake").11. 复现 → 工单模板
Turn this repro into a bug ticket: (1) Title ≤ 70 chars, (2) Reproduction steps (numbered), (3) Expected vs actual, (4) Environment, (5) Severity (Sev-1 → 4 with one-line justification), (6) Affected user count if known. No prose intro. No emojis.12. 无法复现的诊断
I cannot reproduce this user-reported bug locally. List 8 reasons it may not repro: stale build, env diff, data diff, race, browser cache, account state, feature flag, time of day. For each: one quick check. Stop at the first check that succeeds — order by cheapest to verify.容易踩的坑
- 没有确定性复现就让 AI 修——“修复”是猜的。
- “我电脑能跑”类 bug 跳过环境差异步骤。
- 在公开复现里贴真实用户数据。
- 修之前不先写成失败测试。
- flake 和真 bug 不分——先修 flake，否则浪费几小时。
- 输入压得太狠——把触发条件也删了。
- 依赖时间的复现不固定时钟 / seed。
优化技巧
- 没复现的 bug 是 feature request——先投入做复现。
- 输入二分缩——最快收敛到最小。
- 永远先写失败测试再写修复。
- Heisenbug 先分 flake 和真 bug——修法完全不同。
- 仅生产复现的 bug 一般是环境差异。
- 对外分享前先脱敏，别贴完再补。
- 复现文件存进
tests/repros/<ticket-id>.spec.ts，未来回归用。
FAQ
- 复现该花多久？: Sev-1：必要的时间。Sev-3：1 小时为限，超过去要更多信息。
- AI 看不到我生产数据，还有用吗？: 结构和测试骨架它能给，数据你来填。
- 50 次出 1 次算”真 bug”吗？: 通常是 race。用模板 8 让它变确定。
- 每个 bug 修复 PR 都该带复现测试吗？: 是。除非 bug 在第三方 CSS 那种没法单测的位置。
- 付费功能的复现怎么对外分享？: 用模板 9 脱敏，保留失败结构、替换数据。
- 真的复现不出怎么办？: 走模板 12。多数”复现不出”是环境或数据漂移。