🛠️ 第4章 Codex 的任务地图
📄 一句话概括

四个入口不是四个产品,是同一个执行内核的四扇门。 每扇门自带一样东西:IDE 带位置,CLI 带编排,App 带任务单,Web 带沙箱。 Demo 量出来的结论有点扫兴:同一个任务,四个入口产出的补丁指纹一模一样。

📝 本章和前面几章的关系

前三章讲完三件事:它是什么、边界在哪、第一次怎么跑通。 从这一章开始铺地图——入口、档位、值守、本地云端、三个工具,一章看全。 这一节只回答一个问题:你在哪儿跟它说话,会改变什么。 结论先说:改变的是「上下文从哪个门进来」,不改变「它怎么干活」。 Demo 用同一份仓库、同一个改名任务跑了四遍,四次算出来的指纹都是 f2398cc9。 这个「一样」比任何解释都有说服力。

一、IDE 插件:贴着光标

光标在哪,上下文就在哪。你选中三行、光标停在第 12 行,它就只读那一段。 这是四扇门里定位最准的一扇。代价是视野窄:它看得见你指的那一段,看不见别处。 典型翻车:你让它「把这个函数改好」,它改好了这个函数, 但调用它的那三个地方全忘了——因为那三处不在选区里。 什么时候用它:你已经在看那段代码了,而且你确定改动只涉及这一段。这两个条件少一个,就换门。 一个容易被忽略的细节:插件到底把什么发出去了?有的只发选区,有的发整个文件, 有的连打开的其他标签页一起发。这决定了它「看得见多少」,也就决定了它会不会顺手改别处。

二、CLI:贴着终端与脚本

输入是命令行参数加当前目录,输出是标准输出加退出码。 它的强项不是「跟人对话」,是「被别的程序调用」。 一条命令能进 Makefile、进 CI、进定时任务。 这是四扇门里唯一能真正「自动化」的一扇——另外三扇都要有人在场点一下。 代价是你得自己把上下文说清楚。它没有光标,你得写「改 calc.py 里第 12 行的 add」。 写不清,它就只能猜。 什么时候用它:批量、重复、要写进流程。 一个细节很值钱:CLI 的输出是纯文本,所以它能进日志、能被 grep、能贴进工单。 排查「上次它到底干了什么」的时候,这一点比界面漂亮重要得多。

三、App 与 Web:贴着任务单

App 和 Web 把「一次交互」变成了「一张任务单」:标题、描述、验收标准、状态。 最大的区别在这里:任务单是有状态的。它可以排队、可以并行、可以隔天再看。 前三扇门都是「你现在在不在」,这两扇是「它在不在跑」。 Web 还多一层:仓库是快照,跑在隔离环境里,跑完就丢。 这是四扇门里唯一自带「禁区」的——它碰不到你本机的任何东西,也正因为如此, 它也碰不到你本机的依赖。 代价:你得先把任务写成单子。写单子比说话慢,但写出来的单子能复用、能排队、能交给别人看。

四、四者共享的是什么

入口 自带的那一样 缺什么 什么时候用
IDE 插件 光标与选区 视野、验收 改动就在眼前这一段
CLI 可编排的脚本 精确定位 批量、重复、进流程
App 任务单与排队 本机环境 跑得久、要跑好几个
Web 隔离的沙箱 本机环境 陌生仓库、不想让它碰本机

它们共享三样东西:同一份仓库、同一套执行内核(读、改、验)、同一份规则文件。 Demo 里四次指纹完全一样,就是「共享内核」的直接证据。 所以「用哪个入口」是个效率问题,不是能力问题。 真正决定结果好坏的是「你给了它什么」——目标、位置、约束、验收、禁区那五样(第 1.3 节)。 四扇门各缺一样,正好凑齐。这就是为什么成熟的用法是「换着用」,而不是「选定一个再也不换」。

五、动手 Demo:同一件事,四个入口:补丁指纹一样吗

这个 Demo 不碰任何界面,也不用 Codex。它只做一件事: 同一个任务,在四扇门里各跑一遍,看结果一不一样。 任务:把 calc.add 改名为 add_nums,两处引用一起改。 每次都开一份全新仓库、放同一份 check.py。跑完算一个指纹(两个文件内容拼起来取 MD5 前八位), 再跑一次 check.py。

for name in (u"IDE 插件", u"CLI", u"App", u"Web"):
    root = fresh()                      # 每次一份全新仓库
    put(root, u"calc.py", CALC)
    put(root, u"app.py", APP)
    put(root, u"check.py", CHECK)
    gitinit(root)
    _rename(root)                       # 同一个改名动作
    fp = _fingerprint(root)             # 两个文件拼起来算 MD5
    code, out = py(root, u"check.py")
    prints.append((name, fp, verdict))

实跑输出:

--------------------------------------------------------------------
四种入口,同一份仓库:差的是上下文怎么进来
--------------------------------------------------------------------


  ① 四种入口各自能带进来什么
  --------------------------------------------------------------------
  同一个任务:把 calc.add 改名为 add_nums,两处引用一起改。
| 入口 | 目标 | 位置 | 约束 | 验收 | 禁区 | 自带的那一样 |
|---|:---:|:---:|:---:|:---:|---|---|
| IDE 插件 | 有 | 有 | 无 | 无 | 无 | 光标与选区 |
| CLI | 有 | 无 | 有 | 无 | 无 | 可编排的脚本 |
| App | 有 | 无 | 有 | 有 | 无 | 任务单与排队 |
| Web | 有 | 无 | 有 | 有 | 有 | 隔离的沙箱 |

  四行里没有一行是全的。这不是缺陷,是分工:
  ! 光标给的是位置,命令行给的是编排,任务单给的是验收,沙箱给的是禁区。
  四者加起来才是完整的一份交代。

  ② 四个入口,跑出来的补丁是同一个吗
  --------------------------------------------------------------------
  --- a/calc.py
  +++ b/calc.py
  @@ -1,2 +1,2 @@
  -def add(a, b):
  +def add_nums(a, b):
       return a + b
| 入口 | 补丁指纹 | 同一份 check.py |
|---|---|---|
| IDE 插件 | f2398cc9 | 通过 3 / 失败 0 |
| CLI | f2398cc9 | 通过 3 / 失败 0 |
| App | f2398cc9 | 通过 3 / 失败 0 |
| Web | f2398cc9 | 通过 3 / 失败 0 |

  四个指纹一样?一样。说明入口不改变结果——改的只是上下文从哪个门进来。

  ③ 缺了验收那一项,代价是多少
  --------------------------------------------------------------------
  改之前跑 check.py -> 通过 0 / 失败 3
  改之后跑 check.py -> 通过 3 / 失败 0
  ! 改之前 0/3,改之后 3/0。这两行数字就是「验收」那一格的价值:没有它,你只有一句「改好了」。

四个指纹全是 f2398cc9。这就是「入口不改变结果」的直接证据——四扇门后面站的是同一个内核。 再看第三段:改之前 通过 0 / 失败 3,改之后 通过 3 / 失败 0。 这两个数字是「验收」那一格的价值。没有它,你手里只有一句「改好了」。 注意表里「验收」那一列只有 App 和 Web 是「有」。 IDE 和 CLI 不是不能验,是「没人替你想起来验」。这就是四扇门真正的差别: 都能改对,但只有两扇会提醒你「该验了」。 最后一句结论请记牢:入口只决定上下文怎么进来。 你把五要素给全,哪扇门都能干好;给不全,换门也白换。

30 秒实验

  1. 打开你常用的那个入口,做同一个改动,记一下你补了几句话。换另一个入口做同样的事,再记一次。 差的那几句就是那扇门缺的东西。
  2. 在你用的 IDE 插件里,故意选中三行让它改一个函数。 看它会不会顺手改调用方——这一试就知道它发出去的是选区还是整个文件。
  3. 把一条你常敲的命令写进 Makefile。能进 Makefile 的,才谈得上「进流程」。

常见误区

  1. 「四个入口功能不一样,得挑最强的那个。」 功能一样,内核一样。 差别只在上下文怎么进来——挑的应该是「哪个门离你手上的活更近」。
  2. 「IDE 插件最方便,别的不用学。」 只改局部的时候它确实最好用。 可一旦要批量、要进 CI、要隔天再看结果,它一上手就卡住。
  3. 「Web 版是阉割版。」 它少的是本机环境,多的是隔离。 到底是「缺」还是「多」,取决于任务要不要碰你本机——4.4 会把这个判据说清。
自测三问(点开对答案) 1. 四扇门里,哪一扇自带「禁区」?为什么? —— **Web。**它跑在隔离环境里,仓库是快照,**碰不到你本机的任何东西**——这就是天然的禁区。 代价是它也碰不到你本机的依赖。 2. 为什么 IDE 插件最容易「只改局部、忘了调用方」? —— **因为它的上下文就是光标与选区。** **选区之外的东西它不一定看得见**——所以改函数签名这类「牵一发动全身」的活, 别指望它自己想到调用方。 3. 同一个任务在四个入口跑出一样的补丁,说明了什么? —— **说明四扇门后面是同一个执行内核。** **入口只决定上下文从哪儿进来、结果从哪儿出去**,**不决定它怎么读、怎么改、怎么验。**

下一篇 4.2 讲五个版本:个人只需要看额度那一层,团队才需要看管理和合规那两层。

相关笔记