用 Opus 多智能体编排做全仓库重构审查
作者分享让编排器调度只读子智能体扫描全仓库，产出真实重构建议而非 AI 挑刺的用法。
原始内容
New favourite use case for opus 5.5: Give them the whole repo and ask: “Tell me what we should actually refactor.” • an orchestrator maps the architecture and conventions • it sends fresh read-only agents through every subsystem • it validates, dedupes, and ranks the findings The result: real code smells, dead code, duplication, and architecture issues instead of unnecessary AI nitpicks. Prompt 👇
中文译文
机器翻译，保留原文供核对。
Opus 5.5 的新晋最爱用法： 把整个仓库交给它们，然后问： “告诉我我们实际应该重构什么。” • 一个编排器梳理架构与约定 • 它把全新的只读 Agent 派往每个子系统 • 它验证、去重并对发现的问题排序 结果：真正的代码异味、死代码、重复代码和架构问题，而不是 AI 那些没必要的挑刺。 提示词 👇
深度解析
是什么 这是一条经验分享类推文：作者宣称最喜爱的 Opus 用法，是把整个仓库交给模型并追问“我们真正该重构什么”，并用一张图片附上完整提示词。
核心设计 工作流分三层：一是编排器（orchestrator）先绘制架构与项目约定地图；二是向每个子系统派发“全新的只读智能体”，即每个子任务用干净上下文、无写权限地扫描；三是对发现结果做验证、去重与排序。这个管线把“发现问题”与“评估问题”解耦，避免单一长上下文互相污染。
关键洞察 价值不在模型本身，而在结构化分工：新鲜上下文让每个子系统被独立审视；只读约束保证审查无副作用；排序与去重环节过滤掉 AI 常见的风格化挑刺，留下真实坏味道、死代码、重复实现与架构缺陷。这本质是把代码评审从“问答”升级为“审计管线”。
边界与风险 推文未给出工具实现或评测数据，效果依赖模型能力与提示词质量；“opus 5.5”为作者原文表述，具体版本无法核实。大仓库扫描成本高，产出仍需人工验证，且只读审查不等于落地重构。对读者而言，可借鉴的是编排+隔离+验证的范式，而非即插即用的方案。
精选追评与案例
原作者补充的提示词链接，最值得直接取用。
以幽默方式提醒全仓库重构提示词可能带来破坏性风险。
@pushpak1300 Add - justify why this should be refactored. I'd be looking for specifics such as it's contributed to x number of bugs, we have multiple implementations of the same shape, etc. Point being don't just refactor just to refactor.
中文译文 · 机器翻译
@pushpak1300 它说要删掉你整个代码库 😅
给出 Claude Code 与 Codex 的实测案例，并提示成本偏高。
@pushpak1300 I tried it on one of my Laravel demos that was built by AI a few months ago. With both Claude Code and Codex. It *DID* find *A LOT* of things. Attaching a free screenshots. Will shoot a separate video about it on Laravel Daily, next week. (expensive but) GREAT prompt! https://t.co/dvf2Dloul7
中文译文 · 机器翻译
@pushpak1300 我在几个月前由 AI 搭的一个 Laravel 演示项目上试了。 分别用了 Claude Code 和 Codex。 它*确实*找到了*很多*东西。 附上几张免费截图。 下周我会在 Laravel Daily 上专门拍一个视频讲这个。 （很贵但）很棒的提示词！ https://t.co/dvf2Dloul7
点明去重应按成因合并，避免排序被重复报告带偏。
@pushpak1300 the dedupe step is what decides the ranking: one smell across three subsystems is a single refactor with three call sites, not three findings. collapse on cause, not wording, or the list just rewards whatever got reported the most.
中文译文 · 机器翻译
@pushpak1300 去重这一步才决定排序：同一个代码异味横跨三个子系统，那是一个重构、三个调用点，而不是三条发现。按成因合并，而不是按措辞合并，否则列表只会奖励被报告得最多的东西。
中文实测反馈：排序可用，但误报仍需人工筛选。
@pushpak1300 试过把整个仓库给他们，并问死代码，排名靠谱但误报还得自己筛