企业官网建设流程全解析

说实话，每次听到“我们公司已经买了 Codex 和 WorkBuddy，AI 落地应该没问题了吧”，我都不知道怎么接话。因为过去三个月里，我至少和五家企业的研发负责人做过类似交流，他们买了工具、开了账号、拉了企业版，结果一个月之后打开后台，活跃用户还是那两三个技术极客，业务部门根本没把 AI 当回事。问题从来不是工具不够强，而是没有人把这些通用工具拆开、揉碎、重新嵌进企业内部真实的业务流程里。

我自己是做 FDE（Forward Deployed Engineer）的，通俗讲就是“带着 AI 方案到客户现场，把最后一公里补完的工程师”。这岗位这两年特别火，但干的事情其实很素：弄清楚业务到底想要什么，然后动手把 Codex、WorkBuddy 这类现成产品改造成符合企业语境、数据、流程、甚至员工习惯的样子。我自己的做法总结起来就是一句话：用 FDE 的视角做现场分析，再用一套叫 AKA 的方法论去完成深度定制。这篇文章就把这套思路、具体步骤和踩过的坑都摊开讲一讲。

1. 先泼一盆冷水：买了 Codex 和 WorkBuddy，AI 为什么还是摆设？

1.1 Codex 很强，但它是个“不懂业务的外包程序员”

Codex 这类 AI 编程智能体，能帮你写单元测试、补注释、做简单重构、解释陌生代码库，确实是把好用的“实习程序员”。可问题也恰恰出在“实习”这两个字上。它能读懂你的代码，但它不读你的需求文档、不明白你们内部权限怎么走、不知道你们发布的版本管理规范是什么。你给它一个 ticket，它能写出一段漂亮代码，但这段代码很可能不符合你们的数据库字段规范、没有接统一的日志框架、也绕过了你们必须走的 CR 流程。

我见过一个做电商系统的团队，直接把 Codex 接到工单系统里，让它自动修 bug。结果 Codex 把几个很隐蔽的库存扣减问题用“看似合理”的方式修了，测试也过了，上线后引发了对账异常。不是 Codex 能力不行，而是它没被告知“库存扣减必须走事务、必须加乐观锁、必须记录操作人”。这种业务上下文，是没写进代码库里的，它怎么可能凭空知道？

1.2 WorkBuddy 给了你工作台，但没有“定制”就只是空架子

再说 WorkBuddy。它本质上是一个面向企业的 AI 智能体编排平台，你可以搭建业务工作台，配置各种 Skill，让多个 AI 模型协同干活。听起来很完美，但大多数企业把它买回来之后，只是把文档丢进去，建了一个“智能问答机器人”，然后就没有然后了。

问题在哪？在于 WorkBuddy 只是一个“台子”，台上摆什么工具、谁来触发、每一步怎么校验、结果反馈给谁，这些都需要你根据实际业务去搭建和编排。它不会自动知道你们市场部想要一个能抓取竞品动态的舆情分析 Agent，也不会自动帮你财务部做一个发票信息抽取的流程。没有深度定制，它就是一堆可用的“积木”散落在地上，业务部门看得到，却拼不出能用的东西。

1.3 本质：工具是“生产力”，但解决方案才是“落地”

这里我想拉高一个维度。很多企业把“引入 AI 工具”和“AI 落地”直接画了等号——这是目前最贵的一个认知误区。工具只提供可能性，落地是把可能性变成稳定的、可度量、可复用的业务流程。

拿做饭打比方。你买了一口好锅（Codex、WorkBuddy），不等于你就能开餐厅。你得琢磨菜单（业务场景）、备菜（数据与知识）、定火候（参数与流程）、培训服务员（用户习惯），最后才能端上来一道稳定出品的菜。我的 FDE 工作，干的就是帮企业把这个“从锅到餐厅”的过程补齐，而 AKA 就是我做这件事时反复验证过的操作框架。

2. 我为什么用 FDE + AKA 做深度定制？

2.1 FDE 工程师的角色：不是“你在现场”，而是“你替业务想清楚”

FDE 这个词最早在硅谷的 to B 公司流行起来，核心特点是“工程师不坐办公室，而是长期驻在客户现场”。在 AI 落地这件事上，FDE 的价值不是“现场写代码”，而是能把业务人员的模糊需求翻译成技术方案，再把技术方案变成能让业务人员直接上手的东西。

举个很典型的例子。业务部门说“我想要个 AI 帮我们自动写周报”。你不去现场听，就会设计出一个“用户输入几条内容，AI 生成周报”的简单应用。但如果你坐在他们工位旁边，你才会发现：他们实际需要的是从 Git 提交记录、任务管理系统、值班表、甚至项目周会录音里自动抽取关键信息，还要按不同 leader 的口味调整详略。这个需求，只有透过现场观察才能被真正看见。这就是 FDE 的“现场力”。

2.2 AKA 方法论：Assessment（现状评估）、Knowledge（知识注入）、Automation（自动化闭环）

AKA 是我在大量实战里沉淀出来的三阶段方法论。第一步是Assessment（现状评估），不急着建 Agent，先搞清楚“这个业务现在哪里最痛、谁在做、输入输出是什么、有什么异常分支”。这一步最容易被跳过，但恰恰决定了后面做出来的是“真有用”还是“玩具”。

第二步是Knowledge（知识注入），要把企业内部的知识资产结构化地送给 AI。很多企业觉得“我们有文档，丢给 RAG 就行”，这是远远不够的。文档只是知识的一部分，真正的知识还藏在代码命名规范、历史工单的处理方式、老员工脑子的经验判断里。知识注入要做的事，是把这些散落的东西变成 AI 可理解、可检索、可调用的格式。

第三步是Automation（自动化闭环），也就是把前面准备好的 AI 能力嵌进真实的业务流程里，带触发条件、带审批节点、带效果反馈。没有闭环，AI 只是个“偶尔被想起”的问答工具；有了闭环，它才会变成每天自动跑起来的流程的一部分。

2.3 为什么这套组合能解决“落地”问题？

FDE 和 AKA 的组合，恰好对应了落地过程中的两个缺口。

第一，落地最常见的失败原因是“技术方案和业务需求错位”。FDE 的现场工作方式，把这个错位在最早的评估阶段就暴露出来。第二，落地最慢的环节是“业务知识迁移”。AKA 的 Knowledge 阶段，把知识迁移从“碰运气”变成了“有工序”。第三，落地最难的环节是“让 AI 真正被用起来”。Automation 阶段把 AI 放在业务流程必经之处，不依赖自觉，而是靠流程驱动。

我自己做过的十几个项目里，凡是严格按照 AKA 走完的，基本一个月内都能看到业务侧的活跃率上来；凡是跳过或者颠倒步骤的，基本都变成了“演示很惊艳、日常没人用”的结局。

3. 深度定制实操：从评估到知识注入的完整工序

3.1 第一步：业务评估与场景裁剪，别贪多，先选一个能打穿的切口

我在现场做 Assessment 时，通常会拿着下面这张表格去和业务负责人聊，而不是空泛地问“你想用 AI 干什么”。

这里我特别想强调“风险可恢复”这条。第一次引入 AI 时，千万不要选那种“出错一次就出大事”的场景，比如自动对外发邮件、自动生成合同、自动扣库存。选这类高风险场景，AI 一旦出错，信任墙瞬间竖起，再想推就更难了。比较好的切入场景是：内部周报生成、竞品信息收集、代码审查初筛、工单自动分类、知识库检索问答。

我最近帮一家做工业软件的公司定制，最开始他们坚持要 AI 自动审合同。我硬是劝他们先做“合同条款风险预标记”——由 AI 把可疑条款标出来，业务律师仍然做最终审核。这样既大幅减少人工通读的时间，又把风险控制在了可恢复的范围内。这个决策后来被证明是项目能顺利推下去的关键。

3.2 第二步：领域知识注入，别只做 RAG，要分三层注入

很多企业做知识注入就是“把 PDF 往向量数据库一丢，然后说知识库搭好了”。这样做出来的效果，往往是你问它一个稍微专业一点的问题，它就给你一本正经地胡说八道。我通常把知识注入拆成三层来做。

第一层是结构化语料清洗。不要直接把 Word、PDF 拿来就拆，先做文档分类、去重、敏感信息脱敏，再切成适合检索的块（chunk）。切块不是按字数机械切，而是按语义边界切，比如标题、章节、段落。我常用的经验是：带小标题的文档按标题切，表格单独提取转成 Markdown，代码片段单独存成文本文件。这样检索命中率会明显高过无脑切 500 字一截。

第二层是业务规则注入。这一步是把那些没人写进文档里、但业务运行离不开的规则告诉 AI。举例说，你们公司的工单分为“咨询-故障-需求”三类，表面上是分类，但真实规则是：凡是涉及“退款”的一律算故障；凡是新功能建议一律算需求；只有关键词匹配还不够。把这些规则以“如果…那么…”的形式维护成一份规则集，再让 AI 在推理时优先读取，效果会好很多。这也算是一种轻量级的知识工程。

第三层是持续反馈修正。知识库不是一次性建完就不管了。AI 答错了，业务人员点“纠错”，这条记录要能回流到知识库里，成为新的训练/检索素材。WorkBuddy 里我会专门设计一个“反馈记录”的 Skill，由管理员定期审核，把高频错误问题合并成新的标准答案。这一步常被忽略，但它是知识注入长期有效的保证。

3.3 第三步：在 WorkBuddy 里搭专属工作流，Skill 是核心单元

当知识注入得差不多了，就轮到用 WorkBuddy 把它们变成可执行的工作流。我习惯把每个业务场景封装成一个独立的 Skill——这个词在 WorkBuddy 里类似“技能”，它约定了触发条件、输入参数、调用过程和处理逻辑。

拿“代码周报生成”这个场景举例子。我会在 WorkBuddy 里新建一个 Skill，叫weekly-code-summary，对应的定义大致如下：

name: weekly-code-summary description: 基于 Git 提交记录和任务管理数据，生成技术周报初稿 trigger: - 每周五下午五点 - 用户说“生成周报” input: git_url: 必填 project_id: 必填 steps: - pull_git_log # 拉取最近7天提交记录 - fetch_task_status # 从项目管理工具拉取任务状态 - merge_and_filter # 过滤无效提交，按模块归类 - call_codex_agent # 调用 Codex 生成变更摘要 - generate_report # 按模板生成周报初稿 output: - markdown_report - draft_message for leader

这里有个关键设计：我把“生成摘要”交给 Codex Agent，把“流程调度”交给 WorkBuddy。也就是说，WorkBuddy 负责组织，Codex 负责深度内容生产。这种多 AI 协作的架构，比单个 AI 干所有事情要稳得多。

在实际配置 Skill 时，还要注意设置人类审批节点。尤其是生成后行为——比如“周报自动发送到群”和“周报发送前由本人确认”——我强烈建议先选后者。只要跑顺两周，业务人员对输出质量建立了信任，再逐步放权。这是自动化闭环里很重要的渐进式信任策略。

4. Codex 接入与定制实战：让通用 Agent 学会你们的规矩

4.1 把 Codex 接进企业内部模型服务，配置示例

很多企业买了 Codex，默认用的是 OpenAI 的模型。但出于成本和本地化考虑，一些团队希望将它接到 DeepSeek 这类第三方模型服务上。Codex 是支持通过配置文件切换模型提供方的，我个人的做法是在初始化之后，修改模型配置文件。

# 初始化 Codex 配置 codex init

然后打开生成的配置文件，按下面的方式调整（不同版本字段略有差异，以实际 CLI 提示为准）：

{ "model": "deepseek-chat", "model_provider": "custom", "env": { "OPENAI_API_KEY": "sk-xxx", "OPENAI_BASE_URL": "https://api.deepseek.com/v1" }, "temperature": 0.2, "stream": true, "max_tokens": 8192 }

这里要说明，OPENAI_BASE_URL被很多兼容 OpenAI 协议的服务端所支持，本质上只是把请求转发到第三方模型的地址。配置完成之后，可以用一个简单提示词验证是否生效，比如让 Codex 解释一下当前项目的某个模块。如果 Codex 能正常读取代码并回答，说明模型连通了。

4.2 让 Codex 懂你的代码库：AGENTS.md 是不可或缺的“部门手册”

Codex 和很多 AI 编程工具一样，会优先读取项目根目录下的AGENTS.md文件——它相当于“给 CI 中的 AI 同事看的入职手册”。这个文件里写什么，直接决定了 AI 写出来的代码符不符合企业规范。

我以自己实践过的模板为例，一个典型的AGENTS.md至少应该写清楚四块内容：项目技术栈与目录结构、编码规范（命名、错误处理、注释语言）、必须遵守的架构约束（比如不能直接跨层调用、不能写死密钥）、以及测试和提交要求。

# AGENTS.md ## 技术栈 - 后端：Python 3.11 + FastAPI - 数据库：MySQL 8.x，ORM 使用 SQLAlchemy ## 编码规范 - 所有变量和函数使用 snake_case - 所有对外接口必须使用 Pydantic 定义请求/响应模型 - 日志必须使用 logging，禁用 print - 异常信息必须包含上下文，禁止裸 `except: pass` ## 架构约束 - Service 层禁止直接访问数据库，必须通过 Repository 封装 - 所有金额计算用 Decimal，禁止使用 float ## 测试和提交 - 新功能必须附带单元测试，覆盖率不低于 80% - 提交信息遵循 Conventional Commits

有了这份“手册”，Codex 的行为会立刻收敛很多。没有它的话，让 AI 生成代码就真的像和一个不看团队规范的外包人员合作，代码跑得通但没法维护。

4.3 多 AI 协作编排：Codex 当“执行者”，WorkBuddy 当“调度员”

在深度定制里，我最在意的不是单个 Agent 的能力，而是多个 Agent 之间的配合方式。Codex 适合做“深度智力型”任务，比如写代码、查文档、分析报错；而 WorkBuddy 上的业务 Agent 适合做“流程驱动型”任务，比如拆需求、调接口、汇总结果。

我会设计一个典型的协作链路：业务 Agent 先利用知识库判断工单类型，如果是代码问题，就把上下文（报错截图、日志、相关代码路径）结构化成任务单，交给 Codex Agent 去分析；Codex 返回分析结果和修复建议后，业务 Agent 再按模板整理成人话，附带风险说明，返还给用户。整个过程对用户是透明的，但底层是两个 AI 在接力干活。

这种协作的关键在于上下文交接格式。我习惯用统一的 JSON 结构来传递信息，避免两个 Agent 之间产生歧义：

{ "task_id": "T-20240221-003", "task_type": "bug_fix", "error_message": "TimeoutError: connection pool exhausted", "related_files": ["src/db/connector.py"], "observed_at": "2025-02-21 14:33:22", "requirements": ["不能改变现有调用方式", "需要增加重试机制"] }

多 AI 协作最好从“松耦合”开始：明确各自边界，用标准格式交换信息，而不是让一个 Agent 试图控制另一个 Agent 的全部行为。在 WorkBuddy 里，我基本只用它的流程编排来调度 Agent，而不是让 Agent 之间互相直接对话，后者容易失控。

4.4 参数调优：不是模型越强越好，而是“温度”和“上下文”最影响效果

很多人在深度定制时会忽略参数配置，觉得“反正 AI 会自动理解”。实际上同样的模型，参数不一样，输出稳定性差别很大。

我在定制 Codex 做企业内部代码生成时，温度会调得很低，0.1～0.3 之间。这样生成的内容更保守，不容易自作聪明。如果是做头脑风暴类、文案创意类的生成，温度可以提升到 0.7～0.9。第二个关键参数是上下文窗口，这决定了 AI 能“同时理解”多少内容。在为大仓库写代码时，我不只靠上下文窗口，还会用上面提到的 AGENTS.md 和模块级说明文件来控制输入范围，宁可让 AI 多做几次搜索，也不要把整个仓库一次性塞给它。

WorkBuddy 里配置模型时也要注意超时和重试次数。多 AI 协作时，任何一个环节超时都可能让整个流程卡住。我的经验是：把模型调用超时设为 60 秒，重试三次，第二次重试时减小上下文（比如去掉一些非关键的日志片段），往往就能顺利通过。

5. 常见问题与排查经验实录：这几张“求助帖”背后的真相

5.1 Codex 加载不了组织设置，多半是权限链路问题

不少朋友遇到过“无法加载组织设置”的提示。根据我的经验，这个问题的原因通常很朴素：当前登录账号不在目标组织的成员列表里，或者没有启用组织的制品权限。排查时我会先做三件事：第一，在官网确认账号角色是 Member 还是 Admin；第二，检查 CLI 是否已经用组织账号完成登录；第三，确认当前网络策略是否放通了对应域名的访问。多数情况下是权限没开完，而不是工具本身的问题。

5.2 报错“model is not supported”，先检查模型拼写和版本范围

有时候你会在日志里看到类似“the 'gpt-5.6-sol' model is not supported when using Codex”的报错（具体模型名看你配置），这类问题基本上是配置里填写的模型 ID 与你当前服务端支持列表不匹配。比如你写了一个内部还没上线的模型版本，或者把模型名写错了一个字母，就会触发这个提示。

我的排查步骤非常简单：先在服务端确认可用模型列表，再与本地配置文件逐一比对，注意大小写和版本后缀。如果你用的是第三方模型服务，请务必确认对方是否兼容你当前 Codex 版本所调用的接口协议。很多时候不是 Codex 不支持，而是它对接的那条链路本身就只兼容特定模型名。

5.3 WorkBuddy 的 Skill 一直触发不了，问题大概率出在“触发条件”设计

WorkBuddy 里 Skill 触发不了，我踩过的坑主要集中在两点。一是触发词和设备上下文不匹配。比如你写“用户说生成周报”，但实际业务人员习惯说“把周报整理一下”，就触发不了。建议做触发条件时把目标动作的常见说法都枚举出来，做成一个同义词列表。

二是 Skill 引用的数据源状态没就绪。很多 Skill 第一步是拉取上游数据，如果上游接口鉴权过期，或者字段名变化，Skill 整体就会静默失败。我后来养成了一个习惯：给每个 Skill 的 start 节点加一个“数据源体检”步骤，先快速校验上游接口，有问题就用日志形式告警，而不是让用户干等着。

5.4 多 AI 协作时结果互相矛盾？给 Agent 建立“决策优先级”

多 Agent 协作最头疼的问题是：业务 Agent 说“应该走流程 A”，而 Codex Agent 分析后觉得“可以绕过流程”。这个问题的根源在于没有给每个 Agent 设定决策权力边界。

我的解决方式是在每个 Skill 的配置里增加一个decision_policy字段，明确什么样的情况听谁的。比如：

这样定义清楚后，Agent 之间不是“比拼谁更聪明”，而是“各司其职”，冲突概率会大幅下降。

6. 定制完之后的效果与后续扩展：从“摆设”变成“离不开”

6.1 一个典型效果：从“部门无人用”到“每天早上自觉看”

我用 FDE + AKA 帮一家 SaaS 公司定制过他们的内部代码审查流程。刚买 Codex 和 WorkBuddy 时，每周的代码审查要占用三个架构师大约 10 个小时。做完定制之后，Codex 先做第一道自动化审查，把明显的问题（缺少测试、命名不规范、风险函数调用）全部标出来；WorkBuddy 里的审查工作台自动把这些问题按严重程度排序，附上相关代码片段，架构师只需要处理剩下的高级问题。

落地三个月后，三个架构师在代码审查上的时间降到了每周 3 小时左右。更重要的是，新入职的初级工程师开始主动用这个流程了，因为他们终于能看懂“AI 的批注”里关于规范的解释。工具就从一个“极客玩具”变成了团队工作的必经环节。

6.2 定制过程中的几条独家避坑经验

我把这几年做定制最想说、又很少被写在文档里的经验整理成几条：

• 先从“高频小场景”入手，不要一开始就追求大而全。一次只打通一个流程，比如“工单分类”或者“周报生成”，反复跑熟后再复制到其他场景，比一次性上一堆功能稳得多。
• 宁可让 AI 多问一句，也不要让它瞎猜。在设计 Skill 时，如果输入参数缺失，我通常会让 AI 停下来向用户确认，而不是擅自填默认值。业务场景里，一个错误的默认值可能比不回答更糟糕。
• 测试集要早期建立。开始定制前，先收集 20 条典型输入和对应预期输出，作为后续每一次调整后的回归测试集。这能防止“改好了 A，弄坏了 B”。
• 关注日志和可观测性。AI 流程会失败，不可怕，可怕的是失败后无迹可寻。我会在 WorkBuddy 每个 Skill 的关键步骤上打印结构化日志，记录输入、模型调用耗时、输出和异常。这样以后排查问题事半功倍。

6.3 后续还能怎么扩展：把 Skill 沉淀成部门模板库

当你在一个部门跑通了三个 Skill 之后，一个很有价值的延续动作是把这些 Skill 模板化。WorkBuddy 支持将 Skill 导出为模板，同一个公司里的其他团队可以直接在新场景中使用同样的结构，只需要替换业务知识库和触发词。这样你就不再是一个一个部门去救火，而是可以形成一个“AI 落地工具箱”，让每个部门都能基于模板快速搭建自己的专属工作流。

我个人现在的做法是维护一个内部 Skill 模板库，里面收录了“竞品分析”“代码审查”“周报生成”“客服工单分类”等十几个常用场景，每个模板都包含知识注入清单、Skill 定义、人审节点设置建议。新部门来求助时，我先拿模板快速试点，再根据实际反馈做二次裁剪。这套做法省去了大量重复的从零规划时间。

我自己的感受是：企业买了 Codex、WorkBuddy，其实并没有买错，错的是把它们当成“成品”而不是“原料”。真正让 AI 落地的，是 FDE 工程师愿意花时间去现场理解业务，是 AKA 一样扎实的方法论一步步把评估、知识、自动化串起来。每次项目做得筋疲力尽时，我都会提醒自己：让 AI 产生价值的从来不是一次炫酷的演示，而是第二天早上业务团队仍然愿意打开它、信赖它、使用它。这套路径不轻松，但沿着它走下去，AI 会从一开始的“摆设”慢慢变成团队里不说话但不可或缺的那个成员。