我做的第一个功能不是为普通用户，而是为拆车厂

U-PRO Build Journal（产品构建日记）— 第 3 期

第 2 期结尾留下了一个问题，是我完成多租户数据库迁移之后，完全没料到自己会问自己的问题：现在架构基础已经搭好了，接下来我到底应该先在它上面建什么？

我原本以为答案会很明显。U-PRO 是面向汽修厂的门店管理系统，那么最自然的第一步——任何一款通用库存工具都已经做过的那种——应该是类似"列出你的零件、搜索你的零件、追踪还剩多少库存"这样的功能。安全，符合预期，是那种没有人会问"等等，你为什么先做这个"的功能。

但那不是我做的东西。多租户架构落地之后，我发布的第一个分量十足的功能，针对的是这门生意里一个窄得多的细分领域：报废车辆入库（salvage vehicle intake），以及一套具体的方法，用来算清楚从一辆事故报废车上拆下来的每一个零件，到底值多少钱。如果你不在这个行业里，这大概听起来是一个古怪的、异常具体的起点。确实如此。而我从那里起步的原因，比任何市场调研本身能告诉我的都更能说明：真正会第一批来尝试一款新工具的人，到底是谁。

一个没人愿意解决的问题

拆车厂（salvage yard），或者兼营二手零件生意的修理厂，进货的方式跟普通零件零售商完全不一样。零售商买的是一件一件、单独计价的商品——这颗螺栓多少钱，这个滤芯多少钱，每一笔采购都有自己清清楚楚的价签。而拆车厂买的是整辆报废车，通常是一次性付一笔总价，然后必须把这一个数字拆分成几十甚至上百个零部件——发电机、一整套车门、还能用的变速箱、挡风玻璃——每一件最终都会单独出售，各自定价，等买家正好需要那一件零件的时候。

这就带来了一个真正棘手的会计问题，而大多数库存软件根本不碰它：如果你花一笔总价买下整辆车，里面任何一个零件的真实成本到底是多少？你不能瞎猜，也不能除了第一个卖出去的零件之外，其余全都记成"免费"或"零成本"——这种捷径会在你想看每个零件真实利润的那一刻，悄悄摧毁你毛利数字的准确性。你需要一种真正站得住脚的方法，把一笔采购成本，分摊到价值天差地别的一堆产出上——发动机和一面裂了的后视镜，获取成本显然不该一样，哪怕它们来自同一笔交易。

这在会计学上其实是个早有解法的问题——跟一家企业在一道生产工序用同一批原材料产出好几种不同产品时面对的问题是同一类：要决定这笔共同成本该分给每种产出多少。但通用库存软件懒得去解决它，因为买这类软件的企业大多没有这个问题。一家普通汽配店，进货就是一件一件、各自计价，它没有理由去问"我该怎么把这一笔采购拆成五十种不同的成本基础"。拆车厂却天天都在问这个问题，而据我所知，做这个领域软件的人，没有一个真正给出过实际答案。这个空白，正是 U-PRO 第一个分量十足的功能要去填补的。

这个功能到底做了什么

我最终实现的机制，是正式名称叫做相对销售价值法（relative sales value method）的一个版本——一种会计方法，按每一项产出相对于其他产出的价值高低，把一笔共同成本分摊到多项产出上，而不是随意地平均分配。分摊跟着价值走，不是靠猜，更不是那种只因为发动机和后视镜来自同一辆车，就荒谬地给它们分配相同获取成本的平均分法。

要把这套逻辑做对，不只是写一个计算公式那么简单。真实的报废车入库流程，不会像教科书例子那样干净利落。一辆车进来，一次性完整登记完毕，所有能卖的零件一开始就全部确定、后续再也不用重新分类——这种情况更接近例外，而不是常态。这个功能必须应对那个流程更混乱、更真实的版本，而不只是演示时看起来漂亮的整洁版本。

把分摊算法落到具体数字上

值得用一个具体数字走一遍，因为"相对销售价值法"这个说法听起来，比它背后的思路本身要抽象得多。假设一辆报废车的零件，全部登记定价完之后，总共值 100 个单位的可售价值。光是发动机就可能占这 100 个单位里的 40 个，变速箱加上一套车身面板占掉剩下的大部分，还有几十个低价值的零碎——装饰件、小型传感器、一面裂了的后视镜——各自只占极小的一部分，凑齐剩下的份额。一个零件占总价值的比例是多少，它承担的采购成本比例就是多少：发动机背四成的成本，裂后视镜几乎不背什么成本。

真正让这件事难做的部分，不是算术——把一个数字按比例分给好几个零件，这件事本身并不难。更难的问题是，该怎么处理这样一个事实：报废车入库记录，几乎从来不会在创建那一刻就是最终版本。某个零件在有人凑近仔细检查后，发现入库时没看出来的损伤，被标记为不可售；某个零件在几天后被补录进记录里，因为有人抽出时间把车再翻查了一遍，把第一遍漏掉的东西登记进去。看起来最直接的做法，是每次目录变化时就把其他所有零件的分摊比例重新算一遍，因为作为分摊基础的"可售总价值"刚刚变了。但我刻意没有那样做。一辆车的总价值估算，会在真正开始拆解的那一刻被锁定——此后不管后面又补录或重新归类了多少个零件，这个总数都不能再改。每个零件的成本，只会在它被登记的那一刻，按这个已锁定的总值计算一次。锁定的估算值和实际拆车过程中更混乱的现实之间——比如某个零件最后发现完全没有价值、入库时谁都没预料到的情况、或者单纯的四舍五入——出现的任何差额，都不会被重新摊回给之前已经定过价（很可能也已经卖出去）的那些零件。它会在这辆车最终结清的时候，被车上最后剩下的那一项——废料价值——吸收掉。真正的工程投入，就花在这里：不是去写一个反复重算的循环，而是设计一套系统，让任何已经定过价的东西都永远不需要重新打开，同时账目最终依然能精确落在购车价格上。

为什么我先做了这个，而不是更显而易见的功能

我想在这件事的先后顺序上说实话，因为写在纸面上看，这是个奇怪的优先级选择。通用的库存追踪——搜索、数量统计、低库存提醒——是几乎每一个潜在客户都会立刻认出并期待的功能。而报废车成本分摊，是一个只对市场里一个特定细分群体有意义的功能，而且要把它做对，真的比做基础库存追踪复杂得多。

但我还是先做了它，理由跟功能规划理论关系不大，更多是关于一个尚未上线的极早期产品，真正需要什么：一个通用竞品无法轻易照搬的存在理由。基础库存追踪是入场门槛——每一款门店管理软件都已经做了某个版本，而把一个已有的东西做得稍微好一点，不足以让一个还在观望的店主，在年中就换掉现有工具。相反，一套有会计依据、能站得住脚的报废车零件成本核算方法，是我当时环顾这个市场，真的哪里都找不到的东西。这是一个窄得多的受众，但这群人有一个真实、具体、目前无人解决的问题，先解决它，让 U-PRO 有了可以拿出来说的东西，而不只是"别人做的我们也做，只是稍微好看一点"。

有一种早期产品思维认为，应该永远先为最大的目标受众而做，因为增长就在那里。我认为这个建议，对已经有一定信任基础和采用度可以依托的产品来说是对的。但对一个零客户、零口碑的产品来说，就不那么对了——这时候更紧迫的问题，不是"怎么触达最多的人"，而是"我能给第一个心存疑虑的客户看什么，是他在别处根本得不到的"。

这样做要付出什么代价

这一切都不是没有代价的，我也不想把优先做这个更难、更窄的功能，说成是一个明显正确、毫无缺点的决定。它确实花掉了真实的时间——按更常规的路线图，这些时间本该花在每个客户第一天就会用到的功能上，比如基础搜索和库存计数。每花一周在报废车分摊的会计逻辑上，就意味着有一周，那些对所有人都更有用的功能没有被造出来。

这笔交易，我是清醒地选的。这意味着有一段时间，U-PRO 是这样一款产品：一件窄的事情做得非常好，一大堆平常的事情还完全没做——在架构基础终于搭好之后的最初几周里，这是一个奇怪、失衡的处境。这种不平衡，只有在你确信这件窄的事情，在当下这个时间点，战略价值高于广度的时候，才说得通。我当时是有信心的，但信心不等于确定。我手里握着的，是一个赌注：一小群要求很高、有真实需求却没人服务的早期客户，在这么早的阶段，会比一个所有竞品都已经提供、只是稍微好一点的功能版本更重要。

同样的这种权衡——深度优先于广度，窄而难优先于宽而易——在产品成长过程中，我后来不止一次重新面对，也不总是带着第一次那样的信心。报废车功能，在给了产品一个真实存在理由这个意义上，回本了。但它也意味着其他一切都比原本该有的时间点更晚，而这笔权衡，很快就会变得无法再被忽视。

如果店主问"这跟我有什么关系"，我会怎么回答

如果你不做拆车厂生意，这一切听起来可能都跟你没关系，就基础版的 U-PRO 使用而言，也确实不必有关系。但我认为，这个功能为什么排在最前面，说明了一件即使你永远不会碰报废车分摊界面，也值得知道的事：它告诉你，这款产品是真正下功夫去解决哪一类问题，又是随便应付了哪一类问题。

任何一款库存工具都能告诉你库存快没了。但很少有工具能准确告诉你，仓库里躺着的某一个零件，获取成本到底是多少——尤其是当诚实的答案，需要真正的会计逻辑，而不是一个随手填的占位数字。这是大多数店主永远不会直接去看的小细节。但它恰恰也是决定这套系统最终展示给你的"每单利润"数字，到底是能信任的数字，还是那种看起来挺合理、却悄悄假设每个零件都是白来的、直到被证明不是这样的数字的那个细节。比起早早交付那些看得见的功能，却建立在一个我自己都知道是错的成本模型之上，我宁愿先把这件更难、更不显眼的事情做对，再让那些看得见的功能后续跟上。

一个窄功能，一个悬而未决的更大问题

报废车分摊解决了一个真实、具体的问题，针对一类真实、具体的客户。但它没有解决那个更基本得多的问题——不管是不是拆车厂，每一家店在真正用上这个产品的前五分钟内都会问：这东西跑得够快、够可靠吗，不会反而比它省下的时间还多花时间吧？这个问题不是靠任何单一功能能回答的，不管那个功能做得多好。它是靠围绕这个新架构，剩下的产品能被多快地建起来来回答的——而这份压力，正是塑造了紧接下来发生的一切。

---

这是 U-PRO Build Journal（产品构建日记）的第 3 期。第 2 期讲述了为什么选择把 U-PRO 建成共享数据库的多租户系统，而不是给每家店单独配置专属基础设施。第 4 期会接上这一期留下的线索：把这么专精的东西做出来需要真实的时间，而正是这份压力，推动了这个产品接下来在开发方式上的一次重大转变——第一次把真正的工程工作交给 AI 来做。