2025年算是LLM增强产品井喷的一年，以笔者亲身经历的，不论是自动化测试平台还是云服务稳定性平台，都在已有平台基建的基础上，依靠LLM增强的AIGC能力，做了诸如XMind用例自动生成、用例步骤自主探索、RCA故障定位以及服务发布风险实时解读等有业务价值的能力。
要做出这样的产品，投入的研发人力也肯定不少，而在这个体系下，怎么分配不同的研发角色，既能让每个模块的同学专注自身能力研发，又可以形成有机结合让整个产品顺利运转起来，是产品架构迭代过程中时刻都要思考的重要问题。为此，这篇文章就简单聊下，如果要大力投入这类型的产品研发，可能需要哪些角色，以及其中可能存在配合是怎样的。
首先从纯技术角度出发的话，可能需要这么几类研发：
- 平台工程：分前后端角色，把握整个平台的核心架构迭代，主控需求交付，同时关注产品业务跟稳定性指标；
- 业务域工程：比如自动化测试或者稳定性，也少不了任务调度平台、SRE稳定性等业务域研发的参与；
- Agent工程：在LLM增强产品少不了Chat-Agent的前提下，负责Agent平台研发，也关注Agent的业务场景和效果指标；
- 智能化工程：负责产品中LLM增强/AIGC能力的专项研发，一般作为产品/Agent/业务域工程的下游，主要关注能力效果；
- 知识库工程：一般作为智能化能力的下游，负责知识库CRUD、知识生产、RAG等功能研发，为智能化能力提供上下文基建；
- 智能化算法：主要负责面向业务的模型调优工作，注重智能化/Agent能力效果指标。
在这样基础上，每类角色的职责就会划分地比较清晰，对于单个能力，不同角色之间如何产生技术配合也会比较清楚。
再宏观一点，从业务产品的角度出发的话，产品经理、业务运营、业务BP跟质量QA等角色也是不可少的。在现实场景下，可能是产品经理把握功能迭代和排期定容，业务运营负责产品营销和推广，业务BP负责ToB定点推广落地，而质量QA负责把控产品质量做功能测试和效果评测。通过这样的分工，整套产品研发迭代就可以有效运转起来。
这里重点说下质量QA的角色，在降本增效的大环境下，很多QA的人力都会被砍，这样必然带来产品质量风险，本质便是保质量的事情分摊到了不同人身上，但其它角色都没有足够精力去把这点做深，所以交付时候就容易出现各管各的的情况。如果有条件，愿意把产品质量做的更好的话，对于LLM增强产品研发这件事情，最好还是引入专门把控交付质量的角色，重点补位P0功能、效果评测等复杂的、各方都没有足够精力投入的、存在较大质量交付风险的事情，协力把效果指标和业务指标都优化上来。
最后就是，如果读者你正好身在此局，不妨也从宏观视角审视下自己项目的运转，看看自己身处什么角色，在这个项目里能够多做些什么，多了解些什么。除了技术研发本身之外，对于如何拉通复杂的上下游，协调各方资源，把自己负责的功能和效果都做到极致，这份思考，说不定是此刻的你所需要的。