软硬结合产品中，客户需求与产品规划割裂、组织过度依赖个人能力、应用场景差异大导致产品定义模糊……这些撕裂如何弥合？本文从真实案例出发，提炼出解耦、可复用性、沉淀过程资产三大核心原则，深入组织与产品的深层缝隙，找到系统微操的关键因素。

在上篇中提到，在AI与机器人为两个制高点的软硬结合产品趋势下，到底需要成为什么样的系统构建者？如何在这个软硬逻辑撕裂的泥潭里，找到可靠的据点？在这篇中，我会抛开宏观的叙事，深入到软硬结合的组织与产品的深层缝隙，找到这场系统微操的关键因素。

当客户需求与产品规划割裂，怎么做？

我们先来说说具体的例子。

我在实际工作中遇到一个情况。一家大型的物流企业正在使用我们的机械臂产品，并提出了一个新需求：要在我们的机器人管理OS平台中增加一个新功能：支持多台机器人根据现场后端IP地址进行调试、增加、删除功能，还需要增加数据看板实时显示机器人的现场的任务状态等。

这是一个对客户来说很有意义的功能，而且这是一大的物流企业客户，我们没有什么拒绝的理由。

但是，核心的问题在这里：客户的需求与我们规划的产品功能并不一致。

首先，这个机器人管理的功能我们是在规划中的，但是，我们希望做的是另一个路线：不依赖于现场的具体环境和部署情况，而是管理属性更强，现场环境依赖更少，且看板的功能更多地分散在机器人的状态里。

如果按客户的需求做，就意味着与产品规划割裂，需要推翻重来，如果不做，就是真实的客户和利益损失。

更重要的是，开发人员在之前的项目中已经经历过多次推翻重做的情况，有隐性的抗拒心理。

我在工作中也发现，这是经常会存在，且经常让企业头疼的问题。要生存，就意味着妥协长期的产品发展，要平台化，就意味着真实的现金流损失。

我在那时的思考并确立的原则是：必须做非常规的版本切分。这种切分所用的原则，我愿称之为——解耦。

我的具体做法是，首先将客户的需求拆开，看看哪些符合我们的产品迭代要求？哪些不符合？符合的部分，先行以产品的规划做。但这部分并不能支撑我们产品自主迭代的需求。那我们就把未落实的功能用空壳（空的交互结构和空的代码结构）先占起来，作为产品的一个过渡版本。

先实现这个过渡版本的产品迭代更新，再在此基础上实现一个项目版本，做客户的附加需求。

这样做的好处是，最大程度避免了产品推倒重来，且最大化的避免了被客户需求牵着产品定义走的情况。后来，客户也提出了一些问题，但在这个解决框架下，已经是可控的，可规划的。

回到我们一开始的问题。这就是我认为，在软硬结合的撕裂中，需要确立的第一个的核心原则——解耦。

将阶段性的需求与长期的发展需求，将项目需求与产品需求解耦。但解耦不是分开这么简单，它解离的是产品规划必须与客户需求或者与产品迭代绑定的耦合。

解耦的重要性在于：它不仅体现在一个功能需求的迭代里和客户需求与产品需求的拉扯里，更体现在一个组织架构的布局里。

当产品过度依赖个人的能力支持，怎么做？

前面我们说，软硬结合时代，是从阵地战到系统战的迁移。而对于一个组织来说，其组织的路径固化解法，也在于解耦。

我接触过一家做传统软件算法的公司，他们是做视觉算法的，他们判断出了软硬结合的趋势，并希望给他们的软件算法能力，穿上一个硬件的外壳——成为机器人、无人机等智能硬件设备的供应商。这个生态位很像英伟达之于电脑整机厂商。

但不同的是，团队人员其实并没有硬件能力。本质上来说，这其实是一家公司在组织基因上向硬件的迈进。这其实不是一个招聘岗位的问题：因为如果招聘一个硬件大牛，必须面对一个问题，面对新产品，谁有决策权？谁能最终拍板方案？如果这个硬件大牛离职，对公司的业务的影响是很大的，这是一个组织结构性的问题。

我当时给出的提议是，招聘一个统筹型的产品经理，负责广维度的统筹，另外搭配一个深度考虑硬件开模、结构、散热等的硬件工程师，死磕硬件实现。

这个解法的核心原则就是解耦，为什么？

首先，它把一个硬件大牛，解耦为了一个广度统筹型的PM，和一个专业纵深的工程师。整个组织对单人的依赖大幅降低。这个统筹性PM和工程师的职责是可控的、可管理的，汇报层级是清晰可控的。假如任何其中一个人离职，都不至于出现项目停摆的局面。

这就是解耦的真实的威力——它不带来直接可见的收益或产品进展，但它带来产品可以产生和软硬结合的促成条件，并降低系统性风险。

当然，解耦能做的远不止这些。如果深入构建系统的细节，这两个岗位，其自身能力与岗位职责也可以进一步解耦。

怎么理解呢？

过去，我常常发现人员离职之后，带走了的大量的隐性的岗位信息，比如，汇报人是谁？产品踩过那些坑？产品这么做的理由是什么？这些隐性信息随着人员的离职，即便新人来到，也需要花很多的时间去了解，甚至有的关键信息已经销声匿迹了，而让它出现的，常常是再踩一遍坑。

所以，对于产品，对于组织，对于系统来说，都有必要——人员与岗位能力的解耦。产品的坑、权责关系都有必要定期记录以及整理归档，这是对于产品和系统来说宝贵但却很容易忽略的隐性资产。

这就是我所说的系统的内涵：系统不仅仅是产品这里的功能关系，更是影响这个产品发展的组织关系、权责结构。

上面提高的解耦，它的威力已经很大。其实，对于做好软硬迁移的系统，我还总结了很多其他的关键因素和考量指标。

当产品应用场景差异大，无法准确定义产品，怎么做？

这就是我想说的第二个原则——可复用性，而成长这个可复用性的关键方法，我称之为适度抽象。

工作之初，我负责的AR望远镜产品，在北京的通州、昌平的3座大公园中部署使用。但我当时面对一个问题：各公园对产品科普的内容不同、形式要求不同。我们几乎是每个项目重做一版，这个产品的自主迭代产生了很大的挑战，甚至——我们很难说清这个产品是什么，只能说出它的功能，它的形态这种描述性的，对系统性的产品很难定义。但这个问题一直留在我的脑海里，成为我面对新产品时思考的基础。

后来，我在一家车企里工作，他们在设计系统方面梳理的非常条理。Figma的设计系统体系是非常完善，随着组件、布局、变量token体系的丰富，足以在设计系统层面做的非常细致。我们搭建起组件库、图标库，并细致得引入变量之后，可以几乎实现横竖屏设计的分钟级别切换，而之前的手动调整，会是按天数的。我们有3个不同尺寸的车型适配，有至少10个功能模型，都靠建立的这套系统，将适配效率将原来的2-3个月的适配预估降低到了2-3个周基本完成。更重要的是，未来有新车型后，我们这要系统可以直接复用。

后来，我在机器人工作做机器人管理控制系统的交互框架时，就采用这个原则——复用。复用是系统构建的基础，这对系统构建来说是非常核心的原则。

我们的AMR机器人在当时至少需要应用于3个场景，搬运、辊涂、抛光。他们的场景操作流程差异非常大，搬运需要选点位，抛光需要设定参数。按理说，很容易就会进入AR望远镜产品被场景牵着走的泥潭。

但这时候，我已经带来过去踩坑的警觉，和对设计系统的秩序的敬意在思考问题的解法了。我首先按照搬运的逻辑梳理出了一个较为完备的流程，然后，我进行了一种反向操作——适度抽象：将具体的流程抽象为可扩展、可具体化的流程。

怎么适度抽象呢？我把场景的元素刨除，只留下一种结构关系。使用实质上就是3步骤：选一个点，再选一个点，设置，开始。整个交流流程依赖的其实就是这四个动作。而对于抛光、辊涂来说，它们同样也是有准备点位，目标点位，有设置。更验证这个思路是合理性的是：后来我们加入了建图功能，而整个交互框架其实是不需要变的，建图不影响选点，影响的只是选点的方式。

也就是说，这个框架虽然简单，但是可以扩展层级的，当加入地图选点的时候，其实是在这个交互框架下增加了一个抽象层级。

所以说，复用的基础是抽象，但抽象是需要适度的抽象，抽象到能扩展出不同的形态，能丰富结构的框架，但不是抽象为一个无法发展的问题或结论。

当产品探索的过程容易白费力气，怎么做？

这就是我想说的第三个原则，我愿意称之为——沉淀过程资产。

这对于从0到1的产品来说，是非常有先见的意识和构建。

正常来说，我们做一个硬件产品，会要经历EVT、DVT、PVT等阶段，本质上是一种逐步测试，逐步验证，把控验证过程与成本的阶段规划，而前一阶段过程中产生的，会在下一阶段解决，逐步解决。

但我所说的过程资产，其实有所不同。之前，我们的一个智能硬件产品要参加展览，而产品还只有一个基本的概念，没有具体形态，甚至没有开模经验，且只有一个月的时间，不可能完成EVT、DVT、PVT等阶段。

我当时的解法是：首先，按照前面的“解耦”原则，单独把产品拉出一个展览的阶段性版本V0.1，但展览只用手板件来做，算是先行进入了EVT阶段，并且，建立一个敏捷沉淀库，把做手板件过程中的探索沉淀为资产，包括联系的厂商、我们的关键需求、加工的成果以及遇到的坑记录进敏捷沉淀库，吸收为V1.0产品的可复用基础，并且把里面的结构和布线先行按照V1.0版本设计，避免后续设计返工。这样做，产品保住了展览，又为产品的后续规划提供了可复性的基础。

过程资产沉淀的最大作用是，让探索的过程成为了标记的过程。它将探索的过程标记为路径，沉淀为方法，这让后续的产品迭代时，可以回过头来，在过去做过的路里寻找已有的方法和经验。它让产品探索起就在以一个构建系统的意识和方法去做。

当产品要修改其中一部分，就要改动大部分，怎么做？

其实，这里面也体现出了第四个系统构建的重要考量原则——可回撤性。

对于这个问题来说，最低成本的解决方案是在产品构建之初就纳入考量，而不是当问题出现后再应对。

这个问题其实衡量的是系统的固化成本。它衡量的是，如果我们这一步骤或某一部分这么做了，或者未来处于战略调整需要修改，未来推翻重做的可能性大不大，如果推翻重做，成本高不高，对系统的影响大不大？

其实前面的例子都有反应这一点。就比如机器人管理系统的客户需求，如果我们直接按照客户的需求在产品的版本上做，那么其他客户的需求、产品自主迭代的需求，回撤成本就会非常大。如果展览时直接把结构设计先应付一版本，甚至去开模，那么未来修改结构时，回撤的成本将会非常大。

这也反应出了之前的解耦、复用、沉淀过程资产的重要性。因为如果产品的版本结构解耦度低（如前面的机器人系统客户需求的例子）、沉淀了可复用的资产，那么在产品结构层面改动的成本就会大大降低。包括前面的组织架构（硬件大牛）的例子，说明的事组织架构层面的结构。

也就是说，可回撤性，不是一个具体方法，但是一个考量因素，它将未来可能的修改和调整纳入考量，思考当下的产品和组织的构建，从未降低未来出现问题的可能。

进化的本质，是做切分成小块逐个进化

让我们再回过头来看看那三把剑：底层逻辑对立、路径依赖、AI监管与伦理。

本质上，软硬结合的过程开始，其实是新形态产品从0-1的过程。但它比从0-1更加复杂的是，它不仅要建立新的产品形态和组织秩序，还要对抗旧的产品形态和组织秩序。而这个过程，只能是逐步尝试、寻找验证点、再徐徐展开的。这个过程中会有回撤，会有暂时的产品妥协，但也考验能否把握住产品的核心。

而解耦、复用、过程资产、可回撤，其实就是将一个复杂的组织和产品进行系统性的切分，将切分出来的相对安全的产品和组织部分逐个转化为新的产品和组织的过程。

但重要的是切分的方法，切分不是将可见的、大块的产品功能或组织能力切分，而是，在解耦式切分：小块仍然保持着旧有的关系，但先行迈进新形态、秩序中。

而AI监管和伦理，考验的是整个产品和组织，在未来以机器人和AI为重要影响的新的商业社会、新的伦理社会、新的经济社会下的融入性。

可以说，整个商业经济、社会秩序，也正在进行这样的一场变迁。而我们每一个产品人，都是这场变迁中的铺路石。

只是，这个变迁的沙漏，才刚刚落下几粒沙子。