1874w's recent timeline updates 1874w's recent timeline updates |
1874wV2EX member #626951, joined on 2023-05-04 18:12:45 +08:00Today's activity rank 6814 |
1874.cool
LetTTGACO
 |
Per 1874w's settings, the topics list is only visible after you sign in |
Deals info, including closed deals, is not hidden
1874w's recent replies
12 days ago Replied to a topic by jenhe › 程序员 › 我又又又重构了我的站点 |
@lscho 信息密度太大 +1 ，现在是真看不了这种博客。我感觉我的博客（ https://blog.1874.cool/）还挺简洁的，不过博客站点更多是服务自己，记录自己的实践经验，如果持续坚持写下去，其实外观倒没那么重要。
13 days ago Replied to a topic by luojiedev › OpenAI › 用了一次 5.6 Luna，我就滚回到了 Sol |
目前 Sol 和 Terra 是 V2 的 SubAgent 协议，Luna 还是 V1 版本的，具体体现为：使用 Sol 或者 Terra 时，通过提示词是无法分配 Luna 的子 Agent 去干活的
https://github.com/openai/codex/blob/main/codex-rs/models-manager/models.json#L447
具体可以看这份文件，当 Luna 的 multi_agent_version = v2 时，就能在使用 GPT5.6 时随意指定其他 GPT5.6 模型了
https://github.com/openai/codex/blob/main/codex-rs/models-manager/models.json#L447
具体可以看这份文件，当 Luna 的 multi_agent_version = v2 时，就能在使用 GPT5.6 时随意指定其他 GPT5.6 模型了
Aug 31 Replied to a topic by BuffDog › OpenAI › plus 已经没法用了 |
@Wanex 你这话就不太对了，Fast 根据楼上哥们算下来可能有 5 倍左右的消耗，这个 Fast 即使对比到国内相同消费水平的模型，月卡订阅用户如果也能开 5 倍消耗，也用不起吧。
如果不开 Fast 吐槽下是能接受的，开 Fast 吐槽就说不过去了，我 Pro 5x 都不经常开 Fast ，没意义，又不赶时间。
我是觉得 为什么 OpenAI 不把 Plus 的 Fast 权限收回，否则这个 Plus 额度根本就用不起 Fast 。
如果不开 Fast 吐槽下是能接受的，开 Fast 吐槽就说不过去了，我 Pro 5x 都不经常开 Fast ，没意义，又不赶时间。
我是觉得 为什么 OpenAI 不把 Plus 的 Fast 权限收回，否则这个 Plus 额度根本就用不起 Fast 。
Aug 31 Replied to a topic by BuffDog › OpenAI › plus 已经没法用了 |
@Pernalin 谢谢指正，具体我没试过到底多少倍，但我很少开，只有之前明确重置前实在用不完开过。如果是这样的消耗，那 UP 这个消耗也确实正常，如果不用 Fast 可能能多 5 轮对话哈哈哈
Aug 31 Replied to a topic by BuffDog › OpenAI › plus 已经没法用了 |
@BuffDog #32 你都自己说了懒，懒值得被忽略吗？懒就是你现在问题的核心原因。
至于你说的切换上下文的消耗，直接暴露了你用 AI 还不熟练。中途切换模型最应该考虑的是「模型降智」的问题。从高切低，会导致低模型处理相同任务能力明显不如高模型。从低切高，也会存在低模型的上下文可能会误导高模型的判断。更好的做法是高模型做规划，低模型做机械执行。
至于上下文消耗，你都开 Fast 2.5 倍消耗了，还在意这点上下文消耗？你这前后还是矛盾啊
至于你说的切换上下文的消耗，直接暴露了你用 AI 还不熟练。中途切换模型最应该考虑的是「模型降智」的问题。从高切低，会导致低模型处理相同任务能力明显不如高模型。从低切高，也会存在低模型的上下文可能会误导高模型的判断。更好的做法是高模型做规划，低模型做机械执行。
至于上下文消耗，你都开 Fast 2.5 倍消耗了，还在意这点上下文消耗？你这前后还是矛盾啊
Aug 31 Replied to a topic by BuffDog › OpenAI › plus 已经没法用了 |
@BuffDog #24 我感觉这两种都能接受，就像我前面说的，VibeCoding 时代，人的代码时间是被大量解放的，我对模型的处理时间要求没那么严格，我更喜欢多线程处理独立任务，时间不作为我的考量标准。
至于 80%还是 90%，这个我无法去实际评测，只要是能满足我需求的模型就是好模型。
如果我用低模型能解决，我就认为是 100%。况且一个问题的解决如果只想一次对话就解决的话，那就是我所说的许愿式开发，我认为现阶段 AI 做不到，即使用低模型多几轮对话也能解决问题，我也会认为它是合格的，我个人的期望值没有那么高。
至于 80%还是 90%，这个我无法去实际评测，只要是能满足我需求的模型就是好模型。
如果我用低模型能解决，我就认为是 100%。况且一个问题的解决如果只想一次对话就解决的话，那就是我所说的许愿式开发，我认为现阶段 AI 做不到，即使用低模型多几轮对话也能解决问题，我也会认为它是合格的，我个人的期望值没有那么高。
Aug 31 Replied to a topic by BuffDog › OpenAI › plus 已经没法用了 |
@BuffDog #20 强推理模型是这样的，考虑的很多，边界问题处理的很多。如果是想简单处理，要么提示词要求一下，要么换低一级的模型。
Aug 31 Replied to a topic by BuffDog › OpenAI › plus 已经没法用了 |
@BuffDog #19 降智是另一个问题，尽量避免 许愿式开发 是解决降智的最佳手段，最后还是做好规划再行动。
Aug 31 Replied to a topic by BuffDog › OpenAI › plus 已经没法用了 |
@Nzelites #17 我觉得不该开 Fast 的权限，这玩意是真耗，感觉远不止 1.5 倍。
Sol 偶尔用用其实还行，但从他这个打包处理时间来看，我感觉他这个不像是正常的打包逻辑，一般意义的打包，就是运行一个打包命令等待输出了，不至于处理 17 分钟，应该有其他逻辑在里面。
我感觉这里面的罪魁祸首是 Fast 模式。
Sol 偶尔用用其实还行，但从他这个打包处理时间来看，我感觉他这个不像是正常的打包逻辑，一般意义的打包，就是运行一个打包命令等待输出了，不至于处理 17 分钟，应该有其他逻辑在里面。
我感觉这里面的罪魁祸首是 Fast 模式。
Select Language