1. 一个让人坐不住的数字26%第一次看到“Claude 主导了 Anthropic 26% 的研发打分的也是 Claude”这个说法我的反应和大多数人一样——先愣一下然后开始琢磨这数字到底怎么来的。26% 不是一个随口说说的比例它意味着在 Anthropic 内部超过四分之一的研发工作量已经由 Claude 自己承担了。更关键的是后半句打分的也是 Claude。这就不是简单的“AI 辅助写代码”了而是一个闭环——Claude 干活Claude 验收。我在过去大半年里一直在折腾 Claude Code 和各种 AI 代理工具从最初的“帮我补全个函数”到后来让它独立跑完一个模块的测试用例踩过的坑不算少。所以看到这个标题的时候我脑子里冒出来的第一个问题不是“真的假的”而是“如果让我来复现这套流程需要哪些条件”。这篇文章就是围绕这个问题展开的——不聊虚的只拆解这套 AI 主导研发的范式到底怎么运转以及一个普通开发者能从中学到什么、直接抄什么。如果你正在用 Claude Code、正在搭建自己的 AI 代理工作流或者只是好奇“AI 研发自动化”到底走到哪一步了下面的内容应该能给你一些可以直接落地的参考。我会从整体设计思路讲起然后拆核心环节再给实操步骤最后把我在这个过程中遇到的各种报错和排查方法整理出来。2. 这套研发范式到底在做什么2.1 从“辅助工具”到“主导执行者”的转变大多数人用 AI 写代码的方式还停留在“我写注释它补代码”或者“我描述需求它给个片段”。这种方式的问题很明显AI 只参与了研发链条中很小的一段剩下的设计、拆分、测试、验收、集成全是人在做。而 Anthropic 这套模式的核心变化在于Claude 不再只是“补全工具”而是变成了任务的主导执行者。具体来说一个典型的闭环是这样的人给出高层目标比如“实现一个支持分页的用户列表接口”Claude 负责把这个目标拆解成子任务、编写代码、运行测试、根据测试结果修正代码最后再对自己的产出进行质量评分。人只在关键节点做审核和方向调整。这就是为什么“打分的也是 Claude”这句话如此重要——它意味着质量评估这个环节也被纳入了自动化闭环。我自己的体会是当 AI 只负责写代码的时候你省的是打字的时间当 AI 负责写代码加测试加修正的时候你省的是整个调试循环的时间。后者带来的效率提升不是线性的而是数量级的。2.2 为什么是 26% 而不是更高或更低26% 这个数字其实很有意思。它既不是“AI 什么都能干”的夸张宣传也不是“AI 只能打打下手”的保守估计。从工程实践的角度看这个比例反映的是一个正在爬坡的自动化曲线——有些任务类型已经可以高度自动化有些还不行。根据我的观察和实操经验目前适合 Claude 主导的研发任务大致有这么几类有明确输入输出定义的函数实现、单元测试编写、代码重构、文档生成、bug 定位与修复建议。这些任务的共同特点是目标可验证、边界清晰、不需要大量跨团队沟通。而不太适合完全交给 AI 的是那些需要深度业务理解、涉及多方利益权衡、或者需求本身还在剧烈变动的任务。26% 这个数字背后其实是一套精细的任务分类和路由机制。不是所有任务都无差别地扔给 Claude而是有一套判断逻辑在决定“这个任务适不适合 AI 主导”。这套判断逻辑本身才是真正值得学习的地方。2.3 对普通开发者的实际意义你可能会想这是 Anthropic 内部的事情跟我有什么关系关系很大。因为这套范式的核心组件——Claude Code、MCP 协议、代理工作流——都是对外可用的。你不需要在 Anthropic 工作也能在自己的项目里复现类似的流程。我过去几个月在自己的 side project 里尝试了一套简化版的 AI 主导研发流程覆盖了大约 30% 的日常开发任务。效果最明显的场景是写测试、重构旧代码、处理重复性的 CRUD 逻辑。这些任务以前要占掉我大量时间现在基本可以交给 Claude Code 跑我只需要在最后 review 一下。所以下面我会把这套流程拆开讲清楚每个环节怎么配置、怎么跑、怎么避坑。你可以根据自己的项目情况选择性地采纳其中一部分。3. 核心环节拆解Claude 是怎么“主导”研发的3.1 任务拆解与路由不是所有活都接Claude 主导研发的第一步不是写代码而是判断“这个任务我能不能接”。这听起来简单但实际实现起来需要一套相当精细的提示词工程和上下文管理。我在自己的项目里模拟这套逻辑时用的是一个三层判断机制。第一层是任务类型识别这是一个新功能开发、bug 修复、代码重构、还是测试编写不同类型的任务后续的处理流程完全不同。第二层是复杂度评估这个任务涉及几个文件、几个模块、有没有外部依赖复杂度超过一定阈值的任务会被标记为“需要人工介入”。第三层是上下文完备性检查Claude 需要知道的相关代码、接口定义、数据模型是不是都已经在上下文里了如果缺关键信息它会先请求补充而不是硬写。这套判断机制的核心价值在于它避免了“AI 硬写一堆不能用代码”的情况。我早期用 Claude Code 的时候最大的痛点就是它有时候会“自信地写出完全错误的代码”原因就是它在信息不完整的情况下强行开工。加上任务路由这一层之后这种情况明显减少了。实操心得在配置 Claude Code 的任务路由时建议把“上下文完备性检查”作为强制步骤。具体做法是在系统提示词里明确要求如果缺少关键接口定义或数据模型必须先列出缺失项并请求补充不得直接开始编码。3.2 代码生成与自测循环写完就跑跑完就改任务拆解完之后进入核心的执行环节。Claude 生成代码的方式和普通代码补全有本质区别它会同时生成对应的测试用例并且在生成完成后立即运行测试。这个“写完就跑”的循环是整套流程的关键。我实测下来Claude Code 在生成一个函数之后会自动执行以下步骤先检查项目里有没有现成的测试框架配置然后根据函数签名和业务逻辑生成测试用例接着运行测试最后根据测试结果决定是提交还是修正。如果测试失败它会分析失败原因修改代码再次运行测试直到通过或者达到重试上限。这个循环的效率取决于几个因素。首先是测试框架的配置是否规范——如果项目里用的是 pytest 或者 jest 这类主流框架Claude 能很好地识别和调用。如果用的是比较小众的测试工具可能需要额外配置。其次是测试用例的质量——Claude 生成的测试用例有时候会“过于宽松”只覆盖了正常路径忽略了边界条件。我的做法是在提示词里明确要求“必须包含至少一个边界条件测试和一个异常路径测试”。3.3 自动评分机制Claude 给自己打分的逻辑“打分的也是 Claude”这句话背后是一套自动化的质量评估体系。根据我的理解和实操模拟这套评分机制大致包含几个维度代码正确性测试是否全部通过、代码风格一致性是否符合项目规范、可维护性函数长度、圈复杂度、注释覆盖率、以及任务完成度是否覆盖了原始需求的所有要点。评分的方式通常是让 Claude 在一个独立的会话中以“评审者”的身份来审视“执行者”的产出。这种角色分离很重要——如果让同一个会话既写代码又评分它往往会倾向于给自己打高分。通过开启新的会话、提供独立的评审提示词可以得到更客观的评分结果。我在自己的项目里试过这套方法发现一个有意思的现象当 Claude 以评审者身份打分时它对“代码风格一致性”的要求往往比人类评审还严格。有一次它给一个功能完全正确的模块打了低分理由是“变量命名不符合项目已有的 snake_case 规范”。这种严格程度在初期可能会让人觉得烦但长期来看它确实帮助保持了代码库的一致性。3.4 人工介入的触发条件虽然标题说的是“Claude 主导”但人工介入的环节依然存在只是触发条件变得更明确了。根据我的实操经验以下几种情况会触发人工介入评分低于预设阈值、任务涉及敏感操作比如数据库 schema 变更、连续多次自测失败、或者任务复杂度超出了预设的上限。这套触发机制的设计逻辑是让 AI 处理它擅长的部分把真正需要人类判断的部分留给人类。我在配置自己的流程时把“数据库 schema 变更”和“外部 API 密钥相关操作”设为了强制人工介入项。这两类操作一旦出错修复成本很高不值得为了省一点时间而冒险。4. 实操复现从零搭建一套简化版 AI 主导研发流程4.1 环境准备与工具选型要复现这套流程你需要准备的东西其实不多但每一样都要配置到位。核心工具是 Claude Code这是 Anthropic 官方提供的命令行工具可以直接在终端里调用 Claude 的能力。安装方式根据操作系统不同略有差异在 macOS 和 Linux 上通常通过 npm 全局安装Windows 上建议在 WSL 环境里操作。安装完成后第一件事是配置 API 访问。你需要一个有效的 API 密钥然后通过环境变量或者配置文件的方式设置好。我建议把密钥放在环境变量里而不是硬编码在配置文件中这样更安全也更容易在不同项目间切换。除了 Claude Code 本身你还需要一个版本控制工具Git 是标配、一个测试框架根据你的技术栈选择、以及一个任务管理工具用来记录哪些任务交给了 Claude、哪些留给自己。我用的是最简单的方案Git 加 pytest 加一个 Markdown 格式的任务清单。注意事项在 Windows 上直接安装 Claude Code 可能会遇到路径识别问题报错信息通常是“无法将 claude 项识别为 cmdlet、函数、脚本文件或可运行程序的名称”。这不是安装失败而是环境变量没有正确配置。解决办法是把 npm 的全局安装路径添加到系统 PATH 中或者直接在 WSL 里操作。4.2 配置 Claude Code 的项目级指令Claude Code 支持项目级的配置文件通常放在项目根目录下的.claude文件夹里。这个配置文件是你“教”Claude 怎么在这个项目里工作的关键。我建议至少配置以下几项项目使用的编程语言和框架、代码风格规范缩进、命名约定、注释要求、测试框架和运行命令、以及哪些目录或文件是 Claude 不应该碰的。举个例子如果你在做一个 Python 项目用的是 FastAPI 框架和 pytest 测试配置文件里就应该明确写出这些信息。这样 Claude 在生成代码时就会自动遵循 FastAPI 的惯例而不是给你写一个 Flask 风格的实现。测试命令也要写清楚比如pytest tests/ -v这样 Claude 在自测环节就知道该运行什么命令。我自己的配置文件里还加了一条规则“所有新生成的函数必须包含 docstring格式遵循 Google 风格”。这条规则看起来很小但它让整个项目的文档一致性提升了很多。以前人工写代码的时候总是有人写 docstring 有人不写风格也不统一。交给 Claude 之后这个问题基本消失了。4.3 跑通第一个自动化任务以“实现一个 REST API 端点”为例理论说再多不如跑一遍。我拿一个具体的例子来演示整个流程实现一个“获取用户订单列表”的 REST API 端点。第一步我给 Claude Code 的指令是这样的“在app/routes/orders.py中实现一个 GET/users/{user_id}/orders端点支持分页参数 page 和 page_size返回订单列表和分页元信息。参考app/routes/users.py中的现有实现风格。”第二步Claude 会先读取users.py了解现有风格然后检查数据模型定义确认订单和用户的关联关系。如果它发现缺少必要的模型定义会先提出来。第三步它开始生成代码。生成的代码通常包括路由函数、请求参数校验、数据库查询逻辑、以及响应序列化。同时它会生成对应的测试用例覆盖正常分页、空结果、无效 user_id 等场景。第四步它运行测试。如果测试通过它会输出一个总结包括修改了哪些文件、新增了哪些测试、测试通过率是多少。如果测试失败它会进入修正循环。我实测下来这个端点的完整实现包括测试大约需要 2 到 3 分钟。同样的任务我自己写的话大概要 15 到 20 分钟包括调试时间。效率提升是明显的但更重要的是Claude 生成的测试用例往往比我手写的更全面尤其是边界条件那块。4.4 评分环节的配置与调优评分环节是这套流程里最容易被忽视、但也最重要的部分。我的做法是在 Claude Code 的配置里单独定义一个“评审模式”当执行环节完成后自动切换到评审模式对产出进行打分。评审的提示词我改了好几版目前用的是一个包含五个维度的评分卡正确性测试是否全部通过权重 40%、风格一致性是否符合项目规范权重 20%、可维护性函数长度、复杂度、注释权重 20%、需求覆盖度是否实现了所有要求的功能点权重 15%、以及安全性是否有明显的安全漏洞权重 5%。每个维度按 1 到 5 分打分加权后得到一个总分。总分低于 3.5 的产出会被标记为“需要人工审核”不会自动提交。这个阈值是我根据自己的项目情况调的你可以根据对代码质量的要求来调整。如果项目对代码质量要求极高可以把阈值提到 4.0如果是在做原型验证可以降到 3.0。实操心得评分卡里的“安全性”维度虽然权重不高但绝对不能省。我遇到过 Claude 生成的代码里直接拼接 SQL 查询字符串的情况虽然测试能通过但存在注入风险。加上安全性检查之后这类问题基本被拦截了。5. 常见问题与排查技巧实录5.1 连接与认证类问题这类问题在实际操作中出现频率最高表现也最直接。最常见的报错是连接被重置或者无法连接到服务。根据我的排查经验这类问题通常有几个原因网络环境不稳定、API 密钥配置错误、或者本地代理设置干扰了请求。排查顺序建议是先检查 API 密钥是否有效可以在终端里用 curl 测试一下基本的 API 调用然后检查网络连接是否稳定最后检查有没有本地代理或者防火墙规则在拦截请求。如果是企业网络环境可能还需要确认出口规则是否允许访问相关服务。另一个常见的认证问题是“组织已禁用订阅访问”之类的提示。这通常意味着你的账号类型或者组织设置不支持当前使用的功能。解决办法是联系组织管理员确认权限配置或者切换到支持的个人账号。5.2 环境配置类问题环境配置问题往往表现为“命令找不到”或者“二进制文件未安装”。比如在 Windows 上安装完 Claude Code 之后在 PowerShell 里输入claude命令却提示“无法将 claude 项识别为 cmdlet”。这不是安装失败而是 PATH 环境变量没有包含 npm 的全局安装目录。解决办法分两步先用npm config get prefix找到 npm 的全局安装路径然后把这个路径添加到系统的 PATH 环境变量中。在 Windows 上可以通过“系统属性 - 高级 - 环境变量”来操作在 macOS 或 Linux 上则是修改.bashrc或.zshrc文件。还有一个常见问题是“native binary not installed”这通常发生在安装过程中 postinstall 脚本没有正常执行的情况下。解决办法是手动运行安装脚本或者重新安装并确保安装过程中没有跳过脚本执行。5.3 模型路由与配置类问题这类问题的典型报错是“doesnt look like an anthropic model: expected a gateway model route”。这个错误的意思是你配置的模型名称或者路由方式不符合预期。如果你是通过第三方网关或者代理来访问模型的需要确保配置的模型名称和网关支持的路由规则匹配。我在配置本地模型接入时遇到过类似问题。当时想把 Claude Code 接到本地运行的模型上报错信息就是模型路由不匹配。解决办法是检查网关的配置文件确认模型名称的映射关系是否正确。如果用的是 LM Studio 或者类似的本地推理工具需要确保它暴露的 API 接口格式和 Claude Code 期望的一致。5.4 任务执行类问题任务执行阶段最常见的问题是“Claude 生成的代码测试不通过但反复修改也修不好”。这种情况通常是因为任务描述不够清晰或者上下文信息不完整。我的处理方式是暂停自动循环手动检查 Claude 的上下文里是否包含了所有必要的信息然后补充缺失的部分重新启动任务。另一个常见问题是“Claude 修改了不该修改的文件”。这通常是因为项目配置里没有明确指定哪些文件是只读的。解决办法是在.claude配置文件里加上排除规则把不希望被自动修改的文件或目录列进去。下面这张表整理了我遇到过的典型问题、报错信息和解决方法方便你快速对照排查。问题类型典型报错排查方向解决方法连接认证连接被重置、无法连接检查密钥和网络验证 API 密钥检查网络稳定性环境配置命令无法识别检查 PATH 配置添加 npm 全局路径到 PATH模型路由模型路由不匹配检查网关配置确认模型名称映射关系任务执行测试反复失败检查上下文完整性补充缺失信息重新启动任务文件权限修改了只读文件检查排除规则在配置中添加排除目录5.5 我踩过的三个坑第一个坑是“过度信任自动评分”。刚开始用的时候我看到评分通过就直接提交了结果后来发现有些代码虽然测试通过、评分也高但实际业务逻辑有偏差。原因是评分卡里的“需求覆盖度”维度权重设得太低Claude 实现了一个能跑通测试但不符合业务预期的版本。后来我把需求覆盖度的权重调高并且在提示词里要求“必须逐条对照需求列表确认实现”。第二个坑是“上下文污染”。当我在同一个会话里连续让 Claude 处理多个不相关的任务时前面任务的上下文会干扰后面任务的判断。解决办法是每个独立任务开启新的会话或者在配置里设置上下文清理规则。第三个坑是“测试用例的虚假安全感”。Claude 生成的测试用例有时候会“迎合”它自己写的代码而不是真正验证业务逻辑。比如它写了一个有 bug 的函数然后写了一个刚好能通过的测试。这种情况需要通过人工 review 测试用例来发现或者引入独立的测试生成工具来交叉验证。6. 这套模式适合谁不适合谁6.1 适合的场景与团队特征根据我的实操经验这套 AI 主导研发的模式在以下几种场景下效果最好项目有完善的测试基础设施、代码风格规范明确、任务粒度适中单个任务能在 30 分钟内完成、以及团队对 AI 生成代码有基本的信任和 review 能力。如果你在做的是一个从零开始的新项目这套模式可能不太适合直接套用因为新项目往往缺乏明确的规范和测试基础。但你可以用它来快速搭建项目骨架和初始测试框架然后再逐步引入自动化流程。对于维护型项目或者功能迭代型项目这套模式的价值最大。因为这类项目通常已经有了一套成熟的代码规范和测试体系Claude 可以很快上手并遵循现有规则。6.2 不适合的场景与风险提示有些场景我强烈建议不要完全交给 AI 主导。首先是涉及资金交易、用户隐私数据、或者核心安全逻辑的代码这些必须有人工审核环节。其次是需求本身还在剧烈变动的项目因为 AI 擅长执行明确的任务不擅长处理模糊和矛盾的需求。最后是那些“只有某个人知道怎么做”的遗留系统因为 AI 缺乏必要的上下文。风险方面最大的风险是“自动化偏见”——因为 AI 评分通过了就放松了人工审核。我的做法是设置一个“强制人工审核”的清单清单上的任务类型无论评分多高都必须人工过一遍。这个清单包括数据库变更、认证授权逻辑、外部支付接口、以及任何涉及用户数据导出的功能。6.3 从 26% 到更高比例需要什么条件如果你想把 AI 主导的比例从 26% 提升到更高需要补齐几个条件。首先是更细粒度的任务拆分能力让每个任务都足够小、足够明确。其次是更完善的上下文管理确保 Claude 在需要的时候能拿到所有相关信息。第三是更成熟的评分体系能够准确识别出那些“测试通过但业务逻辑有偏差”的情况。我在自己的项目里做过一个实验把任务粒度从“实现一个模块”细化到“实现一个函数”AI 主导的成功率从大约 60% 提升到了 85% 以上。这说明任务粒度是影响自动化比例的关键变量。当然任务拆解本身也需要成本所以这里有一个平衡点——拆得太细人工拆解的时间可能比省下来的时间还多。7. 一些实用的配置片段和命令7.1 Claude Code 项目配置示例下面是我在一个 Python 项目里实际使用的.claude/config.json配置片段你可以根据自己的项目情况调整。{ project: { language: python, framework: fastapi, test_command: pytest tests/ -v --tbshort, style: { indent: 4, naming: snake_case, docstring: google }, exclude_paths: [ migrations/, secrets/, *.env ], review_threshold: 3.5, max_retry: 3 } }这个配置里review_threshold是评分阈值低于这个分数的产出不会自动提交。max_retry是自测失败后的最大重试次数超过这个次数会触发人工介入。7.2 评审提示词模板评审环节的提示词我改了很多版下面这个是目前用着比较顺手的版本。核心思路是让评审者以独立视角审视产出避免“自评偏高”的问题。你是一个独立的代码评审者。请对以下代码变更进行评分评分维度包括 1. 正确性40%测试是否全部通过逻辑是否正确 2. 风格一致性20%是否符合项目已有的命名和格式规范 3. 可维护性20%函数长度、圈复杂度、注释是否充分 4. 需求覆盖度15%是否实现了需求列表中的所有功能点 5. 安全性5%是否存在明显的安全风险 每个维度按 1-5 分打分输出加权总分和每个维度的简要评语。 如果总分低于 3.5请列出需要人工审核的具体原因。7.3 常用命令速查日常操作中我用得最多的几个命令整理如下。这些命令覆盖了从启动任务到查看评分结果的主要流程。# 启动一个自动化任务 claude task run --file tasks/implement_order_api.md # 查看当前任务状态 claude task status # 查看评分结果 claude task review --last # 手动触发评审 claude review --path app/routes/orders.py # 查看项目配置 claude config show这些命令的具体参数可能随着版本更新有变化建议以官方文档为准。我在这里列出来主要是让你了解整个流程的操作节奏——基本上就是“提交任务、查看状态、审核评分”这三步循环。8. 关于“AI 主导研发”这件事我目前的看法说实话第一次看到 26% 这个数字的时候我有点怀疑。但自己跑了大半年类似的流程之后我觉得这个比例是可信的甚至在某些任务类型集中的项目里这个比例还可以更高。关键不在于 AI 能不能写代码而在于整个工程体系能不能支撑“AI 写代码、AI 测试、AI 评分”这个闭环。我目前在自己的项目里维持着大约 30% 到 40% 的 AI 主导比例主要集中在测试编写、代码重构和 CRUD 逻辑实现上。核心业务逻辑和架构设计还是自己来。这个比例让我既能享受到效率提升又不会对代码质量失去控制。如果你也想尝试这套模式我的建议是从一个小模块开始先把测试基础设施搭好然后逐步把重复性高的任务交给 Claude。不要一上来就追求高比例先把流程跑通再慢慢调优。踩坑是必然的但每个坑踩完之后你对这套流程的理解都会更深一层。