经理不提需求，代码就不能改？

你好，我是曹犟，欢迎关注我的公众号。

前两天在群里面，一个自己创业做 To B 业务的朋友吐槽：他们之前和一家兄弟公司合作做一项新业务，双方加起来只有几个人，做了大半年之后，内部已经基本用起来，也开始有了一些外部客户。

客户少的时候，两个团队还可以正常合作。等到有了大客户，问题就出现了。一方面，大客户自然而然会提出一些定制化需求；另一方面，在客户开始真正关注使用效果之后，合作双方就需要不断做一些临时尝试，看看什么方式更有效。

朋友自己的团队已经完全采用 AI Native 的工作方式。碰到一个新想法，他们的第一反应是先修改、先测试，不行就回滚。他们也不再认为，一套完全标准化的产品形态能够解决所有客户的问题。

但兄弟公司的经理不太了解外部业务，也没有太大兴趣，程序员没有使用 AI，内部需求本身都做不完，所以非常排斥外部客户提出的新需求，更反对定制化。最后，就因为这几项客户需求，两边彻底闹崩了。对方不再参与外部业务，也没有交接任何一个关键模块。

这件事原本看起来像是被对方拿捏住了，但按照朋友的说法，几天之后，他自己就已经把替代模块测试跑通，再稳定一段时间，就可以逐步完成替换。

这件事表面上是几项客户需求把合作谈崩了，背后其实是两套工作方式已经无法兼容：一边看到问题就开始验证，先改、先试，不行就回滚；另一边看到问题，则先等它被某个岗位批准成为“需求”。Agent 真正拉开的，不只是写代码的速度，而是团队处理问题的方式。

这种冲突不只会发生在两个合作团队之间。在同一家公司内部，已经看见问题的人和有权定义需求的人，也可能生活在两套完全不同的工作方式里。

客户有问题，但问题还不算需求

有另一个朋友在某知名大厂工作，有一次跟我吐槽他们团队做 AI 产品的方式。这个产品要求用户用自然语言描述一个复杂的配置操作，在包括他在内的所有正常人的视角里，这种交互明显不合理。自然语言适合表达模糊的目标，但一个涉及多项选择、需要精确确认的操作，很多时候用 UI 来呈现会更清楚，也更不容易出错。

于是，他自然问研发，为什么不把这里改成 UI？

研发回答，因为 PM 没有提需求，所以不能改。

这句话简直让人气笑了。用户已经在使用产品，产品这么明显的一个问题也已经被看到，但这个问题还不能直接推动产品发生变化。因为它必须先由一个拥有特定岗位的人发现、整理、描述，再通过正式流程转交给研发，才有资格成为“需求”。

换句话说，需求不是由用户的问题产生，而是由岗位的权限产生。

这是一种非常尊重流程的工作方式。用户可以遇到问题，研发也可以知道怎么解决，但只要 PM 没有提需求，代码就不能改。在流程面前，他们什么都不是。

更有讽刺意味的是，这个团队做的恰好还是 AI 产品。产品希望 AI 理解一个模糊目标之后，自己拆解任务、调用工具并完成工作；但在研发这个 AI 产品的时候，人却依然需要等待上一个岗位把任务拆好，再按照流程向下传递。

Agent 被要求主动工作，人却被要求等待需求。

当修改变便宜，等待就成了最贵的部分

上面两个故事里，真正的分歧还没到要不要解决问题，而是什么时候可以开始看这个问题。这个分歧在 AI 出现之后越来越尖锐，背后的原因还是修改代码的成本变了。

传统研发流程并不是没有道理。在过去，每一次修改都有很高的开发成本。所以，每修改一个产品功能，需要产品经理写需求、研发评估、测试验证、安排版本再发布上线，本质上是需要有人，或者说流程，来统一判断优先级，控制研发资源的使用。

简单来说，过去的流程，是为了管理昂贵而稀缺的研发资源。

但 AI 正在改变这个前提。很多过去需要几天甚至更长时间的修改，现在可以先由 AI 来实现，再由人判断结果；一些低风险、容易验证、能够回滚的想法，也不必等到所有人都讨论清楚之后再动手，完全可以先做一个控制好范围的实验，用真实反馈帮助团队继续判断。

当实现成本明显下降，组织里的主要成本就会慢慢从“怎么把它做出来”，转移到“谁有权决定可以开始做”。如果一个修改只需要很短的时间，审批、排期和跨岗位传递却需要更长时间，那么，原本用来节约研发资源的流程，反而开始浪费研发资源了。

这种“产品已经开始做 AI，组织还在沿用旧流程”的情况，我在一家成熟 2B 软件公司里也见过。这家公司在原有业务线上做 AI 产品时，专门投入了 6 名 PM。看起来投入不可谓不大，但团队依然按照最熟悉的方式工作：PM 调研、整理和提出需求，RD 接到需求之后再开发。

原有业务比较复杂，需要 PM 本身没有问题，6 名 PM 是多是少也不能脱离具体业务判断。真正的问题是，团队虽然开始做 AI 产品，产品与研发的关系却没有变化。AI 只是变成了需求列表里的一批新功能，负责提需求和负责写代码的人，仍然按照原来的边界分工。

产品在做 AI，组织仍然在做需求转发。

这也是为什么，我一直觉得，企业引入 AI 最没用的方式，就是给每个人买一个账号，培训一下怎么写提示词，然后继续按照原来的岗位边界、审批流程和考核方式工作。组织不改，做事方式不改，AI 带来的效率越高，原有流程的低效反而会越显眼。

当然，这并不是说，有了 AI 以后，任何研发看到问题都可以直接修改生产系统。AI 可以更快地写出正确代码，同样也可以更快地制造错误。涉及客户数据、广告预算、权限、安全和公共架构的变更，依然需要评审、测试和审计。

真正需要改变的，是流程的依据。过去很多流程按照岗位设计，未来的流程则需要更多按照风险设计。

低风险、容易验证、能够回滚的修改，可以让离问题最近的人快速发起实验；高风险、影响范围大、难以恢复的修改，则继续经过严格评审。AI 没有让流程消失，只是让流程应该集中到真正有风险的地方，而不是平均分配到每一处代码修改上。

也许我并不知道，有了 AI 之后，什么样的研发流程是对的。但有一点我非常笃定：还在固守原有流程，根本不去思考怎么改变，一定是错的。

两个团队分裂的并不只是开发效率

再回到开头两个团队的故事。

表面上看，一个团队使用 AI，另一个团队没有使用，所以双方的开发效率逐渐拉开。但更深层的差别，是他们开始用完全不同的方式理解工作。

朋友的团队看到客户提出一个新想法，首先会把它当成一个等待验证的假设：能不能先改一下？怎么测试？效果不好能不能回滚？而另一个团队看到同样的想法，首先想到的则是：这是不是定制化需求？有没有排进内部计划？为什么要打断当前工作？

前一种方式围绕问题组织工作，后一种方式围绕岗位和计划组织工作。开发速度的差异，只是两种工作方式最终呈现出来的一个结果。

这里也不能简单归因于谁更积极。兄弟公司的经理并不对外部业务负责，程序员手上还有大量内部需求，也没有使用 AI 提升效率。在他们原有的职责和考核方式下，排斥外部需求、拒绝临时尝试，其实都是非常合理的选择。

于是就出现了组织里最常见、也最荒谬的一种结果：每个人都严格完成了自己的工作，只有客户的问题没有人负责。

真正的需求应该从客户现场长出来

这个案例里，自然语言和 UI 到底应该怎么组合，最终可能还需要用真实使用效果来验证。但更值得讨论的问题是，一位离用户很近的同事已经看见了产品的使用障碍，这个发现却无法直接推动一次低成本的产品实验。

用户并不关心产品是不是足够像 Agent，也不关心团队使用了什么模型。用户只关心，自己能不能更简单、更准确、更放心地完成一项工作。产品到底该怎么设计，需要看具体任务，而不是看哪种产品形态更符合当前火着的概念。

所谓 Agent 产品，其实不是让用户尽可能多地和 AI 聊天，而是让用户用尽可能低的成本完成工作。

如果一个复杂的操作，用 UI 更清楚，就应该使用 UI；如果用户只需要说清楚目标，后面的拆解和执行可以交给 Agent，就不需要再让用户逐项配置；如果结果用自然语言表述更简单，就用自然语言表述；如果结果用图标展示信息更清楚，就放心大胆引入图标。

这里面没有哪一种交互天然更先进，只有哪一种更适合用户当前的任务。

以前我们给客户介绍产品，往往会花很多时间讲解产品逻辑和使用方案。现在我们越来越倾向于先不讲，直接看客户怎么使用，在哪里停下来，哪些能点击的地方不敢点击，哪些地方需要反复确认，哪些结果出来之后他还是不相信。

因为一旦我们马上开始解释，就可能用人的讲解掩盖产品设计本身的问题。如果用户每次卡住，我们都靠人把他教会，团队最后积累下来的可能不是产品能力，而是一套越来越熟练的培训话术。

从这个角度来说，真正先进的产品工作方式，不是研发能够更快地完成 PM 提出的需求，而是团队能够更快地看见客户的问题，把问题变成假设，再把假设变成可以验证的产品变化。

当代码越来越容易生产，真正稀缺的就不再只是实现能力，而是理解客户现场的能力，以及把观察到的问题快速变成实验的组织机制。

谁能看见客户在哪里卡住，谁能判断一个临时需求背后是真问题还是偶发现象，谁能把验证过的做法沉淀成产品能力，谁才拥有真正难以复制的竞争壁垒。

写在最后

回到那句“因为经理没有提需求，所以不能改”，它并不是某一个研发或者经理的问题，而是传统组织分工的一次非常准确的自我表达。

在这套分工里，每个人都只需要对自己接到的部分负责，整个组织退化成了一个推动流程运转的机器，至于用户的问题有没有真正解决，则需要整个流程跑完之后，大家再一起开盲盒。

而 AI 正在让很多执行环节变得越来越快。这个时候，如果组织依然要求所有问题沿着原来的岗位链条逐级传递，那么，写代码的人越快，等待需求的人就会越多。

AI 时代，真正需要被重写的可能不是代码，而是“经理不提需求，代码就不能改”这条默认规则。

本文作者曹犟正在和团队打造 Omni-Growth Agent，一套 AI 海外增长引擎，你决定交出多少控制权：想把海外营销整个交出去的，我们全托管、按增长结果付费；想自己掌舵的投手，配一个 7×24 盯盘和诊断的 AI Copilot，判断权还在你手上。文中讨论的 Agent 实践，正是我们在 Omni-Growth Agent 上的真实落地。更多信息可以看这里：https://omni-growth.ai