企业官网建设流程全解析

如果你做过前端，或多或少都会遇到这类场景：手头排了一堆页面，要求长得整齐划一，还得对齐项目的组件规范；想从团队组件库里抽一个现成的表单项，结果发现年代太久没人维护，自己动手改完还得补样式和测试；更别说个人项目里那种“今天忽然想搭个后台界面”的冲动，往往文件还没建几个，热情已经凉了。后来我开始用命令行和编辑器里的 AI 编程工具来处理这些重复劳动，Codex 就是这批工具里最能打的一个。它不只是一个会聊天的“懂代码的机器人”，而是能在你项目的真实目录里读取文件、修改代码、跑命令的自动化助手。我把一段需求文档丢进去，到它帮我生成能直接跑起来的前端组件，中间真的可以按秒计算。“秒级生成组件”这个说法，我是在实际写了一个星期的页面之后，才敢拿出来用的。

这篇内容不是官方文档的复读。我会把它当作一次完整的实操记录来写：从安装、登录、写配置，到给 Codex 立一套适合前端项目的规则，再用真实需求让它生产三个组件，最后把我在过程中踩过的坑和排查思路全摊开。如果你平时要写大量 React、Vue 组件，或者正在维护组件库，想把时间花在业务本身而不是反复搭架子，这篇文章大概率对你有用。为了方便不同基础的读者，我也尽量把每一步的“为什么这么做”写在后面。

1. “破局”先破在哪：Codex 和普通 AI 助手的本质差别

1.1 它读的是整个项目，不是你粘贴的片段

用 ChatGPT 或者其它聊天式 AI 写过代码的人，大概率经历过这种流程：把报错信息复制进去，再把自己写的那一坨代码粘贴进去，让 AI 帮忙看。遇到稍微复杂一点的场景，你还得手动补上相关依赖、目录结构、状态管理逻辑，否则它给出来的方案就像在沙滩上盖楼。Codex 的交互方式完全不同：它在你的电脑上启动一个会话，能够直接读取当前目录里的文件，搜索关键词，查看某个组件的实际实现，然后再决定往哪里改。

我第一次用的时候也习惯性地去复制粘贴，后来才发现它会在终端里显示“读取了哪些文件、接下来打算做什么”，那一刻我才意识到，它不是在猜我的项目长什么样，而是真的“看到”了。对前端来说这一点特别关键：你的组件库用什么版本、目录是 feature 划分还是类型划分、样式是 CSS Modules 还是 Tailwind，这些信息聊天式 AI 往往要靠你一次次喂，而 Codex 只需要一次授权就能自己翻。

1.2 交互模式变了：从“问答”变成“执行”

普通 AI 助手的产出终点是“一段你复制走的代码”，而 Codex 的产出终点是“一次你确认过的文件变更”。它会列出准备修改的文件清单，给出改动摘要，等你同意再落盘。这种交互模式对前端开发尤其友好，因为我们的工作天然是“多文件联动”的：改一个组件，可能同时要动它的父级调用、样式文件和测试快照。Codex 在会话里把一整条链路改完，你只需要逐项确认，而不是像过去那样满地捡拼图。

我观察到自己从“问 AI 要代码”到“审核 AI 的修改”这个转变后，很多低价值劳动就被稀释了。过去半小时要完成的页面，等组件规则定了之后，交给它搭起来，我再去做真正的 code review。这种体验让我觉得，所谓“破局”不只是在单位时间里多写了多少行，而是把人的注意力从“怎么写”转移到“写得好不好”上。

1.3 秒级生成背后，真正值钱的是“迭代速度”

说“秒级生成组件”，很多人第一反应是“AI 写代码很快”嘛。但我用下来，真正值钱的并不是首次生成的那几秒，而是后续的迭代速度。手写一个表单组件，第一次把样式和校验写完至少要十几分钟；但 Codex 生成完初版，你提一句“提交按钮在移动端要固定底部”，它可能几秒内就定位到对应 JSX 和样式文件完成修改。

这背后的逻辑是：AI 工具的价值等于“生成速度 × 修改速度 × 上下文保持能力”。Codex 在这三件事上都做得很到位，尤其是一个会话能保持对项目上下文的记忆，这样我反复提需求时不用重新解释技术背景。对前端工程师来说，这意味着你大脑里的“设计意图”到“可交互代码”之间的损耗被压到了最低。

2. 准备一台能跑的 Codex：安装、登录和最小配置

2.1 安装 CLI：npm 与 Homebrew 两条路

Codex 的官方客户端分两种：命令行工具（CLI）和桌面应用。我先从 CLI 说起，因为在自动化脚本、CI 流程和快速原型场景里，命令行始终是最稳的入口。如果你用的是 macOS 且装了 Homebrew，一行命令就能拉起来：

brew install codex

如果团队环境里更习惯 npm，也可以全局安装 OpenAI 官方发布的 npm 包：

npm install -g @openai/codex

安装完成后，在终端输入codex --version能打印出版本号，就说明装好了。我在 Windows 机器上也试过，官方提供了 Windows 桌面版安装包，操作上没有根本差异；不过平时开发主力建议还是用 WSL 或原生终端，主要是文件路径和脚本执行的体验更顺。

注意：无论从哪种途径安装，务必从官方渠道获取安装包，别在第三方网站下载来路不明的“绿色版”。这类工具需要访问项目文件，使用非官方版本等于把代码安全交给陌生人。

2.2 登录与凭证：把身份信息配置对

安装完接着就是登录。CLI 会引导你完成浏览器里的授权流程，登录成功之后凭证会保存在本地配置里，之后启动会话就不必再来一遍。如果你在 CI 环境里用，可以通过官方文档指引配置访问令牌，把它写到环境变量里给 Codex 读取。

我在实际使用中至少遇到过三种凭证状态：一种是已经登录但会话失效，表现为输入指令后立刻报认证错误；第二种是登录了 ChatGPT 账号，但某些模型权限受账号类型限制，导致选模型时被拒绝；第三种是用团队共享的 API 凭证，通常比较可控。后面第 5 章我会专门展开说模型权限那个坑，这里先提醒一点：尽早区分清楚“你手里的账号能访问哪些模型”，能避免很多莫名其妙的报错。

2.3 最小可用配置：三件事必须写在配置里

Codex 的配置文件在用户目录下的~/.codex/config.toml，初次登录后会自动生成。前端工程师拿到这个文件，我建议第一件事不是乱改，而是确认三样东西：默认模型、允许自动执行的命令范围、以及是否开启审批模式。

一个相对稳妥的最小配置是这样：

model = "你的默认模型名称" [approval_policy] # 允许执行读取类命令，写操作需要我确认 read_only = true untrusted = "read_only"

解释一下：model字段换成你有权限使用的模型即可，登录之后可以用官方文档的帮助命令查看可选范围；approval_policy是我个人强烈建议设置的部分。把写操作保持在“需要我确认”的状态，等到了信任它的时候再尝试放宽，别一上来就给满权限。

2.4 VSCode 插件：在编辑器里获得“掌控感”

光有命令行还不够，前端人的主战场在编辑器里。Codex 在 VSCode 里的扩展版我已经用了比较久，体验和直接在终端开会话没什么区别，但省去了切换窗口的麻烦。装好扩展后，左侧会出现 Codex 面板，你可以直接在编辑器里圈选代码、输入修改意图，Codex 会把 diff 展示给你，确认后才写入。

这种在编辑器里“圈选代码 + 提需求”的操作，对重构老组件特别顺手。我曾经把一个三百多行的旧表格组件交给它做拆分，选中整个文件之后只写了“把搜索区、表格区、分页区拆成三个子组件，保持对外 API 不变”，它给出的改动方案清晰到可以直接走评审。后来我基本形成了固定习惯：小改动去命令行走得快，大重构留在编辑器里看 diff，两边配合才最舒服。

3. 给 Codex“立规矩”：让前端组件像团队同事写出来

3.1 AGENTS.md：你项目的“第一份提示词”

很多人和 AI 编程工具配合不顺，问题不是出在 AI 能力上，而是出在“项目没有给 AI 立规矩”。Codex 会优先读取项目根目录下名为AGENTS.md的文件，把它当作自己行动的“项目总纲”。你在这个文件里写清楚工程规范、目录约定、组件写法禁忌，产出的代码就会明显向团队风格靠拢。

我接手一个中后台前端项目时，第一件事就是写了这份文件。里面会明确：这是一个 React 18 + TypeScript 项目，组件库是 Ant Design 5.x，状态管理用 zustand，组件都放在src/components下按页面划分；不允许直接写内联样式，必须使用项目已有的 Less 变量；新组件要求导出默认组件并提供类型定义。等 Codex 读完这份规则，它产出的代码质量立刻上了一个台阶。

3.2 前端规则至少要覆盖四个维度

给 Codex 立规矩时，我会往这四个方向写：框架与依赖、目录结构、样式方案、代码风格。这四个维度缺一个，就会出现“代码能跑但像个陌生人写的”的问题。

框架与依赖要让 Codex 知道“你不许乱引新库”，比如能用现有库实现的需求就不要擅自引入第三方包；目录结构要告诉它“新文件放哪里、对应的文件名怎么起”；样式方案要写清“BEM 命名还是 CSS Modules，尺寸单位用 rem 还是 px”；代码风格要规定“函数组件一律箭头函数、memo 包裹、props 类型必须导出”。把这些写进 AGENTS.md 之后，我几乎不再需要逐条纠正它的输出风格。

3.3 组件库和内部封装：规则要精确到“用哪个”

团队在前端项目里最怕的其实是组件库版本混用。如果项目里用了 Ant Design，同时又有人图省事引入了 Element 风格的碎片代码，样式和数据规范很快就会变得四不像。这事必须在 AGENTS.md 里用最明确的语气写死：优先使用哪个组件库、哪些组件是内部封装过的、封装组件的命名前缀是什么。

我实际踩过一个例子：第一次没写“表格列渲染统一使用项目封装的 ColumnRender 组件”，Codex 生成的列表页里直接裸写了render: (text) => <span>{text}</span>，虽然功能没问题，但和项目里其它页面的交互风格差异巨大。后来我把“列渲染必须走封装”写进规则，同类问题再没出现过。这个细节看似不起眼，但对维护组件库的人来说就是天壤之别。

3.4 一个仓库里既有 Vue 又有 React 怎么办

现在不少团队的老项目是“多框架混居”：管理后台用 React，一部分营销页还是 Vue 2。这种项目交给 AI 工具时最容易乱套，它可能把 Vue 组件写成 React 写法，或者在.vue文件里冒出 JSX 来。我的做法是在 AGENTS.md 的路径识别上下功夫，明确写出不同目录对应不同框架和规则。

例如这样写：“src/react/*下的组件必须用 React 函数组件 + TypeScript；src/vue/*下的组件必须用 Vue 3<script setup>风格；如果让你修改某文件，先判断它的后缀和目录归属再决定语法”。Codex 在上下文里读到这类分而治之的规则后，基本能做到“进哪个庙念哪个经”。这一步很关键，也最容易被人忽略，毕竟前端工程天然就是多技术栈并存的。

4. 实战记录：从零到三个组件，整个流程我拆给你看

4.1 场景拆解与提示词模板

空谈理论没用，我直接拿一个典型业务页面来演示。这个需求来自我手头一个商家管理后台：要做“客户资料编辑页”，包含一个表单组件、一个最近订单列表组件、和一个订单详情弹窗。过去这种需求我照着组件库文档抄，大概耗时一个下午；用 Codex 配合写好的 AGENTS.md，从输入需求到本地跑通，我截表记录的时间大概在十五分钟左右。

写需求时千万别只写一句“给我写一个表单”。给 Codex 的需求越具体，它的第一次产出就越接近终版。我的提示词模板是“背景 + 文件路径 + 功能清单 + 交互细节 + 验收标准”，五要素缺一不可。

下面是我们实际给 Codex 的提示词，供参考：

背景：在 src/pages/CustomerDetail 下实现客户资料编辑功能区。 要求：使用本项目 AGENTS.md 规定的 React + TypeScript + antd5 技术栈。 功能清单： 1. 客户基本资料表单，含姓名、手机号、邮箱、状态选择，其中手机号做 11 位校验； 2. 点击保存调用 src/api/customer.ts 里的 updateCustomer 接口，成功后弹出 Message； 3. 表单下方展示最近 6 条订单的列表，使用业务封装的 OrderTable 组件； 4. 点击列表行打开订单详情弹窗，数据从 getOrderDetail 接口读取。 验收标准： - 所有新增文件位于 src/pages/CustomerDetail/components 下； - 表单提交有 loading，校验失败滚动到第一个错字段； - 列表空状态使用 Empty 组件展示。

这串提示词我用了几次下来，最大的感受是“验收标准”四个字极其好用。你一旦写了可验证的硬要求，Codex 就不会交一个只强调“页面长出来”的半成品，而会自动去考虑 loading、空状态、接口错误这些真实场景。

4.2 表单组件：事件与校验逻辑的一次到位

按上面的提示词，Codex 在第一次会话里就生成了CustomerInfoForm.tsx和配套的CustomerInfoForm.test.tsx。我特别关注了手机号校验的写法，它没有用 antd 自带的rules正则走个过场，而是自定义了一个校验函数，确保在触发 onBlur 时才校验、避免输入过程中频繁报错。这个细节让我比较意外，说明它在读取 AGENTS.md 里的“编辑体验规范”之后，确实做了一定的业务思考。

组件生成结束后，Codex 会列出准备创建的文件清单和改动摘要。我逐一检查后确认落盘，然后直接在项目里运行 lint 和单测，一次通过。原本这个环节最耗时的“接口联调状态处理”，现在由 AI 自动对接写好的 api 方法，我只需要检查它有没有处理失败态。省下来的时间，是我过去最缺的那种整块思考时间。

4.3 列表组件：让生成代码对齐现网风格

第二个组件是最近订单列表。这个页面看起来只是展示数据，但往往是最容易在团队里产生风格偏移的：有人用 Table 默认样式，有人给列加自定义筛选，有人把操作列塞了一排按钮。因为 AGENTS.md 里已经写明“表格列渲染必须使用封装组件 OrderTable 的 render 配置”，Codex 第一次输出就统一用封装组件完成了所有列定义。

我觉得这步才是“AI 替代重复劳动”的关键价值。以前这种页面最大的成本不是“写不出来”，而是“写完要人工对齐团队风格”。当项目规则被固化在 AGENTS.md 中后，生成结果天然带着团队约束，审核成本随之降下来。现在再看那些吐槽“AI 代码风格太乱”的帖子，我第一反应就是：你的项目规则文件写了吗。

4.4 改造代码：不是每次都要从零生成

Codex 的另一大用途是在旧代码基础上做局部改造，这比从零生成更让我受益。比如列表页原有代码的表单查询区用了三个独立的下拉选择框，视觉拥挤，我让它把三个下拉合并成一个搜索面板，并且保留原有表单值联动逻辑。

实现上，Codex 在会话里先定位到对应的SearchForm.tsx，然后追加了一个可展开的“高级搜索”区域，把所有搜索字段收纳进去；原来的默认值、URL 参数同步逻辑被原样保留。这种“外科手术式修改”比生成新代码困难得多，但 Codex 因为能读取相关文件上下文，改完之后的代码阅读起来和团队里资深同事的手笔差不多。

4.5 收尾：编译、Lint、人工复查

千万不要以为 AI 让文件落盘就万事大吉。我每次都会做三件事：跑一次 TypeScript 类型检查、跑一次 lint、最后自己把关键交互点过一遍。TypeScript 检查是为了捕抓它偶尔漏掉的类型导入，lint 是为了对齐团队规则，人工复核则是看数据流和业务逻辑是否成立。

实测中，纯前端组件的首次通过率大约在八成以上，剩下两成多是企业鉴权、权限控制这类全局状态问题。遇到这种情况，我不是让它无脑重试，而是把报错信息复制进会话，让它读报错再说。Codex 处理自己的报错比处理陌生报错更准，因为它看到的是自己生成的代码。这个流程走下来，稳定性和人工写代码已经没有明显差别。

5. 我踩过的坑：报错速查、模型权限和“伪成功”

5.1 常见报错与处理速查表

和 Codex 厮混这段时间，我遇到了不少典型问题，这里按“现象—原因—处理办法”整理成一个速查表，希望能帮你少走点弯路。

这张表看似简单，但每一行背后的教训都是我实打实烧出来的时间换来的。比如“一直在文件里打转”的问题，初期我以为是 AI 变笨了，后来才明白是会话里塞了太多无关代码，通过/compact压缩之后立刻恢复清醒。

5.2 模型权限：账号类型决定能用的武器

关于“模型不可用”这个报错，我想多讲几句。Codex 的可用模型和登录账号类型有关，有的账号能用全套模型，有的账号只允许低配模型。遇到“模型当前不可用”时，不要先去网上搜乱七八糟的绕过方案，最稳的办法是回到官方配置说明里确认账号的权限矩阵。

我在团队里遇到过成员把账号类型搞混，导致同一份配置在他电脑上报错，换台机器就正常。后来统一改用团队级凭证，这个问题才彻底消失。顺带说一句，如果你只是想在 Codex 里接其它服务商的模型，而服务商提供了官方 API 地址和密钥，那么在配置文件的模型字段里改成对应的模型名，也是在文档允许范围内的做法。但如果服务商没有官方集成，就别自己折腾旁门左道。

5.3 “伪成功”：文件生成了，项目却编译不了

有一种失败比报错更隐蔽，我把它叫“伪成功”：Codex 显示任务完成、文件都已生成，但你一运行npm run build就崩了。最常见的原因是类型定义缺失、引入路径错误、或者它用了某个没安装的依赖方法。

我的排查顺序是这样：先看构建报错指向哪个文件，再把报错原样丢给 Codex，让它自己去读相邻文件的导出方式。它看到真实的报错后，通常能立刻修正。这个经验说明一件事：AI 生成的自信不代表正确，必须经过编译器和 lint 的“现实检验”。把校验工具接入自动化流程，比用人眼检查更靠谱。

5.4 会话太长导致上下文失效

用 Codex 写前端组件，一个会话从早用到晚的情况并不少见。但会话越长，它的输出就越容易“走神”，表现为顾此失彼、忘记结构、把已有组件重写一遍。这时别硬撑，Codex 提供了/compact命令，能把前面的对话压缩成一份精简摘要，释放上下文空间，同时保留关键决策点。

我自己的节奏是：每完成一个中等规模组件就/compact一次，需要继续修改时再/resume恢复。这样既不用担心上下文丢失，也能保持较快的响应速度。这个习惯让我在后面几天的开发里明显减少了“它怎么突然变蠢了”的困惑。

6. 让 Codex 成为前端生产力工具的三条经验

第一，项目规则永远比提示词技巧优先。大多数人第一次用 Codex，都在琢磨怎么把提示词写得更花哨，而我踩过一轮之后发现，最省力的投入是先把 AGENTS.md 写好。你项目里那些“约定俗成”的东西，对它来说并不天然成立。把团队规范固化成文字，AI 才能稳定地输出符合预期的代码。

第二，把它当实习生而不是“外挂”来用。实习生写完代码你会检查，会指出问题，会告诉他团队规范在哪里；对 Codex 也应如此。我很少让它一口气生成一个大页面，而是拆成“表单组件、列表组件、弹窗组件”这样的小任务逐个确认。任务拆细之后，每一轮的产出都处于可控范围内，错误率反而更低。

第三，用代码校验工具代替肉眼抽查。TypeScript、ESLint、Prettier 这些本就是你项目里的看门人，Codex 生成的代码同样要被它们审判。把它们跑进 pre-commit 钩子，让任何不合格的生成代码在提交前原形毕露。这一条看起来平淡无奇，但正是很多人在“AI 编程”风潮里容易忽略的底座。

我在实际用 Codex 的这段日子里，最大的体会是它把“从需求到组件”的时间成本拉到了一个很奇怪的水平，以至于我开始重新分配自己的精力：以前把大量时间花在写重复样子上，现在可以腾出手来思考组件边界、交互细节和数据流。对我这种常年和业务需求拉扯的前端来说，这是比“写得更快”更让人开心的事。如果你也正被重复的组件劳动耗着，不妨按这篇文章的路径，花一个下午把 Codex 配好，再写一份属于自己的 AGENTS.md。你会回来感谢自己的。

最后再分享一个小技巧：第一次配置完，别急着处理复杂业务，先让它把项目里的一个老组件按照你的规则重构一遍。这个“试水”过程能最快暴露规则里的漏洞，也能让你在没有业务压力的前提下熟悉确认 diff 的节奏。等这一轮走完，再让它上真实需求，你会明显感受到什么叫顺手。