35%这个数字很抓眼球，也很容易被误读。
Cursor官网把产品定位为 AI coding agent，并列出 Agents、Tab 和 Changelog 等入口。据智源社区转引的文章，Cursor CEO称AI已自主提交35%的代码，云端Agent开始承担规划、编码、调试和交付。
但“AI写了35%的代码”，不等于“初级工程师少了35%的工作”。现有材料没有提供“Cursor 3.5上线三周”的正式版本说明，也没有三家研发团队的Git统计。初级工程师的代码占比还剩多少，现在没有可信数字。
35%不是一张人力换算表
这35%按什么计算？代码行、提交次数，还是完成的任务数？统计覆盖哪些仓库？AI生成后又被人工修改的代码算谁的？智源社区提供的摘要没有交代这些口径。
口径不同，结果会差得很远。一次文档更新和一次核心业务改动都可以算作一个提交，但需要的判断、测试和责任不是一回事。Agent先写初稿，工程师补上边界条件、检查依赖，再决定是否合并，这些工作也很难被一个生成代码占比反映出来。
因此，35%能说明Agent已经进入开发环节，却不能说明初级工程师只剩下65%的作用，更不能拿来计算团队该减少多少人。
最先交给Agent的，是第一版实现
智源社区的摘要提到，云端Agent正从输出代码片段，转向交付可评审的工件。变化不只是“多补全几行”，而是工具开始接过一段连续工作：先规划，再编码、调试，最后交出结果供人检查。
需求清楚、约束明确、验收标准容易描述的任务，更适合让Agent先做。样板代码、常规接口、测试草稿和文档初稿，人工从零敲出的时间会减少。
偏偏这些工作曾是新人熟悉代码库的入口。自己写过一遍，才会碰到依赖冲突、异常分支和模糊需求；如果直接从需求跳到生成结果，新人可能看得懂代码，却没有完整经历实现和排错。
团队省下了第一遍编码的时间，也压缩了新人的练习空间。
Git里的提交少了，事情没有一起消失
Agent交出代码后，仍然要有人回答：改动影响哪些模块？异常情况有没有覆盖？失败后怎么回退？这次修改最终由谁负责？
Git擅长记录改了什么，却记录不全需求澄清、约束设定、结果验证和风险判断。一个工程师亲手输入的代码变少，不代表他的工作变少；也可能是时间被挪到了审查、测试和问题定位上。
如果绩效还围绕代码行数和提交次数，团队很容易把“写得少”误判成“贡献少”。更实用的做法，是按任务查看AI初稿、人工修改、审查意见和最终责任人。对初级工程师的评价，也应包括他能否解释代码、设计测试、定位问题，并在拿不准时及时请资深同事介入。
新人的门槛，从生成代码移到了完成交付
会写提示词不难。难的是说清楚生成结果为什么能用，哪里可能出错，还缺哪些验证。
AI编程助手提高了代码生成的起点，但不会替工程师承担上线后的后果。新人需要练习的，也不再只是从零写出一段代码，而是把模糊需求整理成明确约束，检查Agent的改动，并把任务完整交付。
团队也不能把所有简单任务都交给Agent。新人仍然需要经历从需求、实现到测试的完整过程，否则审查能力会失去来源：没有亲手处理过问题，就很难判断AI的答案错在哪里。
所以，“初级工程师的代码占比还剩多少”暂时没有百分比答案。现有材料支持的数字只有35%，它描述的是AI参与编码的程度，不是新人岗位的缩减比例。眼下更确定的变化是，第一版代码正在减少，审查、验收和对结果负责的分量正在增加。
资料来源
