数百个开发代理同时工作、超过100万行代码、数十亿Token——这是Cursor在2026年初公开的一项实验规模。团队让代理在同一项目中连续运行数周，用规划者和执行者分工推进任务（iThome，2026-01-16）。
另一个更容易引发焦虑的数字是35%。据智源社区转载的新智元报道，Cursor CEO称，平台上约35%的代码已经由AI自主提交（智源社区，2026-03-09）。
但代码行数不是工作完成度。会生成代码，和能独立交付、承担结果，中间还隔着测试、调试、依赖处理和人工评审。
我们没有复刻那个百万行实验，而是把Cursor 3.5放进一个约6万行的开源全栈项目。项目使用React、Node和PostgreSQL。主分支冻结后，多代理模式连续运行9天，完成两轮迭代。
不看生成量，先看返工量
测试拆成了三组：
- 代码审查：检查12个近期PR，涉及约3800行diff，任务包括风格检查、潜在bug标记和API误用识别。
- 单元测试：为30个核心业务函数生成并运行测试，检查边界、反向和错误路径。
- 依赖升级：同时把TypeScript从5.4升到5.6、React从18升到19，由代理识别兼容问题并生成patch。
每组任务都保留人工复核记录，结果分为代理一次通过、追加提示后修复、无法解决三类。比起代理写了多少代码，我们更在意两件事：哪些结果可以直接采用，哪些结果会把返工留给工程师。
代码审查最稳，跨文件仍是盲区
12个PR中，Cursor 3.5的一次通过率约为67%。从具体审查结论看，约72%可以直接采用，其余部分需要工程师重新判断。
漏报主要出现在跨文件问题上。Promise未捕获异常带来的连锁影响、闭包中的状态污染，都要求审查者沿着调用链继续追踪。代理通常能指出当前函数的问题，却容易忽略周边模块发生了什么。
过度警告则集中在样板代码。ESLint已经覆盖的格式问题，它还会再说一遍；面对明确的类型断言，也会反复提醒“可能不安全”。这些提示不难处理，但会增加筛选成本。
所以，代码审查可以交给代理打头阵，却不能直接撤掉人工二审。格式、简单API误用和局部bug适合自动过滤，跨文件副作用、架构和安全判断仍要由有经验的工程师负责。
测试写得很快，却不一定抓得住bug
Cursor 3.5为30个业务函数生成测试时，平均每个函数耗时4.2秒，边界用例、反向用例和错误路径都能给出，速度没有问题。
覆盖率也明显上升：
- 行覆盖率从61%提高到84%；
- 分支覆盖率只从38%提高到49%；
- 12个测试在第一次运行时全部通过，但人工注入6个故意写入的bug后，只有2个被捕获。
问题出在mock。代理为了让测试顺利运行，会把不少复杂分支压平。最终得到的测试整齐、自洽、可以执行，覆盖率数字也好看，却没有形成足够强的回归保护。
把这类代码叫作“展示型测试”并不过分。它适合搭建PR阶段的测试骨架，但缺失的断言、失败路径和异常组合，仍要由测试工程师补齐。覆盖率上涨，不等于系统真的更安全。
依赖升级能找到坑，填坑还得靠人
TypeScript和React同时升级，是三组任务中最容易失控的一组。
Cursor 3.5识别出14个存在冲突的依赖项，其中9个给出了明确建议。但处理具体改动时，结果并不完整：React 19移除defaultProps带来的连锁反应，代理只标记了3处，人工检查后发现实际有11处需要修改。
面对tsconfig严格模式下的隐式any，它又走向另一个极端，一次提交改动约800行。这样的patch即使能通过编译，也很难直接进入团队评审。
最后，两名工程师用了约1.5天手动收尾。代理在这里更像侦察兵：先列出可能冲突的依赖，生成一版预演patch，让团队提前知道风险在哪里。让它直接完成升级并提交，可靠性还不够。
多代理省下的是排队时间
Cursor公开的实验把代理拆成规划者和执行者：规划者遍历代码库、生成任务，执行者并行处理，再把结果整理成可评审的工件。这种方式提高的主要是任务吞吐量，而不是单个代理的判断能力。
测试中最明显的收益也来自批量工作。一次生成50个组件的prop类型和50个测试文件骨架，耗时从两天压缩到约30分钟。新成员可以直接在脚手架上修改，评审者拿到的diff和说明也更整齐。
代价同样具体：
- 架构、性能和安全问题的失败模式，仍要靠人识别；
- 项目规模扩大后，上下文窗口、代码索引和依赖关系会限制代理判断；
- 调试代理生成的代码，有时比从零编写更慢，因为接手者没有原始的思考过程。
多代理可以同时开工，却不能自动补上责任链。任务拆得越多，团队越需要明确谁来验收、谁能合并，以及出现回归后由谁处理。
团队先改门禁，再扩大使用范围
引入Cursor 3.5时，不必先讨论要开多少账号，更该先划清代理的工作边界。
先定义可直接提交的任务。 格式修复、测试骨架、类型补全和重复组件适合批量处理；架构调整、安全审计和复杂依赖升级不应自动合并。
代码审查保留两层门禁。 代理负责筛掉格式问题、简单bug和常见API误用，资深工程师继续检查调用链、跨文件影响与架构风险。
测试分成生成和验证两段。 代理写骨架，测试工程师再用mutation testing、失败用例注入等方式验证测试是否真的能发现问题。
依赖升级只让代理预演。 风险清单和patch可以自动生成，最终修改与合并权仍留在人手里。
按节省时间衡量，不按代码行数衡量。 35%代表代码占比，不代表35%的开发工作已经可靠完成。更有用的问题是：哪类任务能稳定交给代理，交付后还需要多少返工。
初级程序员没消失，低判断任务正在减少
在批量生产、代码整理和标准化任务上，Cursor 3.5的速度可以接近一位中级工程师。但涉及架构判断、性能调优、跨文件一致性和安全审计时，它仍需要更有经验的人兜底。
初级程序员的工作因此被重新切分。可批量、可标准化的部分先被代理接走，留下来的工作变成阅读生成代码、验证结果、修正盲区和解释改动。外包式、模板式、组件堆积式的任务受到的影响会更直接。
这不等于新人岗位马上消失，却意味着只会按需求堆代码越来越不够用。读懂项目、判断影响范围、设计有效测试和控制合并风险，正在变成更基础的能力。
与其被“35%自主提交”刺激，不如先检查自己的任务列表：哪些工作已经能被Cursor稳定接住，哪些工作交给它之后反而增加返工。前一部分可以大胆自动化，后一部分暂时还得留给写代码、也为代码负责的人。
参考资料：