Orca 代码审查怎么做？不写新代码，只审代码的流程

最后更新：2026-10-25

Orca 是 Stably AI 出品的免费开源桌面应用，自称 ADE，也就是 Agent 开发环境。它的办法是把 Claude Code、Codex、OpenCode、Pi 这些命令行编程 Agent 装进同一个界面，让它们各自在独立的 git worktree 里并行干活，最后把结果摆在一起对比，只合并最好的那一份。这篇不写怎么用 Orca 写新代码，只写审查流程：把旧代码、别人的改动、多份实现扔给多个 Agent 并行审，审完再决定合不合。

审查和写代码，在 Orca 里有什么不一样？

写代码是让 Agent 产出改动，审查是让 Agent 只给意见、不动代码。这个区别要先写进提示词：审的目标是什么、重点看哪些文件、输出是意见清单而不是改动。审的时候不合并、不落地，意见先摆出来对一遍，再决定改不改。还有一个区别：写代码看结果好不好，审查看意见准不准。意见要能指到具体行、具体逻辑，不能只给一句笼统的好坏。笼统的意见对不上 diff，批注往返也没法落到实处，等于没审。审的时候还有一个心态上的区别：写代码盼着一次过，审查盼着问题早暴露，暴露得越早，改起来越便宜。

审什么？先看哪几样？

先看逻辑有没有跑偏：改动是不是你要的那个任务、有没有顺带改了不该改的东西。再看边界条件：空值、异常输入、极端分支有没有处理。第三看改动范围有没有越界：文件清单对不对、是不是动了不相关的模块。范围、逻辑、边界三样先过一遍，再看写法细节。细节可以放批注里提，但不能因为细节问题就否掉逻辑没问题的一份。主次不分，审查就变成挑写法，真正的问题反而漏过去。

审查的提示词怎么写？

三件套：审的目标、重点文件、输出形式。目标写清楚：审这份改动对不对，不是重写。重点文件列出来：这次改动涉及哪几个文件、哪几处是关键。输出形式定下来：只给意见、不改代码，意见按文件和行号列，问题、理由、建议分开写。提示词含糊，审出来的意见就含糊：没写目标，Agent 可能直接上手改；没列重点文件，意见就散在全量代码里，挑不出来；没定输出形式，意见和改动混在一起，审完还要再拆一遍。

多个 Agent 并行审，结果怎么对？

先找一致的地方：几个 Agent 都指出同一个问题，这个问题先信，优先处理。再看分歧的地方：有的 Agent 说有问题、有的说没问题，分歧本身就是信号，回到 diff 上再看一遍，到底是哪一行、哪段逻辑有争议。分歧不要凭票数定：两个说没问题、一个说有问题，不代表少数错了，关键看理由能不能指到代码上。理由能指到具体行和逻辑的，权重更高；只给结论没给理由的，先放一边。对结果的方法和挑结果的方法是一回事：先定标准再看答案，不凭第一印象。

审查意见怎么落成批注往返？

意见先落成批注：有意见直接在那一行写，写清楚问题是什么、为什么是问题、建议怎么改。批注发回去让 Agent 改一版，改完再比一轮：上一轮的意见有没有改掉、有没有改出新问题。往返没有固定轮数，标准是意见清掉为止：问题项一项一项打勾，清完了再合并。批注里绕圈子的时候停下来：意见来回几轮还没定，多半是审的目标没写清楚，或者改动本身方向就不对，回到提示词和目标上改，比在批注里磨快。批注是打磨的工具，不是兜底的办法。

审到什么程度可以合并？

三条都过才能合：逻辑没跑偏、边界有着落、改动范围没越界。意见清单清掉是硬条件：还有没解决的问题项，就不合。合并之前还有一个动作：合进去的那份 diff 自己先通读一遍，确认改动和审过的意见对得上，再点合并。审完就合、合完就不看，是审查流程最常见的破口：审过的意见要落在合并的那份里，不是落在被丢弃的那份里。通读一遍花不了多少时间，合错之后回退花的时间更多。

审旧代码和审新改动，做法一样吗？

不一样。新改动有明确的范围：这次改了哪几个文件、为什么改，审的时候对照着改动清单看。旧代码没有改动清单，审之前先定范围：审哪一个模块、审哪一类问题，范围不定，审就散了。旧代码的审法是先圈范围再派活：模块、问题类型、输出形式写进提示词，再让多个 Agent 并行审。审旧代码更容易审出风格问题，风格问题放批注里提，不因为风格问题否掉逻辑没问题的一份。审旧代码还有一条：别想一轮审完整个库，一轮审一个模块，审完记下来，下一轮再审下一个。

审查意见互相矛盾怎么办？

先回到 diff 上看：矛盾的意见各自指在哪一行、哪段逻辑，理由能不能站住。理由站得住的留下，站不住的去掉；两边理由都站得住，说明这处本身就有两种合理做法，这时候看验收标准：哪种做法更符合这次任务的目标。标准也定不了的时候，记下来先不合：有争议的改动不急着合，合进去再改比合之前争清楚贵。矛盾不是坏事：审出矛盾，说明并行审真的在起作用，单 Agent 审是审不出分歧的。分歧摆在台面上，才有机会挑对。

几个 Agent 审的时候，要不要互相看对方的意见？

先各自独立审，再对结果。并行审的价值就在独立：几个 Agent 各自看同一份 diff，各自出意见，意见摆在一起才有对比的意义。审的时候就互相看，意见会互相靠拢，分歧出不来，并行审就退化成了一份意见换几个说法。做法是分两步：第一步各审各的，意见按文件和行号列清楚；第二步把几份意见摆在一起对，一致的地方先信，分歧的地方回到 diff 上再看。两步的顺序不能反：先独立再对照，对照才有东西可对。独立审还有一个好处：同一处问题被几个独立视角同时指出，说明这个问题确实明显，优先处理就更有依据。

审完之后，记录怎么留下来？

每一轮审完记一笔：审的是哪份改动、几个 Agent 审的、一致意见有哪些、分歧落在哪几处、最后合了哪一份、为什么合它。记录不用复杂，几行字就行，关键是每次都记。记下来的东西下次直接复用：同类改动来了，审的重点、常见的坑、挑意见的方法都不用从头想。没留下来的审查经验等于没攒，下次遇到同类改动还得从头审一遍，并行开再多也只是重复花钱。复盘的习惯和审查本身一样重要：审完不记，等于审完就忘。

不会编程的人，审查这套流程跟自己有什么关系？

实话实说，审查默认你懂 diff、能看懂改动逻辑，整个动作就是读 diff、写批注、合并。完全不写代码的人，方向正好相反的产品是 aiglade：「Aiglade 是一个 Windows 桌面软件，把 Claude Code、Codex CLI、Hermes、OpenClaw 等多个 AI 装进一个中文窗口，带中文向导，装上就能用，不用会编程。」它的口号是「不用先学会技术，也能让 AI 替你干活」。一句话总结：会写代码、要审别人改动和多份实现的人看 Orca；不会编程、只想让 AI 替你干活的人看 aiglade。

参考来源

相关阅读