企业官网建设流程全解析

1. 从零理解 Codex 的四层配置体系

很多人第一次接触 Codex 的时候，注意力全在"怎么让它写代码"上，结果用了两周还是停留在"对话式补全"的阶段。真正把 Codex 用出生产力的那批人，关注点其实在另一层：Rules、AGENTS、Prompts、MCP 这四个东西怎么协同。它们分别对应"约束边界""角色定义""任务指令""外部能力"四个维度，缺一个都会让 Codex 的表现大打折扣。

我先把这四个概念用一句话说清楚，方便你建立整体认知：

• Rules：告诉 Codex"什么不能做、什么必须遵守"，是硬性约束，类似团队里的代码规范文档。
• AGENTS：定义"谁来做、以什么身份做"，是角色与协作单元的抽象，决定 Codex 以什么视角处理任务。
• Prompts：描述"这次要做什么、做到什么程度"，是具体任务的指令层。
• MCP：解决"能调用什么外部工具、能访问什么数据"，是能力扩展层。

这四层不是并列关系，而是从稳定到易变、从全局到局部的递进结构。Rules 和 AGENTS 相对稳定，一次配置长期复用；Prompts 每次任务都在变；MCP 则是按需挂载的能力插件。理解这个层次关系，是后面所有实操的基础。

提示：如果你现在只用了 Prompts 一层，那 Codex 对你来说就是个"高级补全工具"；把另外三层补上，它才会变成"能独立干活的协作单元"。

1.1 为什么单靠 Prompts 撑不起复杂项目

我见过太多人把全部精力花在"怎么把提示词写得更长更细"上，结果项目一复杂就崩。原因很简单：Prompts 是易失的。你这次写了一段很完美的指令，下次开新会话就没了，得重新写。而且当项目里有十几个模块、几十个文件时，你不可能在每次对话里把所有约束都复述一遍。

Rules 解决的就是这个问题。它把"这个项目里不允许用 any 类型""所有 API 调用必须走统一封装""提交前必须跑 lint"这类约束固化下来，Codex 每次工作都会自动加载。这就好比你招了个新同事，与其每次叮嘱他"记得写注释"，不如直接给他一份团队规范文档。

AGENTS 解决的是另一个问题：视角切换。同一个任务，让"前端工程师"视角和"测试工程师"视角来处理，产出完全不同。AGENTS 让你可以预定义多个角色，需要时直接切换，而不用在 Prompt 里反复描述"你现在是一个资深后端工程师，你关注性能和并发安全……"。

MCP 则是把 Codex 从"只能看代码"扩展到"能查数据库、能读设计稿、能调接口"。没有 MCP，Codex 就是个闭门造车的代码生成器；有了 MCP，它才能真正接入你的工作流。

1.2 四层体系的加载顺序与优先级

这里有个很多人踩过的坑：四层配置冲突时谁说了算。根据我的实测，Codex 的处理逻辑大致是这样的优先级（从高到低）：

也就是说，如果 Rules 里写了"禁止使用某个库"，但你在 Prompts 里明确要求用它，Codex 会倾向于遵守 Rules 并提示你冲突。这个设计是合理的——约束应该比指令更稳定。理解这一点，你在排查"为什么 Codex 不听话"的时候就有方向了：先看是不是 Rules 拦住了，再看 AGENTS 的角色是不是不对，最后才怀疑 Prompts 写得不好。

2. Rules 的写法：从"能跑"到"跑得稳"

Rules 是四层里最容易被忽视、但收益最直接的一层。我刚开始用的时候也觉得"写规范文档太麻烦"，直到有一次 Codex 在一个金融计算模块里用了浮点数做金额运算，我才意识到 Rules 不是可选项。

2.1 Rules 文件的组织方式

Rules 通常以配置文件的形式存在，放在项目根目录或专门的配置目录下。常见的组织方式有两种：

单文件模式：所有规则写在一个文件里，适合中小项目。优点是查找方便，缺点是文件会越来越长。

分目录模式：按规则类型拆成多个文件，比如rules/security.md、rules/style.md、rules/testing.md。适合大型项目，每类规则独立维护。

我个人的建议是：项目初期用单文件，超过 200 行就拆分。因为规则文件一旦太长，Codex 加载时可能只读取前面部分，后面的规则形同虚设。这个坑我踩过——写了 500 多行规则，结果发现后半部分根本没生效。

2.2 什么样的规则真正有效

不是所有规则都值得写。我总结了一个判断标准：这条规则是否能被机器明确判定。

有效的规则长这样：

• "所有金额计算必须使用 Decimal 类型，禁止用 float"
• "API 响应必须包含 error 字段，类型为 string 或 null"
• "禁止在循环体内发起网络请求"

无效或低效的规则长这样：

• "代码要写得优雅"（无法判定）
• "注意性能"（太模糊）
• "尽量复用代码"（没有明确边界）

写 Rules 的时候，我习惯用"禁止/必须 + 具体对象 + 可验证条件"的句式。这样 Codex 在执行时能明确知道边界在哪，你事后 review 也有据可依。

2.3 Rules 校验规则的实际运作

Rules 写完之后，怎么知道它真的生效了？这里有个实用技巧：故意写一段违反规则的代码，看 Codex 会不会拦。

比如你在 Rules 里写了"禁止使用 var"，然后让 Codex 写一段用 var 的代码。如果它照做了，说明规则没加载；如果它提示你"根据项目规则，这里应该用 let/const"，说明规则生效了。

这个验证步骤非常重要，因为 Rules 的加载路径、文件命名、格式都可能出问题。我遇到过规则文件放在错误目录导致完全不生效的情况，排查了半天才发现是路径问题。

注意：Rules 不是越多越好。规则太多会让 Codex 变得畏手畏脚，甚至频繁报冲突。我的经验是控制在 30 条以内，只保留真正重要的约束。

3. AGENTS：把 Codex 从工具变成协作单元

如果说 Rules 是"规矩"，那 AGENTS 就是"角色"。这一层是很多人完全没意识到的，但它是 Codex 从"补全工具"进化到"协作单元"的关键。

3.1 AGENTS 到底是什么

AGENTS 可以理解为一组预定义的角色配置。每个 AGENT 包含：角色名称、职责描述、关注重点、可用工具范围、输出格式偏好。当你需要 Codex 以某种特定视角工作时，直接调用对应的 AGENT，而不用在 Prompt 里重新描述一遍。

举个例子，一个典型项目里可能有这几个 AGENT：

• 架构师 Agent：关注模块划分、依赖关系、扩展性，输出偏向设计文档。
• 实现 Agent：关注代码质量、边界处理、性能，输出可直接运行的代码。
• 审查 Agent：关注潜在 bug、安全隐患、规范符合度，输出问题清单。
• 测试 Agent：关注覆盖度、边界用例、异常路径，输出测试代码。

这四个 Agent 处理同一个需求，产出完全不同。以前你要在 Prompt 里写一大段"你现在是一个资深架构师，你关注……"，现在直接切换 Agent 就行。

3.2 定义 AGENT 的关键要素

一个能用的 AGENT 定义，至少要包含这几个部分：

角色定位：一句话说清楚这个 Agent 是谁、负责什么。比如"你是一个专注于数据一致性的后端工程师"。

关注维度：列出这个角色最在意的几个点。比如"并发安全、事务边界、幂等性、错误恢复"。

行为约束：这个角色不该做什么。比如"审查 Agent 只输出问题，不直接改代码"。

输出格式：期望的产出结构。比如"按严重程度分级，每条包含位置、问题、建议"。

我实测下来，关注维度和行为约束是最影响效果的两项。关注维度决定了 Codex 会往哪个方向深挖，行为约束决定了它不会越界。

3.3 多 Agent 协作的实战模式

单个 Agent 已经很有用，但真正的威力在于多 Agent 协作。我常用的一个模式是"实现-审查-修复"三段式：

1. 用实现 Agent完成功能代码。
2. 切换到审查 Agent，让它挑毛病。
3. 回到实现 Agent，带着审查意见修复。

这个流程比"让一个 Agent 从头做到尾"质量高很多。原因是不同角色的关注点天然冲突——实现 Agent 想的是"怎么把功能做出来"，审查 Agent 想的是"哪里会出问题"。这种对抗性反而能暴露更多隐患。

提示：多 Agent 协作时，记得把上一阶段的产出作为下一阶段的输入。否则审查 Agent 不知道实现 Agent 写了什么，就无从审起。

4. Prompts 的进阶：从"描述需求"到"控制过程"

Prompts 是大家最熟悉的一层，但熟悉不等于用得好。大部分人写 Prompt 停留在"描述需求"阶段，而真正高效的用法是"控制过程"。

4.1 结构化 Prompt 的四个组成部分

我习惯把每个 Prompt 拆成四块：

背景：当前项目状态、相关文件、已有约束。让 Codex 知道"现在是什么情况"。

目标：这次要达成什么。要具体到可验证，比如"实现一个支持分页的用户列表接口"而不是"做个用户列表"。

约束：本次任务的特殊要求。注意这里和 Rules 的区别——Rules 是长期约束，这里是本次特有的。

验收标准：怎么算完成。比如"接口能返回正确分页数据，边界情况有处理，有对应测试"。

这四块写全，Codex 的产出质量会明显提升。尤其是验收标准这一块，很多人不写，结果 Codex 交出来的东西"能跑但不对味"。

4.2 让 Prompt 可控的关键技巧

分步执行：复杂任务不要一次性丢给 Codex，拆成几步，每步确认后再继续。这样出错时容易定位，也方便中途调整方向。

显式要求思考过程：让 Codex 先说明"打算怎么做"，你确认后再让它动手。这一步能拦下很多方向性错误。

提供反例：告诉 Codex"不要写成什么样"，有时候比正面描述更有效。比如"不要用嵌套三元表达式，不要在一个函数里处理超过三个职责"。

限定输出范围：明确说"只改这个文件""只输出 diff""不要动其他模块"。防止 Codex 顺手改了不该改的地方。

4.3 Prompt 与 Rules 的边界划分

这里有个常见困惑：某条要求到底该写进 Rules 还是 Prompt？

我的判断标准是：这条要求是否跨任务复用。如果是，写进 Rules；如果只针对本次任务，写进 Prompt。

比如"所有函数必须有类型标注"——这是跨任务的，进 Rules。"这次先不写测试，专注实现"——这是本次特有的，进 Prompt。

搞混这个边界会导致两个问题：Rules 里塞了太多一次性要求，变得臃肿；或者 Prompt 里反复写同样的约束，浪费时间。

5. MCP：给 Codex 接上外部世界

MCP 是这四层里最新、也最容易被神化的一层。很多人一上来就想接一堆 MCP 服务，结果配置半天跑不起来。我的建议是：先想清楚你要解决什么问题，再决定接什么 MCP。

5.1 MCP 解决的核心问题

Codex 默认只能看到你给它的代码和文本。但真实工作里，信息散落在各处：数据库里的表结构、设计稿里的组件、接口文档里的字段定义、本地文件里的配置。MCP 就是把这些外部信息源接进来的通道。

一个典型的 MCP 使用场景：你要写一个查询接口，但需要先知道数据库表结构。没有 MCP，你得手动把表结构贴进 Prompt；有了 MCP，Codex 可以直接查询数据库元信息，自己搞清楚字段。

5.2 MCP 的 Host 与 Server 架构

理解 MCP 要先理解它的架构。MCP 采用 Host-Server 模式：

• MCP Host：发起请求的一方，也就是 Codex 本身。
• MCP Server：提供能力的一方，比如数据库 MCP Server、文件系统 MCP Server、设计工具 MCP Server。

Codex 作为 Host，通过标准协议向各个 Server 请求能力。每个 Server 暴露一组工具（tools），Codex 根据需要调用。

这个架构的好处是解耦：你想加新能力，只要挂一个新的 Server，不用改 Codex 本身。

5.3 配置 MCP 的实操要点

配置 MCP 通常涉及几个步骤：

1. 确认 Server 可用：先单独测试 MCP Server 能不能跑起来，别一上来就集成到 Codex 里。
2. 配置连接信息：把 Server 的地址、认证信息填到 Codex 的配置里。
3. 验证工具列表：配置完成后，确认 Codex 能列出该 Server 提供的工具。
4. 小范围试用：先用一个简单任务测试，确认调用链路通畅。

我踩过的最大的坑是认证信息配置错误，导致 Codex 一直报连接失败，但错误信息很模糊，排查了很久。后来养成习惯：配置完先单独验证 Server，再集成。

注意：MCP Server 不是越多越好。每挂一个 Server 都会增加启动开销和潜在故障点。只挂当前任务真正需要的。

5.4 MCP 与 RAG 的区别

经常有人问 MCP 和 RAG 有什么区别。简单说：

• RAG解决的是"从大量文档里找相关信息"，本质是检索增强。
• MCP解决的是"让模型能主动调用外部能力"，本质是工具调用。

两者可以配合：用 RAG 找到相关文档，用 MCP 调用外部工具处理。但它们不是一回事，别混为一谈。

6. 四层协同的实战案例

光讲概念没用，我用一个真实场景把四层串起来。

6.1 场景：给现有项目加一个数据导出功能

假设你有一个 Web 项目，现在要加一个"导出用户数据为 CSV"的功能。看看四层怎么配合。

Rules 层（项目已有，自动生效）：

• 所有文件操作必须处理异常
• 禁止在请求处理函数里做耗时操作
• 新增功能必须有对应测试

AGENTS 层（选择实现 Agent）：

• 角色：后端实现工程师
• 关注：边界处理、性能、可测试性

Prompts 层（本次任务）：

• 背景：项目使用某 Web 框架，已有用户模型
• 目标：实现导出接口，支持按条件筛选
• 约束：大数据量要分批处理，不能一次性加载
• 验收：接口可用，有测试，边界情况有处理

MCP 层（挂载数据库 MCP）：

• 让 Codex 能查询用户表结构，确认字段

四层齐备，Codex 的产出质量会明显高于只给一个 Prompt。

6.2 排查"Codex 不听话"的完整链路

当你发现 Codex 的行为不符合预期时，按这个顺序排查：

第一步：看 Rules 是否拦截。检查项目 Rules 里有没有和当前需求冲突的条款。这是最常见的原因。

第二步：看 AGENTS 角色是否匹配。如果你用的是审查 Agent，它当然不会直接改代码。确认当前激活的是哪个 Agent。

第三步：看 Prompts 是否清晰。需求描述是否具体、验收标准是否明确、约束是否写全。

第四步：看 MCP 是否正常。如果任务依赖外部数据，确认 MCP Server 连接正常、工具可调用。

第五步：看上下文是否超限。长会话可能导致早期信息被截断，必要时开新会话。

这个排查顺序是我从多次踩坑中总结的，能覆盖 90% 以上的"不听话"情况。

6.3 常见配置冲突与解决

7. 我踩过的坑与经验总结

最后分享几个只有实际用过才会知道的细节。

Rules 的加载是有顺序的。如果多条规则冲突，后面的可能覆盖前面的。所以把最重要的规则放在前面。

AGENTS 切换不会清空上下文。切换 Agent 后，之前的对话历史还在。这既是好事也是坏事——好处是信息连续，坏处是可能带入上一个角色的思维惯性。必要时开新会话。

Prompts 里的否定句要慎用。Codex 对"不要做 X"的理解不如"要做 Y"准确。能正面描述就正面描述。

MCP 的调用是有开销的。每次调用外部工具都要走一轮网络往返，频繁调用会拖慢整体速度。批量操作比逐条调用高效。

四层配置要版本化管理。Rules、AGENTS 这些配置文件应该进版本控制，跟着项目一起演进。我见过有人把配置放在本地不提交，换台机器就全丢了。

定期清理失效规则。项目演进过程中，有些 Rules 会过时。定期 review，删掉不再适用的，保持配置精简。

这套四层体系我用了大半年，最大的感受是：前期配置的投入，会在后期成倍收回。刚开始花两小时写 Rules 和 AGENTS，后面每个任务都能省下反复解释的时间。如果你还在只用 Prompts 的阶段，建议从 Rules 开始补，这是投入产出比最高的一层。