交互式 QA

它要解决的问题

“导出报表时点 CSV 有时下下来是空的，但 PDF 没问题”——真实世界的 bug 报告往往就是这么一句话，里面夹着用户的操作习惯、系统的实际行为和一堆没说出来的前提。直接把这类描述贴进 issue tracker，会出现几个反复出现的代价：开发读不懂“有时”指什么，几年后重构换了模块，旧 issue 里的语境彻底失效，后人只能对着一堆过期信息猜。

交互式 QA 要处理的就是这条链路上的前半段：在对话中把零散的自然语言描述，变成耐久、以用户视角出发、使用项目领域语言的 issue。它扮演的角色是 QA 工程师加上领域语言侦探，而不是代码修复者。

工作方式

它按五个步骤推进：

1. 倾听并轻度澄清：最多问 2-3 个短问题，聚焦预期与实际的差异、复现步骤、是稳定复现还是偶发。描述已经足够清晰就直接登记，不做过度访谈。
2. 后台探索代码库：对话的同时浏览相关代码，目的是理解该区域的领域语言、功能本应做什么、用户可见行为的边界——不是为了找修复方案。
3. 判定范围：如果修复跨多个独立区域、存在多个可分离的关注点或多故障模式，就拆分成多个 issue；反之保持单条。
4. 登记 issue：直接登记并分享链接，不先让用户审阅。
5. 继续会话：直到用户说结束，每个 issue 独立登记，不批量处理。

I/O 侧，它接收自然语言描述的缺陷或 BugReport 工件，输出 QAIssueSet，下游可直接进入 triage 分诊，或交给 request-refactor-plan 形成修复计划。

边界与注意点

• 只描述问题，不修复代码。需要落地修复计划时，应转交 triage 或 request-refactor-plan。
• issue 里不引用文件路径、行号或内部实现，这些信息容易过时，重构后即失去意义；描述的是行为，不是代码。
• 拆分原则是宁可多个薄 issue，也不要少数厚 issue，同时要诚实标注阻断关系，按依赖顺序登记以便引用真实编号，最大化并行度。
• 复现步骤必填，整个 issue 需精简到开发者 30 秒内能读完。
• 术语必须贴合项目自身的领域语言——也就是用户用的那种话，而不是工程师的内部黑话。

换句话说，它负责把“问题说清楚”这件看似简单、实际很耗沟通成本的事标准化。