我管一个二十来人的研发团队,之前在一家做交易系统的公司带过基础架构。 Claude Code 在我们团队铺开大概半年了,从我自己用,到全员用,到现在 进了 CI、进了评审流程。

这篇不写"AI 让团队效率翻倍"那种东西。我想说的是另一件事: 作为技术负责人,这半年我真正花心思的,不是怎么让大家用上 Claude—— 那个一周就铺完了——而是怎么让它别把团队带沟里去。 工具好用是真的,但好用和"对团队是净收益"是两回事。

考虑到国内订阅Claude确实有点困难，参考一下靠谱的网站：claudemax.shop

先看一组数字,顺便看清楚陷阱在哪

第一张图我故意把四个数字放一起。前三个都是好消息: Anthropic 自己公开的数据,内部 PR/人/天涨了 67%; Faros 那份分析了 22000 名开发者、4000 多个团队的报告里, 人均完成的 epic 数涨了 66%,团队层面代码类任务涨了 210%。

数字很漂亮。但你注意第四行——那是红的。

GitClear 分析过 2.11 亿行代码,发现一个趋势: 新写进去的代码,两周之内就被改写掉的比例在上升。 还有 Georgia Tech 的研究,AI 生成的 CVE(安全漏洞)在 2025 年四季度到 2026 年一季度之间翻了三倍,光 2026 年三月 确认的案例就比之前一整年都多。

前三个数字和第四个数字,往往是同时发生的。这就是技术负责人 和一线工程师看 AI 工具的根本区别——一线工程师看"我今天写完了 多少",负责人得看"这些东西半年后还能不能维护"。

PR 数会涨,这几乎是必然的。但 PR 数从来不等于价值。 你要是只拿 PR 数去跟老板汇报 ROI,迟早要还债。

哪些活我交给了 Claude,哪些没敢交

第二张图是我自己梳理的。一个简单的规律: 越靠近"把已知的事做出来",Claude 接得越多; 越靠近"判断和担责",越接不了。

我大幅交出去的:

写 RFC 和技术方案初稿。这个是真省事。以前写一份方案文档, 光把备选项、各自的取舍列清楚就要小半天。现在我把背景和约束 讲清楚,让它先出一版,我在上面改。注意是"初稿"—— 里面的技术判断还是我的,但从空白页到有个能改的东西,这段时间省下来了。

代码评审的第一遍。风格、空指针、边界条件、明显的漏洞, 这些机械的部分让 Claude 先过一遍。它不累、不烦、不会因为是 第八个 PR 就开始划水。但请注意我说的是"第一遍"—— 架构合不合理、这个抽象对不对、跟我们系统的演进方向搭不搭, 这些它看不出来,得人来。

把口头的架构讨论整理成文档。会上吵完了,让它整理成结构化的 决策记录。重构、跨文件批量改动、迁移类的活,也都可以交。

我用了但盯得很紧的:

有个做法我挺喜欢——让 Claude 当"多角色评审团"。 一个需求,让它分别从系统、数据、安全、企业合规四个角度 各出一遍意见。这个用法网上有人写过,核心价值不是它的意见多高明, 而是它解决了一个真实的协调难题:让四个领域的专家同时看同一份 需求,在现实里能拖两周,因为大家在不同时区、不同 sprint。 Claude 把这四个视角的"初步意见"几分钟就给你凑齐了。 但最后拍板的是我,它给的是输入,不是结论。

技术选型对比也是。它能把对比维度列得很全,但它不知道 我们团队三个人最熟哪个栈、不知道我们那套遗留系统的坑、 不知道明年的招聘计划。这些隐性约束得我补。

我没敢交出去的:

这个方案要不要做、什么时候做。团队怎么排、谁做什么、 谁该带谁。还有最后那条——出了生产事故、交付砸了, 签字担责的是我,不是工具。

这三件事是技术负责人这个岗位存在的理由。 真要哪天这些也能外包给 AI 了,那这个岗位也就不需要了。 但 2026 年五月,还远没到那天。

把 Claude 接进团队,我管的四件事

第三张图是我认为技术负责人该亲自管的四件事。 工具谁都会装,但下面这四件,装之前就得想清楚。

第一,立 CLAUDE.md。

Claude Code 的作者 Boris Cherny 有句话我觉得说得很准: CLAUDE.md 不是给人看的 README,是给你的 AI 队友的入职文档。 你每往里加一条修正,就是一个以后不会再犯的 bug。

它是放在仓库根目录的一个 markdown 文件,Claude 每次启动会读。 我们团队的 CLAUDE.md 大概是这样:

项目约定

技术栈

• 后端: Go 1.23 + PostgreSQL + Redis
• 评审/提交前必须跑: golangci-lint run、go test ./...
• 完成后用 gh pr create 开 PR

架构约束(硬性)

• 数据库访问只走 repository 层,handler 层禁止直接查 DB
• 对外 API 变更必须同步更新 openapi.yaml
• 金额一律用整数(分),禁止 float

评审红线 —— 命中即打回

• 任何直接的 DDL(建表、改表)
• 跳过错误处理直接返回
• 在日志里打印密钥、token、身份证号

不要做

• 不要为了"完整"扩大改动范围,只改我要求的
• 不确定的地方先问,不要猜​

注意 /init 这个命令能生成一个 CLAUDE.md,但它生成的是 个空架子,不能直接用。真正有用的内容,是团队在用的过程中 一条条攒出来的。这个文件越厚,全队从每次会话里得到的杠杆越大。 这是会复利的投入。

第二,定评审纪律。

这条是底线:AI 写的代码,必须过人工评审。 不能因为"跑起来了""看着对"就合进去。 我那位资深同事说过一句话我一直记着—— "技术上能跑"和"运营上可靠"不是一回事。

红线类的检查,要设成硬否决。开源社区有个叫 /dev 的 Claude Code 工作流,它的做法值得参考:任何直接的 DDL 就自动打回,合并前强制跑安全审计。我们也照这个思路, 把几条红线设成"命中即拒",不讨论。

第三,看对的指标。

PR 数会涨,这个前面说过了。但负责人要同时盯三个数: 新代码两周内的改写率、变更失败率、评审耗时。 光看 PR 数,你看到的是表象;这三个数,才是代码健康度的体温计。 Claude Code 现在自带 contribution metrics, 在 claude.ai/analytics/claude-code 能看到 PR 和代码行数据, 但那只回答"用了多少",不回答"用得好不好"。 后者得你自己接 DORA 那套指标去对照。

第四,管采用落差。

这条容易被忽略。席位数不等于使用率。 你买了 100 个许可,可能只有 30 个人日活。 Jellyfish 的数据说,大概五分之一的人会在 20 周内停用 Claude Code。 这个流失,不做使用追踪根本看不见。 负责人的活是去搞清楚:停用的人是卡在哪了,是工具不趁手, 还是他们的活本来就不适合,还是没人教。

"810 倍"那个数字,别急着信

第四张图我想专门讲一下,因为这个数字最近传得很广。

Y Combinator 的 CEO Garry Tan,把他自己的 Claude Code 工作流(叫 GStack)开源了,在 GitHub 上拿了八万多 star。 他自报 2026 年的开发产出大概是 2013 年的 810 倍—— 每天 11417 行,对比 2013 年的每天 14 行。

810 倍。听起来很疯。但作为技术负责人,你得看清三个前提:

一,他说的是"逻辑代码行",不是原始行数。 逻辑 LOC 衡量的是有意义的改动——新行为,而不是重新格式化的空白。 这个口径其实比你第一眼想的要诚实。

二,这是单人前后对比,不是对照实验。Tan 拿自己 AI 之前 和之后比,是个诚实的数据点,但不是科学结论。

三,它不适用于所有场景。TechCrunch 的分析就指出, 做硬件相关、强监管领域的开发者,增幅小得多。

我为什么要泼这盆水?因为技术负责人最容易踩的坑, 就是拿一个明星个例的数字,去给自己整个团队定 KPI。 Tan 是 YC 的 CEO,他写的多半是他自己很熟的、约束很少的代码。 你团队里那个在维护十年遗留系统、天天跟监管合规打交道的工程师, 他的 810 倍永远不会来。你要是按这个给他定指标, 你不是在提效,你是在逼他往代码库里灌水。

半年下来,我的几条实在话

要我给同行几条建议:

CLAUDE.md 要当成正经工程资产来维护,指定人负责,定期更。 它是你团队和 AI 之间的合同,合同含糊,活就含糊。

评审纪律不能松。AI 让"写"变快了,但"读"和"判断"没变快。 如果你团队的评审还是老节奏,那 AI 写得越快, 积压在评审环节的债就越多。这个瓶颈是负责人要去解的。

汇报 ROI 的时候,别只报 PR 数和"代码行数翻倍"。 老板那边好看,但你自己心里要有另一本账—— 两周改写率、变更失败率。这两本账对不上的时候, 对不上的地方就是你下个季度的技术债。

最后一条,也是我最想说的。AI 把初级的、机械的活拿走了之后, 团队里初级工程师的成长路径其实变窄了—— 他们原来就是靠写那些活练出来的。这件事 AI 不会替你操心, 但它是技术负责人的活。怎么让人在 AI 时代还能成长为 能做判断、能担责的工程师,这个问题, 比"我们团队这季度多发了多少 feature"重要得多。

工具会让你的团队跑得快。但跑得快的团队会往哪跑, 是不是还在往一个健康的方向跑——这个, 得有一个有名有姓、会担责的人盯着。那个人是你,不是 Claude。