上个月被一个做企业服务的客户拉去旁听季度复盘他们今年在 AI 工具上花了六位数预算Codex 买了团队版WorkBuddy 工作台也搭起来了但业务部门最后只丢出一句话AI 很厉害但跟我们没关系。我听完一点都不意外这种“买了先进工具却落不了地”的现场我这两年见了太多。Codex 确实是目前写代码、拆任务、处理长文本的一把好手WorkBuddy 这类智能工作台也确确实实能把多个 AI 能力串成一条流水线。但问题在于模型懂语言不懂业务工具自带能力不带你们的流程。买回来的那一刻它只是一台没有接线的设备没人做过“现场安装”也没人给它配好“企业知识骨架”。我后来自己花了大约两个月用一套组合打法帮两家企业把这个问题解决了核心就是两个缩写词FDE 和 AKA。FDE 是一套 AI 落地的现场工程流程AKA 是给智能体装上的企业知识架构。这篇文章就把完整思路、配置过程和踩过的坑都摊开讲给正在被“AI 买了但没落地”折磨的同学一份可以直接抄的作业。1. 工具买了不少AI 却没落地问题出在“能力”和“业务”之间先别急着怪模型。Codex 和 WorkBuddy 的能力在演示环境里是没问题的真上了生产环境之所以失灵问题往往出在“能力面”和“业务面”之间那一大段空白里。这一段空白既不是模型能自己补的也不是云厂商会替你补的。1.1 默认状态下的 Codex 和 WorkBuddy只是“高级玩具”Codex 默认是躺在终端里或者躺在桌面应用里的。一个业务同事打开它看到的是一块空白对话框不知道自己要干什么也不知道它能干什么。开发同事用起来爽是因为他自己心里清楚要解决什么问题、要调哪个接口、要写什么测试这不是 Codex 的能力这是这位开发同事本身的能力。WorkBuddy 的默认状态稍微好一点至少有个工作台界面但是行业里 90% 的工作台搭建就是把几个智能体图标摆上去配上几句“你是某领域专家”的提示词。员工点进去聊两句发现输出很泛既不知道公司的产品细节也不知道业务的术语和红线很快就当作玩具丢掉了。这不是员工不肯用新技术而是工具没有跟他的真实工作发生任何关联。真实工作是有上下文、有格式、有审批链、有部门黑话的默认的通用模型什么都不知道。1.2 我见过最典型的三种“买了不落地”现场第一种叫“没有入口”。Codex 装好了WorkBuddy 开通了但员工该写代码还是写代码该用 Excel 还是用 Excel。工具和每天的固定工作流中间是断的没有人告诉模型“你在这个流程的第几步、给我什么格式的输出”。第二种叫“没有信任”。模型第一版上线回答里有一个数据错了或者引用了一份过期制度业务负责人立刻拍板“这东西不行”。然后整个项目被冷藏再也没人敢碰。这是 AI 落地最常见的死法不是被竞品打败的是被一次幻觉吓死的。第三种叫“没有边界”。更危险老板说你们放开用于是模型被拿去干它不擅长的事比如直接生成对外承诺、替员工做财务判断。出了事之后责任全算在 AI 头上但本质上是没人给它设权限、定边界。这三种现场靠买更贵的模型解决不了靠换一个产品名称也解决不了。它们都是工程问题不是模型问题。1.3 为什么不能只怪“模型不够聪明”我经常被问到是不是应该换一个更强的模型我的回答通常是先把你手里的模型用明白再说。OpenAI Codex 这类模型的长处是理解长上下文、结构化输出、代码生成和任务拆解WorkBuddy 这类工作台的长处是承接多智能体协作、调用企业工具和沉淀会话。它们不是“不聪明”而是默认带的是“通用常识”不是“企业知识”。通用常识知道“退换货一般有七天无理由”但不知道你们公司“特殊渠道订单不退不换、赠品不算在退款金额里”通用常识知道“售后工单要分类”但不知道你们客服部的分类里有“售后维权”和“投诉升级”两套不同的处理路径。没有这些企业知识的注入再强的模型也就是个聪明但没经验的实习生。所以我的核心结论是落地问题的本质是把“强通用能力”改造成“强特定场景能力”需要的是现场工程方法和企业知识工程。这就是接下来要讲的 FDE AKA。2. FDE把“AI 落地”当成现场工程来做FDE 这三个字母不同行业有不同解释在做 AI 落地的时候我把它定义为“现场部署工程与落地流程”有时也叫“Full-cycle Deployment Engineering”。你完全不用纠结名字重点是一套可复制的步骤勘测、适配、验证、移交。这四步是我做所有 AI 项目都不跳过的骨架。2.1 FDE 不是岗位是一套四步流程勘测、适配、验证、移交勘测是在动手之前先搞明白业务现场的真实情况。要到业务部门去问清楚他们每天最耗时间的任务是什么、哪些活儿重复、哪些活儿需要查很多内部资料、哪些决策错了代价很大。这一步最容易被跳过因为技术团队天然喜欢先玩工具但少了勘测后面全是自嗨。适配是把模型能力映射到具体任务上。Codex 适合自动生成结构化文本、写脚本、总结长文档WorkBuddy 适合把多个技能编排成一个完整流程。适配阶段要产出“能力对照表”这个任务由谁来触发、模型做什么、人工审什么、输出到哪里去。验证是灰度跑起来拿真实数据看效果。不是看它回答得是否流畅而是看它的输出有没有被人直接采用、需要修改多少、有没有踩到红线。验证阶段必须有明确的指标哪怕一开始很粗糙也行。移交是把它交还给业务团队。你要做配置文档、培训课、常见问题手册更要设置一个“值班人”。没有移交环节项目一结束工具就死在下一个人手里了。2.2 场景盘点把业务需求翻译成模型能完成的任务我在勘测阶段会用一个简单的表让业务负责人自己填。字段分别是部门、任务、频率、单次耗时、痛苦点、现有工具、可接受的错误率。填这个表的过程本身就是一次业务梳理。举个例子售后部门填的是“工单分类每天 200 条每条 5 分钟容易分错现有系统没有自动打标功能”。那这个场景就非常适合切给 AI因为它是高频、规则相对清晰、错误有兜底人工审单的任务。相反如果填的是“处理工商投诉每周 3 次出错后果严重”这种场景就不适合第一阶段做。翻译任务的时候要把“人话”翻译成“模型话”。业务说“帮我看看这个工单该怎么回”落到模型任务上就是输入工单描述输出建议分类、建议话术、风险提醒、需要人工确认的信息四个字段。这样模型才知道你要的是结构化结果而不是一篇散文。2.3 能力映射Codex 和 WorkBuddy 各自该干哪一摊工具不是越多越好关键是分工清楚。在我的项目里Codex 和 WorkBuddy 的分工通常是这样Codex 负责深度推理、代码生成、长文档分析、数据清洗这一类“单点高智力”的活WorkBuddy 负责调度、编排、多智能体协同、对接企业现有系统这一类“流程型”的活。如果只买了一个工具也没关系。FDE 的核心理念是“用现有工具先跑通一个闭环”不是“集齐所有工具再开工”。我在实际项目里见过有人非等 WorkBuddy 的某个插件上线才肯推进结果一等就是三个月业务热情全凉了。先用手头工具做出一版能看的成果比追求完美架构重要得多。能力映射还有一个容易被忽略的维度谁触发。Codex 更适合“开发者在终端触发”和“通过 API 被工作台触发”WorkBuddy 更适合“业务人员在聊天框触发”和“钉钉/飞书/企业微信里触发”。入口决定了使用率入口越靠近日常干活的地方落地率越高。2.4 最小可行改造不要一上来搭“企业级 AI 工作台”企业里最长见的错误是一上来就搭一套“全公司统一的 AI 中台”要接这个系统、那个权限结果项目组陷在内部协调里三个月出不了成果。我的建议是走最小可行改造的路线选一个部门、一个场景、一个工具、两周时间先把一个端到端闭环打通。这条路线的逻辑很简单AI 落地的阻力主要是信任问题信任只能靠一个看得见、摸得着、解决真实痛点的案例建立起来。你做一个“售后工单自动分类”的场景比做十页《企业 AI 建设规划白皮书》有用得多。具体操作上我会把 WorkBuddy 的工作台先收缩成一个“单场景工作台”里面只放一个技能叫“售后工单助手”输入是一个工单编号或一段描述输出是一张分类建议卡片。跑通之后再往里面加第二个技能。这样一个季度下来工作台里会自然长出三到五个真实在用的技能而不是最开始就摆十个“专家”图标。2.5 反馈闭环会话记录怎么变成持续改进的素材FDE 的最后一步移交必须包含反馈闭环。每一轮 AI 输出员工是直接用了、改了、还是弃了这个数据是整个系统唯一真实的“评分卡”。我会让 WorkBuddy 在技能里加一个“结果反馈”按钮员工点“采纳”或“修改”修改后的文本回收到知识库里。每一周项目负责人把这一周被修改最多的 10 条案例拿出来判断是知识库缺东西、提示词没表达清楚还是模型被误导了。这个过程有点像给新人做入职培训先给手册他做错了你把错的地方回填到手册里他下一轮就进步了。智能体也是这样只不过它的“入职培训”是持续进行永不停歇的。3. AKA给智能体装上一层“企业知识骨架”解决了“谁用、在哪用、怎么开始用”之后接下来要解决的是“模型凭什么能答对”。我的答案是一套我称为 AKA 的工程方法全称是 Agent Knowledge Architecture也就是“智能体知识架构”。它的作用是在模型和真实业务之间加一层企业自己的知识骨架。3.1 AKA 不是什么神秘系统就是三层知识结构AKA 不是某个厂商卖的现成系统而是一种建模方法。我认为企业知识只有放进三层结构里模型才真正“懂业务”第一层是原子知识第二层是流程知识第三层是判断知识。原子知识就是事实和术语比如产品规格、价格政策、部门职责、客户类型、内部黑话。“我们家的订单编号前四位代表渠道CD 开头是京东渠道”这就是原子知识。没有它模型连你们在说什么都听不懂。流程知识是步骤和规则比如售后处理的标准路径先核对订单、再判断原因、然后决定退款还是补发、最后跟客户确认。模型知道了流程才知道在什么节点该输出什么内容不会一上来就给人开退款单。判断知识是最难积累的一层它是“什么情况可以变通什么情况必须升级”。比如“客单价低于 50 元的订单退款后不用追回赠品客单价高于 500 元的订单必须人工复核”。这类经验通常只存在于老员工脑子里需要业务负责人一条一条喂给系统。3.2 为什么提示词越长效果反而越差很多人做定制时第一反应是写一个几百行的提示词把公司制度全塞进去。我试过几次效果非常差。模型在长提示词里会“迷失”尤其是当知识之间互相矛盾、优先级没有标清楚时它的输出会变得又长又空。AKA 的做法是“知识外置精确定位”。不要把全文制度塞进提示词而是把制度拆成小知识块放到知识库或者 Skill里让模型在需要的时候检索。提示词里只保留三层骨架你是什么角色、你当前的步骤、你必须输出的格式。你可以把提示词理解成“岗位说明书”很少会有人因为读一本百科全书的条目就能把岗位干好但一个带着工作手册的新人遇到具体问题翻到具体章节反而能上手。AKA 就是那本可以随时翻阅、持续更新的工作手册。3.3 Codex 的 AKA 配置用 AGENTS.md 把业务规则焊进去Codex 有一块专门用来放项目规则的配置文件通常叫 AGENTS.md放在项目根目录下Codex 在读取代码库时会自动把它作为上下文。我强烈建议所有做深度定制的团队都用起来。不要把 AGENTS.md 写成一篇文章要写成一组“规则卡片”。下面是一份我实际用过的最小示例# AGENTS.md ## 项目背景 - 这是企业内部的售后工单处理辅助项目 - 目标根据工单描述输出分类、首答草稿和风险提示 - 所有输出必须使用中文保持客服语气 ## 数据规范 - 订单编号格式CD开头为京东渠道TB开头为淘宝渠道 - 工单分类物流问题、质量问题、无理由退货、投诉升级 - 以上四个分类不允许自定义新增 ## 行为规则 - 先判断订单渠道再判断问题类型 - 客单价大于500元的订单必须给出“建议人工复核”标记 - 不允许直接承诺赔偿金额只允许给出赔偿区间建议 - 引用知识库内容时必须标注“参考文档编号”这样配置之后Codex 的输出稳定性会明显上升。因为它每一次回答之前都会先看到这套业务规则相当于在动手干活之前先被判了一遍“岗位红线”。3.4 WorkBuddy 的 AKA 配置把 Skill 写成可维护的配置WorkBuddy 里对应的概念是“技能Skill”也就是一套可以被聊天框触发的工作流。很多教程会教你怎么建技能但很少告诉你技能维护才是重点。我会给每个 Skill 配一个最简配置模版包含四块触发词、输入输出、知识库引用、边界规则。下面是一份售后工单助手的 Skill 配置示例名称: 售后工单助手 触发词: 工单助手, 售后分类, 帮我回工单 输入: - 工单描述文本 - 可选: 订单编号 输出: - 建议分类 - 首答草稿 - 风险提示 - 需要人工确认的字段 知识库引用: - 产品常见问题FAQ - 退换货与退款规则 - 客服语气规范 边界规则: - 仅输出建议不执行发送 - 涉及赔偿金额时只给区间 - 检测到客户情绪激烈时自动建议转人工这个配置的精髓在于“边界规则”。让 AI 只做“建议者”不做“决策者”是业务团队愿意放行的关键。你越是想让 AI 独立完成整个流程业务团队的抗拒就越大你越是在边界上让步AI 反而越容易进场。3.5 参数调优不是温度越低越好也不是上下文越长越好知识骨架搭好之后还要调四个我常用的参数。第一是 temperature中文叫随机性。需要输出标准化结果的场景我都会把它调到 0.1 以下甚至直接设成 0需要做头脑风暴的场景才调高到 0.7 左右。第二是 top_p我通常保持默认或者跟随温度一起调整很少单独大幅改动。第三是检索数量也就是从知识库里取多少个相关片段我一般控制在 3 到 5 个之间太多了模型会抓不住重点太少了又容易漏信息。第四点是上下文窗口也是最容易被误解的。很多人觉得 Codex 支持超长上下文就把整年的聊天记录全塞进去结果模型处理得很慢而且注意力被无关内容稀释。正确的做法是“够用就行”把和当前任务最相关的知识通过 RAG检索问答捞出来而不是把整个知识库铺开。上下文长是能力能不能用好长上下文是工程。4. 一次完整落地实录售后工单分类与首答草稿说了这么多原则我用一个真实做过的落地案例串一遍完整流程。这个案例来自一家电商公司总共花了两周完成首版效果和踩坑过程都很典型。4.1 为什么会选售后工单这个场景当时这家公司的售后部门每天要处理两三百条客户工单每单员工要花十分钟左右先查订单再看聊天记录判断问题类型再找对应规则最后手写一段答复。工单量大、人员流动也快老员工带新员工至少要一个月才能独立上手。这个场景有三个非常适合启动的特点第一是高频每天都有效果可以被迅速验证第二是规则相对清晰主要流程是查单、分类、给答复第三是容错友好AI 只生成“建议草稿”最终发送必须由人工点击这给了团队极大的安全感。选场景是我一直强调的 FDE 第一步。别找那种“很厉害但很冷门”的 AI 应用找一个每天都让大家头疼、又不会因为犯错造成严重后果的任务才最容易跑出正循环。4.2 按 FDE 流程走一遍200 条历史工单和 3 条边界勘测阶段我先把售后主管和两个老客服拉来聊了两小时拿到三张纸一张是现有的工单分类定义一张是不同问题对应的处理路径还有一张是客服老手口中“只可意会”的经验规则比如“客户一上来就骂人的先别谈规则先安抚”。适配阶段我从系统里导出了过去三个月的 200 条历史工单每条都带处理结果。不是拿这 200 条直接喂模型微调而是让它们成为验证集模型跑完一遍后我和售后的主管一起看结果准不准规则漏没漏。验证阶段我们把问题集中在三块分类准不准、首答草稿是否可用、风险提示是否覆盖。第一版结果分类准确率大约 68%听起来不高但已经把员工从“每条都要自己从头判断”变成“只需要在系统给的建议上改一改”这个体验是完全不一样的。我们还定了三条边界写进了 WorkBuddy 的 Skill 配置里模型只给出建议不替代客服发送涉及补偿金额只给区间客户情绪化用语触发“转人工”标签。这三条边界是整个项目能被业务接受的最重要原因。4.3 按 AKA 配置落地知识库、技能和权限的完整示例知识库方面我们先把最常见的三份文档做了结构化处理产品 FAQ 清理成“问题-答案-来源文档编号”的格式退换货规则拆成“条件-动作-限制”的三段式客服语气规范整理成“要做”和“不要做”两个清单。Codex 侧的 AGENTS.md 我放进了前面提到的那组规则。WorkBuddy 侧建了一个“售后工单助手”技能触发词设为“工单助手”。两个工具共用同一个知识库知识库放在公司内部的文档系统里每周更新一次更新的同时生成变更记录这样模型引用时可以带上“文档版本号”避免旧规则被当成现行规则引用。权限这块是最容易忽略的。我们给模型读取的权限只开放了工单分类、FAQ、退款规则这三类文档没有开放客户聊天记录里的原始完整内容也没有开放财务和库存数据。因为模型用不到那么多信息权限给得越宽幻觉的空间越大出事的概率也越大。4.4 灰度验证看什么指标才算真的“落地”了灰度验证我没有只看一个准确率而是设了三个维度的指标。第一是“采纳率”员工点击“直接复制使用”的比例这说明输出质量真的过关第二是“修改成本”员工在一份回答上平均改动多少字这个指标比准确率更能反映效率提升第三是“异常率”有没有出现违背边界规则的回答比如擅自承诺赔偿、漏标记高金额订单。跑了两周之后结果大概是这样的工单分类的准确率从 68% 提升到 84%主要靠的是把判断知识补齐比如“赠品破损”究竟算物流问题还是质量问题这类老员工眼里的常识首答草稿的平均修改幅度从“几乎全部重写”变成“改两三个词就能用”异常率为 0没有出现越过边界的回答。处理单个工单的平均耗时从 10 分钟降到了 4 分钟左右。但说实话降本不是我最看重的我最看重的是售后主管开始主动说要给 WorkBuddy 增加新技能。当业务方从“被推着用”变成“追着要加功能”这个项目才真正算落地。4.5 复盘哪些指标变好了哪些坑还没填复盘的时候我们特别坦诚地列了三个还没解决的坑。第一个是长尾问题依然吃力冷门产品、特殊渠道订单的分类准确率明显偏低原因是这类样本本身只有十几个模型能参考案例太少。第二个是情绪检测还太粗我们用关键词触发“转人工”偶尔会错杀客户说一句“你们太让我生气了”就被标记成高风险反而增加了人工工作量。第三个是知识库维护有人的问题虽然流程定了但文档更新这事很容易被遗忘。后来我们加了一个“月底知识盘点”的提醒让售后主管和客服老手各出 10 条新遇到的情况回填到知识库里这项工作成了每个月固定的半小时会议。这些问题现在还在磨但整套系统已经从一个“Demo”变成了“每天有人用的工具”。这个转变不是靠模型升级带来的是 FDE 流程和 AKA 知识骨架一点点堆出来的。5. 常见问题与排查技巧实录最后整理一份这段时间高频踩到的问题速查表很多坑是一模一样的你提前看一眼能省下不少排查时间。5.1 高频问题速查表问题Codex 启动时报“model not supported”比如某个版本号打错了。原因配置的模型 ID 当前账号不可用或者手滑写成了不存在的模型名。处理打开配置文件改成账号里真实可用的模型 IDCLI 的 models 列表里能看到。问题WorkBuddy 技能不触发聊天框里发了触发词没反应。原因技能名称、触发词或 frontmatter 格式不对或者技能没有被发布到当前工作台。处理先看技能配置的 YAML/JSON 有没有语法错误再确认是否点过发布/保存版本。问题Codex 读取不了组织设置比如无法加载 org 信息。原因登录态过期、组织选择错误或账号权限不够。处理重新登录检查账号所属组织让管理员确认该账号有项目访问权。问题模型输出经常引用旧制度。原因知识库更新了但模型的检索结果没有跟着更新或者旧文档没下线。处理把过期文档放进“已下线”列表并确保文档有版本时间字段AGENTS.md 里加强制校验规则。问题员工普遍说“AI 反应慢”。原因很多情况下不是模型慢而是每次调用时塞了太多无关上下文或者是多个动作串行等待。处理把一次超长任务拆成多个短任务先快速给一版草稿再深入完善体验会好很多。问题模型总是话很多给一堆没用的大道理。原因输出缺少格式约束没有把“要什么字段”写在提示词里。处理在提示词里改成结构化输出模板并且只允许输出三个字段以内的内容。5.2 几个容易被误判成“模型不行”的问题最常见的误判是“它答错了就是模型不够聪明”。我见过一个项目模型把红头文件的生效日期理解错了团队直接判定大模型不可靠。查到最后发现是知识库里文档的 OCR 扫歪了一个版本号跟模型一点关系都没有。数据和知识的问题不要急着甩锅给算法。第二个误判是“提示词写得越细越好”。有个同事把客服话术和财务退款规则写在一起结果模型在客服开场白里开始聊财务条款。拆开之后两者各归各问题立刻消失了。提示词设计要守“单一职责”原则就像代码函数一样一个提示词干一件事。第三个误判是“上下文越长越好”。我把一家企业的一整年客服记录塞进去之后模型每次处理前都要“阅读”很久而且容易被更早的无效对话带偏。压缩到最近 30 条相关对话效果反而好了。长上下文是有价值的但只有配合检索和裁剪才会有价值。5.3 关于“员工不愿用”的另一种解法员工不愿用我觉得主要不是人抗拒技术进步而是工具没有进入他的工作动线。你让客服从工单系统里复制一段描述再切到 WorkBuddy 粘贴等结果再复制回来这个操作本身就是一种惩罚。体验不好的工具怪人不用是不公平的。解法是把入口做得无限短。比如在工单系统里加一个“一键发送给 AI 助手”的按钮让系统自动把工单信息填充到 WorkBuddy回来后自动把建议草稿填充回回复框。员工几乎感觉不到自己换了一个工具只是感觉自己“打字变快了”。这一小步往往比三个月的大型推广有效得多。另一个经验是把荣誉感给业务方。我会在工作台界面上标明“售后知识库维护人张姐”让懂业务的老同事感觉到系统里有自己一份心血。谁的知识被采纳得多、谁的文档被模型引用得多是可以做成一个小看板的这会极大地提高知识库的维护质量。5.4 上线前必须检查的 8 个点每次项目正式灰度之前我都会拿一张检查清单过一遍。第一账号权限是否最小化模型能读到的资料是否都是它干活需要的第二输出格式是否固定能不能被下游系统直接解析第三有没有设置“人审”节点关键动作是否永远不会被模型直接执行第四知识库文档有没有版本和负责人第五过期文档是否已下线第六技能触发词是否和现有聊天机器人冲突第七有没有给员工预留“反馈”和“跳过”的入口第八有没有安排一个固定的周会来复盘修正案例。这八条全过一次大概只要半小时但能避免上线后 80% 的常见事故。我见过太多团队急着把功能抛给业务出口上什么都没装结果第一次翻车就全盘推倒。慢一点把护栏装好AI 落地反而会更快。6. 一点经验分享如果有人问我Codex 和 WorkBuddy 这类工具买回来后最重要的第一步是什么我会说是“先承认它们是工具不是答案”。它们能不能产生价值完全取决于你有没有一套工程方法把它们接进业务流程有没有一层知识架构让它们听得懂公司语言。我做过的所有成功案例几乎都遵循同一条路径一个每周让人头疼的高频场景一套简洁的边界规则一份持续更新的业务知识库和一个愿意至少跑两周灰度验证的业务伙伴。至于模型选谁、平台叫什么反而都是后话。还有一个体会是别想一次做完。现在每次听到“我们要搭建全公司 AI 体系”这种话我都会建议先从一条工单流水线的自动化开始。因为真正能说服所有人的永远不是一个宏大的规划书而是某个同事亲眼看到自己手里十分钟的活被机器三分钟干完了而且干得还不差。再分享一个小技巧把每次会话里模型被人工修正的内容存下来月底翻一翻你会惊讶地发现那些最值钱的企业知识其实早就散落在员工每天的修改里你只需要把它们捡回来放回知识骨架中。这才是比任何参数调优都更持久、更难被竞争者复制的东西。