Claude Code 团队入职：先把规范写进仓库

当团队使用 Claude Code 时，每位新开发者入职，都意味着两位新成员加入：开发者本人，以及他的 Agent。开发者有几周时间熟悉团队的工作方式，而他的 Agent 第一天就开始写代码，它所知道的一切，都来自仓库里的说明。

如果团队把工作方式写在 Agent 会读取的地方，入职就会更快；否则，反而会更慢：新人的首批 PR 很快就提交了，看起来也像那么回事，却忽略了团队一半的约定。

下面这份一天入职计划，可以让开发者和他的 Agent 都做好准备。

入职前：让仓库把自己说明白

大部分准备工作都应该在新开发者到来之前完成。检查仓库中是否具备以下三样东西。

根目录下共享的 CLAUDE.md。 Claude Code 会在每次会话开始时自动读取它。里面应该包含常用命令（安装、运行、测试、lint）、目录结构、可供模仿的参考实现、各个模块的负责人，以及团队确实会执行的几条规则。如果你还没有这样的文件，可以从我们的团队 CLAUDE.md 模板开始。

提交到版本控制的 .claude/settings.json。 共享权限就放在这里：哪些命令 Claude Code 可以直接运行，无须询问；哪些命令绝对不能运行。把它提交到版本控制，意味着新人的 Agent 从一开始就和其他人的 Agent 遵守相同的限制，而不是取决于新人在头一个小时里随手点了哪些授权。

在规则不同的目录中放置目录级 CLAUDE.md。 如果支付服务或数据流水线有自己的约定，就在对应目录里放一个 CLAUDE.md。Claude Code 在该目录中工作时会读取它，根目录的文件也就能保持简短。

可以做个快速测试：找一位从没见过这个仓库的人，让他打开 Claude Code，问一句：“怎样只运行某个文件的测试？”如果回答不对，新人的 Agent 也会答错。

上午：配置开发环境和个人设置

1. 安装并登录。 安装 Claude Code，登录，然后克隆仓库。从仓库根目录启动一次，让它读取共享文件。

2. 一起阅读共享的 CLAUDE.md。 花 20 分钟，和新开发者一起读一遍。这是你手头最快了解代码库的方式，也是他的 Agent 开展工作时会依据的上下文。凡是新人觉得困惑的地方，Agent 很可能也会困惑，所以当场把它改清楚。

3. 配置个人设置。 个人偏好应该放在开发者自己的 ~/.claude/CLAUDE.md 中，而不是共享文件里，比如希望回答有多详细、编辑器使用习惯、希望用哪种语言解释。个人权限调整放在 .claude/settings.local.json 中，这个文件不纳入版本控制。第一天就把两者的界限讲清楚，避免为了适应某个人而修改团队规则。

4. 介绍团队的命令。 如果团队在 .claude/commands/ 中维护了自定义斜杠命令，比如 /review 或 /new-endpoint，就带新人过一遍。这些命令就是团队工作习惯的可执行版本。

中午：有人陪同的第一个任务

挑一个小而真实、完成标准明确的任务：可以是一个有复现步骤的 bug，也可以是一个遵循现有模式的小型接口。不要用练习性质的玩具任务，也不要选涉及多个团队职责的任务。

让新开发者用 Claude Code 完成它，旁边安排一位队友观察 30 分钟。重点不在代码，而在于观察 Agent 在你的仓库里如何行动：

• 它有没有遵循参考实现，还是自己发明了一套结构？
• 它第一次就运行了正确的测试命令吗？
• 它有没有把修改范围限制在任务所需的文件内？
• 在规则要求先询问的地方，比如 schema 变更、身份验证、计费，它有没有停下来询问？

每一个“没有”，都意味着共享文件存在缺口，而不是新人犯了错。把这些问题记下来。

下午：提交第一个 PR，第一次修正说明文件

1. 按正常流程提交 PR。 使用和其他人一样的模板、检查项和评审人。新人借助 Agent 写出的代码，应该接受与任何新人代码相同的评审。

2. 把发现的缺口变成修改。 针对陪同任务中每一个“没有”，在合适的 CLAUDE.md 中新增或修正一行说明。让新开发者完成修改，再单独提交一个小 PR。

这是新人第一天能做的最有价值的事情。他是团队里唯一用全新视角看待仓库的人，而他的 Agent 则最能直观地暴露：书面说明究竟遗漏了什么。

下班前：检查哪些事情

一天结束时，新开发者应该已经具备以下成果：

• Claude Code 已能在仓库中运行，并使用共享设置。
• 个人 ~/.claude/CLAUDE.md 中记录的是自己的偏好，而不是团队规则。
• 一个解决真实任务的 PR，已经合并或经过评审。
• 一个改进团队说明文件的 PR。

如果这四项都做到了，他的 Agent 就已经能按照团队的方式工作，而说明文件也为下一位新人变得更完善了一点。

为什么团队越大，这件事越重要

三个人的团队，约定可以存在大家脑子里，靠日常交流传播。到了三十个人的团队，每位开发者的 Agent 每天都会根据仓库里的说明，做出数百个小决定。新人入职时，“我们实际怎么做”和“文档里怎么写”之间的差距最容易暴露，因此，这也是弥合差距的最佳时机。

从已有文档开始

最耗时的通常是共享文件的第一版。其中大部分内容，其实已经存在于入职指南、工程手册，以及介绍各项职责归属的页面中。只是这些内容还没有整理成 Agent 会读取的形式。

这就是我们开发 AI Workspace Builder 的原因。上传团队已有的文档，它就会使用你自己的 Anthropic API key，在 15 到 30 秒内生成 CLAUDE.md、每个角色的配置，以及一个安装脚本。可以免费试用一个工作区，无须提供银行卡。

无论采用哪种方式，下一位新人都是你最好的测试机会。观察他的 Agent 第一天做错了什么，然后把它写下来。

如需采取进一步措施，可以考虑屏蔽此人和／或举报滥用行为。