课程简介
AI 大模型正在改变企业软件和数字化项目的交付方式。传统项目往往围绕“需求冻结、系统开发、上线验收”展开，而 AI 原生项目更强调真实业务场景、样本数据驱动、快速 PoC、持续反馈和长期运营。
FDE（Forward Deployed Engineer）在这一变化中承担关键角色：既要理解业务现场，又要理解智能体、知识库、工具调用、AI Coding、系统集成和效果评估，能够把业务问题转化为可运行、可迭代、可运营的 AI 能力。
本课程不是单纯讲 FDE 概念，也不是纯工具教学，而是围绕企业 AI 项目落地，帮助学员理解并实践：
1.FDE 在 AI 原生交付中的角色与边界；
2.智能体、知识库、工具调用等关键技术底座；
3.Harness Engineering 如何让智能体稳定、可控、持续进化；
4.敏捷 AI 工程如何推动企业 AI 项目从 PoC 走向真实使用；
5.如何结合自身业务场景设计 FDE 落地行动计划。
目标收益
完成两天课程后，学员应能够：
1.理清 FDE 与传统开发、产品经理、售前顾问、交付工程师的区别；
2.理解 AI 项目与传统软件项目的关键差异；
3.掌握 Agent 的核心能力：感知、记忆、推理规划、工具调用；
4.理解 RAG、知识库、多模态知识处理、MCP/API/插件等企业级 Agent 技术要素；
5.掌握 Harness Engineering 的基本方法：Guide、Skill、Prompt、Memory、Tools、Feedback、Sensor；
6.能够围绕一个业务场景设计初步 AI PoC 路径；
7.能够识别 FDE 落地中的数据、系统、权限、安全、组织协同和度量问题。
培训对象
AI转型中的程序员和架构师、企业数字化/研发/交付/咨询/解决方案团队中的 FDE 候选人、AI 项目负责人、业务方案顾问、技术骨干
课程大纲
|
Day 1 上午｜FDE 角色重构与 AI 原生交付范式 核心目标：建立统一认知，理解为什么 AI 时代需要 FDE，以及 FDE 在企业 AI 项目中的真实站位。 |
1. FDE 的来源、定义与岗位边界 FDE 为什么不是传统“驻场开发”； FDE 与产品经理、业务顾问、售前、交付工程师、开发工程师的区别； FDE 的核心站位：站在业务现场，把业务意图转化为可运行的 AI 能力； Echo / AIBP、Delta / FDE、业务专家、技术中台之间的协作关系。 2. AI 项目为什么不能按传统软件项目做 传统软件：需求冻结、功能开发、上线验收； AI 原生项目：需求涌现、概率输出、持续反馈、持续优化； 为什么很多 AI 项目“Demo 好看、上线不好用”； 为什么 B 端 AI 项目必须让业务在真实环境中尽早体验。 3. FDE 的工作方式变化 从“自己写代码”到“组织智能体完成任务”； 从“交付系统”到“交付持续演进的 AI 能力”； 从“响应需求”到“发现问题、验证价值、沉淀机制”； FDE 的核心工作逐步转向 Harness：让智能体少犯错、不重复犯错、贴近业务价值。 4. 案例导入：AI 项目如何从场景走向能力 可选案例： 交通设备故障诊断与维修维护智能体； 制造业生产-运营智能化升级； 研发助手与需求分析智能体； 企业研报 / 规划报告智能体。 5. 课堂互动：学员业务场景初步识别 每位学员选择一个自己熟悉的业务/交付/研发场景； 判断该场景是否适合 AI 介入； 初步识别业务价值、数据可得性、系统接入难度和风险边界。 上午产出： FDE 角色认知图； 本企业/本团队 AI 场景初步清单。 |
|
Day 1 下午｜FDE 必备 Agent 技术栈与企业级架构 核心目标：让学员理解 FDE 需要掌握的关键技术底座，但不陷入纯工具教学。 |
1. Agent 的四类核心能力 感知：接收文本、语音、图片、文档、系统事件等输入； 记忆：短期上下文、长期记忆、知识库、业务规则； 推理与规划：任务拆解、步骤规划、反思与纠错； 工具调用：API、MCP、插件、脚本、数据库、企业系统。 2. Workflow、Agent 与 Multi-Agent 的适用边界 Workflow 适合确定流程； 自主 Agent 适合需求涌现、业务变化快、探索性强的任务； Multi-Agent 适合复杂任务拆解与并行处理； 企业落地不是二选一，而是按场景组合使用。 3. RAG 与知识库工程 传统 RAG：切片、Embedding、向量检索、重排、引用溯源； 多模态知识库：PPT、表格、流程图、图纸、维修手册； 传统 RAG 的常见问题与 Vectorless 知识库； 本体 / 图谱在复杂系统、组织关系、故障链路中的作用； 知识库不是一次建设，而是持续运营。 4. 企业系统接入与 Agent 架构 Skill、MCP、插件、Webhook 的关系与区别； 企业已有系统、数据库、小模型、OCR/CV 服务如何接入； 权限、安全、日志、灰度、版本管理； LUI 对话入口与传统 GUI 的关系与区别； 开发环境、测试环境、生产使用界面的分层。 5. 演示/轻实操：构建一个轻量知识库助手 上传资料； 建立索引； 提问与引用溯源； 发现回答问题并修正知识库； Skill开发； 讨论如何扩展为企业业务助手。 下午产出： 一个轻量知识库/智能体原型； 企业级 Agent 技术路线草图。 |
|
Day 2 上午｜Harness Engineering 与 AI Coding / 智能体开发实战 核心目标：理解 FDE 的核心工作如何从“写代码”转向“调教智能体、设计约束、沉淀机制”。 |
1. 为什么 FDE 的核心工作是 Harness 大模型本身只是 token in / token out； Agent runtime 负责拼接上下文、调用工具、接收返回和循环执行； FDE 的工作不是控制智能体每一步，而是设计 Guide、Feedback 和质量机制； Harness：让智能体犯过一次的错不再重复犯。 2. Harness 的关键组成 Guide / Rule：行为规则、项目规约、业务边界； Skill：可复用操作流程和任务能力； Prompt：任务说明与上下文组织； Memory：长期经验和偏好沉淀； Tools：外部系统、脚本、API、数据库； Feedback / Sensor：用户反馈、测试、Review、日志、监控。 3. AI Coding 与智能体开发流程 从需求到任务拆解； 让 AI 先给计划，再执行修改； 小步开发、测试验证、Review； 多智能体协作：需求分析 Agent、项目经理 Agent、程序员 Agent、测试/Review Agent； Prompt / Skill / Code / Docs 统一版本管理。 4. Harness 深度案例：需求分析智能体如何迭代 示例问题： 需求重复； 编号冲突； 索引不完整； Skill 冲突； 智能体自发写入错误业务洞察。 修复方法： 清理数据； 合并和重构 Skill； 重建索引； 增加自动检查脚本； 将修复经验提交到版本管理。 5. 实操：把一次错误沉淀成 Harness 改进 发现智能体回答错误或任务执行失败的样例； 分析错误来源：知识缺失、规则缺失、工具失败、上下文混乱、评估缺失； 设计修复动作：Guide、Skill、索引、测试、日志； 形成可复用检查清单。 上午产出： Harness 任务清单； 一条“错误 → 机制修复”的样例记录。 |
|
Day 2 下午｜敏捷 AI 工程落地流程与场景实操 核心目标：把 FDE 方法和 Agent 技术转化为企业可执行的 AI 项目落地路径。 |
1. 敏捷 AI 工程四阶段 阶段一：样本数据与首次 PoC 先拿 3–5 个样本数据，不看数据不承诺； 一周内做出第一次可感知效果； 用真实样本验证技术可行性和业务价值。 阶段二：决策关口与场景筛选 技术可行性； 数据可得性； 业务价值； 接口人投入； 风险与合规边界； 组织配合度。 阶段三：真实环境试用与持续优化 让种子用户真实使用； 保留人工/旧流程兜底； 通过业务反馈持续调整知识库、Skill、工具和界面； 不追求第一版完美，追求真实环境可观察、可纠正； 随着AI系统/智能体的完善逐渐扩大试用范围直至生产运行。 阶段四：生产运行、监控与季度升级 使用率、渗透率、人工接管率、错误复发率、业务效果； 监控与运营； 模型、工具链和知识库持续升级。 2. 每周迭代机制 周一：FDE 技术任务会，明确本周任务、产出和责任人； 周二至周四：开发、业务互动、测试验证； 周五：业务/FDE 演示复盘，确认下周方向； 每次迭代都要沉淀 Prompt、Skill、知识库、测试和经验。 3. AI 项目效果评估 不要只看“准确率”，还要看： 用户是否持续使用； 原流程是否被部分替代； 人工接管率是否下降； 用户纠正次数是否下降； 错误是否重复发生； 业务指标是否改善； 知识库和 Skill 是否可复用。 4. 分组工作坊：设计一个 FDE 场景 PoC 每组选择一个业务场景，完成： 场景描述； 业务价值假设； 样本数据清单； 需要接入的系统/工具； 智能体功能草图； Harness 设计：Guide、Skill、Tools、Feedback； 4–8 周落地行动计划。 5. 结营汇报与专家点评 每组展示 PoC 方案； 专家点评业务价值、技术可行性、数据准备、风险边界； 形成下一步行动建议。 下午产出： 每组一个 FDE 场景 PoC 方案； 数据 / 系统 / 工具清单； Harness 设计初稿； 4–8 周落地行动计划。 |
|
Day 1 上午｜FDE 角色重构与 AI 原生交付范式 核心目标：建立统一认知，理解为什么 AI 时代需要 FDE，以及 FDE 在企业 AI 项目中的真实站位。 1. FDE 的来源、定义与岗位边界 FDE 为什么不是传统“驻场开发”； FDE 与产品经理、业务顾问、售前、交付工程师、开发工程师的区别； FDE 的核心站位：站在业务现场，把业务意图转化为可运行的 AI 能力； Echo / AIBP、Delta / FDE、业务专家、技术中台之间的协作关系。 2. AI 项目为什么不能按传统软件项目做 传统软件：需求冻结、功能开发、上线验收； AI 原生项目：需求涌现、概率输出、持续反馈、持续优化； 为什么很多 AI 项目“Demo 好看、上线不好用”； 为什么 B 端 AI 项目必须让业务在真实环境中尽早体验。 3. FDE 的工作方式变化 从“自己写代码”到“组织智能体完成任务”； 从“交付系统”到“交付持续演进的 AI 能力”； 从“响应需求”到“发现问题、验证价值、沉淀机制”； FDE 的核心工作逐步转向 Harness：让智能体少犯错、不重复犯错、贴近业务价值。 4. 案例导入：AI 项目如何从场景走向能力 可选案例： 交通设备故障诊断与维修维护智能体； 制造业生产-运营智能化升级； 研发助手与需求分析智能体； 企业研报 / 规划报告智能体。 5. 课堂互动：学员业务场景初步识别 每位学员选择一个自己熟悉的业务/交付/研发场景； 判断该场景是否适合 AI 介入； 初步识别业务价值、数据可得性、系统接入难度和风险边界。 上午产出： FDE 角色认知图； 本企业/本团队 AI 场景初步清单。 |
|
Day 1 下午｜FDE 必备 Agent 技术栈与企业级架构 核心目标：让学员理解 FDE 需要掌握的关键技术底座，但不陷入纯工具教学。 1. Agent 的四类核心能力 感知：接收文本、语音、图片、文档、系统事件等输入； 记忆：短期上下文、长期记忆、知识库、业务规则； 推理与规划：任务拆解、步骤规划、反思与纠错； 工具调用：API、MCP、插件、脚本、数据库、企业系统。 2. Workflow、Agent 与 Multi-Agent 的适用边界 Workflow 适合确定流程； 自主 Agent 适合需求涌现、业务变化快、探索性强的任务； Multi-Agent 适合复杂任务拆解与并行处理； 企业落地不是二选一，而是按场景组合使用。 3. RAG 与知识库工程 传统 RAG：切片、Embedding、向量检索、重排、引用溯源； 多模态知识库：PPT、表格、流程图、图纸、维修手册； 传统 RAG 的常见问题与 Vectorless 知识库； 本体 / 图谱在复杂系统、组织关系、故障链路中的作用； 知识库不是一次建设，而是持续运营。 4. 企业系统接入与 Agent 架构 Skill、MCP、插件、Webhook 的关系与区别； 企业已有系统、数据库、小模型、OCR/CV 服务如何接入； 权限、安全、日志、灰度、版本管理； LUI 对话入口与传统 GUI 的关系与区别； 开发环境、测试环境、生产使用界面的分层。 5. 演示/轻实操：构建一个轻量知识库助手 上传资料； 建立索引； 提问与引用溯源； 发现回答问题并修正知识库； Skill开发； 讨论如何扩展为企业业务助手。 下午产出： 一个轻量知识库/智能体原型； 企业级 Agent 技术路线草图。 |
|
Day 2 上午｜Harness Engineering 与 AI Coding / 智能体开发实战 核心目标：理解 FDE 的核心工作如何从“写代码”转向“调教智能体、设计约束、沉淀机制”。 1. 为什么 FDE 的核心工作是 Harness 大模型本身只是 token in / token out； Agent runtime 负责拼接上下文、调用工具、接收返回和循环执行； FDE 的工作不是控制智能体每一步，而是设计 Guide、Feedback 和质量机制； Harness：让智能体犯过一次的错不再重复犯。 2. Harness 的关键组成 Guide / Rule：行为规则、项目规约、业务边界； Skill：可复用操作流程和任务能力； Prompt：任务说明与上下文组织； Memory：长期经验和偏好沉淀； Tools：外部系统、脚本、API、数据库； Feedback / Sensor：用户反馈、测试、Review、日志、监控。 3. AI Coding 与智能体开发流程 从需求到任务拆解； 让 AI 先给计划，再执行修改； 小步开发、测试验证、Review； 多智能体协作：需求分析 Agent、项目经理 Agent、程序员 Agent、测试/Review Agent； Prompt / Skill / Code / Docs 统一版本管理。 4. Harness 深度案例：需求分析智能体如何迭代 示例问题： 需求重复； 编号冲突； 索引不完整； Skill 冲突； 智能体自发写入错误业务洞察。 修复方法： 清理数据； 合并和重构 Skill； 重建索引； 增加自动检查脚本； 将修复经验提交到版本管理。 5. 实操：把一次错误沉淀成 Harness 改进 发现智能体回答错误或任务执行失败的样例； 分析错误来源：知识缺失、规则缺失、工具失败、上下文混乱、评估缺失； 设计修复动作：Guide、Skill、索引、测试、日志； 形成可复用检查清单。 上午产出： Harness 任务清单； 一条“错误 → 机制修复”的样例记录。 |
|
Day 2 下午｜敏捷 AI 工程落地流程与场景实操 核心目标：把 FDE 方法和 Agent 技术转化为企业可执行的 AI 项目落地路径。 1. 敏捷 AI 工程四阶段 阶段一：样本数据与首次 PoC 先拿 3–5 个样本数据，不看数据不承诺； 一周内做出第一次可感知效果； 用真实样本验证技术可行性和业务价值。 阶段二：决策关口与场景筛选 技术可行性； 数据可得性； 业务价值； 接口人投入； 风险与合规边界； 组织配合度。 阶段三：真实环境试用与持续优化 让种子用户真实使用； 保留人工/旧流程兜底； 通过业务反馈持续调整知识库、Skill、工具和界面； 不追求第一版完美，追求真实环境可观察、可纠正； 随着AI系统/智能体的完善逐渐扩大试用范围直至生产运行。 阶段四：生产运行、监控与季度升级 使用率、渗透率、人工接管率、错误复发率、业务效果； 监控与运营； 模型、工具链和知识库持续升级。 2. 每周迭代机制 周一：FDE 技术任务会，明确本周任务、产出和责任人； 周二至周四：开发、业务互动、测试验证； 周五：业务/FDE 演示复盘，确认下周方向； 每次迭代都要沉淀 Prompt、Skill、知识库、测试和经验。 3. AI 项目效果评估 不要只看“准确率”，还要看： 用户是否持续使用； 原流程是否被部分替代； 人工接管率是否下降； 用户纠正次数是否下降； 错误是否重复发生； 业务指标是否改善； 知识库和 Skill 是否可复用。 4. 分组工作坊：设计一个 FDE 场景 PoC 每组选择一个业务场景，完成： 场景描述； 业务价值假设； 样本数据清单； 需要接入的系统/工具； 智能体功能草图； Harness 设计：Guide、Skill、Tools、Feedback； 4–8 周落地行动计划。 5. 结营汇报与专家点评 每组展示 PoC 方案； 专家点评业务价值、技术可行性、数据准备、风险边界； 形成下一步行动建议。 下午产出： 每组一个 FDE 场景 PoC 方案； 数据 / 系统 / 工具清单； Harness 设计初稿； 4–8 周落地行动计划。 |
近期公开课推荐
