欢迎收听十字路口，我们关注新一代 AI 技术浪潮带来的行业新变化和创业新机会。十字路口是乔布斯对苹果公司的一个比喻，形容他站在科技与人文的十字路口，伟大的产品往往诞生在这里。AI 正在给各行各业带来改变，我们寻找、访谈和凝聚新一代 AI 创业者和 AI 时代的积极行动者，和他们一起探索和拥抱新变化、新的可能性。
Koji
我是十字路口的柯基，联合创办了街旁、新世相和糖岛，发起了 AI Hacker House 这个新一代 AI 创业者的社群空间。我相信科技，尤其是 AI，是我们这一代人最大的价值创造机遇。欢迎大家找我聊天，碰撞想法，链接下一个可能性。
Ronghui
我是十字路口的荣慧，在美元 VC 工作过，也做过五年的硅谷驻站记者，关注科技发展和商业故事，也欢迎大家找我聊天、交流。
本周我们来聊一下 AI coding。AI coding 是今年整个 AI 领域最热的话题之一。最开始是 Cursor，年营收做到了 5 亿美元，估值也疯狂飙升到 100 亿美元，成为今天硅谷最炙手可热的独角兽。
模型公司 Anthropic 今年发布 Claude Code 之后，收入增长曲线突然变得非常陡峭，甚至超过了 OpenAI，当然它的基数可能小一点。从辅助编程插件，到深度整合的 IDE，再到可以独立完成编程任务的智能体，各种形态的 AI coding 层出不穷。大量资本和顶级人才都在进入这个领域。
黄仁勋曾经说，人类的语言很可能就是未来的编程语言，我们不再需要程序语言了。这句预言感觉正在加速成为某种现实。
在国内，AI coding 同样非常火热。差不多 2 个月前，阿里发布了 Qoder。我们身边很多资深开发者对 Qoder 的评价都很高，尤其是赵春晓，他也上过我们的播客。有一次他告诉我们，他觉得 Qoder“炸裂式地好”，尤其是对于存量代码的可视化能力，也是其他 AI coding 产品没有提供的。
因此，本期《十字路口》我们非常开心地邀请到了阿里巴巴 Qoder 的负责人丁宇，花名叔同，和我们一起聊一聊，在看上去已经一片红海的 AI coding 战场里，Qoder 诞生的故事和你们的一些思考。叔同，你好，欢迎来到《十字路口》。
丁宇
很高兴来到《十字路口》。
Koji
我们还是从快问快答开始。请问叔同，你的年龄？
丁宇
42 岁。
毕业院校？
丁宇
吉林大学，计算机专业。
给我们用一句话安利一下 Qoder。
丁宇
Qoder 是一个面向未来的产品，所以它定位为下一代智能体编程平台。
在 Qoder 之前，你在做什么？
丁宇
我加入阿里 16 年了，做过淘宝的架构，也做过双十一的技术负责人。过去 10 年主要围绕容器化、云原生，包括阿里的一些云原生技术演进，以及相关技术的产品化。
你的 MBTI 和星座分别是什么？
丁宇
我的 MBTI 是 INTJ，架构师，跟我的工作也非常相像。星座是天蝎座。
目前 Qoder 的用户规模和商业化进展怎么样？
丁宇
我们上线 2 个月了，现在已经有 50 万活跃开发者。商业化也比较符合预期。
Ronghui
可不可以请叔同先给我们讲一讲，今天打得火热的 AI coding 赛道，整体的全景图是什么样的？也请你给我们科普一下。
丁宇
1. AI Coding的三条路径
好的。首先，大家有一个行业共识：大语言模型非常擅长 coding。于是，不同团队开始在这个方向打造产品。
很自然地，大家会思考，如何把一句话的需求、一个想法或者一个 idea，实现成一个软件和服务，或者一个网站。比如 Lovable、Bolt.new 等产品，往往服务于创作者，也就是泛开发者。
但这种产品可能会带来一些问题，就是它的生命周期可能比较短暂。每个人都有想法，每个人都可以实现，可能几美元就能实现一个自己的软件。但这个软件的生命周期能够存活多久？如果它只服务于自己的需求，就没有办法长时间生存。
所以自然而然地，就出现了一些能够把自己的作品变成平台，让别人来购买和使用自己作品的平台。国内也有团队在做类似 Replit 这样的产品。
在这个领域，我们把它定义为从零到一，通过 AI coding 去做软件和服务的一类产品形态。
还有一些产品，比如今天讲的 Cursor、Claude Code，就是刚才所说的集成式、一站式的工具。它们解决的是什么问题？更多是为专业开发者提升效率。
今天这个行业中有 3,000 万专业开发者，他们每天都在生产大量代码、软件和服务，产生商业价值。大语言模型的编码能力已经超过了人类个体，问题在于，如何把它运用到人类个体的工作中，产生更大的价值和生产力，提升程序员的产能。
从这个角度，就会出现一些专业工具。它们在不同场景下提供能力，比如代码补全、智能体协作开发，甚至自主编程，以不同形态解决这个领域的问题。
这类产品往往解决的是从一到十，或者从十到一百的问题。因为每一个软件开始产生商业价值以后，就需要深度理解、长期迭代，以及长生命周期的维护过程。它对 AI coding 产品的要求就不一样了。
所以我们可以看到，很多用户对 AI coding 产品有一个典型用法：先用 Lovable 创造一个服务网站，等它开始投入商业化以后，再用 Cursor 对它进行修改。因为它从一到十、从十到一百以后，复杂性上升了，一个简单的一句话就能生成服务的产品就不太适用了，它走向了专业领域。这是第二类产品。
整个行业中还有 Devin 这一类产品，它锚定的不是为专业开发者提升工作效率，而是直接提供一个数字员工，实现人力替代。
人力替代的核心价值在于，我能够像一个正式员工或者实习生一样接受完整任务，长时间工作，协调各种角色和资源，最后交付一个完整结果。这在它们刚推出的时候，是一种比较超前的设计。
今天我们看到，类似 Cursor、Qoder 这样的产品已经逐步具备了这种能力。所以这几种形态会走向融合：服务于专业场景，解决复杂任务，并且能够长时间工作。
基本上，我们可以把它们分成几个方向：从零到一，从一到十，以及从十到一百。
Koji
但最后你会觉得，大家会大一统吗？
丁宇
非常有可能大一统。它们的核心需求，都是通过 coding 提供一种软件服务，满足一个业务场景，创造一个商业价值。
未来大家在能力上会做得很强，形态上会更加多元化，最后就会走向大一统。
Ronghui
我好奇一个问题：在你说的最后可能融合的结果里面，模型会起到什么样的作用？因为很多人会说，Cursor 终有一天会做自己的模型，这个影响其实还是非常大的。
丁宇
从我们对各个产品和基模厂商的模式分析来看，这也是为什么我们认为阿里有机会做出更强的 AI coding 产品，因为我们有模型能力。
没有模型能力，就会被一些人定位为“套壳”的产品。它的成本比较高，也不能跟模型进行联动优化。
我们可以看到，这对产品的估值、收入以及成本的影响都很大。但如果有模型，就可以控制整个联合优化的过程，从性能、成本和效率上进行优化。另外，对企业利润也会有很大的改变，因为它不会成为一个帮模型创造流量的服务。
所以我们判断，它们一定会提供或者构建自己的模型。
Koji
所以你也觉得 Cursor 一定会做自己的模型？
丁宇
对。
我们现在录播客是 10 月中旬，这期播客应该会在程序员的节日 10 月 24 日播出。Qoder 是 2 个月前，也就是 8 月份发布的。
你们发布的时候，整个赛场已经是一片大红海了。当时你们选择了怎样独特的竞争角度和战略，去在这么激烈的战场里迅速切出自己的赛道？
丁宇
2. Qoder进攻真实软件
这是一个很好的问题。我们推出产品的时候，整个行业中的相关产品已经非常多了，确实是一个红海市场。但我们对这个市场和产品定位有自己的判断。
还是从刚才的逻辑来分析。Vibe coding 被大家广泛接受，大家会觉得特别惊艳：一句话就可以创造一个软件服务。但我们发现，95% 以上的专业开发者都在维护真实软件。
什么叫真实软件？我们认为，真正能够产生商业价值的软件，一旦产生商业价值，就要为用户和客户负责。它会变成非常严肃的修改、迭代和演进，不能有任何故障问题。
而且它会有很多历史积淀，可能已经存在了 5 年、10 年。这就要求 AI coding 工具对它的历史非常了解，不能乱改，不能发挥想象，也不能产生幻觉。
所以我们看到，这是一个价值高地，因为它是真正在支撑信息产业、产生价值的软件服务。今天很多工具的切入点都是从 Vibe coding 开始做，而我们另辟蹊径，从面向真实软件开始定位和构建产品。这是我们的第一个切入点，也就是与众不同的地方。
另外，我们也看到了一些趋势。最开始，大家以人为主导写代码，是辅助编程阶段：人负责写，AI 帮忙填一些空。这是业界比较常见的状态，比如 Tab 补全。
第二个阶段是协作式编程。人和智能体可以同步互动，比如帮我补一些文档、注释，补全一些功能，或者把测试补全。人和智能体通过互动，共同完成任务，形成一种合作关系。
但随着模型和智能体的发展、演进，会出现一种新的合作模式，我们叫 AI 自主编程。AI 加上智能体，可以形成一个数字员工，完整地、异步地完成一大块任务。
这相当于开发者拥有了一个助手，拥有了团队里的同事，甚至拥有了一支 AI 军团，可以整块整块地完成任务。我们看到，这个趋势已经到来了。
所以我们的产品有两个核心定位：一个是面向真实软件，另一个是智能体编程平台。智能体编程平台就是“我不干，智能体干”。这是我们对未来开发协作模式的定义。
从这两个点切入，Qoder 就会和现有产品有非常不同的呈现。
这个洞察也是从用户、商业和市场中来的，自下而上发现需求。但为什么一开始没有那么多人去做维护软件这件事？是因为它不够酷炫，还是因为比较困难？
丁宇
我认为两个原因都有。每个人都喜欢做创造性的工作。一句话就可以生成一个自己非常喜欢、非常漂亮的网站，这会让人非常兴奋，也有很强的获得感，对产品也会带来很好的好感。
这个领域中，要把大语言模型的能力发挥出来，本来就会出现各种形态。正因为我们是后来者，第一次的果实已经有很多人在摘了，所以我们希望直接进攻价值高地，去做真实软件的场景。
这里面还有一些区别。刚才我们讲到开发者工作的阶段，是从辅助到协同，再到自主。每一个阶段我们都会做。虽然我们定位为下一代自主编程平台，但并不是说其他能力就不做，因为我们的核心定位是服务最广谱的开发者。
不管开发者处于什么阶段，我们都希望服务他们。今天中国开发者和海外开发者所处的阶段不一样，中国的模型和海外的模型所处的阶段也不一样。
因为我们有不同产品，也和客户有非常多互动，所以能够看到大家使用习惯上的差别。以中国市场为例，很多人还是以代码补全和问答为主：有不明白的地方，让模型回答，回答完以后自己修改。
海外已经进入了另一个阶段，开发者已经不怎么自己干了，更多是让模型帮忙全部改掉。所以大家处在的阶段还不一样，这也形成了针对中国情况的一点差异化。
Ronghui
Qoder 是一个从第一天就做全球市场的产品，对吧？并没有特别强调中国版和海外版，而是一个版本。
丁宇
是的。我们必须服务于广谱开发者，所以这几类功能都要有，用户可以按照自己的使用习惯组合产品能力。
哪个功能用得多，就多使用哪个功能。比如代码补全用得多，就多用补全；Ask 用得多，就多用 Ask。如果中国开发者快速拥抱最先进的生产力，也可以直接使用自主编程，因为这些能力我们都有。
所以，一方面我们要服务广谱开发者；另一方面，我们的产品形态会比较多元化。首先我们有 IDE，也发布了命令行，还会发布 JetBrains 插件。我们也会在不同场景里集成使用。
比如今天有一些工作流水线、各种内部平台，都可以使用编程智能体来委派任务、跟进进度、校验结果。我们还会从不同切面、不同形态，以及不同输入和输出方式上去做支持，比如图片输入、语音输入等多模态能力。
我们希望在这样一个产品平台上，以不同模态、不同形态形成不同触点，满足 coding 和制造软件的多元化需求。这就是我们希望呈现的产品。
Koji
用户最常拿你们和谁比较？
丁宇
现在还是 Cursor 比较多。但 Cursor 规模比较大，我们还处在追赶的过程中。
你们和 Cursor 最大的差异化，第一是存量代码的可视化，让大家更好地维护已经写好的软件；第二就是刚才说到的智能体，它可以更独立地完成编程。为此你们也做了很多工作，包括比较倡导 spec-driven，也就是需求文档驱动。
这可以具体讲一讲吗？当你说到需求文档驱动时，它对应着怎样的工作流和产品功能？
丁宇
3. Spec驱动智能体协作
这是一个逐步进化的过程。以前我们讲提示词工程，后来讲上下文工程，本质上都是如何构建更好的上下文，让大语言模型在可控的情况下做出更大的贡献和结果，工作更长时间。
为什么一定要用 spec-driven 的方式驱动智能体？因为我们要让它做更大块的任务，就必须把需求说清楚。需求包括人类需要提供的内容：需求洞察、业务逻辑设计、技术模式和技术架构的选择，以及设计规约。
还要明确如何设计模块，实现要求是什么。相当于定义出技术文档和业务架构设计。把这些文档设计出来以后，这也是一个和模型交互的过程，模型就能理解：我接到了一个什么样的任务，这个任务具体有哪些需求，有多少步骤。
这其实是原来人与人之间协同方式的一个映射。比如我们 3 个人要开发一个软件，也大致是一样的：你是老板，提出一个需求；我们进行调研，搞清楚到底要什么；选择技术；把需求写清楚，把 PRD 写详细；明确怎么验收；再进行上下游、数据和业务对接。
把这些东西写清楚以后，程序员来实现，实现完以后再推向市场，根据反馈进行迭代。这就是我们把原来人与人之间协同的流程，映射到和大语言模型交互的过程中。
这样一来，智能体就能接收到详细的 spec，异步、长时间地自主完成需求。同时，它还可以自主验收，校验结果是不是符合开发者的预期。所以 spec-driven 是让智能体长期工作的必然选择，它对应的是传统团队开发中人与人之间交流的真实流程。
这里面也有一些小技巧。现在人其实也不愿意写需求文档，但大语言模型不但擅长写代码，也很擅长写需求文档。
Ronghui
我注意到，在使用 Qoder 的过程中，我给它一个想法之后，它第一步是帮我写文档。
丁宇
为了写好 spec 文档，我们构建了一些智能体，但这个能力没有显性地呈现在功能模块里。
用户先像老板一样，写一句话需求。然后，写 spec 的智能体会把它拆解成非常标准的设计文档。用户可以在里面做一些微调，或者进一步提出要求，最后确认一遍文档。
如果用户认可内容，就可以开始执行。这样就能驱动智能体长时间执行任务。
Koji
我们之前试用了 Wegic 的一个新产品，它也有类似的理念：把需求文档、整个 UI，以及它的情绪板，作为常驻在无限画布角落里的资源。之后再做任何页面和改进时，它都会记得去读取这些东西，就像做网站的“宪法”一样，不管做什么都要先读一读宪法。
丁宇
这也是一种比较常用的约束智能体行为的方式。我们这里也是一样的，比如系统提示词和记忆，都是为了让产品更符合人的习惯和需要。
我们给开发者提供了很多趁手的工具。有哪些规则，什么事情不能做，什么事情应该怎么做，都可以像你说的“宪法”一样写进 rules 里。智能体在执行过程中就不会跳出这个框架。
就像每个公司先约法三章，我们也提供了这样的开放接口给用户。
除了对传统开发流程的映射，有没有什么新的调整或变通？
丁宇
4. AI时代重做开发心流
在我们看来，确实形成了基于 AI 时代的一种新的开发方式。
以前构建工具时，最看重的一点往往是不要打断用户的心流，要让用户不受干扰地、整段整段地工作。比如 JetBrains 或 VS Code，核心理念都是不打断用户的心流：所有工作都在一站式平台中完成，让用户能够心无旁骛地持续工作。
但到了 AI 时代，心流其实很难维持。工具变多了，用户开始结对编程。结对编程必然有一问一答，有互动，也会有一定拉扯：你做得不太满意，帮我改一下；或者我再提一个新的要求。
因为工作变成了两个人在做，或者一个人带着一个小队在做，所以工作方式会发生变化。过程中还要约束智能体的行为，rules 就是一种约束。
我们还提供了一个智能体。为了表现得更好，它会不断归纳开发者的行为习惯：开发者想要什么、不想要什么，哪些东西会接受，哪些东西会拒绝。它把这些归纳成新知识，写进记忆里。
但对用户来说，这些知识或记忆不一定完全符合自己的意图。可能今天只是某种特殊情况，所以用户还可以编辑和修改记忆。
另外，为了节省成本，用户可以压缩上下文、切换模型，或者重启会话。用户会不断考虑这些事情，所以心流已经发生了变化。
在产品构建过程中，我们要取得一个平衡：既要提供趁手的工具，让用户拥有很高的生产力，又不能让他总有被打断的感觉。这并不容易，尤其是心流被打断的原因很难对抗。
所以这时候要给用户掌控感。如果开发者掌控着整个局面，能够约束智能体的行为和走向，虽然感受变了，但他的实际感受仍然是好的。这也是为了适应 AI 时代，人的工作方式必须发生一定变化。
Ronghui
可以举一个具体例子吗？为了帮助用户进入心流状态，你们做了哪些特别的功能，或者做了哪些特殊取舍？
丁宇
其实每一个功能我们都会考虑：这里是不是会让用户觉得被打断，是不是会让用户有理解成本，够不够自然。
我们现在觉得，被打断或者违反心流体验并不是最重要的，因为新的模式必然是这样。但有一点很重要：不要让用户有理解成本。
如果一个东西一眼看过去，用户看不懂，说明你的传达、行为和交互设计让人产生了理解成本和思考成本，这就有问题。对于开发者来说，一切都必须特别自然。
所以我们所有功能都围绕这些原则来做。
我刚做产品经理那会儿，大概 15 年前，有一本很畅销的书叫《别让我思考》，英文是 Don’t Make Me Think。它讲的用户理念就是一句话：不要让用户思考。
今天我们做的一些功能也是一样的。包括你可能知道，我们没有提供模型选择，其实也是贯彻这个理念的一种实现。
Koji
这确实很有趣。大家会默认你们使用的是通义千问的模型，但我看你们官方网站上说，谁的模型效果好就用谁，而且不让用户选择。
丁宇
我们对产品有一个最高原则：整合全球最优的模型，给用户最好的效果。这里面既会有海外模型，也会有千问模型。
在什么场景使用什么模型，我们认为这也是不打断用户心流的体现。因为如果像 Cursor 一样，把 40 个模型放在那里，对用户的打断其实很强。
用户要形成知识：什么模型有多贵，擅长做什么，我在什么场景用谁；还要不断测试、排序。可能下个月模型发版以后，能力又变了，还要重新测一遍，在心里重新排序，再在合适的场景切换模型。
这种打断是很要命的。大家最后变成了模型选择器、训练师或者测试员。
Ronghui
但会不会有些用户希望自己拥有掌控感？尤其是市场上出现了一个新模型，比如 Claude 5.0，大家都说它石破天惊，效率提升了 10 倍，所有人都想用。如果在 Qoder 里不能直接选择 Claude 5.0，用户可能会很难受，甚至流失。你怎么看？
丁宇
我们用结果给客户一个答案：你在 Qoder 里问同样的问题，和那些显式使用 Claude 5.0 的产品相比，结果有没有差异？我们用结果说话。
AI coding 类产品最重要的其实是 3 个点，也就是一个“不可能三角”：性能、效率和成本。你要想又快又便宜，可能性能就不够好；你要想又快、效率又高，也就是性能又好，成本可能就比较高。
所以我们一直在权衡这件事情。对于你这个问题，我们的看法是：最好的模型出现了，别人可以选择，我们没有选择，但我们的结果一定不比对方差，甚至要比对方更好。
Koji
这个不可能三角有一天可以变成可能吗？
丁宇
这里面的核心技术挑战就是上下文工程。今天谁能够以更优秀的方式构建上下文，谁就能解决成本、性能和效率的问题。
另外还有模型选择器。我们有一个理念：机选要优于人选。这是第一个理念。第二个理念是，平台知识要优于个人知识。
我们有海量用户和海量使用数据，更容易从宏观上、从统计学上知道什么样的场景适合什么模型。
为什么说机选优于人选？人来选模型，一方面会打断心流；另一方面，人不可能每一次对话都切换一个模型。一般来说，用户新起一个会话时选一个模型，之后每问一个问题不会换模型，因为人不可能每问一个问题就换一次模型。
如果每问一个问题都换一次模型，人就变成机器了。但由系统来选择，就可以做到每一个问题都使用最适合的模型，给用户更好的效果。
这也是我们和友商产品在理念上不太一样的地方：我们用效果说话。
你们会用什么方式，让一个不了解 Qoder 的用户知道你们确实能达到这样的效果？
丁宇
我们下一步会开放评测集，也就是真实软件评测集。用户可以在一个公共数据集里，在不同产品上比较效果，包括耐用度、成本消耗、完成任务的时效性，以及最后成果的满意度。
理念归理念，产品上要呈现出这样的效果，还是要靠评测。用户体感也是一种评测，但评测集会更加客观和数据化。
这个产品对阿里意味着什么？
丁宇
5. Qoder押注全球市场
之前我们的 CEO 吴泳铭也讲过，coding，或者说大语言模型的 coding 能力，是走向 AGI 的必经路径。
对我们来说，还是要通过 Qoder 这样的产品，端到端地提升大语言模型的 coding 能力，服务更多开发者和更多场景。所以，它是阿里整个 AI 战略的一部分。
具体能够做多大贡献，还是要看产品能够做到多大的市场占有率。现在已经非常好了，开了一个很好的头。
你来负责这个产品的时候，内部有没有一个 promise：要把它做成什么样子？
丁宇
我们的愿景是做到世界前三。
现在排第几？
丁宇
现在还远远没有到排名的时候。它就像一场马拉松，大家其实刚刚跑了 1,000 米，还要看后劲、资源情况和整体加速度。
一般听到“前三”，第一反应就是第三。其实前三和第三差别不大。
丁宇
对，前三和第三差别不大。但我们认为这是一个愿景，因为市场竞争太激烈了。
我们的信心还是来自独特优势。虽然 Qoder 刚发布 2 个月，但开发者已经非常认可。我们初步定下的产品定位，是做价值高地、做真实软件，也得到了用户非常积极的认可。
另外，我们对阿里巴巴、模型、技术人才和技术把控力都有信心，也能够和相关兄弟团队进行端到端优化，提升产品整体的性能、效能和成本，增强综合竞争力。
我们还会在产品呈现形态和用户工作界面上做大量创新，把底层模型能力、中间的上下文组装构建能力，以及工具使用能力，整合成更有竞争力的多元化产品形态。
从这个角度，我们整合了很多优势。和友商、包括国际上先进产品相比，我们认为自己还有很大的后劲和比较大的优势，这也是信心的来源。
你们从立项到上线，大概用了多长时间？
丁宇
是在 2025 年发生的，非常快。
Qoder 在 8 月发布。之前阿里已经有一个很成功的编码产品，叫通义灵码。为什么在有通义灵码的基础上，还要再做一个 Qoder？
丁宇
通义灵码在国内已经做了 2 年多，得到了开发者非常大的喜欢，在插件市场的占有率也是中国第一。
所以我们更多讨论的是一些基本面的选择：以什么平台去做全球化，以什么形态去做，是插件、IDE、命令行，还是其他形态；是智能体单独输出，还是和产品结合。
另外还有模型选择：到底使用纯自家的模型，还是整合全球各种模型。我们对这些问题都做了深入探讨。
最后促成我们做决定的，还是一些观点和判断。我们从市场出发，认为开发者一定会选择最好的、最优质的、最懂使用习惯的、能够给他带来最大价值的产品。
所以我们决定做今天 Qoder 这样的形态。通义灵码定位为服务中国市场的产品，而 Qoder 是面向全球市场的产品。
这样做当然也是为了给自己的模型争取时间。如果一年内阿里的模型变成全球最好的模型，那么 Qoder 里本来就是混合模型，也能直接使用。但我们不能等模型成为世界第一以后再去服务开发者，那样就没有机会了。
所以我们先服务开发者，也给自己的模型争取一些时间。确定这条路径以后，大家的干劲都非常足。
我们对这个市场足够了解，也打造过比较成功的产品，有这样的经验。
所以你们是一个完整的团队，这个团队不是从零开始组建的？
丁宇
对。团队之前就在做通义灵码，当然也有一些做其他工作的同学一起加入进来。
所以起步比较快，大家也都很拼。我们都比较信奉技术改变世界。当真正遇到一个能够改变世界的技术，或者把这项技术辐射到全球，去改变很多开发者、创造很多价值的机会时，大家都会非常投入。
Ronghui
我比较好奇，项目立项时，是你主动要求来的，还是组织安排的？
丁宇
可以说是双向奔赴。通义灵码本身是一个很不错的成果，把它延伸成面向全球的产品，我们认为非我们莫属。
我刚才突然想到，Qoder 从品牌上看，似乎希望不要有那些所谓的冠名，前面是什么、后面是什么，而是给人一种相对轻的感觉。大家想到的是一个工具，而不是先想到阿里巴巴。
丁宇
这也是我们为什么叫 Qoder。Qoder 是 coder 的谐音，代表程序员。
我们的定位不是因为哪个模型诞生，也不是因为哪个平台诞生。它就是一个程序员，是你兜里的程序员、你家里的程序员，也是你团队里的程序员。
所以它没有这方面的限制，才会有更大的发展空间。
Koji
方便介绍一下，Qoder 在阿里整个 AI 战略里处于什么位置吗？
丁宇
很重要的一点，是我们获得了很多资源支持，包括目标解绑和团队效率方面的支持。
我们需要卸掉一些包袱，面向市场去看友商怎么做、别人为什么跑得快，然后自己也要跑得快。阿里在这些方面给了我们非常大的支持。
很多人会担心，大厂的流程、机制和约束条件会非常复杂，一定会拖慢效率，尤其是从零到一的产品。
我们认为，Qoder 是内部创新，也是内部创业，同时获得了非常大的开放度。这是最好的支持。
Qoder 发布时，大家就说 BAT 三家都发布了自己的 AI coding 产品。海外 Anthropic 也在做 Claude Code，OpenAI 也有 Codex。
从你的视角看，不管国内还是海外，创业公司还有机会吗？如果有，机会在哪里？
丁宇
从今天来看，创业公司的机会会越来越少。
虽然 AI coding 是大语言模型的封装型产品，但它同样需要比较大的资本投入。要形成一定规模，团队投入和成本投入都很大。
另一方面，创业公司不占优势，平台的优势会越来越大，因为平台有自己的飞轮效应。
我们以 Claude Code 为例。Claude Code 和 GPT-5 Codex 有先天优势，因为它们使用自己的模型，成本比较低。比如 Cursor 使用它们的模型，成本可能要高几倍。
所以模型厂商可以做到性能好、成本低、效能也不差。对它们来说，自己的平台和集群属于沉没成本，但卖给 Cursor 时一分钱也不会少，于是它们自然会形成优势。
但早期的创业公司有很大的机会。Cursor、Lovable 也是这样，它们早期定义了一个品类和形态，有先发优势，再加上迭代速度，就可能让后来者追不上。
今天这个时点，如果再有创业公司进入，就一定要创造新的模式。如果在同类型产品上，和大厂、模型厂商以及拥有先发优势的厂商竞争，就没有什么优势。
国内你觉得谁做得比较好？
丁宇
我觉得我们做得很好。
除了你们呢？
丁宇
其实也没有几家了。我觉得它们都是值得尊敬的对手。
这个领域正因为大家有不同理念，构建了不同的产品形态，所以会满足不同开发者的诉求。本质上，它不是直接竞争，而是在一个非常大的领域中撬动一部分用户。
以专业开发者为例，全球可能最多覆盖到三分之一，还有三分之二没有覆盖。所以今天还没有到竞争特别激烈、大家高度同质化、所有方面都卷极致性价比的阶段，产品形态仍然是百花齐放。
你觉得 AI coding 产品的用户留存会是一个担心点吗？因为代码库在那里，今天我可以用 Qoder，明天也很容易切换到 Cursor。如果 Cursor 接入一个更强的模型，用户可能就会切换。
丁宇
我们内部一直讨论一个问题：Repo Wiki，也就是代码可视化的材料，是不是只有在 Qoder 中才能看？
最后我们决定，这是不可能的，它一定要在哪里都能看，而且一定归属于用户，用户可以把它导出去，这个资产属于用户。
当然，我们也会思考，如何让用户留在平台上。但我们认为，差异化能力和开放性会赢得用户的好感和认可。
第一，我们要做出差异化能力；第二，我们要做出开放性。我们认为这才是最大的黏性。
6. Repo Wiki还原代码历史
Ronghui
说到 Repo Wiki，很多好评的来源也是因为你们针对存量代码。比如我突然接手一套可能有 100 个人写过的代码，怎么理解它，怎么修改它，同时保证不要改一个 bug 又引出 100 个自己都不知道从哪里冒出来的 bug。
这是你们提供的一个很大价值。Repo Wiki 听起来很容易，但我想象中做起来可能没有那么容易。存量代码可能又多、又乱、又杂，你们是怎么把它整理出来、还原出来，让用户清晰理解这些存量代码的？
丁宇
你说的又乱、又杂、比较复杂、工作量比较大，这些工作对于大语言模型来说其实都比较擅长。第一个判断是，我们的实现都是用大语言模型完成的，但我们会构建自己的相关智能体。
从对开发者日常工作的理解来看，所有工作的沉淀中，最实时、最新鲜的就是代码。
比如老板提出一句话需求，我们把功能改掉，但大家不会把文档再补一下，因为这件事不经济。代码一定会改，而代码呈现出来的业务形态，一定是老板和产品经理需要的。
随着这样的演进，最后文档就已经失真了，没有参考价值。所以我们所有工作的出发点都是代码。
代码也不只有一个切片，它还有提交记录和历史版本。我们会分析当前切片、某一个历史切片，以及中间过程中的变更记录。
基于这些信息，我们形成对整个代码库的理解，包括它的设计、背后的思考、经历了多少次迭代、时序和关系、业务架构，以及整个业务逻辑，然后把这些东西生成出来。
这样就有了一个超脱于以前所有文档、价值更高的文档。而且它的每一行、每一个字都是大语言模型生成的，也没有给人带来新的工作量。
随着代码库发生变更和提交，它还可以刷新文档，实时、增量地更新。所以这个文档可以说是系统中最有价值的文档，但它是 AI 生成的。
这听起来确实非常有需求。我们学计算机时，老师第一课就说要把文档写好，至少要把注释写好。
我刚开始工作时，经常在复盘会上听工程师说，这次注释没写好，所以效率不高。然后大家找一个解决办法：下一次互相 review 代码，确保对方的代码写了文档、写好注释。
但往往事与愿违。在人性和老板对速度的要求面前，几乎没有团队能够真正维护一份好的文档。这是一个非常显性的需求。
为什么之前 Cursor 没有做，或者其他友商没有做？这是第一个问题。第二个问题是，如果有一天它们想做，也能做到你们的程度吗？还是说你们有一些秘密配方，或者独到的工程解决思路，让别人追赶起来没有那么容易？
丁宇
肯定没有那么容易。实现这个功能本身可能比较容易，但还是回到刚才那一点：如何多快好省地实现，既便宜、效果又好，还能理解整个历史记录。
我们有一整套规划。第一，我们定制了模型来做这件事情；第二，我们定制了自己的智能体；第三，Repo Wiki 本身有一套维护工作流，也有一套使用工作流。
所以对我们来说，它是一个体系，深度融合到开发者的工作过程中。技术上我们做了很多定制，从业务场景上也一样：如何让它变成沟通和协同工具。
比如今天要交接一个工作、交接一个模块，或者有人离职、有人入职，需要学习一个系统，都可以从这份文档开始。我们定义了一整套逻辑。
如果一个团队有 10 个人开发这个系统，也不需要生成 10 次。因此，我们构建了和 Git 仓库结合的共享与导出能力。
所以它不是一个原子化能力，而是一整套工作流，形成了体系化的壁垒。
这个工作流可能和 Qoder 的其他工作流有一定耦合。如果让我自己做，确实没有那么容易。
丁宇
对。我们刚上线时，生成一个 Repo Wiki 可能需要 60 分钟，现在最新版本已经把时间缩短了 5 倍。
它产生的 token 量确实特别大，所以需要花不少时间。但正因为我们有定制化模型的能力，可以获得几倍的效能提升。
Koji
我有一个好奇：我们都知道 Repo Wiki 生成出来的结果还不错，但你们在做的过程中，怎么评估它的质量？
比如生成一张图好不好，或者回答一个问题好不好，人很容易做判断。但如果我给你一个代码库，你生成一份文档，我来判断文档好不好，这个难度非常大。
而且这不只针对一个代码库，你可能要测几百、甚至上千个代码库，判断生成的 Repo Wiki 好不好。当时你们内部的评估工作是怎么设计的？
丁宇
今天大语言模型领域都面临横向评测的问题：到底谁好，在什么场景下谁好，哪些 case 下谁好。
一种比较方法是和自己比：这一版是不是比上一版好。另一种比较方法是，我定制的模型和海外比较优秀的模型相比，到底谁生成得更好。
生成得好不好，一部分由人来判断；另一部分，我们也会通过类似强化学习的方式进行比较，比如用奖励模型判断哪些东西是好的，哪些东西采纳率更高，哪些内容被查看得更多。
还可以通过用户标注能力来判断。通过这些方式，就能识别这个东西是不是进步了。
对于最开始的版本，我们主要看自己的模型和海外模型谁生成得更好，这里面确实有一部分人的工作。
接下来，比如今年短期内，你们希望很快实现的目标是什么？
丁宇
7. 云端沙箱释放生产力
核心思路还是提升产品能力。我可以分享一个 Quest Mode。
Quest Mode 代表的是自主编程，也是我们对未来开发者工作形态的定义和预判：更多开发者会使用自主编程，人负责做 leader，智能体完成更多工作。
在这个过程中，我们发现有一个天花板：人的工作时间，以及人的电脑。
我把电脑合上就不能工作了，但希望 AI 还能继续工作。我下班了就不能工作了，也希望 AI 还能继续工作。
所以 Quest Mode 延伸出了云端沙箱环境。我们通过 Spec，把 Spec 和代码库发到云端，智能体就可以在云端长时间工作。即使我休假了，它也可以继续工作。
我还可以同时启动 10 个异步沙箱，并行完成任务。它和我的工作、生活习惯是异步的。相当于我一个人带着 10 个智能体完成一组需求，生产力提升了 10 倍，同时又没有影响工作和生活的平衡。
我们认为，这种模式真正打开了时间和空间的限制，能够带来 10 倍生产力提升。我们也发布了这样的能力。
Cursor 也有 Agent 模式，但听起来 Qoder 和 Cursor 在都叫 Agent 的模式下，还是有很大不同。Qoder 是云端沙箱，可以多线程。除了这一点，还有哪些不同？
丁宇
Cursor 也支持云端模式，但大家的实现方式不太一样。它可以在远程启动 IDE，而我们没有远程 IDE，远程的只是一个运行环境，这样更加灵活，时效性也更好。
我不太需要 IDE 中很多插件和工具，只要把智能体迁移到云端，就可以启动很多并行沙箱，并发完成很多任务。
这样资源消耗更省，启动也更快。所以大家在路径选择和实现方式上，会有很大的不同。
你会觉得用户和 Qoder 之间的关系是：用户是老板，Qoder 是一个未来能够独立编程的智能体？
丁宇
其实 Devin 和 Manus 都有类似的设计理念。它们有一个共同功能：如果一个智能体工作了很久，我可以问它“你现在在干什么？为什么让我等了这么久？”
Devin 和 Manus 都可以回答这个问题，就像我在询问自己的下属。它会立即停下手中的工作，转过头来做一个快速汇报。汇报完以后，我可以调整它的工作内容，然后告诉它“行，你继续”。
Qoder 也支持类似的功能。因为智能体长时间做一件工作时，可能会跑偏，也可能耍小聪明，跳过一些任务。
所以我们一方面约束它的行为。任务开始时就制定一个 to-do list，智能体必须严格按照 to-do list 执行，不允许跳过任务，也不能没做完就告诉你做完了，这在 Qoder 里是不存在的。
另一方面，在执行漫长任务的过程中，我们会不断输出它的工作流。用户可以询问它，也可以在过程中给出新的指示和要求，纠正它的行为。
我们提供这样的能力，也是担心智能体跑了三四个小时以后，从中间某个环节开始跑偏，最后生成的结果对大家都是一种浪费。
你怎么看未来，不只是 AI coding，而是整个 AI 领域里，人和 AI 会变成什么样的关系？
丁宇
8. 人和AI如何协作
我还是想从 coding 来讲。我们有一个观点：coding 会变成大语言模型的双手和执行器，也会成为数字世界和物理世界之间的连接器，帮助人完成很多复杂任务。
人在这里面一定会成为管理者，提出明确要求，然后由不同的智能体去理解、协同，完成任务。
未来在职场和商业社会中更有竞争力的人，一定是能够充分驾驭 AI 的人。他能够把智能体管理好、协同好，找到一个场景和业务形态，把业务价值做出来。
今天为什么会有很多 AI 原生公司？我觉得它们代表了未来一种很好的人与 AI 的协作关系：形成很多有创造力的组织，很多工作由 AI 之间相互协同完成。这也可能成为未来的主流组织形态。
虽然叫 Qoder，但你们未来只做 coding 吗？
丁宇
目前肯定只做 coding，但我们认为产品形态和覆盖场景还有很大的外延。
今天我们是从下到上构建产品能力：在模型之上做优化和定制，做上下文工程，形成大量智能体和工具。
当这些能力做到比较领先时，上面的产品形态和产品界面一定可以延展。IDE 只是一种形态，代表专业开发者工作的核心界面，是一个最大公约数。
CLI 代表更专业、更自动化的开发者界面。我们还会把智能体集成到很多流水线和定制化场景里，甚至集成到手机或 App 中，在里面唤起智能体为用户工作。
所以形态上会有更多展开。从场景角度看，今天每一个小需求都可以被满足，大量场景会数字化。很多复杂任务也可以让 AI 挑大梁，智能体会成为执行器。
未来绝不只有一个 IDE。
Ronghui
感觉你们更像是在承载 Claude Code 所代表的使命，以及它可以想象的外延。
丁宇
我们希望把自己定位为模型之上的编程智能体。Qoder 的 IDE 是编程智能体 IDE 平台，未来也可能有编程智能体的其他平台。
Koji
在我们录播客的前一天，Qoder 刚发布了 CLI，也就是命令行模式。很想请教一下，你们发布它的背景和内部思考是什么？刚才已经提到了一些，看看有没有补充。
另外，大家也会关心它和 Claude Code 有没有竞争。如果有的话，怎么竞争？
丁宇
我们先讲为什么构建这种形态。
做 IDE，是希望把 coding 能力以大家最普遍的工作界面提供给开发者。最广谱的开发者还是以 IDE 作为工作界面，所以我们要做 coding，自然会做 IDE。
但在这个形态之外，用户的开发界面其实非常多元。开发者不是一周 7 天、一个月 21 天都在 coding，他还有其他工作，也会在不同平台承载工作。
有些工作可能是写脚本，有些是做维护，通过命令行做一些事情，或者进行流水线集成，在其他平台开展工作。
IDE 是一种全封装的形态，无法把智能体外化出来，它是封闭的。所以我们需要用一种灵活方式集成智能体。命令行承载的就是命令行、脚本和被集成的形态。
比如 Vim，不同开发者也会使用不同的 IDE。我们不能假设所有开发者都在用 VS Code，但 Qoder 的 IDE 是基于 VS Code 的，这天然会放弃一部分开发者。
CLI 理论上可以服务所有开发者，因此打开了更广泛的用户群体。从这些角度出发，我们一定会推出这种形态，因为我们的目标是服务广谱开发者，服务更大的用户规模。
至于怎么和 Claude Code 竞争，它不是单一维度的竞争。模型、成本都是维度。
Claude Code 在上下文构建上比较简单粗暴，但效果非常好。我们会做得更精细。因为有时候如果不用自家模型、使用其他模型，成本会很高，所以我们不能只在一个维度上竞争。
我们在上下文组装上做了很多工作，也对智能体的灵活性进行定义，在 subagent 等设计上也有自己的实现。
另外，我们希望进行多场景渗透。做场景恰恰是我们擅长的，比如可以在手机上安排一项工作，在 Slack 或 IM 里跟进、安排工作。
场景化能够满足一部分用户的刚需。我们是应用层产品，而模型厂商不会去做这些产品形态上的创新，所以大家会形成差异化定位。
Ronghui
刚才我们多次提到上下文工程。听起来 Qoder 在上下文方面做了不少工作，可不可以稍微展开讲一讲？有没有一些具体心得，或者优化上下文的方法论可以分享？
丁宇
今天要构建比较好的上下文工程，一定要做到“多、快、好、省”。
另外，智能体需要什么工具，我们要设计哪些工具，采用哪些技术实现方案，才能达到这样的效果？本质上就是驱动大语言模型工作。
我们做了很多探索。比如相关性检索。今天不可能每次都把所有内容丢给模型，因为这非常消耗成本和时间，所以一定要找到其中的相关性。
到底使用向量化检索，还是文本检索？要不要加入语义检索？每一个相关问题，都要找到自己的实现方式。
还要考虑到底使用 agent 还是 subagent，采用什么方式完成工具调用，聚集上下文内容，再拼出一个合理的上下文。上下文绝不是越长越好。
之后还要和模型互动拿到结果，可能不断循环调用工具，最后完成任务。整个过程中要做到多、快、好、省，还要有多元化的工具选择和智能体实现方式。
我们还做了记忆构建。记忆非常关键。用户在和模型、和我们的上下文工程交互的过程中，会给出非常明确的指示，这些指示可能是潜移默化的。
用户不会在提示词里写清楚，而是说“这个不是我要的”“这个是我要的”“我喜欢什么、不喜欢什么”。我们会快速把这些东西抽象出来，变成规则。
有些会变成系统提示词，有些会变成记忆。记忆会约束下一轮以及之后所有交互中模型的行为。
这样既不会让上下文增长得太快，因为上下文增长越快，成本越高，又能保证比较好的效果，让开发者觉得这个工具越用越懂自己。
原来的行为习惯变成了模型的行为规约。用户不需要把事情说明白，模型已经学会了，彼此开始形成默契。我们在这方面做了很多探索和创新。
Koji
刚才讲到 memory infrastructure、沙箱和 to-do list，这些都是你们自建的吗？还是也使用了一些开源或第三方方案？
丁宇
都是自建的。这也要求团队在这个领域有比较深的理解和积累。
这期节目会在 10 月 24 日程序员节播出。我想问一个比较个人的问题：如果你今天回到刚开始工作的时候，已经知道后来世界发生了这么多变化，现在回看当时的自己，会有什么感触？
丁宇
对于每一个工作者，或者职业工作者来说，还是要有一定的预判性。我们要感知未来会发生什么样的变化和趋势。
不要为过去的事情买单，还是要为未来即将发生的事情买单。我希望大家勇敢地迈出这一步，做出主动选择，而不是被动地被推着走。这个世界的容错率很高，大家应该勇敢地迈出这一步。
Ronghui
你自己作为一个做了这么久程序员的人，做这个产品以来有什么感受？会不会有一种自己在“革自己的命”的感觉？
丁宇
我倒没有觉得自己在做一个革命性的工具。我们更多是认为，在给未来的程序员探索一条发展路径。
未来的开发者，甚至泛开发者，需要什么样的工具，什么样的工具能够创造更大的商业价值，我们是从这个角度思考的。
今天我们不做，这件事也一样会发生。大家的工作方式、组织协作关系都在发生变革。
我们希望以一种面向未来、更懂开发者，也更懂未来组织生产关系和协作方式的姿态和视角切入，探索出一个让开发者未来更有发展的平台。
不是简单地说以后程序员都不需要了，以后都由我们的工具来做。我非常不认可这个观点。一定是人和智能体协同工作的形态。
作为一个做了很多年开发者的人，我认为优秀的开发者还是要站在技术的肩膀上，而不能成为技术的奴隶。
所谓站在技术肩膀上，就是所有技术为我所用，创造更大的产能和商业价值。我们讲的就是，要从技术那里获得红利。你拿到了，就是弄潮儿；拿不到，可能就会被淘汰。
所以我们希望把 AI coding 的能力平民化，让大家很容易获取。但如果不能主动拥抱，不能很好地驾驭，也会有问题。
Koji
你怎么看 AI 会取代程序员这件事？
丁宇
9. 程序员不会被取代
我相对比较乐观，不觉得 AI 会取代程序员。
首先，程序员要能够驾驭 AI，把 AI 当成一个巨人，站在它的肩膀上创造业务价值。这样的程序员都很有前景。
另外，还有一个杰文斯悖论：当成本变低时，需求会被打开。需求变成海量以后，大家都可以低成本地进行很多创作。
于是会出现很多泛开发者，他们可以做一些小创新，或者满足一部分群体；专业程序员则可以做大的创新，因为他们仍然具备专业性。
从这个角度讲，程序员数量可能会变多。但前提是能够借助 AI。如果能爆发出 5 倍、10 倍的生产力，一定会更有前景和竞争力；如果做不到，可能就会变成普通程序员。
整体来说，我们还是比较乐观的。
你们内部现在的开发方式是什么样的？
丁宇
我们团队很多人日常都在大量使用 Qoder，我们用 Qoder 做 Qoder。
我们也有明确要求：代码生成中有多少是 AI 生成的。我们用这个要求逼着大家革新自己，不是革命，是革新自己。
这是从什么时候开始的？
丁宇
从通义灵码时代就开始了。
你觉得未来工程师的核心竞争力，会从编码能力转变成哪些能力？
丁宇
一定会变得更加复合。开发者的定义也会变得更加宽泛。
以前开发者会有比较细的分类：后端、前端、iOS，或者 DBA。现在这种精细分工已经不再是绝对的。后端工程师也可以做前端，前端也可以做后端。
大语言模型具备很强的抹平差异的能力，个体能力被极致放大，打破了很多边界。
打破第一层边界以后，可能还有第二层边界。模型的写代码能力已经比人强了，无论产能还是效率，人都不能和它比。
这时人就要往上走一层，具备需求洞察、意图识别、需求描述、整体设计、结果验收，以及产品 sense 等能力。每个开发者未来都会是复合型人才。
如果今天让你分别给程序员和大一的计算机新生一些建议，帮助他们在 AI 时代更好地获得事业上的进步，你会分别给出什么建议？
丁宇
对于大学一年级的计算机同学，第一，要充分拥抱 AI，探索 AI 能为你做什么，探索它的边界，把它充分用起来，成为一个会驾驭 AI 的人。
第二，还是要充分学习计算机专业知识。今天计算机体系结构并没有发生革命性变化，仍然是冯·诺依曼体系结构，仍然是这些操作系统：Linux、Windows、Mac。
如果不了解这些结构，就没有办法校验模型做的东西是好是坏。你不知道它做得好不好，就没法驾驭它，它可能会忽悠你，所以一定要有专业性。
另外，AI 也不是什么都能做。比如大语言模型没有创造出大语言模型。今天 AI coding 产品可以做一个 iOS App，但它做不了 iOS 系统，因为后者足够复杂、足够需要顶层设计，也足够少见。
它仍然有很多不能做的事情，而不能做的事情往往是附加值最高的部分。以后一个简单软件可能只值 5 毛钱，一个简单的创意和 idea 也可能不值钱，因为谁都能做。
所以要学习、提升专业性，去做 AI 做不了的工作，保持好的职业发展，做更有创造力的工作。
那你觉得，在大厂里成长的工程师，在职业发展上需要什么技能？
丁宇
对计算机相关的同学来说，这是一个很好的时代。以前大家总说程序员不够，项目开发不出来，所以要延期。以后这种事情可能就不存在了，因为自身瓶颈被打破了。
我突然觉得很开心，因为之前各种项目延期真的是最痛苦的来源。
丁宇
程序员恰恰是有优势的。过去 20 年、30 年，程序员这个行业发展很快，每个人都在快速学习，所以程序员根本不在乎再多学一个东西，或者把一个东西学精。每个人都有这个能力。
这反而成为大家的优势。我对这个群体最有信心，相信大家能够拥抱 AI 时代，创造更大的产能。
Ronghui
你可以讲讲你自己吗？你的经历里有做双十一架构这样巨大、极具挑战的事情。连续 9 年双十一不宕机，背后都有你的参与。
我之前在聚美负责移动事业部，那几年每次大促都会宕机。大促前一天晚上，几个工程师甚至跑到机房去上香，实在没有办法。后来这成了一个表情包，我们特别爱发那个表情包。
可以讲讲当时的一些故事吗？
丁宇
不能说是靠我和我们的团队，还是整个公司在里面投入了很多资源，也有很多优秀人才一起贡献。
10. 双十一系统扛住百倍流量
我加入阿里的时候，正好是双十一快速起量的时期。双十一比日常有 100 倍的流量增长，每一个系统都撑不住。
当时的工作方式是每个人负责一个系统，或者几个人负责一个系统。大家各管一摊，像铁路警察，各管一段。
在日常情况下没有问题，因为每个系统都有很大余量。但面对 100 倍流量，我不能用 100 倍成本解决。其实即使用 100 倍成本也解决不了，因为大家仍然是一块块积木，没有非常强的连接和相互匹配，里面有很多瓶颈。
所以我们当时在中间件、全链路压测、容量管理、自动化运维和弹性等方面，做了全方位的技术升级。
2013 年，我们和团队开创性地提出了全链路压测，也是全球第一个提出这个概念。今天它已经成为互联网服务的标配。
有了这项技术以后，整个系统就可以达到一种平衡：系统中没有瓶颈。如果瓶颈来了，或者超过处理能力，就不把流量放进来；只要放进来的流量，都能够处理。
所谓没有瓶颈，就是在都跑满的情况下，每个系统都是满的，不会出现某个地方资源非常冗余，而另一个地方已经满得不行。
我们把几百、上千个系统保持在一致的水位。每个系统都不会挂，真要挂也挂在外面，让流量不进来。
所以，把全局架构做到这个程度，就在很大程度上解决了双十一的问题。
现在听起来非常云淡风轻，几句话就讲完了。但我想，当时遇到的阻力不只是技术阻力，还涉及几千个工程师。
每个人都有自己的 OKR，为了配合你们的构想，他要花很多时间改造自己的系统，这可能和他当年的 OKR 没有直接或间接关系。内部沟通工作是怎么做的？你是如何实现的？
丁宇
首先，大家有共同目标。大家都在做双十一，确实有成百上千的工程师参与。大家的目标就是双十一不要挂，这个目标是前提。
另外一个很好的地方，是我们能够一体化作战，整个双十一的优先级最高。它还有一个 deadline，因为软件可以延期，但双十一不能延期。
在这些多重因素驱动下，还是能够协调资源。
但作为驱动者、协同团队和方案提出者，我们要给整个事情兜底。什么叫兜底？能够驱动的资源我们就驱动，驱动不了的我可以上，我来帮你做。
时间就摆在那里，deadline 也摆在那里，不能延期。所以我们什么方法都用：有时自上而下推动，有时自下而上推动，用各种方式推进。
另外，阿里很早以前就做到了技术统一化，这也是我们的优势。如果今天大家使用不同技术栈，这边是 Python，那边是 Go，这里是 Java，那里是 C++，就很难做。
技术统一以后带来了红利。我们的迭代可以一改一大片，也有很多优秀的中间件。所以这件事情其实 3 个月就做完了。
大家也很有成就感，贡献很大，后来成为行业标配，现在还在发挥作用。参与这件事情的人也都得到了非常好的成长。
我很好奇，聚美那几年每次大促前夜，我们真的没有一个人知道大促开始后会不会宕机。
那时我算是业务比较重要的高管之一，会待在工程师的作战室里。但我感觉现场的工程师也没有人知道接下来几秒钟，倒计时“10、9、8、7”之后会发生什么。所有人都像是在祈祷。
作为阿里巴巴，你们在同一时间、另一个作战室里的心态是什么？会和我们类似吗？会紧张吗？
丁宇
肯定会紧张。我们的理念叫“在双十一之前创造双十一”。
双十一之前已经预演过很多次，而且是真实流量、真实用户动线和真实用户请求。但挑战在于，所谓真实，并不是双十一零点的真实，所以还是不够真。不够真，就会产生很大影响。
我们前期会做几次真实演练。比如某一天零点，50 万笔交易在一秒钟内同时进来，和双十一一模一样。
然后就会发现很多问题，再去排查：哪些是技术瓶颈，哪些是并发问题，哪些是容量问题，哪些是弹性问题，然后一个个解决。
下一次再压测时，原来的问题没了，但又会出现新问题。我们再把问题修掉，压到第三次、第四次，这些问题就会逐渐收敛。
问题收敛，是不是就意味着可以高枕无忧，等待双十一到来了？
丁宇
也不是。随着运营活动和爆款商品的变化，原来的测试和验证数据在流量分配上可能不够真实，就会出现错配。
错配意味着整个系统的动态调节和自我修复能力必须足够强。资源、流量和容量都要具备动态性。
但如果在高压力下进行调整，也会产生新的波动。所以我们依然很紧张。
不过从 2013 年以后，没有出过太大的问题，小问题还是接连不断，但我们认为这也是一定会发生的。
那每年双十一结束的时候，你的心情是什么？
丁宇
有时候也有运气因素，所以我们比较喜欢去灵隐寺。
这也成了我们的一种文化：双十一之前要去灵隐寺拜一拜。
当作团建？
丁宇
对，既是团建，也是放松的方式。大家压力都很大，也算找一个心灵寄托。那一秒过去，就知道这次怎么样了。
Koji
一般多久？
丁宇
一般 10 分钟。
你每年的心情都一样吗？有没有什么时候特别不一样，或者有想哭的感觉？
丁宇
最开始的时候压力比较大，后来就越来越从容了。因为技术架构也是一代一代向前发展，每一代都会面临新的问题，也会有新的机会。
比如我们解决了稳定性问题，后面还要解决成本问题。我们不希望 50 倍流量要花 3 倍成本。
后来我们定了一个目标：双十一可能有 50 倍流量，对于整个集团来说，能不能不多花一分钱？
这个目标是你提的吗？
丁宇
不是，是 CTO 提的。
但由你们来做。
丁宇
对。所以这就涉及为什么要做容器化、云原生化。
我们一直有一个 mindset：永远要从技术那里获得红利，技术驱动商业，创造价值。阿里巴巴的技术人一直有这样的追求。
集团里有很多业务板块：国内、国际、搜索、广告、电商、飞猪、饿了么、高德，以及 UC 等。大家拥有很多业务和资源，但不是每个业务都参与双十一，每个业务又都不希望受到影响。
我们通过调度、管理和弹性，通过容器等新技术，把大家打通，形成分时复用、充分弹性和混合部署，包括数据类业务和业务类服务。
该多的时候就扩，扩出来的资源给它们使用；它们用完以后再还回来。可能 20 分钟、10 分钟，就能完成大规模集群的伸缩。
云上也可以复用，各个业务板块之间可以复用，这个小时和下个小时之间也可以复用。把这些事情做到极致，就带来了海量成本节省。
今天这已经成为行业中的标准技术实现，也推动了国内容器化和云原生技术的普及。大家对效率、弹性和成本都有同样的需求，双十一只是一个缩影。
感觉真的很像每年一次高考。先进行几次模拟考，不停地查找哪里不会，然后再改。
你是从哪一年开始不再负责双十一的？
丁宇
后来我开始做另一件事情：当我们把阿里的稳定性和成本做到比较高的水位以后，就考虑如何把这些技术变现。
能力已经溢出了，因为这是行业中的普遍需求。所以我们开始做产品化，赋能行业用户，包括很多互联网企业和产业互联网用户，用产品化技术服务他们。
我做了好几年这方面的工作，负责一些产品，后来就逐渐不再负责双十一了。
Ronghui
那再到双十一的时候，心情是什么？
丁宇
是放松购物的心情。
终于可以随便买，给服务器猛加压力，轮到你加压力，而不是你扛压力了。
丁宇
对。但其实我们值班时也会猛加压力，因为我们希望业务大发展，自己也是消费者。
如果系统很稳定，但不知道零点会有多大峰值，我们其实都在买买买。系统一旦出问题，就先不买了，赶紧处理问题。没问题的话，大家就一直买，因为确实很优惠，前 100 单还有优惠。
Koji
你会不会觉得，既然已经做过双十一这么大的项目，后面还要再做什么事情，才能获得同样大的成就感？
丁宇
11. AI成为最大的舞台
不能从这个角度思考。对我来说，还是要做有价值、对社会有贡献的事情，让技术进步，造福一些人。这就是价值感的来源。
每个人都需要一个舞台，但舞台不是你想有就能有，还要看社会环境和所在平台是否提供了这个舞台，也要看自己的能力是否 ready。
当时我们做了一些判断和选择。我们的技术处理流量的能力，仍然是全球领先的，但流量不可能再大太多，因为中国人口红利也触顶了。
我们已经有一套体系和方法论，也不需要再有太多革命性的东西。所以我们做了很多技术标准化工作，也进行了大量开源，包括中间件开源、云原生领域开源。
同时，我们开始商业化，希望技术创造新的商业，通过技术打开新的商业局面。
本质上，就是让我们的技术创造更大的价值，寻找更大的舞台。到今天，我们认为 AI 是最大的舞台和放大器，所以做了这样的选择。
现在发布 Qoder 2 个月了，你觉得自己的选择怎么样？
丁宇
很正确，无比正确。
最后一个问题。在你看来，3 年、5 年之后做到什么样的成绩，你会特别满意？你想象中的那个画面里，整个生态从程序员到用户，会是什么样的？
丁宇
我们畅想未来，如果 3 年以后愿景能够达成，希望在 Qoder 这样的产品上，生产出最多的真实软件，也就是具备商业价值的软件，覆盖最多的场景，让这些场景通过软件产生更多价值。
这是从我们自身角度希望看到的。
至于周围的世界会发生什么变化，还是要回到大家相不相信 AGI 会到来。
从我的个人观点看，我们希望 coding 成为一种通用能力，通过智能体的方式外化出来。就像奥特曼讲的，从对话到推理，再到智能体、创新和组织。
我觉得 3 年这个时间窗口里，组织这件事可能会发生。AI 多智能体可以联动，完成宏大、长期、复杂的目标，调用各种工具，与现实世界交互。
Coding 能够帮助它解决复杂问题，而且带来确定性。大语言模型回答、生成和推理出的内容，本身不具备确定性；代码带来的却是确定性。
所以在未来世界中，做很多管理和生产实践时，coding 会成为一个很必要的选择。
从需求端看，大家的需求可能会得到充分满足，也会出现很多新的业务形态和创新型业务。
从场景端看，比如有一天马斯克登上火星，火星上的房子肯定不是宇航员建的，而是 AI 建的。它一定是由大语言模型、智能体和机器人共同驱动完成的。
我相信这一天会到来，而 coding 会在其中发挥非常重要的作用。
谢谢叔同来做客《十字路口》，也希望 Qoder 可以取得更多成绩。改天如果有机会，比如半年后或一年后，我们再来复盘、再来聊一次。
丁宇
好的，谢谢。
感谢。如果你认为有朋友也会喜欢本期十字路口的内容，请转发微信推荐给他们。最后，欢迎你加入十字路口的会员群，我们鼓励大家在群里聊天互动、交朋友，寻找未来的同路人。