將程式碼審查交給其他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服務之間消失。