我管一个二十来人的研发团队,之前在一家做交易系统的公司带过基础架构。 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。