企业官网建设流程全解析

最近和几个技术负责人聊天，大家问得最多的不是“AI 能干什么”，而是“公司明明买了 Codex，也搭了 WorkBuddy 工作台，AI 为什么还是没落地？”这个问题我感触很深。我见过太多团队把工具买回来、权限开好、账号发完，然后发现 AI 在真实业务里既不靠谱也不可控，最后又退回人肉写代码、人肉查资料的老路。我自己的判断一直没变：AI 落地难的从来不是模型能力，而是没人把“任务定义”和“知识上下文”这两件事做扎实。这篇就用我最近给团队做的一套深度定制方案——FDE + AKA——来完整复盘一下问题到底出在哪、我是怎么改的，以及你可以怎么抄这份作业。

先解释两个词。FDE 是 Feature-Driven Engineering，特性驱动工程。它不是新岗位，而是一套把模糊业务需求变成 Agent 可执行任务的方法论：先拆特性边界，再写机器可读的任务定义，最后按定义执行和验收。AKA 是 Agent Knowledge Architecture，Agent 知识架构。它解决另一个问题：让 Agent 在正确的时机、用正确的检索姿势，拿到正确范围的企业知识。二者配合起来，Codex 这类编码 Agent 才知道该动哪个文件、不该动哪个模块；WorkBuddy 这类工作台才能真正从“文件检索器”变成“能干事的协作者”。

这篇文章我不会吹“AI 通用能力”或者“一键落地”，只讲我实操下来的完整路径、任务定义怎么写、知识库怎么组织，以及中途踩过的坑。

1. 为什么 Codex、WorkBuddy 买回来却不干活

1.1 Codex 在真实业务代码库里的水土不服

先说 Codex。Demo 阶段它是真能打：给一个 GitHub issue，它能自己列计划、改代码、跑测试，看起来和资深工程师差不多。但一进真实业务仓库，问题马上就暴露了。

真实业务代码库是什么样的？几百万行代码、几十个微服务、权限模型藏在三个模块里、慢接口的根因在底层公共包、有些“历史遗留”代码没人敢动。Codex 面对这种场景，最常见的表现是：它能定位到文件，但定位不到“真正的决策依据”。比如你让它优化一个查询接口，它会凭经验猜测是缺索引，然后给你加索引；但你们数据库其实是读写分离的，从库延迟本来就高，真正的问题是跨服务调用次数太多。Codex 没有看到调用链、没有读监控数据、不知道架构约束，所以产出一份“语法完全正确、逻辑完全跑偏”的代码。

这不是模型笨，是上下文没喂够。Codex 的上下文窗口是有限的，你不能把整个代码库塞进去。它需要有人告诉它：问题边界在哪、哪些模块允许动、验收标准是什么、哪些技术手段被禁止。这恰恰是企业落地时最缺的环节。大多数团队只是把 Codex 连上仓库，然后丢一句“帮我看下这个接口为什么慢”，后续全靠模型自由发挥。自由发挥在开源 demo 里是亮点，在业务代码里就是事故现场。

1.2 WorkBuddy 更像“昂贵的搜索引擎”

再说 WorkBuddy 这类 Agent 工作台。我理解它的定位是给团队提供一个可编排的 AI 工作环境：可以挂知识库、配工具、让多个 Agent 协作。听着很美好，但我们实际用下来，早期阶段它做得最多的事是“搜索”。

为什么？因为知识库没结构化。大家把 PRD、技术方案、接口文档、运维手册一股脑扔进去，WorkBuddy 能帮你找到“哪份文档提过这个模块”，但它不理解这份文档在当前任务里到底是参考、是约束、还是已经失效的旧规范。结果就是：你问它“订单超时怎么排查”，它会给你翻出三份互相矛盾的文档，一份说用 Redis 分布式锁，一份说改数据库状态机，还有一份是四年前已经废弃的定时任务方案。Agent 没有能力判断哪份文档说了算，最后只能把所有可能性都列出来，让你自己选。

这本质上是一个知识治理问题。企业买 WorkBuddy 买的不是一个搜索引擎，而是一个能干活的 Agent。但如果底层知识是“一锅炖”，Agent 的表现就永远停留在“帮你搜资料”的层面。我后来总结了一句话：没有知识架构的 Agent 工作台，只是把内部 wiki 换了个 AI 皮肤。

1.3 根因：买的是工具，缺的是落地的工程闭环

把 Codex 和 WorkBuddy 的问题放一起看，根因其实很清楚：工具本身没问题，缺的是把它们接入业务的那层“工程闭环”。我把它拆成三个断层。

第一是任务断层。业务方说“这个页面太慢了”，产品经理翻译成“优化列表接口性能”，然后直接丢给 AI。中间没有经过“特性拆解——验收标准定义——约束条件声明”这个环节。AI 拿到的是一个模糊目标，它只能靠猜。

第二是知识断层。企业知识散落在代码、文档、人员经验里，Agent 不知道哪些是权威、哪些已过期、哪些在这个任务里必须遵守。它没有一张“知识地图”，自然无法形成决策依据。

第三是流程断层。AI 产出的代码，没有和代码评审、CI 检查、性能回归、发布规范串起来。它改完就说“完成了”，但没有人验证是不是真的完成了。工具变成了一个“AI 建议生成器”，而不是研发流水线里的一环。

这三个断层不补上，换任何模型、买任何平台都没用。接下来的 FDE + AKA，就是我从这三个断层入手做的深度定制方案。

2. FDE：把“生成代码”升级成“交付功能”的工程方法

2.1 FDE 到底在解决什么问题

我给团队做定制的第一个切入点，是重新定义 AI 的任务输入方式。以前大家习惯用自然语言描述任务，比如“优化用户列表接口”。这种描述对人类没问题，人类会脑补上下文；但对 Agent 来说，它不知道“优化”的量化标准是什么、范围是只改查询还是可以动表结构、验收时怎么判断成功。

FDE 的核心思想是：把任务从“一句话需求”升级成“一份特性定义”。所谓特性（Feature），是指一个可独立交付、可独立验收的业务功能单元。特性不是越大越好，也不是越小越好，它应该满足三个条件：有明确的价值目标、有清晰的改动边界、有可执行的功能清单。

这个思路其实不新鲜，早年特征驱动开发（Feature Driven Development，FDD）就有类似影子。但我把它做了改造：FDE 的目标读者不是人，而是 Agent。也就是说，这份特性定义必须写成人能看懂、Agent 也能直接消费的格式。人类看它，可以快速理解“这个任务要干什么”；Agent 看它，能直接提取出边界、约束、验收清单，并据此规划代码修改。

你可能觉得：“这不就是写清楚需求吗？”对，但差别在于：普通需求文档是给人读的，充满模糊形容；FDE 的定义是给机器读的，每一项都必须是可校验的陈述。比如“性能要好”是不可校验的，“响应时间低于 800ms”才是可校验的。

2.2 FDE 四步循环：Feature-Definition-Execution-Evaluation

我实际落地时，把 FDE 拆成四个环节，形成一个闭环。

第一步是 Feature 拆解。接到一个需求后，先别急着让 AI 改代码，而是先人工判断：这个需求能不能拆成若干个特性？每个特性的边界在哪？哪些模块属于本次范围，哪些明确不算？这一步的主要产出是一份范围清单，比如“本次只改 user-service 的查询链路，不改订单服务，不动数据库表结构”。

第二步是 Definition 编写。把拆好的特性写成结构化定义。这里我建议用 YAML 或 JSON，而不是纯文本，因为机器解析方便、字段不容易遗漏。定义里至少要有目标（Goal）、范围（Scope）、验收标准（Acceptance Criteria）、约束条件（Constraints）、禁止事项（Donts）。禁止事项特别重要，它能挡住 Agent 的“自由发挥”。

第三步是 Execution 执行。把定义交给 Agent 后，不是撒手不管，而是让它先输出执行计划、再动手改代码。我会要求 Agent 遵循一个固定路径：先解读数据表结构和现有实现，再选择一个最小改动方案，最后自测并逐条对照验收标准。这个环节最怕的是 Agent 跳过计划直接写代码，所以我通常会在提示词里强制要求“先给方案，再改代码”。

第四步是 Evaluation 验收。Agent 提交结果后，不能只看“代码编译通过”，要逐条跑验收标准。能自动化的（比如单测、性能脚本）全部自动化；不能自动化的（比如业务语义是否正确）要人工复核。FDE 的验收不是一次性的，Agent 如果没过，要把失败原因写回来，回到第二步修正定义，形成一个循环。

这个四步循环最大的价值，是把不可控的“AI 自由发挥”压缩到可控范围。你给 AI 的空间是有限的：目标是你定的，边界是你画的，做不做由验收说了算。

2.3 实操示例：把一个工单改造成 FDE 任务定义

下面给你看一个真实的简化示例。团队接到一个性能工单，原文是：“用户列表接口最近很慢，老板很急，你优化一下。”

如果用传统方式丢给 Codex，它大概率会加个索引、改个查询，然后说完成。但按 FDE，我会先把它改写成这样：

feature: user-list-optimization goal: 将 GET /api/users?page=1 的响应时间从 2.5s 降低到 800ms 以内 scope: include: - src/application/user_query.go - src/infrastructure/user_repository.go exclude: - src/interface/auth - src/domain/user.go # 领域模型不允许改动 acceptance: - 500万行数据、冷缓存场景下，P95 响应时间低于 800ms - 现有分页接口的返回字段和格式不变 - 慢查询日志中不再出现该接口对应的全表扫描 - 新增索引必须通过 EXPLAIN 验证，且查询计划命中索引 constraints: - 不允许引入新的中间件或缓存组件 - 数据库必须兼容 MySQL 5.7 - 不能改变用户表的写入性能，写延迟增幅不超过 5% donts: - 不要为了优化一个接口给所有字段加索引 - 不要修改 API 返回结构 - 不要绕过 repository 层直接写 SQL dos: - 先分析当前慢查询日志，定位耗时点 - 用 EXPLAIN 验证当前查询计划 - 优先考虑组合索引和覆盖索引 - 改动完成后提供性能对比数据

为什么这份定义能提高落地成功率？因为它把所有可能导致偏差的地方都提前锁死了。“改动返回结构”是 Agent 最容易自作主张做的事，donts 把它挡住；“500 万行数据冷缓存”给验收设置了真实场景；“写延迟增幅不超过 5%”要求 Agent 权衡读优化和写开销，不能只顾一头。

这份 YAML 写好之后，我会把它放到任务启动目录下的 AGENTS.md 或者直接作为 codex 的 instructions 内容。Codex 在读取上下文时，会把这个文件作为最高优先级指令。实测下来，一次性通过的比率比“裸奔”提示词提高了不少。这个后面细说。

3. AKA：给 Agent 一张企业知识的地图和规则

3.1 AKA 的概念与组成

FDE 解决的是“任务定义”，但 Agent 光知道要干什么还不够，它还得“知道去哪儿找依据、该信什么、不该信什么”。这就是 AKA 的活。

AKA，Agent Knowledge Architecture，是一套面向 Agent 的知识组织方式。它和普通知识库的区别是：普通知识库只关心“内容是什么”，AKA 还关心“这份内容在什么场景下是权威的、什么场景下是参考的、什么场景下应该直接忽略”。

我最早做 AKA 是被一个事故逼出来的。团队把技术文档全部接入 WorkBuddy 之后，Agent 在处理订单支付问题时，引用了一份已经废弃的“旧支付网关切换方案”，导致代码改得完全不对。事后排查发现，知识库里没有给文档打“效期”和“适用范围”标签，Agent 分不清新旧文档的优先级。从那天起，我开始给知识库加规则、加层级，AKA 的雏形就出来了。

AKA 不只是一个目录，它包含三部分：知识内容、知识元信息、检索规则。知识内容就是文档、代码示例、接口说明；知识元信息是这些内容的状态、适用范围、权威级别；检索规则则决定 Agent 在回答哪类问题时，优先去哪个知识源取数。

3.2 四层知识架构：产品层、代码层、流程层、治理层

我实际搭建 AKA 时，把企业知识分成四层。这样的分层不是为了好看，而是为了保证 Agent 在不同任务阶段能拿到不同粒度的上下文。

第一层是产品层。它包含用户故事、PRD、业务指标、功能验收口径。产品层的知识用来回答“为什么要做这个功能”“业务上什么叫成功”。比如一个“优化购物车”的任务，Agent 需要知道购物车的核心业务指标是转化率和结算率，而不是笼统的“好用”。

第二层是代码层。它包含模块地图、接口契约、数据模型、测试基线、历史变更记录。代码层解决“现状是什么”。Agent 动手改代码前，应该从这里了解项目结构、命名规范、常用设计模式。我会把这块做成模块地图，标注每个模块的职责、依赖关系、易错点。Codex 检索到这里时，不会迷茫于几百个文件，而会按图索骥。

第三层是流程层。它包含研发流程、评审规范、发布策略、回滚方案。流程层解决“怎么交付”。Agent 不是只负责写代码，它写的代码要能通过 CI、能被评审、能安全上线。所以它在设计解决方案时，就得知道你们的发布窗口、灰度策略、数据库变更审批要求。

第四层是治理层。它包含权限边界、技术选型约束、安全红线、禁用依赖。治理层是硬约束，Agent 在任何情况下都不能违背。比如“生产环境数据库禁止直接执行 DELETE”“禁止引入未经安全评估的开源库”“支付相关代码改动必须由人工复核”。这些内容如果只写在文档里，Agent 大概率会忽略；必须写成可检索的规则条目，并且在提示词层面反复强调。

这四层之间的关系是：产品层定义目标，代码层定义现状，流程层定义路径，治理层定义底线。Agent 在执行任务时，每一层都得有，缺一层就可能跑偏。

3.3 AKA 如何约束上下文窗口与检索策略

你可能发现了，AKA 本质上是一套“知识路由”机制。它的核心问题不是“有什么知识”，而是“当前任务应该给 Agent 哪些知识”。Codex 的上下文窗口有限，你不能把几千页文档全部塞进去；塞得越多，模型越容易抓住次要信息而忽略关键约束。AKA 要做的是，根据 FDE 任务定义中的 Goal 和 Scope，动态决定检索范围。

我在 WorkBuddy 里是这么配置的：每个特性任务会带一个“知识检索上下文”，告诉 Agent 需要关注的代码目录、需要遵守的治理规则文件、需要查阅的历史决策记录。同时我会把知识库里的文档按 AKA 四层打上标签，比如layer: product、layer: process、authority: high、status: active。检索时，WorkBuddy 只取和当前任务标签匹配的高权威文档，过期文档直接不返回。

举个例子。一个“用户列表接口优化”任务，AKA 会返回四类内容：模块地图里 user-service 的职责注释（代码层）、该接口的契约文档（代码层）、数据库变更审批流程（流程层）、禁止直接修改表结构的规则（治理层）。它不会返回四年前的技术方案，也不会返回和用户模块无关的订单知识。检索结果变精准了，Agent 的决策质量自然就上来了。

这部分我踩过的坑是：一开始想做大而全的知识图谱，把所有文档都结构化，结果投入巨大、收益甚微。后来改成了“FDE 驱动知识沉淀”：只针对正在推进的特性任务，沉淀对应的 AKA 条目。任务做完，知识也就留下了，团队付出的额外成本很小。

4. 深度定制实录：一次数据库索引优化的完整落地

4.1 场景目标：让 Codex 接手性能优化工单

前面讲了很多概念，这部分拿一个我实际完成的案例，完整串一遍。我们团队有一个用户列表接口，线上 P95 响应时间到了 2.6 秒，业务方天天催。以前这类工单都是让资深后端看，现在我们的目标很明确：让 Codex 在 FDE + AKA 的框架下，自主完成这个性能优化任务，并且结果要过人工评审。

这个场景适合做试点，因为边界清晰：只涉及 user-service 一个服务，影响面集中在查询链路，验收标准可以用性能指标量化。而且风险可控：即使 Codex 改坏了，回滚成本也不高。我经常说，选试点场景不要选核心交易链路，先选一个“坏了也不致命、指标能量化、边界很清楚”的功能。

任务启动前，我先做了两件事。第一件事，把这套任务写成 FDE YAML 定义，就是 2.3 节那份文件，放到 Codex 工作目录，并把它设为 instructions 的一部分。第二件事，按 AKA 准备知识上下文：拉了用户表的 DDL、当前慢查询日志的片段、该接口的 controller/service/repository 调用链、以及团队关于 MySQL 索引规范的一页规则。这些知识放进 WorkBuddy 的知识库里，打上 AKA 标签。

4.2 FDE + AKA 的配合方式

整个执行过程，FDE 和 AKA 是这样配合的。第一步，Codex 读取 FDE 定义，知道目标是把 2.5s 降到 800ms，也知道不能动返回结构、不能引入新组件。第二步，Codex 向 WorkBuddy 发起知识检索，WorkBuddy 按 AKA 标签返回四类内容：用户表结构、接口调用链、索引规范、数据库变更审批要求。第三步，Codex 基于这些上下文输出解决方案。

Codex 当时给出的方案是：在user_group和status两个字段上建一个组合索引，因为慢查询日志显示 WHERE 条件里这两个字段的过滤性最好。这个方案本身是对的。但你注意，这里有一个容易踩坑的点：Agent 提出建索引方案时，它并不知道这个表有多少存量数据、建索引要花多长时间、会不会锁表。AKA 里如果只有 DDL 而没有“这个表有 500 万行”这个元信息，Agent 就会漏掉迁移评估。

我在 AKA 的四层知识架构里，代码层要求必须记录“数据量级”和“变更风险提示”。这次就是因为 DDL 里标了“行数约 500 万，ALTER TABLE 需走变更窗口”，Codex 自动补了一版执行计划：先分析索引创建耗时，再建议在低峰期执行，并生成了回滚脚本。这就是 AKA 知识粒度的价值：它让 Agent 看到了代码之外的运维现实。

改进完成后，Codex 跑了一轮自测：用 EXPLAIN 验证查询计划是否命中新索引，又写了一个简单的压测脚本模拟冷缓存场景。这些验收动作不是我手动指挥的，而是 FDE 定义里的 acceptance 字段驱动它执行的。它知道验收标准是什么，所以会主动去做验证，而不是改完代码就说“完成”。

4.3 定制前后的效果对比

这个案例上线后，我统计了一份效果对比。我不喜欢“感觉上变好了”这种结论，凡事用数据说话。对比维度是：一次通过率、返工次数、平均处理时长、需要人工介入的节点数量。对比对象是同一个团队在没有 FDE + AKA 之前用 Codex 处理性能工单的表现。

需要说明的是，这个提升不是模型变强了，也不是 Codex 开窍了，而是我们把任务定义和知识上下文这两个“变量”控制住了。同样的模型，输入从“一句话模糊需求 + 空上下文”变成“结构化定义 + 精准知识”，输出质量必然有质的提升。

4.4 过程中踩过的坑和处置记录

这次定制不是一帆风顺，我踩过几个坑，写出来给你避雷。

第一个坑是任务定义太细。FDE 刚落地时，我把验收标准写得极其苛刻，比如“响应时间必须不超过 400ms”“必须使用覆盖索引”“不允许任何额外排序”。结果 Codex 为了满足性能指标，开始写非常怪异的查询，绕过了原有架构，后来被 Code Review 打回。教训是：验收标准要贴合真实业务，不要为了追求完美指标逼 Agent 走极端；约束条件的数量也要克制，否则 Agent 会为了满足 A 约束而违反 B 约束。

第二个坑是知识一次性灌太多。有一次我把用户服务全部文档都放进了检索范围，想着“多给点知识总没错”，结果 Codex 被一份过期架构文档带偏，地用了已经废弃的数据库连接池方式。这就是 AKA 没做好的表现。后来我强制要求：知识检索范围必须和 FDE 的 scope 字段对齐，scope 以外的知识默认不返回。宁可少给，不能给错。

第三个坑是验收标准无法自动判断。FDE 里有一条验收标准是“写延迟增幅不超过 5%”，但 Codex 自己没法验证这条，因为它没有写入压测环境。一开始它直接忽略这条，后来我把它在任务里标成“需要人工复核项”，让 Agent 在交付说明中明确写出“此条待人工验证”，而不是假装完成。这也提醒我：FDE 的验收标准要区分“Agent 可自验”和“需人工验证”，不然验收环节会失真。

第四个坑是回滚预案初始化。Codex 第一次提交索引变更方案时，没有任何回滚信息。我后来在 FDE 模板里加了一个必填项：回滚计划。Agent 必须给出“如果索引导致写入性能下降，如何快速删除索引并验证老查询计划”的方案，才允许提交。这一条在后续几次变更里救了我们好几次。

5. 企业导入 AI 工具的分阶段落地路径

5.1 阶段一：选小场景，固化模板

如果你看完前面内容，准备在自己团队里落地，我建议你分阶段走，不要一上来就搞大平台、大知识库。

第一阶段的核心是“选小场景 + 固化模板”。先挑 3 个左右的特性任务，要求边界清楚、指标可量化、风险可控。比如“优化某个接口性能”“修复某个模块的空指针问题”“给某服务补充单元测试”。然后为这几个场景写 FDE 定义模板。模板不需要一套通用，你要针对每个场景设计字段。等模板跑顺了，团队会慢慢养成习惯：拿到需求先写定义，定义写不清楚就不开工。

这个阶段不要急着建知识库，先把任务定义流程跑通。你会发现，让业务方和技术团队把目标写清楚，本身就已经解决了一大半“AI 不落地”的问题。因为很多时候，人是靠默契在交流的，AI 没有默契，只能靠清晰的定义。

5.2 阶段二：把专家经验沉淀成 AKA 知识图谱

第一阶段跑通后，进入第二阶段：开始沉淀 AKA 知识架构。这个阶段最有效的方法不是请咨询公司来做知识梳理，而是跟着 FDE 任务走：每个任务完成后，回看这次 Agent 缺了什么知识、问过什么问题、哪些信息是靠人工补充的。把这些内容补进 AKA 的对应层级。

比如这次索引优化任务，团队资深工程师口述了“这个表写入量大，建索引要注意锁表”，这就是一个典型的知识沉淀点。把它结构化成一则代码层知识条目，打上适用范围标签，后续 Agent 再遇到类似任务就有依据了。

这个阶段要特别注意知识的“新鲜度”。AKA 不是建完就结束了，它需要持续维护。文档废弃、架构调整、依赖升级，都要同步更新知识条目。我建议把 AKA 更新纳入 Code Review 流程：Agent 改了架构，必须同步改对应的知识条目，否则不通过。

5.3 阶段三：把 Agent 工作流缝进研发闭环

前两个阶段解决的是“单点任务做好”，第三阶段要考虑“流程闭环”。Agent 产出代码不算完，它要能和现有的代码评审、CI、发布流程打通。

我会建议把 Codex 和 WorkBuddy 接入内部的代码托管平台：Agent 提交代码时自动创建 MR（Merge Request），MR 描述里附带 FDE 任务定义和验收执行结果；CI 流水线自动跑单测和性能检查；评审人看到的不只是“AI 改了几行代码”，而是“AI 基于什么目标、在什么约束下、做了哪些改动、自验结果如何”。这个信息透明度很重要，它让评审人敢于给 AI 的代码放行，而不是每次都要从头理解一遍。

流程闭环还包括失败反馈。如果 Agent 的改动被评审打回，打回原因要结构化记录，比如“违反治理层第 3 条”“性能验收未通过”“知识检索定位错误”。这些反馈会回流到 FDE 定义和 AKA 知识库中，形成正向循环。这其实就是把 AI 当成一个新人工程师来带：它犯错，你纠正，它记住，下次改进。

5.4 常见问题速查表

最后整理一份这个落地过程中团队问得最多的问题，直接给对策。

这张表里的问题，我基本都遇到过。有些问题表面看是模型问题，追到根上都是任务定义或知识治理的问题。别急着换更强的模型，先把这两件事补上。

跑了两个多月，我最深的体会是：AI 落地的瓶颈从来不是 API 贵不贵，而是你有没有一套方法，把模糊业务拆成清晰任务，再把组织知识变成 Agent 能消费的上下文。FDE 让你的 Agent 知道要干什么，AKA 让它知道去哪儿找依据。这两件事做扎实，Codex、WorkBuddy 这类工具才真正算接入业务，而不是躺在工具架上吃灰。

最后分享一个小技巧：不要试图一开始就定制一个大而全的平台。挑一个收益高、边界清的场景，把 FDE + AKA 跑通，做出一个让团队惊艳的案例，再慢慢向外复制。我最早就是在“用户列表接口优化”这一个场景上跑出信心，后面才逐步扩展到订单、库存、报表模块。AI 落地就像滚雪球，第一把雪最难捏，但只要你把框架搭对，后面的路会越走越顺。