如何用 Claude Sonnet 4.6 做大仓库代码审查与规划

快速答案

值得用，但更准确的说法是：Claude Sonnet 4.6 现在已经足够胜任大仓库代码审查和实现规划的第一轮工作，不过真正高杠杆的用法仍然是先审查、后补丁。按 2026-03-24 的 Anthropic 官方信息，Sonnet 4.6 已经是 Claude Free 和 Pro 的默认模型，可用于 Claude Code 和 API，价格仍是每 100 万输入 token 3 美元、每 100 万输出 token 15 美元，并被官方文档列为支持最高 1M context 与 64K max output。Anthropic 同时仍把 Opus 4.6 定位为更适合深度重构、多 agent 协调和高风险任务的更强模型。

更稳的实际闭环是：

• 把仓库级长期规则写进 CLAUDE.md
• 先用 Plan Mode 或只读分析模式
• 在任何代码改动前先要 repo map、unknowns 和 failure modes
• 先批准文件边界和测试边界
• 补丁分开执行
• 合并前再跑 /review 或等价的 diff review

有一个细节不能忽略：Anthropic 当前文档虽然把 1M context 当作真实能力来描述，但 context window 文档依然把它写成带 beta/API 条件的能力。更安全的理解是：长上下文让流程更舒服，不代表你可以跳过边界控制。

为什么现在值得写这篇

Anthropic 在 2026-02-17 发布了 Sonnet 4.6。真正有用的变化，不只是 Sonnet 更会写代码了，而是 Claude Code 周边这套工作流终于更容易写成明确流程，而不是只存在于聊天记录里。

Sonnet 4.6 让你可以更低成本地做 repo 理解、风险审查和实现规划。Claude Code 则补齐了让这套流程落地的工具：CLAUDE.md memory、/init 和 /review 这类内置 slash command、Plan Mode，以及项目级命令或 skills。

组合起来，才是一套真正适合大仓库的工作方式：

• 共享规则存在仓库里，不只存在聊天里
• 审查和规划发生在编辑之前
• 模型有一条明确的书面边界不能越过
• 最终补丁仍然要对照 diff 和测试来验收

官方信息到底改变了什么

官方信息	落到实际工作流里的意义
Sonnet 4.6 成为 Claude Free 和 Pro 默认模型，且 Anthropic 表示它可用于 Claude 各计划、Claude Code、API 和主要云平台	更多开发者无需特殊配置就能复用同一套流程
Sonnet 定价仍是 $3 input / $15 output 每百万 tokens	先做规划、后做实现的第一轮成本足够低，适合日常使用
Opus 4.6 官方价格更高，为 $5 input / $25 output 每百万 tokens，且被定位为最强深度推理模型	你有了清晰的升级规则，而不是默认先用最贵模型
Anthropic 的模型总览把 Sonnet 4.6 列为 64K max output	长篇 review notes、计划和问题清单更容易一次输出
发布说明和 context docs 把 1M context 描述为 beta，而模型总览把 Sonnet 4.6 写成支持 1M context	大仓库、长规格、长 diff 更现实，但不要假设所有使用面都天然等价
Anthropic 为 Sonnet 4.6 文档化了 adaptive thinking 和 extended thinking	任务开始变模糊时，你可以先提高 reasoning effort，而不是立刻切到 Opus
Anthropic 仍把 Opus 4.6 定位为更适合代码库重构、多 agent 协调和高风险深推理	Sonnet 应该是默认审查器，而不是最终批准者

这里最容易被误读的一点是：长上下文只有在任务边界已经清楚时才有价值。它不能替代文件清单、unknowns 列表和模型之外的验证步骤。

什么情况下应该默认先用 Sonnet 4.6

只有当下面这些条件同时成立时，Sonnet 4.6 才适合作为第一步：

• 你需要先理解现有仓库，再决定怎么改
• 任务可以被收敛成审查、规划或有边界的局部改动
• 在补丁出现前，你就能说清楚如何验证
• 第一轮判断做错，代价只是烦，不是灾难

适合的任务：

• 修 bug 之前先梳理 repo 结构
• 对一个 PR 做第一轮风险审查
• 在有边界的重构前先追共享逻辑
• 对比两种实现方式是否符合现有约定
• 从大 diff 或 ticket 中提取测试计划

不适合的任务：

• 认证、计费、安全、合规相关改动
• schema migration 和回滚代价高的数据任务
• 跨系统重构且存在隐性二阶影响
• 根因尚不明确的线上问题
• 依赖团队尚未写清的产品意图的任务

一套更实用的 Claude Code 大仓库工作流

第一步：把稳定规则写进 CLAUDE.md

Anthropic 的 Claude Code 文档明确支持项目 memory 文件 CLAUDE.md，memory 文档也支持用 @path 导入其他文件。相比每次会话都重新口述规则，这才是更稳的做法。

一个小而够用的例子：

# Review defaults

Read @README.md for architecture and @package.json for scripts.

- Map files and unknowns before suggesting edits.
- Prefer the smallest diff that solves the task.
- Name tests and manual checks explicitly.
- Stop if the task crosses a public API, schema, or auth boundary.

如果仓库里还没有 CLAUDE.md，Anthropic 也把 /init 文档化为可用于初始化的内置命令。

这么做的好处是：

• 规则能跨会话保留
• 新的 review run 会继承同一套边界
• 人类同事也能直接检查和修改这套流程

第二步：先进入 Plan Mode 或只读分析

如果你就在 Claude Code 里工作，Plan Mode 是更安全的起点，因为它会先把模型放在分析态，而不是直接写补丁。

一个明确的 CLI 入口是：

claude --permission-mode plan

第一轮提示词可以这样写：

Analyze this repository task in review mode.

Return only:
1. the files or directories to inspect first
2. the architecture you infer from them
3. what is still unclear
4. likely failure modes
5. whether this should stay on Sonnet 4.6 or escalate

Do not write code yet.

Task:
[paste the ticket, bug, or PR description]

这一步同时做了三件事：

• 强制模型先读 repo，再谈实现
• 产出一份你自己也能核对的文件短名单
• 把不确定性显式写出来，而不是藏进一个很自信的补丁里

如果你不在 Claude Code 里，也可以在 Claude chat 或 API 里沿用同样的结构。真正重要的不是界面，而是要把分析和编辑拆开。

第三步：先要 risk-first review，不要先要 fix

当 Sonnet 已经完成 repo map 后，下一步不是让它直接写代码，而是让它优先找“哪里会改坏”。

Based on the repository context you gathered, review this task as if you were trying to prevent a bad patch.

Return:
- likely files affected
- public contracts that might break
- hidden dependencies or assumptions
- tests and manual checks that must pass
- one reason to stop before editing

Do not write code yet.

这通常是 Sonnet 在日常工作里最值钱的一步。模型足够快，能扫较大的表面积；成本也足够低，你完全可以在任何人动文件之前先否掉计划。

如果它的回答仍然很像在猜，那就是信号：要么提高 thinking effort，要么直接升级到 Opus，而不是逼 Sonnet 继续硬做。

第四步：让 Sonnet 产出最小安全计划

做完风险审查后，再让它给出最窄、但仍然可执行的实现路径。

Now produce the smallest safe implementation plan.

Constraints:
- touch no more than 5 files unless you hit a blocker
- preserve public API names unless change is unavoidable
- avoid new dependencies
- stop if the fix implies an architecture or schema change

Return only:
1. files to edit
2. exact change summary by file
3. tests or commands to run
4. what would make this plan invalid

这正是 Sonnet 4.6 更长输出和更稳 instruction following 发挥价值的地方。一个有边界的计划，通常比一个“看起来很聪明”的补丁更有用，因为它更容易读、容易比对，也更容易被否决。

第五步：把 thinking loop 和 editing loop 分开

不要让同一个会话既负责理解架构，又在你不知不觉中重写半个仓库。

更稳的顺序是：

1. Sonnet 做 repo map
2. Sonnet 写 risk review
3. Sonnet 写 bounded plan
4. 你或其他工具去应用补丁
5. Sonnet 再 review 最终 diff

如果你本来就在 Claude Code 里，Anthropic 也已经把 /review 作为内置命令文档化了，所以它天然适合放在 diff 已经存在之后。

你也可以用一个普通的 diff-review 提示词：

Review this diff against the approved plan.

Flag:
- scope drift
- duplicated logic
- missing tests
- claims the patch does not actually prove
- places where the repository's conventions were ignored

把两个循环拆开，最大的好处是流程可读。这样模型就更难在半路偷偷改题。

第六步：把长上下文当加分项，不要当拐杖

Sonnet 4.6 的长上下文能力是真实存在的，但细节口径不能忽略。Anthropic 当前的 context-window 文档仍把 1M context 描述为 Claude Sonnet 4 在 API 中的 beta 能力，而模型总览页则把 Sonnet 4.6 列为支持 1M context。

更安全的执行规则是：

• 默认认为结构化提示词比原始上下文尺寸更重要
• 只有当你真的需要把大规格、长 PR、日志和代码一起塞进来时，再使用 1M context
• 即使上下文很长，也持续要求文件短名单和 unknowns 列表

如果会话开始发散，就主动重设边界。Anthropic 也文档化了 /compact，适合只保留被批准的计划，而不是整段越来越长的聊天历史。

标准 Sonnet、提高 thinking 和 Opus 该怎么选

Anthropic 当前的产品定位已经把分流规则说得比较清楚。

场景	更适合的第一步	原因
repo 定位、文件发现、第一轮 PR 审查	标准 Sonnet 4.6	快、便宜，而且通常够用
模糊但仍有边界的 bug 或重构	Sonnet 4.6 + 更高 thinking effort	可以先换来更强推理，而不是立刻付 Opus 成本
高风险架构改动或跨系统重构	Opus 4.6	Anthropic 仍把 Opus 定位为更强的深度推理模型
高代价生产改动的最终签字	Opus 4.6 或人工审查	这里错误成本高于速度价值
产品意图或业务规则本身不清楚	先让人做决策	没有任何模型能替团队发明正确需求

核心判断很简单：Sonnet 负责默认审查与规划；Opus 用于判断成本远高于阅读成本的任务。

一套可直接复用的日常提示词栈

如果你只想拿走一套能长期复用的流程，用这四段就够了。

Prompt 1：Repo map

Read this repository context and identify the smallest set of files I should inspect first.
Explain the architecture in plain English, list unknowns, and do not propose fixes yet.

Prompt 2：Risk review

Review this task for likely regressions, hidden dependencies, and tests that must pass.
Prefer warnings over solutions.

Prompt 3：Bounded plan

Produce the smallest safe plan.
List exact files to touch, what changes in each file, and what would make this plan invalid.

Prompt 4：Diff review

Review this diff against the original plan.
Flag:
- scope drift
- duplicated logic
- missing tests
- claims the patch does not actually prove

这组提示词故意写得很无聊。无聊是好事。它会把 Sonnet 固定在 reviewer 和 planner 的角色上，而不是让它变成一个过度自信的 autopilot。

常见失败模式

失败模式	实际会发生什么	更稳的修正方式
把长上下文当成已理解	1M context 只是让你放进更多材料，不代表模型真的理解了仓库	总是要求它列出 unknowns、弱假设和最小相关文件集
把规则只留在聊天里	下一次会话必须重新学习同样边界，流程会越来越不一致	把长期规则写进 CLAUDE.md，而不是只放在 prompt 里
一开始就要求实现	模型会优先追求推进感，而不是正确性	先强制做 repo map 和 risk review
让模型悄悄扩 scope	大上下文模型会顺手把很多“顺便清理”也合理化	要求精确文件列表，没有具体理由就拒绝 scope 扩张
在本该由人决策的地方继续用 Sonnet	模型无法补出团队从未写清的产品意图和业务规则	让 Sonnet 暴露 tradeoff，但最后由人做决定

FAQ

什么时候应该从 Sonnet 升级到 Opus？

当任务真正昂贵的部分是“判断”，而不是“读得快”时，就该升级。典型场景包括高风险架构改动、跨系统重构、代价高的生产签字，或者任何一个错误假设都会很贵的任务。

用这套流程一定要 1M context 吗？

不需要。就算上下文更小，这套流程仍然成立，因为真正提高质量的是结构：文件短名单、unknowns、risk review 和 bounded plan。1M beta window 的价值，更多是让超大任务在可用时更舒服。

应该先用 /review 还是先用 Plan Mode？

先用 Plan Mode 或只读分析。/review 更适合放在 diff 已经存在之后。

每个仓库都值得有一个 CLAUDE.md 吗？

如果你会反复在同一个仓库里使用 Claude Code，值得。一个小而明确的 CLAUDE.md，通常比你每次重打一遍同样的规则更划算。

最后结论

Claude Sonnet 4.6 现在值得用，不是因为它能替你拍板，而是因为它把 AI 辅助开发里最便宜但最重要的一段做得更好了：在你动代码前先理解仓库。

把 Sonnet 4.6 作为大仓库默认的 reviewer 和 planner；把稳定规则放进 CLAUDE.md；把补丁边界写清楚；把验证留在模型之外；把 Opus 留给那些“错了会很贵”的任务。

核验说明

已于 2026-03-24 按 Anthropic 官方来源核验：

• Sonnet 4.6 发布日期、Claude 默认可用性、Claude Code / API 可用性、Sonnet $3 / $15 定价、1M context beta 口径，以及 Opus 与 Sonnet 的定位，核对自 https://www.anthropic.com/news/claude-sonnet-4-6
• Sonnet 4.6 与 Opus 4.6 的当前定位、max output、thinking 支持，核对自 https://platform.claude.com/docs/en/about-claude/models/overview
• 1M context 的当前 beta 范围与 API 条件，核对自 https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• CLAUDE.md memory、@path imports、/init、/review、/compact 以及 Claude Code 常见工作流，核对自 https://docs.anthropic.com/en/docs/claude-code/memory、https://docs.anthropic.com/en/docs/claude-code/slash-commands、https://docs.anthropic.com/en/docs/claude-code/common-workflows
• 当前 Claude 定价页背景信息，核对自 https://claude.com/pricing