经历过类似的 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 ）、框架层（快速收敛）、个人工作流层（这里才是独立开发者能建立差异化的地方）。