场景一：补齐项目协作资料
目标：让新贡献者知道如何安装、测试和提交修改。
- 在项目体检中固定目标分支完成体检，重点阅读项目说明、贡献指南、Issue 模板和 PR 模板的检查项。
- 选择有证据支持的缺口，在报告页点击“生成改进草稿”。
- 在草稿与交付中核对：命令是否来自真实的项目清单？删去模型猜测的功能、地址和流程。查看内容检查中“npm 脚本不存在”“相对链接找不到目标”等提醒。
- 想确认新人真的能执行，就审阅贡献路径验证的计划并在隔离环境中运行。
- 把相关文件草稿合并为一个 Draft PR，交由项目自身的审查流程。
- 合并后重新体检，确认关联检查已通过。
完成标准：草稿内容与项目实际一致，关键命令有证据，交付目标正确。体检中“已通过”数量的变化可以作为辅助，不能代替内容审阅。
场景二：处理一个 Bug 报告
目标：判断某个输入是否真的触发错误，并给出有依据的回复或修复候选。
- 在关注矩阵中找到这条 Issue。它在“先补信息”象限时，先生成补充信息回复，请报告者提供环境、输入和复现步骤。
- 信息足够后开始 AI 分诊，核对提取出的实际行为、预期行为和运行环境，保存你的判断。
- 在“修复与验证”中生成复现方案。重点审阅机器判据：它是否真的对应报告中的故障？
- 确认后在 Docker 中执行。复现默认执行 3 次，查看稳定性和每一次的证据。环境受阻、网络失败或依赖缺失要单独处理。
- 稳定复现后点击“准备修复建议”，进入维护调查，核对候选补丁与原始要求，再执行支持范围内的双版本对照。
- 把结论和仍然存在的不确定性写入回复草稿，确认后发布。
完成标准：明确区分“稳定复现”“未稳定复现”和“环境阻塞”，并说明结论适用的版本与条件。未能复现不能证明用户报告的问题不存在。
场景三：审阅一项代码改动
- 在审查航道中找到目标 PR。“待审查”泳道右侧、斜纹区域里的票卡，是等待最久还没有人审的。
- 点击“读取文件与检查”，先理解作者意图、关联的 Issue、base / head 分支和 CI 状态。这一步不调用 AI。
- 进入 PR 审查，开始 AI 审查，并查看实际覆盖范围。大型或被截断的 Diff 需要补充人工审查。
- 对每条发现追到源码和变更位置，删除误报、重复意见和没有证据的推断。
- PR 有新提交时重新审查，不要把旧 head 的结论用在新代码上。
- 生成并编辑 COMMENT 草稿：语气聚焦可执行的问题，写明证据和建议。
完成标准：评论中的每个问题你都能解释，未审范围已经说明。是否批准、请求修改或合并，仍在项目的 GitHub 工作流中决定。
场景四：判断对照验证是否有说服力
对照验证用同一组测试分别运行原始版本和候选版本。判断结论时：
- 原始版本命中目标故障、候选版本通过，并且这个故障对应目标需求——才支持“该改动改善了目标行为”。
- 两个版本都通过：本次测试没有区分改动，不能说明改动有效。
- 依赖安装失败：不能据此判断补丁正确与否。
- 同时查看额外回归命令，避免只修好了一个例子，却破坏了正常路径。
人工提供验收测试时，记录测试的来源和编写方式；填写来源声明本身并不能证明测试是独立或充分的。
控制成本和工作量
- 先免费，再付费：先做基础体检、阅读原文、读取文件与检查，再对确实需要的 Issue 和 PR 发起模型任务。打开页面不会自动开始 AI 审查。
- 一次只解决一个边界清楚的问题：先修好连接或环境错误，再重试任务，不要连续创建重复任务。
- 复用已有结果：PR 审查只有部分块失败时，用“仅重试失败块”，不必从头再审一遍。
- 批量要有节制：批量分诊每次最多 12 条，先用筛选缩小范围。
- 看实际用量：模型用量以服务商返回为准；服务商没有返回费用时，不要把空值当作免费。
保留可以复查的交付记录
每次交付都应能回溯：仓库、分支、提交、来源 Issue 或 PR、审阅后的内容和验证证据。共享日志和报告前，删除密钥和不应公开的项目资料。
发布前，维护者应该能回答三个问题：
- 这条建议来自哪里？
- 验证了什么？
- 哪些还没有验证？
重要的结论建议请另一位维护者阅读；单人维护时，也应在发布前逐项重新核对一遍。