当企业客户 75% 的代码完全由 AI 生成时，软件开发已迎来'星球大战时刻'。Cursor CEO 用震撼数据揭示：工程师正从代码编写者转型为'幽灵同事'管理者，而 agent 团队甚至能独立开发浏览器原型。这场变革不仅重构技术流程，更将颠覆创业门槛与教育体系。

你有没有想过，”写代码” 这件事的本质，可能已经彻底变了？不是那种小修小补的变化，而是从根上变了。就在最近，Cursor 的联合创始人兼 CEO Michael Truell 做了一次演讲，他分享的一组数据让我久久无法平静：他们企业客户里，一年前还有 85% 的代码是人类亲手写的，而现在，75% 的代码完全由 AI 生成，人类根本没有碰过那些语法。这不是某个激进的实验室数据，这是真实发生在企业里的事。

我把这场演讲反复看了好几遍，越看越觉得 Michael 说的不只是”AI 辅助编程”这件小事，他描述的是一个时代的终结，和另一个时代的开始。软件开发正在经历的转变，和当年图形界面取代命令行一样深刻，甚至比那更深刻。因为这一次，变的不只是交互方式，变的是”谁在写代码”这个最根本的问题。

这篇文章，我想借助 Michael 的演讲，认真梳理一下这场变革到底在哪里，以及我对它的一些深度思考。

软件开发的隐藏成本，从来没人好好说清楚

Michael 在演讲一开始讲了一个很有意思的类比。他说，演讲地点原本是一家电影院，当年《星球大战》就在那里首映。星球大战之所以在电影史上是个分水岭，不只是因为故事好，而是因为它背后的技术创新——一个叫 DijkstraFlex 的计算机控制摄像系统，可以让摄像机精确重复同样的运动轨迹，分层拍摄模型，然后合成为一个无缝镜头。没有人工介入，完全由计算机控制。

他用这个故事来说明一件事：技术的突破，往往就是某个行业”之前”和”之后”的分界线。他认为，我们现在正在软件工程领域经历同样的时刻。

但在讲那个”之后”之前，Michael 花了不少时间说”之前”是什么感觉。这部分我觉得特别值得认真听，因为大多数人对软件开发的复杂性是没有直觉的。

他说，几年前，构建软件的唯一方式，是用正式的编程语言一行一行地写文本。你脑子里有一个想法，但你不能直接告诉计算机你想要什么，你必须把这个想法翻译成极其精确的逻辑指令。if this then that，loop over this list，take this data and put it here。每一步都要说得清清楚楚，不能有任何歧义。

听起来只是有点麻烦，但实际上这件事的代价是极其高昂的。一个用几段话就能描述清楚的功能，翻译成代码之后可能是几万行。不是因为程序员在偷懒，而是计算机要求这种精确性。这是人类语言和机器语言之间天然存在的鸿沟。

但更大的问题不是写新代码，而是改旧代码。Michael 说，专业软件工程之所以难，很大程度上是因为”已有逻辑的重量”。你面对的不是一个简单的 Python 小脚本，而是几千万行代码组成的系统。你要改一个功能，可能需要在成千上万个文件里做协调一致的修改，同时还不能破坏现有的逻辑。

他说了一个让我很触动的比喻。他说，软件的复杂性是被藏起来的。如果你去看一座哥特式大教堂，你能从外表直接感受到建造它有多难——飞扶壁、石雕、穹顶，复杂性就写在表面上。但软件不一样，我们花了很大力气让它看起来简单，用户只看到几个按钮和少量信息，底层几千万行代码的复杂性完全隐形了。

这种隐形带来了一个长期存在的误解：产品经理和非技术人员总觉得，改一个小功能应该很快啊，不就是改几行代码吗？但专业工程师知道，他们真正在做的事情，是在几千万行代码里找到正确的位置、理解上下文、评估影响范围、做出修改、测试、再修改。这才是软件开发大部分时间的真实消耗。

我自己在做 AI 和 SaaS 产品的过程中，深切感受过这种成本。一个看起来”很小”的需求，工程师说要两周，你觉得他们在拖延，但其实他们花的大部分时间根本不是在写那几行新代码，而是在理解、评估和协调那几千万行旧代码。

三个时代：从 Tab 补全到 agent 管理

Michael 把软件开发的演变分成了三个阶段，这个框架我觉得非常清晰，值得好好拆解。

第一个时代，是”手工时代”。就是刚才说的那种，人类从头到尾一行一行写代码。几年前的世界就是这样，几乎没有 AI 的介入。

第二个时代，是”Copilot（代码助理）时代”。这个时代的标志是 GitHub Copilot 和 Cursor 早期的 Tab 补全功能。AI 开始介入，但方式比较保守——你在写代码，AI 在旁边看着，猜你下一步要写什么，给你一个建议，你按 Tab 接受或者忽略。这是一种人在主导、AI 在辅助的模式。

第三个时代，就是我们现在正在进入的”agent 时代”，以及它的进阶版”teams（团队）时代”。在这个时代，你不再是一行一行写代码，而是给 agent 布置任务，让它自己去完成大段大段的工作，甚至端到端地完成一个完整的功能。

Michael 拿出了一组 Cursor 内部数据来说明这个转变有多快。他说，在 2025 年的时候，Tab 补全和 agent 请求的比例发生了戏剧性的变化。2025 年初，Tab 补全的次数是 agent 请求的 10 倍——也就是说，大家还是主要在用 AI 做小的补全。但到了 2025 年底，这个比例完全反转了，agent 请求的数量已经超过了 Tab 补全，而且 agent 请求在一年内增长了超过 15 倍。

这个数据很有震撼力。但他随后说了一句话，让这个数据变得更有分量：一次 Tab 补全，可能只是几个字符或几行代码；但一次 agent 请求，通常是一大块工作，可能是几十个文件的修改，可能是一个完整功能的实现。所以 agent 请求数量超过 Tab 补全，意味着 AI 做的工作量其实已经远远超出数字本身所呈现的。

然后他分享了 Cursor 自己内部的数据，我觉得这是整场演讲最有说服力的部分。他说，在 Cursor 内部，目前已经有 30% 的 PR（pull request，即代码提交审核）是完全由 agent 从头到尾独立完成的，全程没有人类介入。这些 agent 有自己的计算机，运行在云端，可以连续工作好几个小时甚至几天，完成一个端到端的任务。

再加上刚才那个企业数据——一年内，企业客户的 AI 生成代码比例从 15-20% 跳到了 75%——你会意识到，这不是趋势，这是正在发生的现实。

工程师正在变成什么

我觉得 Michael 整场演讲里最重要的一个洞察，是关于”工程师角色在变”这件事。

他说，在 Copilot 时代，工程师还是代码的主要生产者，AI 是辅助工具。但随着我们进入 agent 时代，越来越多的工程师开始不触碰语法本身，他们开始变成”agent 管理者”。他们的工作，从写代码变成了：描述任务、分配给 agent、检查结果、给出反馈、再分配下一个任务。

他用了一个很形象的比喻来描述这个变化。他说，以前你有几千名人类工程师在维护你的软件。现在，你不只有这几千名人类工程师，你还有几万个”幽灵同事”（ghost colleagues）在并行地参与你的软件开发。你需要招募最聪明、性价比最高的 agent 同事，同时你也需要重新设计人类和 AI 之间、AI 和 AI 之间、人类和人类之间的协作方式。

这个”幽灵同事”的概念，我觉得是目前我听过对 agent 时代最准确的描述。它不是说 AI 取代了人类，而是说人类的工作方式发生了根本性的改变：你从一个生产者，变成了一个协调者和审阅者。

但他也非常诚实地说，这种转变如果做不好，会有很大的风险。生成大量质量低下的代码是很容易的——架构决策糟糕、bug 遍布、不可持续。所以工程师花在”review（代码审查）”上的时间越来越多，不只是看代码本身，还要看构建版本，测试行为，评估架构合理性。

这让我想到一个观点：agent 时代的工程师，对系统架构的判断力和对代码质量的鉴别力，反而变得比以前更重要了。以前你可能还能靠”写”来掌控质量，现在你需要靠”看”和”判断”来掌控。这是一种完全不同的能力要求，但同样需要深厚的工程素养做支撑。

从管理 1 个 agent 到管理几十个，这是两种完全不同的体验

Michael 在演讲里区分了两种不同的 agent 工作模式，我觉得这个区分非常重要，但很少有人真正说清楚过。

第一种，是现在大多数人用 agent 的方式：agent 在你的本地电脑上运行，你在旁边盯着，给它喂下一步的任务，等它完成，再给下一步。这个模式有一个很强的瓶颈——因为所有 agent 都在编辑同一个代码库的同一个版本，你很难同时运行超过三个。你基本上是在”保姆”这些 agent，一个一个地照顾它们。

第二种，是 Michael 描述的 teams 时代的模式：每个 agent 都有自己独立的计算机，在云端运行，自主地长时间工作，不需要你时刻盯着。这意味着你可以同时协调几十个 agent 同事，每一个都在处理自己独立的任务，互不干扰。

这两种模式的体验是天壤之别。前者是线性的、串行的，你是一个瓶颈；后者是并行的、异步的，你变成了一个指挥中心。

但这也带来了新的挑战。管理几十个并行工作的 agent，意味着你需要不断地切换上下文，不断地在不同任务之间跳转，判断优先级，协调冲突。这在认知上其实是很高的要求。它不再像以前那样，深度专注在一个问题上；而是要求你有更强的全局视野和任务编排能力。

我觉得这个转变对软件团队的组织方式也会产生深远影响。以前工程团队的分工，很大程度上是按照代码模块来划分的。而在 agent teams 时代，分工可能更多是按照”谁负责哪些 agent 的输入和输出质量”来划分的。团队里最有价值的人，不一定是写代码最快的，而是最会描述清楚任务、最能判断 agent 输出质量、最能设计 agent 协作架构的人。

一个极限实验：让 agent 用一周时间从零写一个浏览器

Michael 在演讲最后分享了一个实验，我觉得这是对 agent 能力上限最直接的一次探索，也是目前能看到的最有说服力的案例之一。

Cursor 的团队做了一个实验：能不能让 agent 团队，在完全没有人类参与的情况下，从零开始开发一个浏览器？整整一周，没有人类介入，agent 自主地运行，自主地生成 PR，自主地修复问题，自主地迭代。

结果是什么？一周内，这个 agent 团队生成了超过 300 万行代码，创建了大量 PR，最终构建出了一个”基本功能可用”的浏览器原型。演讲里展示了一段时间线视频，可以看到代码库的文件和文件之间的连接，在一周内从无到有被建立起来。

更有意思的是迭代的过程。第一天，这个浏览器甚至无法正常渲染 apple.com 的页面；到了第二天、第三天、第四天，渲染质量在不断提升；到了最后，它已经有了一个相当不错的网页渲染引擎。

Michael 说得很坦诚，这个实验还非常初期，不是 production-ready（可以投入生产）的状态。但他想说的是：这个方向是可行的。完全自主的 agent 团队，在足够长的时间和足够的并发数量下，可以完成以前只有人类团队才能完成的系统级工程任务。

我对这个实验的理解是：它不是在证明”AI 可以取代程序员”，而是在探索一个问题的边界——在没有人类参与的情况下，agent 团队能走多远？这个边界在不断扩展，而且扩展速度比我们想象的快很多。

我对这一切的深度思考

听完 Michael 的演讲，我思考了很久。我想说几个自己的认知，有一些可能和主流观点不太一样。

第一个认知：我们对”写代码”这件事的价值判断，需要根本性地重新校准。

在过去几十年里，”能写代码”是一种非常稀缺的能力，程序员的高薪很大程度上来自于这种稀缺性。但如果 75% 的代码可以由 AI 生成，那么”写代码”本身的稀缺性就在快速消退。真正稀缺的，正在变成另一种能力：知道要构建什么、知道如何把一个模糊的目标拆解成清晰的任务、知道如何判断 agent 的输出是否真正解决了问题。

这种能力，我觉得可以叫做”系统性思维加产品直觉”。它不是一种新能力，但它的重要性被大幅放大了。以前你有系统性思维，但不会写代码，你就只能做产品经理；现在，你有系统性思维，能有效地给 agent 布置任务，你就能独立构建相当复杂的系统。这是一个巨大的解放。

第二个认知：agent 时代最大的瓶颈，不是技术，而是信任。

Michael 说，现在很多工程师花大量时间在 review 上。为什么？因为他们还不完全信任 agent 的输出。这不是坏事，这是合理的。但这种信任需要被建立，而建立信任需要时间和数据。

我觉得，未来两三年里，一个很重要的发展方向，是建立一套围绕 agent 输出的”可信度评估体系”。不只是测试代码能不能跑，而是评估它的架构是否合理、是否有长期的可维护性、是否引入了隐性风险。这个评估体系，会慢慢从依赖人工 review，变成有 AI 辅助的半自动化验证。到那个时候，整个开发-验证-部署的循环速度，会进一步加快一个数量级。

第三个认知：那个”幽灵同事”的比喻，暗藏了一个很深的组织管理挑战。

Michael 说，你现在不只有几千名人类工程师，还有几万个幽灵同事。这听起来很美好，但我觉得它带来的挑战被严重低估了。

管理几千名人类员工，我们已经积累了几十年的经验，有绩效体系、有晋升路径、有沟通规范、有组织文化。但管理几万个 agent 同事呢？你用什么衡量一个 agent 的”绩效”？你如何设计 agent 和 agent 之间的协作规则？你如何处理 agent 产生冲突或者做出错误决策的情况？

这些问题，软件工程领域还完全没有成熟的答案。我觉得，未来几年会出现一批专门解决这些问题的工具和方法论，类似于当年 DevOps 解决了持续集成和持续部署的问题。那些率先把这套方法论做出来的公司，会有巨大的先发优势。

第四个认知：这场变革对”谁能做软件创业”这个问题的影响，是最被低估的。

过去，做一个有竞争力的软件产品，你至少需要一个强大的技术团队。一个人或者两个人的团队，想构建一个复杂的系统，几乎是不可能的，因为工程产能是硬约束。

但在 agent 时代，这个硬约束正在被大幅软化。Michael 的数据显示，30% 的 PR 已经是由 agent 端到端完成的。如果这个比例继续提升，意味着一个有强产品直觉和系统思维的个人，可以借助 agent 团队完成以前需要十几名工程师才能做的工作。

这不是说工程师不再重要，而是说进入门槛在下降，创业团队的最优组合在改变。我越来越相信，未来最厉害的创业公司里，会有一批是由极少数人但配备极大量 agent 资源构建出来的。这是一个完全不同的创业范式。

第五个认知：我们需要重新思考”软件教育”这件事。

当 75% 的代码由 AI 生成，你还需要学编程吗？我的答案是：需要，但学的东西变了。

以前学编程，学的是语法、是算法、是如何实现。这些东西的重要性没有消失，但它们的优先级下降了。更重要的，是理解系统是怎么运作的，是能够在高层次上描述清楚你想要什么，是能够发现 agent 产出的问题出在哪里。

这就像是学开车和学制造汽车的区别。你不需要懂发动机的每一个零件，但你需要知道什么时候刹车，什么时候换道，以及当车子发出异响的时候，那个声音意味着什么。

软件教育，需要在这个维度上做一次大的重构。那些最先理解这件事、并且重新设计课程的机构，会培养出在 agent 时代真正有竞争力的工程师。

Michael 最后说了一句话，我觉得可以作为整场演讲的总结，也可以作为我这篇文章的结尾：软件工程正在经历它的”星球大战时刻”。在那之前，和在那之后，是两个完全不同的世界。我们正好站在这个分界线上。