夜雨聆风
AI编程时代软件产业变革与跨学科人才的胜出
一个开发团队的 Vibe Coding 实战与反思
一、我们是谁：一个 50 人的小团队
我们是一家拥有大约 50 位工程师的小团队，业务集中在管理软件和行业支付两个方向。团队下分为五个组：
·云端组：使用 Golang、C#、React；
·客户端组：使用 Swift 和 Kotlin；
·测试组：基本以手工测试为主；
·产品组：包括产品经理和 UI 设计；
·AI 组：由 AI 方向的硕士毕业生组成，负责 CV、NLP、Voice、LLM 等模型训练和应用。
团队的工作风格是“轻管理、重工程”：没有纯粹的管理人员，部门经理或者 Team Lead 也是干活最多的人，更像是一个团队的师父。团队所有人都要动手做具体的工作。
“我们没有专门”管人”的人——这就为后来全面拥抱 Vibe Coding 留下了一种工程师文化的土壤。”
二、从“自己造”到”全面用”：我们为什么下定决心
2025 年 10 月，我们开始接触 Claude Code。2025 年年底，我们做出了一个对小团队来说很大的决定：全面转向 Vibe Coding。
截至 2026 年 5 月，团队中 33 人使用 Claude Code 开发，其他人还在用 Copilot 这类辅助编程工具。每月 Token约 15 亿 Claude Token—— 但与生产率提升相比，收获非常显著。
一次被打消的“自研”念头
2025 年 8 月，我们曾认真考虑过基于大模型自己做一款 Agent 编程工具和部署工具。当时的设计思路，是用辅助开发的方式把”需求 — 开发 — 测试”几个环节串起来；预计的难点，是开发中各种工具和接口的调用。
真正打消我们自研念头的，是 2025 年年底深度使用 Claude Code 的体验：
“我们做不出来。”
Claude Code 跟 Chat 里直接生成代码片段、跟 IDE 里 Copilot 的辅助编程，完全是两代产品。即便对比 Cursor 和 Codex，Claude Code 也有显著领先。
深入研究之后才发现：代码检索、语义理解、计划与执行、控制与授权……每一环都是难题。我们当初是把问题想简单了。
三、真实的生产力：数据与体感
外部数据
从 Anthropic 公司的统计来看，2026 年第二季度的效率是 2024 年的 8 倍；当然，不同业务、不同团队、不同熟练度，提升幅度差异很大。在我们自己的经验里：
·效率提升高：一般的 Web 应用、移动 App 开发；
·效率提升偏低：涉及 AI 模型、RAG 检索、Prompt 工程等。
一些公开的可信实验也佐证了类似的结论：高级工程师获得的生产力收益接近 junior 的 5 倍；高强度 AI 用户在高使用周的工作产出可达非用户的 4 至 10 倍；Forbes 报道甚至给出过”高强度用户 AI 代码产出是其他人 46 倍”的数字。
在与一些大厂同行私下交流中我们也了解到，大厂里普遍已经不再手写代码，Claude Code 是最流行的 Vibe Coding 工具，多数大厂都使用了定制版 CLI。但 AI 产生的代码依然需要工程师 Review，对工程师的要求是每天 Review 大约 3000-8000 行代码。
我们自己的几个项目
让数字落到我们自己身上，下面是同期几个项目用 Claude Code 的实际产出对比。”预测人月”是按过去手写代码的方式估算的工作量，”生产率提高”是相对于这个基线的倍数。
|
项目 |
代码行 |
功能点 |
表数 |
预测人月 |
Claude Code 开发人数 |
Claude Code 开发时间 |
生产率 提高 |
|
Connect |
115,000 |
2,000 |
41 |
133 人月 |
2 |
3 月 |
25 倍 |
|
Studio |
179,818 |
3,150 |
72 |
210 人月 |
1 |
3 月 |
70 倍 |
|
Test |
48,800 |
575 |
14 |
62 人月 |
1 |
0.5 月 |
124 倍 |
表 1：我们 3 个项目使用 Claude Code 的实际生产率提升
需要说明的是：这些数字看起来“夸张”，但它衡量的是全新的应用类型项目、且规模适中、需求清晰，并无太多研究环节例如模型训练、算法调试造成断点。
我们自己的体感：断崖式长尾收尾效应
数据是漂亮的，但工程师每天真实的感受其实更复杂。在我们的项目里，Vibe Coding 的效率呈现出一个非常独特的曲线，我把它称为——
“断崖式长尾收尾效应。”
前期的需求阶段、第一版代码阶段，效率高得令人吃惊：几小时到几天就能拿到一个可运行的系统。但当进入“微调优化、用户体验打磨”的阶段，与前期相比，几乎是踩进了泥潭。
图 1：断崖式长尾收尾效应——前期高效带来”进度幻觉”，后期长尾才是真功夫
这种“前期高效”非常容易制造一种进度幻觉：以为项目就快完成了，但其实最难啃的那块骨头还在后面。
不过，我并不想为此苛责 Vibe Coding。这种后期的”低效”，很大程度上来自前期需求不准确、后期变更、以及人类用户体验诉求的涌现——这本来就是软件最难的部分，AI 没让它变难，只是把”容易的部分”突然变得太容易了，凸显了原本就难的那部分。
四、Harness 与”多模态”的 Claude Code
Harness 比想象中重要
Vibe Coding 在今天，已经可以服务无技术经验的用户：用自然语言提模糊需求，经过逐步澄清，就能生成准确的软件代码。
但 Harness 真的很重要。Claude 文件、各种 Skill、对 Session Context 的控制等等，都会显著影响 Vibe Coding 的效果。为此我们做了两件事：
1. 开发了全套的 Agent / Command / Skill；
2. 开发了基于 Web 的 Studio，接入 Bedrock 的 Claude Code，统一团队的 Harness，便于控制风险、集中管理。
Claude Code 的”多模态”使用
Claude Code 的应用领域不止编程。我们还围绕它开发了：日志实时分析、自动化测试平台、AI 任务监控、自动部署……目标是软件全生命周期的”基于 AI 的全自动”。
这个思路其实是被一次故障逼出来的。
2026 年 2 月，我们一个新上线的支付系统在夜间发生故障。系统维护和开发同事都紧急投入排查。经过两个小时，发现问题与云的 Serverless 环境版本更新有关，但具体原因仍不清楚。这时，负责研究 Claude Code 的同事灵光一现，让 Claude Code 读所有云服务的系统日志——大约 10 分钟，问题被定位了；几乎在同一时刻，维护同事用传统方法也定位到了同一处。
“大模型是多模态的，Claude Code 的用法也是”多模态”的——它不止是编程工具，需要使用者自己去发现。”
第二天，我们就开始基于 Claude Code 开发日志监控系统。
五、最难的不是技术，是人
过去两年，我们公司一直在用 Copilot。虽然没有具体数据统计，但直观感受是开发效率确实提升了。Copilot 的推广很简单：开通账户，IDE 里用起来，没人反对。
但 Claude Code 不一样。它改变了程序员的工作模式：第一，不再用 IDE；第二，用对话的方式下达任务。我们能明显感觉到，一部分程序员是有抵触情绪的。
我们对此有几个猜测：脱离 IDE 后，程序员”不再看代码”，会产生一种失控感；对话模式本身可能也不适应。为此我们做了一次匿名调研，结果让人深思——
调研里的一些数字
·在 Copilot 辅助编程 vs Claude Code 自动化编程的比较上，16% 的人认为 Copilot 更好；33% 的人认为两类工具适用于不同场景；14% 的人不确定；仅 37% 的人明确认定 Claude Code 优于 Copilot。
·对于是否接受 Claude Code 的工作方式，2% 的人不接受，21% 的人认为不适用于核心代码。
·对于未来软件开发的工作方式，只有 16% 的人认为，将来不再区分岗位的技术方向、也不再区分开发环节——但这恰恰是我们认为大概率会发生的未来。
·只有 16% 的人认为 Claude Code 给自己带来了岗位安全感——这其实是大家不愿意承认自己的危机感。
我们的推广策略：邀请制 + 老项目 Review
我们没有强制推广，担心给已有项目带来不稳定，也不想生硬施压。我们采用的是内部邀请制：
1. 从平日热爱新技术的同事开始，逐步纳入 Studio；
2. 每一位新增用户，都从一个”新功能或新产品”开始，全过程体验一个小工程的 Vibe Coding；
3. 老项目则从代码 Review、Bug 修改入手，更稳妥；
4. 对支付中的已有核心代码（如支付网关），Studio 只做 Review，修改仍在 IDE 完成。
这样花了 3 个月，70% 的同事能够每天使用 Studio，使用程度有别。但我们依然面临几个挑战：
1. 如何说服全体同事都顺利使用 Studio；
2. 如何把”分环节、分技术工种”的作业模式，改为”全环节、全工种”模式——其中最大的挑战，是说服程序员去关注需求、关注产品。人的技能要转变，岗位的职责也要改变，这是最困难的；
3. 团队管理要随之改变，例如过去基于 JIRA 统计任务，现在可以用 AI 在 Studio 里统计工程师的对话工作量、完成的代码和功能；
4. 产品开发效率提升后，团队的其他工作（营销、客服等）要怎么跟上。
六、对未来：我们的几个预判
1. 关于职业：程序员会消失，软件工程师会留下
“程序员”——也就是”把自然语言形式的详细需求翻译成代码”的这种职业，会消失。
但软件工程师还在，只是更偏重产品规划、需求、体验。在软件工程工作中，单纯掌握语言/技术的专业重要性下降，AI 替代率较高；而电子信息、信息系统、管理科学等兼顾技术和需求的跨学科类专业，反而更适合在 Vibe Coding 模式下工作。
这意味着两件事，而且这两件事已经在我们团队转型中真实显现。
第一，单纯的技术专业重要性会快速下降。把宝押在“精通某门语言或框架”上的同学，会发现这套经验在 Vibe Coding 时代很快折旧——AI 已经能做得很好。具体的语言、框架、平台知识，原本是软件工程师的核心资产，现在反而变成了最先被替代的部分。
第二，跨学科背景反而成为优势。信息系统、管理科学、电子信息这类专业，本来就是“跨界”训练——同时懂技术、懂业务、懂流程、懂沟通，视野全面。Vibe Coding 恰好取消了”分工种分环节”，需要一个人独立完成需求、设计、开发、测试、运维全过程，跨学科背景天然适配这种新模式。
把这两件事放到团队转型的现场来看，会更直观——
·产品经理是赢家。原本就在做需求澄清、用户体验、跨部门协调，这些恰好是 Vibe Coding 时代的核心能力。他们只需要补一点 AI 工具操作，就直接成为新工作流的主力——几乎是”优势放大”。
·程序员则吃亏更多。过去最值钱的“具体语言 / 框架经验”被 AI 替代，必须从零开始学需求分析、产品思维、用户体验。转型周期长，损失的经验也最多。换句话说，他们要重新做”产品入门生”——这不仅是技能切换，更是身份切换，痛苦也最大。
“结论很冷：在 Vibe Coding 时代，纯技术经验是负债，跨学科视野是资产。”
2. 关于软件：即用即抛，生产与消费并轨
当前，软件的“生产”和”消费”是隔离的：一边是开发团队，一边是用户。
在 Vibe Coding 支持下，软件的生产将实现即时化——用户需要的时候，随时生产。生产率不再是关键瓶颈，软件可能变得”即用即抛”。
3. 关于岗位：技术方向消亡，环节边界消失
软件开发首先不再为“技术方向”设立岗位——”Golang 工程师”、”Java 工程师”这样的区分将不再有意义。
开发过程也不再区分需求分析师、开发、测试、维护这些职位。软件工程师个人承担全部环节。
4. 关于能力：一种”行政升职型”的 M 跃迁
软件工程师的技能要求和职责，将呈现一种我们称之为“行政升职型”的 M 跃迁。
所谓“行政升职”，指的是从程序员升迁到产品经理 / 项目经理，再从产品经理 / 项目经理升迁到部门经理这样的路径——它有别于 P 级别（专业能力）的跃迁。
在 Vibe Coding 模式下，软件和互联网企业的 P 级别仍然存在，但以学术和研究人才为主。在软件工程领域，随着 Vibe Coding 越来越强大：
·程序员必须蜕变为产品经理，负责整个产品的全部环节；
·如果 Vibe Coding 进一步强大，产品经理则进一步蜕变为部门经理。
图 2：”行政升职型”的 M 跃迁——P 级专业路径被压缩，工程师被推上 M 行政路径
每一步蜕变，软件工程师对技术细节的控制都会更少，但要管理、要掌握的方方面面会更多——岗位价值的核心，从”做出来”，变成了”扛得住”。
七、“2 米高台阶”：这一次，工具的智能可能高于它替代的人
人类的职业能力，仿佛一场漫长的登山。从最初的石器打猎，到机械化、电气化、信息化，再到今天的 AI 化——每一次工具升级，都是垫在人类脚下的台阶，让人们从低级劳动迈向更高级的劳动。
体力劳动不必多说；脑力劳动过去也有计算师、翻译这类职业，逐渐被替代。但每一次替代，都会有更多、更高级的职位让被替代的人承接——其本质是：这些工具的智能，并不高于它所替代的人。
唯有这一次大模型出现的升级，情况不同。
“这次的台阶是”2 米高台阶”——它太高了，超过很多人的身高，大家攀爬不上去。只有最优秀的精英才能迈上，站到更高的平台上。”
图 3：”2 米高台阶”——过去工具的台阶不高于人的身高，AI 这一阶却让大部分人够不到
维纳说，人有人的用处。人是一路适应环境进化而来的——即便人没有台阶 2 米那么高，也会在摸索中适应环境，找到自己的新定位。而 AI 无论多高，归根结底也是为了服务于人。今天 Vibe Coding 很强大，但 Harness 需要人来设计；做出的软件和系统，也是为了服务人。人是中心，这一点依然没变。
八、争议、立场与一点信念
对于 Vibe Coding，业内的争议依然很多。负面观点大致分两类：
一类认为“大模型产生的代码都是垃圾”。这类观点的典型代表是 Linus Torvalds——作为 Linux 的发明人和掌门人，他对 AI 编程一直持负面态度。从 2024 年到 2026 年，他在 6 次公开采访中不同程度、不同角度地批评 AI 编程。但仔细看，他这两年的态度其实发生了巨大转变：
·2024 年：「AI 90% 是营销噱头」；
·2026 年：「AI 像编译器一样提高生产率，但程序员还是必须理解代码」。
另一类认为“Vibe Coding 耗费的 Token 价值已经超过人工成本”，这类观点多见于缺乏数据支持和深入分析的新闻报道，例如：微软撤销部分 Claude Code 内部许可证、Uber 提前耗尽年度 AI coding 预算、Mercor 宣称 token 支出超过员工薪资等。
而我们的立场，基于真实的实战经验，是这样的：
“Vibe Coding 已经是成熟的生产方式。我们看不到退回手写代码和 AI 辅助编程的可能性。”
我们选择相信，这是一次远超过互联网的技术革命。我们准备好迎接软件行业全面的变革——这种变革会发生在生产率与成本、软件的生产与消费方式、人才的能力与职责、团队的组织模式等方方面面。
在如此颠覆性的产业革命面前，每个从业者个人的命运、每家企业的命运，都会随之剧烈起伏。但软件从业者应该相信：
“这是前进的方向。不论在这个过程中，我们个人和团队失去了什么，获得的都是整个世界——一个全新的世界。”
· · ·
—— 写在团队全面转向 Vibe Coding 的第 6 个月
