从实现需求到共创价值：AI Native时代需要什么样的工程师团队？

1024程序员节当天，小红书技术副总裁风笛受邀出席中国计算机学会举办的CCF中国工程师文化日（简称CED）五周年盛典，在大会上系统阐述了技术组织建设的核心转型方向。当天包括CCF秘书长唐卫清、百度首席技术官王海峰、蚂蚁集团平台技术事业群副总裁周俊、并行科技董事长陈健等行业领袖，从技术创新、行业生态、社会责任等维度，深度解读了工程师文化宣言在AI时代的五维进化。

风笛的分享主要围绕AI Native时代技术团队如何重构协作模式，推动工程师角色从传统执行者向价值创造者转变展开，回答了谁挤占了工程师写代码的时间、AI编程的能力边界、AI时代技术团队的新的组织和协作模式等问题。

以下根据风笛演讲整理：

从上一次参加活动到现在，已经是第五届了。相比几年前，最大的变量就是AI。今天要跟大家分享的是：如何能够把AI新时代的工程师更好地组织起来。

这张图反映的正是工程师的卷积问题。传统开发模式中，工程师冲在生产交付最前面，但整个交付流程要兼顾速度和质量，就得频繁直接对生产环节做沟通协调。这导致工程师的受累：会议占满白天，真正能沉下心写作代码的时间，反而被挤压到了夜晚。我们调研过一些反馈，工程师表示自己写代码最快乐的时间，就是夜晚无人打扰的时候。

那么，工程师的时间都去哪儿了？很多刚从学校毕业的同学，会觉得工程师的时间安排像下图所示。从研发组织和公司的视角来看，整个工程师团队的实际生产力遵循这个公式：劳动效率 x 有效的劳动时间(在研发排期里常被称为PD日，即有效工作时间) x 需求命中率。

然而，实际情况是：大部分工程师的编码时间只占到1/3，其余都在对齐、解释、救火和应付流程。在像双11大促等不确定性更高的项目中，被更高占比的沟通协作时间所挤压的编码时间甚至降到1/4及以下。对比两张表格，我们可以看到差距之大。

数据来自一线公司团队的访谈调研，存在部分metric度量数据作为支撑。

这种现实情况不仅存在于互联网研发团队，甚至存在于一些硬件公司、软硬结合的公司。在此环境下，工程师的综合能力发展持续受到伤害。具体呈现出几个问题：

• 技术成长断层：工程师在工作3–5年后受晋升影响，逐渐远离代码生产，写代码的手感生了，倒是沟通技巧练得更溜了

• 创新能力下降：没有时间做“非业务驱动的技术性探索”

• 工程质量难提升：短期上线优先→ 测试不足 → Bug 多 → 修复时间反噬开发时间

• 心理疲惫 / 职业倦怠：工程师从“创造者”变成“需求翻译机”，长期消耗创造力

理想与现实为何总是存在差距？核心源于以下几方面：

• 业务强需求驱动下，以业务为中心而非技术，需求频繁变动，研发仅被当作 “实现工具”

• 项目节奏高压，需求压缩开发时间，工程师陷入救火式开发，既没时间思考重构，还得耗费精力修复 “赶工产物”

• 无法避免的层级化管理，管理者实际在“管理情绪”，安抚工程师使其花更多时间把事情做好

• 技术债积累，阻碍系统迭代，团队质量下降、人员溃散，在“架构孵化和对抗架构腐化”中不断循环

• 效率工具投入不足，在数以千万行代码的大型代码库中，高效探索开发变得非常困难

下图是大家比较熟悉的敏捷开发示意图。现在有一种新兴方式叫AI编程、甲板编程。这种编程方式和传统的编程方式对比有一个很大的区别：快。 快到一个人能够成为全栈多面手，涉及前端、客户端、服务端甚至算法。

但有趣的问题是：待你最后交付，会发现"车"上长出一堆莫名其妙的东西。目前这类快速开发方式通常不会告诉你，大家都是在做demo、做快速原型，反正能跑就行。然而现实情况里，没有人会拿一个demo直接上线。

当我们讨论AI编程时，一般可以分成以下三类：

• 来自“未使用者”的分享：他们没用过AI编程工具，主要信息来源是投资人的文稿和公众号的焦虑营销

• 来自效率工具的研发团队：他们制造“锤子”，肯定只讲工具能解决什么问题。看完后你会觉得世界似乎更美好了

• 来自实际应用者的分享：他们实际使用了工具，能够告诉你功能的边界，“谁用谁知道”

  下图是我们对于AI Coding的能力评估，红绿黄代表我们在实践中的评估结果。这个评估会随着使用深入而变化，特别是当企业代码库接入、做了后训练之后，表现会截然不同。

基于我们对当下AI编程能做与不能做的认知，团队的组织和协作方式正在发生变化。

过去的协作方式是串行的：从产品、技术负责人、模块负责人，再到开发、测试、运营、上线，类似施工工序的层层转包。其中最关键的环节是技术负责人到模块负责人的任务分解。技术本身的实践和生产不是大问题，但沟通是瓶颈、流程是核心。很多公司的研发流程里做了大量这样的环节。

新范式下情况则完全不同。Agent coding可以产生很多自动化能力，可以成为一种协调者。在这个过程中，一个工程师能够调用指挥大量agent。需要强调的是，不要把agent理解成“搞定一切”的银弹，也不要指望一个agent就能代替你上班，也许未来有可能，但现在还是不现实的。

这会导致过去研发团队中关键节点上owner或leader的主要工作，变成解决人与人之间的协调、需求之间的冲突，以及弥补信息差。

乔布斯曾经说过：

所以在新范式下，组织将面临三大核心转变：

• 从层级制向网络化、任务制转变：AI协作成为中间层，技术力量随之转变自己的定位

• 从授权到专精：未来越来越多的技术leader会在自己非常熟悉、知道怎么做的事情上花更多时间。正如乔布斯所说，优秀的leader应该是知道怎么做，而不是主要做任务分解然后安排流程。

• 从职能型组织到流式组织：以任务组为最小协作单元，AI能力贯穿在整个生产过程中

团队会变得更小，呈现出“小团队”、“高算力”、“扁平化”的特点——由6-8人类似特种兵小队的自组织小组，能够调用、驱动强大的AI能力，整个团队结构随之变得更加扁平。

我们需要建设以任务导向、去中心化的网络型组织，让工程师逐渐从需求的实现者转变为价值的共同创造者。当生产力更强后，工程师能够参与到价值创造过程，而不只是实现需求。

和大家分享一个小红书的实战案例。2025年初，我们在48小时内全球上线翻译功能。决策阶段，我们花了一个小时决定要做这个功能；上线阶段，采用新的协作方式，整个工期连起来只用了48小时；最终将如此复杂的功能在极短时间内交付给全球用户。这个例子充分展示了新协作模式的威力。

在未来，AI 会越发强大，但它并不会取代研发工程师，而是会把对工程师的要求提升到一个新的水位。未来不再需要大量的、处于初级水平的“代码翻译员”，需要的是能够把人的创造力在过程中充分发挥出来，把AI作为协作者，能够定义系统、治理复杂性、确保可靠性的工程师。