澄川的资料核验项目交接完成之后，公司里另一个团队找上门来：仓储部门也想做类似的事——供应商到货资料的核验。他们听说采购那边"上了个 AI，效果不错"，希望直接把那套搬过来，最好下个月就能用。

这是 FDE 职业里最容易被误读的一类请求。"把成功的经验复制过来"听起来像纯收益：代码有了、规则有了、踩过的坑都有了，第二个项目应该是第一个项目的打折版。组织里也常有人这样推动——

平台团队希望沉淀"通用能力"，管理者希望一次投入多次回报，这些期待本身没错，错的是把"结构相似"直接当成"能力可复用"。

FDE 在这个时刻的产品判断：哪些经验应该沉淀成可复用的能力，哪些应该诚实地留在原地。

判断的骨架是四笔账——共同点、差异、投入、接收。四笔账都算过，答案自然浮出来；跳过任何一笔，复用就会从省钱的路径变成烧钱的路径。

一、复制一个流程，为什么不等于复用成功

先看一个最简化的推理错在哪里：采购资料核验做成了，仓储也是资料核验，所以仓储能直接用。

这个推理跳过了最重要的一环：第一个项目成功的原因，未必是那套代码和规则，而可能是项目里那些不再出现的条件——采购团队的资料管理员愿意每天配合复核、供应商的资料格式相对稳定、业务主管对判据有清楚的直觉。第二个项目里，这些条件一个都不保证存在。FDE 组织研究里那句话说得很准：第二个业务单位接入时，要验证通用规则是否仍然成立，再决定是否产品化。

"成功原因不可复制"还有一个实务上的麻烦：第一个项目的团队往往说不清自己为什么成功。问他们，答案是"规则梳理得细"或者"用户配合"——这些是叙事，不是归因。真要为复用做准备，得回到第 15 篇的判据和第 20 篇的价值账去看：哪些改善有数据支撑、支撑它的条件是什么。说不清成功原因就急着复制，复制的是自己以为的原因，两边的系统一样了，结果还是不一样。

第一个项目的成功标准是"采购资料核验质量达标"，这个标准里不含"可以被复用"。

为了复用，第一个项目里的一些东西可能要重做——把硬编码的规则抽成配置、把和采购系统绑死的接口改成可适配、把散在代码里的判据显性化。这些工作第一个项目不需要做，复用的账里却必须算。

也要看到另一面：不是所有差异都值得单独实现。如果两个场景 80% 的判断逻辑相同、只有确认角色和个别规则不同，为那 20% 从零建一套，同样是浪费。

复用判断的价值就在两头都防：既防止高估共性、把不兼容的东西硬塞进共用资产；也防止低估共性、把本该共享的东西各写一遍。

两头防住之后，正确的姿态既不是热情的"都能复用"，也不是防御性的"都要重做"，而是逐项过堂——这正是接下来两节的动作。

二、先比较新旧业务的共同点与差异

落到操作上，第一张表是差异单。把两个场景沿同一条轴拆开看。

两边核验的都是"资料"，但对象不同——采购核验的是供应商资质资料，仓储核验的是到货单证。资料类型清单要重新列；字段结构有一部分重合（文件、来源、日期），有一部分完全不同（到货单有批次和数量，资质资料没有）。这一层的结论是：数据模型的结构可沿用，字段配置要重做。

原核验里有一条规则是"设备用途必须与采购申请一致"。搬到仓储，这条规则失效——仓储没有采购申请这个参照物，它的对应规则是"到货数量必须与入库计划一致"。看起来都是"两个字段要一致"，但参照对象、数据来源、失效后果全部不同。相似字段不代表同一规则，这是差异单里最值钱的一行。

采购侧的确认角色是资料管理员（第 23 篇那张授权矩阵），仓储侧应该是收货组。确认角色变了，第 17 篇的权限矩阵整行要换；更深一层，确认的判据也变了——资料管理员判断"资质是否齐全"，收货组判断"单证与实物是否相符"，第 15 篇的质量判据要按新任务重写。

原系统的异常主要是资料缺页和格式问题；仓储场景多出一类高频异常——单证齐但货不对。这类异常的处置路径（暂停收货？联系司机？）在原系统里根本不存在。异常清单要重新收集，不能沿用。

四个维度过完，差异单的结论大概是这样：

流程结构（接收—核验—确认—回写）可沿用，判断规则基本不可复制，身份和异常要重做。

这个结论先于任何"能不能复用"的判断——差异单回答"差多少"，不回答"值不值"，值不值是下一节的账。

差异单的填写有个纪律：每一行差异都要注明证据来源。而证据不会自己上门——填单前要对仓储那边做一轮小型调查，动作和第 04 篇初始调查同构：看一次真实的收货核验（不是听介绍，是跟一次现场）、要一份近期的异常记录、访谈确认角色每天实际怎么判断。跳过这轮调查直接填单，填出来的不是差异单，是想象单。

每一行差异都要注明证据来源。写"仓储确认角色是收货组"，依据是什么——访谈了仓储主管？看了他们的作业指导书？还是推测？推测的行要在复用评审时当场验证。差异单不是文档作业，是证据作业。

三、决定抽取、配置还是继续定制

三档：抽取成共用能力、做成可配置的参数、或者承认这就是场景特例、单独实现。

判断某一处该进哪一档，问题不是"技术上能不能抽"，而是"抽出来的东西有没有第二个使用者，以及使用者变了之后谁改"。

以澄川这条链为例：文件解析和字段抽取的通用部分可以抽取——两边的输入都是扫描件，抽取逻辑与业务无关。

核验规则的框架可以配置化——"字段 A 与参照物 B 一致"这个模式两边共用，但 A、B 是什么是参数；而"设备用途与采购申请一致"这条具体规则就该留在采购场景里——它只服务一个场景，抽出去只会让平台里多一条没人敢动的历史逻辑。判断的证据不需要什么高深方法：问一句"除了这里，谁还会用到它"。答得出具体使用者的，进前两档；答不出或者答案含糊的"以后说不定用得上"，一律按场景特例处理。"以后说不定"是抽取决策里最贵的一句话，它的真实含义通常只是"现在不想做决定"。

这个分档的动作，本质上是 FDE 在替组织做产品判断：什么进平台、什么留在项目。FDE 研究里那个最小组织的分工在这里生效——平台资产负责人可以拒绝把仅适用于单个项目的逻辑放进共用平台，但必须给出判断理由与替代保存位置。拒绝要给出路，否则项目方的本能就是把所有东西都往平台里塞，塞进去就没人管。

有些差异小到不值得任何动作——两边资料类型名称的显示格式不同，让配置里存一个显示模板就够了，为它开一个评审会是浪费。分档的目的是把注意力花在真正影响复用成败的地方，不是把每个差异都仪式化。

一个时间维度：今天的"场景特例"可能是明年的"共用能力"。

第一次遇到某类逻辑，留在项目里；第三次遇到，共性有了证据，重新评估要不要抽取。反过来也成立：抽早了比抽晚了更贵——为两个场景抽的公共层，第三个场景来了发现接不上，公共层要返工，两边使用方还要陪着回归。抽取的时机判断和第 20 篇的口径判断是同一种功夫：宁可晚一点有把握，不要早一点好看。

四、把适配、回归与维护算进投入

复用值不值，最后一道工序是算账。这张账最常见的算错方式，是只算"省了多少"，不算"花了多少"——具体说，漏掉理解和维护这两笔。

澄川这笔账（工时为估算示例，不是实际记录）：

重做：如果仓储从零实现，假设估算为 50 小时。这是用于比较的基线，并非真实项目工时。

复用也不是零，而是一组假设估算：

在这些假设下，复用的首年投入合计为 34 小时。采购侧必须回归，是因为复用改变的是共用资产。

对比：理论节省 16 小时，约 32%。省了，但没有"复制粘贴"这个词暗示的那么省。而且这 16 小时建立在"估"上——理解存量这一项尤其容易失准，第一眼以为 4 小时读懂的系统，读进去发现规则散落在代码、文档和老员工脑子里，实际可能翻倍。账要按区间记，不要按点记。

FDE 研究的复用考核设计里有一条要求把这笔账框死：

复用节省的是净投入，应扣除理解、配置、修复与维护成本。只报告"复用了、省了"而不报告扣减项，是复用汇报里最常见的注水。

这笔账对管理者的用法也要说清：32% 的节省要不要做，不是 FDE 替管理者回答的。账的职责是把选择摆实——选项一：复用，省 16 小时但引入共用资产的长期维护责任；选项二：重做，多花 16 小时但两边独立演进互不牵连。

组织规模小、场景还在快速变化时，"重复建设"有时是正确的选择，两条独立实现各自迭代三个月后哪条跑得更好，本身也是信息。

第 22 篇的老规矩在这里第三次生效：FDE 摆选项，结论栏留给有权的人。

把这笔账摆成表还有一个附带的好处：它逼着估算的人把"复用"拆成看得见的动作。写"复用，约 34 小时"是一句话；写"理解 4、适配 12、回归 8、交接 4、维护 6"是五项工作，每项都可以追问依据、都可以在实际发生后回填比对。估算表因此也是复盘表——项目结束时把实际数填回去，下次的估算才有校准的锚点。

第一问：如果复用后采购侧要改规则，改动会波及仓储侧吗？

波及，说明两边的耦合已经形成，维护责任表要写清楚共用部分谁签字放行——第 19 篇的 owner 机制从单系统扩展到了共用资产。

第二问：如果半年后第三个场景来了，这份账怎么更新？

第三次的理解成本应该低于第二次（说明抽取真的沉淀了能力），如果三次的理解成本持平，说明抽出来的东西可读性不足，复用没有真正发生，只是复制了三份困惑。

账算完、代码搬完，复用还有最后一关：资产要有接收人。这一关失败的样子很典型——平台仓库里躺着一个"通用核验组件"，没有文档说明适用条件，没有指定的维护人，两个使用方各自改了自己那份副本，半年后仓库里的"原件"已经和任何一份运行中的代码都对不上了。资产从接收那天就开始腐烂。

资产接收要落到 FDE 那张资产接收单的骨架上：适用场景（什么样的核验任务可以套用）、不适用场景（什么条件下必须单独实现——差异单里的行直接翻译过来）、依赖项（平台版本、接口、字段）、验证方法（可重复运行的测试）、配置差异（哪些参数允许因场景变化）、接收人与维护人（写到具体角色）、下一次试用（指定实际项目，避免只归档不验证）、退役条件（无维护人、关键依赖失效或效果不可接受，就退役——退役不是失败，是资产池的代谢）。

最后一条"下一次试用"值得单独说：资产收录的验证不是归档那一刻完成的，是下一次真实使用完成的。没有指定下一次试用的资产，接收单写得再全也只是库存。

接收的动作也要和第 24 篇的交接一样过演练：仓储团队的工程师在 FDE 不代操作的前提下，用这个组件独立跑通一个最小任务——读一份样例资料、配一条自己的规则、跑一次核验。跑通了，接收才成立；跑不通，要么组件缺文档，要么抽取的抽象层不对，两种情况都比"归档后三个月才发现没人会用"便宜。

对 FDE 个人，这一篇的方法还多一层含义：你在一个项目里沉淀的判断——什么时候分类讨论、什么时候算账、什么时候拒绝——比代码更可复用。这套判断的可迁移性，靠的不是记忆，是每篇这些卡片本身：差异单、估算表、资产接收单。工具留下来了，方法就留下来了。

先破"复制即复用"的错觉，用差异单把共同点和差异摆开，按抽取/配置/定制三档分配每处差异，把理解、适配、回归、交接、维护五项算进复用的成本，最后让资产带着接收人和退役条件入库。

复用的价值不在资产数量，在这条链有没有走完。

迁移练习留给你：用 Field RFC 的格式写一份复用建议（本指南对这一格式的改编，不冒称任何厂商的内部标准），五个字段——现场问题（要解决什么）、共性证据（至少两个场景的同类需求）、范围（这次抽什么、不抽什么）、维护人（谁签字放行共用部分的变更）、不适用条件（什么样的场景别用它）。五个字段里最难写的是最后那个"不适用条件"——写得出来，说明你真的知道这个能力的边界在哪。

下一篇换一个学习方向：不看你自己的项目，看别人的成功案例——怎样从一个"某公司用 AI 提效三倍"的故事里，读出真正可迁移的方法。

一次经验怎样变成可复用能力：FDE的产品判断

架构师

人工智能

复用经验不等于复制代码：需先通过差异单核对数据、规则、权限、异常四层差异，再决定抽取、配置或定制，并算清理解、适配、回归、交接、维护五项成本。资产须明确适用条件、维护人与下次试用，否则会快速失效。判断核心是"谁能用、谁维护、何时退役"。

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

一次经验怎样变成可复用能力：FDE的产品判断

一次经验怎样变成可复用能力：FDE的产品判断

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐