Coroid 完成后会在独立分支上创建 pull request，该分支基于你的基准分支生成。它不会直接合并代码，最终决策权仍归你所有。
随附的内容包括：
- 代码变更内容
- 随代码一同编写或更新的测试用例
- 运行现有测试套件后的结果
- 组织内配置的所有质量门控的判定结果
- 对代码差异的评审记录，其中已修复的问题会标注清楚，未修复的问题也会列明
此举并非要取代你的评审流程，而是让你的评审成为后续环节，而非首个环节。
实际需核查的内容
机械性校验工作已由系统完成，你只需重点关注只有你才能判断的事项：
- **它是否解决了正确的问题？**请将其与需求文档中的验收标准对比，而非凭记忆判断你当初的要求。
- **它是否与代码库风格匹配？**编码规范、命名规则、抽象结构等。Coroid 会通过读取代码推断这些规则，大部分情况下都能准确匹配——但偶尔也会有偏差。
- **它是否触碰了你意料之外的内容？**查看代码差异前的文件列表即可知晓。
- **新增的测试用例是否有实际意义？**无法验证任何逻辑的通过型测试用例，还不如没有测试用例。
退回工作
你有三种可选方案，成本依次递增：
- 添加评论并请求返工——该任务会连同你的反馈一起返回给开发智能体，上下文信息得以保留。适用于“内容正确但尚未完善”的情况。
- 驳回方案并重新执行——适用于方案有误而非执行过程出错的情况。
- 取消任务——适用于该工作根本无需开展的情况。取消操作会终止运行并释放智能体资源。
返工评论需像给同事提意见一样具体明确。“此代码未处理空值情况”这类表述能直接给出修复方向；而“需进一步修改”这类表述则只能靠猜测。parseRange“ produces a fix”能引导出修复方案；“needs work”则只能让人盲目猜测。
合并代码
通过你常用的工具合并代码，遵循常规的分支保护规则、必填校验项及审批要求。Coroid 会创建 pull request，后续的流程仍由你现有的机制管控。
合并流程并无特殊之处——这也是刻意设计的结果。pull request 创建的合并请求与普通请求无异，因此会走你信任的现有评审及CI流程。
下一步
后续指引——根据你想要实现的目标，跳转至文档的其他部分。