引言:中国其实"驻场"了二十年,为什么还缺 FDE?
2026 年上半年,硅谷的新闻是三笔大钱:OpenAI 拉私募成立约 40 亿美元的 Deployment Co.,Anthropic 组了约 15 亿美元的 AI 服务公司,AWS 自掏 10 亿美元建数千人的 FDE 组织——巨头集体押注"把 AI 交付进企业"的前线部署工程师。
消息传到国内,很多做 toB 交付的老兵第一反应是失笑:驻场?我们驻了二十年了。
但另一组数字笑不出来。据智能超参数的中标监测,2025 年全年国内大模型相关中标项目多达 7539 个,披露金额约 295 亿元,项目数量较上年增长 396%——需求确实在爆炸。可是行业里人人都知道另一半故事:签下来的项目,交付得七荤八素;POC 惊艳、上线拉胯;验收标准扯皮半年,回款遥遥无期;驻场工程师干成了"高级人肉运维",项目结束什么也没沉淀下来。中国 toB 市场从不缺驻场的人,缺的是能把 AI 项目"交付成、验收掉、回款回、复制开"的人——这才是 FDE 与传统驻场的本质区别。
这篇文章做一件事:基于国内大模型 toB 市场的公开行情数据,加上政企交付一线的实践,把 FDE 的核心能力整理成一份 四阶段 × 12 项 的培养清单——并且,每一项都按中国 toB 的真实约束校准:招投标、账期、免费 POC、需求蔓延、数据不出域、信创合规、领导可见性。每项能力回答三个问题:它防止什么事故、具体怎么练、达到什么程度算过关。可以直接拿去当团队培养 SOP 和每周复盘检查表,也可以作为个人转型的对照自查表。
先看行情,再上清单。
一、中国 toB 行情:钱在哪、谁在赚、坑在哪
需求侧:政策点火,央国企掏钱。 这一轮国内企业级 AI 的采购主力不是互联网公司,是央国企和政府:按智能超参数的统计口径,央国企发起的大模型采购在整体市场中数量占比超过六成、金额占比约一半;行业分布上,政务、教科、通信、能源、金融、交通、医疗是项目数量最集中的七大赛道,其中千万级大单三百余个、亿元级大单四十余个。政策是最强的点火器:国资委的 AI+ 专项行动持续加码,2026 年 4 月国务院发文首次明确"支持采购大模型、Agent 服务",叠加工信部等八部门的"AI+制造"专项——企业级 AI 在中国正式从"试点期"进入"政府采购 + 规模放量"阶段。对 FDE 来说,这意味着未来几年的主战场画像非常清晰:预算充足、流程严格、合规刚性的大 B 和 G 端客户。
供给侧:四类玩家同台。 从中标榜单看,科大讯飞凭借在教科、医疗、金融等行业的场景化复制稳居"标王";火山引擎、百度、阿里云、腾讯云四朵云稳居前十;运营商系集成商(中电信人工智能、中移系统集成等)凭央国企身份以总集成商角色切走大量项目;再加上智谱等模型厂商和一大批转型中的传统集成商。注意一个结构性信号:榜单头部厂商的共同点,恰恰是在细分行业里形成了"可复制的解决方案"——这与本文第 12 项能力直接呼应,后面细讲。
人才行情:国内价码已经立起来了。 腾讯云在上海挂出的"AI 前线部署工程师"月薪 35–65K、15 薪;智谱等模型厂给到 60–80K 月薪;综合公开信息,国内头部企业 FDE 年薪大致落在 30 万–80 万人民币区间。与美国市场(中高级总包 30 万–55 万美元)相比绝对值差距明显,但在国内技术岗普遍收缩的背景下,这是少数逆势起价的岗位族——而且供给严重不足,因为它要的是"懂业务 + 懂工程 + 扛得住甲方"的复合体。
行情底色:四个中国特色变量。 照搬硅谷的 FDE 方法论在国内会水土不服,因为约束条件不同。做国内 toB 交付,四个变量必须进入你的能力模型:
其一,私有化部署与数据不出域是默认项,不是选项。等保、数据安全法、行业监管加上信创要求,意味着你面对的常常是国产化算力 + 国产/开源模型 + 隔离网络的组合——模型能力比公有云旗舰弱一到两档,这个落差要靠工程和知识结构化补回来。
其二,招投标与账期决定现金流。项目从标书里来,写标书的人和用系统的人往往不是同一拨;验收标准如果模糊,验收就会拖延,回款就会遥遥无期——在国内,验收标准不只是质量文档,是回款依据。
其三,甲方强势与需求蔓延。"顺便帮我们把这个也做了"是每个乙方都熟悉的句式;领导意志与一线痛点常常是两张需求皮;项目还要考虑"领导看得见"的汇报价值。
其四,驻场传统深厚,但缺产品飞轮。传统驻场是人力外包逻辑:人走了,什么都没留下。Palantir 式 FDE 的核心是前线经验回流产品、A 客户的方案复用给 B 客户——这恰恰是国内集成商毛利困境的解药,也是"驻场"与"FDE"的分水岭。
一盆必要的冷水。 吴恩达对 FDE 的质疑值得认真听:企业侧 AI Engineer 的需求量终将远大于厂商派驻的 FDE;FDE 天然带厂商立场,不中立;它可能只是 AI 产品不成熟期的过渡角色。但把这套论证放到中国语境,结论要修正:国内多数政企客户的 IT 自建能力显著弱于美国企业,信息化历史欠账更多,组织上更习惯"交钥匙工程"——对乙方交付能力的结构性依赖,在中国比在美国更深、更持久。真正的风险不是需求消失,而是低价中标把毛利打穿:FDE 是贵的,如果你的交付不能复制、不能沉淀,这门生意在中国的账算不平。这也是为什么这 12 项能力里,"验收"与"复制"两项在中国版里权重最高。
二、能力模型总览:四个阶段,十二项能力
本文不把能力平铺成清单,而是沿一次真实交付的生命周期展开——因为在中国 toB 语境下,这条生命周期同时也是现金流曲线:进场期决定你签什么、立项期决定你能不能验收回款、交付期决定你交付成本、放大期决定你毛利和复购。
-
进场期(听懂业务):①需求考古 ②流程测绘 ③切口选择
-
立项期(定义成功):④验收标准工程 ⑤POC 纪律 ⑥职责契约
-
交付期(构建系统):⑦知识结构化 ⑧人机分工设计 ⑨合规与风险兜底
-
放大期(沉淀资产):⑩渐进放量 ⑪信任运营 ⑫资产化复制
使用姿势有两个。带团队:新人按阶段递进训练,先在老带新项目里练进场期三项,过关再往后走。做复盘:项目出问题沿四阶段回溯,通常能定位到具体能力缺失——"验收拖了半年回不了款",查④;"POC 做了仨月还在加需求",查⑤和⑥;"上线后业务不用",查⑥和⑪;"每个项目都从零干起、越干越亏",查⑫。
下面逐项拆解,统一结构:防什么事故 → 怎么练 → 达标线。
三、进场期:听懂业务的三项能力
① 需求考古
防什么事故:照着招标文件做需求。国内项目的第一现实是:标书不等于真实需求——写标书的人(信息中心、咨询方甚至友商)和最终用系统的人(一线业务)往往不是同一拨,标书里还常混着上一个供应商的产品参数。照标书交付,技术上合规,业务上没人用,验收时两头不讨好。
怎么练:进场后做三层访谈,每层问的问题不同。分管领导层:这个项目在您的年度工作里排第几?明年您希望向上汇报什么成果?信息中心层:现有系统格局如何?哪些红线不能碰?上一个项目为什么不了了之?一线业务层:您一天的工作流里最烦的一步是什么?现在怎么绕过去的?三层答案拼在一起,才是完整需求——领导要的是"成果",信息中心要的是"可控",一线要的是"省事",三者不重合的部分,就是项目最大的风险敞口,进场期就要摆上桌面。产出必须落成结构化文档:业务背景、目标、现状、差距、具体需求、初步方案,拒绝自由叙述。
达标线:一轮访谈之后,能用一页纸写清三层诉求及其冲突点,且三层的人看了都认账。写不出冲突点的需求文档,基本可以断定还没挖到底。
② 流程测绘
防什么事故:AI 安在错误的节点上。国内企业还有个加重症状:流程文档普遍缺失或失真——制度汇编里写的是"应然流程",一线跑的是"实然流程",两者差距可以大到面目全非。按制度文件设计 AI,上线即撞墙。
怎么练:引入任何 AI 之前,先蹲现场还原实然流程(as-is)。对每个节点采集五要素:输入从哪来、谁在判断、依据什么规则、输出给谁、异常走哪条路;再给每个节点标两个数:耗时、出错率。值得 AI 介入的节点会在这两列数字里自己跳出来。国内场景多做一层:标注每个节点的"系统归属"——这一步在谁家的系统里发生,牵涉哪个部门的接口和权限,因为跨系统、跨部门的节点在政企环境里协调成本最高,直接影响你的排期与报价。
达标线:一张 A4 纸画清改造前后差异,业务负责人和信息中心主任都看得懂;并且你能指着图回答两个问题——时间花在哪了,接口卡在谁那。
③ 切口选择
防什么事故:全面铺开,全面烂尾。"AI 全面赋能"式立项在政企市场尤其高发,因为大项目更好立项、更好汇报——但十几个方向同时铺开,资源摊薄、依赖交织,一年后一个能独立验收的东西都没有。
怎么练:从蓝图逐层下钻到单一功能点,每次只切一刀,切口用四个维度打分:业务痛感(影响多少人、多高频、当前多少耗时,全部量化)× AI 可行性(注意按私有化环境里实际可用的模型能力评估,不是按公有云旗舰的演示效果评估)× 交付周期(4–8 周可见效)× 汇报价值(成果能否被领导看见、讲清、对外示范)。第四维是中国 toB 的现实:一期做成"标杆",二期三期的预算才有人批。但要守住一条纪律:汇报价值是加分项,不是目的——为了大屏而做大屏、为了发布会而做 demo 的"可见性工程",短期风光,长期透支信任。
达标线:能向任何质疑者量化回答"为什么先做这个不做那个",并且答案里同时包含业务账和汇报账。
四、立项期:定义成功的三项能力
④ 验收标准工程
防什么事故:验收扯皮,回款遥遥无期。这是国内 toB 与硅谷语境差别最大的一项:在美国,验收标准是质量问题;在中国,验收标准是现金流问题。合同里"系统运行稳定、功能满足需求"这类模糊表述,等于把回款的解释权交给了甲方——验收拖一个季度,乙方现金流就断一个季度。
怎么练:在合同和 SOW 层面写入可量化验收:输入规格(什么格式质量的数据允许进入)、评估维度、通过阈值(数值多少、谁定的、写进合同附件)、输出模板、异常规则(什么情况转人工)、后续动作。工程升级心法:把验收标准直接做成一份评测集(eval set)——立项时拉甲方业务骨干共同标注 30–50 条真实样本,每条写清期望输出与判定理由,双方签字。这份评测集一鱼四吃:验收依据、回归测试集、模型换代基准,以及最重要的——回款触发器:跑分达标即满足验收条件,白纸黑字,不看心情。经验规律:同一个模型,验收标准从模糊到清晰,表观达标率常能提升二三十个百分点——变的不是模型,是标准;而在国内,变的还有回款周期。
达标线:甲方拿着评测集,不需要你在场就能自己打分;且验收条款细到"打分达标 = 验收通过 = 付款条件成就"。做不到,风险都在你这边。
⑤ POC 纪律
防什么事故:免费 POC 内卷,验证阶段无限膨胀。国内市场"免费 POC、效果达标再合作"已成通行获客话术,竞争之下乙方很难拒绝——但没有边界的免费 POC 是吞噬交付团队的黑洞:范围越做越大、数据越接越多、周期越拖越长,最后 POC 做成了免费交付,项目还未必签。
怎么练:POC 可以免费,但必须有边界、有转化条件,四条写进 POC 协议或备忘:范围(单一场景、明确功能点,超出即变更)、数据(甲方提供的样本量与质量责任、脱敏责任归属)、周期(硬上限,建议两周,最长不超过四周)、转化条件(达到什么指标进入商务流程,达不到双方止损)。POC 本身则执行最小验证纪律:允许手动复制粘贴、允许没有 UI、10–30 条样本、只验证核心判断逻辑是否成立——POC 阶段搭平台,是用自己的成本给别人的犹豫买单。
达标线:每个 POC 启动前四要素齐备;两周内产出结论;团队全年的 POC 转化率有人统计、有人复盘。没人算这笔账的团队,正在被免费 POC 慢性失血。
⑥ 职责契约
防什么事故:两个国内高发事故。一是需求蔓延不加钱:"顺便帮我们把 OA 也对接了""领导说再加个手机端"——每个"顺便"都是没有报价的工作量;二是数据责任悬空:项目延期的第一大原因往往不是技术,是甲方数据迟迟给不出、给出来质量稀烂,而合同里没写数据准备是谁的责任,锅最后全在乙方头上。
怎么练:立项时白纸黑字签下三张单。分工单:甲方负责评价标准制定、领域知识与数据供给、业务骨干投入(写明人名和投入比例)、最小场景陪跑;乙方负责系统接入、工程化、安全权限、稳定性监控。变更单机制:任何新增需求走书面变更,评估工作量与工期影响后双方确认——"顺便"两个字在项目里不存在。数据责任单:数据范围、格式、质量标准、脱敏责任、供数时限,逐项落名;甲方供数延期,工期顺延,写进合同。三条红线不变:乙方不替业务做专业判断,业务不替乙方做技术选型,知识由业务供给、乙方负责结构化。
达标线:复盘会上每个关键决策和每次延期都能指认责任归属,没有灰色地带;全年项目里"无偿变更"的工作量占比有统计、且逐年下降。
五、交付期:构建系统的三项能力
⑦ 知识结构化
防什么事故:知识库变文档坟场。国内版的加重症状:私有化环境里你可用的往往是国产/开源模型加受限算力,模型能力比公有云旗舰弱一到两档——把十五年的制度汇编、技术规程一股脑扔给一个能力受限的模型,效果只会更惨。模型越弱,知识结构越要强,这是私有化交付的铁律。
怎么练:把业务知识建模为三要素——实体(业务对象:设备、工单、患者、合同)、关系(对象间关联:隶属、触发、依赖)、规则(判定逻辑:阈值、路由、豁免条款,政企场景里大量藏在制度文件的"但书"条款里)。在此之上设计调用路由:先识别当前处理什么对象、处于什么状态,再决定调用哪个知识域、套用哪条规则。央国企有个独特富矿:多年沉淀的制度、规程、案例库天然带结构(章节、条款、适用范围),结构化抽取的性价比远高于互联网企业的野生文档——这也是国内知识密集型场景(能源、医疗、政务)AI 项目可行性的底气所在。
达标线:给你一份 100 页的业务手册或制度汇编,能拆出实体清单、关系清单、判定规则清单和可独立调用的知识域划分。拆不出来,说明还在"读文档",没在"建结构"。
⑧ 人机分工设计
防什么事故:让 AI 一条龙包办全流程。国内政企环境里这个错误的代价更高,因为责任制文化是刚性的——出了事要能找到签字的人,"AI 判的"在任何追责场景下都不成立。另一个反向事故:把定时同步脚本包装成"AI 赋能"充数,验收时被懂行的专家当场戳穿。
怎么练:对流程每个节点做执行主体三分法。AI 承担识别、分类、生成、给建议——概率性输出可接受的模式任务;自动化程序 承担采集、搬运、计算、状态同步——规则明确无需判断的确定性任务;人 承担标准制定、最终审核、复杂例外、以及一切需要签字担责的环节。政企场景的标准搭配是"AI 初判 + 人签发":AI 提效,人担责,系统留痕(谁在何时基于什么建议做了什么决定)——留痕不是负担,是保护经办人的机制,把这一点讲给甲方听,推行阻力会小一半。
达标线:拿到完整业务场景,能逐节点标注执行主体和责任人,每个标注说得出理由;方案评审时,甲方法务和安全部门挑不出"无人担责"的环节。
⑨ 合规与风险兜底
防什么事故:高危场景裸奔上线。国内 AI 触达用户的场景,头顶悬着一整套刚性合规:《生成式人工智能服务管理暂行办法》的内容安全要求、数据安全法与个保法的数据要求、等保测评、行业监管(医疗的诊疗规范、金融的适当性义务)——一条不当输出在国内不只是舆情事故,可能直接是合规事故。
怎么练:为每个 AI 触达用户的场景选定放行模式,且在政企与强监管行业,这不是自由选择而是合规映射。白名单(仅确认安全的问题域可自动输出,其余全部转人工):医疗、政务、金融等场景的默认项——以医疗为例,AI 生成的任何面向临床或患者的内容,必须经专业人员确认后方可进入正式档案,这是责任结构,不是效率参数;黑名单(默认放行,拦截敏感项):仅适用于物流查询、FAQ 等低风险高频场景;灰度(先白后黑):中风险场景先积累安全样本再逐步放开。每个上线方案必附四件套:风险分级、兜底策略(出错谁处理、多快响应)、影响半径上限、回滚预案(多快全量切回人工);面向公众的生成场景,再加内容安全审核链路与日志留存。
达标线:一票否决制——无分级、无兜底四件套、无合规映射说明的方案,不上线,没有例外。
六、放大期:沉淀资产的三项能力
⑩ 渐进放量
防什么事故:验证通过后直接全量铺开,在长尾数据里翻车;或者更隐蔽的死法——模型输出一个"看似高级但无人理解"的结构,甲方既不会用也不敢改,交付物技术上成功、组织上死亡,二期自然没有下文。
怎么练:五步放量节奏——AI 粗跑产出初步结果;抽约 1% 样本交甲方资深业务人员校准;把校准结论固化为甲方能用自己的话解释的模板;AI 按模板全量执行;甲方复核新类别与边界 case。铁律:交付物拿给业务方,对方能用自己的语言复述判断逻辑;复述不了,打回重做,无论指标多好看——因为在国内,能复述逻辑的甲方骨干,就是你在客户内部的"代言人",二期立项时替你说话的是他,不是你的 PPT。
达标线:全量上线时,甲方至少一名业务骨干能脱稿讲清系统逻辑、独立处理八成边界 case——这个人同时就是你下一期项目的内部推手。
⑪ 信任运营
防什么事故:两种对称的失败。其一,把承载信任的人际触点自动化掉——客户答疑、客情跟进这类环节表面是信息传递,实际是关系载体,全自动化之后效率上去、续约下来;其二,验收即失联——国内 toB 是典型的关系型市场,复购和转介绍几乎全部来自被经营好的标杆客户,验收完拍屁股走人,等于把最贵的获客资产扔在了现场。
怎么练:流程改造时对每个拟自动化节点追问:这一步是"无价值搬运"还是"有价值接触"?原则:自动化消除搬运,不消除接触。项目层面做三件事:把"甲方自给自足"写进交付目标(文档、培训、值班交接,驻场结束时对方能独立运维和小步迭代);把信息中心处成"自己人"(他们是你在客户内部的长期接口,也是下个项目的第一情报源);验收后建立固定回访节奏(季度回访、版本升级通报、标杆案例共创——案例要让甲方领导一起出面讲,成果是他的,复购是你的)。
达标线:方案中能指出至少一个"刻意不自动化"的环节并给出业务理由;交付结束三个月后系统仍在被使用、被维护;年度盘点时,老客户复购与转介绍占新签的比例有数、且在涨。
⑫ 资产化复制
防什么事故:每个项目从零开始,越干越亏。这是国内集成商的经典毛利困境:定制化程度高、人力成本刚性、低价中标压价——如果交付不能复制,FDE 模式在中国的账根本算不平。看看中标榜单就知道出路在哪:头部厂商的共同特征,恰恰是在教科、医疗、金融等赛道形成了场景化的规模复制——同一套解决方案覆盖不同客户,才撑得起数量与毛利。
怎么练:三步抽象法。第一步,把一个行业场景完整跑通,确认端到端链路;第二步,抽出与客户无关的通用件——流程骨架、评测框架、知识路由逻辑、合规兜底机制、部署脚本(信创环境的适配包尤其值钱,做一次,后面每个国产化项目都在收利息);第三步,验证迁移性:换一个同行业相邻客户,只替换知识库、数据接口和少量定制层,看几天能跑通。每个项目交付文档必含《复用指南》:哪些组件通用、哪些需替换、替换工作量估计。FDE 的隐性 KPI 不是"做完这个项目",而是"让下一个项目更快、更便宜"——这是 Palantir 模式的精髓,也是中国乙方从"项目公司"走向"产品公司"的唯一路径。
达标线:同行业相邻场景,换一个人基于你的框架和文档,复用七成以上组件、一周内跑通最小闭环;公司层面,单位项目的交付人天逐年下降——这个数字不降,"资产化"就只是 PPT 词汇。
全景速查表(建议截图保存,作每周复盘检查表用):
七、个人怎么练:国内语境下的三条转型路径
路径一:把现在的公司当客户。 12 项里有 9 项不需要外部客户就能练。选所在公司一条真实业务流程(报销审批、客服工单、内容审核都行),完整走一遍进场期与立项期:三层访谈、画实然流程、量化耗时、选切口、写出带评测集的验收标准。这套文档本身就是能力铁证——而且大概率会真的落地,因为你可能是全公司第一个认真画过这条流程的人。
路径二:从乙方交付与售前转型,这是国内最短路径。 对照国内 FDE 岗位 JD,最受欢迎的三类背景恰好是国内存量最大的三类人:集成商/软件公司的交付与实施工程师(懂驻场、懂政企现场的复杂性)、售前解决方案架构师(懂需求翻译与方案表达)、有大模型应用开发经验的后端工程师(懂工程化)。已在其中一类的,补齐另外两块的作品证据即可。投递四件套作品集:一页纸需求文档(带三层诉求冲突分析)、一张流程测绘图、一份带评测集的验收标准、一份复用指南——这四样对应 12 项里最难伪装的能力,有经验的面试官一眼分辨。
路径三:别只盯乙方,甲方侧同样缺人。 央国企的数字化部门、科技子公司正在大量吸纳"懂 AI 落地的自己人"——甲方侧 FDE 的工作内容高度重合(选场景、定标准、管乙方、保合规),稳定性更高,且恰好回应了吴恩达的判断:企业自建 AI 能力是长期趋势,提前站到甲方侧,等于站到了趋势的收益端。区域市场也值得看:大模型采购正从一线向省会与地市财政/国企下沉,本地化交付人才在二线市场的稀缺度反而更高。
结语:在中国做 FDE,更难,也更值得
把硅谷的 FDE 叙事平移到中国会失真:这里没有 45 天优雅撤场的剧本,有的是招投标、账期、免费 POC、需求蔓延和信创合规。但正因为环境更复杂,这 12 项能力在中国的稀缺溢价反而更高——2025 年 7539 个中标项目、295 亿元的盘子背后,是无数个"签得下来、交付不动"的团队在给会交付的人抬价。
三条行动建议:带团队的,把速查表做成每周复盘检查表,重点盯④验收和⑤POC 两项——它们直接决定现金流;想转型的,从路径一开始,本周就约一位业务同事做第一次三层访谈;已经在交付一线的,对照达标线自评,把"资产化复制"作为下一个项目的刻意练习——每交付一个项目,问自己一句:这次,我给下一个项目留下了什么?
最后留一个判断供讨论:随着 AI 编码能力增强,12 项里"构建系统"的部分会越来越多被 AI 自己完成,而进场期与放大期的能力——听懂中国甲方、经营长期信任、把项目变成资产——会更值钱。机器越擅长交付,懂得让交付发生的人越贵。
《FDE：企业RAG+Agent+Skills的智能体案例实操和源生Agent Harness开发案例实操》
大模型实战专家—周红伟 法国科学院算法博士/前阿里人工智能专家/马上消金风控负责人
课程背景
公司企业科技业务正加速推进大模型应用从试点探索向规模化落地转变。当前团队在AI应用开发中普遍面临三个断层：一是业务需求与AI技术方案之间缺乏统一表达框架，需求理解偏差导致交付反复；二是现有开发多依赖低代码平台快速搭建原型，但在复杂企业任务中暴露出可控性不足、调试困难、难以对接现有系统等问题，源生开发能力缺失；三是团队对提示工程、RAG、Agent等技术的掌握停留在工具操作层面，缺乏从业务场景识别、方案设计到工程实现的全链路能力。与此同时，企业业务对AI应用的安全性、合规性、可审计性要求远高于通用场景。直接照搬通用大模型应用模式无法满足内部管控要求，需要在架构设计、工具调用边界、人工确认机制、日志审计等方面进行专门设计。团队当前缺乏一套面向企业场景的Agent开发方法论和可复用的工程模板，导致项目周期拉长、效果不稳定、生产化推进困难。
本次培训聚焦公司真实业务场景，围绕企业RAG、Agent、Skills三类核心能力展开，通过Spec Coding规范业务到代码的转换过程，并通过源生Agent Harness开发弥补低代码平台的能力边界。课程采用工具链掌握、开发优化、项目落地三阶段递进，帮助学员建立从需求洞察到可交付AI应用的完整闭环能力。
课程收益
通过两天学习，学员能够获得以下收益：
第一，掌握企业RAG的工程化落地方法。能够针对企业文档特点设计合理的切片与检索策略，理解召回率、答案忠实度等核心指标的评估方法，具备将模糊业务问题转化为可验证RAG任务的能力，避免在真实项目中走通方案却无法稳定复现的问题。
第二，具备高级提示词工程与定制化AI能力加强的实操经验。能够使用结构化提示词四要素方法控制企业术语一致性与输出格式，掌握多步推理与自检提示设计，能够将财务计算、合规条款匹配等业务能力封装为可复用的Skill，并通过Skill与RAG协同完成复杂任务。
第三，获得源生Agent Harness从零搭建的开发能力。理解Agent推理循环、工具调用协议、上下文管理等核心机制，能够手写一个基础Agent循环并接入企业工具，处理异常返回与降级逻辑，不再受限于低代码平台的黑盒限制，具备将原型推进到生产化改造的工程基础。
第四，学会用Spec Coding方法将企业业务规则精确转化为Agent实现规格。能够编写包含任务目标、输入输出、约束条件的Spec文档，将合规要求转化为可校验的条款，并根据Spec生成代码骨架与测试用例，显著降低业务与开发之间的沟通成本与返工率。
第五，建立企业业务场景识别与端到端方案设计能力。能够从真实业务流程中筛选高价值AI切入点，区分替代型与增强型应用，完成技术可行性与业务影响评估，输出结构化的AI场景卡片，使技术方案从一开始就对准业务指标。
培训时长
2天
课程大纲
第一天 主题：企业RAG+Agent+Skills智能体Spec Coding开发
第一部分 企业RAG基础与业务场景映射
1.1 企业RAG技术栈拆解
1.1.1 检索增强生成在企业场景的适用边界与局限
1.1.2 企业文档结构特点对切片策略的影响
1.1.3 RAG与传统搜索、微调在成本与效果上的对比
1.2 企业业务需求到RAG问题定义
1.2.1 从信贷报告、合规文件、研报中识别检索诉求
1.2.2 将模糊业务问题改写为可验证的RAG任务
1.2.3 定义评估指标：召回率、答案忠实度、业务可用性
1.3 案例复盘：企业研报问答系统
1.3.1 原始需求与数据现状分析
1.3.2 方案选型与失败点回顾
1.3.3 可复用经验与避坑清单
第二部分 高级提示词工程在企业Agent中的应用
2.1 结构化提示词设计方法
2.1.1 角色、任务、约束、输出格式四要素拆解
2.1.2 企业术语一致性控制技巧
2.1.3 提示词版本管理与回归测试
2.2 多步推理与自检提示模式
2.2.1 思维链在财务计算与合规判断中的使用
2.2.2 让模型先列依据再给结论的强制格式
2.2.3 自检提示设计：要求模型标注不确定项
2.3 企业场景提示词实战
2.3.1 研报摘要生成提示词逐行解析
2.3.2 合同条款风险识别提示词调优
2.3.3 多轮对话中保持上下文一致的写法
第三部分 定制化AI能力加强：Skills设计与实现
3.1 Skills在企业智能体中的定位
3.1.1 Skill与工具调用的区别
3.1.2 哪些业务能力适合封装为Skill
3.1.3 Skill的输入输出契约设计
3.2 企业领域Skill开发实操
3.2.1 财务指标计算Skill：公式封装与异常处理
3.2.2 合规条款匹配Skill：规则与模型混合策略
3.2.3 数据脱敏Skill：敏感信息识别与替换逻辑
3.3 Skills与RAG的协同模式
3.3.1 检索结果驱动Skill调用
3.3.2 Skill输出反哺检索条件优化
3.3.3 多Skill编排完成复杂企业任务
第四部分 低代码平台搭建企业Agent原型
4.1 低代码平台能力边界与选型依据
4.1.1 支持RAG与Agent编排的平台功能对比
4.1.2 企业级部署对权限、审计、版本的要求
4.1.3 低代码与纯代码混合开发的取舍
4.2 用低代码搭建企业问答Agent
4.2.1 知识库接入与切片配置实操
4.2.2 提示词模板与变量绑定
4.2.3 流程编排：检索、生成、后处理串接
4.3 原型验证与快速迭代
4.3.1 用真实业务问题做批量测试
4.3.2 基于反馈调整切片与提示词
4.3.3 输出可演示的最小可行产品
第五部分 企业业务场景设计：从流程中识别AI机会
5.1 业务流程拆解与AI切入点定位
5.1.1 画业务流程图并标注信息流转节点
5.1.2 用频次、复杂度、容错率筛选高价值场景
5.1.3 区分替代型AI与增强型AI
5.2 端到端方案设计框架
5.2.1 输入数据、处理逻辑、输出交付物定义
5.2.2 技术可行性评估：模型能力、数据可得性、系统集成
5.2.3 业务影响预估：效率提升、风险下降、体验改善
5.3 场景设计分组实战
5.3.1 每组选择一个真实企业业务流程
5.3.2 输出AI场景卡片：问题、方案、指标
5.3.3 交叉评审与讲师反馈
第二天 主题：源生Agent Harness开发与项目落地
第一部分 Agent Harness架构解析
1.1 Agent Harness核心组件
1.1.1 推理循环：计划、执行、观察、反思
1.1.2 工具调用协议与错误恢复机制
1.1.3 上下文管理与记忆策略
1.2 企业场景下的Harness设计差异
1.2.1 安全边界：哪些操作禁止自动执行
1.2.2 审计日志：每次工具调用的完整记录
1.2.3 人工确认节点在关键流程中的插入
1.3 代码级Harness最小实现
1.3.1 手写一个基础Agent循环
1.3.2 接入一个工具并处理异常返回
1.3.3 打印完整推理轨迹便于调试
第二部分 Spec Coding：从规格说明到Agent实现
2.1 Spec Coding理念与企业场景适配
2.1.1 规格说明驱动的开发流程
2.1.2 企业业务规则如何在Spec中精确表达
2.1.3 Spec评审与验收标准定义
2.2 编写企业Agent的Spec
2.2.1 任务目标、输入输出、约束条件模板
2.2.2 边界案例：异常输入、缺失数据、超长文本
2.2.3 将合规要求转化为可校验的Spec条款
2.3 Spec到代码的映射实操
2.3.1 根据Spec生成Agent骨架代码
2.3.2 将业务规则转化为提示词与校验逻辑
2.3.3 用Spec驱动测试用例自动生成
第三部分 源生Agent Harness开发实操
3.1 搭建可运行的Agent Harness工程
3.1.1 项目结构与依赖管理
3.1.2 实现模型调用与响应解析模块
3.1.3 实现工具注册与调度模块
3.2 企业工具接入与调试
3.2.1 接入外部API：行情、公告、内部系统
3.2.2 工具返回结果的结构化与截断策略
3.2.3 工具调用失败的降级与重试逻辑
3.3 多Agent协作模式
3.3.1 主管-执行者模式在企业研究任务中的应用
3.3.2 Agent间消息传递与结果汇总
3.3.3 协作流程中的冲突处理与最终决策
第四部分 项目实战：企业智能体端到端开发
4.1 实战任务定义
4.1.1 从第一天场景卡片中选定一个开发方向
4.1.2 明确输入数据来源与输出交付物
4.1.3 定义成功标准与可量化指标
4.2 分组开发与里程碑推进
4.2.1 第一里程碑：跑通Harness基础链路
4.2.2 第二里程碑：完成核心Skill接入并产出可用结果
4.2.3 第三里程碑：处理边界案例并完成评估报告
4.3 代码评审与问题定位
4.3.1 小组间互评Agent实现
4.3.2 讲师针对典型错误做代码走查
4.3.3 记录问题并形成改进清单
第五部分 效果评估与生产化考虑
5.1 Agent效果评估方法
5.1.1 构建企业场景测试集与标注标准
5.1.2 多维度评估：准确性、稳定性、响应时长
5.1.3 A/B对比与回归测试流程
5.2 从原型到生产的关键改造
5.2.1 权限体系与敏感操作管控
5.2.2 日志、监控与告警设计
5.2.3 模型版本管理与灰度发布
5.3 安全合规要点
5.3.1 数据脱敏与传输加密
5.3.2 输出内容合规校验机制
5.3.3 人工复核通道与兜底策略
491
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
