文章核心观点 AI技术革命正在深刻改变软件工程和研发模式 传统的以代码量、技术贡献率等指标衡量程序员价值的方式已不合时宜 行业需要重新思考效率度量、团队协作模式和个人能力发展 拥抱AI并主动变革的组织和个人将获得竞争优势 而焦虑源于对变革的不适应 真正的价值在于构建符合时代需求的能力[1][5][6][7] AI时代的技术人焦虑与价值 - 技术人的焦虑主要源于对自身能否适应AI时代的不确定性 而非AI技术本身[5][6] - 善于使用AI的个人和组织 未来将击败不善于使用的[6] - 个人价值源于符合时代的能力 这是真正的“地心引力” 价格终将向价值回归[7] - 主动站在变革潮头的团队虽然辛苦 但会自然而然地摆脱焦虑[6] 研发效能的重新定义与度量 - 程序员80%的时间用于沟通 仅10%到20%的时间用于编程 因此单纯提升编码效率对整体效能影响有限[10] - 企业最核心的研发人员 每年编写的核心代码可能不足100行 但每行都价值巨大 影响着数十亿甚至数百亿的业务[11] - 评判绩效不能单看代码行数 一行前端代码的价值可能仅为一行核心代码的1/1000[10] - AI生成的代码目前多为基础的“脚手架代码” 复杂业务逻辑和系统集成仍需人脑完成[10] - 度量效能应使用真实的“人月”数据 以端到端的方式评估业务价值与资源消耗[11] - 软件开发并非线性流水线 增加人手会导致沟通成本指数级上升 无法同比缩短工期 这被称为“人月神话”[11][12] 工程师角色演进与“半全栈”现实 - “部门墙”是长期存在的协作难题 团队内沟通频率是跨团队的几十倍甚至上百倍[16] - 理想化的“全栈工程师”因门槛过高、行业岗位划分惯性等原因 在过去十年并未普及[16][17] - AI极大降低了跨领域学习新技能的门槛和挫折感 使跨职能尝试变得可行[19] - 提出“AI产品设计前端工程师”这一新角色构想 融合产品、设计和前端能力 旨在打掉部门墙、提升需求沟通准确性[20] - 完全的全栈工程师仍属稀有 更现实的路径是拆分为“产品设计前端”和“架构与后端”两节 通过API进行桥接[20][23] AI提效的推行路径：产研先行 - 在AI转型中 将产研提效置于业务提效之前 通过自闭环“打个样”[22][25] - 产研知识（如写代码）在团队内部形成闭环 具备自评和验证条件 是率先应用AI提效的理想场景[25] - 先解决自闭环的困难 积累AI使用深度和能力 再应对跨团队协作的更高难度[25] - 产研提效能带来显性效率提升和隐性价值 如更精准满足业务需求、减少返工、避免积累“技术债”[27] - 阿里云CIO团队内部推行系统化的组织激活金字塔 底层是AI通识认证 中间是产研提效 上层是业务提效[26] AI引擎的燃料：知识管理与数据提纯 - 本轮AI革命中 业务与IT部门的无缝协作是关键 核心在于获取业务部门大脑中的“知识”[29] - 如果将AI比作引擎 那么知识就是燃料[30] - 知识分为两类：结构化的知识（存在于系统、数据库）由IT部门主导；非结构化知识（如语言类）由业务部门主导[30] - 产研人员需将公司积累的结构化和非结构化数据 通过AI整理成有价值的信息 即进行“数据炼煤”[31] - 原始数据如同“粗煤” 需经过提纯去杂变成“洗选精煤” 才能供AI引擎有效使用[32] - 技术人应首先利用自身闭环的代码数据提升软件工程效率 而非等待外部条件成熟[33] AI时代的人才需求与组织变革 - 程序员需具备“左移”能力 即更多地朝产品和业务方向看齐 理解端到端的流程[36] - 扎实的基本功在任何时代都不过时[36] - 招聘时最看重两大特质：好奇心（以持续跟进日新月异的AI技术）和韧性（以应对变革中的挫折）[39] - 企业通过“书同文、车同轨”的AI通识教育（如阿里云大模型认证）拉齐全员认知 减少变革摩擦力[39] - 公司规模近150人 其中120多人第一时间获得了阿里云大模型认证 正在寻求进一步变革[40] - 变革主导者需深刻认知变革必要性 通识教育是减少沟通摩擦的必要条件 然后以好奇心和韧性应对后续挑战[40] AI的宏观影响与行动指南 - AI不会立即导致程序员失业 但会极大提升整个软件工程的效率[41] - AI像一面镜子 既能帮助发现问题 又能辅助解决问题[42] - 阿里云CIO团队通过上述方法已实现非常大的效率提升[42] - 应对不可逆的技术变革 应主动理解趋势 在势能爆发前率先启程 成为趋势的一部分[43]