企业官网建设流程全解析

1. 当"秒级生成"不再是营销话术：前端组件生产的真实瓶颈在哪

前端开发这行干久了，你会发现一个很拧巴的现象：业务方要一个中后台表格页，你心里清楚这东西的结构无非是搜索区、工具栏、表格主体、分页器四块，闭着眼睛都能写出来，但真动手敲，从建文件、写类型定义、接状态管理、调样式变量到处理边界情况，两个小时就没了。这两个小时里，真正需要"思考"的部分可能只占十分钟，剩下全是重复劳动。

Codex 这类 AI 编程工具进入视野之后，很多人第一反应是"让 AI 帮我写组件"。但实际用下来，大部分人的体验是：生成的代码能跑，但没法直接用——命名风格跟项目对不上、状态管理用的是它自己那套、样式写死了 px 值、类型定义缺胳膊少腿。于是你花在"改 AI 代码"上的时间，未必比从零写少多少。这就是"秒级生成"这个说法最尴尬的地方：生成确实快，但落地不快。

我写这篇文章想聊的，不是"Codex 有多神"，而是怎么把它的生成能力真正压进前端组件生产的流水线里，让"秒级"从生成环节延伸到可用环节。核心思路有三条：第一，把项目规范前置成 Codex 能读懂的上下文，而不是生成后再纠正；第二，用组件模板和代码片段把生成结果的"骨架"固定下来，让 AI 只填肉不搭架；第三，建立一套生成后的自动校验链路，把人工 review 从"逐行看"降级成"看差异"。

这套方法适合谁？如果你是中后台系统的前端负责人，团队里天天有人写 CRUD 页面，那这套东西的收益最明显；如果你是独立开发者，接私活时经常要快速搭页面，也能用；如果你只是偶尔写写组件，那可能杀鸡用牛刀了。下面我会把配置、模板、校验、踩坑这几块拆开讲，尽量给到能直接抄的配置和代码。

2. 让 Codex 读懂你的项目：上下文注入的三种粒度

Codex 生成质量差，八成不是模型不行，而是它不知道你的项目长什么样。它默认的"世界观"是一个通用的 React/Vue 项目，用的是最常见的写法。但你的项目可能有自己的目录约定、自己的请求封装、自己的状态管理方案。你不告诉它，它就只能猜，猜错了你就得改。

上下文注入这件事，我试过三种粒度，效果差异很大，值得展开说。

2.1 全局粒度：项目级配置文件

最粗的粒度是在项目根目录放一个 Codex 能识别的配置文件，把项目的技术栈、目录结构、编码规范写进去。这个文件的作用相当于给 AI 一份"项目说明书"，每次生成都会带上。

我自己的配置大概长这样，放在项目根目录的AGENTS.md或者 Codex 约定的配置位置：

# 项目技术栈 - 框架：React 18 + TypeScript 5 - 状态管理：Zustand（禁止使用 Redux） - 请求库：项目自研的 request 封装，位于 src/utils/request.ts - UI 库：Ant Design 5，禁止引入其他组件库 - 样式方案：CSS Modules + Less 变量，变量定义在 src/styles/variables.less # 目录约定 - 页面组件：src/pages/[模块名]/index.tsx - 通用组件：src/components/[组件名]/index.tsx - 类型定义：就近定义，不单独建 types 目录 - API 定义：src/services/[模块名].ts # 编码规范 - 组件一律用函数式 + hooks - 禁止使用 any，未知类型用 unknown - 事件处理函数命名：handleXxx - 布尔变量命名：isXxx / hasXxx / shouldXxx - 样式类名用 camelCase，通过 styles.xxx 引用

这份配置看起来啰嗦，但它解决了一个关键问题：Codex 生成代码时不再"自由发挥"。比如它原本可能给你生成import { useDispatch } from 'react-redux'，现在它会知道这个项目用 Zustand，直接生成useXxxStore的调用。

注意：配置文件里的"禁止"条款比"推荐"条款更有效。AI 对否定指令的遵循度，实测下来比正面描述高不少。所以与其写"推荐用 Zustand"，不如写"禁止使用 Redux，状态管理统一用 Zustand"。

2.2 模块粒度：按业务域拆分上下文

全局配置解决的是"通用规范"，但不同业务模块有自己的特殊性。比如订单模块的表格列特别多，需要虚拟滚动；用户模块的表单校验规则特别复杂，需要抽成独立的 schema。这些信息如果全塞进全局配置，文件会臃肿到 AI 读不完（上下文有长度限制），而且大部分生成场景用不上。

我的做法是在每个业务模块目录下放一个轻量的_context.md，只写这个模块特有的约定：

# 订单模块约定 - 表格统一使用 VirtualTable 组件（src/components/VirtualTable） - 金额字段一律用分存储，展示时除以 100 - 订单状态枚举定义在 src/constants/orderStatus.ts - 所有列表接口返回结构：{ list: T[], total: number, page: number }

生成订单相关组件时，把这个文件和全局配置一起喂给 Codex，生成结果的贴合度会明显提升。这里有个实操细节：模块级上下文不要超过 200 行，超了就说明这个模块该拆了，或者该把部分内容下沉到全局配置。

2.3 任务粒度：单次生成时的即时指令

最细的粒度是你在每次让 Codex 生成时，临时补充的指令。这部分最灵活，也最容易被忽略。很多人用 Codex 就是丢一句"帮我写个用户列表页"，然后抱怨生成得不好。正确的做法是把这次任务的约束条件说清楚：

生成一个用户列表页，要求： 1. 搜索区包含：用户名（输入框）、状态（下拉，选项来自 UserStatus 枚举）、注册时间范围（RangePicker） 2. 表格列：用户名、手机号、状态（用 Tag 展示）、注册时间、操作（编辑/禁用） 3. 分页用 Ant Design 的 Table 自带分页，每页 20 条 4. 数据请求走 src/services/user.ts 里的 getUserList 5. 状态管理用 Zustand，store 定义在同目录的 store.ts 6. 编辑操作跳转到 /user/edit/:id，禁用操作弹确认框后调接口

这种"清单式"指令的好处是，Codex 生成的代码结构基本就是你要的，你只需要微调细节。我对比过，同样一个列表页，模糊指令生成后要改 40 分钟，清单式指令生成后改 10 分钟就完事。

三种粒度的关系是叠加的：全局配置打底，模块上下文补充，任务指令收口。三层都到位，Codex 生成的东西才真正"像这个项目里的人写的"。

3. 组件模板：把"骨架"固定下来，让 AI 只填肉

上下文注入解决的是"AI 知道什么"，但还有一个问题：即使 AI 知道规范，它每次生成的代码结构还是会有波动。今天生成的列表页把请求逻辑写在 useEffect 里，明天可能写在自定义 hook 里。这种波动对个人开发者无所谓，但对团队协作是灾难——review 成本高，维护时找不到规律。

解法是组件模板。核心思想是：把组件的"骨架"（文件结构、导入、类型定义、函数签名、样式引用）固定成模板，让 Codex 只填充"肉"（具体的业务逻辑、字段、交互）。

3.1 列表页模板的设计

我以中后台最常见的列表页为例。一个标准的列表页模板包含这些部分：

// 模板骨架（简化版） import React, { useEffect } from 'react'; import { Table, Form, Input, Button, Space } from 'antd'; import { useXxxStore } from './store'; import styles from './index.module.less'; // 类型定义区 interface XxxItem { // TODO: 字段由 Codex 填充 } interface SearchParams { // TODO: 搜索字段由 Codex 填充 } const XxxList: React.FC = () => { const { list, total, loading, fetchList } = useXxxStore(); const [form] = Form.useForm(); // 搜索区渲染 const renderSearchForm = () => { // TODO: 由 Codex 根据字段生成 }; // 表格列定义 const columns = [ // TODO: 由 Codex 根据字段生成 ]; useEffect(() => { fetchList({ page: 1, pageSize: 20 }); }, []); return ( <div className={styles.container}> <div className={styles.searchArea}>{renderSearchForm()}</div> <Table columns={columns} dataSource={list} loading={loading} pagination={{ total, pageSize: 20 }} rowKey="id" /> </div> ); }; export default XxxList;

这个骨架的价值在于：它把"结构决策"提前做完了。Codex 拿到这个骨架，只需要做三件事——填充XxxItem的字段、填充SearchParams的字段、根据字段生成搜索表单和表格列。它不需要决定"用不用自定义 hook""请求放哪里""分页怎么处理"，这些都已经定死了。

实测下来，用模板 + Codex 填充的方式，生成一个列表页的时间从"从零生成 + 大改"的 30 分钟，降到"填充 + 微调"的 8 分钟左右。而且生成结果的风格高度一致，团队里谁生成的都一样。

3.2 表单页模板的关键差异

表单页的模板跟列表页不一样，核心差异在"校验逻辑"和"布局"。表单页最容易出问题的地方是校验规则——AI 经常生成一堆重复的校验代码，或者用错校验时机。

我的表单页模板会把校验部分单独抽出来：

// 校验规则区（Codex 填充） const rules = { // TODO: 字段校验规则 }; // 布局配置（固定） const formLayout = { labelCol: { span: 6 }, wrapperCol: { span: 18 }, };

然后在指令里明确告诉 Codex："校验规则统一写在 rules 对象里，不要在 Form.Item 里内联写 rules"。这样生成出来的代码，校验逻辑集中在一处，改起来方便，也方便后续抽成共享 schema。

3.3 模板的维护成本与收益平衡

模板这东西有个坑：维护成本会随项目演进而上升。如果项目升级了 Ant Design 版本，或者换了状态管理方案，所有模板都得改。所以模板不能太多，也不能太细。

我的经验是：只给"高频且结构稳定"的组件建模板。中后台系统里，列表页、表单页、详情页这三类占了 70% 以上的开发量，且结构高度稳定，值得建模板。至于图表页、看板页这种结构差异大的，建模板反而束缚手脚，不如直接用上下文注入 + 任务指令的方式。

另外，模板要放在版本控制里，跟项目代码一起演进。我见过有团队把模板放在某个人的本地目录，结果人一走模板就失传了。模板是团队资产，不是个人工具。

4. 生成之后的自动校验：把 review 从"逐行看"变成"看差异"

Codex 生成完代码，直接提交肯定不行。但人工逐行 review 又太慢，失去了"秒级"的意义。我的做法是搭一条自动校验链路，把明显的问题挡在人工 review 之前。

4.1 静态检查：ESLint + TypeScript 的第一道网

生成完代码，第一件事是跑 lint 和类型检查。这一步能挡掉大概 60% 的低级问题：未使用的导入、类型不匹配、命名不规范、缺少依赖项。

关键是要给 Codex 生成的代码配一套"严格模式"的检查规则。我通常会在项目里单独配一个针对生成代码的 ESLint 配置，比常规配置更严：

{ "rules": { "no-unused-vars": "error", "no-console": "error", "@typescript-eslint/no-explicit-any": "error", "@typescript-eslint/explicit-function-return-type": "warn", "react-hooks/exhaustive-deps": "error" } }

react-hooks/exhaustive-deps这条特别重要。Codex 生成 useEffect 时，经常漏依赖项，导致闭包问题。这条规则能直接标出来。

4.2 结构校验：用脚本检查生成结果是否符合模板约定

静态检查过了，不代表结构对。比如 Codex 可能把请求逻辑写在了组件里而不是 store 里，或者把样式写成了内联 style 而不是 CSS Modules。这些"结构性问题"ESLint 查不出来，得自己写脚本查。

我写过一个简单的 Node 脚本，检查生成文件里是否包含某些"禁止模式"：

const fs = require('fs'); const path = require('path'); const forbiddenPatterns = [ { pattern: /style=\{\{/, message: '禁止使用内联样式，请用 CSS Modules' }, { pattern: /from 'react-redux'/, message: '禁止使用 Redux，请用 Zustand' }, { pattern: /axios\./, message: '禁止直接使用 axios，请用项目封装的 request' }, { pattern: /: any\b/, message: '禁止使用 any 类型' }, ]; function checkFile(filePath) { const content = fs.readFileSync(filePath, 'utf-8'); const issues = []; forbiddenPatterns.forEach(({ pattern, message }) => { if (pattern.test(content)) { issues.push(message); } }); return issues; }

这个脚本挂在 git pre-commit hook 里，生成代码提交前自动跑。有问题直接打回，让 Codex 重新生成或者手动修。

4.3 人工 review 的聚焦点：只看三件事

自动校验过了之后，人工 review 就不需要逐行了。我通常只看三件事：

第一，业务逻辑对不对。比如搜索条件是否正确映射到了接口参数，状态枚举的展示文案是否准确。这部分 AI 猜不准，必须人看。

第二，边界情况处理了没有。空数据、加载中、请求失败这三种状态，AI 经常漏掉。我会重点看有没有 loading 态、有没有空状态提示、有没有错误处理。

第三，有没有"看起来对但实际有坑"的代码。比如 useEffect 的依赖项虽然通过了 lint，但逻辑上是否真的需要重新请求；比如分页切换时是否重置了搜索条件。这些是 AI 的盲区，需要人的经验判断。

这套流程跑下来，一个列表页从生成到可提交，大概 15 分钟。相比从零写的 2 小时，效率提升是实打实的。而且因为结构统一，后续维护成本也低。

5. 那些让我踩过坑的细节：命名、类型与状态管理

前面讲的都是"方法论"，这一节聊点具体的坑。这些坑不踩一遍很难意识到，但踩过之后就成了肌肉记忆。

5.1 命名冲突：AI 的命名习惯跟项目对不上

Codex 生成组件名时，倾向于用很通用的名字，比如List、Form、Table。这些名字在单文件里没问题，但一旦项目里多个模块都有同名组件，导入时就乱了。

我的解法是在任务指令里强制要求命名前缀。比如生成订单列表页，就明确说"组件名用 OrderList，store 用 useOrderListStore，样式类名用 orderList 前缀"。这样生成出来的东西不会跟其他模块撞车。

还有一个隐蔽的坑：AI 生成的变量名有时会跟项目里的全局变量或工具函数重名。比如它可能生成一个formatDate函数，而项目里src/utils/date.ts已经导出了同名函数。这种冲突 ESLint 不一定能查出来（取决于配置），但运行时会出问题。我的做法是在全局配置里列出项目常用的工具函数名，让 AI 避开。

5.2 类型定义：AI 倾向于"够用就行"

Codex 生成 TypeScript 类型时，有个明显的倾向：能省则省。比如接口返回的嵌套对象，它可能只定义一层，深层用any或者干脆不定义。这在开发时没问题，但后续改字段时就没有类型保护了。

我的应对方式是在任务指令里明确要求"所有接口返回类型必须完整定义，嵌套对象也要定义"。同时在全局配置里写死"禁止使用 any，未知类型用 unknown"。两条一起上，生成结果的类型完整度会好很多。

另外，AI 生成的类型定义经常跟后端实际返回对不上。这个没办法靠配置解决，只能靠"生成后拿真实接口数据跑一遍"。我通常会让 Codex 生成完之后，自己手动调一次接口，把返回的 JSON 贴给 Codex，让它根据真实数据修正类型定义。这一步多花两分钟，但能省掉后续一堆类型报错。

5.3 状态管理：Zustand 的 store 生成有讲究

用 Zustand 的项目里，Codex 生成 store 时经常犯一个错：把所有状态和操作都塞进一个 store，不管它们是否相关。比如一个列表页的 store 里，既有列表数据，又有搜索表单的值，又有弹窗的开关状态。这导致 store 越来越臃肿，复用性差。

我的做法是在模板里把 store 的结构固定下来，分成三块：数据区（list、total、loading）、查询区（searchParams）、操作区（fetchList、resetSearch）。然后告诉 Codex"按这个结构填充，不要新增顶层字段"。这样生成出来的 store 结构统一，后续要抽公共逻辑也方便。

还有一个细节：Zustand 的set和get用法，AI 有时会写错。比如在异步 action 里获取最新状态，应该用get()而不是闭包里的旧值。这个坑我在全局配置里专门写了一条提示，让 AI 注意。

6. 从"能用"到"好用"：把生成流程接进日常开发

前面讲的都是单点技术，这一节聊怎么把它们串成一条流水线，真正接进日常开发。

6.1 目录结构与脚本组织

我的项目里会有一个.codex目录（名字随意，看工具约定），里面放这些东西：

.codex/ ├── templates/ # 组件模板 │ ├── list-page/ │ ├── form-page/ │ └── detail-page/ ├── contexts/ # 模块级上下文 │ ├── order.md │ └── user.md ├── scripts/ # 校验脚本 │ ├── check-structure.js │ └── check-naming.js └── config.md # 全局配置

生成组件时，根据组件类型选对应模板，根据业务模块选对应上下文，拼成完整的 prompt 喂给 Codex。生成完跑校验脚本，过了就进人工 review。

6.2 一个完整的生成流程示例

假设要生成一个"优惠券列表页"，完整流程是这样的：

第一步，确定组件类型是列表页，从templates/list-page取模板骨架。

第二步，确定业务模块是营销模块，从contexts/marketing.md取模块上下文（假设有这个文件）。

第三步，拼 prompt：全局配置 + 模块上下文 + 模板骨架 + 任务指令。任务指令里写清楚字段、接口、交互。

第四步，Codex 生成，输出到src/pages/marketing/coupon/index.tsx和同目录的store.ts。

第五步，跑check-structure.js和check-naming.js，有问题打回重生成。

第六步，跑 ESLint 和 tsc，有问题手动修或打回。

第七步，人工 review，重点看业务逻辑、边界情况、隐蔽坑。

第八步，本地跑起来，调真实接口验证，修正类型定义。

这套流程走下来，一个中等复杂度的列表页，从开始到可提交，大概 20 分钟。其中 Codex 生成只占 1 分钟，剩下都是校验和修正。所以"秒级生成"的真正含义不是"1 分钟搞定一个页面"，而是"把重复劳动压缩到 1 分钟，把人的时间留给真正需要判断的部分"。

6.3 团队协作时的注意事项

如果这套东西要在团队里推广，有几个点得提前想清楚。

第一，模板和配置要有人维护。不能建完就不管了，项目演进时模板得跟着改。我建议指定一个人负责，或者轮流负责，每次项目有大的技术决策变更时同步更新。

第二，生成代码的 review 标准要统一。不能这个人 review 严，那个人 review 松。我通常会把 review 要点写成 checklist，大家照着看。

第三，要允许"不用这套流程"。有些组件结构特殊，硬套模板反而别扭。这种情况就直接手写，不要为了用工具而用工具。

第四，生成代码的注释要保留。Codex 生成的代码有时会带一些解释性注释，这些注释对后续维护有帮助，不要为了"代码干净"全删掉。

7. 关于 Codex 配置与常见问题的实操补充

聊到这儿，顺便把一些配置层面的实操细节补上。这些内容网上说法不一，我按自己实测有效的来写。

7.1 配置文件的位置与优先级

Codex 的配置一般分几层：全局配置（用户级）、项目配置、任务级指令。优先级是任务级 > 项目级 > 全局级。所以如果你在项目里配了规范，但某次任务想临时突破，直接在任务指令里说明就行，不用改项目配置。

项目级配置我建议放在版本控制里，跟代码一起走。这样团队里每个人拉下来的配置都一样，生成结果也一致。全局配置放个人目录，放一些个人偏好，比如"生成代码时注释用中文"这种。

7.2 模型选择与生成质量的取舍

Codex 支持不同的模型，生成质量跟模型能力直接相关。我的经验是：结构复杂、逻辑绕的组件，用能力强的模型；结构简单、纯 CRUD 的组件，用快模型就行，省时间。

但有个反直觉的点：不是模型越强生成越好。强模型有时会"过度设计"，给你生成一堆你用不上的抽象层。快模型反而更"老实"，按你说的做。所以选模型要看任务类型，不能一刀切。

7.3 生成失败或结果异常时的排查思路

Codex 生成结果异常，通常有几个原因。一是上下文太长，超出了模型的处理能力，导致它"忘了"前面的指令。这种情况要精简上下文，把不相关的模块配置去掉。二是指令有歧义，AI 理解偏了。这种情况要把指令拆细，一条一条说清楚。三是模板本身有问题，比如模板里的类型定义跟实际不符，AI 照着错的模板生成，结果自然错。

排查的时候，我通常先把任务指令简化到最小，看生成结果是否正常。如果正常，再逐步加回上下文，定位是哪部分导致的异常。这个方法虽然笨，但很有效。

7.4 关于中文支持与界面语言

Codex 对中文指令的理解没问题，但生成代码里的注释和文案，默认可能是英文。如果你需要中文注释，在全局配置里明确写"代码注释用中文，UI 文案用中文"。实测这条指令的遵循度挺高。

界面语言这块，不同版本的 Codex 设置方式不一样，有的在设置里能直接切，有的需要改配置文件。我建议直接查对应版本的官方文档，别照着旧教程改，容易改出问题。

8. 写在最后：工具的价值在于"用对地方"

这套东西我用了大半年，最大的体会是：Codex 这类工具的价值，不在于它能"替你写代码"，而在于它能"替你写那些你不想写的代码"。中后台系统里大量的 CRUD 页面，结构重复、逻辑简单、但量大，这才是 AI 生成的最佳战场。至于那些真正需要架构设计、需要业务判断的部分，AI 目前还替代不了，也不该指望它替代。

另一个体会是：配置和模板的投入是值得的，但要控制度。我见过有人花两周搭一套完美的生成流水线，结果项目里就三个页面，纯属过度工程。也见过有人完全不做配置，每次生成都靠"运气"，结果改代码的时间比写代码还长。合理的度是：项目里高频重复的组件类型建模板，通用的规范写进配置，剩下的靠任务指令灵活处理。

最后分享一个小技巧：每次 Codex 生成出让你满意的代码，别急着提交，先把它"回填"到模板里。比如你发现某种搜索表单的布局特别好用，就把它抽象成模板的一部分。这样用久了，你的模板会越来越贴合项目，生成质量也会越来越高。工具是死的，用法是活的，慢慢养，才能养出一套真正顺手的流程。