1024程序员节当天，小红书技术副总裁风笛受邀出席中国计算机学会举办的CCF中国工程师文化日（简称CED）五周年盛典，在大会上系统阐述了技术组织建设的核心转型方向。当天包括CCF秘书长唐卫清、百度首席技术官王海峰、蚂蚁集团平台技术事业群副总裁周俊、并行科技董事长陈健等行业领袖，从技术创新、行业生态、社会责任等维度，深度解读了工程师文化宣言在AI时代的五维进化。
风笛的分享主要围绕AINative时代技术团队如何重构协作模式，推动工程师角色从传统执行者向价值创造者转变展开，回答了谁挤占了工程师写代码的时间、AI编程的能力边界、AI时代技术团队的新的组织和协作模式等问题。
以下根据王晓博演讲整理:
从上一次参加活动到现在，已经是第五届了。相比几年前，最大的变量就是AI。今天要跟大家分享的是:如何能够把AI新时代的工程师更好地组织起来。
谁挤占了工程师的编码时间?
这张图反映的正是工程师的卷积问题。传统开发模式中，工程师冲在生产交付最前面，但整个交付流程要兼顾速度和质量，就得频繁直接对生产环节做沟通协调。这导致工程师的受累:会议占满白天，真正能沉下心写作代码的时间，反而被挤压到了夜晚。我们调研过一些反馈，工程师表示自己写代码最快乐的时间，就是夜晚无人打扰的时候。我们曾统计过公司提交代码的峰值时段:小高峰是零点前后到凌晨一点，最高峰是晚上十点钟。可以看到，工程师确实是非常辛苦的行业。
那么，工程师的时间都去哪儿了?很多刚从学校毕业的同学，会觉得工程师的时间安排像下图所示。从研发组织和公司的视角来看，整个工程师团队的实际生产力遵循这个公式:劳动效率x有效的劳动时间（在研发排期里常被称为PD日，即有效工作时间）x需求命中率。
然而，实际情况是:大部分工程师的编码时间只占到1/3，其余都在对齐、解释、救火和应付流程。在像双11大促等不确定性更高的项目中，被更高占比的沟通协作时间所挤压的编码时间甚至降到1/4及以下。对比两张表格，我们可以看到差距之大。
数据来自一线公司团队的访谈调研，存在部分metric度量数据作为支撑。
这种现实情况不仅存在于互联网研发团队，甚至存在于一些硬件公司、软硬结合的公司。在此环境下，工程师的综合能力发展持续受到伤害。具体呈现出几个问题:
技术成长断层:工程师在工作3–5年后受晋升影响，逐渐远离代码生产，写代码的手感生了，倒是沟通技巧练得更溜了
创新能力下降:没有时间做“非业务驱动的技术性探索”
工程质量难提升:短期上线优先→测试不足→Bug多→修复时间反噬开发时间
心理疲惫/职业倦怠:工程师从“创造者”变成“需求翻译机”，长期消耗创造力
理想与现实为何总是存在差距?核心源于以下几方面:
业务强需求驱动下，以业务为中心而非技术，需求频繁变动，研发仅被当作“实现工具”;
项目节奏高压，需求压缩开发时间，工程师陷入救火式开发，既没时间思考重构，还得耗费精力修复“赶工产物”;
无法避免的层级化管理，管理者实际在“管理情绪”，安抚工程师使其花更多时间把事情做好
技术债积累，阻碍系统迭代，团队质量下降、人员溃散，在“架构孵化和对抗架构腐化“中不断循环;
效率工具投入不足，在数以千万行代码的大型代码库中，高效探索开发变得非常困难。
全栈多面手?理性识别AICoding的能力边界
下图是大家比较熟悉的敏捷开发示意图。现在有一种新兴方式叫AI编程、甲板编程。这种编程方式和传统的编程方式对比有一个很大的区别:快。快到一个人能够成为全栈多面手，涉及前端、客户端、服务端甚至算法。
但有趣的问题是:待你最后交付，会发现"车"上长出一堆莫名其妙的东西。目前这类快速开发方式通常不会告诉你，大家都是在做demo、做快速原型，反正能跑就行。然而现实情况里，没有人会拿一个demo直接上线。
当我们讨论AI编程时，一般可以分成以下三类:
来自"未使用者"的分享:他们没用过AI编程工具，主要信息来源是投资人的文稿和公众号的焦虑营销;
来自效率工具的研发团队:他们制造“锤子”，肯定只讲工具能解决什么问题。看完后你会觉得世界似乎更美好了;
来自实际应用者的分享:他们实际使用了工具，能够告诉你功能的边界，“谁用谁知道”
下图是我们对于AICoding的能力评估，红绿黄代表我们在实践中的评估结果。这个评估会随着使用深入而变化，特别是当企业代码库接入、做了后训练之后，表现会截然不同。
新的协作方式与组织变革:以任务导向的去中心化网络型组织
基于我们对当下AI编程能做与不能做的认知，团队的组织和协作方式正在发生变化。
过去的协作方式是串行的:从产品、技术负责人、模块负责人，再到开发、测试、运营、上线，类似施工工序的层层转包。其中最关键的环节是技术负责人到模块负责人的任务分解。技术本身的实践和生产不是大问题，但沟通是瓶颈、流程是核心。很多公司的研发流程里做了大量这样的环节。
新范式下情况则完全不同。Agentcoding可以产生很多自动化能力，可以成为一种协调者。在这个过程中，一个工程师能够调用指挥大量agent。需要强调的是，不要把agent理解成"搞定一切"的银弹，也不要指望一个agent就能代替你上班，也许未来有可能，但现在还是不现实的。
这会导致过去研发团队中关键节点上owner或leader的主要工作，变成解决人与人之间的协调、需求之间的冲突，以及弥补信息差。
乔布斯曾经说过:“最好的管理者是伟大的贡献者，他们从来没想过要成为管理者。在苹果我们认为聘请职业经理人只会让我们成为一家大公司。这招没用，因为大部分人只会管管事，不会做其他事。
我发现最优秀的人才是那些真正理解业务核心的人。（这里的“业务核心”指的是推动业务成果的关键因素。）管理他们可能会很棘手。但正因为他们在核心业务上的卓越表现，你愿意忍受这一切。正是这种对核心业务的深刻理解造就了伟大的产品。不是流程，而是核心内容。”
所以在新范式下，组织将面临三大核心转变:
从层级制向网络化、任务制转变:AI协作成为中间层，技术力量随之转变自己的定位
从授权到专精:未来越来越多的技术leader会在自己非常熟悉、知道怎么做的事情上花更多时间。正如乔布斯所说，优秀的leader应该是知道怎么做，而不是主要做任务分解然后安排流程。
从职能型组织到流式组织:以任务组为最小协作单元，AI能力贯穿在整个生产过程中
团队会变得更小，呈现出“小团队”、“高算力”、“扁平化”的特点——由6-8人类似特种兵小队的自组织小组，能够调用、驱动强大的AI能力，整个团队结构随之变得更加扁平。
我们需要建设以任务导向、去中心化的网络型组织，让工程师逐渐从需求的实现者转变为价值的共同创造者。当生产力更强后，工程师能够参与到价值创造过程，而不只是实现需求。
和大家分享一个小红书的实战案例。2025年初，我们在48小时内全球上线翻译功能。决策阶段，我们花了一个小时决定要做这个功能;上线阶段，采用新的协作方式，整个工期连起来只用了48小时;最终将如此复杂的功能在极短时间内交付给全球用户。这个例子充分展示了新协作模式的威力。
在未来，AI会越发强大，但它并不会取代研发工程师，而是会把对工程师的要求提升到一个新的水位。未来不再需要大量的、处于初级水平的"代码翻译员"，需要的是能够把人的创造力在过程中充分发挥出来，把AI作为协作者，能够定义系统、治理复杂性、确保可靠性的工程师。
（推广）