老板把 Codex 和 WorkBuddy 都买回来了不少团队第一反应是“这波稳了”结果用了两三个星期新鲜劲一过该写代码的还是自己吭哧吭哧写该处理工单的还是在 Excel 里复制粘贴。Codex 确实能帮忙写函数但问它“我们这个项目的鉴权逻辑在哪几个文件里”它答不上来WorkBuddy 能管日程、能拉数据但让它在内部系统里走一遍“客户投诉→生成退款单→通知财务”的流程它就卡住了。这其实是当下企业内部落地 AI 最典型的症状工具到位了场景没到位知识更没到位。我最近用一个组合打法帮两家公司解决了这个问题——FDEFeature-Driven Engineering功能驱动开发加上 AKAAgent Knowledge Architecture智能体知识架构。听起来挺生僻说白了就是两件事用研发的严谨把 AI 要干的活拆清楚再把公司自己的业务知识“喂”给 AI 当大脑。这套做法不换工具、不推翻现有系统只是把 Codex 和 WorkBuddy 从“摆设”变成“真正的员工”。这篇文章我就把整套思路、实操步骤和踩过的坑完整写出来适合正在被“AI买了没用”困扰的技术负责人、程序员和业务线管理者参考。1. 先搞明白买来的 AI 为什么“落地难”1.1 通用模型解决不了私有业务问题大多数企业买完 Codex 这类工具后第一个崩溃的瞬间是问它内部业务逻辑它开始一本正经地编。这不能怪模型Codex 的底座是通用大模型它的训练数据里确实有无数开源代码和公开技术资料但没有你们公司的订单审批流、没有你们产品线的历史需求文档、没有你们客服团队总结的客户话术。刚接入那几天团队反馈“Codex 写的代码根本没法跑”我看了下问题不在代码质量在于它压根不知道项目里的接口是干吗的。它能写出一个漂亮的 REST API 封装但它不知道你们这边调用的上游服务名、不知道返回码 2301 到底代表什么业务含义。这就是典型缺“业务上下文”的症状。WorkBuddy 也有同样问题。它擅长的日历管理、待办提醒、通用文档总结都基于公开场景一旦涉及内部 OA 系统的字段含义、CRM 里的客户分级规则它就变成了一个“很优雅的废物”。1.2 组织流程没有为 AI 留出“接口”另一个让我很意外的原因出在流程上。大多数公司的业务流是为“人肉执行”设计的根本没有给机器留出操作入口。举个真实例子某公司财务部的报销流程是——员工在 OA 填单、贴票财务专员人工核对金额、检查发票真伪、再手动录入财务系统。你想让 WorkBuddy 帮忙做初审结果发现 OA 表单导出的数据格式五花八门有的填了“交通费”有的填“的士费用”没有标准字段。**流程不标准化AI 就无处发力。**这就像你想教新人办事结果带他走的全是野路子新人当然学废。1.3 缺乏验收标准AI 做完了也没人敢用还有一种情况是AI 确实在工作但没人敢把它的产出当真。程序员让 Codex 生成了一段登录模块代码可代码合不合规范、安全性如何、有没有兼容老接口没人给个准话。于是这段代码被扔在分支里吃灰。CSDN 上 Codex 的段子一抓一大把基本都是这个套路AI 交活了但交付质量没有可信的验收闸门。FDE 的本质就是给 AI 每个任务定义“完成”的标准。AKA 的本质是给 AI 配上业务知识底座让它回答问题、执行任务时有据可依。这两件事互为表里缺一不可。2. FDE把业务需求拆到 AI 能执行的颗粒度2.1 功能驱动开发的核心四步我在做这类项目时不走传统的需求文档路线而是让业务方和技术方一起坐下来用“功能”为单位重新拆解需求。一个功能必须满足四个条件有输入、有处理逻辑、有输出、有明确的验收标准。比如“客户工单自动分类”这个功能拆下来是输入客户提交的文本工单、客户所属行业、历史工单记录处理意图识别咨询、投诉、售后、紧急程度判定、匹配对应处理部门输出工单分类结果、推荐处理人、自动生成的回复草稿验收标准分类准确率不低于 90%回复草稿可用率不低于 80%线上人工修改率低于 20%这个拆法最大的好处是每条验收标准都能变成代码里的测试用例。Codex 生成的代码不是“看起来对”而是“跑得过验收测试”。我给你看一个我在现场常用的需求定义模板格式{ feature_id: TICKET-001, feature_name: 客户工单自动分类, input: { ticket_text: string (必填, 客户描述原文), customer_tier: enum(vip, normal, guest), history_count: int }, processing_rules: [ if 文本包含退款 且 customer_tier vip then 优先级P0, if 文本包含无法登录 then 分类技术故障, if 文本长度 20 且无关键词命中 then 转人工 ], output: { category: enum(咨询, 投诉, 售后, 技术故障), priority: enum(P0, P1, P2), suggested_action: string, confidence: float }, acceptance_criteria: [ 分类准确率 90%, P0 识别召回率 95%, 单条处理耗时 2s ] }我见过太多项目在这里翻车功能定义得含含糊糊比如“让 AI 提升工作效率”——这种就算拆成十八个功能也还是虚的。你必须能把“提升效率”翻译成“AI 每天自动生成 30 条工单回复草稿人工修改后发送”。可以量化、可以测试、可以收敛这才叫功能。2.2 用验收标准反推开发任务FDE 真正聪明的地方在于它是从验收标准反推开发任务的。你先把“什么算做完”定死再让 Codex 去写代码它就不容易跑偏。我给一个团队做客户信用评估功能时验收标准之一是“所有上游参数缺失时必须有明确错误提示不能静默返回 null”。Codex 第一次生成的代码在输入不全时会返回一个空对象业务方根本看不出哪里出了问题——这就是典型的“没有验收标准时 AI 的本能操作”。把这条验收标准写成测试用例然后塞进开发提示词里Codex 生成的结果立刻就变了。它会在函数入口处做参数完整性的显式校验缺了什么字段错误信息里直接写出来。具体到提示词层面我在用 Codex 时会把它接收的上下文化分成三段业务上下文这段功能要解决什么问题用户是谁操作场景是什么技术约束必须使用哪个框架、遵循什么代码规范、不能破坏哪些老接口验收标准输出必须满足什么测试条件边界情况必须如何处理这三段缺一段生成质量都会明显下滑。尤其是技术约束很多团队默认 Codex“懂”但实际上它不懂你们的私有规范——比如代码里必须包含 request_id 的透传、时间戳必须用东八区等。这些内容不加到提示词中AI 百分之百按自己训练数据里的“通用习惯”来。2.3 FDE 流程落地的组织保障FDE 不只是技术方法它要求业务方和技术方坐到一张桌子上把“功能”一项项扣明白。我在实际推项目时要求每个功能必须有一个明确的“业务Owner”和一个“技术Owner”。这个要求看着行政化但作用极大。业务 Owner 负责回答“这个功能到底想干吗”技术 Owner 负责回答“这个功能在系统里怎么实现、数据从哪儿来”。两个人对不上AI 定制就无从谈起。我见过一个反例某公司做“智能合同审查”业务方说要“自动审出问题”技术方问“具体审哪些问题”业务方说“你让 AI 自己判断呗”。结果 Codex 倒是真能生成代码但因为没有明确的法律风险条款清单AI 把合同里的错别字当风险、把真正缺的违约责任条款全漏了。业务方自然不满意又退回人工。这属于典型的“验收标准缺失症”。3. AKA给 AI 造一个有业务记忆的大脑3.1 知识架构的三个层级如果说 FDE 解决的是“AI 该干什么”那 AKA我把这套叫 Agent Knowledge Architecture解决的就是“AI 凭什么干得对”。AKA 的核心是把企业里散落在文档、代码、数据库、聊天记录里的知识整理成 AI 可以调用的结构化资产。我把它拆成三层第一层流程知识也就是“事情怎么运作的”。比如差旅报销是先申请后报销还是先垫付后报销、合同审批的权限上限是多少、客户投诉升级到总监的标准是什么。这些知识通常存在于制度文档和老员工脑子里。第二层领域知识也就是“专业内容本身”。比如律师的合同风险清单、医生的诊断路径、程序员的 API 参考手册。这一层的知识密度最高也是 AI 最容易“一本正经地胡说八道”的部分。第三层经验知识也就是“踩过的坑和补过的洞”。比如“每逢月末财务系统查询特别慢调度任务要错峰”“老客户续费时要先查信用状态再开发票”。这些知识几乎没有任何文档记录得靠访谈老员工挖出来。三层知识全部到位后AI 才有资格说一句“我懂这家公司”。3.2 知识库怎么建从文档到向量库的实操路径现在通用的做法是 RAG检索增强生成。简单说就是先把文档切片、向量化存入向量数据库AI 在回答或执行任务之前先到向量库里检索相关片段再把检索结果拼进提示词。这套流程的好处是 AI 不需要“背下”所有业务资料只需要在需要时找到相关片段。我来给你一份可以直接照抄的实施路径**第一步盘点知识源。**把所有和业务相关的文档拉到一处。不要只认 Word/PDF代码注释、钉钉/飞书群里沉淀的答疑合集、工单系统里的解决记录都是知识源。曾经有个客户最有价值的知识全写在了一个离职员工的本地笔记里人走了知识就没了。我们硬是通过他的交接文档和聊天记录重建了一部分。**第二步清洗与结构化。**这一步最脏最累。很多内部文档的格式是“开会讨论了下决定还是按照老方案来”这种内容没有信息增量。我的做法是让业务人员对每份文档做一个三行标注它讲的是什么主题、适用于什么场景、有什么阅读优先级。这个标注动作本身就能淘汰掉一半垃圾文档。**第三步切片与向量化。**切片的策略很有讲究。无脑按 500 字一截经常把完整业务规则切断。我建议按“语义块”切——一个段落讲完一个意思就单独成为一片。比如合同审查规则里“违约责任条款必须具备以下五项内容”就应该整段作为一个切片不能从中间断开。向量化模型方面中文业务场景我实测下来使用国内主流开源 embedding 模型的效果普遍好于通用英文模型常见的一些国产模型在财务、HR、法律等垂直领域都表现不错。**第四步建立召回测试集。**知识库建完不是直接上线要准备 50 到 100 条真实业务问题逐条测检索召回率。比如“发票丢失了还能报销吗”“合同里违约金上限有规定吗”每道题必须能从知识库里召回正确片段。召回不对不是模型笨是切片切得不对或文档没清洗干净回去调整。3.3 WorkBuddy Skill 与 Codex 的自定义知识接入如果只有知识库没有执行入口AKA 架构就是死的。WorkBuddy 和 Codex 是目前我用来接知识库的两个主要载体它们的定制方式不太一样。**WorkBuddy 这边走的是 Skill技能体系。**你可以把 Skill 理解成给 AI 预装的“业务操作说明书”。一个 Skill 文件里定义清楚触发的场景、需要的输入参数、执行步骤、调用的外部工具或知识库索引。换句话说AI 不是一个通用助手而是“一个懂报销审核的助手”或“一个懂工单分类的助手”。我实际用下来WorkBuddy 的 Skill 开发比想象中简单核心就是一个结构化的配置文本但要命的是里面的“执行步骤”必须写得很死容不得半点模糊。给个简化示例skill_name: 差旅报销初审 triggers: - 用户输入包含报销 - 用户上传报销图片或单据 inputs: - expense_date: 报销日期 - amount: 报销金额 - category: 费用类型 steps: 1. 调用报销知识库检索该费用类型的报销标准 2. 校验金额是否超限若超限标记需上级审批 3. 调用财务系统接口查询该员工部门成本中心 4. 生成初审意见附带依据文档链接 outputs: - review_result: 通过/不通过/需人工复核 - confidence: 置信度 - evidence_id: 依据的知识文档ID用这种方式WorkBuddy 就不再是个只会看日历的助理而是一个能查制度、算金额、给出审核意见的业务角色了。**Codex 这边更偏代码仓库层面的定制。**你可以在项目根目录放一份AGENTS.md文件里面写清楚项目的架构说明、代码风格、命名规范、接口约定、构建命令Codex 读取后会把它作为回答和生成的上下文基准。很多团队不知道这个功能用 Codex 全靠临时对话效果自然不稳定。我在一个 Java 微服务项目里把AGENTS.md写成了包含以下内容的结构服务目录与职责、Maven 模块依赖关系、统一异常码规范、数据库表命名规则、Redis key 前缀约定、部署流水线说明。之后 Codex 生成代码的“本地味道”明显重了很多不再动不动就给你造出一个项目里根本不存在的工具类。3.4 知识架构与功能开发的映射表要确保 FDE 拆出的每个功能都能找到对应的知识和技能支撑我在实际规划时会画一张映射表。这里我把模板给你功能名称核心业务问题需要的流程知识需要的领域知识执行载体工单自动分类客户问题属于哪类客服中心分级响应制度产品线手册、故障代码表WorkBuddy Skill合同风险审查合同缺哪些关键条款法务审批流程与权限合同模板库、法律风险清单Codex RAG智能报表生成经营数据怎么看报表发布审批流程指标口径定义、数据字典WorkBuddy Skill代码自动补全新功能代码如何写Git 分支策略、上线流程现有代码库、框架规范Codex AGENTS.md这张表做完整个落地路径就非常清晰了每个功能都有业务知识支撑有确定的执行载体有验收标准。上不上线一眼就能判断。4. 完整实操从业务诊断到 AI 定制落地4.1 真实场景与诊断结果我带大家完整走一遍实操过程。场景是一家做企业服务的公司主要客户是中小商家日处理客诉工单 200 到 400 条。老板买了 Codex 和 WorkBuddy目标是让客服团队从每天重复回复中解放出来去做更复杂的客户运营。但用了一个月效果为零——客服觉得 AI 回复的都是废话技术觉得 AI 写的整合代码跑不通。我的诊断结果如下业务侧问题客服回复没有统一话术标准同一个“发票怎么开”的问题三个客服给出三种说法。AI 学到的是“百花齐放”而不是“标准答案”。技术侧问题工单系统的数据没有结构化字段分类靠客服肉眼判断。AI 就算能写代码也没有干净的数据源可用。知识侧问题知识库里只有产品说明书和几个 PPT真正的客诉处理经验都在客服组长脑子里从没沉淀成文字。三个问题叠在一起AI 无论多强都发挥不出来。接下来就是按 FDE AKA 逐一拆解。4.2 业务梳理与知识采集第一步是和业务方坐在一起把工单分类从“感觉”变成“规则”。我们花了三天时间把过去三个月的 3000 条工单全部翻了一遍由客服主管逐条给出分类标签再聚合成类。最终归纳出六大类订单问题、发票财务、账号安全、产品使用、退款售后、其他咨询。每一类下面再细分出 2 到 5 个子类。最关键的一步是给每个子类定义了“判定关键词”和“典型场景”。比如“退款售后”的子类“未收到退款”判定关键词包括退款未到、钱没退、退款失败、到账时间等。这些关键词没有从网上找全是从真实工单里抠出来的。这就是经验知识的力量——网上任何一个公开资料都不可能告诉你你们家的客户管“退货”叫“寄回去换”管“退款”叫“退钱”。这不进知识库AI 永远理解不了你们的客户。接下来是知识采集。我们把客服组长拉到一个会议室花了两个下午做了一件事问问题。问法是“客户问过的最奇怪的问题是什么”“你最怕收到什么类型的工单”“什么情况下你会把工单升级给主管”。这三个问题问完挖出了至少 20 条制度文档里根本不存在却在日常处理中反复用到的经验规则。比如有一条“客户说‘我要投诉’但其实只是情绪化表达先安抚再引导不要直接转投诉流程。”这种微妙的业务判断学问全在上下文里AI 要从纯文本里学到几乎不可能必须你喂给它。4.3 知识库搭建与检索调优知识采集完成后我们建了两个知识库客服话术库包含标准欢迎语、各场景回复模板、敏感情绪安抚话术、升级话术业务规则库包含六大类工单的判定关键词、各产品线的常见问题排查步骤、退款政策细则、发票申请流程切片时我们按“一问一答”为最小单元。比如一个条目就是“问题发票开错了怎么办答案登录后台→订单管理→找到对应订单→申请重开→3个工作日内处理”。这样一条切片在回答时召回效果远好于把一个章节的整体说明塞进去。向量化嵌入这一层我提醒一下选 embedding 模型时不要盲目追求大参数。实际对比下来针对中文客服场景参数量适中的专用中文模型比通用大模型的嵌入精度更好尤其是“退货”和“退款”这种近义词好的嵌入模型能区分出业务语境差异。在测试集上我用专业模型把召回准确率从 78% 拉到 94%差距非常大。向量数据库选型直接用了自建的简易方案在公司内网部署原因有两个一是客户工单数据涉敏感信息不能出内网二是自建方案改切片策略、调试嵌入模型时更灵活。如果你们的团队没有运维能力买云厂商的向量数据库也可以但记得先问清楚数据合规。4.4 Codex 深度定制与代码生成有了知识库接下来把 Codex 变成“懂这个项目的开发助理”。我做了三件事第一在代码仓库根目录创建AGENTS.md内容包含项目架构导览、模块职责表、编码规范、异常码规范、接口设计约定。特别强调了“所有新功能必须复用已有 common-utils 包不得自行创建同等工具类”这是之前 Codex 乱造类导致代码腐化的核心痛点。第二把客服工单系统的关键业务流程画成文字化流程描述注意不是画图是给 Codex 能读的文字包括状态机流转、权限校验逻辑、各状态允许的操作。Codex 在处理状态流转类代码时最怕不知道边界条件这份描述补上了空白。第三把知识库的检索接口封装成内部服务并在AGENTS.md中声明该接口的调用方式。这样 Codex 生成的代码如果需要判断“这个工单属于哪一类”会主动调用检索接口获取knowledge片段作为判断依据而不是硬编码规则。经过这三项定制后我让 Codex 生成“工单自动分类模块”的代码。它能把知识库返回的标签作为分类依据还能在代码注释里引用知识库的文档 ID可追溯性一下就上来了。这一点对后续人工审核非常重要——AI 说“这个工单属于退款类”你必须能点开它看到的依据是哪条业务规则。4.5 WorkBuddy 技能配置与流程编排WorkBuddy 这边我们开发了三个 Skill 来覆盖完整流程工单初筛 Skill读取新工单文本调用知识库检索输出分类标签和优先级建议话术生成 Skill根据工单分类和客户情绪从话术库选择模板并生成个性化回复升级判断 Skill当工单满足特定条件如客户情绪词命中、金额超限、二次投诉时自动转人工主管在编排的时候要特别注意一个细节三个 Skill 之间必须有明确的数据传递契约。初筛 Skill 输出的是一个 JSON 对象包含category、priority、confidence三个字段话术生成 Skill 接收这个对象再结合客户姓名、订单号等参数生成回复。任何字段名不一致流程就断掉。这跟程序员设计微服务接口时遇到的问题是同构的。WorkBuddy 的实际搭建过程比 Codex 简单Skill 本质上是配置文件加少量逻辑代码不需要复杂的运维操作。但有一个前置条件很重要——业务规则必须稳定。我见过有团队上午刚把 Skill 配好下午业务方说退款政策变了整个流程又得返工。所以 FDE 阶段的规则固化显得尤其重要先让业务方签字确认“规则就这么定”再进 Skill 开发。4.6 上线测试与灰度验证正式上线前我们做了一轮模拟测试选取最近一周的 500 条历史工单把客户原话输入系统让 AI 跑一遍分类和话术生成然后人工逐条比对。比对结果用三个指标衡量分类准确率AI 分对的工单数 / 总测试工单数目标是 90% 以上话术可用率AI 生成的回复草稿中客服认为“可以直接发送或简单修改后发送”的比例目标是 80% 以上转人工正确率应当转人工的工单中AI 成功识别并转出的比例目标是 95% 以上第一轮测试结果不太好看分类准确率只有 84%问题集中在“订单问题”和“物流问题”经常混淆。排查后发现是知识库里“物流”相关的关键词不足很多客户用“我的货到哪了”“发没发货”这类表达切片里没有覆盖。我们回到知识库补充了两百多条真实表达后准确率提升到了 93%。灰度上线时我们没有一次性放开全量工单而是先让 AI 处理 20% 的工单由资深客服全程复核每天记录修改率。连续跑了五天修改率稳定在 15% 左右才逐步放量到全量。这个节奏非常重要AI 落地的最大风险不是技术失败而是信任崩塌——一旦客服觉得 AI “净添乱”后面再想推就难了。5. 定制过程中的常见问题与避坑实录5.1 Codex 相关环境、代理与上下文代码生成工具在实际接入时环境问题往往比模型问题更早暴露。我在企业部署时遇到最典型的一类报错是调用 Codex endpoint 时出现的本地代理连接失败错误信息类似“cc switch local proxy failed while handling codex endpoint /responses”。这通常不是 Codex 本身的问题而是企业内网的 HTTP 代理没有正确放行接口地址。排查路径按顺序来先确认 Codex 配置的代理地址是否正确再确认接口域名是否在代理白名单里最后确认本地防火墙有没有拦截。企业网络的代理配置和普通家用网络完全是两码事经常有安全策略拦截了长连接。这里没有捷径只能和网络管理员一起过一遍白名单。第二个高频问题是模型选择报错。如果你在 Codex 配置里指定了一个当前环境不支持的模型名称它会直接拒绝服务提示类似于“model is not supported when using codex with a [某些环境]”。解决办法很简单使用配置工具查看当前可用的模型列表或者干脆用默认模型。不要为了追新去手动指定冷门模型稳定性优先。第三个问题是上下文管理。Codex 的对话窗口是有限的很多团队抱怨“聊着聊着它就忘了前面的要求”。这属于使用者问题而非工具问题。我的习惯是长任务拆短大任务拆小关键约束每轮都重申。尤其是在生成跨模块代码时不要奢望 Codex 记得你两小时前说过的一句话。把约束写进AGENTS.md让它每次自动读取比在聊天里反复说一百遍都管用。5.2 WorkBuddy 相关技能不生效与知识库失联WorkBuddy 用起来最常见的问题有两个一个是 Skill 配置完了但不触发另一个是调知识库的时候查不到东西。Skill 不触发九成原因是触发条件写得太窄或者太宽。太窄必须用户输入“我要报销”才触发但实际上客户说的是“这个钱怎么报”太宽任何包含“钱”字的消息都触发导致别的流程被打断。调试办法没有巧劲就是拿真实聊天记录去测一条条调触发词。知识库失联的问题一般出在向量检索的相似度阈值上。阈值设太高检索结果为空设太低返回一堆没用的片段。不同业务场景的最佳阈值不一样客服场景我建议从 0.2 左右开始调。另外提醒一下每次更新知识库后要确认新增的切片确实被正确向量化并写入了库中有时清洗环节会把关键内容误删。5.3 业务侧阻力不是 AI 不行是人不配合技术问题我反而不担心真正翻车的地方在组织层面。最常见的是业务方不提供真实数据、不参与规则梳理、上线后拒绝使用。我解决这个问题的方法有点“土”让业务方参与到验收标准的制定中来并且验收结果直接向管理层汇报。当客服主管自己定下“分类准确率要 90%”这个目标后她会主动跑过来告诉我知识库里还缺哪些常见问题。因为目标是她定的她就有责任去达成。比技术方案更有效的是利益绑定。5.4 常见问题速查表问题现象可能原因排查方法Codex 报本地代理连接失败企业代理白名单未放行接口检查代理配置、放行 API 域名Codex 提示模型不支持指定了环境不支持的模型名查询模型列表改用默认模型Codex 生成代码风格和项目不统一未配置 AGENTS.md补充项目规范文档WorkBuddy Skill 不触发触发条件设置不当用真实对话逐条调触发词AI 回答明显错误但知识库有正确内容向量召回阈值不合适调低相似度阈值、检查切片质量业务方拒绝使用 AI 产出验收标准未和业务绑定让业务方参与制定验收目标AI 生成代码引用不存在的工具类缺项目上下文约束在 AGENTS.md 声明既有工具包6. 落地效果与持续迭代机制6.1 可量化的收益怎么统计这套 FDE AKA 定制做完后最直观的变化是客服工单分类时间从平均 3 分钟降到 5 秒内AI 起草回复让客服的单条处理时间从 6 分钟降到 2 分钟。但我觉得最有说服力的不是这些数字而是客服团队态度的转变。上线第三周客服组长主动跑来说“能不能让 AI 也帮忙起草周报”。当业务人员开始主动给 AI 找活干的时候这个项目才算真正落地。要说服老板追加投入必须有硬数据。我的建议是最少统计两个指标人效提升率和差错率变化。人效提升率 原单条处理时长 - 现单条处理时长/ 原单条处理时长差错率变化 原人工差错数 - 现差错数/ 原差错数。这些数据能从工单系统直接拉出来不用额外采集每周出一张报表。6.2 知识库必须持续喂养很多团队以为知识库建完就结束了这是最大的误区。业务在变、产品在变、政策在变知识库不更新三个月后 AI 又开始“一本正经地胡说八道”。我建议建立一个“周更”机制每周五下午由值班客服把本周遇到的新问题、新话术、新政策整理出来由我用半自动化脚本做清洗、切分、向量化、入库。整个过程控制在半小时内。知识库更新不能依赖技术团队单独做必须让业务方成为知识的生产者技术团队只做加工和审核。6.3 从单场景复制到多场景第一个场景跑通后这套方法论就可以横向复制了。我现在正在做的就是把工单分类的模式复制到销售线索筛选场景同样是分类、同样是优先级判断、同样是话术生成FDE 拆法几乎一模一样AKA 的知识库换成销售知识就可以。这类项目的可复制性比大多数人想象中要强因为骨架是一样的业务规则要被显式化业务知识要被向量化AI 工具要被深度配置化。你只要走过一遍全流程第二遍、第三遍就只是换数据和换场景的事。我个人在这几轮项目里最深的一个体会是企业 AI 落不落地真的不取决于模型多聪明而取决于你愿不愿意做那些“看起来很笨”的脏活累活——翻工单、理文档、定规则、设阈值。把这些功夫下足了Codex、WorkBuddy 自然会从“高级玩具”变成“生产力工具”。
