企业官网建设流程全解析

FDE岗位实务指南 · 第25篇

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

这是 FDE 职业里最容易被误读的一类请求。"把成功的经验复制过来"听起来像纯收益：代码有了、规则有了、踩过的坑都有了，第二个项目应该是第一个项目的打折版。组织里也常有人这样推动——平台团队希望沉淀"通用能力"，管理者希望一次投入多次回报，这些期待本身没错，错的是把"结构相似"直接当成"能力可复用"。

这一篇讲 FDE 在这个时刻的产品判断：哪些经验应该沉淀成可复用的能力，哪些应该诚实地留在原地。判断的骨架是四笔账——共同点、差异、投入、接收。四笔账都算过，答案自然浮出来；跳过任何一笔，复用就会从省钱的路径变成烧钱的路径。

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

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

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

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

还有一层更隐蔽的风险：第一个项目的成功标准是"采购资料核验质量达标"，这个标准里不含"可以被复用"。为了复用，第一个项目里的一些东西可能要重做——把硬编码的规则抽成配置、把和采购系统绑死的接口改成可适配、把散在代码里的判据显性化。这些工作第一个项目不需要做，复用的账里却必须算。

也要看到另一面：不是所有差异都值得单独实现。如果两个场景 80% 的判断逻辑相同、只有确认角色和个别规则不同，为那 20% 从零建一套，同样是浪费。复用判断的价值就在两头都防：既防止高估共性、把不兼容的东西硬塞进共用资产；也防止低估共性、把本该共享的东西各写一遍。两头防住之后，正确的姿态既不是热情的"都能复用"，也不是防御性的"都要重做"，而是逐项过堂——这正是接下来两节的动作。

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

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

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

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

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

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

四个维度过完，差异单的结论大概是这样：流程结构（接收—核验—确认—回写）可沿用，判断规则基本不可复制，身份和异常要重做。这个结论先于任何"能不能复用"的判断——差异单回答"差多少"，不回答"值不值"，值不值是下一节的账。

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

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

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

差异清楚之后，处理方式有三档：抽取成共用能力、做成可配置的参数、或者承认这就是场景特例、单独实现。

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

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

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

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

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

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

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

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

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

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

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

• 理解存量：4 小时，用于读懂原系统的结构和暗藏约定；

• 适配：12 小时，包含字段配置、规则重写和接口对齐；

• 回归：8 小时，确认改动没有破坏采购侧既有行为；

• 交接：4 小时，按第24篇的方式给仓储接收方做演练；

• 维护预留：6 小时/年，共用资产更新时需同时验证两个场景。

在这些假设下，复用的首年投入合计为 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 提效三倍"的故事里，读出真正可迁移的方法。