title: " Claude Code目录工程化 | 4SAPI团队模板" category: 人工智能 tags:
- 大模型API中转站
- Claude Code
- 4SAPI
- .claude
- 工程化
- Hooks
- Skills
- Subagents description: "基于 Claude Code 官方 .claude 目录、CLAUDE.md、settings、rules、hooks、commands、skills、subagents 文档,整理一套适合 4SAPI 大模型 API 中转站项目的团队级目录模板,让 Claude Code 更可控、更可维护、更适合真实工程协作。"
很多人已经开始用 Claude Code 写代码。
但大多数人的用法还停留在:
小项目这样可以。
一旦项目变大,问题就会出现:
- 指令越写越长
- 规则散落在聊天记录里
- 测试命令每次都要重复说
- API Key 安全规则没人记得
- hooks 和 commands 混在一起
- skills、agents 建了一堆但没人知道什么时候用
- 团队成员各自有一套偏好,Claude 输出越来越不稳定
这时候你会发现:
尤其是做 4SAPI 这类大模型 API 中转站接入项目时,目录结构更重要。
因为这类项目天然涉及:
- 多模型 provider
- base_url 和 API Key
- 成本统计
- 日志脱敏
- fallback
- 计费和权限
- 前后端联调
- 自动化测试
- 安全审计
如果 .claude/ 目录乱,Claude Code 很容易把该放在 CLAUDE.md 的规则写进 hook,把该做成 skill 的流程塞进长提示词,把个人偏好提交进团队仓库。
这篇就讲一套更工程化的 .claude/ 目录组织方法。
目标不是炫技。
目标是让 Claude Code 在真实项目里:
1. 为什么 .claude/ 结构会影响 Claude Code 质量?
Claude Code 官方文档里有一个关键点:
这意味着它不是只看你当前这一句 prompt。
它还会看项目里的长期说明、配置、规则和扩展能力。
如果这些东西组织得好,Claude Code 会更像一个熟悉项目的工程师。
如果这些东西组织得乱,它就会像一个拿到十几份互相冲突说明书的新同事。
典型混乱包括:
CLAUDE.md写了 2000 行,什么都塞进去settings.json里既有团队规则,又有个人偏好- hooks 里做了需要模型判断的事
- commands 里放了应该自动执行的检查
- skills 和 commands 重复
- agents 没有明确角色
- 本地覆盖文件被提交进 Git
- API Key、
.env、日志文件没有 deny 规则
所以 .claude/ 的核心不是“多建几个目录”。
而是把不同类型的上下文分层。
2. 推荐目录结构:给 4SAPI 项目用的版本
如果你的项目要接入 4SAPI,推荐从这个结构开始:
这不是让你一上来全建满。
这是最终蓝图。
刚开始只需要:
等项目变复杂,再逐步加:
3. 第一层:CLAUDE.md 只写每次都要知道的事
CLAUDE.md 是项目说明书。
官方文档说明,Claude Code 会读取工作目录及其父目录中的 CLAUDE.md,CLAUDE.local.md 也会一起加载。更靠近当前目录的说明通常更具体。
所以 CLAUDE.md 要轻。
不要把所有细节都塞进去。
适合放:
- 项目是什么
- 技术栈是什么
- 启动、测试、构建命令
- 目录结构
- 核心业务边界
- 最重要的安全规则
- 如何处理 4SAPI / LLM provider
示例:
这份文件应该让 Claude Code 一分钟内知道项目怎么工作。
不是让它读一篇公司史。
4. CLAUDE.local.md:个人偏好不要污染团队规则
很多人会把个人习惯写进项目 CLAUDE.md:
这些不是团队规则。
应该放进 CLAUDE.local.md。
示例:
这个文件要加入 .gitignore:
判断标准很简单:
5. 第二层:.claude/settings.json 负责控制,不负责解释
CLAUDE.md 是引导层。
.claude/settings.json 是控制层。
官方 settings 文档里给过典型例子:可以用 permissions.allow 和 permissions.deny 控制工具、命令和文件访问,例如允许 npm run test,拒绝读取 .env 或 secrets。
对 4SAPI 项目,建议从安全控制开始。
示例:
这类配置特别适合模型中转站项目。
因为项目里很容易出现:
- 4SAPI Key
- 上游模型 Key
- 生产配置
- 计费配置
- 客户数据
Claude Code 可以帮你写代码,但不应该随便读 secrets。
6. 第三层:rules/ 放模块化指令
当 CLAUDE.md 越写越长,就该拆 rules/。
Claude Code 官方文档也建议大项目用 .claude/rules/ 组织多文件规则,并且可以按路径或文件类型让规则更有针对性,减少上下文噪音。
推荐:
llm-gateway.md
security.md
testing.md
前端聊天页面改动后运行:
测试里不要调用真实 4SAPI Key,使用 mock 或测试 Key。
7. 第四层:hooks/ 放自动执行的硬规则
hooks 和 commands 最大区别:
Claude Code 官方 hooks 文档说明,hooks 可以在会话生命周期、用户提交 prompt、工具调用前后、停止前等事件触发,用于阻止危险操作、运行检查、发送通知或做自动化。
对 4SAPI 项目,hooks 很适合做安全护栏。
block-secret-reads.sh
remind-tests-before-stop.sh
示例 settings 片段:
注意:
hooks 适合机械规则。
不适合复杂判断。
比如“禁止读取 .env”适合 hook。
“这个架构是不是优雅”不适合 hook。
8. 第五层:commands/ 放轻量可复用工作流
Claude Code 新文档里提到,自定义 commands 已经和 skills 合流,但旧的 .claude/commands/ 文件仍然可用。
所以你可以继续把轻量任务放在 commands。
适合:
- PR 审查
- 生成变更摘要
- 运行 4SAPI smoke test
- 检查 provider 配置
- 总结成本风险
review-llm-provider.md
test-4sapi-smoke.md
commands 的价值是:
不要让每个人都手写一套“帮我审查一下 provider”。
9. 第六层:skills/ 放完整能力包
skills 比 commands 更重。
Claude Code 官方文档说得很清楚:当你反复粘贴同一套说明、清单或多步流程时,就该做 skill。Skill 的正文只有在使用时才加载,长参考材料平时几乎不消耗上下文。
适合做 skill 的任务:
- 4SAPI provider 迁移
- AI 成本审计
- 日志脱敏检查
- 多模型路由设计
- 发布前 LLM 接入检查
skills/4sapi-provider-migration/SKILL.md
skills/ai-cost-audit/SKILL.md
skills 的关键是“完整工作流”。
如果一个文件就能说清楚,用 command。
如果需要多步、配套文档、检查清单,用 skill。
10. 第七层:agents/ 放专用角色
subagent 适合做专门角色。
官方扩展文档里也把 skill 和 subagent 区分开:skill 是可复用内容,subagent 是隔离运行的 worker。
适合:
- 安全审计员
- LLM provider reviewer
- 文档作者
- 测试工程师
- 成本分析员
agents/security-auditor.md
agents/llm-provider-reviewer.md
agents 不要乱建。
如果两个 agent 角色高度重叠,合并。
如果一个 agent 很少用,删除。
11. 项目级 vs 用户级:哪些该提交,哪些不该提交?
官方 .claude 目录文档强调:
建议:
| 内容 | 放哪里 | 是否提交 |
|---|---|---|
| 项目架构说明 | CLAUDE.md | 是 |
| 团队测试命令 | CLAUDE.md / rules/testing.md | 是 |
| 4SAPI provider 规则 | rules/llm-gateway.md | 是 |
| 安全 hooks | .claude/hooks/ | 是 |
| 个人语言偏好 | CLAUDE.local.md | 否 |
| 个人本地端口 | CLAUDE.local.md | 否 |
| 个人全局 skill | ~/.claude/skills/ | 否 |
| 团队共用 skill | .claude/skills/ | 是 |
| 团队共用 agent | .claude/agents/ | 是 |
| 私人实验 agent | ~/.claude/agents/ | 否 |
判断标准:
12. 4SAPI 项目的渐进式成长路径
不要一上来就把 .claude/ 填满。
推荐路线:
阶段一:最小可用
解决:
- 项目说明
- 常用命令
- 基础权限
- 不读取 secrets
阶段二:规则模块化
解决:
- 前端规则
- 后端规则
- 4SAPI provider 规则
- 测试规则
- 安全规则
阶段三:自动化护栏
解决:
- 阻止危险命令
- 阻止读取 secret
- 停止前提醒测试
- 关键文件改动后提醒审查
阶段四:复用工作流
解决:
- PR 审查
- provider 迁移
- 成本审计
- 发布前检查
阶段五:专用子代理
解决:
- 安全审计
- 文档写作
- LLM provider 审查
- 测试补齐
这条路的核心是:
13. 和 4SAPI 的结合点
为什么这篇要放在大模型 API 中转站系列?
因为 Claude Code 工程化目录,不只是“写代码更舒服”。
它可以直接提升 4SAPI 接入项目的稳定性。
结合点一:统一 provider 规则
rules/llm-gateway.md 规定所有模型调用必须经过 provider 层。
这样不会出现:
- 某个页面直连 OpenAI
- 某个脚本直连 Claude
- 某个后台直连 Gemini
- 只有一部分流量走 4SAPI
结合点二:阻止 Key 泄露
settings.json 和 hooks 阻止读取 .env、输出 Key、把 Key 写进测试。
结合点三:成本审计 skill
ai-cost-audit skill 可以定期检查:
- 是否所有任务都用最贵模型
- 是否缺少 token 统计
- 是否重试过多
- 是否有 fallback 成本
结合点四:provider review agent
llm-provider-reviewer 可以专门审查:
- base_url 是否可配置
- 4SAPI endpoint 是否统一
- 错误处理是否完整
.env.example是否更新- 文档是否同步
这些都能把 4SAPI 从“一个 API 地址”升级成“项目级模型治理层”。
14. 常见错误
错误一:CLAUDE.md 变成垃圾桶
所有内容都塞进去,最后谁也读不懂。
正确做法:
错误二:hooks 做复杂判断
hooks 应该做确定性动作。
不要让 hooks 承担架构判断。
错误三:commands 和 skills 重复
一个任务如果只有一个 prompt,用 command。
如果有多步流程和配套文档,用 skill。
错误四:agents 建太多
每个 agent 都应该有明确角色。
不要建一堆听起来高级但很少使用的 agent。
错误五:个人配置提交进仓库
CLAUDE.local.md、settings.local.json 必须进 .gitignore。
错误六:没有清理废弃文件
每月检查一次:
- 哪些 command 没人用
- 哪些 skill 重复
- 哪些 agent 角色重叠
- 哪些 hooks 已经过时
.claude/ 本身也需要维护。
15. 团队落地清单
你可以直接复制这张 checklist:
如果这 12 条都做到,Claude Code 在团队项目里会稳定很多。
16. 最后总结
.claude/ 目录不是装饰品。
它是 Claude Code 的项目操作系统。
好的结构应该能回答这些问题:
- 项目级指令在哪里?
- 个人偏好在哪里?
- 模块化规则在哪里?
- 自动化安全护栏在哪里?
- 可复用工作流在哪里?
- 完整能力包在哪里?
- 专用子代理在哪里?
- 哪些文件该提交,哪些不该提交?
对 4SAPI 这类大模型 API 中转站项目来说,.claude/ 还能进一步解决:
- API Key 安全
- provider 统一
- 日志脱敏
- 成本审计
- fallback 检查
- 团队协作一致性
一句话总结:
如果你正在用 Claude Code 接入 4sapi.com,建议先从这两个文件开始:
然后按需增加:
这样 Claude Code 才会从“能写代码的助手”,变成“能在团队工程里稳定交付的协作系统”。




