一、顶层设计：区分“团队共享”与“个人专属”

我们的 AI 协作框架严格区分了项目级框架（团队共享）和用户级框架（个人专属） 。

• 用户级框架 (~/)：位于个人电脑主目录下，存放个人的跨项目配置和私人工具集（如翻译指令、写周报的 agent），不提交到项目 Git 仓库 。

• 项目级框架 (./)：位于项目根目录，作为团队协作的“中央枢纽”，所有内容（除个别本地配置外）都必须提交到 Git 仓库 。

项目级框架的核心目录结构

• ./.claude/commands/：团队指令，用于封装标准操作流程（SOP），如一键代码审查 。 例如：cc-review
  
  作用：封装团队的标准操作流程（SOP）。
  价值：将“最佳实践”从口头相传或 Wiki 文档，转变为可一键执行的、永不过时的“活”指令。新人入职，只需告诉他：“审查代码？用 /cc-review。”

• ./.claude/skills/：团队技能，沉淀团队的领域知识，让 AI 更“懂行” 。例如：
  作用：沉淀团队的领域知识和专家能力。
  价值：让 AI 变得“更懂行”。它不再是通用的 AI，而是“懂我们项目的 AI”。

• ./.claude/agents/：团队专家，定义拥有独立上下文和专业技能的虚拟角色（Sub-agents） 。Claude Code使用Subagent示例：前端安全代码审查专家
  
  作用：定义团队需要的“虚拟专家”角色（Sub-agents）。
  价值：将复杂问题，拆解给拥有独立上下文和专业技能的“专家分身”处理，实现“虚拟团队”作战。

• ./.claude/hooks/：团队自动化，用于设置质量门禁和规范动作（如自动格式化代码） 。
  
  作用：自动化团队的“质量门禁”和“规范动作”。
  价值：将代码规范和质量保证，从依赖于人的自觉，转变为系统性的、强制性的自动化流程。

• ./.claude/settings.json：团队共享的全局配置和安全权限基线 。
  
  settings.json（团队共享）：这是团队的“基线配置”。里面应该定义所有成员必须统一遵守的规则，比如权限配置（permissions）、共享的 Hooks、默认的模型选择等。
  settings.local.json（个人专属，.gitignored）：这是个人“定制化”的入口。你可以在这里覆盖 settings.json 中的某些设置，比如换一个自己喜欢的主题（theme），或者为自己开启更激进的 Auto-Accept 模式，而不会影响到团队其他成员。

• ./.claude/rules：条件作用域，视情况来确定是否加载该记忆内容

          适合场景包括 CLAUDE.md 变得太长时，不同文件类型需要不同规范时 

• ./.claude/settings.local.json：个人覆盖配置（如换肤、自动接受模式），此文件需在 Git 中忽略 。

二、Demo：

例如：
问题 1：我希望团队成员都用统一的 commit message 格式。

              这是一种“能力”吗？是的，是生成规范 commit message 的能力。

              希望手动触发还是自动识别？手动触发更合适，因为不是每次对话都需要 commit。

              答案：适合用 Commands（创建一个  /commit  命令）。

问题 2：每当 Claude 要修改代码时，我想自动检查是否符合我们的安全规范。

              这是一种“能力“吗？不是，这是一种“检查机制”。

              需要在工具执行时自动检查？ 对，在 Edit 工具执行前检查。

              答案：适合用 Hooks（创建一个 pre-Edit hook）

问题 3：我想让 Claude 能够查询我们内部的知识库。

              这是一种“能力”吗？ 不完全是，这是“连接外部数据源”。

              需要连接外部系统？ 知识库是一个外部系统

              答案：适合用 MCP（创建一个知识库 MCP server）。

组合使用【自动化流程】：每当有人提交 PR，自动进行代码审查，发现问题就评论，没问题就通过。这需要组合多种技术：

1. Headless 模式在 CI 中触发
└── GitHub Actions 监听 PR 事件，调用 claude --headless

2. 调用 code-review SubAgent
└── 隔离审查任务，避免污染主流程上下文

3. SubAgent 使用 security-check Skill
└── 自动识别安全相关代码，应用专业审查规则

4. Hooks 记录审查日志
└── 每次工具调用都记录，便于审计和调试

5. 结果通过 MCP 发送到 Slack
└── 审查完成后通知相关人员