claude -p "Review this PR" 自动加载 CLAUDE.md。CI agent 和开发者本地运行 Claude 获得相同的项目上下文。不需要额外标志、环境变量或配置文件。
如果 CLAUDE.md 只包含简短的项目描述没有审查标准，CI agent 按通用最佳实践审查。如果包含明确的测试标准、安全模式和审查标准，agent 应用那些具体检查。
通用和项目专属 CI 审查之间的差异在于你在 CLAUDE.md 里放了什么。
数据
一个团队在丰富 CLAUDE.md 前后测量了 CI 审查质量：
| 阶段 | ”有用”评分 | 误报率 |
|---|---|---|
| 丰富前 | 30% | 40% |
| 加了测试标准后 | 72% | — |
| 加了安全标准后 | 85% | 12% |
CLAUDE.md 的每次充实都产出了可量化的改善。测试规范让 agent 标记缺失的测试和不正确的 fixture。安全标准让它捕获支付处理问题。误报率下降 70% 因为 agent 停止标记那些实际上是团队有意选择的做法。
两个团队，同一流水线，不同审查
两个团队共享一个 monorepo，CI 配置完全相同。团队 A 的审查稳定标记缺失的错误处理和不完整的测试。团队 B 的审查很通用。
区别：团队 A 的 CLAUDE.md 包含错误处理标准和测试覆盖标准。团队 B 的没有。同样的流水线，同一个模型——CLAUDE.md 是变量。
CI 的 CLAUDE.md 里该放什么
测试规范。 测试框架细节、fixture 模式、覆盖率期望、集成 vs 单元测试指导。没有这些，agent 无法评估测试是否充分。
审查标准。 团队认为什么是阻塞问题 vs 建议。命名的严重度等级。不同文件类型的必检项。
安全标准。 项目特定的敏感模式——支付处理规则、auth token 管理、数据清洗要求。
代码例子。 可接受和不可接受的模式。这些比文字描述更有效地定住 agent 的理解。
不放在 CI 的 CLAUDE.md 中的： 临时信息（sprint 目标、当前事故）、每次运行变化的信息（diff 上下文——那从 prompt 来）、或属于 .claude/rules/ 的 path 范围标准。
CLAUDE.md vs 动态 Wiki 注入
一个 DevOps 负责人提议在每次 CI 运行前从 wiki API 获取审查标准并作为内联上下文传入。
这增加了：
- 外部依赖 — wiki API 宕机导致所有 50 次日运行的 CI 中断
- 无版本控制 — 标准变更没有审查历史、没有回滚
- 自定义脚本 — API 的获取、缓存、错误处理
版本控制中的 CLAUDE.md 避免了全部三个。标准通过有审查的 PR 变更。它们无需网络调用始终可用。不需要自定义脚本就能加载。
Claude Code 在 -p 模式可以处理作为参数传入的内联上下文——动态方法在技术上不是不可能。它在运维上不如一个自动加载的版本控制文件。
多服务模式
五个微服务有共享安全标准和独特测试模式：
每个服务的 CLAUDE.md 包含：
- 共享安全标准（通过
@import从公共文件、或直接包含） - 服务专属测试模式和规范
每个服务的 CI agent 加载其 CLAUDE.md 自动获得两层。不需要集中注入服务、不需要标准分发的 MCP server、不需要手动复制。
新 CI 集成的第一步
在第一次 CI 运行之前就在 CLAUDE.md 中记录团队的编码标准、测试期望和审查标准。不是之后——之前。
不带项目上下文运行 claude -p 产出通用输出。迭代 prompt 参数来改善质量比先在 CLAUDE.md 中建立标准更慢且更难维护。
一句话总结： CLAUDE.md 在 CI 中和本地一样自动加载——用审查标准、测试规范和安全标准丰富它，把通用审查变成项目专属的（30% 有用 → 85% 有用）。