AI 时代，不是所有业务诉求都该进入研发系统

过去很多团队里，其实默认存在着一条很稳定的链路：业务提出诉求，产品整理成需求，设计给出方案，研发接手实现。

这条链路在很长一段时间里都没有太大问题。因为在那个阶段里，“把一个业务问题翻译成系统能力”这件事，本来就主要只能由研发来完成。于是大家也逐渐形成了一种近乎默认的理解：只要业务提出了一个问题，它最终大概率都会被整理成研发需求，进入排期、设计、开发、测试这条链路。

换句话说，研发系统一直是业务诉求最主要、也几乎是唯一的正式承接通道。

但 AI 进来之后，变化并不只是“代码写得更快了”。更早发生变化的，其实是另外一件事：

不是所有业务诉求，都还需要先被翻译成研发需求，再进入研发系统。

有些问题，本质上只是规则没说清、流程没理顺；
有些已经可以被现有 Skill 直接承接；
有些更适合用 NoCode 或配置化能力吸收；
只有剩下的一部分，才真的需要进入正式研发链路。

所以今天如果还把所有业务诉求都默认推给研发，再讨论“怎么提效”，其实已经有点晚了。真正先变化的，是业务诉求进入系统的方式。

如果把传统产研协作再抽象一点，会发现它背后其实有一个很强的默认前提：

业务问题的主要解法，最终都要靠研发系统来承接。

这也是为什么过去很多组织虽然知道“翻译损耗”存在，但仍然愿意接受它。因为从业务诉求，到产品需求，到设计方案，再到研发实现，这种层层翻译虽然有成本，但它几乎是唯一可靠的路径。

但今天，这个前提开始松动了。

AI 带来的变化，不只是让研发在既有链路里写得更快、做得更多；它还在改写一件更上游的事：一个业务诉求出现之后，它已经不再只对应“转成研发需求”这一种去向。

这意味着，过去那条单一路径开始分叉了。

有些诉求，在进入研发之前就应该被拦下来重新澄清；
有些不需要新开发，而应该直接复用已有自动化能力；
有些适合被配置化平台吸收；
只有一部分，才真的应该进入研发系统，并继续在内部按复杂度分层处理。

如果这个分叉没有被看见，组织就很容易出现一种表面上的提效、实则更深的拥堵：
AI 确实让研发更快了，但研发仍然在承接大量本不该由它承接的问题。

今天很多关于 AI 提效的讨论，仍然停留在“怎么让研发更快写代码”。这当然重要，但它更像是问题的后半段。

前半段其实是：

这个诉求到底该不该进入研发，它应该被哪种交付方式承接。

这是一个很容易被忽略的变化。

因为在过去，“业务诉求”和“研发需求”之间几乎是天然连在一起的。一个问题只要被提出来，接下来往往就是产品整理、设计补齐、研发开发。

但在 AI 时代，这条线开始被拆开了。

业务诉求仍然存在，但它不再天然等于一个研发需求。它可能只是一个需要澄清的口径问题；可能是一段可以由数字员工执行的稳定流程；可能是一个适合 NoCode 搭建的小工具；也可能确实需要进入研发系统，但只需要轻量研发承接。只有更复杂、更高风险、更系统性的部分，才需要进入完整研发链路。

所以如果今天还把“需求管理”理解成“需求来了以后如何分优先级、如何排研发”，其实已经少看了一层。
在真正进入研发分层之前，实际上先出现了一层更上游的判断：

这个业务诉求，应该被哪一种机制承接。

这也是我想讨论的第一层。

在讨论“需求复杂度分层”之前，其实先出现了一层更上游的判断：

一个业务诉求，到底该不该进入研发系统；如果要解决，它应该被哪一条交付路径承接。

我把这一层叫做 G 层（Gateway Layer）。
你可以把它理解成业务诉求的分流层。

它解决的不是“这件事复杂不复杂”，而是更前面的那个问题：

这件事应该走哪条路。

这两个问题很容易被混在一起，但其实不是一回事。

“复杂度分层”讨论的是：既然已经进入研发，那该按什么等级处理。
而 G 层讨论的是：它到底要不要先进入研发。

这层一旦被明确出来，很多原来会被默认推给研发的问题，就会开始被重新分流。
有些被澄清吸收掉，有些被已有 Skill 承接，有些被配置化平台消化，只有一部分继续流向研发系统。

从这个角度看，AI 带来的不只是执行效率的提升，更像是把过去那条单一路径，改写成了一套新的路由机制。

有些业务诉求表面上看像“要做一个功能”，但本质上并不是系统建设问题，而是规则没说清、流程没理顺、协同边界不一致。

比如在一个管理后台里，业务提出要新增一个“异常状态”字段，希望在列表页和详情页都展示出来。继续往下梳理后发现，真正的问题不是缺字段，而是几个角色对“什么情况算异常”的判定标准并不一致：有人按时间阈值算，有人按处理结果算，还有人按人工标记算。
在这种情况下，如果直接进入研发，最后大概率只是把尚未统一的规则提前固化进系统里。

这类问题更优先的动作，往往不是开发，而是先把规则说清楚，把口径统一，把流程理顺。很多时候，一份说明文档、一轮规则对齐，甚至一次流程调整，就比新增页面元素更有效。

所以 G0 不是“不做”，而是：

先别急着把口径问题翻译成系统需求。

还有一类诉求，确实需要被执行，但它需要的不是“新开发”，而是“调用已有能力”。

比如运营团队每天都要从一份名单里筛出待处理对象，登录后台逐个检查状态是否满足条件，再把结果回填到表格里并通知对应负责人。如果这个过程中的判断规则已经比较稳定，系统入口也相对固定，那么更合适的承接方式，往往不是新提一个研发需求，而是让数字员工直接调用已有 Skill，完成“读取名单—查询状态—按规则判断—输出结果”这条链路。

再比如，某个流程系统里每天都要做一次固定检查：把第二天待执行的数据跑一遍规则校验，把异常项整理成清单，发给对应角色处理。如果这套检查逻辑已经相对清晰，它更像是一个稳定的执行任务，而不是一个新的系统建设问题。

这类诉求的关键不是“有没有系统”，而是：

有没有现成能力可以直接承接。

它真正要的是执行，不是新的系统改造。

再往前一步，有些诉求确实需要一个工具形态，但复杂度又不足以进入正式研发链路。这时更合适的方式，不是让研发从零写代码，而是让它被 NoCode、模板化能力或配置化平台吸收掉。

这里说的“配置化”，不是指研发内部再做一层抽象配置，也不只是简单改几个后台参数，而是指诉求本身适合被表单、字段、流程、模板等现成能力组合吸收，作为一个轻工具被快速搭建出来。

比如一个运营团队临时要做一个活动登记台，用来收集门店、时间、参与人员、物料需求、审核状态等信息。它需要表单、列表、筛选、简单流转，看起来像个“小系统”，但逻辑并不复杂，生命周期也未必长。
这类问题如果走完整研发排期，成本通常会高于收益；而如果通过现成的配置化能力快速搭起来，反而更合适。

再比如，一个内部协作场景需要一个轻量的异常上报页：填报问题类型、影响范围、处理进度，并支持按区域和状态筛选。这类需求同样需要页面和数据结构，但并不一定值得进入正式研发系统。

所以 G2 的判断标准，不是“能不能做”，而是：

值不值得动用正式研发资源去做。

也有一些诉求，已经明确需要改系统、动代码、提 PR，但边界清晰、影响范围有限，适合轻量研发模式承接。

比如在一个业务管理后台里，新建表单时需要根据当前上下文自动带出一组默认值；
或者在详情页里取消一个状态标签的展示，并同步移除相关提示文案；
再比如在提交流程前新增一层规则校验，不满足条件时给出驳回提示。

这类需求通常集中在一个页面、一个表单流程、一个局部规则链路或一个提示逻辑中。它已经明确属于研发问题，因为要改系统行为、要进入代码仓库；但它的边界又足够清晰，不一定需要完整的重型链路来处理。

如果上下文准备得足够明确，这类需求就很适合由 Agent 结合仓库上下文先完成实现，再由研发做 review 和少量修正。它不是“不经过研发”，而是以一种更轻的研发方式被承接。

所以 G3 的关键是：

它已经是研发问题，但还是轻量研发问题。

最后一类，才是真正需要进入正式研发系统的诉求。

它们往往不是某一个页面上的单点改动，而是会同时影响多个模块、多种角色、多个状态流转，甚至会牵动下游口径、历史逻辑和验收方式。
这类问题表面上也可能只是一个“加规则”“补流程”“改展示”，但一旦往下展开，会发现它改的已经不是一个局部行为，而是一整段系统链路。

比如一个看起来只是“增加前置校验”的需求，真正落地时却发现，它会同时影响提交流程、异常处理方式、角色提示、统计口径和后续追踪逻辑；
又或者一个看起来只是“取消某类标记展示”的调整，继续拆下去才发现，它背后连着聚合逻辑、多个下游消费方，以及一整套已经运行中的判断规则。
这时候，问题就不再是“把一个功能点做出来”，而是“如何在不打乱既有系统的前提下，重新组织一段完整链路”。

这类诉求，已经不能再按轻量研发来处理。因为真正的难点，不在于代码本身，而在于要同时处理好多源输入、任务建模、实现过程和最终验证。
它需要的，不只是一个能写代码的 Agent，而是一条更完整的端到端链路：输入如何被理解，约束如何被显式表达，任务如何被拆解，结果如何被验证，风险如何被控制。

所以 G4 的关键不是“需求更大”，而是：

它已经形成了系统级影响。

真正决定它落在 G3 还是 G4 的，不是标题看起来大不大，而是它影响的是一个局部逻辑，还是一整段系统链路。

到这里，G 层解决的是第一个问题：

一个业务诉求，该走哪条交付路径。

只有当它被判断为需要进入研发系统之后，问题才会进入第二层：L 层（Level Layer），也就是研发执行等级层。

换句话说，G 层回答的是：

该不该进研发，该走哪条通道。

而 L 层回答的才是：

既然已经进了研发，这件事该按什么等级处理。

这两个问题看起来接近，但实际上处在完全不同的位置。
G 层决定的是“去向”；L 层决定的是“处理强度”。

如果没有 G 层，很多本不该进入研发系统的问题，会被过早技术化；
如果没有 L 层，那些已经进入研发的问题，又会被用同一种方式粗暴处理。
前者会导致研发入口拥堵，后者会导致研发内部失配。

从这个角度看，AI 时代真正需要的，不只是一个“需求分层模型”，而是一套更完整的两层机制：

先在 G 层判断诉求应该被哪种交付方式承接；
再在 L 层判断进入研发之后，它应该按什么等级被处理。

在这套框架里，L0 到 L4 解决的是研发内部的执行强度问题。
例如，最轻的一层，可能已经边界清晰到可以由数字员工直接闭环；再往上，是 Agent 能独立完成大部分实现、研发只做 review 的需求；再复杂一些，则需要补充约束、加强验证；再往上，才进入完整的任务建模、执行和自动化验证闭环。

这部分，这篇先不展开。
因为比起马上把 L0 到 L4 全部讲透，更重要的其实是先看清：

在“需求分层”之前，实际上先出现了一层诉求分流。

如果把整件事重新看一遍，会发现 AI 带来的变化，并不只是研发提效工具的升级。它更像是把过去那条单一路径，改写成了一套新的路由机制。

过去，很多组织默认的处理方式是：

业务提诉求，产品整理需求，设计补方案，研发接手实现。
这条链路的问题不在于它错，而在于它默认了所有问题最终都要流向研发系统。

但今天，这个默认前提正在失效。

有些诉求应该先被澄清；
有些应被已有 Skill 直接承接；
有些适合由 NoCode 吸收；
有些进入轻研发；
只有其中更复杂、更高风险、更系统性的部分，才真正进入正式研发系统，并继续在内部按等级被处理。

所以 AI 真正改写的，不只是“研发怎么更快做需求”，而是：

业务诉求不再默认直接流向研发，而是先被判断应该由哪种交付方式承接。

从这个意义上说，研发系统开始从“默认入口”变成“特定类型问题的专业承接方”。这不是研发被削弱了，而是研发终于不必再承担所有问题的统一入口。
真正被强化的，反而是整个组织面对业务诉求时的分流能力、路由能力和承接能力。

过去，很多问题默认都要先进研发，再讨论怎么做；
现在，更重要的问题开始变成：

它到底应不应该进入研发，以及如果进入，应该以什么等级被处理。

这或许才是 AI 时代需求机制真正变化的地方。

当业务诉求不再默认进入研发系统之后，一个更具体的问题也随之出现：

哪些足够轻、足够清晰、足够稳定的诉求，已经可以直接交给数字员工承接？

这也是我接下来更想继续展开的一层。
当一个诉求被判断不需要进入传统研发链路，或者即使进入研发也已经轻到足以被 L0 承接时，它到底是如何被数字员工真正完成交付的？

下一篇，我想专门展开这一点：

什么样的 G1 诉求，已经可以直接交给数字员工，以及我们是如何把数字员工这条链路真正跑通的。