企业官网建设流程全解析

Claude Code 用了半年，我把它最值钱的 12 个命令榨干了

一名 Java 后端在 5 个真实项目里，把 Claude Code 命令用成"瑞士军刀"的复盘

去年团队里一个同事离职后，我接手了一个 8 万行的 Spring Boot 老系统。从那以后，我开始重度依赖 Claude Code——不是用它"写代码"，而是用它做我一个人搞不定的代码考古、生产事故复盘、Code Review。

半年下来，我把 50 多个命令筛了一遍，留下了 12 个真正救命的。

这篇文章不讲命令清单（那个文档谁都能翻），讲的是在 Java/Spring 真实项目里，这些命令怎么组合用、踩过哪些坑、哪些命令是看起来好用实际是雷。

一、接手祖传代码：先别急着读，让 Claude 帮你"考古"

场景

一个跑了两年的 Spring Cloud 项目，目录结构混乱，common包下堆了 47 个 util 类。我需要在三天内搞清：

• 哪些类在用、哪些是僵尸
• 核心调用链长什么样
• 哪些代码动过三次以上（说明反复改，肯定有坑）

我用的命令组合

第一步：/init初始化项目记忆

# 在项目根目录/init

/init会自动扫描项目生成CLAUDE.md。但默认生成的内容对我没用——它会写"这是一个 Spring Boot 项目"这种废话。

我立刻手动覆盖，追加项目专属规则：

# CLAUDE.md ## Project Context - 电信计费领域遗留系统，2023年起逐步重构中 - 老模块用 dubbo + xml 配置，新模块用 spring cloud alibaba - 数据库：MySQL 8.0 + 几张历史遗留的 Oracle 11g 表 ## Code Conventions - 业务异常统一抛 BizException，错误码 6 位数字 - 日志必须带 traceId，格式: [traceId={}] xxx - 禁止在 Controller 层直接写 SQL - 所有对外接口必须有 @ApiOperation 注解 ## Domain Knowledge - 用户编号规则：前 2 位省份 + 中间 8 位时间戳 + 后 4 位序列 - 计费周期：自然月，月初 1 号 0 点跑批 - 金额一律用 BigDecimal，保留 4 位小数

这一段写完，后面所有会话都不用再重复解释项目背景。半年后新来的同事接手时，直接 clone 就能用。

💡踩坑警告：/init生成的内容别直接用。它扫描出来的是"字面结构"，不是"业务含义"。必须人工补业务规则。

第二步：/agents建一个"代码考古"专属子 Agent

/agents# 然后输入：@agent-create code-archaeologist"专门用于分析遗留代码。任务：1) 识别类之间的依赖关系 2) 标记可疑代码（高复杂度 + 低注释 + 多次修改）3) 输出调用链 mermaid 图。禁止修改任何文件。"

子 Agent 在隔离的上下文里跑，不污染主对话。考古跑完了，结果粘回来用。

二、生产事故半夜叫起来：调试会话的"防爆"操作

场景

凌晨 2 点，告警群炸了——订单服务超时。代码三个月前写的，里面混了 Feign 调用、Redis 缓存、数据库事务。我需要一个干净的环境复现，但不能把生产数据喂给 Claude。

我的工作流

第一步：先/clear还是先/compact？

这是关键决策点。

我那次选了/clear。凌晨大脑不清醒，简洁的上下文比"完整历史"更救命。

第二步：用--append-system-prompt限制 Claude 行为

claude --append-system-prompt"当前任务：生产环境事故复盘。规则：1) 不修改任何代码 2) 不执行 SQL 3) 不调用任何会写入的 HTTP 接口 4) 所有建议必须先在本地 dry-run 5) 涉及金额的查询必须脱敏"

为什么不直接用--system-prompt？

--system-prompt会完全替换Claude Code 的默认指令，包括内置的安全检查和行为约束。看起来"更干净"，实际你失去了所有的护栏。永远优先用--append-system-prompt。

第三步：让 Claude 自己监控上下文

/context# 输出示例：# Context usage: 67% (134,400 / 200,000 tokens)

在调试长链路问题时，我设了个习惯：每解决一个子问题就跑一次/context。看到 70% 立刻/compact，别等 90%——90% 的时候 Claude 已经记不清两小时前的栈帧了。

# 关键参数：定向压缩/compact retain the Feign call chain and Redis cache keys

/compact默认会无差别压缩。加retain参数告诉它保留什么，否则你两小时前标记的关键调用链会被一起压掉。

三、批量生成样板代码：/fast模式的双刃剑

场景

新模块要写 30 个 CRUD 接口。按以前的做法，两天。开了 Fast Mode 之后，两小时。

/fast

但是，Fast Mode 真的只是"快一点"吗？

官方说 Fast Mode 跑的是同一个 Opus 4.6，只是调整了 API 配置。但我实测下来发现两个问题：

1. 会话中途开启，历史上下文按 Fast Mode 费率重新计费。一个跑了一小时 Sonnet 的会话开 Fast，等于前面一小时按 Opus 价格补差价
2. 生成质量略降。Fast Mode 下，Claude 倾向于"先给你一个能跑的版本"，少了反问和澄清

我的策略：

• 启动会话时就开/fast（不要中途开）
• 写样板代码、生成测试用例、写文档——这些任务用 Fast
• 架构决策、调复杂 bug、写生产核心链路——关 Fast，用普通 Opus

/cost是控制预算的命脉：

/cost# Session cost: $2.47# Input tokens: 48,392# Output tokens: 12,847

我给自己定了一条规矩：单次会话费用超过 5 刀必须停一停，review 一下是不是有低效调用。几次事故之后我才发现，反复让 Claude 读同一个大文件是吞金兽。

四、Code Review：用/simplify替代我自己的眼睛

场景

PR 提了 800 行变更，自己 review 容易犯困。让 Claude 帮我先扫一遍。

/simplify

/simplify是个多 Agent 并行的审查器。它会启动三个 Agent：

• 代码质量Agent：命名、重复代码、复杂度
• 安全漏洞Agent：SQL 注入、权限绕过、敏感信息泄露
• 最佳实践Agent：Spring 规范、异常处理、事务边界

实话说，Claude 找出来的 bug 比我多。我有一次被它标红一个Long转int的强转（用户 ID 超过 int 范围），这种 bug 人眼 review 根本注意不到。

但是——/simplify不是/review。

/review在 2026 年 3 月被官方弃用了。我看腾讯云那篇《Claude Code 命令体系解析》还把/review写出来，这其实是过时信息——新版本里就是/simplify。

踩坑警告：/simplify会读你项目里所有相关文件做上下文关联。在一个 8 万行项目里跑一次，可能 30 秒到 1 分钟。耐心等，别中途/clear。

五、CI/CD 流水线：--print的隐藏价值

场景

我需要个 GitLab CI 任务，PR 提了之后自动让 Claude 看看代码 diff 给出建议。

关键命令：claude --print

claude--print"Review the following diff and output critical issues in JSON format:$(gitdifforigin/main...HEAD)"

--print是一次性查询，问完就退出，不进交互。这正好契合 CI 的本质：每个任务都是独立的、不需要历史。

我写了个脚本塞进.gitlab-ci.yml：

claude-review:stage:reviewscript:-git fetch origin main-claude --print "你是一个严格的 Java Code Reviewer。审查以下 diff，重点关注：1) 并发安全 2) 资源泄漏 3) 事务边界 4) N+1 查询。输出 markdown 格式的 review 报告。Diff:$(git diff origin/main...HEAD)">claude-review.mdartifacts:paths:-claude-review.mdonly:-merge_requests

注意：--print在 CI 里跑必须设两个东西：

1. ANTHROPIC_API_KEY环境变量（用 GitLab CI 的 masked variable）
2. --dangerously-skip-permissions标志——CI 环境没人交互，必须跳过权限确认

--dangerously-skip-permissions这个名字看着吓人，但在隔离的 CI 容器里是安全的。它跳过的只是"是否执行这个命令"的交互提示，不是安全检查。

六、5 个我最后没用上的命令（避坑清单）

七、写在最后：命令只是皮，思维是骨

半年用下来，我最大的感悟是：Claude Code 的价值不在于"知道多少命令"，而在于"在什么场景用哪个"。

同样的/compact，在调试生产事故时是救命，在写新功能时是添乱。同样的/fast，写样板代码时是神器，写架构决策时是负担。

命令可以查文档，但对项目的判断力查不到。