很多人使用Codex做工程任务时会有一个很自然的判断代码已经改完了任务应该也差不多结束了。但真正进入Git和PR工作流以后经常会发现代码改完只完成了一半。因为真实的软件工程链路并不是修改代码 ↓ Done而更接近修改代码 ↓ Review Diff ↓ 确认Branch ↓ Commit ↓ Create PR ↓ CI / Review ↓ 继续修复 ↓ 最终MergeCodex 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/paymentWorktree能够让这些任务拥有独立的工作目录和Git状态从而避免多个Agent直接干扰同一个Working Tree。但Worktree解决的是Working State Isolation。它不代表Branch一定选对了。所以提交前至少确认Current Branch Base Branch Current Revision尤其是长任务。因为任务运行期间main可能已经继续向前。四、一个常见坑代码正确但Base已经变了假设Agent从mainA开始工作。花了40分钟修改。期间团队已经合并Commit B Commit C现在mainC但Agent的Branch仍然基于A这时候Agent自己的测试可能全部通过。但真正准备PR时A ↓ Agent Changes需要和C重新组合。于是可能出现冲突旧代码覆盖测试环境变化接口Contract已经改变。所以Local Tests Passed并不一定等于PR ReadyBranch和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 RequestOpenAI对Codex的定位也一直包含“完成Pull Request、Refactor、Code Review”等端到端工程任务而不只是生成代码。但PR创建成功只是PR Open不是Task DonePR后面还会出现CI Review Requested Changes New Commits Rebase Conflict所以真正的状态应该拆开Code DonePR CreatedPR VerifiedPR ApprovedTask 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 passAgent很可能自然扩大范围。例如本来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 ReadyBranch / Commit状态正确4. PR OpenPull Request已创建5. VerificationCI / Review进行中6. Ready to Merge验证通过可进入最终合并最后Task Done才真正成立。十六、什么状态才叫真正Code DoneCode Done应该至少满足Expected Files ChangedNo Unexpected DiffRelevant Tests Passed但这还只代表Implementation完成。还不代表PR已经完成。十七、什么状态才叫PR DonePR Done至少应该包含Correct BranchFocused DiffCI PassedReview ResolvedNo 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 ChangesCodex 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现在在哪个Branch2. Base目标Branch有没有更新3. Diff当前完整Diff是什么4. CI真正失败的是哪一个Check5. 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 DoneCodex现在越来越多地支持Diff Review、Git操作、Worktree、GitHub Code Review以及PR反馈处理本质上说明Agent正在从代码生成工具进一步进入完整软件工程生命周期。所以开发者真正需要建立的也不能只是怎么让Codex把代码写对。还应该包括怎么让Agent生成的修改能够稳定进入Branch、PR、CI和Review并在流程中断以后可靠恢复。当这一套能力成熟以后Codex才能真正从Code Agent走向Engineering Agent。持续更新Codex、大模型开发相关技术内容。长期使用各类代码大模型整理了稳定的AI会员订阅渠道。