推荐语

探索LLM应用层研发新范式：如何在资源有限时快速验证产品与营销可行性。

核心内容：
1. LLM应用层研发面临的四大核心挑战
2. 风险前置策略与"最小可营销产品"新概念
3. 结合模型能力发展的灰度研发路线图

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

其实本文要谈的范式并不是一个很少见的方式，但真的能这么做的团队并不多。我感觉目前遇到的case中，能这么做的创业团队大概这方面的研发能力已经跻身于第一梯队了。如果是在一个超过100人的组织中（严格来说是单一业务中），那么这种研发方式就更加少见，并且更加难推动。

而我刚刚在一个组织中实践和推行了这种方式，所以也算是有了一些在组织中实践的经验，不算是无病呻吟。

本文在我之前的实践基础上，又做了一些扩展，增加了一个重要的维度——营销。这个版本应该是目前比较稀有的融合方案了，希望能给读者带来一些启发。

以及本文应该也能向读者展示我目前对于GenAI应用层创新的思考框架。

1、本质问题

所有的药都应该针对具体的问题，本文的范式也不例外。

在我看来，LLM应用层中，新功能的研发面对如下问题：

【1】对用户需求不够了解，无法细分用户群，对某个用户群也不知道做到什么程度才能PMF。

【2】不知道如何触达用户，不知道如何才能以相对低的成本进行营销推广。

【3】对大模型在具体场景中的能力边界和性价比缺乏清晰认知，既不知道它在哪些用户问题上可以做到 PMF，也不知道某个产品功能/效果是否能够在传播中获得优势。

【4】整体产品研发和营销迭代速度不够快的问题，特别是在当下技术供给趋同，应用层思路也趋同的阶段。

这里还有一个点是量化评估，不过这个点感觉更多是一个具体环节。

对于绝大多数团队和组织来说，在【1-2】这两点里，用户需求洞察和用户触达中有很大一部分，是由团队或组织的整体认知和能力所圈定的。我在这方面也不懂，本文就从略了，但不代表这个起点不重要。

剩下的问题是，在已经大致圈定了用户需求和营销方式之后，如何继续解决【1-4】的问题，而这是本文范式的目标。

当然这里还是着眼于新业务和新功能，所以一些更长期的因素也没有在本文中讨论。

2、范式介绍

在目前的GenAI应用层中，有个重要的因素是：选择是否要指望模型未来的提升来解决问题，还是现在就要自己解决一些问题，而且这并非0-1二元选择，中间有很多灰度路线。本文讨论路线是，自己解决核心问题，但还会考虑到模型能力在持续发展。

2.1、风险前置

大家现在都知道MVP（Minimum Viable Product，最小可行产品）的概念，目的就是用最小的成本，先去验证最关键的假设。也就是把最有风险的环节移到项目最前期来检验。

现在大家说MVP的时候，更多是侧重于产品功能和用户需求的验证。但实际上，在新产品、新功能的营销阶段，营销成本已经逐渐成为最大的成本项，特别是对于软件类应用来说。产品能满足用户需求，但无法低成本有效营销触达的产品，实际上已经是不可行的。

所以我们现在应该扩展MVP的定义，或者说换一个不容易引发歧义的叫法更好。《AI炼金术》最近有一期播客提到一个叫法“最小可营销产品”，其实就很有可参考性。我觉得说在MVP阶段，产品功能和可营销性都是需要考虑的，叫什么暂且不论。但这个产品原型阶段是需要客户需求、研发、营销三方面能力的最小团队的。而过去的MVP团队往往只具有前2方面能力的角色。

2.2、核心功能验证小队（CVP，Core Validation Pod）

为了和容易被误解的MVP进行区分，我从团队的角度上造了一个词叫做：产品核心功能验证小队。

这个小队应该闭环相关的研发、需求洞察、营销等能力，可以独立交付一个最小化的PMF且营销成本可接受的产品原型。这里叫做原型是它还可以被改进，但实际上它的标准就应该是一个可用的产品，用户大概率会一边骂一边用。

这个CVP小队的职责就是通过迭代产品原型，消除【1-3】的风险，并通过把人数最小化、快速迭代来提升产品探索速度，以此来优化【4】。

2.3、CVP驱动的研发流程

那么现在一个新产品/功能的研发流程就可以划分为：

【1】产品设计，原型立项。

【2】CVP小队进行产品V0.5版本开发和迭代，直至确认可行。

【3】如果CVP研发阶段通过，则视领域场景和情况决定是否还需要做继续优化再发布，（还是可以直接先发布）。

如果优化阶段发现有明显的问题，则再回到【2】环节进行迭代优化。

【4】其他研发资源或其他资源介入，把CVP交付的产品核心按场景要求重新构建，以满足稳定性、可维护性、产品UI细节优化、非必要的端侧App开发等等方面。

所有风险较高的探索环节都需要放在【2】环节中，并且在CVP中包含对应方面能力的人。例如有些功能也需要UI交互方面的探索设计，那么UI设计和前端/App端能力的人也需要纳入到CVP中。

但CVP并非越全面越好，CVP的主要职责是快速迭代去解决无法被解耦的重要风险，所有能够解耦开的相对风险不那么高的都可以放在独立的环节进行，可以是并行的【2】，或者是【3、4】环节中。

越多的人会导致CVP的最终选择趋向于中庸，并且迭代速度也会显著下降。但也并非1人就可以了，因为即使一个人能够同时兼任所有角色，他的思维也需要不断在各种视角上进行转换，而这个转换成本是较高的，容易导致某些方面的思考不足。

===

这个只是一个相对宏观的流程，实际过程中还可以再进行分解，例如软件产品中，还可以把【3】分解为：

【3.1】成本和延时优化。

【3.2】独立的产品效果量化评估。

……

3、实际组织中会遇到的问题

3.1、人员选择

首先，CVP需要的能力跟很多组织专业化细分的岗位不同，它更需要的是广度，能自己闭环，而不是在某方面深入。当真的遇到一些深度问题时，它可以去找外援。而对于绝大多数功能来说，并不需要更细分的专业岗位。

第二是，CVP的工作内容是高度不确定性的，与之相对的是组织中有很多岗位是可以算得清楚某个工作的人日消耗的，例如后端、前端、测试等等岗位。后者中有一些愿意探索新东西、接受不确定性的人，但很多人天然是想远离不确定性的，因为这和他的工作方式和被考核方式是冲突的。

在CVP中，延期是正常的，每个尝试的方案可以估计时间，但做出来后的效果是否满足要求则不知道，而去尝试和测试这点就是CVP团队的意义。如果没有达到效果，那么自然就要再换其他方式，或者放弃该项目。在CVP中，甘特图等传统项目管理工具的价值很小。

如果一个组织中，之前没有这种原型探索验证+工程化的研发流程划分，那么在其中找到适合的人来做相关的事情是比较难的，因为这不同于已有岗位的能力要求，考核方式也很不相同。最好的方式还是按需从外部招聘，并同时给这类团队适合的绩效评价方式。一般来说，有小团队创业经历的人更适合这种探索类岗位。

3.2、对已有研发流程的“破坏”

从研发风险来说，CVP实际上是把之前分散在研发和推广等各环节的风险都聚合并前置了，它实际上改善了组织其他部分的不确定性。

但CVP团队很难跟其他团队放在一起进行联合排期、绩效考核等等。因为它们的工作方式和工作性质完全不同。

万事都喜欢均匀化管理的组织实际上很难在内部【容忍】这样的团队的存在。无论是人还是组织，能挣到的钱都是自己认知的反映，这也就是所谓组织文化（中的维度之一）。双月OKR很难践行一些长期且没有中间反馈的战略，原因也是如此。

这里很有意思的是，这种研发方式跟PMO实际上很容易有冲突。组织中，PMO的职责除了信息收集和同步外，还有一部分就是研发进度的标准化。但实际上CVP的方式是创造了一种新的研发模式，并且需要配套的进度反馈方式，与传统能够算清楚人日的研发活动很不相同。要说的话，很类似于产品立项之前的混沌阶段。PMO执行的任务信息表的结构，很大程度上反映了组织对不同研发模式的认可度。那些既不能体现在PMO项目大盘上、又没有自己状态类别的研发范式，其实并没有真正被组织所接受。

还有一个常见问题是，立项时需要的一些数据支持。实际上在不少场景下，想获得一个准确的预计数据很难，特别是你连产品功能效果和营销效果都不能很确定，都还需要CVP去验证的时候，你如何可能得到一个准确的数据呢？所以在实践中，立项可能也分为两个阶段比较好，一个是原型探索立项，CVP小队接需求；第二个才是正式产品立项，由更多的研发资源团队来接需求。而整个第一个阶段实际上都对应到过去的产品调研立项阶段。那么是不是这个环节不拆分就好了？我觉得考虑到这并非单一产品岗的工作，而是CVP小队的整体工作，还是建议应该设立匹配该环节的研发流程管理方式才是更好的。毕竟组织想要的就是可解释性，不可解释的黑盒容易被人诟病。

3.3、线上与预研的方案一致性

当新功能上线之后，就变成了一个已有的功能。已有功能也需要优化和迭代，那么谁能做这件事呢？

实际上很多重要的迭代还是需要CVP小队进行，虽然可能需要的能力范围比新功能预研时候少一点，但仍然经常需要不止一种角色。

这时候就涉及到CVP团队是否能够方便地基于线上的业务状态来进行继续迭代。而很多时候，线上正式方案和CVP预研的方案在技术实施方案上有差异，导致后续功能迭代没有那么顺畅。

那么一种方式是，内部有一种抽象度更高的平台/DSL，能够让预研和线上系统都使用完全同样的技术框架和基础设施，一个实现可以相对容易地在CVP阶段和线上实现中进行迁移，而不需要经过大规模的重写翻译。

另一种方式就是，两边的技术框架可以解耦，但要给CVP团队配相对更完善的内部数据和逻辑接入能力，可以让他们更好地接入线上系统的逻辑，并替换修改其中的一部分。

3.4、评估体系（略）

对于LLM应用来说，量化评估是一个重要的问题，在组织中更是容易只看指标。

我后续会另外单独讨论这个问题。

3.5、AI原生的组织

实际上不光CVP团队的成员需要对于目前GenAI模型的能力有较多的了解，（研发岗的角色尤其如此），他们在过程中也会需要大量使用AI工具。

对于原型构建阶段，AI Coding是很好的工具，（当然仍然不能指望无脑抽卡，有使用方式的范式），可以降低开发成本，快速从一个方案切换到另一个方案等等。

3.6、避免极端

虽然说CVP团队已经有了AI工具的加持，但目前AI Coding工具和AI Agent工具（如Manus等）仍然不能很可靠的验证一些复杂或非常规的想法。目前AI Coding工具对于UI/UX的反馈迭代自动化链条还在早期。

所以实际上仍然需要人来做很多工作，CVP团队不是一帮CXO，只是在指挥AI干活。

我看到了一些极端的case，希望单人闭环地承担研发、产品、运营、UX、数据在内的所有职责。当然这种想法很好，但目前这对于绝大多数从业者来说难度太高了。这种地方目前是坑，别去。

另外是，希望通过倒逼来让组织内自动采用AI工具实现敏捷迭代的，实际上这也不行的。这个可以的话，国企的效率早就提高了。这个就不展开了。

实际上新的组织形式需要设计的，不是已有组织的渐进优化变革。用中央传动轴的工厂不会因为倒逼就能靠员工自己变革为用电动机的工厂，每个人没有那么大的权限。这不是自下而上能完成变革的。

不转型迟早会死，但如果太过于跑极端，则会死得更快。组织结构是自然发展出来的，每个公司的现状都不是创始人在3年前能够一下设计出来所有岗位的。

当然还有一些团队希望招聘和培养研发+产品的综合岗位，但这目前看成本较高周期较长。我目前觉得仍然需要产品+研发的组合，这样才不至于在招人上卡住。我对于招聘标准有句话：招聘方包括没有龋齿在内的各种要求，只要你能招得到就没有问题；反过来如果你招不到，那就是你的问题。招人的结果直接反映了招人期望和岗位设计的“正确”与否。

4、代价是什么

当然一切组织变革都有代价。

我现在已经离开之前实践该范式的团队，正在看新的机会。尝试对这个离开进行归因的话，有很多原因，而其中应该有一部分就是这个的代价吧。

就看你是不是身处一个愿意支付这个代价的岗位，或者一个有能力承担这个代价的岗位。