将代码审查交给其他AI也能维持判断标准的方法
可以向一个AI说明代码结构，将安全或性能审查委托给其他AI。
但如果新AI不知道当前工作的保存条件和证据状态，可能重新提议已排除的解决方案或扩大范围。
代码审查中需要继续的不仅是代码片段，还有已确认的事实、禁止条件和修改审批边界。
仅传递代码会缺失的信息
即使看同一个diff，如果没有以下信息，判断可能不同。
- 用户经历的实际故障
- 期望值与实际值首次出现差异的边界
- 已确认的非原因
- 必须保存的现有功能
- 允许修改的文件和函数
- 原因尚未确定的状态
- 部署和验证的STOP条件
用Saved留下证据
可以将重要的日志解读、代码分支和风险警告留为Saved。
Saved不是将AI的回答确定为正确答案的功能。而是回到下一个审查者需要重新确认的特定问答的坐标。
用Anchor创建审查契约
在移交给其他AI之前可以将以下内容整理为Anchor。
- 当前问题定义
- 已确认的事实
- ROOT_CAUSE_PROVEN与否
- 现有功能保存契约
- 允许的修改范围
- 禁止的变更
- 下一步验证工作
Anchor不替代整个实现指令书，但提供审查应出发的基准。
用Handoff分离角色
可以向一个AI委托只读证据审查，向另一个AI委托有限的diff review。
使用Handoff就不必每次重新说明同一基准，同时按角色获得不同视角。
新AI不是无条件跟随之前的结论。而是在保存条件和证据的基础上独立审查。
防止原因确定前混入解决方案
代码审查中最危险的是将可能的原因当作实际原因处理。
在Anchor中明确留下当前证据状态，可以减少下一个AI随意进行修改、回滚和重构。
5BY.AI不自动审批工作。而是将用户决定的Gate和STOP条件连接到下一个对话。
在Graph View中查看审查流程
在5BY.AI Graph View中可以审视原因调查Pack、重要Saved、修改审批Anchor和之后审查Pack如何连接。
可以重新确认仅凭最终提交会消失的以下内容。
- 为何只修改了该文件
- 为何排除了某个替代方案
- 在哪个证据之后批准了修改
- 部署前审查了什么
实际工作流
- 在第一个AI中调查故障和代码流程。
- 将重要不一致边界留为Saved。
- 将原因和保存契约创建为Anchor。
- Handoff到其他AI委托只读反证审查。
- 原因维持则确定exact patch范围。
- 实现后在新的AI中进行有限的diff review。
- 将结果和剩余风险记录到新Anchor。
不替代正式开发记录
代码仓库、issue、测试结果和部署记录应留在正式系统中。
5BY.AI不替代那些记录，而是让人重新找到与AI审查时产生的判断流程。
将代码审查交给其他AI时需要的不是复制大量说明。
而是将至今已证明的和尚未证明的、需要保存的功能和允许的范围维持在同一个出发点。
5BY.AI的Saved、Anchor和Handoff帮助那些判断标准不在对话窗口和AI服务之间消失。