上下文压缩

新用户遇到 Claude Code 在 compact 后上下文仍满、再次压缩和新开会话都继续崩溃，100k 上下文也未能撑住。

一位群友用中等推理档完成智能体代码，再由更适合实时判断的 jev 模型运行金铲铲决策，以避开大模型响应慢的问题。

针对复杂 UE5 插件连续运行数日仍无结果的问题，群友判断根因是让 AI 直接面对混淆底层代码，容易迷失在结构中。

群友反馈静态独享住宅 IP 下 Claude 与 Codex 使用稳定，并采用 Claude 负责方案与复核、Codex 负责执行的工作流。

围绕 VSCode 里的 Claude，群友讨论了多项目窗口、磁盘占用、速度、价格和使用场景分工。

Taylor 给出一条明确的成本经验：Claude Code 开 1m 上下文、一次上文输入 650k，花了 16 元算力，因此 Codex 压缩上下文时建议新开对话。

群里把 Codex 手动开启 1M 上下文的配置、成本和性能风险讲清楚了：超过 272K 会进入更贵的 Long Context，窗口继续变大也可能让效果下降。

Peter 详细说明了 Codex 的两种提示词定制入口：用 developer_instructions 追加规则，或用 model_instructions_file 替换客户端 base_instructions。

Codex 长线程协作的核心风险被定性为自动上下文压缩后，业务约束可能丢失或权重下降，而不是简单的“没上下文”。

群里把 workbuddy/codebuddy 与 Codex 放在不同场景下比较：vibe coding 仍更偏 Codex，但办公、团队协作和国内环境里，workbuddy+ima 的可用性更强。

晚间讨论从节约上下文转到如何约束 Codex 工作方式，群友的反馈是它容易陷入安全审计和无用表述，导致耗费 token 却没产出。

有群友对比扣子和 Codex：复杂严谨任务 Codex 会一路深挖，但简单文案和建站类任务可能显得过度思考。