AI 时代，技术人如何自处和突围？
阿里云智能集团副总裁、CIO 蒋林泉（花名：雁杨），从程序员到国内最头部的云计算厂商的 CIO，既完整经历了从云计算到 AI 原生的技术浪潮，又在这个过程中完成了自身角色的转变，深知开发者在 AI 时代的竞争力应该如何构建。
这期《C 位面对面》，极客邦科技创始人兼 CEO 霍太稳（Kevin），与蒋林泉（以下称雁杨）展开深度访谈，探讨了 AI 对技术人和产研变革的深远影响。
对话开始前，我们先划重点：
AI 时代，技术贡献值该怎么衡量？AI 生码采纳率和真实提效有多大关系？
技术人的未来，是全栈工程师吗？“AI 产品设计前端工程师”是什么新物种？
AI 提效，是先产研，还是先业务？怎么看产研提效的价值？
AI 引擎如何靠知识驱动？知识怎么分类？应该由谁主导？
这轮 AI 下，大厂 CIO 如何招人？顶尖能力是什么？
带着问题找答案，我们一起回顾这场对话的精髓。
一、AI 技术革命的大时代下，那些焦虑和不焦虑的人
我们用一个思想实验开始。
雁杨说，他很早给团队做过简单的思想实验：假设 AI 一定会这样发展，若我们公司装作 AI 没发生，固守旧有模式，但你的同学在隔壁公司，他们积极拥抱 AI、重塑自己。一边是惯性的温床，一边是变革的暗流，你选哪个？大家毫不犹豫地选主动变革。
这引申到遍布网络的焦虑话题，为什么焦虑？ 实际上，是不确认自己是否能适应 AI 时代，担心被时代抛弃。
当然，我们总是先预设大量的焦虑，但近期与众多程序员接触，InfoQ 发现，大家并没有那么强烈的焦虑，反而充满对未来的一腔热情。
有人充满热忱，有人天生钝感。雁杨在谈话中打趣说，“不焦虑的人分两类，一类是善于用 AI 所以不焦虑。还有一类，他不善于，但还没意识到，也不焦虑。”当然，大部分人应该是另一类，能意识到 AI 很重要但并不善于用它。
导致焦虑的源头在自己，不在 AI。雁杨说到一个人生话题 ： 任何一段职业都是一段 Journey，一个人一般不会在一家公司干一辈子，所以你可以规避一家公司的 AI 变革，但你规避不了整个 AI 时代和整个行业的变革。 时代的浪潮有它残酷的一面，与其说是向死而生，不如说主动站在最潮头。“善于用 AI 的人和组织，将来会击败不善于用 AI 的”。
当然，站在 AI 浪潮最前的团队是很辛苦的，他们既要做业务，又要提效，还要适应 AI 时代的转型变革，但就是自然而然地不焦虑了。因为对于程序员来说，未来几年一定要接受 AI，要基于 AI 去做事，这是个本质的存在。
很多人关心 AI 投入，对个人的价值回报。的确，在技术变革中一定会浮现价值和价格两个概念，这适合引用雁杨的经典说法：价格是围绕价值波动的。人的价值来自于符合时代的能力，这是真正的“地心引力”，只要价值在，你的价格迟早会朝着价值回归。
相反，如果用“价格”去拉动大家朝着价值方向靠拢，“价格”只会沦为一种信号。所以，让价格自然地向价值靠拢，这是第一层意义。第二层是，当我们用 AI 能力提升价值，一定会吸引到同路人，那些想一起站在 AI 时代潮头的人会毫不迟疑地加入，这就形成一个好的循环。
二、代码行数≠高产出，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 时代，避免高昂的沟通成本以实现研发提效，是不是只有一种选择，就是构建全栈工程师？ 我们去看下一个话题。
三、工程师的未来，全栈是理想，半全栈是现实
提到程序员 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]）
四、AI 提效，产研先给业务“打个样”
我们用 AI 武装多合一的全栈能力，目的是提升端到端的真实效率，这里涉及很关键的两个层面：业务提效、产研提效。
雁杨在 AICon 2025 深圳站上，曾分享过在阿里云内部推进 AI 转型，本质上是需要为业务提供 Result as a Service（RaaS），而阿里云 CIO 团队可能是当前时点为数不多的，能够真正大规模实现端到端落地、给业务交付结果的实践团队。
之所以能达到上述效果，除了在演讲中分享到的内容（完整版：阿里云 CIO 蒋林泉：AI 大模型时代，我们如何用 RIDE 实现 RaaS 的首次落地？），雁杨还提到其中一个小改革：他把产研提效的顺序，放到了业务提效前面，先通过产研提效自闭环解决问题，再跨部门开展业务提效。
这与过去或者很多企业的常规想法可能有出入。过去，业务提效往往被放在产研提效前，主要是因为业务效果更直观，见效快。企业的核心目标通常是为了帮助业务发展和创新，因此会优先关注如何提升业务效率。
在他所带的 CIO 团队，也曾存在同样的疑问：为何不先做业务提效？ 他用自己真实的想法去说服大家：“我们研发和产品去用 AI 做业务产品时，要跟业务的知识去做融合，因为知识在业务的脑子里面，所以要跨团队去获取知识、去协作。但是，产研的知识、写代码的知识在产研脑子里，所以知识本身是在团队自闭环的。于是，什么代码好与不好，程序员自己就能评价，数据、评测能力都在自己团队，并且代码是有编译器检查验证的。相反，如果在闭环中都做不到用 AI 来给自己提效，那不闭环的情况凭什么能做到？”
雁杨所说的“凭什么”就是产研到业务跨界，带来的难度指数升级，好的办法就是先通过自闭环“打个样”。
所以，雁杨推行团队本身在研发产品这些方面，都用 AI 来提效，“至少我们先打下个基础，自己知道 AI 是怎么回事，怎么深度去用才能带来这些能力，再去跟业务跨组织合作时，保证基础是扎实的。” 我们知道，这其中的过程尽是困难，所以他主张，一定要先解决掉自闭环的困难，才有基础去协助解决跨团队的困难。
这也已经呼应到阿里云 CIO 团队积极推行的 系统化 的组织激活金字塔，下面是研发的软件工程的产研提效（先行），上面是业务提效，来推动整个变革。（金字塔还包含最底层的阿里云大模型认证，作为拉齐 AI 全员通识的底座）。
在推动产研提效的过程中，不仅为跨业务团队合作打了样，也能看得到显性的提效成果，还有背后看不到的价值。
“我们的迭代效率提高了，使得在满足业务需求的正确性、价值性上，得到极大的提升。” 过去很多项目因为种种摩擦原因，上线了发现不是业务想要的，但开发团队常常因为返工时间不足，于是“改不动了，就这样吧”，最终留下不少“半垃圾的技术债”。同样地，很多企业内部，都是这么不停地上线，不停地堆叠 “技术债”，尽管我们说在不断生产有价值的东西，但也带来大量的垃圾补丁——又只好不断地“补丁加补丁”。
但 AI 打破了这种无力的恶性循环，让开发者在软件上线前就能与业务方更充分地交流确认，不断校准方向，最终做到“一上线就是精准满足客户需求的”。这种快速迭代、准确满足业务需求的能力，同时也免去了给未来留下大量的技术债，在雁杨看来，这是很难被效率衡量的，但恰恰是产研 AI 提效的一个质变。
五、先炼好“燃料”，再发动引擎
先做产研提效再做业务提效，追其根本，雁杨认为，“这一轮的 AI 革命，如果想要落地，业务跟 IT 之间的交互要非常融洽、无缝地进行协作。” 如果划出协作的关键，是 IT 部门要获取业务部门大脑中的 “知识”。
他指出：“我们这一轮 AI，假设它是引擎，那知识就是燃料。”
“业务知识在业务的脑子里，不在 IT 的脑子里，所以这个引擎的燃料存在于另外一个团队的大脑，如果不能从中掏出来正确的燃料，AI 这个引擎是走不动的。想要掏出这个燃料，就要紧密协作，促使业务配合，否则从人脑的知识，变成一个别人读得懂的、正确的知识，难度是很高的。”
他把这些燃料知识分两类：一类是结构化的知识，一般都在系统、数据库、大数据里，这部分知识由 IT 部门主导；另一类是非结构化知识，比如语言类知识等，应该由业务部门主导。 两者结合起来，才能形成魔法的效应。
问题来了，对于普通的一线研发同学，他能做什么？
可以理解为，产研同学要把自己公司现有积累的数据，不论是结构化的数据还是非结构化数据，通过 AI 方式将其整理成有价值的信息 ，提供给后面的 AI 引擎去燃烧。
这里有一个 “数据炼煤” 的工作。
做个类比，从煤炭工业标准，煤可以分为原煤（未洗选的天然煤）、洗选精煤（通过物理洗选去除杂质后的煤），而提炼数据的过程，就如同煤炭的提纯去杂。
“产研一定要把很多原煤（粗煤数据）变成洗选精煤（去杂质的数据），因为 AI 引擎烧不了粗煤，粗煤数据有错有漏、存在杂质，如果给 AI 引擎烧，烧出来的结果势必会让你看到无数杂质。但有些企业甚至连粗煤都没有，而是游离在业务方的脑子里，所以你必须先把粗煤弄出来，去掉杂质，最后才能给你的 AI 引擎去燃烧。”雁杨用了一段很形象的比喻。
他提醒技术人：不要临渊羡鱼，“鱼”就在自己手上。
可以这么理解，“编程里的数据是什么语料？其实就是代码本身。也就是说，自闭环的代码就是技术人手里的数据，同时本身又是专家，又手握工具，所以，完全可以先把自己领域的软件工程效率提升好。”相反如果只是等待外部条件成熟，抱怨与业务的不闭环，但又不去研究自己闭环的数据。这就等同于在江边徒劳张望——临渊羡鱼，不如退而结网。
六、这轮 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 也会帮你提升。一切都在不停变化，而这是唯一的适应和学习方式。
七、写在最后
谈话中，雁杨辟谣了一个说法，他说很多人设想 AI 能够马上改变什么，紧接着码农都不需要了。这是无稽之谈，最后一定是需要的。但不一样的是，我们确实可以通过 AI 让整个软件工程的效率得到巨大的提升。
站在全局去细微观察，雁杨发现，AI 其实是一面镜子。
想要 AI 产生魔法效应，就得一步一步找到问题和解法：从引入 AI 工具，到代码采用率，再到度量思考，紧接着用“全栈”攻破代码采用率不能解决的效率问题，但又遇上“半全栈”都很难实现的难题，最后尝试一刀切的“产品设计前端”与“架构后端”两节... ...AI 像一面镜子，在帮我们发现问题，AI 又辅助我们解决问题。截至目前，阿里云 CIO 团队借此已经实现非常大的效率提升。
从中看得出，任何新事物来了，用行动和热情与其相处，焦虑就随之消退。
透过雁杨的表达，他想告诉更多人，无论开发者、程序员、未来的 AI 工程师，还是 AI 当下的芸芸：既然我们认定，技术变革是不可逆的，那就做更理解这场变革的人，朝着 AI 对行业变革的趋势线方向，在势能爆发之前，率先启程，成为趋势的一部分。
