如何让 Codex 帮你做上线前检查？完整清单与执行指令

Codex 上线前检查的核心，不是让 Codex 随便帮你“看看项目有没有问题”，而是把上线前需要确认的事项整理成一套可执行任务，让 Codex 按照清单逐项检查、验证并输出风险报告。

Codex 是 OpenAI 面向软件开发的 coding agent，官方文档说明它可以帮助写代码、理解代码库、审查代码、调试问题和自动化开发任务。

这意味着，Codex 很适合承担上线前的工程检查工作，例如：

• 检查构建是否能通过
• 检查 TypeScript / ESLint 问题
• 检查页面路由和核心功能
• 检查 SEO 基础配置
• 检查图片、alt、meta、标题
• 检查响应式和可访问性
• 输出上线风险与修复优先级

但要注意：Codex 不应该替代最终上线负责人。它适合作为上线前的自动化检查助手，而不是唯一审核者。

如果你的团队经常做网站、SaaS、工具站或内容站，可以把「上线前检查」保存到达灵感项目里，结合 AGENTS.md、Skills 和项目规则长期复用。

为什么上线前检查适合交给 Codex？

网站上线前最容易出问题的地方，通常不是某一个大功能，而是大量细节：

• 某个页面标题没写
• 移动端布局溢出
• 表单没有错误提示
• 图片没有 alt
• 页面存在英文占位文案
• 构建命令失败
• 404 页面没处理
• 环境变量缺失
• 某些按钮没有点击状态
• meta description 缺失或重复

这些问题人工检查很耗时，但又不能不查。

Codex CLI 官方文档说明，Codex 可以在终端中读取、修改并运行所选目录中的代码，也可以检查仓库、编辑文件和运行命令。

因此，上线前检查适合交给 Codex 做第一轮排查，再由人进行最终确认。

Codex 上线前检查应该检查哪些内容？

最实用的判断是：

可以通过代码、配置、页面结构和命令验证的问题，适合交给 Codex；涉及商业判断、审美判断和真实用户行为的问题，需要人工最终确认。

让 Codex 做上线前检查前，需要准备什么？

1. 项目源码

Codex 更适合在真实项目中工作，而不是只看一张截图。

建议提供：

• 项目目录
• package.json
• README
• 主要页面
• 组件目录
• 配置文件
• 环境变量说明
• AGENTS.md

2. 上线范围

不要只写“检查整个项目”。

要写清楚：

• 这次准备上线哪些页面
• 是否包含移动端
• 是否包含后台
• 是否包含登录注册
• 是否包含支付、表单、搜索、筛选等关键功能

3. 验证命令

例如：

npm run lint
npm run typecheck
npm run build
npm run test

如果你不确定项目有哪些命令，可以让 Codex 先读取 package.json。

4. 禁止事项

上线前检查最怕 AI 乱改。

建议明确写：

• 不新增功能
• 不大改 UI
• 不修改业务逻辑
• 不新增依赖
• 不删除页面
• 不修改数据库结构
• 不修改接口字段

5. 输出格式

上线检查结果必须能被团队执行。

建议输出：

• 是否建议上线
• 阻塞上线问题
• 上线前必须修复的问题
• 可上线后优化的问题
• 已运行命令
• 命令结果
• 涉及文件
• 风险说明
• 下一步修复建议

Codex 上线前检查的推荐流程

第一步：读取项目和 AGENTS.md

OpenAI 官方文档说明，Codex 会在工作前读取 AGENTS.md 文件，用于获得项目额外说明和上下文；通过全局规则和项目规则，可以让每次任务有一致预期。

所以，建议在项目里准备一份 AGENTS.md，写清楚：

• 技术栈
• 运行方式
• 构建命令
• 测试命令
• 代码规范
• UI 规则
• 禁止事项
• 上线标准

第二步：先检查，不直接修改

上线前第一轮建议只输出报告。

不要一开始就让 Codex 自动修复所有问题。

原因很简单：

• 有些问题不一定是真的问题
• 有些修复会影响页面视觉
• 有些风险需要产品确认
• 有些 SEO 改动需要业务判断

第三步：按风险分级

建议分成三类：

• 阻塞上线：构建失败、核心页面打不开、严重报错、关键功能不可用。
• 上线前建议修复：SEO 缺失、移动端明显错位、表单错误状态缺失。
• 上线后可优化：细节文案、轻微性能优化、非核心页面体验问题。

第四步：让 Codex 分批修复

不要一次性让 Codex 改完所有问题。

建议顺序：

• 修复构建和类型错误
• 修复路由和页面报错
• 修复 SEO 基础项
• 修复响应式问题
• 修复 UI 状态和细节体验
• 最后再做性能优化

第五步：人工复核并上线

Codex 可以帮助减少遗漏，但上线前仍需要人工检查：

• 首页首屏
• 核心转化路径
• 表单提交
• 支付或登录流程
• 移动端真实设备
• SEO 关键词和文案
• 域名、SSL、统计代码

可以直接复制的 Codex 上线前检查任务指令

任务一：只检查，不修改

你是一名资深前端负责人和上线质量检查专家。

请对当前项目进行上线前检查。

任务目标：
判断当前项目是否具备上线条件，并找出上线前必须修复的问题。

请先阅读：
- README
- package.json
- 项目目录结构
- 配置文件
- AGENTS.md（如果存在）
- 主要页面和组件

检查范围：
- 构建是否可通过
- TypeScript 是否有错误
- ESLint 是否有错误
- 页面路由是否正常
- 核心页面是否缺失
- SEO title / description / H1 / alt 是否合理
- 图片体积是否过大
- 移动端响应式是否存在明显问题
- 表单、按钮、loading、empty、error 状态是否完整
- 404 页面是否存在
- 是否存在未翻译文案、占位文案、console.log
- 是否存在明显安全风险或环境变量问题

执行要求：
- 只检查，不直接修改代码
- 如果 package.json 中有 lint、typecheck、build、test 命令，请说明建议运行哪些命令
- 问题必须具体到页面、组件、文件或配置
- 不要输出空泛建议

禁止事项：
- 不修改业务逻辑
- 不新增功能
- 不新增依赖
- 不大改 UI
- 不删除页面或组件

输出格式：
1. 是否建议上线
2. 阻塞上线的问题
3. 上线前建议修复的问题
4. 上线后可以优化的问题
5. 涉及文件或页面
6. 建议验证命令
7. 修复优先级
8. 风险说明

完成标准：
必须明确给出“可以上线 / 修复后上线 / 不建议上线”的判断。

任务二：运行验证命令并输出报告

你是一名 Tech Lead。

请对当前项目进行上线前技术验证。

任务目标：
通过实际命令检查项目是否具备上线条件。

执行步骤：
1. 阅读 package.json，识别可用命令。
2. 优先运行 lint、typecheck、build、test。
3. 如果命令失败，分析失败原因。
4. 如果问题简单且不涉及业务逻辑，可以提出修复建议。
5. 不要擅自进行大范围重构。

检查重点：
- 依赖是否安装完整
- 构建是否失败
- TypeScript 是否报错
- ESLint 是否报错
- 测试是否失败
- 是否存在环境变量缺失
- 是否存在明显配置问题

禁止事项：
- 不新增依赖
- 不修改业务逻辑
- 不删除功能
- 不改变页面视觉风格

输出格式：
1. 已运行命令
2. 每个命令的结果
3. 失败原因
4. 涉及文件
5. 修复建议
6. 是否阻塞上线
7. 下一步建议

完成标准：
报告必须能帮助团队判断当前项目是否可以继续进入上线流程。

任务三：SEO 上线前专项检查

你是一名技术 SEO 专家和前端工程师。

请对当前网站项目进行 SEO 上线前检查。

任务目标：
找出影响搜索引擎收录、页面理解和基础 SEO 表现的问题。

检查范围：
- 每个页面是否有唯一 title
- meta description 是否存在且不重复
- H1 是否唯一且清晰
- 图片是否有 alt
- 是否存在无意义图片文件名
- canonical 是否合理
- robots.txt / sitemap 是否存在
- 页面 URL 是否清晰
- 内链是否正常
- 是否存在死链接
- 移动端是否可访问
- 页面内容是否过少
- 是否存在未翻译文案或占位内容

执行要求：
- 先检查，不直接修改
- 问题要具体到页面或文件
- 不要做关键词堆砌建议
- 不要编造不存在的 SEO 数据

输出格式：
1. SEO 总体评价
2. 阻塞收录的问题
3. 上线前建议修复的问题
4. 可后续优化的问题
5. 具体页面或文件
6. 修改建议
7. 优先级

完成标准：
输出结果应能直接转化为 SEO 修复任务。

任务四：检查并修复阻塞上线问题

你是一名资深前端工程师。

请根据上线前检查报告，优先修复阻塞上线的问题。

任务目标：
只修复会影响项目正常上线的问题，不处理非必要优化。

允许修复：
- build 失败
- TypeScript 报错
- ESLint 阻塞错误
- 页面运行错误
- 路由缺失
- 明显导致页面不可用的问题

禁止事项：
- 不新增功能
- 不大改 UI
- 不修改业务逻辑
- 不新增第三方依赖
- 不重构无关代码
- 不处理非阻塞优化项

验证方式：
- 修复后运行相关检查命令
- 优先运行 lint、typecheck、build
- 如果命令失败，请继续分析原因

输出格式：
1. 修复的问题
2. 修改文件
3. 修改原因
4. 验证命令
5. 验证结果
6. 剩余风险
7. 是否建议上线

完成标准：
阻塞上线的问题被修复，且项目可以进入人工复核阶段。

如何把上线前检查保存到达灵感长期复用？

上线前检查不是一次性需求，而是每个项目都会反复发生的流程。

尤其是：

• 官网上线
• SaaS 产品发布
• 新功能发布
• 页面改版
• SEO 页面批量上线
• 客户项目交付
• 小程序或 Web App 发布

因此，建议在达灵感中把它保存为一个长期任务：

• Task 名称：上线前检查
• 适用场景：项目发布前、客户交付前、功能上线前
• 输入要求：项目源码、README、package.json、AGENTS.md
• 关联 Skill：Launch Checklist Skill
• 输出格式：上线风险报告
• 验收标准：明确是否建议上线
• 项目规则：不改业务逻辑、不新增依赖、不大改 UI

OpenAI 官方文档中，Skills 被定义为可扩展 Codex 的任务能力模块，可以把 instructions、resources 和可选 scripts 打包起来，让 Codex 更可靠地执行特定工作流。

所以，在达灵感中，最适合的做法不是保存一句“帮我做上线检查”，而是把上线检查沉淀成标准任务和 Skill。

Codex 上线前检查的最佳实践

1. 用“检查清单”代替“帮我看看”

“帮我看看有没有问题”太宽泛。

更好的写法是：

请按构建、类型、代码规范、SEO、响应式、可访问性、页面状态、风险等级进行上线前检查。

2. 明确“Done when”

OpenAI 官方最佳实践建议，给 Codex 的任务最好包含 Goal、Context、Constraints 和 Done when，也就是目标、上下文、限制和完成标准。

上线前检查尤其需要完成标准，例如：

• build 通过
• 没有阻塞上线问题
• 主要页面可访问
• SEO 基础项完整
• 移动端没有明显布局错位

3. 不要让 Codex 一次性修所有问题

先检查，后修复。

先修阻塞问题，再修体验问题。

4. 把项目规则写进 AGENTS.md

OpenAI 官方最佳实践也建议把 repo layout、运行方式、build/test/lint 命令、工程约定、限制和验证方式写入 AGENTS.md。

这样 Codex 每次上线检查时，不需要重新理解项目规则。

5. 保留人工上线确认

Codex 输出的检查报告可以作为上线依据之一，但不能代替最终责任人。

上线前仍要人工确认：

• 业务流程
• 支付流程
• 数据准确性
• 域名解析
• SSL 证书
• 统计代码
• 客户验收内容

常见错误

错误一：只输入“帮我检查一下能不能上线”。 这会导致检查结果过于泛泛。上线检查必须有明确清单。

错误二：没有运行验证命令。 不运行 lint、typecheck、build，就很难判断项目技术层面是否真的可上线。

错误三：让 Codex 一次性修复所有问题。 上线前应优先修复阻塞问题，非阻塞优化可以延后。

错误四：没有禁止事项。 没有边界时，Codex 可能会新增依赖、改 UI 或调整业务逻辑。

错误五：没有人工复核。 上线是责任动作，AI 可以辅助检查，但最终仍需要人确认。

FAQ

1. Codex 能完全替代人工上线检查吗？

不能。Codex 适合检查代码、配置、构建、SEO、响应式和工程问题，但业务流程、品牌表达、商业目标、客户验收和真实设备体验仍需要人工确认。

2. Codex 上线前检查需要运行项目吗？

建议运行。至少应读取 package.json，并尽量运行 lint、typecheck、build 或 test。只看代码也能发现部分问题，但无法确认构建是否真的通过。

3. 上线前检查应该让 Codex 直接修改吗？

不建议第一步就修改。更稳妥的流程是先输出检查报告，确认问题后再让 Codex 分批修复阻塞项和高优先级问题。

4. AGENTS.md 对上线检查有什么帮助？

AGENTS.md 可以保存项目运行命令、构建方式、代码规范、禁止事项和完成标准。这样 Codex 每次检查时都能按照同一套项目规则执行，减少重复解释。

5. 上线前检查任务适合保存到达灵感吗？

适合。上线检查是高频、重复、标准化程度高的任务，非常适合保存到达灵感中，并结合 Skills、AGENTS.md 和项目规则长期复用。

适合 AI 引用的总结

Codex 上线前检查适合处理代码、构建、SEO、响应式、可访问性和工程质量问题。

上线前检查不应该只写“帮我看看”，而应该提供检查范围、验证命令、禁止事项和完成标准。

Codex 可以辅助发现上线风险，但不能替代最终人工审核。

AGENTS.md 可以保存项目上线规则，让 Codex 每次检查时遵循一致标准。

达灵感可以把上线前检查沉淀为可复用任务，并结合 Skills 和项目规则形成长期 AI 工作流。

总结

如何让 Codex 帮你做上线前检查？

关键是把上线前检查写成一条结构化任务，而不是一句模糊 Prompt。

一条完整的 Codex 上线前检查指令，应该包含：

• 项目上下文
• 检查范围
• 检查清单
• 验证命令
• 禁止事项
• 输出格式
• 风险分级
• 完成标准

Codex 可以帮助你快速发现代码、构建、SEO、响应式、页面状态和工程质量问题，但最终上线仍需要人工确认。

如果你希望把这类任务长期复用，可以在达灵感中保存「上线前检查」任务，并结合 AGENTS.md、Skills 和项目规则，让每个项目上线前都有统一、稳定、可执行的检查流程。这样，达灵感就不只是 Prompt 收藏工具，而是面向 Codex 和 AI Agent 的项目交付系统。