打开网易新闻 查看精彩图片

一个谷歌工程师用周末搞了个 side project,从想法到上线只用了 6 小时。同一周,他在公司推进的功能卡在第三个跨团队对齐会上,进度条还没走到 10%。

这不是偷懒的故事。他在内部文档里算了笔账:AI 让写代码速度快了 5 倍,但"等人"的时间一点没减。5 倍乘以 0,结果还是 0。

周末的幻觉:一个人就是一支军队

「早上想了个功能,午饭前就跑起来了。」

这是谷歌产品经理 Aidan Clark 的描述。上周末他又在"vibe coding"——一个最近硅谷很火的词,大意是让 AI 当你的结对编程伙伴,你负责提需求,AI 负责生成代码,节奏跟着"感觉"走。

在这种模式下,他一个人扮演了四个角色:产品经理画需求、设计师调界面、前端写交互、后端搭服务。没有晨会,没有评审,没有"我开个 ticket 你排一下期"。

Clark 承认这有作弊成分:新项目没有历史包袱,不用服务 99.9% 的可用性承诺,用户量也是零。但问题在于——这种"作弊感"的落差,正在变成日常工作的讽刺。

周一回到办公室,他看自己的团队路线图,看到的是"重型"史诗任务(Epic):需要前端专家、后端专家、移动端专家、集中式 PM 层,像接力赛一样传递需求。一个核心功能要串起四五个团队,每个交接点都是潜在的减速带。

AI 把编码时间从 10 分钟压到 2 分钟,但等另一个团队改 API 接口,还是要等两周。

同步税:被忽略的成本黑洞

同步税:被忽略的成本黑洞

Clark 给这个现象起了个名字:同步税(Synchronization Tax)

企业给工程师配了 AI 工具,代码生成速度确实快了,但生产速度没变。一个后端变更 10 分钟写完,接着要等两周让别的团队排期改接口,再开三场会对齐 JSON 字段的命名规范。5 倍的编码提速,被无限长的等待时间稀释成零。

「我们不再是代码生成的瓶颈,人类沟通和技术孤岛才是。」

这句话的潜台词很扎心:公司花大价钱买的 AI 许可证,省下来的时间全填进了会议和邮件。ROI 算起来好看,实际体感像在用跑车拉煤。

更隐蔽的伤害是人才流失。Clark 观察到,工程师在这种结构里会陷入"虚假忙碌"——键盘敲得飞快,成就感却越来越低。周末的 side project 之所以上瘾,是因为它还原了创造的原始快感:想法→实现→验证,闭环在几小时内完成。

而企业里的闭环,经常以季度为单位。

两人史诗:一个激进的实验提案

两人史诗:一个激进的实验提案

Clark 的解决方案听起来像组织架构的"极简主义":2-Person Epic 模型

核心配置只有两个人。一个产品经理, owning "做什么"和"为什么",定义业务价值和用户旅程。一个全栈工程师, owning "怎么做"和落地执行,从 UI 到核心后端服务一竿子捅到底。

工程师的武器库包括 AI 助手和标准化的"Paved Roads"(铺好的路)——公司内部预置的基础设施模板、组件库、部署流水线。目标不是让工程师更累,而是让他们不用再把 ticket "扔过墙"等别人接。

这个模型有个前提:AI 已经把"全栈"的门槛拉低到可接受范围。以前一个人hold住前后端+移动端是神话,现在 Claude、Cursor、Copilot 可以承担大部分 boilerplate 工作,工程师的角色变成导演而非主演。

但 Clark 也留了退路。他在文档里明确说:「我知道标准反驳是什么——我在从零开始,没有遗留代码要解耦,没有几千个付费用户要伺候。」

这些反驳成立。只是他追问了一句:这个"不成立"的有效期还有多久?

时间表:谁在为"还没准备好"买单

时间表:谁在为"还没准备好"买单

Clark 的担忧指向一个更深层的问题:企业总是在等"成熟"的那一刻。

等 AI 代码质量再稳一点,等全栈能力被验证,等组织架构调整的风险可控。但技术扩散不等人。周末的 side project 不会消失,只会越来越多——而做过 6 小时闭环的人,很难再回到 6 周等一个接口的生活。

「如果我们现在不开始建通往未来的桥,就会被自己当作'生产力工具'的 AI 甩在后面。」

这句话的悖论在于:AI 既是问题的一部分,也是解决方案的一部分。它放大了旧结构的低效,也提供了绕过旧结构的可能。企业可以选择加固城墙,也可以选择开一扇侧门。

Clark 的 2-Person Epic 是一扇侧门。它不适合所有场景——金融级的合规系统、需要物理硬件联调的项目、涉及 20+ 第三方集成的企业套件,这些可能永远需要重型团队。但对于大量"在现有产品里加功能"的场景,两个人+AI 的实验成本,可能低于维持五个专职 headcount 的年度预算。

谷歌内部是否有人响应这个提案,Clark 没有透露。但他公开这份文档本身,就是一种组织行为学的样本:在大厂提"减少协作"的建议,需要一点周末 side project 积攒的勇气。

最后一个细节。Clark 在文档结尾附了张周末项目的截图:一个简陋但完整的仪表盘,数据源、可视化、分享链接俱全。配文是发布时间——周六上午 11:47。

同一时刻,他的工作邮箱里躺着三封未回复的会议邀请,主题分别是"Q3 对齐""技术方案评审""跨团队依赖梳理"。