Codex真正高级用法：让它自己监督自己干活

刷到一个国外开发者分享的 Codex 使用技巧，专门用来处理难度高、目标复杂的任务。我拿几个任务试了试，最明显的感受是：以前是我一直盯着 Codex，现在可以让一个 Codex 去盯另一个 Codex。 他的做法是，遇到复杂任务时，不要直接让当前线程一个人从头干到尾，而是对它说： “请为另一个线程写一个目标，让它完成这项任务。你负责持续监督和检查，必要时给它反馈，直到它真正弄明白并通过验证。” 说白了，就是把一个线程变成执行者，另一个线程变成监督者。 刚开始我以为这只是“多开一个窗口”，实际用下来才发现，真正有用的是两个线程所处的位置不一样。 工作线程负责写代码、改文件、跑命令，很容易一头扎进实现细节里。主线程不用亲自处理每一行代码，反而能站在外面看它有没有偏离目标、漏掉需求，或者只是做出了一个“看起来能用”的版本。 我试的时候就遇到过这种情况：工作线程已经觉得任务完成了，主线程重新对照目标后，发现它只处理了正常流程，异常情况根本没有验证。它把问题重新发回去以后，工作线程才继续补测试、改逻辑。 如果只有一个线程，我大概率也会被那句“已经完成”带过去。 为什么这招比单纯说一句“请仔细检查代码”管用？ 因为同一个线程写完代码以后，再让它检查自己的代码，它通常还是会顺着刚才的思路往下走。 方案是它定的，代码是它写的，检查时自然也会沿用前面的假设。最后很容易变成自我证明：“需求已经覆盖了”“这个情况理论上不会发生”“现有测试应该足够”。 但“应该没问题”和“已经验证没问题”，完全是两回事。 换一个独立线程，相当于切断前面的思路。它不知道实现者当时为什么这么写，也没有“证明自己是对的”这层包袱，只能重新看需求、读代码、跑测试，再根据实际结果作判断。 我自己用下来，审查线程列出的问题并不一定每条都很重要。有些确实只是比较保守的提醒，甚至有点过度挑刺。但一串问题里面，经常会藏着一两条真正关键的东西：没有处理的边界条件、只存在于文档里的测试、未经验证的环境假设，或者需求里提到了但代码根本没实现的分支。 最有价值的往往不是它找出多少问题，而是它会逼着整个任务从“代码写完了”，继续走到“结果被验证了”。 #howto入门codex #prompt #ai工具 #vibecoding #编程 #程序员