大厂CIO独家分享：AI如何重塑开发者未来十年

在 AI 时代，若你还在紧盯代码量、执着于全栈工程师的招聘，或者仅凭技术贡献率来评判价值，执着于业务提效的比例而忽略产研价值，你很可能已经被所谓的“常识”困住了脚步。

AI 时代，技术人如何自处和突围？

阿里云智能集团副总裁、CIO 蒋林泉（花名：雁杨），从程序员到国内最头部的云计算厂商的 CIO，既完整经历了从云计算到 AI 原生的技术浪潮，又在这个过程中完成了自身角色的转变，深知开发者在 AI 时代的竞争力应该如何构建。

这期《C 位面对面》，极客邦科技创始人兼 CEO 霍太稳（Kevin），与蒋林泉（以下称雁杨）展开深度访谈，探讨了 AI 对技术人和产研变革的深远影响。

对话开始前，我们先划重点：

• AI 时代，技术贡献值该怎么衡量？AI 生码采纳率和真实提效有多大关系？

• 技术人的未来，是全栈工程师吗？“AI 产品设计前端工程师”是什么新物种？

• AI 提效，是先产研，还是先业务？怎么看产研提效的价值？

• AI 引擎如何靠知识驱动？知识怎么分类？应该由谁主导？

• 这轮 AI 下，大厂 CIO 如何招人？顶尖能力是什么？

带着问题找答案，我们一起回顾这场对话的精髓。

1

AI 技术革命的大时代下，那些焦虑和不焦虑的人

我们用一个思想实验开始。

雁杨说，他很早给团队做过简单的思想实验：假设 AI 一定会这样发展，若我们公司装作 AI 没发生，固守旧有模式，但你的同学在隔壁公司，他们积极拥抱 AI、重塑自己。一边是惯性的温床，一边是变革的暗流，你选哪个？大家毫不犹豫地选主动变革。

这引申到遍布网络的焦虑话题，为什么焦虑？ 实际上，是不确认自己是否能适应 AI 时代，担心被时代抛弃。

当然，我们总是先预设大量的焦虑，但近期与众多程序员接触，InfoQ 发现，大家并没有那么强烈的焦虑，反而充满对未来的一腔热情。

有人充满热忱，有人天生钝感。雁杨在谈话中打趣说，“不焦虑的人分两类，一类是善于用 AI 所以不焦虑。还有一类，他不善于，但还没意识到，也不焦虑。”当然，大部分人应该是另一类，能意识到 AI 很重要但并不善于用它。

导致焦虑的源头在自己，不在 AI。雁杨说到一个人生话题 ： 任何一段职业都是一段 Journey，一个人一般不会在一家公司干一辈子，所以你可以规避一家公司的 AI 变革，但你规避不了整个 AI 时代和整个行业的变革。 时代的浪潮有它残酷的一面，与其说是向死而生，不如说主动站在最潮头。“善于用 AI 的人和组织，将来会击败不善于用 AI 的”。

当然，站在 AI 浪潮最前的团队是很辛苦的，他们既要做业务，又要提效，还要适应 AI 时代的转型变革，但就是自然而然地不焦虑了。因为对于程序员来说，未来几年一定要接受 AI，要基于 AI 去做事，这是个本质的存在。

很多人关心 AI 投入，对个人的价值回报。的确，在技术变革中一定会浮现价值和价格两个概念，这适合引用雁杨的经典说法：价格是围绕价值波动的。人的价值来自于符合时代的能力，这是真正的“地心引力”，只要价值在，你的价格迟早会朝着价值回归。

相反，如果用“价格”去拉动大家朝着价值方向靠拢，“价格”只会沦为一种信号。所以，让价格自然地向价值靠拢，这是第一层意义。第二层是，当我们用 AI 能力提升价值，一定会吸引到同路人，那些想一起站在 AI 时代潮头的人会毫不迟疑地加入，这就形成一个好的循环。

2

代码行数≠高产出，AI 生码采纳率≠真提效

谈焦虑的时候我们谈到了价值。AI 变革继续，程序员的技术贡献，该怎么衡量？

不少人或许会觉得，AI 能辅助写代码了，程序员的工作效率岂不直线上升？——并没有。在大型企业的技术团队，程序员的 80% 时间不是在写代码，而是在沟通；真正用来编程的时间，往往只剩下 10% 到 20%。进一步讲，即使生码率 30% 实现了又如何？ 全部写代码节省掉又如何？程序员的总环节时间并没有明显节省，人也几乎一个都不能少。

AI 可以生成代码，但目前大部分都是基础的 “脚手架代码”，这些代码通常不包含复杂的业务逻辑，与此同时，越是容易生成的代码，它采纳率越高。相对比，“那些最关键的代码、业务逻辑，和那些比较难的算法，或者说是跟现有系统的复杂集成还要保证兼容的，这都是靠人脑去做。”雁杨直接指出。

所以在评判程序员的绩效时，雁杨从来不单看写了多少行代码。“我带过各种团队，包括芯片的、内核的、虚拟化的，再到这个数据的、调度的、前端的；我发现前端代码量一般特别大，但一行前端代码和核心代码相比，价值可能只是后者的 1/ 1000。那怎么能用代码量来度量？” 以前尚且如此，何况 AI 生码也带来大量“灌水”的今天。

透过 InfoQ 与阿里云、亚马逊等研发资深人士，发现一个重要的信息点：企业最核心的研发人员，每年写的最核心的代码，可能一年连一百行都不到，但每一行消耗了大量的时间去思考，因为每一行可能都会影响着企业几十亿甚至几百亿的一个业务，所以，核心代码是企业非常慎重对待的。

一个很大的疑问来了， AI 生码采用率，到底和我们真实的提效关系有多大？

于是，这里涉及一个现实又复杂的课题：如何度量。 雁杨认为，“我们要诚实地面对自己，要先去度量同样类型的需求下，整个项目组把时间究竟花在哪里？ 然后，我们能不能用 AI 把这些时间，端到端地从项目原来需要 10 个人变成只用 5 个人？”

所以最终，度量一个需求的效率，雁杨选择用真实的“人月”数据作为单位。“以端到端的方式来看，我们先回到业务的最远端，看能够产生多大的价值，再看实现这个需求消耗多少‘人月’，那就是效能的度量。”

这里也延展出另一个经典的话题：软件工程度量的复杂度，并不是简单的线性关系，源于软件开发是逻辑与协作高度耦合的产物，而非流水线作业（出自布鲁克斯的经典之作 《人月神话》）。书中揭示的核心逻辑是：如果 5 个程序员可以用 6 个月做好软件，那么再加 5 个程序员（变成 10 个人），能不能减少一半时间做好软件（3 个月）？答案是否定的。 雁杨强调的逻辑是： 软件工程的核心是沟通。

如果通过增加一倍的人数，就期望减少一半的完成时间，是不成立的。雁杨剖析道，“团队增加人数，反而导致增加大量的沟通时间，就像由原来的 5 个人互相沟通，变成现在的 10 个人互相协同，人的沟通节点指数级放大，管理的难度随着人数增加而增加。” 很显然，达不到最初的设定结果。这是《人月神话》映射的思维谬误，似乎产生了一种人力代替的幻觉。

当然，选择引入 AI 无疑是正确的，但回归到症结：我们不能期待，仅靠提升 AI 生码采用率就能提升端到端的研发效能，因为增加的 AI 就像上述假设中增加的人一样，然而，阻力点在沟通成本。

那么 AI 时代，避免高昂的沟通成本以实现研发提效，是不是只有一种选择，就是构建全栈工程师？ 我们去看下一个话题。

3

工程师的未来，全栈是理想，半全栈是现实

提到程序员 80% 的时间花费在沟通，就不得不提一个滞留企业多年的难题：部门墙。

有实践数据显示，团队内沟通频率是跨团队的几十倍甚至上百倍， 软件工程刚好要跨越很多部门，这充分示意了“部门墙”。

即使有明确的分工，但由于目标差异、沟通障碍、文化差异、资源不对等等原因，跨部门时这堵“墙”仍然存在。比如，业务团队可能希望迅速推出新功能或调整策略，产品经理则希望确保产品质量和可用性，技术团队需要更多的时间来实现技术方案和进行测试。他们 KPI 不同、信息也不完全对等，在跨部门协作时容易因出现冲突或不一致，由此耽误良久。

为了解决部门墙问题，过去业界提出“全栈工程师”这种方案，如果一个人能够同时懂前端、又会后端、还会测试... 那沟通成本问题不就解决了吗？但理想丰满，现实骨感，想要打造具备前端、后端及算法的全栈能力的人才很难——门槛过高，招不到人。

另外，即使全栈工程师有其独特价值，但个人基于自身的职业发展，习惯于深入某个领域（要么前端路线、要么后端架构、要么测试工程，等等），而许多公司基于现实状况，其岗位也依旧按照传统的角色划分（前端、后端、测试）。即使基于个人热爱恰巧掌握全栈能力，但也无法脱离行业规则，更不能在实操中越界工作，所以，大家并没有一条明确的全栈路线可循。

基于这样的历史发展惯性，事情过去 10 年了，大家热议的全栈工程师一直没有推开。

但如今，雁杨发现，AI 让这件事变简单了。 他发现，自己团队各个职能部门的人，都开始尝试跨领域，用 AI 辅助学习：有前端告诉他，说自己写后端好像也没那么难了；还有算法工程师已经涉足前端和后端开发，手搓了个 Manus 出来。

“AI 会一直在那里，它可以不停教你，让你在陌生领域学习新技能的速度极大提升。如果你错了，可以把这个错误扔给 AI，说你帮我改一改，没有了挫折感。但以前你在一个陌生世界里会非常容易受挫——出了问题要搞半天，你就会放弃了。 ”雁杨如是说。

进一步探索，雁杨对程序员的角色也有了新思路，他设立了一个新的类全栈角色：“AI 产品设计前端工程师”。顾名思义，即产品、设计、前端 “三合一”，而“AI 工程师”则强调要用 AI 技术辅助。

他认为，如果一个产品经理既懂设计，又会前端开发，那么在与客户沟通时，自己就可以把想法转化为设计稿，甚至能做出 demo，直接与业务方交流，对业务需求准确度的把控，大有裨益。

过去，团队和业务方沟通依赖 paperwork，但写出来的东西和实际需求之间往往会有偏差。等产品上线后，业务方常常觉得，结果并不是他们真正想要的。如果产品经理自己就能够把设计做出来（退一步讲，即使写不出代码也没关系），至少可以直接与业务方做产品的交互展示和现场修改，一切就高效很多。依照“全栈”思路，虽不求一个人精通产品、设计、前端三个环节，但融合两个环节，也能打掉一个“部门墙”，是不小的进步。

现实如此，即使有 AI 加持，多合一的全栈工程师也是稀有的存在。雁杨很清楚，理想归理想，现实还得分步来，对于完整的 “全栈”角色，他主张拆成两节：一个叫“产品设计前端”，一个叫“架构与后端”。

这“两节化”的 AI 工程师岗位，完全不同：

• 后端更多是互联网架构，涉及高可用、可扩展、性能、 API ；
• 前端基于 API ，做好交互，把它呈现给业务方；
• 最终，API 成为“产品设计前端”和“架构与后端”两节之间的 Bridge。

目前，阿里云 CIO 团队的对外招聘中，已经公布了“AI 产品设计前端工程师”岗位。雁杨并未贸然给这个岗位起个高深的名字，他想更准确、清楚地传递给开发者。

感兴趣的朋友可以关注 AI 工程师的新岗位，透过 JD 去看看真实要点。（阿里云智能 -AI 产品设计前端工程师（PDFE）招聘[https://careers.aliyun.com/off-campus/position-detail?&positionId=100000403001&trace=qrcode_share]）

4

AI 提效，产研先给业务“打个样”

我们用 AI 武装多合一的全栈能力，目的是提升端到端的真实效率，这里涉及很关键的两个层面：业务提效、产研提效。

雁杨在 AICon 2025 深圳站上，曾分享过在阿里云内部推进 AI 转型，本质上是需要为业务提供 Result as a Service（RaaS），而阿里云 CIO 团队可能是当前时点为数不多的，能够真正大规模实现端到端落地、给业务交付结果的实践团队。

之所以能达到上述效果，除了在演讲中分享到的内容（完整版：阿里云 CIO 蒋林泉：AI 大模型时代，我们如何用 RIDE 实现 RaaS 的首次落地？），雁杨还提到其中一个小改革：他把产研提效的顺序，放到了业务提效前面，先通过产研提效自闭环解决问题，再跨部门开展业务提效。

这与过去或者很多企业的常规想法可能有出入。过去，业务提效往往被放在产研提效前，主要是因为业务效果更直观，见效快。企业的核心目标通常是为了帮助业务发展和创新，因此会优先关注如何提升业务效率。

在他所带的 CIO 团队，也曾存在同样的疑问：为何不先做业务提效？ 他用自己真实的想法去说服大家：“我们研发和产品去用 AI 做业务产品时，要跟业务的知识去做融合，因为知识在业务的脑子里面，所以要跨团队去获取知识、去协作。但是，产研的知识、写代码的知识在产研脑子里，所以知识本身是在团队自闭环的。于是，什么代码好与不好，程序员自己就能评价，数据、评测能力都在自己团队，并且代码是有编译器检查验证的。相反，如果在闭环中都做不到用 AI 来给自己提效，那不闭环的情况凭什么能做到？”

雁杨所说的“凭什么”就是产研到业务跨界，带来的难度指数升级，好的办法就是先通过自闭环“打个样”。

所以，雁杨推行团队本身在研发产品这些方面，都用 AI 来提效，“至少我们先打下个基础，自己知道 AI 是怎么回事，怎么深度去用才能带来这些能力，再去跟业务跨组织合作时，保证基础是扎实的。” 我们知道，这其中的过程尽是困难，所以他主张，一定要先解决掉自闭环的困难，才有基础去协助解决跨团队的困难。

这也已经呼应到阿里云 CIO 团队积极推行的 系统化 的组织激活金字塔，下面是研发的软件工程的产研提效（先行），上面是业务提效，来推动整个变革。（金字塔还包含最底层的阿里云大模型认证，作为拉齐 AI 全员通识的底座）。

在推动产研提效的过程中，不仅为跨业务团队合作打了样，也能看得到显性的提效成果，还有背后看不到的价值。

“我们的迭代效率提高了，使得在满足业务需求的正确性、价值性上，得到极大的提升。” 过去很多项目因为种种摩擦原因，上线了发现不是业务想要的，但开发团队常常因为返工时间不足，于是“改不动了，就这样吧”，最终留下不少“半垃圾的技术债”。同样地，很多企业内部，都是这么不停地上线，不停地堆叠 “技术债”，尽管我们说在不断生产有价值的东西，但也带来大量的垃圾补丁——又只好不断地“补丁加补丁”。

但 AI 打破了这种无力的恶性循环，让开发者在软件上线前就能与业务方更充分地交流确认，不断校准方向，最终做到“一上线就是精准满足客户需求的”。这种快速迭代、准确满足业务需求的能力，同时也免去了给未来留下大量的技术债，在雁杨看来，这是很难被效率衡量的，但恰恰是产研 AI 提效的一个质变。

5

先炼好“燃料”，再发动引擎

先做产研提效再做业务提效，追其根本，雁杨认为，“这一轮的 AI 革命，如果想要落地，业务跟 IT 之间的交互要非常融洽、无缝地进行协作。” 如果划出协作的关键，是 IT 部门要获取业务部门大脑中的 “知识”。

他指出：“我们这一轮 AI，假设它是引擎，那知识就是燃料。”

“业务知识在业务的脑子里，不在 IT 的脑子里，所以这个引擎的燃料存在于另外一个团队的大脑，如果不能从中掏出来正确的燃料，AI 这个引擎是走不动的。想要掏出这个燃料，就要紧密协作，促使业务配合，否则从人脑的知识，变成一个别人读得懂的、正确的知识，难度是很高的。”

他把这些燃料知识分两类：一类是结构化的知识，一般都在系统、数据库、大数据里，这部分知识由 IT 部门主导；另一类是非结构化知识，比如语言类知识等，应该由业务部门主导。 两者结合起来，才能形成魔法的效应。

问题来了，对于普通的一线研发同学，他能做什么？

可以理解为，产研同学要把自己公司现有积累的数据，不论是结构化的数据还是非结构化数据，通过 AI 方式将其整理成有价值的信息 ，提供给后面的 AI 引擎去燃烧。

这里有一个 “数据炼煤” 的工作。

做个类比，从煤炭工业标准，煤可以分为原煤（未洗选的天然煤）、洗选精煤（通过物理洗选去除杂质后的煤），而提炼数据的过程，就如同煤炭的提纯去杂。

“产研一定要把很多原煤（粗煤数据）变成洗选精煤（去杂质的数据），因为 AI 引擎烧不了粗煤，粗煤数据有错有漏、存在杂质，如果给 AI 引擎烧，烧出来的结果势必会让你看到无数杂质。但有些企业甚至连粗煤都没有，而是游离在业务方的脑子里，所以你必须先把粗煤弄出来，去掉杂质，最后才能给你的 AI 引擎去燃烧。”雁杨用了一段很形象的比喻。

他提醒技术人：不要临渊羡鱼，“鱼”就在自己手上。

可以这么理解，“编程里的数据是什么语料？其实就是代码本身。也就是说，自闭环的代码就是技术人手里的数据，同时本身又是专家，又手握工具，所以，完全可以先把自己领域的软件工程效率提升好。”相反如果只是等待外部条件成熟，抱怨与业务的不闭环，但又不去研究自己闭环的数据。这就等同于在江边徒劳张望——临渊羡鱼，不如退而结网。

6

这轮 AI 下，大厂 CIO 如何招人？

新一轮 AI 已经是一场变革，它对人的认知、能力、心性，都在促发新要求。

雁杨是过来人，他从以往的资深程序员走到 CIO 这个角色。谈到这两种角色的差异，他说到：“原来作为程序员，需求来自产品经理的 PRD ，所以接下来需要做的，就是单纯把原来别人已经准备好的 paperwork “翻译” 成代码；而 CIO 的角色，要理解业务、组织业务需求，把它变成对应的流程设计，再去组织团队的技术人员，翻译成代码。这里相当于，要左移到前面——即更多做业务接触和对产品经理的管理，也是更加的端到端。”

细心品读会发现，这里提到一个关键词：“左移”。 我们可以理解为，它是程序员未来发展中，不可或缺的自我修养。

雁杨提到两点能力：

第一， “永远朝左看”： 依照雁杨的经历，他发现，程序员永远要保持朝左看的意识和能力，也就是“左移”朝着产品和业务多看看，这会让程序员的数码世界和现实世界的匹配更升华。

第二，“基本功永远不过时”： 无论是 AI 时代还是非 AI 时代，程序员扎实的基本功是永远不过时的。

在能力之外，是人的心性。

富有好奇心、 保持韧性，是阿里云 CIO 招聘时最看重的两大特质。他解释称，AI 技术日新月异，所以人才需要保持好奇：“你不好奇就不能够一直跟进这些技术”；另外要有韧性：“因为你跟进技术时，会经常遭受挫折”。尤其在变革时代，挫折更多，韧性也就是具备“大心脏”来应对这些。

在历史性的巨大技术变革背景下，科技大厂就像一艘大船，总有人是船长，有些人是大副，还有些人是船员；不能要求每个船员都有好奇心，又有大心脏；但对于想做大副、做船长的领头人，总需要这样的特质。

当然，即使不是人人都具备这些特质，企业的整个组织也会“拖着”大家往前走。比如，阿里云以 CIO 团队为原点，很早开始推动“书同文、车同轨”的 AI 通识教育，通过 阿里云大模型认证 培训的方式，让技术人、非技术人都掌握相同的 AI 知识，让部门、跨部门都处在一个 AI 语境下沟通。

之所以这么做，因为拖着往前走的过程中，一定是有变革摩擦力的，而 AI 通识认知是减弱摩擦力的第一关。InfoQ 作为一家科技媒体，同样担忧 AI 转型的步伐和全员紧跟的节奏，一号位也在着力推动 AI First 的理念，让业务和产品都与 AI 充分联动起来。公司将近 150 人的规模，120 多人第一时间都拿到了阿里云的大模型认证，当下正在进一步寻求变革。

但雁杨认为，对于变革想法和通识问题是有先后的。“首先是你要先想到变革， 特别是变革里面主导这件事情的人，他一定会深刻认知到要去变革，‘书同文、车同轨’只是个必要条件（非充分），借此去跟公司的业务、技术团队拉齐，解决最基本的沟通摩擦力，否则变革会卡死在原地。然后，才是迎面进一步的阻力，需要带着好奇心、韧性来升级打怪”。

对于企业来说，想 AI 变革就先消除摩擦力。对于个人而言，有好奇心就马上去干，有问题就用韧性迎难而上，过程中需要弥补的能力，AI 也会帮你提升。一切都在不停变化，而这是唯一的适应和学习方式。

7

写在最后

谈话中，雁杨辟谣了一个说法，他说很多人设想 AI 能够马上改变什么，紧接着码农都不需要了。这是无稽之谈，最后一定是需要的。但不一样的是，我们确实可以通过 AI 让整个软件工程的效率得到巨大的提升。

站在全局去细微观察，雁杨发现，AI 其实是一面镜子。

想要 AI 产生魔法效应，就得一步一步找到问题和解法：从引入 AI 工具，到代码采用率，再到度量思考，紧接着用“全栈”攻破代码采用率不能解决的效率问题，但又遇上“半全栈”都很难实现的难题，最后尝试一刀切的“产品设计前端”与“架构后端”两节... ...AI 像一面镜子，在帮我们发现问题，AI 又辅助我们解决问题。截至目前，阿里云 CIO 团队借此已经实现非常大的效率提升。

从中看得出，任何新事物来了，用行动和热情与其相处，焦虑就随之消退。

透过雁杨的表达，他想告诉更多人，无论开发者、程序员、未来的 AI 工程师，还是 AI 当下的芸芸：既然我们认定，技术变革是不可逆的，那就做更理解这场变革的人，朝着 AI 对行业变革的趋势线方向，在势能爆发之前，率先启程，成为趋势的一部分。

文章来自于“InfoQ”，作者 “木子”。