很多人使用Codex做工程任务时，会有一个很自然的判断：

代码已经改完了，任务应该也差不多结束了。

但真正进入Git和PR工作流以后，经常会发现：

代码改完，只完成了一半。

因为真实的软件工程链路并不是：

修改代码
↓
Done

而更接近：

修改代码
↓
Review Diff
↓
确认Branch
↓
Commit
↓
Create PR
↓
CI / Review
↓
继续修复
↓
最终Merge

Codex App现在本身就提供Git Diff、Commit、Push、创建Pull Request等Git能力；Diff面板可以直接查看Local Project或Worktree中的修改，并支持针对具体代码继续Review。Codex也可以在GitHub Pull Request基础上继续处理Review反馈。

所以真正容易出问题的不是：

Agent会不会修改代码？

而是：

修改以后，代码状态、Git状态和PR状态能不能一直保持同步。

可以把这条链抽象成：

Code State
↓
Git State
↓
PR State
↓
CI State
↓
Review State
↓
Task State

其中任何一层断掉，

都会出现一种非常常见的情况：

“代码明明改好了，但PR就是不顺。”

---

一、第一步：Code Done之前，先把Diff看明白

Codex修改完代码以后，第一反应不应该是：

直接Commit。

而应该先看：

Diff。

Codex官方最佳实践就明确建议，在任务完成以后直接使用Diff面板Review修改，重点检查Bug、Regression和风险模式。Diff面板还可以切换查看本轮修改，帮助缩小Review范围。

为什么这一层这么重要？

因为Agent完成任务时很容易同时产生两类修改：

Expected Change

以及：

Incidental Change

例如任务只是：

修复登录接口401。

但Diff里可能同时出现：

auth.ts
session.ts
README.md
package-lock.json
debug.log

其中真正需要的可能只有：

auth.ts
session.ts

其他文件可能来自：

依赖变化；

自动格式化；

临时调试；

顺手修改。

如果不先Review Diff，

后面Commit和PR会把这些变化全部带进去。

---

二、为什么Diff是Agent工程里的第一个“事实来源”？

Thread里Agent可能说：

我修改了认证逻辑并补充了测试。

但真正进入Git以后，

最可信的不是这句话。

而是：

git diff

因为：

Conversation描述的是Agent认为自己做了什么。

Diff描述的是Repository实际上发生了什么。

两者必须一致。

所以可以建立一个简单原则：

Agent Summary
↓
Diff Verification
↓
Accept Change

而不是：

Agent Summary
↓
直接Commit

这和前面我们讲过的Evidence思维完全一样：

先看实际证据，再相信“Done”。

---

三、第二步：确认Branch，不要让正确代码落在错误位置

Diff没问题以后，

下一步是：

Branch。

这一步看起来很基础，

但在Codex多Thread、Worktree、多Agent环境里反而更加重要。

例如：

main

正在由开发者自己使用。

Agent运行在：

feat/auth-fix

另一个Agent可能在：

feat/payment

Worktree能够让这些任务拥有独立的工作目录和Git状态，从而避免多个Agent直接干扰同一个Working Tree。

但Worktree解决的是：

Working State Isolation。

它不代表：

Branch一定选对了。

所以提交前至少确认：

Current Branch
Base Branch
Current Revision

尤其是长任务。

因为任务运行期间：

main

可能已经继续向前。

---

四、一个常见坑：代码正确，但Base已经变了

假设Agent从：

main@A

开始工作。

花了40分钟修改。

期间团队已经合并：

Commit B
Commit C

现在：

main@C

但Agent的Branch仍然基于：

A

这时候Agent自己的测试可能全部通过。

但真正准备PR时：

A
↓
Agent Changes

需要和：

C

重新组合。

于是可能出现：

冲突；

旧代码覆盖；

测试环境变化；

接口Contract已经改变。

所以：

Local Tests Passed

并不一定等于：

PR Ready

Branch和Base必须重新检查。

---

五、第三步：Commit不是保存动作，而是任务边界

很多人把Commit理解成：

保存一次代码。

但在Agent工作流里，Commit还有另一个很重要的价值：

Traceability。

一个好的Commit应该回答：

这一组修改到底完成了什么？

例如：

不建议：

fix

或者：

update files

更合理的是：

fix(auth): refresh session before token expiry

这样后面PR Review时，

Reviewer能够快速理解：

Goal
↓
Commit
↓
Diff

之间的对应关系。

尤其当Codex继续根据Review修改时，

如果Commit边界本身已经很乱，

后面的PR也会越来越难维护。

---

六、为什么一个PR不要顺便塞太多东西？

Agent写代码速度越来越快以后，

非常容易出现：

Task A
+
顺手重构B
+
格式调整C
+
依赖升级D

最后全部进入同一个PR。

对于Agent来说：

这些修改可能都“合理”。

但对于Reviewer来说：

真正需要解决的问题变成：

哪些变化属于原始任务？

所以PR真正需要控制的是：

Change Surface。

可以建立一个简单规则：

One Goal
↓
Focused Diff
↓
Reviewable PR

而不是：

One Agent Session
↓
One Huge PR

这两件事不是一回事。

---

七、第四步：Create PR之后，Task还远远没结束

Codex现在可以把可Review的Diff继续转成Pull Request；OpenAI对Codex的定位也一直包含“完成Pull Request、Refactor、Code Review”等端到端工程任务，而不只是生成代码。

但PR创建成功只是：

PR Open

不是：

Task Done

PR后面还会出现：

CI
Review
Requested Changes
New Commits
Rebase
Conflict

所以真正的状态应该拆开：

Code Done

PR Created

PR Verified

PR Approved

Task Done

很多Agent工作流出问题，

就是把这几个状态全部压成了一个：

Done。

---

八、第五步：CI失败以后，真正容易把PR越修越乱

这是Codex接PR工作流以后非常常见的场景。

比如：

Agent创建PR。

CI出现：

Unit Test Failed

然后让Codex继续：

修一下。

Codex修改以后：

CI第二次失败：

Type Check Failed

再修改。

第三次：

Lint Failed

如果每次Agent都扩大修改范围，

PR就会从：

Fix Bug

逐渐变成：

Fix Bug
+
Test Change
+
Type Refactor
+
Lint Cleanup
+
Unrelated Files

最终PR越来越难Review。

---

九、CI失败后正确动作不是“继续改”，而是先分类

出现CI Failure以后，

建议先判断失败属于哪一类。

第一类：Task-related Failure

例如：

你修改的接口导致测试失败。

应该：

Fix
↓
Re-run

---

第二类：Environment Failure

例如：

网络；

依赖下载；

Runner异常。

应该：

Retry / Environment Check

而不是改代码。

---

第三类：Pre-existing Failure

和当前Diff无关。

应该记录：

Existing Issue

不要为了让CI全绿，

顺手修改另一个系统。

这就是：

Failure Classification。

---

十、为什么CI失败特别容易导致Scope Drift？

因为Agent的目标经常是：

让测试通过。

如果任务定义只有：

Tests must pass

Agent很可能自然扩大范围。

例如本来：

Fix auth bug

结果发现另一个测试失败。

Agent可能认为：

那我也一起修掉。

所以更好的任务定义应该是：

Fix auth bug
↓
Run related verification
↓
Do not modify unrelated failures

这时候：

Pass Test

才不会覆盖：

Task Boundary。

---

十一、第六步：PR Review之后，任务会进入Recovery阶段

Codex现在可以在当前项目处于PR Branch并拥有GitHub访问时，继续帮助处理Pull Request反馈。官方GitHub集成也支持让Codex直接Review PR Diff，并按照Repository Guidance给出标准GitHub Code Review。

真正复杂的地方是：

Reviewer提出修改以后，

PR已经不再处于第一次创建时的状态。

可能同时发生：

Reviewer Comment
+
New Main Commit
+
Agent New Change
+
CI Result

于是任务进入：

PR Recovery。

---

十二、什么叫PR Recovery？

可以理解成：

一个已经进入协作流程的PR发生变化以后，怎样重新建立一致状态。

例如：

PR
↓
CI Failed
↓
Agent Fix
↓
Reviewer Comment
↓
Agent Fix Again
↓
Main Updated
↓
Conflict

这时候最危险的是：

Agent仍然沿用最早的Task Context。

但GitHub中的实际PR已经经历了多轮变化。

所以Recovery第一步不是：

继续改。

而是：

Fetch Current State
↓
Review Current Diff
↓
Read Latest Comments
↓
Check CI
↓
Re-plan

也就是重新建立：

Current Truth。

---

十三、PR恢复最怕“旧上下文 + 新代码”

这和前面Thread Handoff是同一个底层问题。

例如Thread里记得：

文件A已经修好

但Reviewer后来又修改了文件A。

或者Main合并了新的实现。

这时候：

Thread Memory
≠
PR Reality

如果Agent不重新获取PR状态，

就会基于旧世界继续工作。

所以进入Recovery时应该先建立：

Latest Branch
Latest Diff
Latest Review
Latest CI

再继续。

---

十四、为什么PR Badge和PR状态值得关注？

Codex App持续增强Git和PR工作流，本质上就是在把Agent任务从：

Code Generation

进一步连接到：

Engineering Lifecycle

当前Codex App的Git功能已经覆盖Diff查看、Commit、Push、PR等常见操作，而Worktree和Review功能则让不同Agent任务以及PR反馈可以继续在同一工程工作流里推进。

这意味着开发者真正应该看的不只是：

Agent现在有没有在运行？

还要看：

这个任务在Git生命周期里到底处于哪一个状态？

---

十五、可以把Codex PR状态拆成6层

我建议以后不要只使用：

Running / Done

而是拆成：

1. Implementation

代码修改中

2. Diff Review

修改已完成，等待Diff确认

3. Git Ready

Branch / Commit状态正确

4. PR Open

Pull Request已创建

5. Verification

CI / Review进行中

6. Ready to Merge

验证通过，可进入最终合并

最后：

Task Done

才真正成立。

---

十六、什么状态才叫真正Code Done？

Code Done应该至少满足：

Expected Files Changed

No Unexpected Diff

Relevant Tests Passed

但这还只代表：

Implementation完成。

还不代表：

PR已经完成。

---

十七、什么状态才叫PR Done？

PR Done至少应该包含：

Correct Branch

Focused Diff

CI Passed

Review Resolved

No Unexpected Conflict

也就是说：

Code Done
+
Collaboration Done
=
PR Done

---

十八、什么状态才叫真正Task Done？

最终还要回到最原始的：

Goal。

假设任务是：

修复用户登录401。

即使PR已经Green，

还需要确认：

原始问题是否真正解决？

如果测试只是：

Unit Test Passed

但没有验证：

真实Session Refresh场景，

任务仍然可能没有真正闭环。

所以完整结构应该是：

Code Done
↓
PR Done
↓
Goal Verified
↓
Task Done

这四个词不能混用。

---

十九、一个比较稳定的Codex PR闭环流程

以后让Codex完成真实工程任务，可以直接按照下面顺序。

第一步：Implementation

让Agent完成修改。

---

第二步：Review Diff

检查：

Files
Scope
Unexpected Changes

Codex App本身就支持通过Diff面板直接Review当前修改。

---

第三步：Git Check

确认：

Branch
Base Revision
Commit

---

第四步：Create PR

保证PR只有：

One Goal。

---

第五步：Verification

等待：

CI
Review
Security

---

第六步：Recovery

如果失败：

Fetch Current State
↓
Classify Failure
↓
Fix Only Relevant Scope
↓
Re-run Verification

最终才：

Ready to Merge

---

二十、为什么PR Recovery以后一定要重新看Diff？

这是一个非常实用的习惯。

第一次修改时，

你可能Review过：

10 Files

后来Agent根据Review继续修改。

如果直接相信：

只是修了Reviewer提到的问题。

很容易漏掉新的变化。

所以每一次Recovery以后，

应该重新查看：

Current Full Diff

而不是只看：

Agent刚才说改了什么

Codex App本身提供当前完整Diff以及Last Turn Changes两种Review视角，这正适合分别处理“总体PR状态”和“Agent刚刚新增的修改”。

---

二十一、可以建立一套最小PR Recovery Checklist

以后PR断掉以后，不要马上说：

Codex继续修。

先检查：

1. Branch

现在在哪个Branch？

2. Base

目标Branch有没有更新？

3. Diff

当前完整Diff是什么？

4. CI

真正失败的是哪一个Check？

5. Review

最新Reviewer要求是什么？

6. Scope

这次修复是否仍然属于原始Goal？

然后：

Current State
↓
Re-plan
↓
Modify
↓
Verify

---

二十二、Agent越强，PR工程反而越重要

过去人一天可能提交：

1—3个PR。

Agent并行以后：

Agent A
Agent B
Agent C
Agent D

可能同时产生大量修改。

Codex现在本身就是围绕多Agent、Worktree和可Review Diff来设计这种并行工程模式。

这时候真正的瓶颈很容易从：

Code Generation

转移到：

Diff Review
Branch Management
PR Review
CI Recovery
Merge Coordination

也就是：

Integration。

---

二十三、未来Agent工程真正稀缺的可能不是代码，而是“可合并性”

如果Agent一天生成：

100个修改。

但只有：

20个能够顺利Review、验证、Merge，

真正有效产出还是：

20。

所以Agent时代非常重要的指标可能不是：

Code Produced

而是：

Verified PRs Merged

这和前面讲过的：

Verified Outcome

完全一致。

---

二十四、可以把整个链条压缩成一句话

很多Codex失败不是：

代码没有写出来。

而是：

Code
↓
没有成功进入Repository协作流程

真正稳定的Agent工程必须把：

Generate

连接到：

Integrate

最终形成：

Implement
↓
Review Diff
↓
Branch
↓
Commit
↓
PR
↓
CI
↓
Review
↓
Recovery
↓
Merge

这才是真正的：

Engineering Loop。

---

最后

Codex代码改完以后，

最容易产生的误判就是：

Task已经完成。

但真实工程里：

Code Done
≠
PR Done

同样：

PR Done
≠
Task Done

真正完整的状态应该是：

Code Done
↓
Git Ready
↓
PR Open
↓
CI Verified
↓
Review Resolved
↓
Goal Verified
↓
Task Done

Codex现在越来越多地支持Diff Review、Git操作、Worktree、GitHub Code Review以及PR反馈处理，本质上说明Agent正在从：

代码生成工具

进一步进入：

完整软件工程生命周期。

所以开发者真正需要建立的，也不能只是：

怎么让Codex把代码写对。

还应该包括：

怎么让Agent生成的修改能够稳定进入Branch、PR、CI和Review，并在流程中断以后可靠恢复。

当这一套能力成熟以后，

Codex才能真正从：

Code Agent

走向：

Engineering Agent。

持续更新Codex、大模型开发相关技术内容。
长期使用各类代码大模型，整理了稳定的AI会员订阅渠道。