02 - 用户级 vs 项目级：为什么分两层
一句话结论
用户级 = 你是谁（跨项目稳定）；项目级 = 这个项目是什么（每个案件/项目不同）。两者互补，不替代。
详细对比
| 维度 | 用户级 | 项目级 |
|---|---|---|
| 文件 | ~/.claude/CLAUDE.md / ~/.codex/AGENTS.md |
<项目>/AGENTS.md / <项目>/CLAUDE.md |
| 生命周期 | 长期稳定 | 每个项目一份 |
| 修改频率 | 半年/一年调整一次 | 每个新案件/项目生成一次 |
| 内容 | 角色身份 / 工作流 / 协作偏好 / 法律安全基线 / 回溯契约 | 最小项目上下文 / 受控事实入口 / 文件结构 / 回溯契约项目细化 |
| 谁负责 | 你自己 | 项目负责人 |
| 适用场景 | 全部 session 共享 | 仅该项目目录下 |
为什么必须分两层
不分两层会出两类问题：
问题 1：把项目特定信息写到用户级
例：把"我是 XX 案件的代理律师"写到 ~/.claude/CLAUDE.md。然后下次你处理 YY 案件时，agent 还会记得 XX 案件——污染。
问题 2：把跨项目稳定信息写到项目级
例：每个新项目都重新写"我是律师 / 我做合同审查 / 不要替我下结论"。重复劳动。
哪些内容放用户级
按 5 个模块（详见 references/04-modules.md）：
- M1 角色身份：你的角色、执业地域、主要业务方向
- M2 工作流与产出：你最常做的几类工作、产出文档
- M3 协作偏好：详尽 vs 简洁、批注 vs 修订、中英文
- M4 法律安全基线：权限、保密、溯源、人工裁决
- M5 回溯契约：决策、证据、期限和交付分别使用哪个权威载体
跨项目稳定的内容 → 用户级。
哪些内容放项目级
按 4 个模块：
- M6 最小项目上下文：项目代号、类型、阶段、关键时点
- M7 受控事实入口：strict/local/team、事实位置、读取和披露条件
- M8 文件结构约定：用什么目录模板、命名约定、gitignore
- M5 项目级细化：本项目特殊的回溯要求（叠加用户级总开关）
每个项目特定的内容 → 项目级。
用户级与项目级的协同
两者不是孤立的——它们有交集：
- 用户级 M5 是通用分类与选择原则，项目级 M5 绑定本项目已有权威载体
- 用户级 M1 角色身份会作为项目级 M6 项目上下文的"我方"主体
- 用户级 M2 工作流会决定项目级下一条必要问题，但不自动索取完整案件详情
agent 在项目级工作时，会同时读取两层，做综合判断。
已跑过 project-init 的项目
project-init 会生成项目级 AGENTS.md 作为项目协议。本 skill 与之互补：
project-init生成的 AGENTS.md 通常是通用项目协议（协作流程、文档体系等）- 本 skill 用受管区块补法律安全、回溯契约和受控上下文规则
- detect.sh 检测到已跑过
project-init时，本 skill 只 upsert 法律安全、回溯和受控入口，不重写其他
详见 references/15-sync-with-project-init.md。
顺序：先用户级再项目级
第一次使用建议顺序：
- 默认先用 quick 在约 5 分钟内生成用户级最小基线；需要教学时再进入 guided
- 新案件/项目先补最小项目字段；复杂团队治理再进入 team 深化
- 用户级半年/一年检查更新；项目级随项目生命结束归档
用户当前只需要项目级时可以直接处理，不强制先完成用户级；完成后再建议补跨项目稳定基线。
接下来读什么
- 怎么检测当前环境装了哪些 harness → references/03-harness-detection.md
- 8 个模块全览 → references/04-modules.md
- 与
project-init的协作细节 → references/15-sync-with-project-init.md