2. Linux.do
  3. 总结一下自己现在的开发模式，简称CFO架构（codex-fable-opus or cc-fable-opus）

总结一下自己现在的开发模式，简称CFO架构（codex-fable-opus or cc-fable-opus）

Imaxwel 2026-07-05 10:53 1

同一个上下文codex的gpt5.5搞一轮规划出个plan.md，临时移动到其它目录屏蔽其结果，让cc的opus 4.8再搞一轮规划出个plan.md，然后恢复gpt5.5的结果，统一让fable 5根据前二者的plan.md结果定夺，最后在codex/cc里面实施。这样似乎可以避免fable烧token太过夸张。

那我在哪儿？我就是个旁观者。。。

最新回复 (11)
  • Brisbane 07-05 11:03
    1楼

    这个过程能自动化吗？感觉手动操作还是比较复杂

  • Gilbert Young 07-05 11:08
    2楼

    codex里面的5.5现在流口水太严重了，如果web不降智，pro还是更严密一点。

    fable适合讲故事，opus 4.6适合写报告

  • Carnivore 07-05 14:23
    3楼

    你不如直接用fable写规划然后opus或者gpt执行呢

  • Jonathan Chan Geek 07-05 14:25
    4楼

    有没有一种可能fable出方案让5.5或者opus review或者执行更合适呢

  • 邱明月 07-05 14:58
    5楼

    佬可以了解一下openrouter的fusion模式；可以自己搞一个类似的；

  • Imaxwel 楼主 07-05 16:23
    6楼

    应该可以完全自动化，不过我目前不想被架空，还继续当一个审慎的旁观者做human in the loop

  • Imaxwel 楼主 07-05 16:25
    7楼

    gpt pro一个月额度有点少，平时就用在深度研究，代码上没舍得用，而且似乎还需要sub2api转，懒得折腾

  • Imaxwel 楼主 07-05 16:28
    8楼

    fable直接规划，似乎也可以，只是我担心直接写规划上下文容易扩大化，就用gpt和opus先搞这个广度的问题，最后fable在两个Plan的范围内定夺，上下文范围相对可控

  • walaqi 07-05 16:28
    9楼

    这，中间多烧的tokens，还不如让fable五直接来

  • Imaxwel 楼主 07-05 16:29
    10楼

    有可能的，我发现上下文太大，fable烧token有点架不住。所以先opus/gpt检索一轮

  • Imaxwel 楼主 07-05 16:30
    11楼

    或许吧。主要我opus和gpt分别走的订阅，只有fable走的中转，所以更care后者的token

* 帖子来源Linux.do
附近帖子
返回
飞读
随机推荐