企业官网建设流程全解析

更新时间：2026 年 7 月 10 日。本文只讨论 OpenAI Codex 与 GPT 模型在真实代码库中的调试方法。

并发 Bug 最麻烦的地方，不是代码量大，而是错误通常发生在两个请求交错执行的瞬间。单次运行可能完全正常，日志却只留下一个“重复订单”结果。

这类问题不适合让 GPT 直接猜补丁。更可靠的流程是：

现象描述 → 调用链搜索 → 时序分析 → 失败测试 → 最小修复 → 回归验证

一、先把问题写成可验证现象

不要只说“订单接口有并发问题”，而要写清楚输入、触发条件和完成标准：

现象：相同 request_id 偶发创建两条订单。

触发：两个请求几乎同时到达创建接口。

期望：同一个 request_id 最多创建一条订单，重复请求返回稳定结果。

约束：保持 API 响应结构，不修改无关模块。

这段描述会帮助 Codex 缩小搜索范围，也方便后续判断测试是否真正覆盖问题。

二、先让 Codex 读取项目规则

在仓库根目录创建 AGENTS.md，写入测试命令和审查要求：

Codex 会在开始任务前读取项目指令。订单、支付、鉴权等目录可以放更具体的 AGENTS.md，增加幂等、事务和数据隔离规则。

可以先运行只读检查：codex --ask-for-approval never “Summarize the current repository instructions.”

三、分阶段定位根因

把下面的提示发给 Codex，先禁止修改文件：

请先定位订单创建入口、request_id 查询、数据库写入和现有测试。

然后列出所有调用方，画出两个相同 request_id 并发到达时的执行时序。

判断应用层检查、事务和数据库约束分别承担什么职责。

输出根因、影响范围、最小修复计划和需要新增的回归测试。

这一步要关注 Codex 实际读取了哪些文件，而不是只看结论是否听起来合理。

四、用时序证明竞态窗口

假设当前逻辑是：先按 request_id 查询；如果已有记录就返回；否则执行插入。

两个请求可能按以下顺序执行：

1. 请求 A 查询，结果为空；
2. 请求 B 查询，结果为空；
3. 请求 A 插入成功；
4. 请求 B 插入成功。

根因是“查询”和“插入”之间存在竞态窗口。应用层判断不能单独保证幂等，通常还需要数据库唯一约束、事务和唯一键冲突处理。

高质量审查发现应包含：

[P1] 查询后插入不是原子操作

触发条件：两个请求使用相同 request_id 并发到达。

影响：可能重复创建订单，进一步造成重复扣款或库存扣减。

最小修复：唯一约束、事务内写入、冲突后的稳定响应，以及并发回归测试。

五、先写失败测试，再改生产代码

让 Codex 先完成测试：

请新增一个最小并发回归测试。

两个任务提交相同 request_id，断言最终只能存在一条订单。

测试必须在当前实现上失败或暴露重复结果；不要修改生产代码。

说明并发同步方式和断言原因。

测试不要依赖随机 sleep。可以使用屏障、事件或受控 fake store，让两个请求确定地同时通过查询阶段。

测试通过后，再让 Codex 实现修复，并要求它运行订单测试、类型检查和 lint。

六、控制修复范围

修复任务应该明确写出边界：

只修复已确认的 request_id 并发幂等问题。

不修改 API 响应结构，不处理无关格式问题，不新增不必要依赖。

最终报告修改文件、数据库约束证据、测试命令和剩余风险。

审查修复时重点检查：

• 唯一约束是否真实存在于数据库；
• 事务边界是否覆盖必要的读取和写入；
• 冲突是否转换为稳定的业务响应；
• 重试和超时是否产生新的副作用；
• 并发、重复和失败重试是否都有测试。

七、使用 Codex Review 检查最终 diff

完成修改后先执行 git status --short 和 git diff --stat，确认没有混入无关文件。

在 Codex CLI、App 或 IDE 扩展中运行 /review。Review 适用于 Git 仓库，可以选择未提交修改或相对基础分支的差异，并报告优先级明确的发现。

针对关键改动，可以追加：

只检查当前 diff 的并发、事务和数据一致性风险。

每个发现给出触发时序、影响、证据和验证命令。

无法证明的问题标记为“需验证”，不要猜测。

八、GitHub PR 中触发审查

仓库连接 Codex Cloud 后，可以在 Pull Request 评论中使用 @codex review。

如果只关注安全问题，可以写 @codex review for authorization and tenant-isolation regressions。

仓库级 AGENTS.md 中可以加入以下规则：

• 所有写操作检查幂等性；
• 新路由必须经过鉴权中间件；
• 查询必须包含 tenant_id；
• 数据库迁移必须支持滚动发布；
• 日志不得输出令牌和完整身份信息。

确认某个问题后，可以在同一 PR 中请求 @codex fix the P1 issue，但修复后仍需重新检查 diff 和 CI。

九、GPT 模型如何分工

复杂调用链、事务、安全和兼容性分析，可以使用 GPT-5.5 等强推理模型；文件归类、日志摘要和简单筛选可以使用更快的 GPT 模型。

模型选择只是资源分配策略，不能代替证据。高优先级发现必须通过失败测试、静态检查或人工代码路径确认。

十、降低误报的三个办法

1. 强制每个发现提供具体触发条件；
2. 要求先写最小失败测试；
3. 进行第二轮反证审查，寻找上游保护、前置条件和已有测试。

可以让 Codex 执行：

请重新检查上一轮发现，不要默认结论正确。只保留经得起反证的问题。

十一、轻量 Pro 使用建议

如果你每天需要审查多个仓库、运行大量长上下文任务，或者希望把本地 /review、GitHub Review 和后续修复串成连续流程，Pro 更适合这种高频 Codex 工作方式。

先把 AGENTS.md、并发测试和审查模板配置好，通常比单纯增加调用次数更重要。

总结

Codex + GPT 的并发调试应当围绕证据展开：先描述现象，再定位调用链，用时序证明竞态，用失败测试确认问题，只做最小修复，最后运行 Review 和回归测试。

模型可以扩大代码覆盖面，但最终可靠性来自测试、规则和人工审查边界。