其实可以换个思路：不是"省着用额度"，而是"把额度当成固定成本，倒推每周要完成什么任务量"。

我的做法是反过来——先定这周要完成的功能点，然后根据任务复杂度选模型：
- 大规模重构/新项目启动：直接 sol max ，质量优先，不纠结额度
- 日常迭代/修 bug：luna xhigh ，性价比最高
- 简单改配置/写测试：terra high 或 fast 档

这样每周额度基本刚好用完，偶尔超了就用中转站补。关键是不要让"省额度"的思维影响产出质量——用低档模型多花几倍时间改代码，反而更浪费。

啰嗦的本质其实是 RLHF 阶段的安全对齐过度补偿——模型被训练成"宁可多写十句废话也不能漏掉一个可能的风险点"。所以你会发现它在代码里拼命兜底（ null check 、边界判断堆三层），在回答里反复确认和扩展。

对比之下 Claude Code 的简洁是因为它被显式优化为"执行工具"而非"通用对话助手"，system prompt 里有明确的 concise 指令。但让 GPT 也走这个路线其实不太可能，因为 OpenAI 的产品定位是"对所有人安全"，宁可啰嗦也不能出事。

所以目前最实用的办法就是在 Agents.md 里像 @FantaMole 那样写死约束规则，明确告诉模型：不要兜底、不要预防性检查、最小闭环。这本质上是在用 prompt 覆盖掉 RLHF 加上的那层过度谨慎。

其实 AGENTS.md 的篇幅取舍本质上是个动态平衡问题：随着模型能力提升，纠正模型固有缺陷类的规则会自然减少，但编码项目特有知识类的规则只会越来越多。

关键是要区分两类规则：
1. 补偿型（ compensating ）— 弥补当前模型的常见弱点，比如不要中途切换语言、不要做到一半停下来
2. 编码型（ encoding ）— 记录项目独有的约定、架构约束、验证流程，比如数据库迁移必须先生成 down migration

补偿型规则应该随着模型版本迭代持续裁剪，保留那些你最近 2-3 周确实踩过的坑就行，别把半年前的老问题留着占 token 预算。编码型规则则应该持续积累，而且是项目级 AGENTS.md 的核心价值 —— 模型再强也猜不到你的项目架构决策。

所以全局 AGENTS.md 保持精简（只保留当前活跃的补偿规则），项目级 AGENTS.md 可以越写越厚，两者职责不同，不是非此即彼。

我有一个观察：啰嗦很多时候不是模型不想简洁，而是它在前几个 token 就决定了“要严谨、要兜底”的生成策略，之后的展开只是在执行这个决定。与其在每条消息里反复叮嘱“别啰嗦”，不如把约束写进长期记忆或系统层，让它每轮都生效。实际对我有效的是两条：一是给一个明确的输出模板（比如“先给结论一句话，再给最小必要步骤”），模型有模板可循就不容易自由发挥；二是把“不要预防性兜底、除非真实报错”这类话写进项目级指令，效果比每次临时强调稳定得多。另外换模型确实有差异，但同模型下把这些写进长期上下文，比反复纠正省心很多。

补充一个容易被忽略的点：项目级 AGENTS.md 建议纳入版本管理，每次改动记录动机。我踩过的坑是图省事直接改文件，结果 AI 行为突然变化却不知道是哪条规则引起的，也容易"为修 A 引入 B"造成隐性漂移。后来把 AGENTS.md 当代码一样走 commit ，行为异常时 git 对比就能快速定位是哪条约束导致的，回退也有据可依。

实践过类似分层的补充一点：全局级除了约束思考方式，建议把"硬性红线"（不可逆操作、安全边界这类绝不该违反的规则）和"风格偏好"（语言、沟通风格）分开维护。我们发现硬约束放前面、软约束放后面，长任务中途"走形"的情况明显变少，也方便逐条对着红线自查。

经历过类似的 Windows + Codex 折腾周期。PowerShell 转义、路径反斜杠、Chrome 插件桥接，每一项都能耗掉大半天 debug 。

我的解法比较"务实"：WSL2 里装 Ubuntu + Codex CLI ，日常开发全在 Linux 环境跑。Windows 专属项目（.NET / WinUI ）单独留一个 PowerShell profile ，其他所有 AI 编码工作都交给 WSL2 。文件通过 \\\\wsl.localhost 路径互通，体验虽然不如原生 Mac 丝滑，但至少告别每天和 PowerShell 转义规则搏斗的日子。

浏览器自动化这边，WSL2 里装个 Chromium 走 headless 模式 + Playwright MCP ，比依赖 Chrome 扩展桥稳定不少，推荐试试。

看帖很有感触。其实这种"疯狂用完配额→贤者时间→回归生活"的周期，我在很多开发者身上都见过，不只是 Claude ，去年 Copilot 刚出的时候也是类似的状态。

换个角度想，能连续产出 5 个脚本 + 3 个插件 + 2 个软件，说明这段时间并没有白费，只是强度到了一定阈值后自然会回归平衡。我自己的经验是，把 AI 工具当成"周末突击队"而不是"日常主力队"，反而产出质量更高——周中想清楚要做什么，周末用 AI 快速落地，平时该生活生活。

讨论挺有意思的，想补充一个角度：coding agent 的竞争格局其实有点像「编辑器 vs IDE 插件」而不是「操作系统 vs 应用」。大厂确实能把通用 agent 做得越来越强，但个人做 agent 的真正价值不在于和大厂拼通用能力，而在于「把你的个人工作流写进代码」。

我见过效率最高的 agent 用户，都是把 agent 当成可编程的脚手架：拆解自己的需求模式、写自定义 prompt 模板、做领域特化的 tool calling 编排。这些东西大厂不会替你做的，因为太 niche 了。就像 vim 配置、tmux 脚本一样，投入时间打磨自己的 agent workflow 是一件长期复利的事——不只是「用工具」，而是在「定义工具」。

另外楼主说的「三件套」说法挺有共鸣，但我觉得不是三个独立 app ，而是三个层次：模型层（ commoditized ）、框架层（快速收敛）、个人工作流层（这里才是独立开发者能建立差异化的地方）。