作者 / 来源：中智凯灵 / AiDD

——北京 AiDD 会后观察（3）：从场景探索、影子运行到业务自主运营

▼

做出一个能跑的 AI Demo，正在变得越来越容易。

但让它进入真实业务、面对复杂数据、经受持续评估，最后由业务团队稳定运营，仍然是企业 AI 落地最难跨越的一段路。

问题往往不在于某一个模型不够强，也不只是需求、开发或测试中的某个环节没有接上 AI。更深层的矛盾是：企业还在用传统软件项目的方式，管理一个充满概率性、涌现性和快速变化的新系统。

在第 10 届 AI+研发数字峰会（AiDD）北京站，阿尔法立方 CEO、AI 大模型落地实战专家李明宇以《FDE 落地三年：从行业实践探索到可复用方法论》为题，复盘了从 2023 年进入真实生产域，到 2024-2025 年以 FDE 推进多类项目，再到 2026 年延伸至 FDE for SE 的实践过程。

演讲最后，李明宇代表司南智能软件工程研究院（SIISE）发布《企业级 FDE 个人能力水平模型》V1.0，也把三年实践进一步落到人才评价与组织用人上。

三年实践留下的核心判断是：新设一个热门岗位远远不够。AI项目还需要新的现场角色、推进节奏、评估循环和组织机制，才能从原型走向稳定运营。

图 1：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：三年实践从现场沉淀出 FDE、3AD、EDD 与 Harness 四套方法（PPT 第6 页）

一、FDE 为什么要更早进入现场

大模型让企业项目的前提发生了变化：同一个任务可能存在多条可接受路径，模型和工具快速更新，AI 进入业务后还会反过来改变需求。需求、设计和验收，都要在真实使用中不断校准。

如果仍按“先把需求一次写完整，再依次设计、开发、测试、上线”的线性方式推进，团队很容易在真实数据和真实用户出现以后反复推倒重来。

FDE 正是在这样的现场中被需要。

它不是“驻场开发”的新名字。传统驻场开发往往在需求分析完成后承接实现；FDE 则更早进入现场，与业务人员、工程师和管理者共同定义问题，把业务意图转成 AI 可执行的任务，并一直走到验证、部署、反馈和持续升级。

图 2：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：FDE 的关键不是“人在现场”，而是决策、工程与反馈都贴近现场（PPT 第 11 页）

李明宇把 FDE 的能力概括为四点：深入现场、推动业务、全程落地和工程能力。这里尤其值得注意的是“全程”而不是“全栈”。AI 与软硬件技术仍在快速演进，一个人很难成为所有技术方向的专家；但 FDE 必须能够贯穿问题洞察、任务定义、实现验证、生产部署和运营反馈。

所以，FDE 首先是 Engineer，其次才谈咨询、沟通和组织推动。业务咨询、架构操盘、AI 驯化和监控运维，对应的是 FDE 在一条完整交付链上经常切换的四种视角。

二、PoC 的任务，不是证明“能做”，而是决定“要不要继续”

角色改变以后，项目推进方式也必须改变。

这套方法被概括为 3AD，即 Agile Agentic AI Development：价值驱动、业务共创、数据优先、小队作战、快速迭代。团队交付的，是可以在使用中生长的 AI 能力。

第一阶段的 PoC，也就不再是未来产品的缩小版。

一个漂亮的 Demo 可以展示模型会做什么，却不能回答企业更关心的几个问题：这个场景有没有足够高的业务价值？真实数据上的效果怎样？业务方是否愿意持续投入？数据和目标环境是否就绪？当 AI 犯错时，风险由谁发现、谁接管、怎样处置？

这些问题必须用逼近真实的样本来验证。样本既要有容易成功的正向情况，也要放入负向情况、边缘情况和脏数据；运行环境则要尽量接近企业最终可用的内网算力、模型选型、合规限制和系统接口。

业务 Owner 同样是 PoC 的必要条件。AI 项目需要有人对业务价值、数据协调、用户反馈和迭代优先级负责。如果没有真实 Owner，或者业务价值逻辑、数据准备和目标环境明显不成立，及时停止往往比继续做出一个更精致的原型更有价值。

PoC 结束时，团队应当形成一次更可信的 Go/No-Go 决策：什么值得继续，什么需要调整，什么应该尽早放弃。单纯的“技术可行”，回答不了这些问题。

图 3：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：PoC 同时验证业务价值、真实效果、数据环境、风险兜底与投入意愿（PPT 第 16 页）

三、周度迭代、按天拆解，把错误视为下一轮任务

进入正式交付后，AI 项目也不适合靠长周期计划推动。

李明宇给出了一套已经逐步标准化的周度节奏：周一工程师团队回顾上周工作，拉通共性技术问题，确定任务依赖与优先级；周二到周四深入业务现场完成开发、调优、测试和归因；周五向 AIBP 与核心用户演示本周结果，确认效果改善了多少、还差在哪里，并收集下一轮反馈，作为下周任务的输入。

任务被拆到两三天完成，最长不超过一周；“持续优化”不能成为一个没有边界的任务名称，每一轮都要有可验收的目标和结果确认机制。

图 4：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：周度迭代把用户反馈、差距归因和开发任务压缩进同一节奏（PPT 第 17 页）

在这个循环里，EDD——评估驱动开发——负责回答“系统是否真的变好了”。团队先定义什么叫“好”，再用真实样本测量，随后把失败归因到数据、确定性计算、业务方法或平台能力，形成具体改进任务，最后做回归验证，既确认目标能力提升，也防止原有能力退化。

这一步有两个很重要的边界。

第一，不能把所有问题都交给大模型。适合由确定性规则、传统计算或行业小模型处理的部分，应当从智能体推理流程中拆出来。选择正确的工程手段，比强迫一个模型包办所有任务更重要。

第二，Harness 不是项目初期一次搭好的静态底盘。它把上下文、工具、规则、权限、验证和反馈组织在模型之外，并随着真实错误持续生长。一次失败可能带来知识更新、规则调整、工具补充、Skill 改进或评估集扩充；当这些改进被保存下来，同类错误再次发生的概率才会下降。

周五演示时暴露的错误，周一就应该成为下一轮任务：数据有缺口就补数据，规则有问题就调整 Harness，效果发生变化就补评估和回归。3AD 管项目节奏，EDD 管改进证据，Harness 负责把已经验证的做法留下来。这样，失败才会成为系统下一次做得更好的输入。

金融行业的实践案例展示了这套循环如何落到具体工作中。项目先用知识库、专家人设、关键技能、信源优先级和检索策略完成冷启动，再让 AI 在真实任务里持续产出，由 AIBP 和专家判断对错、指出差距。专家不需要先把脑中的隐性经验完整写成方法论，更像是在给 AI“批卷子”；FDE 再把错题归因到数据、方法、规则或平台能力，转成下一周的改进任务和回归验证。

当专家反馈进入系统，AI 既能修正某一道题，也能逐渐学到处理一类问题的方法。专家是否愿意投入时间、组织怎样确认这部分贡献，同样会影响循环能否长期运行。工程机制与组织机制，就这样在项目现场接到了一起。

图 5：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：金融案例通过 AIBP 挑错、专家反馈、FDE 归因和每周重测提炼隐性知识（PPT 第 24 页）

四、不要等到“零错误”，先让 AI 在影子位置学习

很多企业希望 AI 在上线前接近 100% 可靠，再允许它进入生产。但对概率性系统来说，这个条件既不现实，也会让系统长期停留在脱离真实业务的测试环境中。

更可行的路径，是让 AI 尽早处理真实任务和真实数据，但先以影子系统的方式运行：原有业务仍按既定方式完成，AI 同步给出结果，与人工或既有系统进行比较。它接触的是真实工作，却还没有独立承担全部生产责任。

影子运行的价值，是在可控范围内暴露问题。团队可以不断加入边缘场景，观察 AI 在什么条件下偏离目标，再用专家反馈和真实结果驱动改进。随着能力稳定，AI 才逐步从辅助位置进入正式流程，承担越来越多的工作。这种在真实任务中获得反馈、持续纠偏的机制，体现了强化学习的反馈优化思想；但在企业项目里，它依靠的不只是模型训练，还包括专家反馈、工程归因和持续回归。

这里的“允许 AI 犯错”，绝不等于降低生产要求。相反，它要求企业提前设计更具体的兜底：哪些输出必须人工复核，哪些操作只能在有限权限内执行，怎样自动校验，什么情况下需要降级、停止或回退，错误发生后由谁接管和处置。

当系统逐步走向生产，主导权也要发生转移。业务团队应当能够补充知识、调整规则和 Skill，理解关键指标，并处理常见运营问题；FDE 则从日常主导者逐渐退出，在新场景、新模型、新数据分布等重大变化出现时，再介入增量升级。

交付完成的标志，是业务已经能够自主运营，系统仍在被监控和改进；而 FDE 无须永久留在现场兜底。

交通行业的一次大型项目提供了更直观的结果。面对与安全高度相关的复杂业务，材料和人员虽然齐备，传统线性流程却让 AI 能力迟迟无法进入实际工作。项目随后引入现场 FDE、短周期验证、一线专家持续共创，以及评估和人工兜底，逐步改变原有推进方式。

作为结果，项目分批上线了 11 套智能体，并形成能够自我运转的 FDE 前端交付模式。数字之外，项目已经有了自己的反馈节奏、业务参与方式和改进能力。从PoC 到生产，缺口正是在这样的工作方式中被一段段补上。

图 6：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：交通案例以现场 FDE、短周期验证、专家共创和人工兜底改变交付模式（PPT 第 23 页）

五、不要让 FDE 成为孤勇者

FDE 能力要求很高，很容易被想象成一个自带答案的“超级个体”。但软件工程没有银弹，AI 项目也不可能靠一个人替代全部业务和技术角色。

李明宇把项目所需的组织配套拆成了前线与中后台两个层面。业务侧的 AIBP 或 Deployment Strategist 更偏业务目标、价值判断、数据协调与优先级决策；FDE 以 AI 工程能力为底座，主动进入业务；FDIE 贴近一线处理算力、模型、平台、部署、运行和维护，把成本、可靠性与业务目标连接起来；领域专家则提供 FDE 无法替代的专业真值判断。

图 7：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：AIBP、FDE、FDIE、技术中台和工具链共同构成前线交付能力（PPT 第 15 页）

与此同时，企业仍然需要中后台团队持续评估不断翻新的模型、AI Coding 工具和内部 AI 工具：哪些适配业务，哪些满足目标环境与合规要求，哪些可以进入统一工具链，哪些还需要改进。中后台还要建立评估、准入和发布流程，把经过验证的能力作为一致装备提供给前线。

这并不意味着每家企业都要建设庞大的自研中台。团队规模较小时，可以把重点放在技术评估、统一准入和前线支持；规模较大时，再增加平台化和自研能力。关键不在于组织图画得多复杂，而在于不能把业务、工程、基础设施、风险和运营责任全部压给场景里的一个 FDE。

六、从企业 AI 项目到软件工程：FDE for SE 的延伸

2026 年，FDE 的实践进一步延伸到 SE（Software Engineering）。AI Coding 工具个人会用，不等于组织级生产可用。李明宇在演讲中提出，让 Spec 与代码 diff 在同一个 commit 中提交，使后续维护者能够追溯 AI 为什么这样实现；同时对 AI 产出的代码分级审查，把有限的人力投入高风险部分。

图 8：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：FDE for SE 把研发任务、项目知识、Coding Agent、测试、Review、经验沉淀和度量记录连接成闭环（PPT 第 26 页）

这只是 FDE for SE 的一个应用分支，却再次说明了同一件事：AI 不是替企业省掉工程，而是改变工程师把时间花在哪里。手写代码的比例会降低，问题定义、上下文组织、任务边界、验证标准、风险判断和反馈沉淀会变得更重要。

同样的方法也延伸到算法研发：工程师定义问题边界、业务约束、指标和停止条件，由 Agent 批量实验，自己判断方向和结果。

七、从项目经验到能力标准：企业级 FDE 怎样被评价

当 FDE 走出岗位概念，企业需要回答得更具体：什么样的人能够独立承担真实场景，谁可以牵头复杂生产项目，又该用什么证明这些能力确实存在？演讲最后，李明宇代表司南智能软件工程研究院（SIISE）发布《企业级 FDE 个人能力水平模型》V1.0。

图 9：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：发布SIISE企业级 FDE个人能力水平模型（PPT 第 36 页）

模型把能力分为五个领域：业务洞察与 AI 任务定义、AI 应用架构与全栈工程、Harness/数据与知识工程、EDD/风险治理与生产运营、现场交付领导与资产复用。

图 10：李明宇《FDE 落地三年：从行业实践探索到可复用方法论》：企业级 FDE 能力模型覆盖五个能力域，并保持工程能力与现场交付的综合要求（PPT 第 39 页）

L1 到 L4 不按工作年限简单划分，而是看一个人能否完成局部任务、独立交付清晰场景、牵头复杂生产项目，直至跨项目定义方法和培养团队。

模型尤其强调真实证据。业务与决策、工程实现、验证与运行、结果与复用四类材料，需要说明个人做过什么，项目是否经历生产验证、失败治理和业务采纳，Rules、Skills、知识库、评估集等资产有没有留下。证书、工具熟练度或一次顺利的演示，都不能单独代替这些证据。

这套标准保留了一条重要边界：FDE 需要推动协作闭环，却不能替代 AIBP、FDIE、领域专家、数据、安全、平台和运维等组织角色。企业既要识别合适的人，也要为他们配备能够完成交付的环境。

结语：从一个项目走向一套可复制的交付能力

回看三年实践，FDE 已经不再像一个负责串联需求、开发、测试和交付的协调岗位。他以工程能力为底座，把业务意图转成可以验证、运行和退出的系统。企业获得的，是一个上线的 Agent，也是一套能从错误中学习、由业务接手运营的交付机制。

北京站之后，留给企业的问题很具体：怎样让每个真实项目，都成为下一次 AI 落地不再从零开始的基础？

 主要参考演讲

• 李明宇：《FDE 落地三年：从行业实践探索到可复用方法论》，第10 届 AI+研发数字峰会（AiDD 北京站），2026 年 8 月 21 日。
• 格物穷理，开物成务——司南智能软件工程研究院（SIISE）发布，第 10 届 AI+研发数字峰会（AiDD北京站），2026 年 8 月 21 日。
• SIISE发布：《企业级FDE个人能力水平模型》，第 10 届 AI+研发数字峰会（AiDD北京站），2026 年 8 月 21 日。

北京站的两天，我们看见企业 AI 正从单点工具走向可靠的交付系统。但关于 Agent 如何进入业务、如何规模化落地、如何持续创造价值，讨论还将继续。下一站，9月19日，AiDD 将来到成都，与更多一线实践者共同寻找答案。期待与你在成都见面。

了解 AiDD 成都站详情及报名：https://www.aidd.vip/dhrc-cd2026