如何让 AI 实现软件复用？
在软件开发中，我们常遇到这些问题：
- 同样的功能，在不同页面重复实现
- 修复一个 bug，要在多个地方改同样的代码
- 新人不知道有现成组件，又造了一遍轮子
- 公共组件更新后，不知道有哪些地方在用
很多人只把复用理解为“复制粘贴代码”或“复用封装好的构件”，其实软件复用可以分为两个层次：
1.源码级复用：复用已封装好的构件、函数、组件，直接调用、开箱即用。
2.设计级复用：复用成熟的处理机制、通用流程、设计模式、业务规则，在新场景复用“思路和框架”。
一个成熟的开发过程，必须同时支持源码级复用和设计级复用，才能真正降本增效、提升质量。
传统复用方式的痛点
- 复用知识分散在团队成员脑子里，源码级复用靠人记，设计级复用靠经验
- 没有集中、可搜索的清单，构件找不到、设计思路更难沉淀
- 代码评审时难以发现重复代码，也很难检查设计是否合理复用
- 新组件提取后、新设计沉淀后，没有及时登记和传播
AI的优势：同时支持两层复用
- 自动扫描项目，发现可复用的源码构件和设计模式/处理机制
- 开发前主动推荐可用组件，同时推荐适用的设计思路/成熟方案
- 评审时检查是否遗漏源码复用，也检查是否忽略设计复用
- 自动维护复用清单，同时沉淀构件资产和设计资产
我们做了什么：一个真实案例
项目背景
这是一个 Python Flask + 前端 JS 的全栈项目，包含：
- 多个功能页面（智能评审、需求生成、设置等）
- 已有多个公共组件，但没有系统整理
- 用户反馈：文档预览功能在不同页面实现不一致
我们的行动
- 提取统一的文档预览组件（源码级复用）
- 沉淀通用的文档预览处理机制（设计级复用）
- 建立复用清单，同时登记构件与设计方案
- 改造 AI 的工作流程（skill），支持两层复用
第一步：建立复用清单，同时沉淀两层资产
复用清单是 AI 实现复用的基础，既要登记源码构件，也要沉淀设计方案。
清单包含什么？
字段 | 说明 | 示例 |
资产类型 | 源码构件 / 设计方案 | 源码构件：DocPreview；设计方案：通用预览流程 |
名称 | 清晰命名 | DocPreview - 文档预览组件 / 通用文档预览处理机制 |
功能/思路 | 简要描述 | 提供统一预览界面 / 支持多格式、本地/远程文件预览 |
应用场景 | 适用范围 | 所有需预览文件的页面 / 各类文件预览类需求 |
解决痛点 | 消除的问题 | 避免重复编码、体验不一致 / 避免重复设计、逻辑混乱 |
位置/文档 | 路径或说明 | static/js/doc-preview.js / docs/design/preview-flow.md |
使用示例 | 代码或流程 | 见下文 / 标准流程步骤 |
首次引入 | 时间/版本 | 2026-06-01 |
清单结构
- 前端源码构件：文档预览、文件上传、Toast 提示
- 后端源码构件：Excel 格式化工具、通用校验模块
- 设计方案资产：通用预览流程、统一错误处理、权限校验机制
关键原则：
- 清单文件：REUSABLE_ASSETS.md（根目录）
- 同时收录源码构件和设计方案
- 构件给代码示例，设计给流程文档
- 新增资产第一时间更新清单
第二步：改造AI的工作流程，支持两层复用
改造 3 个核心 skill，让 AI 同时识别、推荐、校验源码复用和设计复用。
2.1改造「reusing skill」（复用提取）
原有问题：只支持提取源码组件，不支持登记设计方案
改造方案：新增双资产模式——提取源码构件、沉淀设计方案、统一登记
核心工作流：
- 模式判断：提取源码构件 / 沉淀设计方案 / 登记已有资产
- 源码模式：从重复代码提取公共组件
- 设计模式：从相似流程提炼通用处理机制、设计模式
- 登记模式：录入清单，完成兼容性验证
2.2改造「bug-fixer skill」（Bug修复）
原有问题：修复时只查源码组件，忽略设计复用
改造方案：新增双重复用检查
- 查复用清单：优先复用现有源码构件
- 查设计资产：优先复用成熟处理机制
- 界面/流程类Bug：优先复用对应源码组件+设计方案
2.3改造「update-backreview skill」（变更评审）
原有问题：评审只查代码重复，忽略设计重复
改造方案：强化双重复用校验
- 源码复用检查：是否使用现有公共组件
- 设计复用检查：是否复用成熟处理流程、设计模式
- 新增资产检查：新组件/新设计是否登记到清单
第三步：形成循环机制，两层复用常态化
开发前
- 开发者：要做文件预览功能
- AI：查复用清单 → 推荐 DocPreview 构件 + 通用预览设计方案
- AI：提供代码示例 + 流程说明
开发中
- 无适配资产 → 提取源码组件、沉淀设计方案
- 完成后 → 自动登记到复用清单
修复Bug
- 修复前 → 先查源码构件、再查设计方案
- 避免重复编码、重复设计
代码评审
- 检查是否复用源码构件
- 检查是否复用成熟设计机制
- 检查新增资产是否登记
实践成果
- 源码复用：消除不一致
- 之前：3个页面各自实现预览，代码重复、体验混乱
- 现在：统一用 DocPreview 组件，代码唯一、体验一致
- 设计复用：统一处理逻辑
- 沉淀“多格式文件预览”通用机制，新页面直接套用流程
- 避免重复设计、逻辑差异、Bug反复
- 资产清单完整
- 登记7个源码组件、3个通用设计方案
- 构件有代码、设计有文档，新人上手快
- 流程闭环
- 提取 → 沉淀 → 登记 → 推荐 → 评审，两层复用全闭环
文档预览组件使用示例（源码复用）
//方式1：路径预览
openDocPreview({
type:'path',
path:'/path/to/document.docx',
name:'需求文档.docx'
});
//方式2：本地文件预览
openDocPreview({
type:'file',
file:fileObject,
name:file.name
});
总结
核心要点
- 复用分两层：源码级复用（构件）+ 设计级复用（机制/模式），缺一不可
- 资产先沉淀：建立统一清单，同时收录源码构件和设计方案
- 流程要嵌入：复用检查融入开发、修复、评审全流程
- AI强执行：AI负责扫描、推荐、校验，人做最终决策
- 闭环才持久：提取→沉淀→登记→推荐→评审，循环迭代
软件复用不是简单“省代码”，而是省设计、省时间、提质量、降风险。支持两层复用，AI 才能真正帮团队把复用做到极致。