| Code Review（CR） | 在代码合入主干前后，由人或工具检查设计、正确性、可维护性、测试、风险与团队约定的活动。 |
| Merge Request（MR） | 开发者请求把一个分支的改动合入另一个分支的协作对象；GitHub 常称 Pull Request（PR）。 |
| Shift-Left | 把质量检查提前到编码、提交或合并请求阶段，让问题在进入后续测试和发布前暴露。 |
| 静态分析 | 不运行程序，依据语法、类型、数据流或预定义规则检查代码。 |
| Agent | 能根据目标、当前状态与工具结果，动态决定下一步动作的模型驱动系统。 |
| Workflow | 由代码预先规定路径，模型和工具在固定节点执行的工作流。 |
| Harness | 包围模型的工程运行支架，负责上下文、工具、状态、权限、验证、恢复和观测。 |
| MCP | Model Context Protocol，用 Host–Client–Server 架构标准化模型与工具、资源、提示模板之间的交互。 |
| Session | 一次完整审查任务的顶层状态对象，承载请求范围、当前步骤、统计与生命周期。 |
| Batch | 从一次大审查中切分出的工作单元，包含有限文件或 diff 工作量。 |
| Issue | AI CR 产出的一条候选问题，通常包含位置、描述、严重度、证据与修复建议。 |
| allowed_next_step | 由服务端维护的下一步许可，限制 Agent 只能领取和提交当前允许的任务。 |
| 采纳率 | 在给定统计口径中，被开发者接受的有效 AI 建议占可判定建议的比例。课程会区分它与通用 Precision 的映射关系。 |
| 召回率 | 在给定真值集合中，被 AI 找到的问题占应被 AI 找到问题的比例。分母定义决定数值含义。 |
| Precision | TP / (TP + FP)，预测为正的样本中真正为正的比例。 |
| Recall | TP / (TP + FN)，所有真实正样本中被找出的比例。 |
| F1-Score | Precision 与 Recall 的调和平均，二者任何一个过低都会拉低 F1。 |
| TP | True Positive，系统报告且经口径确认确实存在、值得报告的问题。 |
| FP | False Positive，系统报告但经口径确认不成立或不应报告的问题。 |
| FN | False Negative，按口径应被系统找出但实际漏掉的问题。 |
| 质量门 | 在流程继续前执行的可判定检查，例如字段完整性、工作量、问题密度或高风险建议检查。 |
| LCS | Longest Common Subsequence，最长公共子序列；可用于比较建议代码与最终代码的行级相似关系，但不等价于语义等价。 |
| Recheck | 对 AI 首轮候选问题进行二次验证，检查它是否属于本次变更、是否符合真实上下文，以及修复建议是否必要。 |
| 负向记忆 | 从反复拒绝或验证无效的审查意见中提炼出的条件化过滤规则，用来降低同类误报再次出现的概率。 |
| Diff Scope | 问题位置与本次代码差异的关系，例如变更行、上下文行或差异范围外；它影响问题是否应归因于当前变更。 |
| Worktree | Git 为同一仓库附加的独立工作目录，可让不同分支在隔离目录中并行工作。 |