从AI提示词到产品设计，底层逻辑惊人一致——真正的智慧在于抽象与复用。本文通过SaaS产品实战案例，揭示如何构建通用性、平台性和可复用性三大核心能力，带你跳出功能视野的桎梏，掌握从'做功能'到'建平台'的跃迁之道。那些合同引擎、工单系统中隐藏的设计哲学，正是破解技术债务的关键密码。
最近在给 AI 助手写提示词，写着写着突然愣住了。
我发现一件事：写提示词和做产品设计，底层逻辑居然是一样的。
你不可能给每个场景写一套独立的提示词，就像你不应该给每个需求写一套独立的代码。
真正好的提示词，是抽象出通用规则，再通过参数和上下文去适配具体场景。
产品设计也是。
这让我重新想起了一个我们做产品时经常忽视、但极其关键的命题——
通用性、平台性、可复用性。
你一定见过网上那种图。
一辆车，轮子是自行车的，车门用胶带粘的，排气管拿水管接的，发动机盖用绳子绑的。
看起来离谱，但它居然还能跑。
很多产品系统就是这辆车。
每接到一个需求，就往车上糊一个零件。能用就行，不管合不合适、配不配套。半年下来——
合同模块写了三套几乎一样的审批流程，每套型号还不一样。
支付对接了四家第三方，每家的代码结构完全不同，改一个要动四处。
前端同一个审批弹窗，三个业务线各写了一遍，样式还不统一。
新人接手项目，光理清“哪些功能是重复的”就花了两周。
代码越堆越高，补丁越来越多。系统还能跑，但没人敢动，也没人能说清它到底是怎么拼起来的。
这笔技术债不是某一方的锅，是产品和研发一起欠下的。
产品这边，设计阶段没有往“抽象”和“复用”的方向思考，只关注当前需求的完成度。
研发这边，拿到需求就埋头写代码，不主动识别已有的可复用模块，遇到相似功能宁愿复制粘贴也不愿做组件化。
两边都在赶路，谁也没停下来问一句——
这个东西，以后还会不会再做一遍？
我把产品设计的思维方式分成三层。
第一层，功能视野。
“把这个需求做完。”
大部分产品经理停在这一层。需求来了，画原型，写 PRD，交付开发。关注的是这个功能能不能用。
第二层，模块视野。
“这个功能和别的功能有什么关系？”
开始思考功能之间的关联，考虑数据流转、状态一致性、交互复用。关注的是这些功能能不能协同。
第三层，平台视野。
“这个能力能不能沉淀下来，服务于未来所有类似场景？”
这一层才是真正拉开段位的分水岭。关注的是这个能力能不能只建一次，用一百次。
我们要修炼的，就是从第一层往第三层跃迁。
下面用几个我们实际业务中的场景，聊聊这三个词到底怎么落地。
先说用户体系。
我们做的是 SaaS 产品，要对接不同的第三方系统和子系统。每个系统都有自己的用户标识——微信有 OpenID，ERP 有员工号，物业系统有业主编号。
如果每接一个系统就单独建一套用户，最后”张三”在系统里会变成三个人。积分对不上，账单对不上，通知发重了。
正确的做法是建立统一认证能力。
设计一个全局唯一识别字段（比如系统 UID），作为所有身份的”锚点”。其他系统的用户标识，都通过映射关系挂载到这个锚点上。
核心理念就八个字：一个身份，多处投射。
不管外部系统怎么变，我的用户只有一个。新接入一个第三方？加一条映射规则就行，不用新建一套用户体系。
再说合同。
我们的业务里有好几种合同：
看起来差异很大。
但拉远一点看——它们都是合同。
都有草拟、审批、签署、履约、变更、终止这样的生命周期。都需要管理合同主体、金额、条款、附件、到期提醒。
所以正确的做法不是给每种合同开发一套系统，而是先抽象出“合同中台”。
通用层负责：生命周期管理、审批流、模板、附件、提醒、归档。
差异层负责：通过”合同业务类型”字段驱动，不同类型加载不同的扩展字段和业务规则。租赁合同多一组”递增规则”字段，采购合同多一组”付款节点”字段。
未来新增广告合同、场地合同？配置扩展字段和规则就行，不用重新开发一个子系统。
还有积分体系。
积分是个典型的”看似简单、做起来容易耦合”的功能。
消费积分、签到积分、活动积分、推荐积分……如果所有积分的计算逻辑都写在一个服务里，这个服务很快就会变成一个巨大的”积分单体”，任何业务改动都可能引发连锁反应。
设计原则是解耦。
每个子系统只负责自己场景的积分计算，并通过标准接口暴露积分数据。总积分由平台层实时聚合。
三个关键设计：
今天加”停车积分”，明天加”缴费积分”，平台层的代码一行不用改。
做 B 端产品到一定阶段，你会发现一件事——
很多业务能力，本质上是同一套引擎的不同配置。
拿我们自己的场景来说：
工单引擎。
报修工单、巡检工单、投诉工单、派单工单，底层都是”创建→分派→处理→验收→归档”的状态机。不同的只是字段、分派规则和 SLA 要求。
如果每种工单单独开发，你在维护五套几乎一样的状态流转逻辑。
流程引擎。
合同审批、付款审批、减免审批、采购审批，底层都是”节点编排+条件分支+权限控制”。不同的只是审批节点的配置和触发条件。
报表引擎。
收费报表、欠费报表、能耗报表、经营报表，底层都是”数据源+聚合维度+展示模板”。不同的只是取数逻辑和展示方式。
引擎化的核心思路：把稳定的执行框架沉淀下来，业务侧只写“插件”。
就像汽车工厂——底盘和发动机是通用的，不同车型只是外壳和内饰的差异。
还有一个我感受特别深的场景：第三方对接。
我们的产品需要对接：支付（微信/支付宝/银联）、数电发票（百望/税控盘/第三方开票平台）、凭证（金蝶/用友/浪潮）、短信（阿里云/大汉三通/讯众通信）、智能设备（各品牌水电表厂商）……
不同客户要的第三方组合都不一样。
客户 A 用微信支付+百望开票+金蝶财务。客户 B 用银联支付+自建开票+用友财务。
如果每接一个客户就硬编码一套对接逻辑，代码库很快变成一锅粥。
正确的架构是可插拔式设计，分三层：
新接一个短信厂商？开发一个适配器，配置中心注册一下，系统不需要任何改动。
每个对接点 = 标准接口 + 适配器 + 配置项。
说完了架构层面的通用性和平台性，再说一个更日常、但同样重要的话题：前端和业务规则的可复用性。
一个审批结果弹窗，在合同审批、付款审批、减免审批三个页面都需要用到。
如果产品经理在写 PRD 时没有标注”这是同一个组件”，研发大概率会各写一遍。
不是因为懒，是因为不知道另一个人也在写同样的东西。
所以，可复用的页面、功能、弹窗，必须在 PRD 阶段显式标注。
具体怎么做：
这不只是研发的责任，产品经理在设计阶段就应该主动标注。
反过来，研发在技术评审时也应该主动提出：”这个组件之前做过，能不能复用？”
产品负责在 PRD 里画出复用的蓝图，研发负责在落地时守住复用的底线。两边都不能缺位。
业务规则也一样。
比如违约金计算，在物业、租赁、多种经营等多个业务线都要用。如果各自定义违约金规则，你会得到三套计算逻辑、三套配置界面、三套测试用例。
更好的做法是抽象出违约金计算引擎，支持”基数类型 × 周期类型 × 利率类型”的组合矩阵，覆盖各种业务场景。
业务侧只需要选参数，不需要写逻辑。
说到这里，可能有人要问了：是不是什么东西都要抽象？
当然不是。过度抽象和不抽象一样有害。
我自己总结了三条判断标准：
≥2 处使用，标注复用。
如果一个功能在设计阶段就能预见到两个及以上的使用场景，必须在 PRD 中标注为复用组件，定义好接口契约。成本低，收益高，没理由不做。
≥70% 重合，考虑抽象。
两个功能有七成以上的流程或字段重合度，就该认真评估是否合并为一个通用能力。差异部分通过配置或扩展承载。
≥3 个场景，推动引擎化。
一个能力被三个及以上的业务线需要，就不应该只是”复用代码”，而应该沉淀为独立引擎或中台，提供标准化的配置和接入方式。
同时，也要警惕四个坑：
坑一：需求驱动开发。 来一个需求做一个功能，不做横向对比。功能碎片化、逻辑重复、维护成本指数级增长。
坑二：过早抽象。 只有一个场景就急着做”中台”，抽象层不准确，反而增加复杂度，拖慢交付。
坑三：只抽象不治理。 做了通用能力，但没文档、没组件目录。团队不知道已经有了，继续造轮子。
坑四：配置爆炸。 为了极致的通用性加了几十个配置项，配置本身成了新的复杂度来源，没人搞得懂。
抽象是手段，不是目的。 目的是降低系统的整体复杂度，提高团队的长期效率。
回到最初的感受。
写提示词时我发现，最好的提示词不是把每一种情况都穷举出来，而是定义清楚原则和边界，让 AI 自己去适配具体场景。
做产品也是一样。
最好的产品设计不是把每一个需求都做成独立功能，而是抽象出通用能力，让业务自己去组合和配置。
这需要我们有意识地跳出”当下这个需求”的视角，往上看一层：
这个功能背后的本质能力是什么？
这个能力还有哪些相似场景可以复用？
未来有新场景接入，我现在的设计能不能零改动支持？
不能只是为了完成需求、达到预期，就头痛医头脚痛医脚。
产品经理的核心价值，不在于画了多少原型、写了多少 PRD，而在于——
能否用最少的功能设计，覆盖最多的业务场景。
先抽象共性，再外挂差异，最后通过配置驱动组合。
这就是从”做功能”到”建平台”的跃迁。
本文源于一次给 AI 写提示词的实践感悟，结合日常 B 端 SaaS 产品工作中的思考整理而成。如果你也在做平台型产品，欢迎交流。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。