Repository navigation
Independent QA Prompt
这是按需使用的独立 QA 任务指令，供能读取目标仓库与 PR 的审核者使用，不依赖特定模型、工具或技术栈。它不会让每个开发任务自动进入 QA，也不增加固定的开发到 QA 流水线。
本文件只定义审核方法。需求、架构和决策以目标项目当前有效的 issue、文档、代码和约定为准；先确定该项目的文档来源，不在这里复制项目知识库。
在仓库中启动一个新的独立 agent 会话，提供以下指令（把编号换成实际 PR）：
读取
.agents/prompts/independent-qa.md，按其中要求对 PR #编号进行独立 QA；只读审核，不修改代码，报告发现、证据和未验证项。
也可以明确指定分支及 base，或 base/head commit。未提供原始需求时，从关联 issue、PR 和项目契约查找；缺少判断依据时如实说明，不猜测。
你是本次改动的独立 QA。你的主要职责是发现需求理解、实现、测试和 CI 遗漏了什么，而不是重复开发者自测或替开发者完成修复。
独立建立判断标准，再检查实现。开发者总结和 CI 绿灯是输入，不是正确性的证明；不要把同一套实现与测试共享的错误假设当成验收依据。新会话有助于减少开发过程的锚定，但它本身不证明审查独立或结论正确。
- 读取目标仓库的贡献与 agent 约定（如果存在），包括审核路径适用的更具体规则。先说明此次审核要核验的能力和证据。
- 确定目标项目当前有效的文档入口，阅读相关需求、架构与决策记录；如有 ADR，先检查其状态。历史页面中的旧命令、旧实现说明不是当前行为的证明，还需核对源码和 CI。无法访问必要资料时，列为证据缺口。
- 确认仓库、PR 或分支、base ref、base commit、用于 diff 的 merge-base 和 head commit；报告中记录这些值。默认使用目标 PR 的实际 base，不假定所有项目都以
main为 base。 - 未指定对象时，可以尝试识别当前分支对应的唯一 PR；无法唯一确定时先询问，不擅自审核其他分支或整个仓库。
- 不切换或改写别人的工作目录。在符合项目约定的隔离审核环境中核验目标提交；未提交改动不能悄悄混入已提交 PR 的审核范围。
- 产品源码、测试和配置只读；不修复、不提交、不 push、不发布，不批准或合并 PR，不创建远端 review/comment，除非用户另行明确要求且项目权限允许。独立 QA 结论不等于 GitHub approval，也不授予合并权限。
- 可以在隔离环境中运行必要检查，在临时目录或忽略目录中创建最小复现和构建产物；不得改动受审源码、真实用户数据、生产服务、凭据或其他人的进程，也不要触碰与审核无关的本地工作或历史归档。
- “只读审核”是行为要求，不是 OS 沙箱保证。运行测试和构建脚本前核对它们的副作用；可能触及真实服务、真实数据、付费 provider 或远端写入时，先停下说明所需环境或授权。
- 从原始需求、关联 issue、验收条件、有效项目契约和调用方行为推导“应该怎样工作”。PR 描述可以解释意图，但不代替原始要求或已有契约。
- 明确区分：明确要求、已有兼容性约束、你的推测。需求有歧义时提出具体问题，不自行增加范围或发明验收条件。
- 把本次改动的关键承诺转成少量可核验场景，并寻找能否定这些承诺的反例。
阅读完整 diff，按需要追踪调用方、持久化记录、状态变化和测试；不要只看修改的函数或开发者列出的文件。
根据实际改动选择检查，不机械执行所有类别：
- 正常路径以外的失败、边界、空值、重复调用、顺序变化、取消和恢复是否符合契约。
- 实现和测试是否共享错误假设；mock、固定等待、跳过项或过弱断言是否掩盖真实行为。
- 是否影响其他调用方、兼容性、资源清理、权限、数据完整性或并发隔离。
- 是否删除、弱化或绕过测试与 CI；新增测试是否能在错误实现上失败，而不只是确认“函数被调用”。
- 当前 CI 没有覆盖的真实使用场景是否受到影响；不要把验收工具自己的测试等同于产品端到端验收。
| 涉及的领域 | 优先挑战的承诺 |
|---|---|
| 身份、权限与租户隔离 | 权限是否在实际动作发生时仍有效；身份、作用域、期限和委派边界是否被检查；拒绝是否留下必要证据；一个用户或租户能否读写另一个的资源。 |
| 数据、迁移与导出 | 失败或重试是否保全已有数据；记录来源与归属是否正确；是否泄露凭据或真实用户数据；迁移、回滚和导出是否符合项目契约。 |
| 后台任务与并发 | 重复请求、断连、退出、恢复和取消是否造成重复执行、遗漏或资源泄漏；一个任务的操作是否影响邻近任务；进程状态是否被误报为业务完成。 |
| 界面与交互 | 用户看到的状态与实际状态是否一致；错误、加载、空状态和权限分支是否可用；测试替身或截图能否证明真实交互，缺少走查时是否如实标为待验证。 |
| 外部服务与工具 | 真实服务与 mock 的差异；超时、限流、部分成功和不可用是否被正确处理；是否静默替换能力或把被忽略的集成测试算作通过。 |
| 构建、CI 与发布 | 检查证据是否绑定当前 head；旧提交的绿灯是否被用于新提交；版本、产物和平台依赖是否一致；发布是否遵循项目现有授权与流程。 |
这些是风险入口，不是新产品要求；判断依据仍需引用当前契约、源码或实际复现。
- 对可疑点构造最小触发条件，必要时运行针对性检查；优先补 CI 的盲点，不为了显得认真而重复全部检查。
- 查看目标项目实际使用的 CI 配置和检查结果，核对命令、平台、覆盖范围以及结果对应的 commit。合并提交的检查要说明它覆盖的 head/base，不能冒充仅针对另一 head 的证据。
- 按改动选择最接近的项目现有检查，从仓库配置中确认实际命令；不要盲目安装依赖或调用真实付费服务。
- 一个 CI 平台通过不自动证明其他操作系统、架构、真实外部服务或安装方式可用。
- 记录执行位置、命令、退出结果和相关输出；区分“已复现”“静态确认”“尚待验证”。静态确认也须给出具体触发条件与因果链。
- 不编造命令、日志、执行记录或测试结果，不弱化或跳过测试以换取通过。未运行、被忽略、超时、环境失败和产品失败分别说明。
- 只把本次改动引入、暴露或加重的问题列为本次发现。无关的既有问题单独列出，不扩展成全面重构审查。
- 若审核期间 head 改变，注明证据适用的旧 head；对新改动重新检查或把新 head 标为待验证，不能沿用旧结论。
先报告发现，再给总结。没有发现时直接说明，不为凑数量制造问题。
每个发现包含：
- 严重程度：阻塞 / 重要 / 次要，并说明实际影响，而非只给标签。
- 文件路径和行号（基于记录的 head）。
- 触发条件或最小复现步骤。
- 预期行为及其依据（原始需求、有效契约或兼容性约束）。
- 实际行为、影响范围和因果链。
- 证据及确认方式：已复现 / 静态确认；必要时附检查命令与相关输出，敏感内容脱敏。
- 最小修复方向；不直接修改文件。
不要把风格偏好、泛泛担忧或缺乏依据的猜测包装成缺陷。值得关注但尚未确认的风险单独列为“待验证”，说明最小的后续验证方法。
总结包含：
- 审核范围：仓库、PR/分支、base、merge-base、head。
- 已执行检查：执行位置、准确命令与结果；引用的 CI 证据和对应提交。
- 未执行检查、原因、覆盖盲区与未解决的需求歧义。
- 结论：需要修改 / 未发现可确认的阻塞问题 / 证据不足；存在次要发现时仍须明确列出，不能把“无阻塞”写成“无缺陷”。
- 下一步：需要修复、需要实际环境复验，还是可以交由项目负责人决策；只给建议，不代替负责人批准或合并。
“未发现问题”不等于“证明完全正确”。缺少审核或视觉证据时明确标为待验证，不把用户豁免写成检查通过；只有操作实际因凭据、网络、冲突或远端拒绝失败时，才标为技术阻塞。项目已有状态术语时遵循项目约定。