写在前面：本专题讨论 FDE 进场后第一周几乎一定会撞上的那堵墙——客户的"存量系统"。所谓"存量",指的是客户现场已经在跑的 ERP/MES/HIS/CRM/数据仓库/各种接口、定时任务、Excel 报表、手工补数脚本、已经离职没人接手的中间件。这部分内容不是"理论",而是 FDE 在任何一家非初创企业做交付时的必修课:不搞懂存量,任何 AI 方案都是悬空楼阁;搞懂存量之后,大部分"AI 需求"会自动收缩成"集成 + 数据治理"问题。本专题所有方法、工具、口径都来自一线可复刻的工程实践,不杜撰任何公司机密。

59.1 为什么"搞懂存量"是 FDE 进场第一关

业界有个被反复印证的经验法则:AI 项目 70% 的工作量不在模型,而在数据接入与系统对接。这条法则的反面就是——FDE 进场第一周最常见的崩盘场景不是"客户需求不清",而是"FDE 以为客户有数据可用,真到现场发现数据被锁在一套 2008 年的 AS/400 里,只有一份每周一次的 CSV 导出,且字段名是中文拼音缩写"。这种"存量幻觉"是 AI 项目第一大杀手,其杀伤力甚至高于数据质量本身——因为质量差还能改,而你根本不知道数据在哪、怎么取、谁有权批,项目从第一天就死了。

把这件事讲透,需要理解"存量系统"在真实企业里的三个本质特征:

• 它是活的,而且活得比任何 CIO 都久。一家中型制造企业的核心 ERP 平均服役 12–18 年,远超 CIO 的平均任期(国内约 3–5 年)。意思是:现在管这套系统的人,通常不是当年建这套系统的人。文档残缺、口诀式知识、离职交接断层是常态,不是例外。
• 它是业务连续性的承重墙,动不得。AI 项目想做"实时取数",但 ERP 的 DBA 会告诉你"这张表只能夜里 2 点跑全量,白天查会锁库"。AI 项目想做"接口对接",但 HIS 厂商会说"接口要报需求走流程,排期 8 个月"。客户 IT 团队的拒绝不是不配合,是在保护生产系统——FDE 必须先理解这种保护的合理性,再去找变通方案。
• 它是政治资产,不只是技术资产。一套系统背后往往牵涉一个部门、一个供应商、一个立项年份的政治格局。"想从 CRM 里取客户标签"——CRM 是市场部立项的,运维是 IT 部,数据归属归数据中台,标签口径归业务中台,四个部门四个 KPI。FDE 试图绕过任何一方,都会在某个评审会上被叫停。

一句话原则:FDE 进场第一周不是来"做 AI"的,是来"读懂这家公司的 IT 现状地图"的。这张地图没画清楚之前,任何模型选型都是空中楼阁。

这就是为什么 CDEF 方法论把 Context 勘探 阶段的第一项产出明确写成"现状架构图 + 数据资产盘点 + 痛点清单"——这三件东西本质都是 legacy 梳理的产物。本专题展开的就是这三件东西怎么做出来。

59.2 系统梳理的四板斧:架构访谈 / 文档挖掘 / 代码扫描 / 数据流追踪

FDE 在陌生现场做 legacy 梳理,通常会按下面四条线并行推进,每条线产出不同维度的证据,最后交叉验证。

59.2.1 架构访谈(structured interview)

访谈不是"和 IT 经理随便聊聊",而是结构化的 60–90 分钟一对一,目标明确:在一张白板上画出"这套系统从用户点击到最终落库经过几个组件"。访谈对象至少要覆盖四类角色:

角色	你想从他嘴里挖到什么	常见障碍
业务一线(操作员/客服/医生)	真实工作流、绕过系统的"民间流程"、痛点量化	不敢说系统坏话,怕得罪 IT
业务主管(部门经理)	KPI 与系统绑定关系、对"AI 能做什么"的真实期待、预算来源	期待虚高,把 AI 当万能锤
IT 运维/DBA	库结构、字段口径、性能红线、变更窗口、历史踩坑	防御性强,担心 AI 项目抢资源或搞挂生产
厂商实施/外包驻场	系统真实能力边界、可配置项、隐藏接口、原厂支持力度	利益绑定,可能夸大或缩小能力

访谈技巧上,FDE 必须养成几个习惯:先听 30 分钟再问——让人把系统历史讲完,很多"为什么这么设计"的根因会自然冒出来;追问数字——"慢"是没信息的,"日终批跑 4 小时,峰值 6 小时,夜里 11 点开始"才是信息;画图同步确认——边听边在白板或 draw.io 上画,每画完一段就问"是这样吗",被纠正三次以上的图,才是接近真相的图;录音+逐字稿——访谈后 24 小时内整理成结构化笔记,人脑对架构细节的遗忘曲线在 48 小时后会丢掉 60% 以上。

一线铁律:访谈到的架构 ≠ 真实的架构。每个人只看到自己负责的那一段,真实链路一定是多方说法拼出来的,而且永远会有"没人知道为什么这么连"的环节。

59.2.2 文档挖掘(document archaeology)

任何一家服役 5 年以上的系统都会沉淀出一堆文档:需求规格书、设计说明书、接口文档、运维手册、变更记录、事故复盘、供应商交付物。问题不是"有没有",而是散落、版本错乱、过期、甚至自相矛盾。FDE 进场第一件事是把这些文档全部翻出来,而且要带着"考古"的心态——文档的版本演进史本身就是系统演化史。

文档挖掘的实操路径有三条:IT 部门档案柜/SharePoint——通常是立项书、合同、验收报告、年度运维总结;供应商交付包——原厂设计文档、二次开发说明、接口契约(注意原厂文档的版本号要和现场版本对齐,差一个大版本就可能完全失效);运维工单系统/Confluence/wiki——这里藏着最珍贵的东西:事故复盘。一次"2021 年 7 月那条订单接口为什么改成异步"的复盘,比任何设计文档都更接近真相。

挖掘时要做三件事:建一个版本时间线(把所有文档按立项时间排序,看出系统的演化节奏);标注可信度(原始设计文档可信度高,二次开发的 PPT 可信度低,口述补的文档要打问号);建立"文档-代码-现场"三方对照——任何一条关键结论,必须能在三方中至少两方找到佐证,否则标注为"存疑待核"。

59.2.3 代码扫描(codebase recon)

FDE 不一定要读全部代码,但必须有"代码侦察"的能力。对一套客户自研或二次开发的系统,FDE 通常会用以下工具链做静态扫描,而不需要把整个仓库 clone 下来逐行读:

• 依赖与结构扫描:tree / ls + 语言对应的依赖文件(pom.xml / package.json / requirements.txt / go.mod)快速摸清技术栈;用 grep -rn "TODO\|FIXME\|@deprecated" --include=*.java 找出技术债集中点;用 SonarQube / CodeQL 做静态分析拿到复杂度、重复率、坏味道热点。
• 接口发现:grep -rn "@RequestMapping\|@GetMapping\|@PostMapping\|app.route\|@app\." 一把抓出所有对外暴露的 HTTP 接口;对 RPC 系统则扫 .proto / thrift IDL 文件;对消息驱动系统扫 topic/queue 订阅配置。
• 数据访问层扫描:扫所有 @Table / @Entity / Mapper.xml / ORM 模型定义,反推出真实的库表结构,这往往比 DBA 给你的"数据库设计文档"更准——因为代码不会撒谎,文档会。
• 定时任务与批处理:grep -rn "@Scheduled\|cron\|@CronExpression" 或扫 Kettle / DataX / Airflow 配置,梳理出夜间批处理链路,这是"数据到底什么时候新鲜"的关键答案。
• 调用链追踪:如果客户已经接了 APM(SkyWalking / Pinpoint / Jaeger / Datadog),直接导出近 7 天的 trace 拓扑,这是最接近真实调用关系的图,远比任何文档准。

一线技巧:永远以"代码 + APM trace"为最终事实来源,文档和人都是辅助。当访谈、文档、代码三方矛盾时,信代码。这条原则在 90% 的现场都成立。

59.2.4 数据流追踪(data lineage tracing)

数据流追踪回答的是"一个业务数字,从产生到出现在老板看的报表上,经过了哪些系统、哪些转换、哪些手工补数"。这是 legacy 梳理里最难、也最有价值的一环——因为它直接决定 AI 模型能不能拿到"对的数据"。

追踪一条数据流,FDE 通常从两端往中间挤:从源头——业务事件发生点(订单创建、患者挂号、设备上报),找到落库的第一张表;从消费端——最终报表 / 看板 / 模型训练集,反推字段来源。两端各画一张图,中间用 ETL 任务、消息队列、定时同步、视图、存储过程、Excel 手工导入串起来。每一段都要标注:数据新鲜度(实时/分钟级/小时级/日级)、转换逻辑(直接复制/聚合/过滤/计算)、可能的丢失点(全量覆盖/增量失效/字段重命名)。

工具上,如果客户有数据治理平台(Apache Atlas / DataHub / Amundsen / OpenLine),直接拉血缘图;没有就只能手工扫 ETL 脚本(Informatica / DataStage / Kettle / DataX / 自研 Python)和 SQL 视图。手工扫的时候,一个高频踩坑点是存储过程——很多老系统的核心转换逻辑都封在几百行的 PL/SQL 存储过程里,FDE 必须硬着头皮读,这是绕不开的。

59.3 画出现状架构图:四张图 + 一张痛点表

梳理的最终产出是可视化的现状架构,通常拆成四张图,各司其职:

图类型	表达什么	推荐工具	谁会看
系统全景图	一张图看清"客户有哪些系统、彼此什么关系"	draw.io / Lucidchart / Excalidraw	决策层、新进场同事
数据流图	关键业务数据从产生到消费的完整链路	dbt docs / DataHub / 手绘	数据团队、AI 团队
接口契约图	系统间调用的 API/消息/文件清单与时序	PlantUML 时序图 / Swagger UI	集成开发、运维
痛点热力图	在系统全景图上叠加红黄绿,标出性能/单点/合规风险	在全景图上叠色块	决策层、风险评审

系统全景图的画法有一套约定俗成的规范:外圈画业务域(订单域/客户域/生产域),中间画系统(ERP/CRM/MES/数据中台),系统之间用箭头标数据流向(实线=实时,虚线=批,双虚线=文件),系统下面画技术栈标签(Oracle 11g / Spring Boot 2.1 / Tomcat 7)。一张好的全景图,陌生人看 5 分钟就能说出"这家公司的 IT 大概长什么样"。

痛点热力图是 FDE 加分项。把访谈中收集到的痛点(慢、卡、宕机、口径对不上、合规风险)按系统标注上去,用红/黄/绿三色,旁边附一句根因。这张图在立项评审会上是核武器——决策层一眼就能看出"原来真正的瓶颈在订单接口而不是模型",而 FDE 据此可以把 AI 项目的范围合理收缩到真正高 ROI 的点上。

一句话原则:没有可视化现状图的 FDE,就是没有地图的旅行者。图没画出来之前,所有方案讨论都是在脑子里打架。

59.4 Legacy 系统的五种常见类型与差异化应对

实战中遇到的 legacy 系统大致可以归为五类,每类的应对策略完全不同,FDE 必须学会快速分类、对症下药。

59.4.1 老旧 ERP(用友/金蝶/SAP R3/Oracle EBS)

特征:服役 10 年以上,DBA 是唯一懂全貌的人,接口要么是厂商私有协议,要么根本没有,二次开发堆积如山,改一个字段要走变更委员会。应对:绝对不动核心表,所有数据访问走"旁路"——读副本库、读 T+1 的数据仓库快照、读每天凌晨导出的备份文件。需要写回时,绝不直接 update 业务表,而是通过 ERP 提供的标准 API(IDoc / BAPI / 用友 NC 的 EJB 接口 / 金蝶的 WebAPI)或走"中间表 + ERP 端轮询消费"的隔离模式。

59.4.2 无 API 的封闭系统(老旧 HIS/PACS/LIMS/工控 SCADA)

特征:厂商垄断,接口要钱要排期,有些根本是 C/S 客户端,数据库是商专数据库或加密 DBF。应对:三选一——(1) 数据库直连只读,绕过应用层直接读库,但要签数据安全承诺并限定只读账号;(2) 屏幕抓取/RPA,对 C/S 客户端用 UiPath / 影刀 RPA / 自研 Playwright 做界面级抓取,适合低频高价值数据;(3) 文件交换,很多老系统支持定时导出 CSV/XML/HL7,这是最稳的对接方式,代价是新鲜度差。

59.4.3 数据孤岛(Excel 邮件链/共享盘/部门自建小库)

特征:不是系统,是"半人工流程"——一线员工每周把系统数据导出成 Excel,在 Excel 里手工加工,再邮件发给主管,主管再汇总成报表。这是 AI 项目最容易踩的雷:你以为客户"有数据",其实数据活在 50 个版本不同的 Excel 里。应对:不要试图消灭 Excel(消灭不掉),而是找到每个 Excel 的"源头字段",把 AI 模型的数据接入点放在源头系统而不是 Excel。同时用低代码(简道云/钉钉宜搭/飞书多维表格)把高频手工流程数字化,逐步替代 Excel 链。

59.4.4 技术债堆积型(自研系统,没人接手)

特征:五年前某位已经离职的架构师自研的,代码没注释,文档是 PPT,部署在没人敢动的虚拟机上,重启就报警。应对:冻结而非重构。给这套系统画一个明确的"黑盒边界",只通过它的对外接口(库/文件/HTTP)做集成,绝对不要试图重构它的内部——重构这种系统的失败率超过 80%,而且一旦动出问题,FDE 是第一责任人。如果必须改,先做完整的回归测试集,在影子环境跑两周以上。

59.4.5 政治性僵尸系统(立项了没人用,但又不能下线)

特征:某位前领导立的项,花了几百万,业务一线从来不用,但 IT 不敢下线,每月还在烧服务器钱。这种系统在国企和大型集团里非常多。应对:绕开,不要碰。FDE 试图"激活"这种系统会被卷入政治。正确做法是在架构图上把它标灰、注明"低活跃/待评估",然后在 AI 项目范围里完全忽略它。如果决策层主动问起,再提供"是否下线"的 TCO 测算,让决策层自己决定。

59.5 数据资产盘点:四问与一张登记表

数据资产盘点的核心是回答四个问题,简称"数据四问":

1. 有哪些数据? —— 把所有库、表、文件、API、报表列成清单,按业务域归类。
2. 数据在哪? —— 物理位置(哪个库哪个 schema 哪台机器)、逻辑位置(哪个域哪个主题)、访问路径(谁能取、怎么取)。
3. 数据质量如何? —— 完整率、准确率、及时率、一致率、唯一率,每张关键表都要打分。
4. 口径是什么? —— 同一个"客户数",市场部、销售部、财务部各算各的,FDE 必须找出每个口径的算法并标注差异。

实操产出是一张数据资产登记表,字段建议如下:

字段	示例	说明
数据资产名	客户主数据	业务可读名称
物理来源	CRM.t_customer(Oracle)	库.表 / 文件路径
业务域	客户域	归类用
数据负责人	市场部张三 + IT 李四	双负责人制
新鲜度	T+1(每日 2:00 同步)	决定可用场景
体量	1200 万行,日均增 3000	容量评估
关键字段	customer_id, mobile, tag	模型关心的字段
质量评分	完整率 87% / 手机号有效率 92%	抽样实测
口径冲突	与销售部"活跃客户"差 15%	必须标注
敏感等级	L3(含个人识别信息)	合规分类
访问方式	只读账号 zhang_read	落地凭证

这张表是 AI 项目能否落地的硬通货。客户决策层看到这张表,通常会震惊于"原来我们有这么多数据资产从未被利用"或"原来同一条数据在三套系统里有三个口径"。FDE 据此推动数据治理前置——把口径对齐、质量提升作为 AI 项目的前置里程碑,而不是边做模型边等数据。

一线技巧:数据质量评分必须抽样实测,不能信客户自报。客户说"我们的客户数据很完整",FDE 现场抽样 500 条,发现手机号空值率 18%、地址字段 60% 是"详见备注"——这种事每周都在发生。100 条真实抽样 > 100 页需求文档,这条铁律在数据盘点阶段同样成立。

59.6 集成策略:五种通道与选型矩阵

搞清楚存量之后,FDE 要决定"AI 系统怎么和存量对接"。实战中只有五种通道,选型遵循一个清晰的矩阵。

集成通道	实时性	对存量侵入	实施成本	适用场景	主要风险
API 调用	实时	中(要存量暴露 API)	中	AI 推理实时回写、查询	存量接口能力不足
数据库直连	准实时	低(只读账号)	低	模型训练取数、批量推理	锁表、口径漂移、合规
CDC(变更数据捕获)	秒-分钟级	中(开 binlog/redo log)	中高	实时风控、实时推荐	源库性能压力、运维复杂
文件交换	T+1 / 小时级	极低	极低	老旧系统、跨网隔离场景	新鲜度差、格式漂移
消息队列	秒级	高(存量要发消息)	高	事件驱动、多消费端	存量改造成本高、消息顺序与幂等

CDC 是近年最热门也最微妙的通道。工具上有 Debezium(开源,基于 Kafka Connect)、Canal(阿里开源,MySQL binlog)、Maxwell、Oracle GoldenGate(商业)。CDC 的优势是对源库几乎零侵入(只读 binlog/redo log),能拿到真实的行级变更;但坑也深——源库是大流量 OLTP 时,CDC 会成为额外性能负载;DDL 变更(加字段、改类型)会让 CDC schema 失效;消息顺序和幂等性要消费端自己处理。CDC 不是银弹,只适合"实时性要求高 + 源库能扛 + 有 Kafka 基础设施"的场景。

文件交换看似原始,但在中国客户现场依然是最常见的对接方式,原因有三:跨网隔离(生产网与办公网物理隔离,只能摆渡文件)、合规审计(文件可留痕可审计,API 调用难追溯)、存量系统老旧(只支持定时导出)。FDE 不要看不起文件交换,它往往是唯一能在一周内跑通的方案。代价是新鲜度,要把"日终批跑完才有数"这个事实明确写进 SLA,避免业务方误以为是实时的。

选型上,FDE 通常按"实时性要求 → 存量侵入容忍度 → 预算"三步决策:实时性要求高且存量能改 → API;实时性要求高但存量不能改 → CDC;实时性要求不高 → 文件交换或数据库直连只读;事件驱动多消费 → 消息队列(通常配合 API/CDC 一起用)。实战中 80% 的场景是"文件交换 + 数据库直连只读"的组合,CDC 和 API 各占 10% 左右,纯消息队列驱动很少。

59.7 风险识别:四类红线与一张风险登记册

Legacy 梳理的产出除了架构图和数据资产表,还必须有一份风险登记册。风险分四类,每类都有典型的红线信号。

单点风险(SPOF):某个系统是整条链路的唯一通路,挂了全瘫。典型信号——所有数据都从一个 Oracle 主库取、所有外部调用都经过一个 ESB、所有报表都从一个数据仓库出。FDE 必须在风险登记册里标注"这个单点挂了,影响是什么、RTO(恢复时间目标)是多少、有没有降级方案"。

安全风险:数据在流转中被未授权访问、明文传输、弱密码、共享账号。老系统的安全问题往往触目惊心——一个 SQL Server 账号 sa 密码是 123456 已经跑了 8 年;一个 HIS 接口用 HTTP 明文传患者信息;一个 Excel 报表含全量身份证号邮件群发。FDE 发现这类问题后必须书面记录并升级,不能假装没看见,否则一旦出事 FDE 是连带责任人。

性能风险:存量系统已经在性能边缘,AI 系统一接就可能压垮。典型信号——日终批跑 6 小时已经在告警、核心表索引缺失查询 P99 已经 30 秒、API 网关 TPS 上限 50。FDE 必须给每个集成点做压力测试,确认"AI 系统上线后,存量系统的额外负载在可承受范围"。这一步漏做,就会出现"AI 上线第一天把 ERP 拖挂"的事故。

合规风险:数据跨境、个人信息保护、行业监管(医疗/金融/政务)。最容易被忽略的是数据出境——一家跨国集团的国内数据通过 SaaS 接口被海外服务器访问,这在《个人信息保护法》《数据安全法》框架下是高风险事件。FDE 必须在梳理阶段就把"数据物理位置、传输路径、存储位置、访问主体国籍"梳理清楚,并在风险登记册里标注合规等级。

风险登记册的格式建议:风险描述 / 类别 / 影响系统 / 概率 / 影响 / 缓解措施 / 责任人 / 状态。这份登记册不仅是 AI 项目的输入,也是给客户 IT 治理的礼物——很多客户第一次看到完整的风险登记册,会震惊于"原来我们一直坐在火山口上"。

59.8 用 AI 辅助理解 Legacy:代码理解 / 文档解析 / 架构推断

FDE 作为 AI 工程师,有一项特权:可以用 AI 工具加速 legacy 理解本身。这是 2024 年以后的新武器,用得好可以让梳理效率翻倍,用不好会引入"AI 幻觉编造的接口"这种新型坑。

代码理解:对一个陌生的代码仓库,把关键模块喂给代码大模型(Claude / GPT-4 / 国内的 DeepSeek-Coder、Qwen-Coder),让它做"这个函数做什么、这个接口的入参出参、这段 SQL 转换逻辑"的解读。工具上 GitHub Copilot Chat、Cursor、Cline(原 Claude Dev)、Continue.dev 都支持仓库级问答。注意点:绝对不要把生产代码原文上传到公有云 LLM,客户代码有保密和合规要求,必须用本地部署的模型(如 CodeGeeX 私有化、Qwen 本地推理)或签了 DPA 的企业版。

文档解析:客户文档常是 PDF/Word/扫描件,FDE 可以用 OCR(PaddleOCR / Tesseract / 商业 OCR)+ LLM 抽取结构化信息。典型用法——把 200 页的需求规格书喂进去,让它输出"所有接口清单 + 入参出参 + 调用方"的结构化表;把 5 年的事故复盘整理成"事故-根因-改进"的三列表。工具上 LlamaParse、Unstructured.io、Dify 的文档加载器都可用,但所有 LLM 抽取结果必须人工抽检,幻觉率在长文档上仍然不低。

架构推断:把 APM trace、调用日志、SQL 执行日志喂给 LLM,让它推断"调用热点、慢查询、潜在单点"。这是相对新的玩法,效果取决于日志质量。一个稳健的做法是让 LLM 做摘要和聚类,不要让它做最终判断——比如让 LLM 把 10000 条 trace 聚成 20 类、列出每类的特征,然后 FDE 自己判断哪类是风险点。LLM 在"看大量数据找模式"上强,在"做架构决策"上不可信。

口径对齐辅助:这是 AI 在 legacy 梳理里一个被低估的用法。把三个部门对"活跃客户"的三套 SQL 算法喂给 LLM,让它输出差异点、差异原因、可能的统一口径。这种任务 LLM 比人快,而且能找出人容易忽略的细节(比如一个用 last_login > 30 days,另一个用 last_login >= 30 days,差一天)。

一句话原则:AI 是 legacy 梳理的加速器,不是替代品。任何 AI 给出的结论,都必须能在代码、文档、现场三方之一找到佐证,否则不可信。

59.9 与客户 IT 团队的协作:他们最懂存量

Legacy 梳理中,FDE 最大的盟友是客户 IT 团队,最大的敌人也常常是 IT 团队。区别全在于 FDE 怎么开场。

把 IT 当老师,不要当障碍。IT 团队对存量的理解深度,FDE 永远赶不上——他们知道那张表为什么有空字段、那个接口为什么晚上 10 点会失败、那个存储过程是哪任 DBA 留下的雷。FDE 进场第一周,应该主动约 IT 喝茶、请教、画图给他们看请他们纠正,而不是上来就提"我们要从你们系统取数"。先建立"我是来理解你们、不是来给你们添麻烦的"信任,后面所有对接都会顺。

主动让出功劳,主动承担脏活。AI 项目上线后,功劳往往归 AI 团队,而 IT 团队承担了所有集成、运维、变更协调的脏活。FDE 要主动在汇报里写清"本项目成功依赖 IT 团队的 X、Y、Z 支持",主动把 IT 经理放进项目核心成员名单,主动帮 IT 解决一些他们积压已久的小问题(比如帮他们优化一条慢 SQL、帮他们写一个监控脚本)。这些"小投资"会在关键时刻(变更窗口排期、紧急资源申请、跨部门协调)回报十倍。

尊重变更流程,不要绕过。FDE 经常觉得 IT 的变更流程(申请-评审-测试-灰度-上线,平均 2-4 周)太慢,想"先在小范围跑跑看"。这是大忌。绕过变更流程一旦出事,FDE 会被立刻赶出现场,而且整个 AI 团队在公司层面失去信任。正确做法是把变更需求前置,在 Context 阶段就和 IT 一起规划好所有需要变更的点,排进他们的变更窗口。

留下一份比他们自己更全的架构图。FDE 梳理完 legacy 后,产出的架构图、数据资产表、风险登记册,要正式交付给客户 IT 团队。很多时候,FDE 画的图比 IT 自己的还全(因为 IT 每个人只看一段,FDE 是横向串起来的)。这份交付物是最好的"信任凭证"——下一次 FDE 再进场,IT 会主动配合。

59.10 输出物:现状梳理报告 + 集成方案

Context 勘探阶段的最终交付是两份文档,它们是 Design 阶段的直接输入。

现状梳理报告(30–60 页)的结构建议:执行摘要(1 页,给决策层看的)、系统全景与历史演化、四张架构图(全景/数据流/接口/痛点)、数据资产登记表与质量评估、风险登记册、关键发现与建议(3–5 条,每条带业务影响估算)。这份报告的读者是客户决策层 + IT + 业务方,所以语言要分层——执行摘要用人话,正文用工程语言,附录放原始数据。

集成方案(20–40 页)的结构建议:集成目标与范围(AI 系统要和哪些存量系统对接、对接什么数据)、集成通道选型(每个对接点选什么通道、为什么)、数据流转详图(每个数据流的源头、转换、落点、新鲜度、SLA)、接口契约(字段、类型、频率、限流、错误码)、安全与合规设计(账号、加密、脱敏、审计)、变更与回滚方案(对接失败时如何回滚不影响存量)、里程碑与依赖(每个对接点的交付时间与前置依赖)。

这两份文档有一个共同的硬要求:可追溯。每一条结论都要能追溯到访谈记录、文档原文、代码行号、APM trace 之中的至少一处。这是 CDEF 方法论对 Context 阶段的核心要求——没有可追溯性的梳理,等于没梳理。客户决策层在评审会上问"为什么这个接口要 CDC 而不是 API",FDE 必须能立刻调出对应的访谈段落、APM 数据、源库性能指标作为依据,而不是"凭经验"。

本专题小结

• FDE 进场第一周的核心任务不是"做 AI",而是读懂客户的存量系统。存量系统是活的、是承重墙、是政治资产,FDE 必须先理解它的合理性,再去找变通方案。70% 的 AI 项目工作量在数据接入与系统对接,搞不懂存量,任何模型都是空中楼阁。
• 梳理靠四板斧并行:架构访谈、文档挖掘、代码扫描、数据流追踪。其中代码 + APM trace 是最终事实来源,文档和人都是辅助,三方矛盾时信代码。
• 产出是四张图:系统全景图、数据流图、接口契约图、痛点热力图。痛点热力图是 FDE 的核武器,让决策层一眼看清真正的瓶颈在哪。
• Legacy 系统分五类差异化应对:老旧 ERP 走旁路、无 API 系统走数据库/RPA/文件、数据孤岛回到源头、技术债系统冻结而非重构、政治性僵尸系统绕开不碰。
• 数据资产盘点必须回答"有哪些/在哪/质量/口径"四问,产出一张数据资产登记表。质量评分必须抽样实测,不能信客户自报——100 条真实抽样 > 100 页需求文档。
• 集成策略五种通道:API、数据库直连、CDC、文件、消息队列。实战中 80% 是"文件交换 + 数据库只读"组合,CDC 和 API 各占 10%。文件交换不是落后,是合规与隔离场景下的最优解。
• 风险识别四类红线:单点、安全、性能、合规。发现安全合规问题必须书面记录并升级,假装没看见会让自己成为连带责任人。
• AI 工具能加速 legacy 理解(代码理解、文档解析、架构推断、口径对齐),但所有 AI 结论必须能在代码/文档/现场三方之一找到佐证,否则不可信。生产代码绝对不上传公有云 LLM。
• 与客户 IT 协作的核心是把他们当老师而非障碍:先理解后取数、让出功劳承担脏活、尊重变更流程、留下一份比他们自己更全的架构图。
• 最终交付两份文档:现状梳理报告 + 集成方案,共同硬要求是可追溯——每条结论都能追溯到访谈/文档/代码/trace 之一。这是 Context 阶段的核心验收标准。
• 最后一句话送给所有 FDE:进现场先当考古学家,别急着当魔术师。读懂存量的人,才有资格谈改造存量;读懂存量之后,你会发现一半的"AI 需求"自动消失了,剩下的一半才是真正值得做的。

本专题来源

• CDEF 方法论(Context 勘探 → Design 设计 → Engineer 工程 → Feedback 反馈)——本仓库《CDEF方法论》全文,Context 阶段产出"现状架构图 + 数据资产盘点 + 痛点清单"
• 《FDE 工程师完全指南》《FDE 作战指南》——本仓库相关章节关于进场第一周、客户现状勘探的实操指引
• 《FDE落地方案》系列(制造业 MES 对接、政务 12345 数据中台、金融风控 CDC 接入、医院 HIS 集成)——本仓库一线交付案例
• 业界关于 AI 项目失败率的公开研究:RAND Corporation(2024)《The Root Causes of Failure for Artificial Intelligence Projects》——数据/基础设施误判为五大根因之二
• 数据治理与血缘工具官方文档:Apache Atlas、LinkedIn DataHub、Amundsen、OpenLine、dbt docs
• CDC 工具官方文档与实践:Debezium、Alibaba Canal、Maxwell、Oracle GoldenGate
• 代码理解与静态分析工具:SonarQube、GitHub CodeQL、GitHub Copilot Chat、Cursor、Cline、Continue.dev、PaddleOCR、Unstructured.io、LlamaParse
• APM 与调用链追踪:Apache SkyWalking、Pinpoint、Jaeger、Datadog APM 官方文档
• 中华人民共和国法律法规:《个人信息保护法》《数据安全法》《网络安全法》——数据合规、个人信息保护、数据出境红线
• 一线 FDE/FDSE 驻场交付的真实场景:老旧 ERP 旁路集成、HIS 屏幕抓取、Excel 数据孤岛溯源、跨网文件摆渡、CDC 实时风控接入等公开实践(综合提炼,不涉客户机密)