★ FEATURED ARTICLE 客户跟我说我要做一个知识库问答系统的时候我就知道这活儿远没有一句话那么轻松。真正到了企业AI项目的交付现场你会发现百分之八十的精力根本不在写模型调用代码上而在把业务问题翻译成技术方案再让方案在客户环境里稳定跑起来这件事上。最近我带完一期FDE实训工作坊核心就是围绕Codex、WorkBuddy、Harness、RAG、Skills和MCP这一整条链路做的这套组合拳在真实交付里帮我解决了很多项目做完了但用不起来的尴尬。这篇文章就把我在工作坊里讲的东西结合我自己踩过的坑完整梳理一遍。不管你是在企业里做AI落地、是自由顾问还是准备往FDE方向转型的工程师这套东西都能让你少走不少弯路。1. FDE不是头衔而是交付闭环的发动机1.1 FDE到底解决了什么问题FDE的全称是Forward Deployed Engineer翻译过来叫前线部署工程师。但说实话这个头衔的含金量不在于字面意思而在于它重新定义了工程师和客户之间的距离感。传统研发模式里工程师坐在办公室需求从产品经理手里转过来再经过设计、开发、测试、运维一长串链条等你写的代码真正跑到客户现场往往已经过去一两个月了。而FDE做的事情完全不同直接驻到客户现场或者在项目最前线在客户还在描述问题的时候就开始动手。这意味着你不能只懂技术你还得听得懂业务、拆得清问题、搞得定现场。在企业AI项目的交付现场FDE要解决的核心问题有三个。第一个叫需求翻译客户说我想要一个智能客服这背后可能是知识库分散、回答不标准、人工成本高三个完全不同的痛点你要把这句模糊的话拆成可执行的技术方案。第二个叫快速验证AI项目的最大风险不是写不出代码而是做出来的东西不符合客户预期FDE要能够在一周之内给出可演示的初版而不是憋一个月然后翻车。第三个叫工程落地demo做得再漂亮上了生产环境就是另一回事延迟、并发、数据更新、权限控制这些脏活累活才是客户真正买单的部分。我常说一句话FDE是半个顾问、半个架构师、半个全栈工程师再加一个完整的不达目的不罢休。这个角色不是Title游戏而是一种交付哲学——你要对项目能不能用起来负责而不是只对自己写的模块负责。实训工作坊里的CodexWorkBuddyHarnessRAGSkillsMCP恰恰是支撑这种交付哲学的六个工具支点。1.2 先算账再动手企业AI项目选型前的五问在企业AI项目里我最反感的就是上来就写代码。不管工具链多强大方向错了工具再好都是白搭。我给工作坊学员定了一个规矩动手之前必须回答完五个问题。第一问数据在哪里、长什么样、有多少这决定了你该用RAG还是该用微调要不要上向量数据库切块策略应该怎么设计。第二问业务方期望的回答形式是什么是要一段流畅的生成式回答还是希望系统从知识库里定位到具体章节、给出引用原文这决定了要不要走完整的RAG链路还是做传统的关键词检索就够了。第三问错误容忍度有多高如果客户是给内部员工做制度问答说错一条可能影响不大如果是给医生做诊断辅助说错一句话就是事故级。第四问数据的更新频率有多快一天一更和一季度一更对索引构建和缓存策略的要求完全不同。第五问谁在用、多少人用、在什么设备上用这决定了你要不要做流式输出、要不要做移动端适配、并发上限设计到多少。这五个问题回答完技术的轮廓就已经出来了。我的经验是好的AI交付不是我有个锤子然后找钉子而是我看到钉子之后决定用锤子、改锥还是胶水。Codex这类编码AI工具当然能大幅提升编码效率但在它之前你首先得知道自己该写什么。这也是为什么我一直强调FDE的核心竞争力是判断力不是打字速度。2. CodexWorkBuddy让AI编码从单机游戏变成流水线作业2.1 Codex的角色定位能写代码的智能体Codex是OpenAI推出的编码智能体工具本质上它做到了你给它一个任务它能自主完成多文件、多步骤的编程工作。和GitHub Copilot那种你写代码它补全的模式不一样Codex更像是一个能听指令、能规划、能执行的实习生——你告诉它帮我写一个RAG服务的FastAPI后端包含文档上传和查询两个接口它会自己去拆解步骤读相关文件生成代码甚至运行测试来验证自己写的代码能不能跑。但这里有一个特别重要的认知偏差Codex不是一个取代程序员的工具它是一个放大程序员产能的工具。我在工作坊里反复强调Codex的强大程度和你的拆解能力成正比。你给它一个模糊的任务它给你一份模糊的代码你给它一个清晰的、有边界条件的、有验收标准的任务它就能给你一份接近可用的交付物。这和带人是一个道理——你说把页面整好看点UI同学大概率会翻白眼你说首页Hero区域的标题改成左对齐背景换成品牌色移动端下隐藏左侧边栏任务就能顺畅推进。我实测下来Codex对企业内网环境、多模块工程、测试补全这类场景特别顺手。尤其是给已有代码补测试这个活儿以前我要花一下午手写mock数据、断言、边界用例现在Codex可以在几分钟内生成一套覆盖不错的测试桩我再人工核对关键逻辑就行。这不是偷懒这是把精力从重复劳动里解放出来去做代码审查和架构决策。2.2 WorkBuddy的定位一切上下文的收口点WorkBuddy是工作坊里的另一个重头戏它的定位是任务工作台。你可能觉得这词有点虚我说得直白一点WorkBuddy解决的是我开了一堆工具但上下文全乱套了这个问题。企业AI项目的交付流程里工程师的桌面通常是一团乱麻编辑器和终端里开着好几个项目浏览器里几十个标签页全是文档和API参考聊天窗口里有客户发来的需求碎片还有一堆截图、Excel、PDF散落在各处。你写代码的时候需要上下文查文档的时候需要上下文汇报给客户拍板的时候需要上下文——但没有任何一个工具帮你把这些上下文统一收口。WorkBuddy做的就是这件事它把任务、上下文、工具调用、结果数据全部聚合到一个工作台上你不需要在不同应用之间来回切换所有和当前任务相关的信息都在一个界面里有序排列。我用一个生活化的类比来解释WorkBuddy如果说Codex是一个技术过硬的工程师那WorkBuddy就是他的项目经理和作战室。工程师只需要低头干活而项目经理负责把需求文档、技术参考、当前进度、下一步计划全部摆在一面墙上让所有人——包括你自己——随时知道我们在哪、要去哪、卡在哪。2.3 日常任务流从拆解到回填的一次完整循环在企业项目的日常推进中我最常用的循环是四步。第一步在WorkBuddy里新建任务卡片。把客户的需求原文、关联的文档链接、验收标准写清楚。这一步的要点是验收标准必须落到可观察的具体表现上比如检索结果中排名第一的文档必须是来源A的某份制度文件而不是回答质量要好。第二步从任务卡片启动Codex会话。WorkBuddy会把当前任务的上下文——包括需求描述、已有代码结构、约定规范——自动同步给CodexCodex在这个上下文里开展工作。这一步最核心的价值是你不需要手动把散落的信息复制粘贴给AI工作任务上下文是连贯的Codex产出的代码自然就更贴需求。第三步Codex完成编码和自测后把结果回填到WorkBuddy的任务卡片里包括改动文件清单、测试结果截图、遗留问题说明。这个动作不是可有可无的形式主义它解决的是AI做了什么事的可追溯问题。企业客户最怕的就是你去跟他说我改好了效果你看吧而改了什么、为什么这么改、测试结果如何才是专业交付的表象。第四步任务复盘。每周在WorkBuddy上过一遍所有任务卡片看清楚哪些任务是当天闭环的哪些拖了三天卡在哪个环节。这一步把个人工作效率变成了可量化的数据也为后续Harness的流程管控提供了输入。我踩过最大的坑是跳过第二步。以前我图省事在WorkBuddy里记录完需求直接跑到终端里用Codex写代码写完再回来更新卡片。结果就是上下文在工具间流转时总有一截丢失——客户说过的一句话或者一个藏在聊天记录里的附件没有进入Codex的视野最后的产出就和需求产生了偏差。现在我把WorkBuddy当成强制上下文中转站所有需求都必须从任务卡片的上下文进入Codex效果稳定了很多。3. Harness给交付流程装上仪表盘和闸门3.1 为什么纯靠人盯人管不住AI项目企业AI项目的交付周期通常很短但参与的角色又很多客户业务方、客户IT部门、你方项目经理、你方工程师、AI工具本身。这种项目里最怕的不是技术难题而是状态失控——没人说得清楚现在做到哪一步了、哪些环节已经验收过、有没有未评估的改动被偷偷上了线。我见过太多项目翻车都是同一套剧本工程师埋头写了两周写出了一个技术指标完美的系统但客户业务方一看发现回答风格根本不符合内部表达习惯然后又花了两周改改完之后IT部门说服务器上跑不了因为依赖装不上、端口被占用等这些全解决了业务方又说数据更新策略不对……你发现了吗问题不是某个环节掉链子而是整个流程里没有任何闸门在关键节点拦住错误。Harness这个名字本身就是缰绳、控制装置的意思它在我的工作流里承担的角色是交付流程管控层。它不是某个具体软件而是一套用配置和管理工具搭起来的状态机每个交付阶段都有明确的入口条件、操作步骤、验收检查和出口条件只有通过检查流程才能继续往下走。3.2 我在工作坊里用的一个简化Harness配置在一个RAG知识库交付项目中我会把流程拆成六个阶段需求确认、数据盘点、知识库构建、检索链路搭建、Agent与工具集成、联调验收。每个阶段都定义好输入、执行、检查三个核心节点下面是我实际用的一个简化配置示例stages: - name: data_inventory entry_condition: requirements_confirmed true actions: - collect_documents - verify_sensitive_data_filter - count_chunks_estimate exit_check: - all_documents_have_source - sensitive_data_mask_rate 100% - name: knowledge_base_build entry_condition: data_inventory_status passed actions: - chunking_pipeline - embedding_job - vector_index_build exit_check: - chunk_count_in_expected_range - sample_query_recall_rate 80% - name: retrieval_test entry_condition: knowledge_base_build_status passed actions: - build_retrieval_eval_set - run_retrieval_test - analyze_miss_cases exit_check: - retrieval_pass_rate 85% - no_blocking_bug_in_p0你可以看到每个阶段都有明确的入口条件、执行动作和出口检查。出口检查不是走过场它往往意味着客户业务方在这个节点必须确认签字。我特别坚持一点AI项目中最容易混过去的验收环节恰恰是客户最关心的那几个——比如回答有没有引用来源、敏感信息有没有被泄漏到提示词里。把敏感数据掩码率100%这种检查写进Harness配置比任何口头承诺都有说服力。3.3 状态可视化之后发生了两件好事引入了Harness这套流程管控之后我明显感受到两个变化。第一客户信任度大幅提升。因为你不只是在讲故事而是打开一个实时仪表盘给客户看当前进行到哪个阶段、上个阶段的问题清单是否清零、当前的阻塞项是什么。客户不需要天天追着你问进度他自己就能看到一切。这种透明感在企业采购决策里是极具杀伤力的加分项它传达的信号是你对项目有掌控力。第二团队内部交接成本骤降。企业项目的另一个常态是人员流动——项目到一半主力工程师可能要抽去做别的项目。没有流程管控的时候新人接手像考古翻聊天记录、猜代码意图、试环境配置。有了Harness每个阶段的产物、决策、验收结果都有迹可循新人只需要按图索骥把进展补齐过渡期可以从好几周压缩到两三天。这个环节看起来不直接产生代码但它决定了你的代码能不能被客户看到。我的观点一直是在企业AI交付里流程管控能力和技术能力同等重要甚至更重要——因为你面对的是甲方是需要定期汇报的老板他们无法直接感受到你写的Retriever有多优雅但他们能感受到流程是否顺畅、状态是否清晰、项目是否有掌控感。4. RAG知识库能检索和能答对是两码事4.1 一个标准RAG链路的五个环节RAG全称Retrieval-Augmented Generation检索增强生成是目前企业知识库问答落地最主流的技术路线。它的核心思想不复杂在让大模型回答之前先从你自己的知识库里检索到相关内容把这些内容作为上下文拼进提示词再让模型基于这些内容和自身的语言能力生成回答。一套标准的RAG链路可以切成五个环节。第一文档清洗与解析你拿到手的PDF、Word、Excel可能还有扫描件和图片这些原始格式不能直接切块得把它们解析成纯文本或结构化数据。第二文本切块Chunking把长文档切成合适大小的文本片段这个过程直接决定了后续检索的粒度。第三向量化Embedding把每个文本片段用嵌入模型转成向量也就是一串能表示语义的浮点数存入向量数据库。第四检索召回Retrieval用户提问时把问题也转成向量在向量数据库里找最相似的Top K个片段。第五合成回答Generation把召回的片段和原始问题组装进提示词大模型基于这些材料生成答案并附上引用来源。很多团队在demo阶段跑通了这五个环节就认为大功告成但我见过太多项目在能跑通和能答对之间隔着一条巨大的鸿沟。怎么跨越这条鸿沟才是RAG工程化的真正挑战也是下面要展开的内容。4.2 RAG的三个瓶颈以及我的处理策略RAG在实际项目里的表现远不如论文里的基准测试那么漂亮。根据我的实战经验最常遇到的瓶颈有三个。第一个瓶颈是召回质量用户问了一个问题但检索回来的Top K片段里根本没有包含正确答案的内容。这通常有三个原因——切片粒度不对、embedding模型和领域不匹配、或者用户问题的表述方式和知识库里的原文差距太大。我的处理策略是先做检索测试而不是直接测回答质量。我会准备20到30个来自真实业务的高频问题先不看生成回答只看检索回来的内容是否命中正确答案。如果这一层就命中不了后面模型再强也白搭。第二个瓶颈是切片策略文档切块的大小和重叠方式对检索效果的影响远超很多人的预期。切得太细单个片段语义不完整切得太粗片段里又混杂了太多无关信息。我通常在项目前期会用固定窗口语义边界修正的组合策略后面会给出具体的参数配置。第三个瓶颈是幻觉控制检索结果明明是对的但大模型在生成回答时还是自己脑补了一些知识库里不存在的细节。控制幻觉不是靠提示词写请严格根据上下文回答就能完全解决的——你需要两层防护第一层是检索层面的严格约束保证只让模型看到切切实实能支撑答案的内容第二层是生成层面的引用强制要求模型在回答里标注自己依据的是哪个文档片段没有依据的内容一律不说。实践下来这种强制引用机制能把主观幻觉率降低一大截。4.3 结构化知识库和向量知识库的选型聊RAG就绕不开一个话题到底该用结构化的知识库还是用基于向量的知识库我反复被问到这里给出一个清晰的对照。维度结构化知识库向量知识库存储形态表格、图谱、关系型数据向量索引语义相似度匹配适合场景强关系、强规则如人员信息、组织架构、会计分录非结构化文档如制度文件、技术手册、会议纪要查询方式精确匹配、SQL查询、图查询语义检索、模糊查找优点精确、可控、可解释灵活、无需人工抽取字段、支持模糊提问缺点建库成本高、维护成本高存在误召回、可控性稍弱典型案例KG知识图谱、企业主数据平台企业内部制度问答、产品文档问答很多项目的真实情况是混合使用。比如客户问2024年各部门的差旅报销标准是多少这是一个强规则查询用结构化知识库比如一张部门差旅标准表来回答精确率最高而客户问我们的报销制度里有哪些审批环节这是一个语义开放型问题靠向量检索从制度文档里把相关段落捞出来更合适。我处理这类问题的姿势是凡是能结构化、且需要精确计算或强关联推理的优先把数据整理进结构化库凡是长文本、且回答允许一定自由度的走RAG向量链路。然后在Agent层做一个路由判断根据用户问题的意图把请求分发到对应的知识源。4.4 一个可上手的切块与召回参数配置作为FDE你在客户现场不可能用一整套复杂的调优框架起步你需要一套开箱即用的参数作为起点再根据实测结果调整。下面是我在Mac本地搭建RAG知识库时最常用的一套起步参数配合LangChain或LlamaIndex都能直接跑。切块策略选用递归字符文本切分器核心原因是用一组固定分隔符从粗到细去切能保留标题、章节这类自然结构而不是粗暴按字符数硬切from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size800, chunk_overlap96, separators[\n\n, \n, 。, , , , ., , ] )这里chunk_size取800是基于中文表达习惯的经验值800字符大约对应一个中长篇自然段落内容足够完整但又不至于太杂。chunk_overlap取96也就是重叠约12%目的是让跨切块的上下文信息不至于完全断裂。separators的排序值得研究先按段落切再按句子切最后按词切这样可以尽量让每个chunk的语义保持完整而不是从句子中间硬截断。向量化和召回的配置我建议这样起步嵌入模型中文业务场景优先考虑bge-large-zh这类中文语义理解表现更稳的模型英文或混合场景可以用OpenAI的text-embedding-3-small或类似通用模型。向量数据库项目初期选择Chroma或FAISS这类轻量级方案即可先跑通链路命中率验证之后再根据数据规模决定是否迁移到Milvus或ES。召回数量Top K从K6起步配合chunk_size约800字符足以覆盖一个中等长度的文档核心内容后续通过评测集来调整K值和相似度阈值。我常跟学员说参数配置只是起点真正拉开差距的是评测集的质量。好的评测集不是随机抽几个问题而是要覆盖高频业务需求、边界场景和容易混淆的干扰项。每次调整切块策略或召回参数都拿同一套评测集跑一遍用数据说话而不是凭感觉。这才是RAG工程化的正确打开方式。5. Skills与MCP能力封装的两种思路一个闭环5.1 Skills把会做变成可复用Skills这个概念在AI Agent领域越来越受重视它的本质是把一系列操作步骤封装成一个可复用的技能包。你可以把一个Skill理解成一本标准化操作手册定义这个技能是干什么的、输入什么参数、执行哪些步骤、最终输出什么结果。有了Skill之后AI甚至你手下的工程师遇到同类任务时不需要从零开始直接调用对应技能就行。对企业AI交付来说Skills的价值体现在两个层面。第一个层面是把AI的能力沉淀下来项目一期你花了大量精力调出来的RAG检索链路如果只是藏在代码里下一个项目等于从零再来把它封装成一个Skill——比如制度文本RAG检索输入是问题上下文输出是召回的Top K片段加相关包配置——你就在不同项目之间实现了能力的复制。第二个层面是降低团队的协作门槛不是每个人都有你那么强的Prompt能力但Skill把优秀Prompt执行流程固化下来了任何人拿到Skill都能达到你六到七成的效果。Skill不需要做得特别庞杂我反而认为粒度应该小一点、职责单一一点。比如我会把文档清洗单独做一个Skill、把切块参数调优单独做一个Skill这样每个Skill都容易理解和维护。你封装的是一个动作模式不是一个项目本身。5.2 MCP给所有工具装一个通用接口MCP全称Model Context Protocol模型上下文协议。它的定位用一句话概括给AI世界里所有的工具和数据源提供一个像USB-C一样的统一连接标准。你在企业AI项目里会遇到大量工具连接问题代码仓库里的信息怎么让AI读到数据库里的表结构怎么让AI查询设计稿的标注怎么让AI理解团队的Wiki内容怎么让AI在回答问题的时候引用在没有MCP之前每个连接都要单独开发定制化的集成代码工作量大且不可复用。有了MCP之后工具方提供MCP ServerAI应用通过标准协议调用这些Server就像USB-C一样——你不需要换线只需确认两端都支持这个标准接口。我在工作坊里演示过一个很简单的MCP Server用Python的FastMCP框架十来行代码就能把一个知识状态查询工具暴露给AI助手from fastmcp import FastMCP mcp FastMCP(knowledge-status) mcp.tool() def query_kb_status(kb_id: str) - dict: 查询指定知识库的构建状态和检索命中率 # mock逻辑真实项目中这里会查数据库和向量索引 return {kb_id: kb_id, chunk_count: 12034, recall_rate: 0.86} if __name__ __main__: mcp.run(transportstdio)这段代码的逻辑很简单定义了一个叫query_kb_status的工具函数MCP框架会自动把它暴露成标准工具AI助手只需要知道我有一个查询知识状态的能力按MCP协议传参数就能调用不需要关心服务端是用什么语言写的、部署在哪里。这就是MCP意义的直观体现。5.3 SkillsMCP一起用常见的封装套路在完整的企业AI项目里Skills和MCP是互补关系我经常把它们一起用。Skills回答的问题是这个任务应该怎么做MCP回答的问题是这个能力怎么被统一调用。实际操作中我会用MCP把底层数据源和工具暴露出去然后用Skill把业务层面的操作模板封装起来。一个典型的落地场景客户需要一个合同关键条款提取助手。底层我用MCP连接合同文件存储系统和数据库让AI能看到合同文件、能查询合同元数据。上层我封装一个Skill叫合同条款提取规定了从读取文件、分块、调用大模型提取条款、格式化输出到写回数据库的完整操作路径。AI接到一个新合同时调用这个SkillSkill内部通过MCP和底层系统打交道——整个流程对使用者完全透明。这套组合拳的最大收益是交付物变成资产。项目成功交付后你留下来的不仅仅是一堆代码而是一套可以被下次复用的MCP连接器和Skills技能包。客户自己新招的工程师可以快速接手维护你也可以把这些资产复用到其他客户身上。对FDE这个角色来说这种资产化的交付方式才是真正意义上的越做越轻松。6. 常见问题排查与避坑实录6.1 一张速查表解决六个高频问题工作坊和实战项目里我遇到的高频问题翻来覆去就那么几个。这里整理成一张速查表方便你直接在项目现场对照排查。问题现象排查方向处理建议Codex会话启动时报端点调用失败任务卡住先看本地配置文件路径和权限再确认API端点地址配置是否被改动过检查配置文件格式和端点地址是否正确确认网络环境后重启会话不要盲目反复重试先看日志WorkBuddy显示英文界面部分功能找不到检查显示语言和区域设置部分版本的国际版与本地版功能布局不同在设置里切换语言国际版看菜单栏对应位置确认是哪个版本别在旧版里找新版的功能入口RAG检索召回率低答案总是不对重点检查切块策略和embedding模型选择先跑检索评测集看召回内容是否命中原文调chunk_size和overlap考虑换中文语义理解更强的embedding模型MCP Server连不上工具调用超时检查MCP Server是否在运行、配置的端口或transport方式是否匹配先手动运行MCP Server看报错确认调用方配置的transport是stdio还是SSE检查服务端日志Harness状态卡在某个阶段不前进检查该阶段的exit_check是否有某项未通过把check项逐个跑一遍未通过的项单独处理切忌跳过检查强行推进阶段大模型回答出现知识库之外的幻觉内容检查检索结果是否确实支撑答案提示词是否过度开放强制要求模型依据召回的片段回答并标注引用对无法从召回片段支撑的问题直接回复未找到相关信息我特别想强调第一行那个问题。Codex这类AIAgent在企业内网环境跑的时候环境变量、配置文件、网络策略的复杂性远超个人开发环境的想象。遇到会话调不通第一反应不要是重装或重启而是把配置文件和日志打开按上面表格的线索顺藤摸瓜。大多数情况下问题出现在配置文件的格式错误或者端点地址的拼写偏差上。6.2 几个我认为最值得避开的坑第一个坑是拿向量数据库解决一切。我见过不少团队客户说要知识库就直接上向量库把所有文档一股脑丢进去。结果面对满勤奖和绩效奖能不能同时发放这类强规则问题向量检索给出来的答案模棱两可客户满意度极低。我的建议是在项目需求拆解阶段就认真区分哪些知识适合向量化、哪些应该结构化混合方案通常是企业场景的最优解。第二个坑是忽略数据更新机制。很多知识库上线时跑得很漂亮过了两周就没人用了。原因无外乎两个一是里面的文档还是两周前的旧版本客户问了两次都得到过期答案就不信任了二是没有自动化的更新管道知识库新文档进来要靠工程师手动跑脚本。企业级知识库必须在一开始就设计好数据更新机制——是定时抓取、还是人工审核后入库都要在Harness配置的阶段检查里明确下来。第三个坑是不做效果评测就上线。AIAgent项目最大的特点是没有标准答案你可能在demo阶段觉得效果挺好但一旦上了真实数据和真实问题效果可能惨不忍睹。我现在每个项目都必须先花时间构建评测集哪怕只有三五十个问题。这不是大学作业里的实验报告而是企业项目里保护你自己、也保护客户的手段没有评测数据你怎么证明你的系统比之前快、比之前准第四个坑是Skill封装得太大、太杂。很多团队为了复用最大化把整个业务链路封装成一个巨大的Skill结果就是任何一个环节有变化整个Skill都要改完全失去了复用的意义。Skill应该像乐高积木一样小而独立拆得越细组合的空间越大迁移到新项目的成本越低。第五个坑是我个人最痛的教训轻视客户环境的隐形约束。开发环境里跑得丝滑的代码到了客户现场常常因为缺依赖包、端口被封、tls版本不兼容之类的破事卡住。我现在在项目交付收尾阶段会强制走一遍Harness的环境兼容性检查提前在跟客户生产环境一致的容器或虚拟环境里做一次全链路演练。这步只要做一次能省下后面至少一周的救火时间。把思路收回到开头那句话企业AI项目的交付其实就是在复杂业务和快速迭代之间踩钢丝。FDE这个角色之所以越来越被重视就是因为企业不缺技术缺的是能把技术稳稳落进业务场景的人。Codex帮我承担了编码的体力活WorkBuddy帮我把上下文管理得井井有条Harness让交付流程在每个节点都有迹可循RAG让模型真正工作在企业自己的知识上Skills和MCP则让项目经验沉淀成了可复用的资产。这套组合不是哪个公司的官方解决方案而是我在真实交付里揉出来的经验集合你完全可以根据自己手上的项目把它重新编排。每次踩过的坑、优化掉的流程、救回来的项目最后都会变成你自己的交付方法论——这也是FDE这份工作最迷人的地方。
阅读完成 · 觉得有帮助？
)
