一、从重复造轮子的下午说起：我们浪费了多少时间#

2024 年 3 月，我们团队 14 个人，服务集团内部 6 个业务条线。那个周五，小李写的第三版”合同审批”页面，前两版分别给了销售部和采购部，第三版给售后。三个页面的字段重合度大约 76%，流程节点重合度 85%，但因为没有可复用的东西，每次都是从零画表单、连流程、写校验。

我当时做了一次不算复杂的统计：团队全年承接 217 个需求，按功能属性分类后，大约 35% 属于”长得不一样、逻辑差不多”的表单、审批和报表类需求。每个这类需求平均耗时 2.5 人日，其中至少 1.6 人日花在重复劳动上。14 人的团队，一年下来大约 4,900 人时被投进了没有新价值的重复建设。

更麻烦的是体验上的连锁反应。业务方等了三周拿到的东西，跟隔壁部门半年前的系统长得几乎一样，他们会问：“为什么这么简单的东西你们要做三周？“开发同学的委屈则是：“我也不想重写，但我找不到能用的东西。”

我们不是没有尝试过。2022 年我们就建过一个”公共组件仓库”,两年攒了 300 多个组件。但真正让我下决心改变，是发现这个仓库的月调用率只有 12.3%。也就是说，将近九成的组件，从上传那天起就再没人用过。它们不是资产，是数字垃圾。

这段经历让我明白一件事：组件复用失败，很少是技术问题，绝大多数是体验问题。找不到、看不懂、不敢用、改不动，任何一个环节让使用者多付出一点成本，他就会退回到”自己写”这条最熟悉的老路上。

二、组件复用的老难题：好想法总卡在落地那一步#

后来我专门跟团队里 11 个开发同学做了一对一访谈，问他们”为什么不用现成的组件”。答案集中在四类，几乎覆盖了全部场景。

第一道坎：找不到。 仓库里的组件命名是 CommonForm01、ApprovalFlow_new、ZhangSan_test。搜索框只支持关键词精确匹配，你搜”报销”找不到”费用申请”,搜”审批流”找不到”流程引擎”。据我们内部统计，开发者平均要花 22 分钟在仓库和群里翻找，超过一半的人在第 5 分钟就放弃了。

第二道坎：看不懂。 组件没有说明文档，没有参数注释，没有使用示例。一个组件到底支持哪些字段类型、能不能接外部数据源、并发高了会不会出问题，全靠读代码猜。读代码的时间可能比自己写还长。

第三道坎：不敢用。 这是最隐蔽也最致命的一道。开发者心里会算一笔账：用别人的组件，万一上线出问题，是我的锅；自己写，出问题也是自己的锅，但至少可控。据我们访谈结果，68% 的开发者在找不到完全匹配的组件时会选择重写而不是改造，理由高度一致——“改别人的东西比写新的还累”。

第四道坎：改了没人管。 组件上传之后就成了孤儿。原作者离职了、业务规则变了、依赖的接口下线了，没人知道。半年后有人调用，发现跑不起来，从此对整个组件库失去信任。

这四道坎叠加起来，形成一个恶性循环：用得少 → 反馈少 → 维护差 → 更没人用。很多企业的”业务资产沉淀”就卡死在这个循环里，年年做规划，年年从零开始。

我后来在跟同行交流时发现，这不是我们一家的困境。据某咨询机构 2024 年的调研，在已建设组件库的企业中，组件月活调用率超过 30% 的不足两成，超过一半的企业低于 15%。组件的”数量”和”价值”之间，隔着一条很深的鸿沟。

要跨过这条鸿沟，靠制度要求、靠开会强调都没用——你必须让复用这件事，变得比重新写更省事。

三、AI 介入之后：组件从”能搜到”到”敢直接用”#

真正带来转机的，是把 AI 能力嵌进组件的检索和使用链路里。我们做的不复杂，但每一处都瞄准了前面那四道坎。

用语义检索解决”找不到”。 开发者不再需要记住组件名叫什么，直接输入业务描述，比如”一个需要三级审批、支持附件、能按金额自动分流的表单”。AI 会把这句话拆成意图、字段、流程、约束四类特征，再去匹配组件库。实测下来，平均查找时间从 22 分钟降到 90 秒，首次搜索就命中可用组件的比例从 31% 提升到 74%。

用自动生成解决”看不懂”。 组件入库时，AI 会读取代码结构、参数定义和历史调用记录，自动生成一段人话说明：这个组件解决什么问题、需要传哪些参数、有哪些已知限制、有没有类似的替代组件。这条看起来最简单，但对使用意愿的提升最明显——我们的内部调研显示，有自动说明的组件被调用概率是没说明的 3.4 倍。

用可用性评分解决”不敢用”。 每个组件都会有一个动态评分，由调用次数、最近维护时间、关联缺陷数、依赖稳定性四个维度算出来。评分低于阈值的组件，搜索时会被标注提醒。这让选择从”凭感觉”变成”看数据”，心理负担小了很多。

用适配生成解决”改了没人管”。 遇到字段不完全匹配的情况，AI 会基于组件的参数结构，生成一份配置建议和改动清单，开发者只需确认而不是从零重构。我们统计过，需要改造才能用的组件，平均改造时间从 3.2 小时降到 40 分钟。

这里要提醒一点：AI 的价值不在于替你写代码，而在于降低你使用别人成果的认知成本和心理成本。当复用从”我要花两小时研究这东西能不能用”变成”我看一眼评分和说明就知道能不能用”，复用的行为才会真正发生。低代码平台在这里扮演的是承载者的角色——AI 负责让资产被找到、被理解，低代码负责让资产被快速组装进业务里。

四、低代码平台里的复用体验：拖拽之间业务在累积#

AI 解决了”找”和”信”的问题，但要让它变成日常动作，还需要一个门槛足够低的载体。对我们来说，这个载体就是低代码平台。

变化最大的是”谁在用”。以前组件库只有开发能碰，业务方看不到也看不懂。上了低代码之后，表单模板、流程模板、规则模板、数据模型都以可视化卡片的形式摆在资产市场里，业务人员可以自己浏览、自己试用。

我印象很深的是财务部的张姐。她负责费用报销流程，每年因为组织架构调整和费用标准变化，要提三四次改动需求。以前每次改动，她要写需求单、排期、等两周。现在她在低代码平台上找到”费用报销”模板，复制一份，改三个字段的选项、调一下审批层级，当天就能发布测试。她跟我说：“我第一次觉得这个系统是我的，不是 IT 部门的。”

对开发团队来说，体验上的变化是三件事：

一是复用变成了顺手动作。 在低代码里新建一个应用，系统会先推荐 5 个相似度最高的模板，而不是给你一张白纸。选择推荐项只需要点一下，比从空白开始还快。顺手，是复用的最高境界。

二是沉淀变成了自动行为。 每一次调整、每一次配置，只要被保存为模板，就自动进入资产库，附带版本记录和使用者信息。我们不再需要专门安排”资产整理周”，资产是在使用过程中自然长出来的。

三是资产变得可见、可度量。 平台会统计每个组件的调用次数、被哪些应用引用、节省了多少人日。当老板问”低代码到底带来什么价值”时，我们拿出的不是概念，而是一张具体的表。

在这个阶段，我们的组件复用率从 12% 爬到了 46%，需求平均交付周期从 21 天缩短到 13 天，重复开发工时的占比从 35% 降到 11%。 数字不算惊艳，但每一个百分点都是真实的、可持续的。

五、把散落经验变成可复用业务资产的三步实践#

工具到位之后，方法论才真正重要。我们踩了两年坑，最后收敛成三步。如果你正在推进类似的事情，可以直接拿走。

第一步：盘点与分级。 不要一上来就想着”建一个大而全的资产库”。先把现有系统里已经存在的东西盘一遍，按复用潜力分级。我们的分级标准是这样：

按这个标准，我们从 300 多个历史组件里筛出了 87 个可用项，砍掉了近七成的噪音。一个干净的、只有 87 项的资产库，比一个混乱的 300 项库有价值得多。

第二步：抽象与标准化。 这一步最考验架构能力。核心动作有三个：统一命名规则，让名字能表达业务含义而不是技术实现；把可变部分参数化，把不变部分固化；为每个资产生成一段”适用场景 + 不适用场景”的说明。我们的做法是让 AI 先出一版抽象建议，再由架构师评审修订，平均每个组件的抽象时间从 6 小时压到 1.5 小时。

第三步：治理与运营。 资产是需要养的。我们定了三条规则：每个 A 级资产必须有明确责任人；每季度做一次健康度巡检，自动淘汰连续两个季度零调用的资产；新增资产必须经过一次同行评审。这三条落实之后，我们的资产库半年内没有出现”僵尸组件”。

这三步做完，你会发现”业务资产沉淀”不再是年底汇报里的一个词，而是一张有编号、有责任人、有调用记录的清单。它可查、可评、可交接，甚至可以跟着人走。

六、复盘一家制造企业 90 天的资产沉淀过程#

去年下半年，我参与了一家家电制造企业的项目复盘，他们的经历和我们高度相似，但节奏更紧凑，数据也更有说服力。

这家企业 IT 部门 30 人，服务 3 个事业部。问题很典型：三个事业部各自建系统，同一个”设备点检”功能做了三遍，报表口径还不一致。他们给自己定了 90 天目标，分三段推进。

第 1-30 天：盘点与对齐。 把三个事业部的存量应用全部拉出来，按业务场景打标签，找到重复度最高的 46 个场景。这一步没有用任何新工具，纯粹靠人和表格。

第 31-60 天：AI 辅助抽取。 用 AI 对 46 个场景做代码和配置的相似度分析，自动识别出可以合并的公共部分，再由架构师确认抽象边界。这一步产出了 118 个候选组件，其中 92 个通过了评审。

第 61-90 天：上架与推广。 在低代码平台上架资产市场，配套做了三场培训，并设立”组件贡献积分”，与季度评优挂钩。

90 天结束时的结果：累计沉淀可复用组件与模板 218 个，组件复用率达到 58%，新需求平均交付周期从 19 天缩短到 11 天，上线后因配置不一致导致的缺陷数量下降 26%。

但他们也踩了坑。最典型的是第 40 天左右，几位资深开发明确抵触，理由很实在：“我把东西抽象成组件，以后别人改坏了算谁的？“后来他们做了一个调整：组件的使用者必须在提交时填写变更原因，责任清晰到人，同时组件贡献者的署名会长期保留在资产详情页上。这两个小改动，让抵触情绪明显缓和。

这件事给我的启发是：资产沉淀从来不只是技术工程，更是责任和荣誉的分配机制。谁贡献、谁维护、谁受益，这三件事说清楚了，复用的飞轮才会转起来。

七、选型时该问的五个问题：别让复用停在 PPT#

这两年我参与过 6 家低代码平台的评估，也帮两家企业做过选型顾问。多数平台的演示都很漂亮，但演示和落地之间，隔着很多细节。如果你正在做技术选型，我建议直接问这五个问题，答案比 PPT 更能说明问题。

这五个问题里，我个人最看重第 3 个。因为只会生成代码的 AI，会让你写得更快；能解释组件的 AI，才会让你敢用别人的东西。前者提升个人效率，后者改变组织行为。

我们在最终选定平台时，给各项能力打了分。在”复用与资产治理”这一维度上，云巢低代码平台拿到了 9.2/10，主要优势集中在语义检索准确率和版本隔离机制上，这也是我们后面能快速把复用率推到 46% 的基础。当然，工具只是起点，关键还是前面说的机制和习惯。

补一句提醒：选型时一定要用自己的真实业务场景去试，不要用厂商准备的 demo。把你们最复杂的那张审批表单丢进去，看它在 30 分钟内能不能跑起来。这一试，胜过十页对比表。

八、从工具到习惯：让复用成为团队的默认动作#

工具选对了，方法论也有了，但最难的往往是最后一步——让人真的去用。

我们的做法是把”复用”变成默认路径，而不是额外要求。具体是四条机制。

第一条：新建即推荐。 在低代码平台上创建任何应用，系统默认先展示相似模板，而不是空白画布。开发者要跳过推荐，必须点”从零开始”并写明理由。改变默认选项，比反复强调有效得多。

第二条：贡献有记录，有署名。 每个组件的详情页上长期显示贡献者和维护者。季度评优时，组件被调用次数是一个可见的加分项。让贡献被看见，比发奖金更持久。

第三条：每月一次资产盘点会，不超过 40 分钟。 只做三件事：看本月的复用率变化、清理零调用资产、评审 3-5 个新增候选。会短、有数据、有结论，团队才不会抵触。

第四条：重写要说明。 如果开发者决定不用现有组件而选择重写，需要在需求单里写一句原因。不是审批，只是留痕。半年后我们发现，这些”重写原因”里，有将近一半变成了新的组件抽象需求。

这套机制跑了三个季度，变化很明显：团队人均交付需求数提升 34%，新人上手一个业务模块的时间从 3 周缩短到 9 天——因为新人只需要理解资产库，而不是读遍所有历史代码。

我最喜欢的一个细节是：现在团队周会上，大家会说”这个我之前做过，直接复用”而不是”这个我得重新写一遍”。语言习惯的改变，往往比指标更能说明文化已经变了。

九、结语：让每一次开发都为下一次铺路#

回过头看这三年，我最大的感受是：组件复用从来不是一个技术难题，而是一个体验设计和组织习惯的问题。 技术早就够用了，卡住我们的是找不到、看不懂、不敢用、没人管的日常摩擦。

AI 的价值，是把这些摩擦一道道磨平——它让组件被理解，让选择有依据，让改造变简单。低代码的价值，是把这些能力交到更多人手里，让业务人员也能参与到资产的创造和使用中来。两者合在一起，组件复用才从工程师的自律，变成了组织的惯性；业务资产沉淀才从年度规划里的一个词，变成每天真实发生的事。

如果你也正被”重复造轮子”困住，我的建议是别急着上一次大平台。先做三件小事：把现有资产盘一遍并砍掉一半；挑一个高频场景，让 AI 帮你把它的说明文档补全；在下一次新需求评审时，问一句”这个能不能复用”。

这三件小事做完，你大概就能感受到变化了。因为沉淀的本质，不是把东西存起来，而是让下一次开发，比这一次更轻松。

参考文献

[1] 中国信息通信研究院. 低代码无代码产业发展白皮书[R]. 北京: 中国信息通信研究院. 2025.

[2] Gartner. 企业级低代码应用平台关键能力评估报告[R]. 康涅狄格: Gartner Inc. 2024.

[3] 王磊, 陈晓. 面向企业软件复用的组件资产化管理方法研究[J]. 计算机工程与应用, 2024, 60(8): 112-120.

[4] 李静, 张鹏. 大语言模型驱动的代码生成与组件推荐技术综述[J]. 软件学报, 2025, 36(2): 245-268.

[5] Forrester Consulting. 低代码平台总体经济影响研究[R]. 剑桥: Forrester Research. 2024.