「降本增效」是人们在生产过程中永恒不变的话题、永远的追求——于公，长久看可以让企业减少开销并提供更为稳定、优质的产品；于私，能够使自己减少重复无营养的劳动，将精力投入到更为「高精尖」的地方，有助于自我成长，为自己为企业创造更大更多的价值。
提效的方式
现在想一下，在纯 Web 开发或大前端结合 Web 服务的领域中，提效的方式都有什么？
单点提效
从前端角度看，绝大部分前端团队都在不遗余力地去封装自己的工具库、UI 组件库、脚手架与构建工具，有些能力强点的团队还会封装应用开发框架、可视化源码搭建工具等。
从设计角度看，每个部门都会搞自己的设计规范/设计语言/设计体系，整理出一份设计侧的 UI 组件库，并制定一套 Design Token 用于与其他设计及前端沟通交流和设计与研发之间的联动。
从后端角度看，貌似没有什么可提效的空间——后端语言大多公司用的是 Java，相关生态体系已经很健全，顶多做些业务层面的封装。
从产品角度看，产品经理的工作就是接收/提出需求，做一些产品层面创收和改进相关的事情，这类思维活动为主的基本只能通过提升思维能力去提效了，如果有个业务向的知识图谱也许会好些。
链路提效
同工种或者说分工内提效的天花板清晰可见，很容易就会到达瓶颈。要想更进一步，自然而然也必须要跳出自己所处角色的视角，横向寻求上下游间的打通，共同提效。
以前端为中心与其他环节进行打通的话，大概是这么几种手段：与设计之间是设计稿与前端代码互转，即 D2C、C2D；与产品之间是需求文档转代码，即 P2C；与后端之间是采用 FaaS，即常规意义的「前后端一体化」。
产研一体化
上述几种链路提效方式的思考角度，一般都比较表层，仍是以自己或他人的职能为出发点，而不是从问题的本质开始探求解决方案——虽然每个分工角色的交付物不同，但它们都应是同一样事物的体现。
那么，那个「同一样事物」是什么呢？是模型与流程，或是业务概念、概念之间的关系以及相互间的作用，又或是业务知识。
所以，链路级的提效最关键的一点就是领域驱动的统一建模，其产物作为全链路的唯一可信来源（Single Source of Truth）。这意味着，从需求/产品、设计到开发、测试，都要基于同一份「数据」进行。
简要作业流程
产品整理各类需求，划分出各种业务概念，明确它们之间的关系和作用规则，这一过程就是在建模，最终会产出模型和流程。
建模结束后，产品可以在沉淀了 UI 组件、逻辑函数等物料的应用搭建平台上结合建模的产物制作「原型」，「原型」即最终页面。
若已有物料中没有想要的 UI 组件和逻辑函数等，可以用占位符之类的方式标注下，让设计和开发去补上。而 UI 组件和逻辑函数等的研发，既可以走线下又能够走线上。
协作模式变革
从上面的简要作业流程可以看出，从需求到研发最重要的角色基本只有产品和后端——产品负责领域建模和「原型」搭建，后端负责代码及数据连接，设计和前端被「踢」了出去，业务研发流程得到了精简。
从另一方面来看，也应该去尽可能减员——
软件开发过程就是从接到需求到产出符合需求的可用软件的过程。在这一整个链条中，源头是需求提出方，然后经过产品、设计、开发、测试等不同岗位的人处理。
虽说源头是需求方，但更实际的源头是需求方的意愿。这个「意愿」是不是「真（true）」的，首先要打个问号。然后信息在传递过程中肯定会有所损失，每个传递的节点能力越差损失得越多。
信息在每个人那里输入、输出时，因为知识、理解力、表达力等因素，多多少少都会发生变形，为了尽可能「保真」，必然的选择就是减少传递环节，也就是减少参与人数，尽最大可能让需求方的意愿直接变成符合需求的可用软件。
那设计和前端干嘛？要被裁了吗？！当然不是！虽然他们离业务比较远，业务研发流程基本不需要他们，但应用搭建体系的物料开发和维护需要他们啊！在这里，他们对团队的价值能够最大化。
总结
本文简单梳理了在纯 Web 开发或大前端结合 Web 服务的领域中一直以来大家为提效所做的各种尝试，并描绘了「产研一体化」在我脑中的轮廓。
目前主要是几个大厂以提效为目的在「产研一体化」方向进行探索，我在这个方向上也有了比较具体的有待尝试落地的想法，待日后慢慢道来。「反混沌」体系下的「Fxxk Design」和「Future.js」就是「产研一体化」这盘棋上的棋子。
「产研一体化」是中后台应用低代码化进程的一部分，也是前端工业化进程的一部分。