Qodo
提供基于代码上下文的 AI 代码审查工具。
Qodo 当前定位为代码审查与质量治理平台，在 PR、IDE、CLI 和 Git 工作流中分析变更。它结合仓库结构、历史和依赖提供反馈，适合把审查标准落到具体改动。
Qodo 能做什么
接入重点是组织已连接的仓库、个人 Git 身份和团队 Review Standards。仅创建个人账号并不意味着所有仓库都会自动被审查。
本文依据当前平台文档整理，不把旧版 Qodo Gen 的测试生成入口等同于所有当前产品能力。审查意见仍需要结合实际代码、测试和需求判断。
利用整个系统的上下文
平台维护仓库结构、历史与依赖的理解，审查可以考虑跨文件或跨仓库影响，而不只分析单个 diff。上下文完整性取决于接入的仓库和相关资料。
在 PR 中解释发现的问题
审查发现包含问题、原因及后续处理方向，可涉及逻辑错误、边界条件和规则偏离。应检查它引用的事实是否对应当前变更。
检查关联需求与设计
官方列出的发现类型包括关联规格遗漏、Figma 设计偏差和跨仓库冲突。这些判断需要相应链接与上下文，不应假设未提供的需求也会被发现。
将团队惯例用于审查
Review Standards 可综合代码库、PR 历史和明确要求，形成持续演进的规范，再用于后续审查。它提供审查依据，不替代团队对规范的确认。
- 核心用途
- 仓库上下文审查与规范检查
- 可完成的工作
- PR 缺陷、需求遗漏与跨仓库影响
- 如何开始
- 登录并关联 Git 身份，使用已接入仓库
- 使用条件
- 组织需先接入；套餐权益按账号核对
如何使用 Qodo
- 确认组织仓库已接入
组织管理员先完成组织设置；个人用户确认自己要审查的仓库属于已连接范围。
- 创建或加入正确账号
从官方登录入口选择支持的方式；收到组织邀请时，使用接收邀请的同一邮箱登录。
- 关联个人 Git 身份
在账号菜单选择 Link your Git user account，让平台识别自己的 PR 与提交。
- 打开 PR 并处理发现
在已接入仓库创建 PR，核对自动审查结果；用代码与测试验证问题后再决定修复或说明。
审查一次接口修改
适合：维护多人协作仓库的工程师
- 准备输入
- 已接入的仓库、接口变更 PR 和预期行为
- 操作方法
- 编辑建议：确认 Git 身份与仓库连接，提交范围清楚的 PR；逐条检查 Qodo 的问题位置、触发条件和修复方向。
- 预期交付物
- 带有处理结论的审查记录
- 人工检查
- 对有效问题添加复现或回归测试，对不适用建议说明原因。
检查需求是否漏实现
适合：处理需求工单的开发团队
- 准备输入
- PR、关联规格及可检验的验收条件
- 操作方法
- 编辑建议：让审查获得关联需求，重点核对边界条件和未实现部分，再把遗漏整理为后续修改。
- 预期交付物
- 需求与代码的核对清单
- 人工检查
- 区分文档缺失、实现缺失和模型误判，不把审查通过当作需求验收。
统一多人审查尺度
适合：有明确工程规范的团队
- 准备输入
- 现有代码习惯、历史 PR 和正式规范
- 操作方法
- 编辑建议：整理团队的 Review Standards，在小范围 PR 中核对规则应用是否符合真实惯例。
- 预期交付物
- 可迭代的团队审查规则
- 人工检查
- 遇到相互冲突的历史习惯先由团队定规则，再调整自动审查。
界面与参考图片
开始前需要了解
账号与仓库授权是两个环节
个人 Git 关联用于识别提交身份；自动审查针对组织已连接的仓库。没有完成接入时，不能仅靠登录判断配置成功。
需求与设计检查需要上下文
关联规格、工单和设计是审查依据。缺少这些资料时，不能把没有出现相关问题理解为已经满足需求。
平台能力不代表全部套餐免费
概览描述多种工作流，但本文未核实各套餐完整额度。选购时应在当前账号与官方套餐页面核对可用集成和审查范围。
核心为上下文代码审查；组织仓库接入与个人 Git 身份需分别配置。
账号权限、费用与可用功能请以官方入口的当前说明为准。重要结果应先检查，再用于实际工作。
常见问题
Qodo 现在主要用于什么？
当前官方以代码审查、代码质量和开发流程治理为核心，支持 PR、IDE、CLI 与 Git 工作流。
注册之后会审查所有仓库吗？
不会据此自动获得全部仓库访问权。官方快速开始要求组织仓库已连接，并关联个人 Git 身份。
只能查语法问题吗？
官方列出逻辑错误、规范偏离、需求遗漏和跨仓库冲突等类型；具体发现是否成立仍需检查证据。
团队规范从哪里来？
Review Standards 可综合代码、PR 历史及明确要求；团队需要核对其是否反映当前约定。
