Claude Code 最新攻略：Opus 4.8、Dynamic Workflows、Auto Mode 怎么用？
Claude Code 最近更新很密集：Opus 4.8、dynamic workflows、auto mode、agent view、/goal、/usage、/code-review 与 security-guidance plugin 都改变了实战打法。这篇用一套可复制的流程说清楚怎么用。
截至 2026-06-01，Claude Code 已经不只是「开终端让 AI 写代码」。它更像一套 agentic engineering 的小型操作系统：模型选择、effort、背景 sessions、workflows、plugins、review commands、usage 诊断，都会影响实际效果。
这篇把近期官方更新整理成一套可执行打法。主要来源是 Claude Code changelog、 5 月 25-29 日更新、 best practices、permission mode 文档，以及 dynamic workflows 官方博客。
1. 先升级，再选对模型
第一步很无聊，但很重要：先升级并确认版本。5 月底这些功能依赖近期 2.1.x 版本，Opus 4.8 支持至少需要 v2.1.154。
claude update
claude --version
claude
认真做 coding task 时，先切到 Opus 4.8。Week 22 更新说明提到，Opus 4.8 已成为多个 Claude 方案与 Anthropic
API 的默认模型，默认 high effort，困难任务可以用 /effort xhigh。
> /model claude-opus-4-8
> /effort xhigh /fast 只适合等待时间本身很贵的场景。最新 fast mode 已默认转到 Opus 4.8，价格是
$10/M input、$50/M output，约为标准价格 2 倍，换约 2.5 倍速度。它适合
live debugging、互动式 code review，不适合默认为离线批处理打开。
2. 把工作切成三种模式
Claude Code 的任务可以先分三类。小型、可逆修改，普通 session 加测试即可。中型任务要有书面计划、明确验证命令，必要时用
/goal。大型跨 repo 任务，才考虑 background agents 或 dynamic workflows。
| 工作类型 | 建议工具 | 原因 |
|---|---|---|
| 小修复 | 普通 session + tests | 最快，也最容易人工检查。 |
| 中型 feature | Plan + /goal | 让 Claude 持续工作，直到通过可验证条件。 |
| 审计、迁移、研究 | claude agents 或 workflow | 并行调查，避免主 context 被日志和搜索结果塞满。 |
Anthropic 的 best practices 也强调同一件事：给 Claude 一个可以验证结果的方式，先探索再计划再写代码，并且积极管理 context。实际 prompt 里应该写清楚目标、限制、要看的文件或命令，以及最终验证命令。
3. Dynamic workflows 用在大任务
Dynamic workflows 是近期最大更新。Claude 会为任务写 orchestration script，把工作分发给多个 subagents，检查结果后汇总成一个答案。 Anthropic 把它定位在 codebase-wide audit、大型迁移、大型研究问题，以及需要独立复核的工作。
> create a workflow that audits every payment path for missing idempotency checks
> /workflows触发方式很明确：当任务大到一个 conversation 协调不住，就在 prompt 里写 workflow。官方公告也提醒，workflows 可能跑数小时到数天， 而且 usage 明显高于普通 Claude Code session，所以第一次要从小范围开始。适合的例子包括：
- 把所有内部
fetch()调用迁移到新的 HTTP client - 审计所有 route handler 是否缺少 auth check
- 比较三种重构方案，并让 adversarial agents 尝试击穿每个方案
- 在大型 repo 里找 dead code，并要求每个候选都先验证再回报
不要把 workflow 用在小修复。它的协调成本和 token 成本本来就高，买的是广度、独立检查和长时间执行能力。
4. Auto mode 与安全边界
Auto mode 会减少 permission prompts，把动作交给 classifier 判断，阻挡破坏性、可疑或超出范围的操作。它适合可信的开发工作， 尤其适合长任务，但仍然是 research preview，不应该取代人工 review、secrets 检查、deploy 审核或 migration 审核。
# Interactive session 里用 Shift+Tab 切换模式。
# Trusted infrastructure 放在 user settings，不放进 repo shared settings。
> /permissions
> /status
Permission docs 写明，auto mode 默认信任 working directory 和 repo remotes；production deploy、force push、大量删除、
外部数据传输等动作默认会被挡下，除非你明确配置。5 月 30 日 changelog 还提到，Bedrock、Vertex、Foundry 上的 Opus 4.7
和 Opus 4.8 可通过 CLAUDE_CODE_ENABLE_AUTO_MODE=1 opt in。若你本机表现不同，以 /status
和最新 changelog 为准。
实用规则：任务开始前，用自然语言写边界。例如「不要 push、不要 deploy、不要改 billing code，测试通过就停」。真正的组织硬规则， 应该写进 managed settings 的 deny rules，而不是只依赖对话上下文。
5. 用 plugins、review、usage 控成本
新打法不是「让 agent 跑更久」这么简单。越长的 run 越需要护栏。只要 Claude 会改重要代码，就建议安装官方 security-guidance plugin。它会检查代码修改中的漏洞，并在 commit 或 push 周期做更深的 review。
> /plugin install security-guidance@claude-plugins-official
> /reload-plugins
然后配合 review commands。想找 correctness bugs，用 /code-review high；想清理重复、简化结构、提升可读性，
用 /simplify。最近更新后，这两个命令的角色已经分开，不要混用。
> /code-review high
> /simplify
> /usage /usage 很重要，因为 Claude Code 成本已经不只是一段 chat。费用可能来自 subagents、skills、plugins、MCP servers、
cache misses、long context、fast mode 和 workflows。长任务结束后先看 usage，再决定要不要把这个流程变成团队默认。
6. 一套可复制的实战流程
如果是实际 repo，我会这样跑：
- 升级 Claude Code，进入 repo，跑
/status。 - 切到
claude-opus-4-8；只有困难规划或高风险修改才用/effort xhigh。 - 先让 Claude 探索，并列出它看到的文件、命令和风险。
- 要求它写计划，并指定唯一验证命令，例如
npm test、pytest或 build。 - 中型任务设置
/goal tests pass and build is clean。 - 大型任务要求 workflow，但确认 scope 后再让它 fan out。
- 最后跑
/code-review high，再跑/simplify，然后自己检查 diff。 - 收尾看
/usage，判断这套成本是否值得常态化。
核心心态很简单：Claude Code 最适合被当成一个初级工程团队来管理，而不是 autocomplete。给它上下文、隔离环境、 可衡量的完成条件和 review gate。最近更新让这套模式更强，但也让成本与安全边界更重要。