企业使用 Claude Code 的核心问题
个人用 Claude Code，目标是提效；企业用 Claude Code，目标是提效但不失控。 如果每个工程师都自己写 prompts、自己放开权限、自己决定要不要跑测试，短期会快，长期会留下质量、安全和审计问题。
Claude Code 官方文档已经把相关能力拆成几层：memory、subagents、hooks、settings、managed settings。 参考文档包括 memory、 subagents、 hooks 和 settings。
第一层：CLAUDE.md 写团队共识
CLAUDE.md 应该是企业 Claude Code 配置的第一块地基。它不负责“强制执行”，而负责让 Claude 知道团队希望它如何工作。
建议每个仓库至少包含：
- 项目结构：前端、后端、数据库、脚本、测试分别在哪里。
- 常用命令：安装、开发、类型检查、测试、构建、迁移。
- 代码规范：命名、错误处理、日志、状态管理、API 约定。
- 禁止事项：不要改生成文件、不要跳过测试、不要直接改生产配置。
- 上线检查：必须跑哪些命令，哪些文件改动需要额外 review。
官方 memory 文档也提到，企业可以部署组织级 CLAUDE.md，或者使用 managed settings 中的 claudeMd 下发全局行为指导。 但仓库特定规则仍建议提交到项目自己的 CLAUDE.md。
第二层：.claude/rules/ 做路径级规则
一个大仓库里，前端、后端、数据库迁移、安全逻辑不应该共享同一份笼统规则。 官方文档支持把规则放在 .claude/rules/，并用路径匹配控制何时加载。
--- paths: - "src/app/api/**/*.ts" - "src/lib/**/*.ts" --- API 和服务层规则： - 所有外部输入必须校验。 - 不要吞掉异常。 - 涉及订单、支付、权限的修改必须补测试或写明无法测试原因。
路径级规则的好处是减少噪音。Claude 不需要在改 CSS 时加载数据库迁移规范，也不需要在写 SQL 时加载按钮设计规范。
第三层：Subagents 做专业分工
Subagents 适合把团队里的专业角色标准化。例如：
- code-reviewer：只读 diff，输出阻塞问题、非阻塞建议和测试缺口。
- test-writer：读现有测试风格，补最小必要测试。
- security-reviewer：检查认证、权限、支付、文件上传、外部调用。
- migration-planner：只规划数据库迁移，不直接执行破坏性命令。
- docs-maintainer：根据代码变更更新 README、runbook 和内部文档。
官方 subagents 文档强调，subagent 的 description 会影响 Claude 何时自动委派任务。 因此 description 要写清楚触发场景，而不是只写“你是一个 reviewer”。
--- name: security-reviewer description: Use when changes touch auth, payment, order status, file upload, external webhook, admin routes, or secrets. tools: Read, Grep, Glob, Bash --- 你是安全审查 subagent。只做审查，不直接修改文件。 重点检查： 1. 权限是否可绕过 2. 外部输入是否校验 3. webhook 是否验签 4. secret 是否进入日志或前端 5. 订单、支付、退款状态是否存在竞态 输出：阻塞问题、建议问题、需要人工确认的问题。
第四层：Hooks 做强制校验
Hooks 是企业治理里最硬的一层。它不是告诉 Claude “最好这样做”，而是在特定事件上执行脚本或返回决策。 官方 hooks 文档列出了 PreToolUse、PostToolUse、SubagentStart、SubagentStop、Stop 等事件，并说明 hook 可以通过 JSON decision 阻止工具调用。
企业里最实用的 hook 有四类：
- 危险命令拦截：阻止
rm -rf、直接改生产配置、读取敏感路径。 - 质量门禁：写文件后自动跑 format / lint，结束前跑 typecheck / test。
- 审计记录：记录 Claude 调用了哪些工具、修改了哪些文件、触发了哪些 subagents。
- 发布前检查：当 Claude 准备 commit 或 push 时，强制检查分支、测试和变更范围。
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": ".claude/hooks/block-dangerous-command.sh"
}
]
}
],
"Stop": [
{
"hooks": [
{
"type": "command",
"command": "npm run typecheck && npm test",
"timeout": 120
}
]
}
]
}
}注意：Hook 太重会拖慢 Claude Code。建议把高成本检查放在 Stop 或 commit 前，不要每次 Edit 后都跑完整测试。
第五层：settings 和 managed settings 管权限
官方 settings 文档说明了配置优先级：managed settings 最高，其次是命令行参数、本地项目设置、共享项目设置、用户设置。 企业最容易踩的坑，是把强制策略放进用户可改的配置里。
| 配置层 | 适合放什么 | 是否适合强制策略 |
|---|---|---|
| User settings | 个人偏好、默认模型、显示设置 | 不适合 |
| Project settings | 团队共享 hooks、MCP、权限默认值 | 适合团队约定，不适合不可绕过策略 |
| Local settings | 个人机器上的项目覆盖 | 不适合 |
| Managed settings | IT/安全团队下发的企业策略 | 适合 |
对企业来说，权限、网络、沙箱、插件来源、敏感工具限制，应该尽量放在 managed settings 或等价的组织级策略里。
推荐落地顺序
- 先选一个非核心仓库试点 Claude Code。
- 写最小 CLAUDE.md，覆盖项目结构、命令和禁止事项。
- 加 code-reviewer 和 test-writer 两个 subagents。
- 加一个 Stop hook，只跑 typecheck 和关键测试。
- 一周后统计问题：误拦截、漏测试、耗时、开发者满意度。
- 再把规则拆到 .claude/rules/，并补 security-reviewer。
- 最后把不可绕过策略迁到 managed settings。
国内团队订阅建议
如果只是个人开发者，先用 Pro 或 Max 学会 Claude Code 的基本工作流。 如果团队要正式落地，除了订阅模型能力，还要考虑账号管理、成员权限、KYC、支付、交付和后续可用性。
ClaudeMax 的商品价格和交付方式以下单页为准。企业或多人使用场景，建议先明确团队人数、是否需要 Claude Code、是否有身份验证要求，再决定 Pro、Max 或 Team 方向。
下一步可以继续读 Hooks + Subagents 进阶教程，先把个人配置跑通，再升级到团队标准化。