1024 程序员节当天，小红书技术副总裁风笛受邀出席中国计算机学会举办的 CCF 中国工程师文化日（简称 CED）五周年盛典，在大会上系统阐述了技术组织建设的核心转型方向。当天包括 CCF 秘书长唐卫清、百度首席技术官王海峰、蚂蚁集团平台技术事业群副总裁周俊、并行科技董事长陈健等行业领袖，从技术创新、行业生态、社会责任等维度， 解读了工程师文化宣言在 AI 时代的五维进化。
风笛的分享主要围绕 AI Native 时代技术团队如何重构协作模式，推动工程师角色从传统执行者向价值创造者转变展开，回答了谁挤占了工程师写代码的时间、AI 编程的能力边界、AI 时代技术团队的新的组织和协作模式等问题。
以下根据王晓博演讲整理：
从上一次参加活动到现在，已经是第五届了。相比几年前，最大的变量就是 AI。今天要跟大家分享的是：如何能够把 AI 新时代的工程师更好地组织起来。
谁挤占了工程师的编码时间？
这张图反映的正是工程师的卷积问题。传统开发模式中，工程师冲在生产交付最前面，但整个交付流程要兼顾速度和质量，就得频繁直接对生产环节做沟通协调。这导致工程师的受累：会议占满白天，真正能沉下心写作代码的时间，反而被挤压到了夜晚。我们调研过一些反馈，工程师表示自己写代码最快乐的时间，就是夜晚无人打扰的时候。我们曾统计过公司提交代码的峰值时段：小高峰是零点前后到凌晨一点，最高峰是晚上十点钟。可以看到，工程师确实是非常辛苦的行业。
那么，工程师的时间都去哪儿了？很多刚从学校毕业的同学，会觉得工程师的时间安排像下图所示。从研发组织和公司的视角来看，整个工程师团队的实际生产力遵循这个公式：劳动效率 x 有效的劳动时间 (在研发排期里常被称为 PD 日，即有效工作时间) x 需求命中率。
然而，实际情况是：大部分工程师的编码时间只占到 1/3，其余都在对齐、解释、救火和应付流程。在像双 11 大促等不确定性更高的项目中，被更高占比的沟通协作时间所挤压的编码时间甚至降到 1/4 及以下。对比两张表格，我们可以看到差距之大。
数据来自一线公司团队的访谈调研，存在部分 metric 度量数据作为支撑。
这种现实情况不仅存在于互联网研发团队，甚至存在于一些硬件公司、软硬结合的公司。在此环境下，工程师的综合能力发展持续受到伤害。具体呈现出几个问题：
技术成长断层：工程师在工作 3–5 年后受晋升影响，逐渐远离代码生产，写代码的手感生了，倒是沟通技巧练得更溜了
创新能力下降：没有时间做「非业务驱动的技术性探索」
工程质量难提升：短期上线优先→ 测试不足 → Bug 多 → 修复时间反噬开发时间
心理疲惫 / 职业倦怠：工程师从「创造者」变成「需求翻译机」，长期消耗创造力
理想与现实为何总是存在差距？核心源于以下几方面：
业务强需求驱动下，以业务为中心而非技术，需求频繁变动，研发仅被当作 「实现工具」；
项目节奏高压，需求压缩开发时间，工程师陷入救火式开发，既没时间思考重构，还得耗费精力修复 「赶工产物」；
无法避免的层级化管理，管理者实际在「管理情绪」，安抚工程师使其花更多时间把事情做好
技术债积累，阻碍系统迭代，团队质量下降、人员溃散，在「架构孵化和对抗架构腐化「中不断循环；
效率工具投入不足，在数以千万行代码的大型代码库中，高效探索开发变得非常困难。
全栈多面手？理性识别 AI Coding 的能力边界
下图是大家比较熟悉的敏捷开发示意图。现在有一种新兴方式叫 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 作为协作者，能够定义系统、治理复杂性、确保可靠性的工程师。
