近期看来一篇推文（孔某人的低维认知）分享关于LLM应用层新功能的研发范式，结合自己做项目的经验，抛砖引玉，和大家做一些简单的分享。
1. 本质问题
问题不是怎么做功能，而是怎么把风险前置。
对用户需求不够了解，无法细分用户群，也无法判断做到什么程度才能PMF。
不知道如何触达用户，或者即使知道路径，也无法以可接受的成本进行营销。
对大模型在具体场景中的能力边界和性价比缺乏清晰认知，既不知道它在哪些用户问题上可以做到 PMF，也不知道某个产品功能/效果是否能够在传播中获得优势。
产品研发和营销整体的迭代趋势偏慢，在模型能力趋同、应用层差异缩小的阶段，这个点是团队差异的核心。
2. 范式介绍
当我们遇到问题时，究竟应该指望模型未来能力的提升来解决，还是必须在当下通过产品与工程手段主动解决？这并不是一个 0 或 1 的二元选择，而是一条存在大量灰度空间的连续谱。不同问题，所处的位置并不相同。
2.1 风险前置
可用产品到可营销产品的转化。
现在大家说MVP的时候，更多是侧重于产品功能和用户需求的验证。但实际上，在新产品、新功能的营销阶段，营销成本已经逐渐成为最大的成本项，特别是对于软件类应用来说。产品能满足用户需求，但无法低成本有效营销触达的产品，实际上已经是不可行的。
因此，在现阶段GenAI应用层，MVP的定义应该被扩展到最小可营销产品，在验证功能成立和可行的同时验证其可营销性。
2.2 核心功能验证小队（CVP，Core Validation Pod）
CVP这个小队应该闭环相关的研发、需求洞察、营销等能力，可以独立交付一个最小化的PMF且营销成本可接受的产品原型。
2.3 CVP驱动的研发流程
那么现在一个新产品/功能的研发流程就可以划分为：
产品设计，原型立项。
CVP小队进行产品V0.5版本开发和迭代，直至确认可行。
如果CVP研发阶段通过，则视领域场景和情况决定是否还需要做继续优化再发布，（还是可以直接先发布）。如果优化阶段发现有明显的问题，则再回到2.环节进行迭代优化。
其他研发资源或其他资源介入，把CVP交付的产品核心按场景要求重新构建，以满足稳定性、可维护性、产品UI细节优化、非必要的端侧App开发等等方面。
但CVP并非越全面越好，CVP的主要职责是快速迭代去解决无法被解耦的重要风险，所有能够解耦开的相对风险不那么高的都可以放在独立的环节进行，可以是并行的环节2，或者是3、4环节中。
这里我的实践经验是，需要核心的2-3个人在紧密的时间周期内进行完成，需要能力图谱相对比较全面的人，防止出现一些思维维度不全面后续开倒车的情况。
以下是摘自原文，非常有启发性。
3. 实际组织中会遇到的问题
3.1 人员选择
首先，CVP需要的能力跟很多组织专业化细分的岗位不同，它更需要的是广度，能自己闭环，而不是在某方面深入。当真的遇到一些深度问题时，它可以去找外援。而对于绝大多数功能来说，并不需要更细分的专业岗位。
第二是，CVP的工作内容是高度不确定性的，与之相对的是组织中有很多岗位是可以算得清楚某个工作的人日消耗的，例如后端、前端、测试等等岗位。后者中有一些愿意探索新东西、接受不确定性的人，但很多人天然是想远离不确定性的，因为这和他的工作方式和被考核方式是冲突的。
在CVP中，延期是正常的，每个尝试的方案可以估计时间，但做出来后的效果是否满足要求则不知道，而去尝试和测试这点就是CVP团队的意义。如果没有达到效果，那么自然就要再换其他方式，或者放弃该项目。在CVP中，甘特图等传统项目管理工具的价值很小。
如果一个组织中，之前没有这种原型探索验证+工程化的研发流程划分，那么在其中找到适合的人来做相关的事情是比较难的，因为这不同于已有岗位的能力要求，考核方式也很不相同。
3.2 对已有研发流程的破坏
从研发风险来说，CVP实际上是把之前分散在研发和推广等各环节的风险都聚合并前置了，它实际上改善了组织其他部分的不确定性。
但CVP团队很难跟其他团队放在一起进行联合排期、绩效考核等等。因为它们的工作方式和工作性质完全不同。
这里很有意思的是，这种研发方式跟PMO实际上很容易有冲突。组织中，PMO的职责除了信息收集和同步外，还有一部分就是研发进度的标准化。但实际上CVP的方式是创造了一种新的研发模式，并且需要配套的进度反馈方式，与传统能够算清楚人日的研发活动很不相同。要说的话，很类似于产品立项之前的混沌阶段。PMO执行的任务信息表的结构，很大程度上反映了组织对不同研发模式的认可度。那些既不能体现在PMO项目大盘上、又没有自己状态类别的研发范式，其实并没有真正被组织所接受。
还有一个常见问题是，立项时需要的一些数据支持。实际上在不少场景下，想获得一个准确的预计数据很难，特别是你连产品功能效果和营销效果都不能很确定，都还需要CVP去验证的时候，你如何可能得到一个准确的数据呢？所以在实践中，立项可能也分为两个阶段比较好，一个是原型探索立项，CVP小队接需求；第二个才是正式产品立项，由更多的研发资源团队来接需求。而整个第一个阶段实际上都对应到过去的产品调研立项阶段。
3.3 线上与预研的方案一致性
当新功能上线之后，就变成了一个已有的功能。已有功能也需要优化和迭代，实际上很多重要的迭代还是需要CVP小队进行，虽然可能需要的能力范围比新功能预研时候少一点，但仍然经常需要不止一种角色。
一种方式是，内部有一种抽象度更高的平台/DSL，能够让预研和线上系统都使用完全同样的技术框架和基础设施，一个实现可以相对容易地在CVP阶段和线上实现中进行迁移，而不需要经过大规模的重写翻译。
另一种方式就是，两边的技术框架可以解耦，但要给CVP团队配相对更完善的内部数据和逻辑接入能力，可以让他们更好地接入线上系统的逻辑，并替换修改其中的一部分。
Recently, I came across a WeChat post discussing a development paradigm for new features at the LLM application layer. Based on my own project experience, I’d like to build on that and share some thoughts as a starting point for discussion.
1. The Core Problem
The real question is not how to build features, but how to front-load risk.
Insufficient understanding of user needs: teams struggle to segment users and to judge what level of completeness is required to reach PMF.
Unclear user acquisition paths: even when channels are known, teams often cannot market effectively at an acceptable cost.
Lack of clarity around the capability boundaries and cost-performance tradeoffs of large models in specific scenarios: teams don’t know which user problems can realistically reach PMF with LLMs, nor whether a given feature or output has any distribution advantage.
Slow overall iteration across product development and marketing: in a phase where model capabilities are converging and application-layer differentiation is shrinking, iteration speed becomes the core differentiator between teams.
2. Paradigm Overview
When encountering a problem, should we rely on future improvements in model capabilities to solve it, or should we proactively solve it now through product and engineering efforts?
This is not a binary 0-or-1 choice. It is a spectrum with many shades of gray, and different problems sit at different points on that spectrum.
2.1 Front-Loading Risk
From usable products to marketable products.
Today, when people talk about MVPs, the focus is usually on validating product functionality and user needs. In practice, however, during the go-to-market phase of new products or features, marketing cost has increasingly become the largest cost item—especially for software and AI products.
A product that satisfies user needs but cannot be marketed efficiently at low cost is, in reality, not viable.
Therefore, at the current stage of GenAI applications, the definition of MVP should be expanded to a minimum marketable product: validating not only that the functionality works, but also that it can be marketed.
2.2 Core Validation Pod (CVP)
A CVP (Core Validation Pod) is a small team that closes the loop across development, user insight, and marketing capabilities, and can independently deliver a product prototype that achieves a minimal PMF with acceptable marketing costs.
2.3 CVP-Driven Development Process
Under this paradigm, the development of a new product or feature can be divided into the following stages:
Product design and prototype initiation.
The CVP team develops and iterates on a V0.5 version until feasibility is validated.
If the CVP stage passes validation, decide—based on the domain and context—whether to release directly or continue optimizing before release. If major issues are discovered during optimization, return to stage 2 for further iteration.
Additional engineering or supporting resources step in to rebuild the CVP-delivered core according to production requirements, such as stability, maintainability, UI refinement, and non-essential client-side app development.
CVPs should not be overly comprehensive. Their primary responsibility is to rapidly iterate and resolve critical risks that cannot be decoupled. Risks that can be decoupled and are relatively lower can be handled in separate stages—either in parallel with stage 2 or during stages 3 and 4.
From my own experience, this usually requires 2–3 core individuals working closely within a tight time window, with relatively broad capability profiles, to avoid blind spots that later force major rework.
The following section is excerpted from the original post and is particularly insightful.
3. Challenges in Real Organizations
3.1 Personnel Selection
First, the capabilities required by a CVP differ significantly from highly specialized roles common in many organizations. CVPs prioritize breadth and self-sufficiency over deep specialization. When deep expertise is truly needed, external support can be brought in. For most feature exploration, fine-grained specialization is unnecessary.
Second, CVP work is inherently highly uncertain. In contrast, many organizational roles—such as backend, frontend, or QA—allow for clear estimation of effort in person-days. While some individuals in these roles enjoy exploration and uncertainty, many naturally avoid it, as it conflicts with their working style and evaluation metrics.
Within a CVP, delays are normal. The time required to try an approach can be estimated, but whether the outcome will meet requirements cannot be known in advance. Experimentation and validation are precisely the purpose of the CVP. If a solution fails, the team must pivot or abandon the project. Traditional project management tools like Gantt charts have limited value in this context.
If an organization has never separated “prototype exploration and validation” from “engineering-scale delivery,” it is often difficult to find suitable internal candidates for CVP work. The required skill set and evaluation criteria differ significantly from existing roles.
3.2 Disruption to Existing R&D Processes
From a risk perspective, CVPs aggregate and front-load risks that were previously scattered across R&D and go-to-market stages, thereby reducing uncertainty elsewhere in the organization.
However, CVP teams are difficult to integrate into unified scheduling, performance evaluation, or planning with other teams, due to fundamentally different work patterns.
This approach often conflicts with PMO functions. PMOs are responsible not only for information tracking but also for standardizing development progress. CVPs, by contrast, represent a new development mode that requires different progress feedback mechanisms, closer to the chaotic phase before formal product initiation. The structure of PMO tracking systems often reflects which development paradigms are truly recognized by the organization. Paradigms that do not fit existing tracking structures are effectively not accepted.
Another common issue arises during project approval, which often requires precise data forecasts. In many cases, accurate estimates are impossible—especially when both product effectiveness and marketing effectiveness are still unverified and require CVP validation. In practice, it is often better to split project approval into two phases: an exploratory prototype phase handled by the CVP, followed by a formal product phase taken over by larger engineering teams. The first phase corresponds to what was traditionally considered product research and feasibility analysis.
3.3 Consistency Between Production and Pre-Research
Once a new feature is launched, it becomes part of the existing system and must continue to evolve. Many critical iterations still require CVP involvement, even if the required capability range is narrower than during initial exploration.
One approach is to build a higher-level internal platform or DSL that allows both pre-research and production systems to share the same technical framework and infrastructure, enabling smoother migration without large-scale rewrites.
Another approach is to decouple the frameworks but provide CVP teams with stronger access to internal data and logic, allowing them to integrate with and partially modify production systems more effectively.