FDE+AKA：让Codex和WorkBuddy真正在企业落地

企业今年采购预算里大概率都有一笔“AI工具费”。Codex、WorkBuddy这类产品几乎成了软件团队和业务团队的标配选项。但我在服务多家企业时看到一个非常普遍的现象工具装好了账号开通了两周后打开率就掉到三成一个月后基本只剩几个人在“玩”。问题不在工具本身而在于企业把“买工具”当成了“AI落地”。我后来用一套组合方法——FDE 加 AKA 做深度定制才真正把这类工具用起来效果是完全不一样的。这篇文章适合谁看技术负责人、AI产品经理、以及真正在推动企业AI改造的一线工程师。核心观点先放在这儿Codex 解决的是“代码怎么改”WorkBuddy 解决的是“流程怎么跑”但两者都是通用能力不解决“你的企业到底要什么”这个问题。谁来定义这件事我习惯用一个叫 FDE 的岗位角色去定义业务问题再用一套叫 AKA 的方法把问题翻译成 AI 能执行的知识结构。写这篇文章就是把这两套东西怎么配合、怎么落地、踩过什么坑完整讲清楚。1. 先看清楚买了工具不等于 AI 落地1.1 企业 AI 落地卡在哪三道关口我接手过不少“买了 Codex 和 WorkBuddy 之后不知道怎么继续”的企业项目。它们卡住的位置几乎是一样的不是技术难度高而是基础没打好。第一道关是“工具装上了知识没接上”。Codex 确实能在仓库里改代码但它不认识你们公司内部的 API 命名、数据库字段含义更不知道你们代码规范里“禁止直接调用某个老接口”之类的潜规则。WorkBuddy 能编排工作流但你如果没把业务 SOP、术语表、异常处理规则喂进去它只能搭一个“空壳流程”AI Agent 跑起来全是空的。工具是入口知识才是燃料。第二道关是“演示很惊艳真实场景就崩”。厂商演示时用的是标准问题、标准数据一切干干净净。真实业务里一条售后工单可能主语混乱、字段缺失、还夹着截图和语音转写文本。模型没见过这些脏数据自然就崩。不是 AI 不行是它没有“业务上下文”。第三道关是“没有人为结果负责”。Codex 写出来的代码谁审查WorkBuddy 里跑的流程谁维护如果这些问题没有答案工具的活跃度一定随着新鲜感一起消失。我见过最快的案例上线十天就没人碰了因为团队不知道“用它能换来什么”。1.2 通用 AI 工具自带的三堵墙企业采购的通用 AI 工具本质上是带着三堵墙进场的。我在实践中把它们总结为“上下文墙、规则墙、反馈墙”。上下文墙最好理解。模型只能看到当前会话窗口里的内容看不到你们公司的全局系统。你说“把上周的销售数据汇总一下”如果没有提前把数据源、字段口径、统计周期定义清楚它只能瞎猜。你看着像是在提需求其实是在让一个没有背景信息的人做高难度判断。规则墙更隐蔽。每个企业都有一堆“没写进文档但大家都知道”的事情报价不能低于某个底线、某些客户渠道不能盲目触达、代码合并前必须过 review。这些规则如果没有人显式地写成 AI 可读的内容模型就是不知道就会犯错。而且它犯错的样子还很自然让你很难一眼识破。反馈墙则是组织层面的。AI 工具做错了一件事团队修正完就结束了没有机制把“这次为什么错、下次怎么避免”沉淀回工具里。结果就是同一个错误反复犯大家越来越不信任工具。1.3 工具不背锅缺的是“翻译层”我见过很多团队把落地失败归因于“工具不好用”。说实话Codex 和 WorkBuddy 这一梯队的工具能力已经相当能打了。真正缺的是一个翻译层。业务人员说“我要提高线索转化”这是一句人话。AI 需要的是“当线索状态变为已联系超过3天且未进入下一阶段时自动触发短信模板A并在2小时后推送提醒给负责人”——这才是机器能执行的结构化描述。翻译层就是负责把人话变成机器可执行的东西。我早年也天真地以为只要把工具权限放开大家自己就会用。后来的教训是没有翻译层的 AI 项目就像给一个不看乐谱的人发了把昂贵的吉他。他弹不出你想要的曲子不是因为吉他不好是因为没有人把乐谱翻译成他能懂的语言。FDE 和 AKA 就是干这件事的。2. FDE AKA一套不靠“换更贵的工具”解决问题的定制框架2.1 FDE 是什么站在业务问题和工程实现中间的人FDE 是我在实践中沉淀出的一个岗位角色定义英文全称是 Frontline Domain Engineer前线领域工程师。它不是一个厂商定义的头衔更像是一种能力组合既听得懂业务人员的抱怨又看得懂工程实现的结构。为什么企业现在特别需要这种角色因为通用 AI 工具把“提问的成本”降成了零但把“定义问题的成本”抬得很高。以前让开发写个报表业务得先提需求、画原型、排排期中间自带一轮“把话说清楚”的过程。现在大家直接问 AI结果发现问不清楚反而更乱了。FDE 的核心工作就是把模糊的业务诉求变成清晰的任务定义。具体来说FDE 要做三件事。第一盘点业务资产哪些流程是高频的、哪些数据是可用的、哪些环节是 AI 能插入的。第二把业务规则转成结构化描述术语、字段、分支条件、例外情况全都要落到文档里。第三设计验证闭环AI 做完一件事谁来检查、怎么反馈、如何把反馈变成新的规则。没有这三样任何 AI 工具都只是玩具。2.2 AKA 是什么让 AI 知道该做什么、按什么顺序做、做成什么样AKA 的全称是 Actionable Knowledge Architecture可执行知识架构。我在项目里管它叫“给 AI 建知识骨架”。很多人一听“知识架构”就以为是把公司文档全部丢进向量数据库这是天大的误解。AKA 强调的不是知识数量而是知识的“可执行性”。一套可执行的知识架构在我的项目里通常分三层。第一层是领域词汇层把业务术语、实体定义、同义词映射写清楚。比如“线索”和“潜在客户”是同一个东西“流失”在不同部门有不同口径必须统一。第二层是流程规则层把步骤、顺序、分支条件显式化。比如“如果客户等级为A则优先分配如果为C则进入培育池”。第三层是输出约束层规定 AI 的输出格式、质量标准、合规边界。比如“回复客户消息不要超过300字禁止承诺退款语气必须中性”。这三层知识加在一起AI 才知道“应该做什么、按什么顺序做、做成什么样”。听起来简单做起来极考功夫因为大部分业务知识藏在老员工脑子里没人写下来过。AKA 的难点不是建架构而是把大家默认的“隐形知识”挖出来变成显式规则。2.3 两者怎么配合一个导演、一份剧本打个比方FDE 是导演AKA 是剧本。AI 工具是演员再好的演员没有剧本也只能即兴发挥发挥得好是运气发挥得差是常态。FDE 负责决定“我们要拍一部什么样的片子”AKA 负责把剧本写到能直接开拍的程度。实操中的配合顺序是固定的。第一步FDE 进场先做业务访谈和流程盘点找到最有价值的切入点圈出范围。第二步FDE 和业务方一起把这块业务的知识资产梳理清楚这就是 AKA 的原始素材。第三步把 AKA 落成文档、配置、Skill、Prompt注入到 Codex 和 WorkBuddy 对应的位置。第四步跑一段时间收集错误样本回到 AKA 里修改规则。很多团队卡在第二步因为业务方没耐心陪你梳理知识总觉得这是浪费时间。我常用的办法是找一个最痛的小场景用两周时间快速跑通让业务方看到“原来规则写清楚之后 AI 真能干活”他们才愿意投入时间。先有甜头再有配合。3. 用 WorkBuddy 搭出真正能用的业务工作台3.1 别一上来就复刻公司全部流程很多人拿到 WorkBuddy 的第一反应是想把公司所有流程都搬进去OA 审批、财务报销、项目管理全部做成 Agent。我劝你冷静。WorkBuddy 这类平台强在编排和自动化但它不是 ERP也不是流程再造工具。一上来就玩大的大概率两个月后变成一个没人用的“数字烂尾楼”。我给团队定的选择标准很朴素第一条流程高频最好是一周至少出现几十次的任务第二条错误成本要低就算 AI 做错了也不会造成重大损失第三条结果可验证做完之后能明确判断“做对了没有”第四条参与角色不能太多控制在两三个以内否则沟通成本会吃掉自动化收益。按这个标准我见到的企业通常选出来的第一批场景高度类似售后工单分诊、销售线索清洗、周报汇总、简历初筛、合同条款预审。这些任务有共同特点规则相对明确、量又大、人工做起来无聊、AI 做错了影响可控。先拿下这类场景团队信心就起来了。3.2 把一条业务 SOP 变成一个可执行的 WorkBuddy SkillWorkBuddy 的核心定制单位是 Skill。你可以把它理解成一个“带说明书的 AI 能力包”告诉 Agent 在什么情况下、按什么步骤、调用什么工具、输出什么格式。很多团队不会用 Skill是因为他们把它当成了一个普通文档写了一大段描述结果 Agent 根本不按他们的要求做。我踩过坑之后总结出一套四步法。第一步先把原始 SOP 写成“人话版”不要用术语堆砌而是完整描述一个任务从收到输入到交付输出的全过程。第二步拆解步骤和决策点把“如果怎样就怎样”的分支条件明确写出来。第三步定义输入输出字段这是最关键的一步AI 没有明确的输入输出结构就容易自由发挥。第四步准备 5 个真实案例做测试跑不通就改描述直到稳定。一个售后工单分诊的 Skill 描述我通常会写成下面这个样子name: after_sales_triage description: 对售后工单进行自动分诊判断问题类型、紧急程度并分配给对应处理小组。 inputs: - name: ticket_content description: 用户提交的工单原始文本可能包含口语化表述 required: true - name: customer_level description: 客户等级A/B/CA为最高优先级 required: true steps: - 从工单文本中提取问题类型安装调试、故障报修、退货退款、技术咨询 - 根据关键词和情绪词判断紧急度高/中/低 - 如果紧急度为高或客户等级为A则进入加急队列 - 分配小组安装调试-实施组故障报修-维修组其余-客服组 outputs: - category: 问题类型 - priority: 紧急度 - assigned_group: 处理小组 - reply_draft: 给客户的初步回复草稿不超过200字这套描述写完之后还要在 WorkBuddy 里把“Agent 的触发条件”设为“收到新工单”把“工单系统”接进来然后进入测试环节。我测试时用的方法是拿过去一个月的真实工单去掉结果标签让 Agent 分诊再和人工分诊结果对比。准确率能到 80% 以上就可以先试运行。3.3 让“人”留在流程里把工作台设计成三明治结构我见过最激进的团队想让 WorkBuddy 全自动处理工单连审核都不留。我强烈反对。AI 再强业务场景里总会出现规则覆盖不到的情况。深度定制不等于全自动取代而是在流程的关键节点上让人和 AI 各司其职。我的做法是“三明治结构”上层是 AI 批量处理层负责信息提取、初筛、分类、草稿生成这些量大但规则明确的工作中间是人机协同层关键决策、异常处理、客户最终回复必须让人过目底层是知识沉淀层每次人工修正都是一次反馈要把修正原因写回 AKA 的规则库。举个例子工单分诊的最终派单可以自动但涉及高等级客户或高紧急度的工单必须推到人工确认。AI 生成的回复草稿在正式发送前也要有人审。这样设计团队不会觉得 AI 在抢饭碗反而会觉得它是一个“帮忙干杂活的实习生”。落地阻力一下子小了很多。4. 用 Codex 做代码层的深度定制4.1 Codex 的强项与边界如果说 WorkBuddy 解决的是业务流程自动化那 Codex 解决的就是“代码层”的自动化。Codex 和普通聊天式编程助手的最大区别是它能直接操作你的仓库读代码、改代码、跑测试相当于一个真在干活的 AI 结对程序员。这也是它价值大的原因很多人用它写 demo、搭原型结果发现“它写的代码看起来很专业但一跑就崩”——为什么因为缺工程上下文。Codex 的边界非常明确它只理解它能看到的上下文。它能读懂你仓库里的代码结构但它不知道你们团队“为什么在配置文件里加了那个奇怪的参数”“为什么某个目录绝对不能动”“为什么这段逻辑的历史包袱很重”。这些隐性知识如果你不告诉它它就会在改代码时踩雷。所以我对 Codex 的核心用法是先花时间把工程上下文写清楚再让它干活。很多团队不知道Codex 在开始操作仓库时会读取 AGENTS.md 之类的说明文件。你可以利用这个机制把团队规范、仓库结构、禁忌事项写进去。这不是给 AI 增加负担而是把你们团队的“工程惯性”显式化。4.2 上线前必须做好的三件准备工作准备不足就上 Codex等于让一个聪明但没有经验的同事直接去改生产仓库后果可想而知。我的习惯是在上线前把三件事做完。第一件把仓库背景写明白。技术栈、目录结构、命名规范、测试命令、构建方式全部写进 AGENTS.md。别嫌啰嗦Codex 看到了这些生成的代码风格才会和团队一致。第二件把接口和依赖讲清楚。内部服务调用哪些、数据库表结构长什么样、配置中心有哪些 key不给这些信息它写出来的调用代码一定和实际不匹配。第三件把“不许做”的事列出来。不能动哪些目录、不能引入新的第三方依赖、不能绕过代码审查、不能修改公共配置。下面是我在一个中大型项目中使用的 AGENTS.md 精简示例你可以直接参考这个结构# 项目背景 这是一个面向中小企业的订单管理系统后端使用 Java 17 Spring Boot 3前端使用 Vue 3 TypeScript。 # 目录结构 - /src/main/java/com/company/order/ 后端业务代码 - /src/main/resources/ 配置与静态资源 - /frontend/ 前端工程 - /scripts/ 部署与数据库迁移脚本 # 代码规范 - 所有对外接口必须返回统一响应体 ResultT - 禁止在业务代码中直接使用 JdbcTemplate必须走 Mapper 层 - 命名采用驼峰DTO 后缀必须清晰区分请求/响应 # 不允许做的事 - 不要修改 /src/main/resources/application-prod.yml - 不要新增全局异常拦截器已有全局处理 - 不要引入新的第三方依赖库除非经过架构师确认 # 测试要求 - 每次代码修改后必须运行 ./scripts/run_unit_tests.sh - 新增方法尽量补充单元测试写好 AGENTS.md 之后Codex 的行为会发生肉眼可见的变化。最明显的改善是它不再用“看起来高大上但不匹配现有架构”的方式写代码而是贴着你们的代码风格来改Review 成本直接下降。4.3 一个可复制的 Codex 定制闭环Codex 的定制不是一次配置就完事的而是一个持续闭环。我总结了五个步骤每一步都有明确的产出物。第一步单点试跑。先挑一个中等复杂的 issue不要挑那种“改一行配置”的也不要挑“重建整个模块”的。建议选一个需要理解业务规则、但又相对独立的接口改造。第二步把任务描述按四段式写好。我用的模板是背景这段代码是干什么的、目标这次要改成什么样、约束不能动什么、必须符合什么规范、验收标准怎么算完成。这四段缺一不可尤其是验收标准没有验收标准 Codex 就会“自我感觉良好”。第三步让 Codex 先出方案再动手。直接在任务里写“先说明修改计划和涉及文件确认后开始改动”。这一步能防止它一通乱改。第四步代码审查时重点看它“不懂业务规则”的地方比如异常处理是否完整、边界条件是否覆盖。第五步把审查中发现的共性问题沉淀回 AGENTS.md 或项目文档里。每轮循环一次Codex 对这个项目的理解就深一层。一个合格的任务描述长下面这样背景订单模块的 createOrder 接口目前直接同步调用库存服务扣减库存导致高并发时响应时间过长平均 800ms。 目标把扣减库存的逻辑改为异步消息的方式通过 MQ 发送消息给库存服务订单接口只负责落库。 约束 - 不要改动现有的订单状态机 - 必须保留失败后的补偿机制消息消费失败时要能重试 - 新增的 MQ Topic 名称统一以 order_ 开头 - 禁止修改合同模块的代码 验收标准 1. createOrder 接口平均响应时间降到 200ms 以内 2. 库存扣减消息消费失败后订单状态能进入“待处理”并触发重试 3. 所有新增代码通过单元测试和已有代码规范检查4.4 模型、参数和权限的实操经验Codex 用起来参数设置和权限控制比 Prompt 技巧更重要。我在这块吃过亏还是被现实狠狠教育过的。模型选择上建议复杂任务选能力更强、但成本也更高的模型简单任务用它内置的轻量模型就够了。不用每个任务都上最强模型成本和响应速度都不一样。温度这类参数我基本保持默认或调低因为代码生成是“确定性任务”不需要让它天马行空。温度高了它爱给你整活写出你没见过但不想用的代码。权限隔离是必须做的一步。我见过公司直接给 Codex 配了生产库的写权限这已经不是给实习生发钥匙了是给实习生发金库密码。正确的做法是给 Codex 一个受限账号只能操作指定分支不能直接推生产更不能拿到生产环境敏感配置。所有变更必须走 Pull Request再便宜好用的工具也要有审计边界。另一个细节是会话管理。我要求团队一个会话只干一件事不要在一个对话里让 Codex 连续处理三个完全不同的需求。它一旦切换上下文很容易把前面的状态带到后面的任务里改错代码你都不知道是哪次会话引入的。5. 常见问题与排查实录5.1 我踩过的五个高频坑深度定制不是一蹴而就的我在这里把团队最容易踩的五个坑列成一张速查表每条都附上解决思路。现象根因解决方案Agent 回答含含糊糊不给明确结论Prompt 里没有定义输出格式和验收标准在任务描述末尾增加“必须输出什么、以什么格式”的约束WorkBuddy 的 Skill 经常不命中Skill 描述写得像论文没有触发条件和输入示例重写描述明确“什么条件下触发”“输入长什么样”Codex 改坏代码且没有被及时发现没有强制跑测试和 lint在 AGENTS.md 写死“每次修改必须运行指定脚本”并在流程里加入 CI 校验任务上下文被截断结果答非所问一次塞了太多文档和附件只保留必要信息长文档提前提炼核心规则再注入权限太宽导致团队不敢放开用一上来就给高级权限出事就喊停先做只读或沙箱模式用一段时间建立信任再逐步放开5.2 排查方法三层定位法现象多的时候切忌一上来就苦思冥想地改 Prompt。我习惯用“人、流程、工具”三层定位法按顺序排查。第一层看人使用者能不能清楚描述自己的任务有没有准备好典型的输入样例如果使用者自己都说不清“什么样的输入是正常的”那 AI 表现再差也正常问题不在工具。第二层看流程谁负责给 AI 下达任务谁负责验收结果出了错向谁反馈流程不清的话即使工具偶尔做对了也没有人会留意。第三层才轮到工具配置对不对、权限够不够、模型参数是否合理。很多团队恰好搞反了一有问题就怀疑工具不行改了三天参数绕了一圈又回到“人和流程”的问题上。这个方法听起来特别简单但非常管用。我接手过的项目里至少有一半“AI 不听话”的真实原因出在“使用者从来没有给 AI 提供过高质量输入”上面。你给一句含糊的话再强的模型也只能给你一句含糊的回答。5.3 两个容易忽略的细节第一个细节AI 工具的配置错误信息很多是拼写问题但大家第一反应是重装。比如 Codex 启动时提示 “ignoring unknown configuration setting”大概率就是你配置文件里某个键名拼错了或者版本和配置不匹配。先检查配置名对照官方文档看拼写比卸载重装有效得多而且不浪费时间。第二个细节多人共用同一个工作台和同一个 Agent 时一定要做好权限分层。谁可以创建任务谁可以编辑规则谁只能只读查看必须在第一天就分清楚。否则很快就会出现“某人改了一条公共 Skill所有人的任务全都变了个样”的事故。这个问题我在服务客户时亲眼见到过后果是整个团队对 AI 的信任直接归零。6. 深度定制之后团队怎么配合才会真正落地6.1 落地不是部署完成就结束工具配置完、Skill 上线了不代表项目结束这才刚刚开始。我见过太多项目在这个阶段松懈结果三个月后一切回到原点。正确做法是上线后安排两周到四周的“贴身陪跑”每周花一个小时复盘专门看 AI 做错过的案例把典型错误写成新规则沉淀回 AKA。这个阶段最大的心理挑战是你会觉得“怎么问题这么多是不是工具不行”。我的经验是问题多是正常的。规则正在从“人脑的隐性知识”变成“机器能执行的显式知识”这个摩擦过程一定会有阵痛。挺过去AI 的准确率会快速爬升挺不过去就会回到“买了个工具但没人用”的循环。复盘会议必须有业务方参与因为只有他们才知道某个错误为什么是错的。6.2 两条推进路线单点突破还是流程横切给企业做 AI 落地方案时我通常建议在“单点突破”和“流程横切”之间做选择。两条路线各有适用场景不能拍脑袋决定。单点突破是指选一个岗位、一条具体任务线把 AI 做到极致。比如先只做“售后工单分诊”这一个场景让它从 60 分做到 90 分。好处是见效快、风险可控、人心不散。坏处是影响面有限。流程横切是指选一条跨部门的核心流程从开始到结束全面改造。比如从线索生成到成交的全链路。好处是价值大坏处是周期长、协作成本极高没有业务高管的支持基本走不通。我的建议很明确第一次试水只做单点突破。先让一个场景真正好用比同时铺开十一个“差不多能用”的场景强百倍。等团队在单点上建立了完整的“定义问题—注入知识—反馈修正”的循环能力再考虑往流程横切方向扩展。6.3 用什么指标衡量落地效果衡量 AI 落地最忌讳的是盯着“节省了多少工时”这种虚指标。工时节省了但活儿没干好等于白省。我更推荐用三个贴近业务本质的指标一是任务完成率也就是 AI 独立跑通、不需要人工返工的任务占比二是关键质量指标比如工单错误率、代码缺陷率三是使用者的周活跃率这个数字低于五成说明大家根本不觉得它有用再好看的后台 token 消耗都没意义。我自己的习惯是上线第一个月每周看一次这三个指标。趋势比绝对值重要。如果任务完成率在爬升说明知识注入在生效如果卡住不动说明有某个规则没写对回去改 AKA。如果活跃率在跌那大概率不是技术问题是使用体验或组织推动出了问题要及时介入硬扛是没有意义的。回到标题本身的问题企业买了 Codex、WorkBuddyAI 为什么还是没落地我的答案就一句话因为没有人把“业务语言”翻译成“AI 能执行的任务定义”。FDE 加 AKA 这套组合价值不在于发明了什么新工具而在于它强迫企业把每天嘴上说的业务逻辑落成一行行可执行的规则、一个个清晰的输入输出。这个翻译过程是笨功夫也是唯一绕不过去的路。最后分享一个我的心法无论你用 WorkBuddy 搭工作台还是用 Codex 改代码都从“一个最小但真实的任务”开始。先找一个你已经能描述清楚、最让团队头疼的小任务把它做完、做透、做到稳定再谈扩大边界。别一上来就规划宏大蓝图AI 落地的密码从来不在蓝图里在那一个又一个跑通的小任务里。