制作公司如何用 Codex Desktop 审查 diff、跟进 PR 与发布验收

制作公司最容易在上线前出错的时刻，往往不是写代码时，而是客户催着发布、设计稿刚改完、PR 还有评论、staging URL 又开在另一个标签页时。即使 Codex 已经把 diff 审查了一遍，只要团队把“代码没有明显问题”误当成“现在可以正式上线”，价格、广告文案、表单去向或埋点仍可能出错。

本文把上线前工作拆成 diff 审查、PR 跟进、staging 验收和人工发布批准四段。这里的 Codex Desktop 是制作现场的便利用语，指在 ChatGPT desktop app 中使用 Codex，并按任务配合 review pane、Codex CLI 或 IDE extension；它不是把所有这些界面当成同一个正式产品名称。

本文要点

• 先写清 base branch、diff 范围、PR URL、staging URL、变更文件和回滚说明，再让 Codex 开始 review。
• Codex 负责整理差异、发现风险、拟定修复和执行验证；人负责客户承诺、价格、法律表述、发布时间与正式环境批准。
• PR 修复、staging 验收和正式发布必须分栏记录，不能用一句“review 完成”代替。
• AGENTS.md 要写可执行的检查项，例如移动端宽度、表单提交、CTA、OGP、tracking tag 和 rollback note。
• 效果应看返工次数、表单故障、发布事故和客户确认耗时，而不是 AI 改了多少行。

本文依据 OpenAI 的 ChatGPT desktop app、Code review、AGENTS.md、Subagents、Best practices 与 Agent approvals and security 文档整理。使用 Azure DevOps 的团队可继续阅读制作公司的 Azure DevOps 审批与发布流程。

现场最常见的失败场景

项目经理在聊天里只发一句“请 review 这个 PR”，Codex 看到的是代码差异，却不知道客户已经确认了哪版文案，也不知道 staging 上的表单应该发往哪个地址。随后，开发者处理了代码问题，客户负责人看到“没有 blocker”便安排上线。代码本身可能没有语法错误，但页面仍可能展示旧价格、丢失广告参数，或把咨询发送到测试邮箱。

问题不在于 review 没有价值，而在于输入范围和批准含义没有写清。/review 的输出应命名为“diff 检查结果”，不能命名为“发布批准”。同样，staging 页面能打开只说明页面可访问，并不等于客户已经接受文案，也不等于正式环境具备发布条件。

第二类失败发生在并行处理。一个 agent 修改 CTA，另一个 agent 同时调整表单组件，最后合并后的页面看似正常，但 tracking event、按钮文案和提交目标不再对应。读链接、查日志、整理评论可以并行；同一页面的最终写入、diff 复核和发布判断应回到一个主任务中完成。

Codex 与人工审批的边界

给 Codex 的输入应包含明确的 diff 范围、base branch、staging URL、PR URL、变更文件、人工检查项和 rollback note。不要授权它决定价格是否合理、法律文案是否可发布、客户是否已经验收、广告何时启动或正式环境是否上线。技术上干净的改动，仍可能在商业上不符合客户要求。

阶段	Codex 可承担	必须由人确认	应留下的证据
diff 审查	汇总变更、运行 /review、列出风险、提出小范围修复	本次修改是否符合客户委托范围	base branch、变更文件、review 结果
PR 跟进	按评论拟定修复、执行测试、整理剩余事项	是否接受设计变化、追加工时或范围变化	评论与修复对应表、测试命令、最新 diff
staging 验收	整理 Browser 或人工检查得到的页面、链接、表单与不同宽度证据	文案、价格、客户批准、广告和联系信息	staging URL、截图、表单记录、负责人
正式发布	准备 checklist、blocker 列表和回滚步骤	go/no-go、发布时间、生产权限与最终批准	批准记录、发布时间、rollback note

这个边界也应写进 AGENTS.md。规则不要停留在“注意质量”或“谨慎修改”，而要写成可验证的门槛，例如“LP 修改后检查 390px 宽度、表单成功与失败路径、主 CTA、OGP、tracking tag；未经明确指示不得改写客户已批准文案；正式发布必须由指定人员批准”。

处理客户资料时，还要限制输入内容和工具权限。PR 里如有访问令牌、个人信息、未公开报价或客户内部 URL，应先按公司的信息管理规则处理，不能因为要 review 就整段复制到不合适的上下文中。自动执行命令或访问外部服务的权限，也应按任务最小化，并保留人工批准点。

制作公司的三个实务用例

用例一：活动 LP 的 diff 审查与客户确认分离

输入 PR URL、base branch、变更文件、staging URL、修改要求和客户确认备忘。让 Codex 生成三栏表：PR 中要修的代码、staging 上要看的页面、必须等客户确认的事项。它可以检查组件变更、失效链接、响应式风险和测试遗漏，但价格、广告文案、活动日期、客户是否同意以及 production release 仍由负责人判断。

这个用例适合短交期的 campaign LP。关键不是让 Codex 一次处理所有问题，而是让每个发现都有归属。例如“移动端按钮被遮挡”进入 PR 修复栏，“新文案是否符合已签批版本”进入客户确认栏，“广告开始时间”进入正式发布 blocker。这样，开发者不会把商业决定藏在技术评论里。

用例二：逐条处理 PR 评论并控制修改范围

输入 PR comments、目标文件、涉及行、禁止修改的文件和验证命令。要求 Codex 为每条评论分别给出修复计划、实际变更文件、验证结果与尚待人工决定的事项。项目经理或技术负责人再确认客户范围、设计变化、工时影响和 launch date。

例如，客户只要求调整企业网站的导航间距，reviewer 同时指出公共按钮组件存在问题。Codex 可以说明两者的影响范围并拟定修复，但不能自行扩大委托范围。若公共组件会影响其他页面，应先停在建议与风险说明，等人决定是本次修复、另开 PR，还是列入后续维护。

用例三：用 staging URL 验收表单、CTA 与 tracking

输入 staging URL、桌面与移动端宽度、表单示例、主 CTA、tracking tag、rollback note 和 reviewer。输出应包含桌面与移动端 checklist、表单成功和失败结果、链接列表、必要截图与 production blockers。客户批准、广告时间、联系地址以及最终 go/no-go 由人确认。

只有在已配置 Browser、允许访问 staging 站点，并在表单提交等敏感操作前取得所需批准时，Codex 才能实际操作页面。没有这些条件时，它只能准备 checklist 并把浏览器证据标为缺失，由负责人完成表单与截图检查。

这适合询价页、资料下载页或招聘落地页。只看 diff 无法确认浏览器中的最终布局，也无法证明表单真的到达预期终点。反过来，只看 staging 也无法确认是否夹带了无关文件。发布表必须同时保留 PR diff、staging URL、截图、表单结果和回滚说明。

上线前的四步工作流

第一步是固定输入。负责人提供 PR URL 或本地 diff 范围、base branch、变更文件、staging URL、客户批准备忘、release checklist 和 rollback note。缺一项时，不要让“先看看”自然演变成发布决定。

第二步是让 Codex 只做证据准备。对话模式先输入 /review 再选择针对 base branch 的审查；非交互 CLI 可运行 codex review --base main。随后再把风险按严重度整理、拟定修复提示，并执行项目已有的 test、lint 或 build 命令。输出中要明确区分“已验证”“未验证”和“需要人工判断”，不能用笼统的“看起来没问题”。

第三步由获准访问 staging 的 Browser 或负责人检查真实页面。至少覆盖目标移动端宽度、桌面布局、主 CTA、表单成功与失败路径、关键链接、OGP、tracking tag 和回滚入口。截图只能证明当时的显示；表单提交结果、客户确认和发布负责人仍要单独记录。

第四步由人做 production approval。负责人核对客户批准、价格和法律表述、广告安排、正式环境配置、监控方式与 rollback note 后，明确给出 go 或 no-go。Codex 的风险列表是这一步的材料，不是批准者。

可直接使用的提示词

你正在检查一家网站制作公司在使用 Codex Desktop 前的 review 工作流。
输入：PR URL、base branch、staging URL、变更文件、客户批准备忘、release checklist 和 rollback note。

请输出：
1. Codex 可做的工作：diff 摘要、/review、风险列表、修复草案、验证命令。
2. 必须由人决定的工作：价格、广告文案、法律表述、客户确认、发布时间、production approval。
3. 一张三栏表：PR 修复、staging 检查、production blockers。
4. 适合这家制作公司的简短 AGENTS.md 规则。
5. 一个能在 30 分钟内完成的第一步。

规则：不要把 review 结果当成 production approval。没有明确的人工复核，不得改写客户已经批准的文案。

提示词中的 URL 和备忘不能只写“见聊天记录”。应给出稳定位置或明确内容，否则下一位 reviewer 无法复核。若项目没有 staging 环境，也要把这一点记为 blocker，而不是默认为本地显示正常。

可运行的发布检查代码

下面的 JavaScript 不连接 GitHub，也不调用 OpenAI API。它只检查制作公司在把任务交给 Codex 前，是否准备了最基本的 review 输入。保存为 check-release-review.mjs 后，可用 node check-release-review.mjs 执行。

const releaseReview = {
  project: "campaign-lp",
  headBranch: "feature/lp-copy",
  baseBranch: "main",
  diffScope: "feature/lp-copy vs main",
  reviewCommand: "codex review --base main",
  stagingUrl: "https://staging.example.com/campaign",
  pullRequestUrl: "https://github.com/example/site/pull/42",
  filesChanged: ["src/pages/campaign.astro", "src/components/LeadForm.tsx"],
  humanChecks: ["mobile layout", "form submit", "tracking tag", "client approval", "rollback note"],
  productionRequirements: ["client approval", "rollback note", "analytics check"],
  clientApprovalReference: "approval-example-001",
  rollbackPlan: "Redeploy the previous production commit, then rerun form and analytics checks.",
  releaseOwner: "human release owner",
  codexCanDo: ["summarize diff", "run review", "list risks", "draft fix prompts"],
  humanMustDecide: ["publish timing", "legal wording", "pricing claim", "production approval"]
};

const hasText = (value) => typeof value === "string" && value.trim().length > 0;
const hasChecklist = (value) =>
  Array.isArray(value) && value.length > 0 && value.every(hasText);
const expectedDiffScope = `${releaseReview.headBranch} vs ${releaseReview.baseBranch}`;
const expectedReviewCommand = `codex review --base ${releaseReview.baseBranch}`;

const required = [
  ["head branch", hasText(releaseReview.headBranch)],
  ["base branch", hasText(releaseReview.baseBranch)],
  ["diff scope matches branches", releaseReview.diffScope === expectedDiffScope],
  ["review command matches base branch", releaseReview.reviewCommand === expectedReviewCommand],
  ["staging URL", hasText(releaseReview.stagingUrl)],
  ["pull request URL", hasText(releaseReview.pullRequestUrl)],
  ["changed files", hasChecklist(releaseReview.filesChanged)],
  ["human checks", hasChecklist(releaseReview.humanChecks)],
  ["production requirements", hasChecklist(releaseReview.productionRequirements)],
  ["client approval reference", hasText(releaseReview.clientApprovalReference)],
  ["rollback plan", hasText(releaseReview.rollbackPlan)],
  ["release owner", hasText(releaseReview.releaseOwner)],
  ["production approval stays human", hasChecklist(releaseReview.humanMustDecide) && releaseReview.humanMustDecide.includes("production approval")]
];

const findings = required
  .filter(([, ok]) => !ok)
  .map(([item]) => ({ item, fix: "add this before using Codex for release review" }));

console.table(findings);
if (findings.length > 0) process.exitCode = 1;

示例数据完整时，findings 是空数组，进程以状态码 0 结束。把 stagingUrl 改为空字符串后，表格会列出 staging URL，进程状态码变为 1。这个脚本不能证明页面可以发布；它只阻止团队在输入资料不完整时过早开始发布 review。

Pitfall：四个常见陷阱与纠正方法

陷阱一：把 /review 当成 production approval

原因是输出里只写“通过”或“没有 blocker”，没有说明它检查的是哪段 diff。纠正方法是把结果命名为“diff findings”，同时记录 base branch、检查命令和未覆盖项目。production go/no-go 保留给指定负责人。

陷阱二：AGENTS.md 只有抽象原则

原因是“保持高质量”“谨慎修改”无法转成验收动作。纠正方法是写下制作现场的门槛：390px 移动端、表单提交、主 CTA、OGP、tracking tag、禁止擅改客户文案、rollback note 和人工批准人。每条规则都应能回答“如何证明已经检查”。

陷阱三：多个 agent 同时编辑同一个页面

原因是团队为了赶时间，把 CTA、表单和样式拆给多个 agent 并行写入。纠正方法是只并行分配读操作，例如检查链接、整理日志、汇总测试；所有写入回到一个主任务，合并后再用 review pane 检查完整 diff。不要让两个任务同时改同一个 LP。

陷阱四：跳过 staging URL，只看 PR diff

原因是代码差异容易审查，真实页面却需要浏览器、视口和表单操作。纠正方法是用一张发布表关联 PR diff、staging URL、桌面与移动端截图、表单结果、负责人和 rollback note。代码正确但显示、导线或文案错误时，仍应阻止发布。

如何判断流程是否带来收益

不要用“Codex 修改行数”当 ROI。制作公司的简单记录表可以包含：同类发布的人工复核分钟数、因范围不清产生的返工次数、staging 阶段发现的表单或链接问题、发布后事故数、等待客户确认的时间。先记录采用流程前的基准，再按相同口径比较。

成本判断可写成：节省的复核时间 × 团队小时成本 - 流程维护成本。这只是内部估算，不应混入虚构的行业平均值。若复核时间变短，但发布后故障或客户争议增加，就不能算流程改善。

FAQ

Codex Desktop 是正式产品名称吗？

OpenAI 官方文档主要使用 ChatGPT desktop app、Codex CLI、IDE extension 和 review pane 等名称。本文把“Codex Desktop”作为制作现场对这一组工作界面的便利用语，不把它表述为新的独立产品能力。

制作公司应先用 desktop app 还是 CLI？

需要浏览 diff 和 PR 状态的项目负责人，可以从 ChatGPT desktop app 的 review pane 开始。需要在本地运行 test、lint、build 或检查具体文件的实现人员，通常更适合使用 Codex CLI 或 IDE extension。选择依据是任务和权限，不是职位名称。

发布前只运行 /review 足够吗？

不够。/review 有助于检查 diff 和未提交变更，但 staging 上的最终显示、表单结果、客户批准、广告时间、价格与 production approval 仍需独立验证并由人负责。

制作公司适合使用 subagents 吗？

适合用于读操作较多的任务，例如检查链接、读取测试日志、汇总 PR comments 和整理风险。应避免多个 subagents 同时编辑同一个 LP；最终写入与完整 diff 复核交给一个主任务。

培训与咨询入口

制作公司真正需要的不是再多一个聊天窗口，而是让 PR 模板、AGENTS.md、/review、staging 验收、客户批准和 rollback note 使用同一套边界。要把现有项目整理成可重复执行的流程，可从 Claude Code 培训与导入咨询 开始。准备最近一份 PR、staging URL、当前 checklist 和一条实际返工记录，即可把讨论落到现有流程上。

实际测试结果

本文最后按可复现的范围做了检查：保留并逐一核对上述 OpenAI 官方链接；确认站内文章与咨询入口都使用 /zh/ 根路径；用 Node.js 执行 JavaScript 示例时，完整输入返回空的 findings 并以状态码 0 结束，把 stagingUrl 置空后则报告缺项并以状态码 1 结束。代码检查只能验证输入门槛，不能替代浏览器中的 staging 验收、客户确认或 production approval。

读完后可先做一个动作：打开最近一次发布记录，建立“PR 修复、staging 检查、production blockers”三栏，把每一项的人工批准人补齐。这样下一次使用 Codex 时，团队从一开始就知道什么可交给 agent，什么必须停下来等人决定。