当阿里入局全球 AI Coding，战场里的 60 天 | 对话叔同：Qoder 创始人

“很正确，无比正确”

“很正确，无比正确。”

当我们问起阿里巴巴 Qoder[1] （Agentic Coding 产品）创始人叔同，关于他带领团队冲入全球 AI Coding 这片“红海” 60 天后的感受时，他给出了这样简单而坚定的回答。

他的底气，源自一份优秀的成绩单：上线 5 天用户迅速突破 10 万，仅 60 天斩获 50 万开发者用户。

AI Coding 可能是今年 AI 领域最热的话题。

Cursor 年营收达到 5 亿美元、估值飙升至 100 亿，成为硅谷最炙手可热的独角兽；Anthropic 也凭借其强大的 Claude Code，让收入增长曲线比 OpenAI 更陡峭。

在这片卷得炽热的战场，后来者阿里的机会在哪里？

本周，我们邀请到了曾多年担任阿里巴巴“双十一”技术负责人、最早在国内推进全行业云原生化的技术领头人，听他独家分享 Qoder 上线 60 天即取得“开门红”的背后，是怎样的产品思考、技术布局和组织能力在支撑。

🎥 本期播客在 AI Hacker House 录制，视频播客将会发布于「Koji杨远骋」的小红书、B站、视频号、Youtube。

由于访谈全文较长（19,299字），可先参考目录：

🟢 快问快答：年龄、毕业院校、MBTI 与星座、一句话介绍产品、收入与利润、团队规模、Qoder 前的探索经历

🟢 AI Coding 全景图：从 0 到 1 vs 从 1 到 100

一个典型的用户路径：先用 AI 生成一个网站雏形，当它开始产生商业价值，再用更专业的工具去维护和迭代。这背后反映了什么？

• AI 写码赛道的三种主流形态：服务于创作者的“想法落地”型工具、服务于专业开发者的“效率提升”型工具，以及直接替代人力的“数字员工”。
• 为什么说所有形态的 AI 写码工具，最终都不可避免地会走向“大一统”？
• “没有自研模型的 AI Coding 工具，只是在帮模型厂商打工”，为什么说 Cursor 这样的公司最终一定会构建自己的模型能力？
• 大厂做 AI Coding 产品有何天然优势？除了成本，更重要的是能和模型进行端到端的联动优化。

🟢 红海突围：Qoder 的战略选择

当所有人都去摘那些“低垂的果实”时，我们选择了直接进攻“价值高地”。

• 一个关键的战略选择：我们绕过从 0 到 1 生成新项目的“酷炫”场景，直接切入占开发者 95% 工作时间的“真实软件”研发领域。
• 为什么我们把 Qoder 定义为“智能体编程平台”？因为未来的开发协作模式，将从“人机协同”进化为“AI 自主编程”。
• “我不干，智能体干”，这是一种全新的开发范式。
• 另辟蹊径的原因：作为一个后来者，我们希望通过差异化定位，快速在红海中找到自己的生态位。

🟢 需求文档是最重要的！

AI 不但擅长写代码，更擅长写需求文档。

• 从“提示词工程”到“上下文工程”，我们如何让 AI Agent 能够独立完成更大、更复杂的任务？答案是 Spec-Driven（需求文档驱动）。
• 一个典型的 Spec-Driven 工作流：用户提出一句话需求 -> “文档 Agent” 自动生成详细设计文档 -> 用户确认后驱动“代码 Agent”长时间执行。
• 这其实是对现实世界中“老板提需求 -> 产品经理写 PRD -> 工程师开发”这一流程的 AI 化映射。

🟢 产品哲学：从“不打断心流”到“给你掌控感”

AI 时代，开发者被迫进行“结对编程”，过去那种完全不被打扰的“心流”已难以维持。

• AI 时代的新矛盾：既要提供趁手的工具，又不可避免地会打断用户的心流，如何平衡？
• 我们的答案：与其徒劳地追求不被打断，不如给用户完全的“掌控感”，让他成为 AI Agent 的管理者。
• 一个反常识的产品设计：为什么 Qoder 至今不让用户选择模型？ 因为“机选优于人选”，也避免了用户成为“模型测试员”而产生的决策疲劳。
• 我们如何平衡性能、效率、成本这个“不可能三角”？核心在“上下文工程”的精细化运营。

🟢 组织与方法：如何支撑一场闪电战？

为什么 Qoder 能够快速起步？因为我们不是从零开始，而是整合了阿里内部多个成熟团队的人才和技术积累。

• 从服务中国市场的“通义灵码”，到面向全球的“Qoder”，背后发生了怎样的组织和战略演进？
• 一个关键决策：为了争取全球市场的时间窗口，我们先用全球最好的模型服务开发者，同时“以战养战”，为自研模型的发展赢得时间。
• “它就是独立经营的一块业务”，大厂内部创业如何通过组织设计，真正地“甩掉包袱”，实现创业公司级别的敏捷？

🟢 Repo Wiki：攻克“祖传代码”的秘密武器

我们学计算机第一课，老师就说要写好文档和注释，但几乎没有团队能真正做到。这是一个如此显性的需求，为什么之前没人做？

• 开发 Repo Wiki 的第一性原理：“文档是会骗人的，但代码永远是最新的。”
• 我们如何用 AI 解构“祖传代码”？通过分析代码的当前切片和所有历史提交记录，还原出整个系统的设计思想和业务逻辑。
• 如何保证这个文档不过时？随着代码库的变更，AI 会实时、增量地更新这份“活文档”。
• 为什么我们有信心构建壁垒？因为这不是一个原子能力，而是一整套深度定制的模型、Agent 和与 Git 结合的团队协作工作流。

🟢 1024 寄语：AI 时代，程序员如何进化？

程序员可能是最不惧怕学习的群体，这恰恰是我们在 AI 时代最大的优势。

• AI 会取代程序员吗？不会，同时“杰文斯悖论”告诉我们，当成本降低，需求会爆炸式增长，程序员的数量可能会变得更多。
• 未来工程师的核心竞争力是什么？从单一的编码能力，转变为“需求洞察、整体设计、结果验收”等复合能力。
• 给计算机大一新生的建议：拥抱 AI，但更要学好计算机体系结构，因为你得知道 AI 有没有在“忽悠”你。

🟢 双十一往事：一个顶级架构师的两次“高考”

老板给了一个疯狂的目标：双十一流量翻 50 倍，集团能不能不多花一分钱？我们最终做到了。

• “在双十一之前，先创造无数个双十一”，如何通过“全链路压测”这剂猛药，在真实流量下反复演练，驯服上千个系统？
• 技术人如何永远“跟技术要红利”？从解决稳定性问题，到通过容器化、云原生技术极致地优化成本，这背后是一套完整的方法论。
• 顶级架构师的成长之路：从解决一个技术难题，到构建一套技术体系，再到将技术能力产品化、商业化，最终寻找更大的舞台。

快问快答

👦🏻 Koji

我们从快问快答开始。请问叔同你的年龄？

👦🏻 叔同

42 岁。

👦🏻 Koji

毕业院校？

👦🏻 叔同

吉林大学计算机专业。

👦🏻 Koji

用一句话安利一下 Qoder。

👦🏻 叔同

一个面向未来的产品，定位为下一代智能体编程平台。

👦🏻 Koji

在 Qoder 之前您在做什么？

👦🏻 叔同

加入阿里 16 年，做过淘宝架构，担任过双十一技术负责人，过去十年主要围绕容器化、云原生，包括阿里云原生技术演进和相关技术的产品化。

👦🏻 Koji

你的 MBTI 和星座分别是什么？

👦🏻 叔同

MBTI 是 INTJ 架构师，和我的工作非常相像，星座是天蝎座。

👦🏻 Koji

目前 Qoder 的用户规模和商业化进展方便讲吗？

👦🏻 叔同

上线两个月已有 50 万活跃开发者，商业化进展符合预期。

AI Coding 全景图：从 0 到 1 vs 从 1 到 100

👦🏻 Koji

可以请叔同先讲一下现在这个火热的 AI Coding 赛道的全景图吗？给我们科普一下？

👦🏻 叔同

其实大家现在都有一个共识，就是大语言模型在编码（Coding）方面特别强。也因此，不同的团队都开始在这个方向上打造产品。那接下来很自然就会出现一个问题：如何把“一句话的需求”、一个想法，快速变成一个可运行的软件或服务，比如一个网站。像 Lovable、bolt.new 这类产品，其实就是为创作者或者“泛开发者”服务的。

不过这种产品往往面临一个问题——生命周期短。因为现在每个人都有想法、也能实现，甚至花几块钱就能生成一个软件。但如果它只解决自己的一点需求，是无法长期存活的。于是就出现了另一类平台：允许用户把自己的作品发布出来，让别人购买、复用，比如国内的“Youware”这样的产品。这类可以理解为“AI Coding 从 0 到 1” 的产品形态，用 AI 来快速生成基础的软件服务。

另一类产品则像 Cursor、Claude Code 这样的一站式专业工具。它主要面向行业中那 3,000 万专业开发者——他们每天都在生产大量代码和软件，创造商业价值。那怎么帮他们更高效？因为大模型的编程能力已经超过了人类个体，所以关键是如何让它融入开发者的日常工作，提升生产力和产能。

于是这一类产品就更聚焦在补全、智能体协作开发、甚至自主编程等专业场景。它们主要解决的是“从 1 到 10”或“从 10 到 100”的问题——当一个软件开始产生商业价值，它需要长期迭代、深度理解、持续维护，生命周期更长，对 AI 工具的要求也更高。

所以现在很多用户的典型做法是：先用 Lovable 这类工具生成一个网站或服务；等到要商业化、要扩展时，再用 Cursor 来修改、维护。因为随着复杂度上升，原本“一句话生成”的产品就不够用了，必须走向专业开发阶段。

再往前看，还有像 Devin 这一类，它的定位就不再是“帮助开发者提效”，而是“直接提供数字员工”。它的目标是能像正式员工或实习生一样，接受完整任务、长期工作、协调多角色资源，最后交付结果。这是一个相对超前的方向。现在像我们推出的 Qoder 等产品，其实也逐步具备了这样的能力。

所以整体来看，AI Coding 的产品形态可以分成三个阶段——“从 0 到 1”、“从 1 到 10”、“从 10 到 100”。

👦🏻 Koji

最后你觉得大家会不会走向大一统？

👦🏻 叔同

非常有可能。核心需求都是通过 Coding 提供软件服务来满足业务场景并创造商业价值。未来能力会越来越强，形态越来越多元，所以会走向大一统。

👩🏻 Ronghui

我好奇一个问题，模型在你说的这种最终融合趋势中会起什么作用？有人说 Cursor 终有一天会做自己的模型。

👦🏻 叔同

模型影响非常大。这也回到我们为什么认为阿里有机会做出更强的产品和 IP，因为我们有模型能力。

如果没有模型能力，就会被认为是“套壳产品”，成本高，无法与模型联动优化，在估值和收入上也会受影响。

如果有自己的模型，就可以做联合优化，在性能、成本和效率上提升，对企业利润影响也很大，它不会只是给模型厂商导流。所以我们判断，这些产品最终一定会构建自己的模型。

红海突围：Qoder 的战略选择

👦🏻 Koji

Qoder 是在 2025 年 8 月发布的产品。请讲讲当时你们进入这个已经是红海的赛道时，选择了怎样独特的竞争角度和战略，在激烈的战场中快速切出自己的赛道？

👦🏻 叔同

这是个好问题。我们推出产品时，行业中相关产品已经很多，确实是红海市场，但我们对市场和产品定位有自己独特的判断。还是从刚才的逻辑分析，Vibe Coding 被广泛接受，一句话就可以创造一个软件服务，很惊艳。

但我们发现 95% 以上的专业开发者在维护真实软件。真实软件是指真正产生商业价值的软件。一旦产生商业价值，就要对用户和客户负责，需要严肃的修改、迭代和演进，不能有故障问题，并且会有很多历史积累，可能存在 5 年、10 年。这些历史代码不能乱改，不能发挥想象或产生幻觉。因此这是价值高地，因为它真正支撑信息产业持续产生价值。

今天很多工具从 Vibe Coding 切入，而我们选择从真实软件切入，构建产品，这是我们的第一个切入点，也是与众不同之处。

我们还看到一些趋势。AI Coding 发展最初是以人为主导写代码，AI 辅助补全，这是辅助式阶段，如业界常用的 Tab Tab；第二阶段是协作式编程，人和 Agent 同步互动，例如补文档、加注释或补全功能来完成任务和测试。

随着模型和智能体演进，会出现新的合作模式，我们称之为 AI 自主编程，即 AI + Agent 可以形成数字员工，完整、异步地完成任务，开发者相当于多了一个助手或团队成员，有一个 AI 军团能整块完成任务。

我们认为这个趋势已经到来，因此我们把产品定位为两个核心：面向真实软件，以及智能体编程平台——即“我不干，智能体干”。这是我们对未来开发协作模式的定义。从这两个点切入，我们的产品将与现有产品形成明显差异。

👦🏻 Koji

这个洞察是从用户、商业、市场的底层需求中来的。但为什么一开始没那么多人做维护软件？是因为不够酷，还是难度大？

👦🏻 叔同

两个原因都有。每个人都喜欢做创造性工作，一句话生成一个漂亮网站很有成就感，对产品的好感也更多。但要发挥大语言模型的能力，有很多路径。我们是后来者，低垂的果实已经被摘，我们想直接进攻价值高地，进入真实软件场景。

我们讲开发者工作的阶段，从辅助到协同再到自主，这些阶段都存在。我们定位为下一代自主编程平台，但并不是只做自主阶段，而是三个阶段都做，因为我们要服务最广谱的开发者，不管他们处在哪个阶段。

今天中国开发者与海外开发者所处阶段不同，中国的模型与海外的模型发展阶段也不同。由于我们与客户有大量互动，能明显看到使用习惯差异。例如在中国市场，问答式使用更多，用户提问题让模型回答后再改代码；海外已经进入更高阶段，让模型直接改完整代码，自己不太参与。

👩🏻 Ronghui

所以会有一些针对中国情况的差异化。

👦🏻 叔同

对，会有差异化。

👦🏻 Koji

Qoder 是从 day one 就做全球市场的产品，对吧？并没有中国版和海外版之分。

👦🏻 叔同

是的。我们必须服务广谱开发者，因此这些功能类型都要具备，用户可以按使用习惯组合能力。例如补全用得多就用补全，Ask 用得多就用 Ask。如果中国开发者快速拥抱先进生产力，也可以直接用自主编程。这些能力我们都有。

我们的形态也多元化，有 IDE，也发布 CLI，也会发布 JetBrains 插件，也会在不同场景中集成使用。例如在工作流水线或内部平台里，用编程智能体委派任务、跟进进度、校验结果。从不同切面和形态满足 Coding 和软件生产的多元需求。支持图片、语音等多模态输入也是为了提供不同触点。这是我们希望呈现的产品形态。

👦🏻 Koji

大家最常把你们和谁比较？

👦🏻 叔同

现在还是 Cursor 比较多，但 Cursor 体量大，我们仍在追赶。

👦🏻 Koji

你们和 Cursor 最大的差异是隐形知识的可视化，帮助维护已存在的软件；第二是智能体以及Quest模式，更独立完成编程任务。

👦🏻 叔同

我们为此了很多工作，包括我们倡导的 Spec 驱动。Spec 驱动是需求文档驱动，也是为了让智能体能长时间独立完成整块任务。

需求文档是最重要的！

👦🏻 Koji

可以具体讲一下吗？当你说到“需求文档驱动”时，这是怎样的一个工作流？对应怎样的产品功能？

👦🏻 叔同

这是一个逐步进化的过程。从提示词工程发展到上下文工程，本质是构建更好的上下文，让大语言模型在可控情况下产出更大结果并能长时间工作。我们必须使用 Spec 驱动来推动 Agent 工作，因为要让它完成大块任务，需求必须表达清楚。

需求包括业务洞察、业务逻辑设计、技术模式、技术架构选择、设计规约、模块设计、实现要求等。我们通过技术文档和业务架构设计，把任务分解清楚。这个过程也是与模型交互的过程。模型理解任务后，会明确需求内容与步骤。这其实是把原来人与人协作的方式进行映射。

例如三个人开发软件时，一个人提出需求，之后调研、确认技术方案、写清需求文档（PRD）、定义验收方式、数据对接方式，然后程序员实现并推向市场迭代。这一流程被映射到与大语言模型的协同中，模型接收详细的 Spec 后，就能分阶段、长时间自主完成任务，并自检结果是否符合开发者预期。因此 Spec 驱动是实现智能体长期自主协作的必然选择。

👩🏻 Ronghui

它其实是把传统团队协作开发的真实流程做了映射。

👦🏻 叔同

但这里也有一些小技巧，比如需求文档很多人不愿意写，但大语言模型不仅擅长写代码，也擅长写需求文档。

👦🏻 Koji

我注意到，用 Qoder 时，我给它一个想法后，它第一步会先帮我写文档。

👦🏻 叔同

我们为了写好 Spec 文档，我们构建了一些智能体。虽然没有显式展示在功能模块中，但它会把一句话需求拆成标准化的设计文档。用户再做微调或补充确认，确认后就可以开始执行，从而驱动智能体长时间执行任务。

👦🏻 Koji

之前我试用了 Wiki 的一个产品，它把需求文档和视觉稿常驻在无限画布的一角，形成类似“宪法”的存在。之后做任何页面或改动都会参考它。

👦🏻 叔同

这是约束模型行为的常见方式。在 Qoder 中，我们也通过系统提示词和记忆机制来实现类似约束。我们提供很多趁手工具，让开发者定义规则——什么能做、什么不能做，把这些写进 Rules 中。这样模型在执行过程中不会偏离任务，就像每个公司先“约法三章”。这些能力我们也通过开放接口提供给用户。

产品哲学：从“不打断心流”到“给你掌控感”

👩🏻 Ronghui

除了这种对传统开发流程的映射，你们有没有做新的调整或改进？

👦🏻 叔同

我们形成了一些符合 AI 时代的新开发方式。以往构建工具时强调一个核心理念：不要打断用户的心流，让用户在不受干扰的情况下连续完成工作。例如早期的 VS Code，它们的理念都是“不打断用户心流”，在一站式平台中保持用户连续工作。

但在 AI 时代，这种“连续心流”很难维持，因为工具变多，开发变成结对编程甚至多人协作，人和智能体之间需要频繁互动，会自然产生反馈、修改和迭代，例如“这段不满意请改一下”“这里加个功能”等。协作带来生产力提升，但也带来注意力切换成本。同时还要管理智能体行为，例如刚才提到的 Rules 约束。

我们还设计了智能体用于理解和适配开发者的偏好，它会归纳开发者的行为习惯：想要什么、不想要什么、哪些能接受、哪些会拒绝，并把总结写入记忆。但开发者并不一定总同意这些推断，所以他们可以编辑和修改智能体的记忆。

同时，用户还会考虑成本控制，比如压缩上下文、切换模型、重启会话，提高使用效率。所以可以说，在 AI 时代，用户的“心流模式”已经发生变化。他们不仅在开发，还在调度 AI 资源、管理智能体行为、控制成本，所以我们需要在产品里找到一个平衡：既提供趁手工具和高生产力，又不让用户觉得自己被频繁打断或失去掌控。

👦🏻 Koji

听起来保持心流其实不容易，因为被打断的原因很多，而且往往无法避免。

👦🏻 叔同

是的，所以需要给用户“掌控感”。当开发者能掌控整个过程，包括智能体的行为与任务走向时，即便交互频繁，他们依然会有好的体验。这是 AI 时代开发协作方式变化后的核心产品理念。

👦🏻 Koji

有没有一个具体的例子？你们为了帮助用户进入心流状态，做了哪些特殊的设计或取舍？

👦🏻 叔同

我们在每一个功能上都严格评估两件事：第一，它是否打断用户；第二，它是否增加理解成本。我们认为在 AI 协作开发模式下，被打断是客观存在的，但绝不能增加理解成本——也就是不要让用户费力思考怎么用产品，交互必须自然直接。一旦让用户停下来理解界面或功能逻辑，那就违背了好的产品设计原则。

👦🏻 Koji

让我想起我做产品经理时的一本书——《Don't Make Me Think》（中文译名《别让我思考》），整本书核心就一句话：不要让用户思考。

👦🏻 叔同

对，我们秉持的也是同样的原则。比如你可能注意到，Qoder 没有提供模型选择功能，这其实是为了贯彻这个理念。

👦🏻 Koji

这个确实很有趣。因为大家默认你们会用通义千问的模型，但我看官网写的是——用最好的模型，而不是“某一家”的模型，而且不让用户自己选。

👦🏻 叔同

没错，我们有一个最高原则：整合全球最优模型，让用户直接获得最好的结果。所以 Qoder 的模型池里既有海外顶级模型，也有国内模型。但用户不需要手动选择模型，因为模型选择本身就是一种严重打断。

如果像 Cursor 那样列出 40 个模型让用户选，用户就必须停下来学习模型价格、速度、上下文长度、擅长领域，并反复测试、排序，这直接把开发者变成“模型测试工程师”，是极大的体验损耗。

👦🏻 Koji

这其实也是用户的一个期望——他们希望有掌控感。尤其是当市场上出现新版本，比如说 Claude 发布 5.0，大家都在说性能提升十倍，石破天惊。那所有人都想尝试，但如果在 Qoder 里没法直接选择 5.0，他们就会觉得受限，甚至可能流失。你怎么看？

👦🏻 叔同

我们更希望用结果来回答用户的问题。也就是说，用户在 Qoder 里问同样的问题，得到的结果是否不逊色于那些“可以自由选模型”的产品？我们相信结果能说明一切。

其实在这类 AI 编码产品里，有一个“性能不可能三角”：性能、效率、成本。你要又快又便宜，那可能就没法太强；要性能好、效率高，那成本就会上升。我们一直在这三者之间权衡。

所以我们的思路是：当一个更好的模型出现时，即便我们没让用户手动选择，我们的结果也不能比别人差，甚至要更好。

👩🏻 Ronghui

那这个不可能三角，有一天会变成可能吗？

👦🏻 叔同

核心挑战在于“上下文工程”。谁能更好地构建上下文，谁就能在性能、成本、效率之间找到平衡。

另外还有“模型选择器”这件事。我们的理念是“机选优于人选”。第二个理念是“平台支持优于个人选择”。

我们有大量用户和真实使用数据，可以从统计学层面知道不同场景最适合哪种模型。而如果让用户手动选择，首先会打断思路，其次也不现实——没人能在每次提问时都换模型。一般人都是开启一个新会话选好模型后一路用下去。所以我们希望系统能自动判断，为每一个问题选出最合适的模型。这样用户体验和效果都更好。

这也是 Qoder 和其他产品最大的不同：我们用效果说话。

👩🏻 Ronghui

那用户在不了解你们的前提下，怎么能感受到这种效果？

👦🏻 叔同

我们下一步会开放一个“真实软件评测集”。让用户能在同样的数据集上，对比不同产品的效果，包括稳定性、成本、时效性、以及最终结果的满意度。理念是一回事，但产品的实际表现才是关键。用户主观体验是一种评测，而这个评测集能让结果更客观、更数据化。

👩🏻 Ronghui

这个产品对阿里意味着什么？

👦🏻 叔同

我们 CEO 吴泳铭其实提过：“Coding 是走向 AGI 的必经之路。”

对我们来说，Qoder 是帮助大模型通过实际编码任务来提升端到端能力的重要载体。它服务开发者，也服务更广的场景。从战略上讲，它是阿里整个 AI 体系的重要组成部分。当然，最终能发挥多大作用，还得看我们产品在市场上能做到多大占有率。

👦🏻 Koji

嗯，现在已经非常好了，是个很好的起点。

👩🏻 Ronghui

那你刚接手这个产品时，内部有没有一个目标？

👦🏻 叔同

有的，我们的愿景是做到“世界前三”。

👩🏻 Ronghui

那现在第几？

👦🏻 叔同

还远没到排名的时候。现在其实大家都刚跑完马拉松的第一个公里，还要看后劲、资源和加速度。

👦🏻 Koji

一般听到“前三”，第一反应都是“第三”（笑）。

👦🏻 叔同

其实差别不大。前三和第三意义相近。关键是这是一种愿景。市场竞争确实激烈，但我们也有信心。尽管产品刚上线两个月，开发者反馈非常积极。我们一开始就定了“做真实软件、做高价值产出”的定位，也得到了认可。

我们有技术上的优势——无论是阿里巴巴的整体技术能力、模型研发团队的深度，还是上下游协作的能力，都能帮助我们在性能、效能、成本上持续优化。接下来我们还会在产品形态和用户界面上持续创新，把底层模型能力、上下文构建和工具整合得更好，形成更多元的竞争力。

所以我们认为，与国内外的同类产品相比，我们仍有很强的后劲和独特优势，这也是我们信心的来源。

👦🏻 Koji

你们立项到上线大概是一个什么样的周期？

👦🏻 叔同

就是在 2025 年发生的。

👦🏻 Koji

非常快。

👩🏻 Ronghui

8月发布。

组织与方法：如何支撑一场闪电战？

👦🏻 Koji

我知道其实阿里之前已经有一个非常成功的编码产品——通义灵码。在已经有灵码的情况下，为什么还要再做一个 Qoder 呢？

👦🏻 叔同

是的，灵码在国内已经做了两年多，也确实得到了开发者非常大的认可，插件市场的占有率也是国内第一。所以我们在讨论下一步方向的时候，其实不是简单地做加法，而是回到基本面去做了一些核心判断。

比如，我们到底用什么品牌去做全球化？产品形态应该是什么？继续做插件？还是 IDE？还是命令行？或者做智能体的输出？还有，我们的模型要怎么选？是完全用自研模型，还是整合全球最优秀的模型？

这些问题我们都讨论得非常深入。推动我们最终决定做 Qoder 的核心，其实是从市场出发的判断：开发者永远会选择最好的产品——最理解他们、能带来最大价值的那个。所以我们决定把 Qoder 作为面向全球市场的形态。

灵码我们把它定位为服务中国市场，同时也帮助我们自研模型积累时间和数据——假设未来一年阿里的模型能做到全球领先，那 Qoder 当然会全面采用。但我们不可能等模型先成为世界第一、再服务开发者。那时候机会已经没了。必须先服务开发者，再追赶模型能力。

这条路径确定之后，团队的执行动力就非常强，因为我们对市场足够了解，也有成功打造开发者产品的经验，这让我们对 Qoder 的判断很坚定。

👦🏻 Koji

所以这个团队不是从零开始组起来的，而是延续了灵码时期的团队？

👦🏻 叔同

对，核心团队是延续下来的，同时也加入了一些其他优秀的同学，所以起步非常快。大家也都挺拼的，因为我们真心相信技术改变世界这种使命感。而当真遇到一个能让技术影响全球开发者的机会时，大家的投入度是完全不一样的。

👩🏻 Ronghui

那我很好奇，这个项目当时立项的时候，是你主动要来的，还是公司安排的？

👦🏻 叔同

算是双向奔赴吧（笑）。灵码本身已经是很不错的成果，把它延伸为一个全球化产品，我们确实觉得最合适的还是我们这支团队。

👩🏻 Ronghui

而且从品牌上看，Qoder 这个名字似乎也刻意避免跟“阿里”“通义”这些标签强绑定，更像是一个中性、纯产品导向的品牌。

👦🏻 叔同

没错，这正是我们取这个名字的原因。Qoder其实就是“Coder”的谐音，意思就是“程序员”。我们希望这个产品的身份非常清晰——它不是某个模型的附属品，也不是某个平台的延伸，而是属于开发者的工具，可以是你随身携带的程序员、家里的程序员、团队的程序员，没有额外的品牌束缚，这样它才有更大的发展空间。

👩🏻 Ronghui

那它在阿里的整体 AI 战略里处于什么位置？

👦🏻 叔同

对，其实很重要的一点是资源上的支持。包括目标的解绑、团队效率的提升，公司都给了我们很大的空间。我们也卸掉了一些包袱，更直接地去面向市场，看友商为什么跑得快，我们怎么才能也跑得快。

这一点对我们来说是非常关键的。因为外界可能会担心，大厂的流程复杂、机制繁琐、约束多，那是不是就会拖慢效率？尤其是对于一个从 0 到 1 的产品来说，这种担心是很现实的。但我们现在的状态更像是“大厂里的创业”。既有资源的支撑，也有足够的开放度和灵活性，我觉得这是最好的支持方式。

无论是资源支持、机制灵活度，还是决策效率，我们都得到了很大的授权。很多人会担心大厂做创新容易被流程拖死，但在 Qoder 上我们非常幸运，公司给我们的是创业式机制——去掉包袱、快速试错、面向全球竞争。我觉得这是我们能打闪电战的前提。

👦🏻 Koji

Qoder 发布的时候，大家说 BAT 三家都进入 AI Coding 领域了，海外又有 Anthropic 的 Claude Code、OpenAI 的工具，在这种情况下，创业公司还有机会吗？

👦🏻 叔同

老实说，从现在的格局来看，创业公司的机会越来越少了。

一方面，哪怕 AI Coding 听起来像是“大模型的一个封装层产品”，但它需要的投入其实非常大——无论是团队规模、算力资源，还是资金成本。要做出真正能规模化的产品，没有资本的支撑几乎不可能。

另一方面，大平台的优势正在不断放大，它们形成了自己的飞轮效应。举个例子，Claude Code 或者 GPT-5 的 CodeX，它们有天然的优势。因为他们用自家的模型，算力成本低；而像 Cursor 这样的团队用外部模型，成本就要高几倍。所以大平台可以做到“性能好、成本低、效率不差”，三者兼得。因为他们的算力资源、集群设施本身就是沉没成本，而卖 API 却可以按次收费，这就形成了结构性优势。

当然，早期创业公司是有窗口期的。比如 Cursor、或者早期的 Lovable，他们在很早期定义了这个品类，确立了产品形态，再加上快速的迭代节奏，形成了先发优势。

但现在如果再有创业公司想进来，除非能创造出一种全新的模式，否则在同样的产品逻辑下，要同时和大厂、模型厂、以及这些已有势能的公司竞争，确实很难有优势。

👩🏻 Ronghui

那在国内，从产品角度看，你认为谁做得最好？

👦🏻 叔同

我们肯定觉得自己做得最好（笑）。但我觉得这个领域里的对手都很值得尊敬。大家有不同的理念，构建了不同形态的产品，也都在满足不同开发者的需求。

从我们的视角来看，现在这个阶段还不是“你死我活”的竞争，而更像是一个巨大领域里的分化和探索。因为从全球来看，专业开发者可能只覆盖了整个市场的三分之一，还有三分之二的潜在用户没被触达。

所以现在还没到那种极端内卷、极致性价比的竞争阶段。大家都还在形态上百花齐放，各自找到自己的突破口。

Repo Wiki：攻克“祖传代码”的秘密武器

👦🏻 Koji

你觉得 AI Coding 产品的用户留存是你们担心的点吗？毕竟代码库就在那，今天我可以用 Qoder，明天其实也很容易切回 Cursor，尤其如果 Cursor 接入了最新最强的模型。

👦🏻 叔同

我们内部讨论过这个问题。比如你提到的代码可视化能力，也就是我们做的 Repo Wiki。我们讨论过，这样的可视化内容是不是只能在 Qoder 里看？最后我们认为这是不可能的，它一定要是开放的，用户应该可以随时导出，它属于用户，是用户的资产。

所以我们最朴素的想法并不是“怎么强留用户”，而是“用什么方式让用户愿意留下来”。我们认为真正的粘性来自差异化能力和开放性。所以我们会坚持两件事：第一，做出别人没有的差异化能力；第二，保持开放，不做封闭系统。

👦🏻 Koji

很多人提到 Qoder 的好评来自你们解决了“存量代码难维护”的问题。比如我接手一个有 100 个开发者改过的老项目，代码结构复杂、逻辑难懂，随便改一个 bug 可能引出一堆新 bug。Repo Wiki 的价值就在这里。但这个功能看起来简单，做起来应该很难吧？你们是怎么把复杂凌乱的存量代码梳理清楚的？

👦🏻 叔同

其实刚才提到的那类“又乱又杂、工作量很大”的任务，恰恰是大语言模型最擅长的。我们整个实现体系其实都是基于大模型来做的，但在此基础上，我们也构建了自己的一系列智能体。

我们的一个核心判断是：对开发者而言，所有工作中最实时、最鲜活、最具价值的沉淀其实是代码本身。因为当老板提一个需求要改功能时，大家第一时间会改代码，但很少有人会再去同步更新文档——那样太不经济了。所以代码是最准确反映业务现状的载体，是产品经理、设计师和工程师共识的终点。

基于这个逻辑，我们的出发点就是从代码出发。代码不仅是一段静态内容，它还包含提交历史、变更记录、版本演进等动态信息。我们通过分析这些切片与变更轨迹，形成对整个代码库的理解：它的设计逻辑、演进脉络、架构结构、业务关系等，并据此生成一个超越传统文档价值的“活文档”。

这个文档的每一行、每一个字都是由大语言模型生成的，不会额外增加开发者的负担。同时，随着代码库的变更提交，它还会实时、增量式地自动更新。也就是说，这个文档可以被视为系统中最有价值且始终鲜活的文档，但它是由 AI 生成的。

👦🏻 Koji

这确实很有需求。像我们学计算机第一课，老师就说要写好文档、写好注释。工作后也常常因为注释不完善、文档缺失而效率受影响。很多团队都试过建立文档规范、做代码 review 来强化这件事，但往往难以持续。毕竟在速度压力和人性的权衡下，几乎没有团队能长期维护高质量文档。

那我挺好奇的，这么显性的需求，为什么之前像 Cursor 或其他同行没有去做？如果有一天他们想做了，他们能否做到你们现在的程度？还是说我们有一些独到的“秘密配方”或技术体系，让别人不容易追上？

👦🏻 叔同

肯定没那么容易。实现“功能”本身不难，难的是如何又快、又好、又省地实现——既能低成本运行，又能精准理解代码历史与上下文。

我们在这件事上其实做了很多定制化工作。首先，我们有专门为此调优的模型，以及定制的智能体（agent）体系。整个系统都有配套的维护与使用工作流，它深度嵌入开发者的日常工作过程。

技术层面我们做了很多优化，但业务场景同样重要。我们让这个系统成为一个真正的协作工具：比如交接模块、员工离职或入职、接手新项目时，都可以从这份“AI 文档”入手。

此外，我们还和 Git 仓库深度集成，能让多人团队共享、导出同一份智能文档，而不需要重复生成。这就不再是一个原子化能力，而是一整套体系化的工作流。

也正因为如此，它形成了比较坚固的体系壁垒。

👦🏻 Koji

而且它已经和 Qoder 的其他工作流产生耦合了，所以其实别人想做，也不容易复制。

👦🏻 叔同

对。比如刚上线时生成一个 Repo Wiki 要 60 分钟，现在最新版本缩短到了 1/5 的时间。虽然这类任务 Token 量很大、算力消耗高，但因为我们做了模型定制优化，所以效率大幅提升。

👦🏻 Koji

大家都知道你们的 Repo Wiki 效果很不错，但我很好奇在开发过程中，你们是怎么评估它“好不好”的？比如生成一张图、回答一个问题，质量高低人一看就能判断；但如果我给你一个代码库，让你生成一份文档，这个“好坏”的判断就复杂多了。尤其你们要在内部测试上百、甚至上千个代码库的生成结果，这个评估体系怎么设计的？

👦🏻 叔同

这是个非常好的问题。其实整个大语言模型领域都面临类似的挑战——“横评”问题：到底谁更好？在哪些场景下更好？

我们主要有两个维度的评估方式。

第一个是自我对比，即新版本和上一版本比：这次是不是更好、更精准、更稳定？

第二个是外部对比，拿我们定制化的模型和海外头部模型对比，看谁的生成效果更优。

“好坏”的判定我们也不是单纯靠人工，而是结合了多种手段：

• 一方面确实有人力参与——工程师和标注团队会针对一批样本做主观评估；
• 另一方面，我们引入了类似强化学习的机制，通过奖励模型来判断哪些结果是“更好的”：比如被用户阅读、采纳、引用的比例更高，就会被系统标记为“优”。
• 同时我们也收集用户标注与反馈，不断训练这个“判优模型”。

所以整体上，这是一种“人工评估 + 系统自我学习”结合的方式。最初的版本阶段，我们更多是看自己模型和海外模型的对比表现，之后才逐步形成一套系统的自动评估框架。

👩🏻 Ronghui

那你们接下来，比如今年短期之内希望实现的目标是什么？

👦🏻 叔同

其实我们的核心思路还是提升产品能力。我可以分享一下我们的 Quest Mode。Quest Mode 是一个自主编程模式，是我们对未来开发者工作形态的定义或预判。我们认为未来更多的开发者会使用这种自主编程模式：人作为 leader，AI agent 完成更多工作。

在这个过程中，我们发现存在一个天花板，就是人的工作时间和电脑的限制。比如我合上电脑或下班后就不能工作，但我希望 AI 还能继续工作。于是我们在 Quest Mode 的基础上构建了云端沙箱环境，通过 SPEC 把代码库发到云端，让它可以长时间运行。即使我休假，它也能继续工作。

同时，我可以启动十个异步沙箱，让它们并行运行。这意味着我一个人可以带十个 agent 完成一组需求，生产力提升十倍，而不影响工作生活平衡。这种模式真正突破了时间和空间的限制，带来了十倍的生产力提升，所以我们发布了这项能力。

👦🏻 Koji

其实 Cursor 也有 agent 模式，但听起来 Qoder 和 Cursor 在 agent 模式下还是很不同。你们有云端沙箱、多线程等特点，除了这些还有哪些不同？

👦🏻 叔同

Cursor 也支持云端模式，但实现方式不同。它可以在远程启动 IDE，而我们没有远程 IDE，我们的远程环境只是运行环境，更加灵活，时效性更好。

我们不依赖 IDE 中的插件工具，只需把智能体迁移到云端，就能同时启动多个并行沙箱并发执行任务，资源消耗少、启动快。大家在路径选择和实现方式上有很大不同。

👦🏻 Koji

所以你会觉得用户和 Qoder 之间的关系是——用户是老板，Qoder 是一个未来独立编程的 agent。

其实 Devin 和 Manus 都有类似的设计理念，它们也有一个共同功能：如果一个 agent 工作时间太久，我可以问它“你现在在干嘛？为什么让我等这么久？”Devin 和 Manus 都能回答，就像问下属一样，它会停下工作，给我一个快速汇报，我再调整任务，然后让它继续。

Qoder 支持这种功能吗？另外你怎么看未来人和 AI 的关系？不仅限于 AI Coding。

👦🏻 叔同

我们也支持类似功能。因为当 agent 长时间工作时，可能会跑偏，或者耍小聪明跳过任务。这种情况很常见。

我们会在任务开始时制定 todo list，agent 必须严格按列表执行，不能跳过或谎称完成未完成的任务。执行长任务时，我们可以随时询问，它会输出当前工作流，我们也能给出新的指令和要求来纠正方向。

这样可以避免 agent 工作数小时后结果跑偏，造成浪费。因此我们在这方面构建了强大的能力。

👦🏻 Koji

你认为未来人和 AI 的关系会是怎样的？不仅是 Coding 层面。

👦🏻 叔同

我还是想从 Coding 讲起。我们认为 Coding 将成为大语言模型的“双手”和“执行器”，是数字世界与物理世界的连接器，它能帮助人完成复杂任务。

人在其中将成为管理者，提出明确要求，由不同智能体理解、协同完成任务。未来在职场或商业社会中更有竞争力的人，一定是能充分驾驭这些 AI 的人，能管理好、协同好智能体，找到业务场景并创造价值。

这也是为什么会出现很多一人公司——它代表了未来人和 AI 高度协作的关系，形成创造力极强的组织。很多工作由 AI 协同完成，这种组织形态有可能成为主流。

👩🏻 Ronghui

虽然叫 Qoder，但你们会只做 Coding 吗？

👦🏻 叔同

目前我们专注于 Coding，但产品形态和覆盖场景会有很大外延。我们从下到上构建产品能力，在模型之上优化、定制，做上下文工程，形成大量 agent 和工具。

当能力领先后，产品形态和界面会延展。IDE 只是专业开发者的核心界面，是最大工具集。CLI 则面向更专业或自动化的开发场景。我们还会将 agent 集成到更多流水线和定制化场景中，甚至可以在手机或 APP 内唤起 agent 为其工作。

所以形态上会有更多展开。每一个小需求都能被满足，场景会被充分数字化；复杂任务也能由 AI 承担，agent 成为执行器。场景会被全面打开，未来绝不会只有 IDE 一种形态。

👩🏻 Ronghui

我感觉 Qoder 承载的使命和可想象的外延更广。

👦🏻 叔同

是的，我们希望把自己定位为模型之上的编程智能体。我们的 IDE 是编程智能体 IDE 平台，未来还会有编程智能体的其他平台形态。

👦🏻 Koji

在我们录播客的前一天，我们注意到 Qoder 刚发布了 CLI，也就是命令行模式。想请教一下你们发布它的背景和内部思考是什么？刚才已经提到了一些，不知道有没有补充。另外，也想了解它和 Claude Code 有没有竞争关系？如果有，怎么竞争？

👦🏻 叔同

我们先说为什么要构建这个形态。其实还是回到我们做 IDE 的初衷：希望把 Coding 能力以最普遍的工作界面提供给开发者。因为大多数开发者都是通过 IDE 工作，所以我们自然要做 IDE。

但我们也看到，开发界面的使用场景非常多元。开发者不会一周七天、一个月二十多天都在写代码，他们还有很多不同的工作，在不同的平台上完成。有的需要写脚本，有的做系统维护、流水线集成，或者在特定平台上完成任务。而在 IDE 里，这是一个全封装形态，智能体无法外化、无法被灵活集成。

所以我们需要一种更灵活的方式，让智能体能够以脚本或命令行的形式被调用、被集成。此外，不同开发者使用不同的 IDE，比如 Vim、JetBrains 系列、VS Code 等。我们不能假设所有人都在用 VS Code，而我们的 IDE 又是基于 VS Code 的，这样就天然放弃了一部分用户。

但 CLI 可以服务所有开发者，它打开了更广泛的用户群体。从这些角度来看，我们一定会推出这种形态，因为目标是服务更大规模的用户。

第二个问题是怎么和 Claude Code 竞争。我们认为这不是单一维度的竞争。从模型和成本角度看，Claude Code 的上下文构建相对简单粗暴，但效果很好。而我们做得更精细。比如说，使用自家模型能大幅降低成本，而用外部模型成本会很高，因此我们必须在上下文组装上做更多优化。

我们在 agent 的灵活性定义、sub-agent 的设计等方面都有自己的实现。

另一方面，我们更强调多场景渗透和应用层创新。比如我可以在手机上安排任务，也能在 Slack 或 IM 工具中分配和跟进工作。这种场景化能力能满足用户的刚需。而模型厂商通常不会做这些应用层创新，所以我们与他们形成差异化定位。

👦🏻 Koji

刚才多次提到“上下文工程”，听起来 Qoder 在这方面做了很多工作。能不能展开讲讲？有没有一些具体的方法论或优化经验可以分享？

👦🏻 叔同

我们要构建一个优秀的上下文工程，一定要做到“多、快、好、省”。同时要思考 agent 与工具的关系——设计哪些工具、用什么技术方案来驱动模型高效工作。本质上，这都是在驱动大语言模型完成任务。

我们做了很多探索，包括相关性检索。因为不可能每次都把全部内容丢给模型，那样既耗时又耗成本。所以我们要找到真正相关的内容——是用向量检索、文本检索，还是语义检索？每个问题都有自己的最佳实现方式。

同时要决定是用 agent 还是 sub-agent、用哪种方式调用工具，聚合上下文内容，拼出合理上下文。上下文并不是越长越好。我们会让模型在合理上下文内交互，循环调用工具，最终高效完成任务，实现“多、快、好、省”的效果。

我们还构建了记忆系统。记忆非常关键。用户在与模型交互、使用上下文工程时，会给出隐含的指示——他不会明确写在提示词里，而是通过反馈表达，比如“这不是我要的”“我更喜欢这个”。我们会把这些偏好快速抽象成规则，一部分变成系统提示词，一部分变成长期记忆。

这种记忆会影响之后的所有交互，让模型逐渐理解用户偏好。这样既能控制上下文长度、降低成本，又能让模型越来越懂用户。开发者会觉得“这个工具越来越懂我”，因为它把我的行为习惯学习成了自身的行为归约。当我还没解释清楚时，它就已经明白了。

我们在这方面做了大量探索和创新。

👦🏻 Koji

刚才提到 Memory 的 Infra，还用了沙箱、Todo List。这些都是你们自建的吗？还是也用了开源方案？

👦🏻 叔同

都是自建的。这也要求团队在这个领域有足够深的理解和积累。

1024 寄语：AI 时代，程序员如何进化？

👩🏻 Ronghui

想问一个比较个人的问题：如果你回到刚参加工作的时候，知道后来世界会发生这么多变化，现在回看那时的自己，会有什么感触？

👦🏻 叔同

我觉得对每个职业工作者来说，都需要有预判性，要能感知未来的变化和趋势。不要为过去的事情买单，而要为未来即将发生的事情做准备。我希望大家能勇敢迈出那一步，主动选择，而不是被动被推着走。这个世界的容错率其实很高，应该有信心、有行动。

👩🏻 Ronghui

你自己做了这么久程序员，在做这个产品的过程中，有没有一种“革自己的命”的感觉？

👦🏻 叔同

我并不觉得是在做革命性的工具，而是在为未来的程序员探索一条发展路径。我们思考的是：未来的开发者或泛开发者需要什么样的工具？什么样的工具能创造更大的商业价值？这些变化无论我们今天做不做，都会发生——工作的方式、组织协作关系都在改变。

我们希望以更面向未来、更懂开发者、更理解未来组织生产关系和协作方式的姿态去切入，探索一个能让开发者持续成长的平台。而不是说“以后程序员不需要了，全是工具在做”，我非常不认同这种观点。未来一定是人和 agent 协同工作的形态。

我始终认为，一个优秀的开发者要站在技术的肩膀上，而不是成为技术的奴隶。所谓“站在技术肩膀上”，就是让技术为我所用，创造更大的产能和商业价值。抓住技术红利，你就是弄潮儿；抓不住，就可能被淘汰。

所以我们希望让 AI Coding 能力平民化，让获取门槛更低。但如果不能主动拥抱、不能学会驾驭 AI，也会有问题。

👩🏻 Ronghui

那你怎么看“AI 会取代程序员”这件事？

👦🏻 叔同

我相对比较乐观，不认为 AI 会取代程序员。程序员要学会驾驭 AI，把它当成巨人，站在它的肩膀上去创造业务价值。这样的程序员会更有前景。

另外，可以参考“杰文斯悖论”：当成本降低时，需求反而会被放大。AI 降低了开发成本，创作需求就会爆发式增长，出现大量的泛开发者。他们可以做小创新、满足特定群体，而专业程序员会做大创新，因为他们有更强的专业能力。所以程序员的数量可能反而会更多。

关键是要能借助 AI 爆发出 5 倍、10 倍的生产力，这样的人会更有竞争力。做不到这一点，可能就会变成普通程序员。总体来看，我还是很乐观。

👩🏻 Ronghui

你们内部现在的开发方式是怎样的？

👦🏻 叔同

我们团队日常的大部分开发任务都在用 Qoder。

👦🏻 Koji

也就是用 Qoder 来做 Qoder？

👦🏻 叔同

对。我们还有一个明确的要求：每个人的代码中，有多少比例是 AI 生成的。这算是逼着大家去革新自己，不是革命，是自我革新。

👩🏻 Ronghui

这是从什么时候开始的？

👦🏻 叔同

从灵码时代就开始了。

👦🏻 Koji

那你觉得未来工程师的核心竞争力会从“编码能力”转变成什么？会变得更复合吗？

👦🏻 叔同

我们认为“开发者”的定义会变得更宽泛。以前大家分得很细：有后端、前端、iOS、数据库、DBA 等岗位。

但现在这些边界正在被打破。后端也能做前端，前端也能搞后端，因为大语言模型极大地抹平了技术差异。个体能力被放大，边界被突破。打破第一层边界后，还有第二层边界：AI 的写代码能力已经超越人类，人与它竞争写代码没有意义。

所以人要往上走一层，具备需求洞察、意图识别、要求描述、整体设计、结果验收、产品 sense 等能力。这些将成为未来开发者的核心竞争力。每个开发者都要成长为复合型人才。

👦🏻 Koji

如果让你给两类人提建议——一类是程序员，一类是大一计算机新生——帮助他们在 AI 时代更好地发展，你会分别给出什么建议？

👦🏻 叔同

对计算机专业的一年级学生，我的建议有两点：

第一，充分拥抱 AI，探索 AI 能为你做的边界，成为一个能驾驭 AI 的人。

第二，一定要扎实学习计算机的专业知识。

今天计算机体系结构并没有革命性变化，我们依然在冯·诺依曼架构下工作。操作系统依然是 Linux、Windows、macOS。如果不了解这些底层结构，就无法判断 AI 生成的结果好坏，也无法真正驾驭它。AI 可能会“忽悠你”。

同时，AI 也不是万能的。比如大语言模型并不能创造大语言模型，AI Coding 产品可以做一个 iOS App，但它做不了 iOS 系统，因为那太复杂、太顶层、太稀缺。

不能被 AI 取代的部分，才是附加值最高的部分。未来，简单的软件可能只值五毛钱，越是简单、常见的创意就越不值钱。只有做 AI 做不了的事，提升专业性，才能保持创造力和长期竞争力。

👩🏻 Ronghui

那在大厂工作的工程师，职业发展上需要哪些核心技能？

👦🏻 叔同

对计算机相关的同学来说，现在其实是一个非常好的时代。以前大家常说“程序员不够用”“开发延期”，未来这种情况可能会被打破，因为 AI 正在突破开发的瓶颈，这是一个很好的信号。

👦🏻 Koji

听起来突然觉得好开心，因为之前各种项目延期真的是最痛苦的来源。

👦🏻 叔同

其实我觉得这反而是程序员的优势所在。过去二三十年，这个行业发展飞快，程序员几乎都在持续学习。所以对他们来说，再学一个新东西，或者把某个技能学精，并不是困难的事。这反而成为今天最大的优势。我对程序员这个群体一直很有信心，他们会在 AI 时代继续创造更高的产能和更强的竞争力。

双十一往事：一个顶级架构师的两次“高考”

👩🏻 Ronghui

那你自己呢？你的经历挺传奇的，搞过双十一架构这种级别的项目。

👦🏻 Koji

连续九年双十一不宕机是靠你在背后顶着啊（笑）。

我以前在聚美负责移动事业部，那时候每逢大促就宕机。有一年大促前夜，几个工程师甚至跑去机房上香，祈祷系统别崩。后来这还成了一个表情包，我们每次都拿它调侃自己。

所以你可以讲讲你当年的一些故事吗？

👦🏻 叔同

不能说只靠我和我的团队，其实是整个公司投入了巨大的资源，很多优秀的同事都参与进来。我加入的时候，正好赶上双十一流量暴涨的那一阶段。那时的场景是这样的——平时的流量和双十一一比，大概能放大一百倍。几乎每个系统都在极限边缘。

当时的工作方式，是每个人负责一个系统，或者几个人负责一个系统，大家“铁路警察，各管一段”。平时问题不大，因为日常流量有余量；但一旦流量暴涨，这种分散架构就容易散架。你不能用百倍的成本去撑百倍的流量——不仅不经济，技术上也不现实。

于是我们开始在中间件、压测、容量管理、自动化运维和弹性扩展等方面进行全方位的技术升级。那是 2013 年，我们团队提出并落地了一个概念——“全链路压测”。这是全球第一个系统性提出这个做法的团队。今天，全链路压测已经成了所有互联网平台的标准配置。

这个技术的目标是让整个系统没有瓶颈。就是当流量超过处理能力时，我们不让流量进来；只要流量能进来，就一定能被处理。所有系统都保持在一致的水位上——既没有冗余，也没有超载。一旦哪个环节出现“满载”，流量就会被拦在外面，不让它冲垮系统。通过这种全局架构的平衡，我们在很大程度上解决了双十一的稳定性问题。

👦🏻 Koji

听起来你现在讲得轻描淡写，但我想那时遇到的阻力绝不只是技术问题吧？毕竟几千个工程师，每个人都有自己的 OKR。要他们为了这套方案投入大量时间改造系统，而这件事可能和他们的绩效没直接关系。那你当时是怎么推动的？

👦🏻 叔同

我们那时有一个非常强的共同目标——双十一不能挂。这是所有人的共识。整个公司上上下下都围绕这个目标一体化作战。还有一点特别关键：双十一不能延期。软件项目可以延期交付，但双十一不能。这种“必须按时打仗”的约束，让所有资源都围绕着一个节点倾斜。

我们团队的角色更像是一个“驱动者”和“兜底者”。能协调的资源我们去协调，协调不了的，我们自己上——因为时间点就摆在那里。我们会综合使用各种推动方式：有自上而下的指令，也有自下而上的协同。

此外，还有一个很重要的基础优势——技术栈统一。阿里很早就实现了技术体系的统一。如果像有的公司那样，一边是 Python，一边是 Go，还有 Java、C++ 混着用，这事根本推不动。正因为大家都在同一个技术栈上，很多中间件是通用的，我们才能实现“一改一大片”。最终，全链路压测这套体系，我们只用了三个月就完成。

那次项目的成就感非常强。它不仅保障了那一年的双十一，也成了整个行业的里程碑。参与这件事的人，后来几乎都得到了非常好的成长。

👦🏻 Koji

那几年我在聚美，我们每次大促前夜，没人知道零点之后系统会不会挂。那种感觉，就像在祈祷。我记得我坐在作战室，看着屏幕上那条交易曲线跳动，谁都不敢呼吸。你们那边当时的心态是什么？阿里的工程师们也会紧张吗？

👦🏻 叔同

当然紧张（笑）。我们的理念是“在双十一之前创造双十一”。也就是说，在真正的那天到来前，我们会多次做完整演练。这些演练都是真实流量、真实用户路径、真实请求，唯一的区别是量级和时机。

但再怎么演练，也永远不可能 100% 还原零点那一刻的真实场景。所以，每次都还是会有些焦虑。我们通常会做三次全量演练，比如每秒 50 万笔交易，从零点起压，一秒钟爆发。每次演练都能暴露出新的问题——有的是技术瓶颈，有的是并发或容量问题。我们一轮一轮修复，到第三次、第四次时，大多数问题都收敛了。

可即便这样，真正到双十一那天，依然不敢掉以轻心。因为实际流量的分布、爆款商品、营销节奏，都会带来新的不确定性。所以我们要求系统具备动态调度和自我修复能力。

从 2013 年之后，基本再也没出过重大事故，只有一些小波动。这在那个量级下，其实已经是奇迹了。

👦🏻 Koji

太厉害了。

👩🏻 Ronghui

那双十一结束那一刻，你的心情是什么样的？

👦🏻 叔同

有时候也有点靠运气。

👦🏻 Koji

是不是会去灵隐寺拜一拜？

👦🏻 叔同

对对对，有的（笑）。这也成了一种传统文化。

👩🏻 Ronghui

双十一前去灵隐寺拜一拜，成了团队仪式感。

👦🏻 叔同

对，一种团建，也是一种释放压力的方式。大家那时候都太紧张了。

👦🏻 Koji

是过那一秒，心就放下来了吗？

👦🏻 叔同

一般十分钟吧。

👩🏻 Ronghui

你每一年心情都一样吗？有没有什么时候心情特别不一样？有没有想哭的感觉？

👦🏻 叔同

最开始的时候压力比较大，后来就越来越从容了。因为我们技术架构是一代代往前发展的，每一代都会面临新的问题，也会有新的机会。比如我们解决了稳定性问题，接下来就要解决成本问题。我们不希望 50 倍的流量要花 3 倍的成本。那我们后面定了个目标：双十一可能有 50 倍的流量，但对整个集团来说，能不能不多花一分钱？

👦🏻 Koji

这是你提的吗？

👦🏻 叔同

不是，是 CTO 提的。但我们帮他做到了。这也涉及到我们为什么要搞容器化、云原生化。我们一直有一个 mindset：永远要从技术中获得红利，让技术驱动商业，创造价值。阿里巴巴的技术人一直有这样的追求。提出这样的想法，我们也没有觉得不可能。

因为业务里有很多板块：国内的、国际的、搜索、广告、电商、飞猪、饿了么、高德、UC 等等，包括模型。并不是每个业务都参与双十一，但每个业务都不希望受到影响。我们通过调度管理弹性、容器等新技术，把这些资源打通，实现分时复用、弹性伸缩、混合部署，包括数据类和业务类的。通过这些技术，我们可以在短时间内完成大规模集群的伸缩，比如 10 到 20 分钟内完成资源切换。

云上也可以复用，各个业务板块都能复用，不同时段之间也能复用。把这些做到极致，就带来了巨大的成本节约。这些做法也成为行业中的技术标准，推动了国内容器化、云原生技术的普及。因为大家对效率、弹性和成本都有同样的需求。双十一只是一个缩影。

👩🏻 Ronghui

就像每年一次高考。你刚说那个，我感觉很像模拟考。先模拟几次，不停查哪里不会，然后改。那你是从哪一年开始不管双十一了？

👦🏻 叔同

后来我开始做另一件事。当我们把阿里的稳定性和成本做到较高水平后，就开始考虑如何把这些技术变现，让能力溢出。因为这些是行业的普遍需求，所以我们开始做产品化，赋能行业的用户，包括很多互联网企业、产业互联网用户，用我们的产品化技术服务他们。我做了好几年这方面的工作，负责一些产品。后来就逐渐不再负责双十一了。

👩🏻 Ronghui

那再到双十一的时候有什么心情？

👦🏻 Koji

放松购物的心情？

👦🏻 叔同

对。

👦🏻 Koji

终于可以随便买，给服务器猛加压力。现在终于轮到我加压力了，而不是我扛压力。

👦🏻 叔同

哈哈，对。但其实我们值班的时候也是猛加压力。我们也希望业务大发展，个人也是消费者。如果系统稳定，我们也在买。如果系统出问题，就不买了赶紧去处理。没问题的话大家就一直买，也很优惠，还要抢一些。前 100 单是有优惠的。

👩🏻 Ronghui

那你会不会想，我已经做过双十一这么大的项目了，后面还要做什么才能获得同样的成就感？它要到什么程度才能匹配？

👦🏻 叔同

不能这么想。对我来说，还是要做有价值、有社会贡献的事。技术进步、造福他人，这就是价值感的来源。每个人都需要一个舞台，而这个舞台不是你想有就能有的，要看社会环境和你所在的平台，也要看你的能力是否准备好了。

我们当时做了判断，觉得我们的技术处理流量是独步全球的。再大的流量也不可能有了，中国人口红利也见顶了。我们有一套体系和方法论，也不需要再有太多革命性的东西。所以我们做了很多技术标准化的工作，大量开源，比如中间件开源、云原生领域开源，同时开始做商业化，希望技术创造新商业，通过技术打开新的商业局面。

本质上，就是让技术创造更大的价值，寻找更大的舞台。到今天，我们认为 AI 是最大的舞台和放大器，所以做了这样的选择。

👩🏻 Ronghui

两个月之后你觉得这个选择怎么样？现在发布两个月了。

👦🏻 叔同

很正确，无比正确。

👦🏻 Koji

无比正确。最后一个问题：在你看来，三年、五年之后做到什么样的成绩，你会觉得特别满意？你想象中的那个画面，程序员到用户，会是什么样？

👦🏻 叔同

我们畅想未来，如果三年后愿景实现，希望在 Qoder 这样的产品上生产出最多的真实软件——具备商业价值、覆盖最多场景、通过软件产生更多价值。

从世界变化的角度看，关键是大家相不相信 AGI 会到来。我的观点是，希望 Coding 成为一种通用能力，通过智能体的方式外化出来。就像Sam Altman讲的，从对话到推理，再到 agent、创新、组织。

我觉得三年这个窗口里，“组织”这件事可能会发生。AI 多智能体可以形成联动，完成宏大、长期、复杂的目标，调用各种工具与现实世界交互。Coding 能帮助它解决复杂问题，并带来确定性。大语言模型生成内容时不具备确定性，但代码可以带来确定性。未来的管理、生产、实践中，Coding 是必要选择。

从需求端看，大家的需求可能都得到充分满足，会出现很多新的业务形态、新的创业业务。从场景端看，比如马斯克登上火星，火星的房子肯定不是宇航员建的，而是 AI 建的。那一定是大语言模型、agent、机器人一起驱动这件事发生。我相信这一天会到来，Coding 会发挥重要作用。

👦🏻 Koji

谢谢叔同来做客「十字路口」，也希望 Qoder 取得更多成绩。欢迎半年后、一年后来复盘再聊一次。

👦🏻 叔同

感谢。

参考资料

[1]Qoder: https://qoder.com/

文章来自于微信公众号 “十字路口Crossing”，作者 “十字路口Crossing”