团队一起用 Claude Code 的几条实践：额度、规则文件与协作纪律
数据截至 2026-07，价格与限额以各官网为准。
团队用 Claude Code，最容易被低估的一件事是：额度是绑在每个人账号上的，不是绑在项目上的；而真正能在团队里共享、并且值得花力气维护的，是提交进版本库的那几个配置文件。把这两件事想反了，就会出现”某个人一到下午就跑不动、另一个人额度天天用不完”，同时每个人的 AI 又各自按各自的理解改代码。
常见的误解是把 Claude Code 当成一个”团队工具”来规划——先讨论谁来管、怎么分配、要不要设个管理员统一调度。实际用起来会发现，日常使用的粒度就是”一个人、一个终端、一个仓库目录”，协作层面能沉淀的东西很有限，但恰恰是这有限的几样东西决定了团队产出的一致性。下面按团队真正会撞上的顺序讲。
一、先弄明白额度是怎么算的，再谈怎么分工
Claude Code 在订阅计划下的用量由两层限制构成，官方帮助中心对结构的描述是清楚的：
- 5 小时滚动窗：限制一个时间窗内能发多少 prompt。关键点在于计时从你发出第一条 prompt 开始，而不是按整点时钟。也就是说 10:00 发出第一条，15:00 就重置，中间发了多少条都不改变重置时刻。
- 周限额：官方帮助中心的说法是按账户被分配的固定时刻每周重置，重置日和时刻不随你什么时候开始用、什么时候订阅而变化，每个周期给满额度。
这两层叠在一起，对团队排班的影响是实打实的。既然 5 小时窗从第一条 prompt 起算，那”上午随手问一句、下午才开始正经干活”就很吃亏——那一句闲聊已经把窗口点着了，等你真正需要连续推进时，窗口可能只剩一个多小时。团队里可以约定一个很朴素的习惯：当天第一条 prompt 尽量留给真正要做的那件事，零碎的小问题攒到窗口已经开着的时候再问。
至于每个窗能发多少条，第三方汇总口径是 Pro 每窗大约 10 到 45 条 prompt、Max 20x 最高约 900 条，但这只是第三方的汇总，实际条数取决于 prompt 长度、上下文大小和所选模型，官方给的本来就是区间而不是定值。具体以官方页面和你账户里实际显示的为准，不要拿这组数字去做排班表的计算依据。
二、别把”周限额到底多久重置”写进任何自动化脚本
这里有一个必须诚实说明的矛盾。一份流传较广的 GitHub gist（作者 monperrus）在 2026-06-09 到 06-20 大约 11 天里持续监测 utilization 字段，得出的结论是”周限额”实际每 72 小时重置一次，而不是每 7 天；该 gist 的评论区还显示，不同账号、不同档位观察到的重置日差异很大。
这是第三方实测与官方文档表述不一致的地方，不能当作官方事实来引用。但对团队来说，这条信息的价值不在于”到底是 72 小时还是 7 天”，而在于结论：不要把任何假定的周期长度写进自动化脚本或排班规则。有些团队会想做个小工具，按”每周一早上额度重置”来自动排任务、自动发提醒，一旦真实重置节奏和假设对不上，这个工具就会持续地误导所有人。稳妥做法是让脚本去读实际状态，而不是靠算日期推断。
三、真正能共享的是提交进版本库的那几个文件
个人账号、个人额度、个人上下文，这些都没法共享。团队里能沉淀下来、并且值得投入维护成本的，是随仓库走的那几样配置：
- CLAUDE.md：项目规则文件，写清技术栈、目录约定、命令怎么跑、什么能改什么不能碰。它的价值不在于写得多全，而在于它是团队里唯一一份所有人的 AI 都会读到的说明。写法可以参考 CLAUDE.md 怎么写？给 AI 立项目规则。
- 自定义斜杠命令：把团队反复要做的动作（比如”按我们的规范写一次提交信息""跑一遍上线前检查”）固化成命令，新人第一天就能用对姿势。参见 Claude Code 自定义 Slash Command 怎么写。
- Hooks：在工具调用前后插自动化，比如提交前强制跑格式化和 lint、拦掉危险命令。这一层是团队质量门里最省心的部分，因为它不依赖任何人的自觉。做法见 Claude Code Hooks 实战。
- Subagent 定义：把”评审""查文档""写测试”这类角色固定下来，团队成员用的是同一套角色定义而不是各自临场发挥的提示词。见 Claude Code 自定义 Subagent 怎么写。
这四样都在版本库里，改动会走代码评审，这一点很重要——规则文件也应该被评审。见过不少团队把 CLAUDE.md 当成随手改的草稿，结果某个人加了一条”所有新文件都放 src/legacy”，两周后没人记得为什么，也没人敢删。
四、并行开工要有边界，尤其是子代理
多人同时在一个仓库上让 AI 改代码，冲突不是”可能发生”而是”一定发生”。相对稳妥的做法是每人各占一个隔离工作区，具体做法可以参考 Claude Code 配 git worktree 并行多开实战。这样每个人的分支、依赖、构建产物互不干扰，AI 也不会在另一个人正在改的文件上动手。
还有一件和额度直接相关的事值得提醒。2026 年 6 月，Anthropic 为全部 Pro 和 Max 用户做过一次一次性的 5 小时与周限额重置，官方给出的原因是修复了”某些 Claude Code 会话会派生过多并行子代理、比预期更快烧掉用量”的问题。这件事本身已经修了，但它暴露的道理仍然成立：并行的子代理是要花额度的，而且花得比直觉快。团队里如果有人写了一个动辄拉起十几个子代理的工作流，他大概率会是全组第一个撞上限额的人。让子代理数量成为一个需要说明理由的选择，而不是默认动作。
五、撞上限额之后，有用的路径就那么几条
先说一条最需要提前告诉所有人的：客服无法实时手动为你重置或延长配额。很多人撞到上限的第一反应是去找客服申诉，这条路走不通，白白浪费半小时。
实际可用的做法是：
- 用
/status命令查看剩余额度。这是能实时看到自己还剩多少的入口，团队里应该把它变成一个习惯性动作——在开始一个大任务前先看一眼，而不是跑到一半被打断才想起来。更细的读法见 用 /status 管住 Claude Code 的用量。 - 开启 usage credits，在超出包含额度之后继续用。
- 改走 Claude Console 账号的按量付费方式。
- 升级订阅档位。
顺带说一句背景：2026-05-06 Anthropic 宣布永久把 Claude Code 的 5 小时限额翻倍（覆盖 Pro、Max、Team 以及按席位的 Enterprise），同时取消了此前对 Pro 和 Max 的高峰时段限额缩减，Opus 的 API 限额也大幅上调；官方公告把这次调整归因于新增算力上线。这说明限额规则本身是会变的，团队内部如果写了什么”额度使用手册”，记得留一句”以官方页面当前说明为准”，别让一份两个月前的文档变成新人的错误认知来源。撞限额时的完整判断思路，另见 Claude Code 撞到用量限制怎么办。
六、协作纪律：评审的对象是 diff，不是提示词
团队引入 AI 编程之后，代码评审很容易走形。一种常见走形是评审时开始讨论”你这个提示词写得对不对”；另一种是因为知道代码是 AI 写的，评审反而更松——“反正它比我细心”。
比较务实的做法是把评审对象钉死在 diff 上，和人写的代码一视同仁：这段改动解决了什么问题、有没有测试、有没有动到不该动的文件、有没有引入新依赖。至于它是 AI 写的还是人写的，在评审这一刻不重要。提示词该不该改是另一个话题，属于工具改进，可以单独提，但不要占用评审时间。
另外建议团队约定：AI 生成的大规模改动要拆开提交。一次几十个文件的改动，无论是谁写的都没法认真评审；拆成按主题的小提交，评审才有可能是真的评审而不是走个流程。
七、有个前提必须提前讲明白
Anthropic 官方公布的受支持国家/地区列表不含中国大陆（anthropic.com/supported-countries），注册、控制台和 API 端点都在境外。团队做技术选型时，这一点应该在第一次会上就说清楚，而不是等到有人已经把工作流搭了一半才发现。准入政策会调整，具体以官网当前的地区政策页为准。
客观地说，市面上存在第三方中转类服务，但其合规性、稳定性与数据安全风险需要使用者自行判断和承担，本文不提供也不背书任何具体渠道。
说说局限
上面这些做法解决的是”别互相踩、别莫名其妙没额度”这类协作摩擦，它们不解决更根本的问题：AI 写出来的代码质量，最终仍然取决于团队自己对系统的理解程度。一个连自己的模块边界都说不清的团队，写再详细的 CLAUDE.md 也只是把混乱描述得更清楚了一点。
另外，本文引用的限额结构和调整记录都来自公开的官方说明与第三方观察，规则本身在持续变化，团队内部的约定不宜写得太死，留出”以官网当前说明为准”的余地。
小结
额度是按人算的，5 小时窗从第一条 prompt 起算，所以当天的第一句话最好留给正事。团队里真正能共享的是进版本库的那几个文件——规则文件、斜杠命令、hooks、子代理定义，它们也应该走评审。并行开工用隔离工作区，子代理数量当成一个需要理由的选择。撞了限额别找客服，先 /status 看清楚再决定用哪条路。最后，准入前提要在选型第一天就摆到桌面上。