zhuyananbusiness

我有一个观察：啰嗦很多时候不是模型不想简洁，而是它在前几个 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 ）、框架层（快速收敛）、个人工作流层（这里才是独立开发者能建立差异化的地方）。

做过产品/项目的补充个观点：开源项目加速的瓶颈从来不是写代码的速度，而是"确认"的带宽。AI 一小时能产出的代码，够 maintainer 审一周；产出越快，review 、验证、方向确认的成本就越高。所以外面看到的是"为什么不用 AI 加速"，做过的人看到的是"代码是最便宜的东西，贵的是每一步确认"。真正有效的加速，是让 AI 干确定性高的杂活（补测试、改文档、跑 CI ），把人的判断力留给需要它的地方。