企业 AI · FDE · 依赖管理
AI项目还没开始开发，就被硬件厂商卡住了
企业 AI 交付很少是一个团队关门写代码。接口、设备、数据和审批散在不同公司手里，依赖没人管，工期就只是愿望。
有位做 FDE 的朋友分享过一个学校项目。
软件要接现有硬件，开发团队需要设备文档和接口说明。问题是，客户与硬件厂商之间没有为这次项目建立正式协作，硬件方回复很慢。
于是很尴尬：模型还没调，业务流程也没跑，项目已经停在"等资料"。
这类事情在企业项目里太常见了。方案里一句"对接现有系统"，落到现场可能涉及三家公司、四个负责人和一份早已过期的文档。
FDE 会写接口，但不能凭空变出接口。交付能力里必须包含一件经常被低估的工作：管理上下游依赖。
依赖为什么总在启动后才暴露
售前阶段大家更愿意讨论功能。谁也不想在第一次会议上说"我们不确定能不能拿到设备协议""那个供应商已经两年没续维护"。
到了开发阶段，问题才逐个出现：
• 文档有，但版本和现场设备不一致。
• 接口存在，但需要另购授权。
• 测试环境可以用，生产环境还要安全审批。
• 数据能导出，却没有稳定的唯一标识。
• 第三方愿意配合，但没有承诺响应时间。
这些都不是偶发的小插曲。它们直接决定方案能否实现。
开工前，先画一张依赖地图
项目需要哪些外部条件，最好在报价前就摊开。
每项依赖至少写清：资源是什么、由谁提供、当前版本、最晚时间、验证方式、拿不到时怎么办。
不要只写"客户提供接口"。客户公司里谁负责？第三方是否同意？接口文档和测试账号能否在同一天拿到？没有名字和日期的依赖，等于没人负责。
五件东西，把等待变成可管理的风险
依赖清单记录所有外部系统、硬件、账号、数据和审批，不要只记技术接口。
接口契约写清字段、权限、调用限制、版本和错误返回。口头说"能对接"不能进入排期。
响应时限由相关方确认。没人承诺时间，就要在计划里标成高风险，不要伪装成确定进度。
替代方案可以是模拟接口、离线数据、人工导入或缩小第一阶段范围。它只用于继续验证已知部分，避免其他工作全部停下。
验收责任要说明谁确认硬件数据正确，谁确认软件处理正确，谁确认最终业务结果。服务方不能替设备厂商为传感器准确性背书。
合同里至少留三条
第一，客户或第三方未按时间提供依赖时，排期相应调整。
第二，接口版本、授权费用或设备范围发生变化时，双方重新评估工作量。
第三，替代方案能验证什么、不能验证什么，要写进验收条件。
这不是甩锅。恰恰因为责任可见，项目出现问题时才知道该修哪一段。
FDE 的价值，不是一个人扛下所有事
有些人把 FDE 想成能在现场解决一切的超级工程师。结果项目一堵，他既追供应商、又催客户、还要自己补模拟数据，最后所有风险都落到一个人身上。
更稳的做法是建立协作网络。业务负责人确认流程，IT 管理账号和接口，设备厂商解释硬件，安全人员决定边界，FDE 把这些条件接进同一份交付计划。
一个人可以推动问题，却不能替所有参与方作决定。
一份开工检查
在项目启动会结束前，确认下面几件事：
• 所有外部系统和硬件都有明确负责人。
• 文档版本与现场版本已经核对。
• 测试账号、样本数据和权限申请有日期。
• 第三方响应没有承诺时，计划中已经标红。
• 核心依赖拿不到时，有缩小范围或停止项目的条件。
如果这些答案大半是"回头问问"，项目还没准备好进入开发。
企业 AI 落地是一张协作网。代码只是网里的一部分。越早把依赖写出来，越少在交付末尾用加班替别人补合同。
素材来源：xiaomanhedy 在 X 上关于学校 AI 项目第三方硬件依赖的观察。本文在原帖基础上扩展了依赖管理清单。
完