从定制到可复用：沉淀什么、不沉淀什么

复用不是把代码复制一遍，而是把下一次从零开始的时间提前买回来。

一、做了十个项目，还是从零开始

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

一位独立开发者做了五年外包，第十个项目结束时想复用一点东西。他打开硬盘，发现十个项目目录里有十份登录实现、八套部署脚本、五套发票导出逻辑，但没有一份可以直接交给下一个客户。

他试过把 A 客户的登录模块拷到 B 客户的项目里，花了两天才跑通，因为两边对「用户」的假设完全不同：一边一个账号绑一个手机号，另一边一个账号绑多个组织。最后他放弃了，重新写了一遍。

这不是技术能力问题。三个原因几乎每次都一样：

• 没有预留时间。 报价时按「做完功能」算工时，整理资产属于额外工作，永远排在下一单后面。
• 不敢脱敏。 代码里混着客户字段名、真实数据和内部地址，剥离比重写还麻烦。
• 误以为「下次会记得」。 不写 README、不写版本、不写适用条件，三个月后自己都看不懂。

重复劳动不是勤奋的证据，是资产没有沉淀的证据。 一个项目做十遍，收入是十份工时；一份资产用十次，才是复利的起点。

二、四类候选资产

不预设固定复用率。每次记录整理、适配、升级和返工工时，不能只算最初少写了多少代码。

三、先过授权与保密门槛

候选资产必须先完成四项检查，再讨论是否值得整理：

1. **权属与授权：**核对合同、职务成果、委托开发及第三方来源。自己写过代码不证明仍有再次复制、修改或授权的权利。
2. **合同与平台限制：**核对保密、接口使用及商业用途；另建私有仓库不能解除原合同限制。
3. **客户信息：**代码字段、文档、截图、内部地址和提交历史都可能泄密。优先使用合成样本；脱敏后仍可关联识别的数据不能当作匿名数据。
4. **第三方许可：**记录依赖名称、版本、许可证、组合及分发方式，以及是否有例外或另购许可。

任一项不清楚就先暂停复制、发布或向下一客户授权，回到合同核实或取得明确许可；明确不允许时不进入通用库。只有获准保留的通用方法记录，也要避免包含客户特有表达或秘密。

客户特有流程是否值得抽象是成本问题，能否抽取则先是权利问题。两个问题都通过，才进入下表。

四、准入后的复用收益评分

以下三项各 0–2 分、满分 6，只用于安排内部整理顺序。分档为本轮试验选择，不是行业基准。

本例用 5–6 分优先整理、3–4 分限时补短板、0–2 分只保留获准的决策记录；还需比较预计节省和整理维护成本。

反例验收：三项全是 2 分，但合同将相关权利给了客户，且没有复用许可，仍然不能进入资产库；边界不清也不能靠 6 分放行。获准复用的模块得 2+1+1=4 分，可以先限时补环境说明和测试，再决定抽取。

五、沉淀的时机与成本

可以先用 10% 和 15% 两档工时作为教学预算做比较，再按预计出现次数、适配和维护成本选自己的上限。若把整理列为客户付费项，应事先说明交付物和归属，不能擅自将自己的资产建设时间记成客户计费工时。

比抽代码更重要的是写 README。目标是让获得授权的使用者按记录复现运行；首次启动时间应包含依赖、账号和环境准备，不承诺统一的一分钟。 一份合格的 README 至少包含四项：

1. 三条命令：安装依赖、启动服务、跑测试。
2. 环境变量清单与示例值，绝不包含真实密钥。
3. 已知限制与不该使用的场景。
4. 许可证与归属说明，写清哪些部分来自客户项目。

可在验收后安排整理窗口，但不得因此扣留约定交付物或延误结算。先完成客户交接，再在允许的范围内整理通用资产；付款安排不创造复用权。

六、资产库怎么组织

一个能长期用下去的资产库，结构应该比代码本身更稳定。下面是一个可直接照搬的目录示例：

~/work/assets/
├── starters/
│   ├── web-saas-starter/
│   └── api-service-starter/
├── packages/
│   ├── billing-core/
│   └── auth-kit/
├── ops/
│   ├── deploy-vps/
│   └── backup-postgres/
├── docs/
│   ├── discovery-questions.md
│   └── handover-template.md
└── LICENSES/
    ├── proprietary.txt
    └── mit.txt

配套四条规则：

版本号遵循 SemVer ：破坏兼容升 MAJOR，加功能升 MINOR，修 bug 升 PATCH。给自己的包打 tag 之后，下一单引用固定版本，而不是永远跟着主分支跑。

git bundle 可用于离线交接，也可作为多副本备份的一部分；完整性取决于打包的 refs 和前置依赖，不能仅凭一个文件证明完整恢复。LFS 对象、子模块仓库、未提交文件、Issues 等托管元数据另行处理。将副本放在独立故障域，并在空目录演练分支和 tag 恢复，方法见代码与仓库 。公开新仓库前还要检查历史、密钥和曾删除的客户内容。

七、背景知识产权与许可清单

通用组件是否仍归你，需要合同、开发来源和权利链支持；不能仅凭“通用”二字保留权利。软件保护条例第11、13条分别涉及职务开发、委托开发的权属条件。签约时将已有组件与新增成果分别列明，再协商许可。

GPL 需要结合版本、例外和组合/分发事实判断：单独运行独立工具或仅作独立聚合，不等同于把 GPL 代码组成一个闭源程序；分发受 GPL 约束的组合程序可能触发相应源码及许可义务。AGPL 还需另查其网络交互条款。不能只凭“商业项目”就否定使用，也不能因拆目录或换进程就保证不受约束。

例如，客户更换维护商是否可用源码，应看维护许可；出售业务是否可继受背景组件许可，应看转让安排；发布含依赖的组合程序，应复核各许可；拿真实数据做演示则应另查合法依据和保密条件。可把这四项作为交接前的实际验收，不用一句“永久免费使用”替代全部条件。

八、行动清单

• 打开最近三个项目，各挑一个「下次还会用」的模块。
• 先核权属、合同、保密和第三方许可，未通过时暂停抽取。
• 给通过准入的候选按三项评分，并核对整理成本和下一次真实需求。
• 内部可按 starters / packages / ops / docs 分类，公开成果另建已清理历史的仓库。
• 给每个包打第一个版本 tag，并补 LICENSE。
• 记录自己的整理工时预算；客户付费整理须明确范围和权属。
• 检查现有合同是否区分背景 IP 与新增成果。
• 使用合成样本；误入客户信息时核查历史、副本、权限及必要的处置，不只删当前文件。

使用边界与实操验收

上文的工时预算与评分分档都是演示输入，不是行业基准。真实判断要用你自己的项目记录：同一类需求一年出现几次、每次真正省下多少小时。

复算示例：某单全部投入预算 240 小时，其中另行明确 12%、即 28.8 小时为资产整理。下一单实际节省为脚手架 16 小时、组件 10 小时、部署脚本 6 小时，合计 32 小时，净收益 3.2 小时。在未计适配和后续维护时，这笔时间投入在下一单回收并余 3.2 小时；若适配又花 6 小时，则尚差 2.8 小时。整理是否划算取决于后续净节省，不能仅靠一年两单或固定比例判断。

另一个容易忽略的成本是抽象错误。把一个只服务过两个客户的模块抽成「通用包」，第三次遇到不同假设时，你要么加开关，要么推翻重写。可先等更多不同场景暴露边界，再决定抽象；次数只能提醒复核，不能证明第二次或第三次一定合适。

关键参考与核验范围

下列官方资料只支持所标明的规则。案例、价格、评分与工时为教学假设，核验日期：2026-10-22。

• 计算机软件保护条例 ：第11、13条涉及职务及委托开发权属，第18条涉及许可合同，具体应核对事实与合同。
• GNU 许可证 FAQ ：区分聚合与组合程序、分发和许可义务，AGPL 的网络条款也需另查。
• 个人信息保护法 ：第4、21条等涉及可识别个人信息与委托处理；去掉姓名不自动匿名化。
• GitHub 仓库说明 ：仓库可见性与访问权限以托管平台实际能力为准。
• git bundle ：备份、离线传输及增量包的范围和前置依赖。
• 语义化版本 ：公共 API 版本规则，不代替授权或运行环境验证。

系列导航

• 上一篇：该拒的客户：坏客户的七个信号
• 下一篇：什么时候产品化：从项目到产品的三个条件
• 回到目录：一个人的服务生意：从接单、报价到产品化
• 相关阅读：共享底座 、知识产权归属