夜雨聆风早在生成式 AI 大规模爆发之前，我就一直在操盘 AI 相关的业务。大模型浪潮真正来袭后，我又成了第一批把大模型落地到实际业务流中的产品经理。
过去这段时间，我重度体验了几乎所有头部的模型以及开发工具，亲自下场，通过 Vibe Coding 独立跑通了几个真实的业务项目并上线获得了用户。一个人单枪匹马用 AI 构思需求、写代码、排查问题，单兵作战的速度确实快得惊人。
但是，当我在组织架构内推动 AI 业务落地时，却看到了一个极其割裂的现象：公司花大价钱给产研团队配置了顶配的 AI 账号，研发写代码的速度肉眼可见地提升了，但站在业务负责人的视角看，一个中型需求从立项到上线的整体交付周期，依然没有任何明显的缩短。
微观上的个人单点提效，完全没有转化为宏观上的组织产能。
很多团队在引入大模型时，忽略了一个最基础的逻辑：软件工程是一个多角色的串行协作链路。在旧有的协作架构下，局部节点的效率突进，只会引发上下游更严重的系统性拥堵。
当开发的敲代码速度被 AI 大幅拉升后，链路的压力首先向后传导到了测试环节，导致测试迅速成为了整个流程中极其明显的阻塞点。产生这种拥堵的根本原因，绝不在于 QA 团队的技术水平，也完全无关乎他们是否愿意使用 AI 工具，其核心制约在于人类客观带宽的天然上限。
确实，对于一些简单的底层逻辑，团队完全可以通过引入 AI 的自动化 Code Review 或类似 Monkey 测试的脚本去快速完成覆盖。然而，软件产品最终是要交付给真实用户的，这注定了始终会存在大量必须依赖 QA 从真实的“用户视角”去亲身模拟、交互和验收的核心场景。
在研发效率极速狂飙的当下，这些必须耗费人工体验带宽的业务场景，同样会以极其迅猛的速度被开发人员批量产出，并在极短的时间内集中流转到 QA 团队面前。无论测试人员如何优化工具，他们有限的感官体验和主观验收精力，最终都会被这种海量的待测功能彻底击穿。
同时，压力也在向前传导给产品经理。开发写代码变快了，自然需要更多的需求输入。但产品经理出需求的速度，往往跟不上开发的速度。
这背后的原因在于，需求的源头取决于真实的业务反馈。产品经理的上游信息可能来自市场的真实反应、公司高层的战略指令、或是 AB 实验跑出来的客观数据。这些基于现实世界和用户反馈的数据获取周期，绝不会因为有了一个强大的代码辅助工具就自动缩短。获取足够充分的上游输入依然需要大量的时间和业务判断。
更有甚者，一些团队强行在旧流程里塞入 AI，反而加剧了前置的内耗。
我有一位在大厂工作的朋友，他们团队近期极其激进地推行 AI 提效，要求每个角色深度使用大模型以减少纯手工环节。管理层规定产品经理提需求必须全程面向内部的 AI 辅助系统，严禁业务和技术直接口头对齐需求细节，一切流转全部依赖系统生成。
这套做法看似向未来迈出了庞大的一步，但实际运转下来却让人大跌眼镜。因为在这个机制下，业务角色依然被挡在真实的底层代码之外。
当产品经理想要沟通一个极小的改动时，过去可能花十分钟就能把点对点的需求写得清清楚楚。但现在，为了让那个脱离了真实工程环境的 AI “理解”意图，产品经理不得不花费更多的时间去交代项目的宏大背景、当前的状态、具体修改的位置和方式，最后再等待 AI 吐出一份格式标准的需求文档。整个前后交互的过程，耗时远远超过了从前的十分钟。
尽管整个团队表面上都在深度拥抱 AI，协作效率却毫无起色。因为开发最终拿到的，依然是一份业务人员和 AI 艰难聊出来的纯文本。开发拿到这份文档后，还是需要按部就班地再做一次人工处理，把文字重新转化为系统代码。
这就带来了一个无解的局面：开发在等需求，测试在海量的代码里苦苦支撑，而产品经理为了迎合 AI 流程反而耗费了更多精力。我们在旧有的协作架构里加速某几个环节，换来的只是由于跨部门等待和多余信息翻译造成的局部拥堵。
那么，这个问题究竟有解吗？
如果产研团队依然维持传统的“产品出文档、开发敲代码、测试找缺陷”的串行分工，那这个问题基本无解。只要跨部门的转译成本还在，单点提效的天花板就会被协作成本死死压住。
想要真正实现整体提效，必须承认一个现实，AI 的核心价值绝不仅限于充当高级超快打字机，它真正颠覆的是长久以来的专业壁垒。如果不发生组织分工上的本质演进，团队的协作状态就无法获得根本性的改变。
顺着这个思路往下看，如果真的想快，团队的协作状态应该发生一些有意思的“边界模糊”。
首先是信息流转方式的演进。
过去的产研协作总是显得拖沓，根源在于人类使用自然语言表达时天然存在着理解偏差。每个人的大脑并没有直接串联，不同角色对同一句话、同一个需求甚至某项业务策略的理解，可能存在天壤之别。这种沟通鸿沟不仅发生在工作环境里，也普遍存在于日常生活中。
为了弥合这种偏差，团队习惯于用极其繁冗的文档去对齐细节。但自然语言无论写得多长，依然无法做到绝对精准。所有协作角色要想真正消除翻译内耗，最终必须对齐到一个完全标准化的载体上。在互联网项目协作的逻辑里，这个相对绝对标准的东西实际上就是底层代码。
正如我那位大厂朋友的经历，让 AI 去生成更长、更复杂的纯文本需求文档，完全没有抓住提效的重点。理想的改变，应当是跳过容易产生歧义的中间文档环节。对齐人的信息压缩到极简，只讲清业务目标和影响面；剩下的复杂历史逻辑和接口依赖，直接交由 AI 去读取代码库进行检索和理解。用标准化的代码作为唯一的上下文底座，跨部门的信息损耗才会真正降低。
其次是业务侧应该具备“透视”系统的能力（更直接点说是权限）。
过去运营想知道某个促销模块的底层排斥条件，只能去打断开发，干等结果。在当前的技术能力下，技术不应该再是一个黑盒。如果向业务适度开放代码的只读权限，产品和运营完全可以直接向 AI 提问来摸清系统限制。当业务人员在提需求之前就能“看清”系统底牌，后续落地方案的技术试错成本就会断崖式下降。这种做法丝毫没有侵占开发的职能，反而让业务方提出的需求第一次真正具备了工程可行性。
最后，微型需求可以尝试自助流转，但必须极度冷静地看待它的适用边界。
每一个产研团队都被改文案、换头图这类低复杂度需求折磨过。既然大模型可以辅助写代码，很多人理所当然地认为，完全可以让产品或运营自助完成这类微型开发，资深技术只负责最终的代码审查。
如果在一个小型的机动团队或者创业公司里，大家彼此熟悉、信任度极高，且项目的容错空间相对较大，这条路确实是可以跑通的。释放出的宝贵研发精力，也真正能够回归到高并发架构改造等核心挑战上。
然而，一旦把这种模式搬到大厂，特别是涉及到跨部门的复杂需求时，这条理想化的路径就会瞬间破灭。
根本原因在于大厂严密的考核导向。在绝大多数情况下，业务角色和技术角色的核心诉求天然存在着拉扯（甚至可以说是对立）。业务要的是极速上线，技术保的是绝对稳定没有资损。没有任何一个研发团队，会愿意把关乎自己绩效考评和系统红线的代码库，交到一个并不太熟悉的协作方手里。在大厂森严的堡垒下，指望业务方用 AI 盲写代码并无缝推进上线，几乎是一件天方夜谭的事情。
发展到现在这个阶段，无论是大厂还是中小公司，难道真的拿不出钱给大家买 AI 会员吗？其实都是有的。就算买不起两百刀每月的顶级版，给大家每个月配个二十刀的基础会员，员工就已经“Thank you so much”了。
但问题是，这笔钱花出去，积累一个月、三个月甚至一年，整体的成本并不低。怎么把这部分的技术成本，真正转化成为肉眼可见的业务价值，是目前所有人面临的一个极其严峻的问题。
当然，现在大部分团队管理层思考的层面还非常表面。很多人觉得，既然我花了这笔钱给大家配了 AI 工具，那我就要开除掉某几个员工，去把这个技术成本对冲掉，账自然就平了（甚至更低了）。但实际上真的没有这么简单。就像我们前面聊到的这些协作矛盾点，AI敲代码的速度再快，只要团队之间的信任壁垒还在、传统的串行流程还在，整体的项目交付就一定快不起来。如果不去解决协作沟通的底层矛盾，光靠简单的裁员，只会让留下来的员工在拥堵的流程里更加崩溃。
给团队配上 AI 账号，仅仅是个简单的开始。真正能把这笔订阅费花回本的团队，一定是那些敢于坐下来，重新梳理谁来提需求、谁来看代码、怎么分担责任的团队。只有直面现实，把协作的死结彻底解开，技术工具的价值才能真正落地。
