35%先别急着换算成工期
新智元在2026年3月9日的转述称，Cursor CEO Michael Truell在演讲中提到，AI已能自主提交约35%的代码；按该报道口径，一年前约15%。人人都是产品经理的演讲摘要则写到，企业客户场景下有75%的代码完全由AI生成。
两份二手材料的统计对象和口径并不清楚，不能拼成一条增长曲线，更不能直接得出“项目工期减少35%”这样的结论。
比数字更可靠的是Cursor自己的产品定义。官方博客《AI软件开发的第三个时代》把演进过程分成三个阶段：Tab自动补全是第一阶段，同步的提示—响应循环是第二阶段，接下来则是Agent在更长时间内独立处理更大的任务，并减少人工介入。官方还用了“软件工厂”和Agent“车队”的比喻，开发者负责给方向、配工具、审阅结果。
OSCHINA对Cursor 3的报道把它概括为“智能体集群”。过去交给工具的任务通常是一行代码或一个函数，现在可以扩大到一个组件族、一轮测试和一份可审查的PR。
数据口径说明：AtomGit文章援引“Gartner 2026软件工程报告”，称全球75%的企业级前端代码已由AI辅助生成。现有素材没有附原始报告链接，而且“辅助生成”与“自主提交”并非同一指标，因此这里不拿这个数字推算产能。
组件库是个合适的试验场
组件库的范围相对清楚，改动却天然跨文件。迁移一组表单组件，往往会同时碰到src/tokens、组件源码、.stories.tsx、__tests__和类型声明。编译通过，只能说明改动没有立刻报错；token映射、交互状态、公开API和调用方是否保持一致，还要逐项确认。
范围也好拆。表单类、反馈类、布局类、数据展示类可以分别推进，每批都有Storybook、测试和现有调用方作为参照。它比单函数补全更能发挥Agent的多文件处理能力，也比整套应用重写更容易控制边界。
这类任务更常见的问题是改得太顺：几十个文件很快被改完，最后却没人说得清哪些视觉变化是有意调整，哪些只是Agent做了近似匹配。
Agent启动前，先把标准写进仓库
在仓库根目录放一份MIGRATION_STANDARD.md，至少写清这些内容：
- design token的源文件路径，以及旧值到新token的映射；
- 必须覆盖的
hover、focus、disabled、loading、error状态； - 对比度、键盘焦点和ARIA等无障碍底线；
- 类型约束，包括禁用的React API、必须使用的hooks和基础类型；
- 依赖边界，尤其是能否引入新包；
- 允许调整与必须兼容的公开API。
如果文档里只有“统一样式、优化代码”这种宽泛要求，Agent只能自行补齐空白。最容易出问题的是token映射：颜色看着接近，语义却可能完全不同。映射关系应由设计师和前端负责人定好，Agent负责批量执行。
给旧版本留一份能对照的基线
改代码前，先用Storybook跑一遍现有组件，再通过Chromatic或Playwright保存截图。仓库已有的快照、单元测试和无障碍检查也要完整执行一次。
这份基线相当于Agent的“眼睛”。视觉调整如果是预期变化，就在PR里标清目标；如果不是，截图差异必须回查。没有基线，Agent最多只能证明构建成功，无法证明组件没有漂移。
一类组件，一个Workspace
不要把整个组件库塞给同一个Agent。表单、反馈、布局和数据展示可以各开一个Workspace，让计划、多文件改动和Diff保持在可评审的范围内。一次任务混入太多组件，后面即使测试失败，也很难快速定位是哪类改动造成的。
Prompt不需要堆角色设定。把范围、约束、验收命令和禁止事项写清楚更有用：
任务：将 src/forms 下所有组件迁移到 MIGRATION_STANDARD.md。
约束：
1. 仅使用 src/tokens 中已有的设计变量，不得新增硬编码色值或长度；
2. 类型必须继承 types/component-base.d.ts，禁止使用 any；
3. 更新对应的 .stories.tsx 与 __tests__；
4. 保持现有公开API兼容，无法兼容时必须标记 breaking change；
5. 不得自行引入新依赖，也不得直接删除旧组件。
验证：
- 运行 pnpm test:forms；
- 运行 pnpm storybook:build；
- 核对视觉基线并附上差异截图。
交付：
- 列出每个组件的token映射；
- 说明breaking change及受影响的调用方；
- 附测试、构建结果和未解决风险。
这套写法把决策空间收窄了。Agent可以集中处理重复、跨文件的修改，设计语义和兼容策略仍由人确定。
PR里要有证据，不收一句“已完成”
Cursor官方所说的“可评审工件”，落到组件库重构里，应该是一份带证据的PR。至少要有改动范围、token映射、测试结果、构建结果、截图差异、breaking change和调用方影响。
Cursor CEO把云端Agent的计算机使用能力形容为有了“按键盘的手”。它的实际价值就在这里：跑命令、看控制台、核对截图，再根据PR评论回改。测试失败也应原样列出，不能用一段乐观摘要盖过去。
人需要守住几类决策：
- Agent先执行测试、构建和基础自检；
- 资深工程师检查token语义、公开API、类型、依赖和最终合并；
- UI或UX工程师核对视觉与交互，重点看焦点、禁用、加载和错误状态。
基础组件可以抽检，直接影响业务流程的组件应逐个验收。具体比例由发布风险决定，不必套一个看似精确的固定数字。
合并也别急着全量替换。可以用feature flag或alias保留新旧版本，在内部系统先跑一轮，等调用方和视觉回归都确认后再移除旧入口。并行期多长，应跟着团队的发布节奏走。
四种改法最容易失控
直接删除“无人使用”的组件。 Agent给出的引用统计只能作为线索。先用codemod或仓库搜索列出真实引用关系，再由人确认是否删除。
让Agent自行决定token映射。 近似颜色很容易通过肉眼抽查，却会破坏设计语义。映射表应先写进MIGRATION_STANDARD.md。
在同一个Workspace里同时改样式和性能。 先统一token、props和类型，再单独处理memo、虚拟滚动或按需引入。两类改动混在一起，Diff和性能回归都更难判断。
只跑单元测试。 快照、单元测试、无障碍检查、Storybook构建都要覆盖；如果仓库已有构建产物大小检查，也应一并执行。组件库最麻烦的情况往往不是完全改错，而是只改对了一部分。
35%能说明方向，不能替团队做判断
35%的自主提交比例说明，Agent已经可以接手一段相对完整的执行链，而不只是敲出下一行代码。它无法替团队决定token语义，也不知道哪个历史API可以安全废弃。
标准、基线和任务边界准备好后，Agent最有价值的工作是把同一套规则执行到几十个文件，并把测试、截图和风险一起交回来。前端工程师的精力则放在定规则、拆任务、审Diff和准备回滚上。
把Cursor 3只当Tab补全，确实浪费；把它当成无人看管的重写器，也会把旧债成批放大。更稳妥的起点，是先让它迁完一个组件族、交齐证据，再决定是否扩大范围。
