氛围税
更聪明的 AI 编程代理越来越被优化为端到端接管整个软件任务，但许多开发者表示，这会带来臃肿代码、过多测试脚手架、失控的 token 成本，以及更少的控制——对那些必须审查每次变更的人来说，这是一种“氛围税”。另一些人则反驳说，只要通过谨慎提示、小范围任务，以及把模型当作传统工程流程中的初级开发者来使用，他们就能获得大型、可靠的系统和显著的生产力提升。这场讨论凸显出放手式“vibe coding”和严格管理的 AI 辅助工作流之间日益扩大的分歧，也反映出对供应商激励更偏向最大化 token 使用而非面向专家工具的担忧。
结对程序员 vs. 自主代理
- 许多人希望 AI 像一个紧密、快速的“结对程序员”，在指令下做小而精确的修改，而不是从零到一的应用构建者。
- 推荐的方法是：强模块化和 SRP、清晰的接口，并且只让代理在小而隔离的组件内工作，以限制损害。
- 逐渐出现三大阵营：从不用 AI；一次性“足够好”的生成；以及谨慎使用，让 AI 编写代码并由人类密切审查。几位评论者认为，只有第三种才是可持续的。
评论者所说的“氛围税”是什么意思
- 前沿模型越来越偏向长周期、端到端的“把整个东西都做出来”的行为。
- 这通常会导致：
- 推理和输出过长。
- 生成了用户并未要求的过多脚手架、测试和重构。
- 激进地使用子代理和工具，消耗大量 token。
- 例子包括：昂贵的 PR 审查会派生出几十个代理；复杂的 CI/测试契约导致类似活锁的循环；以及模型在简单任务上投入远超所需的精力。
- 对于必须逐行审查的用户来说，这些额外活动会被感受为在时间、注意力和金钱上的“税”。
工作流与缓解策略
- 有些人主张先规格说明的工作流：先让 AI 起草一份详细规格，人类审查后，再让一个（可能更小的）模型实现，并让另一个模型审查。
- 另一些人觉得规格驱动的工作流比直接编码更烦人。
- 几位描述了“微管理式”开发：逐步规划、小任务、持续审查，并把代理当作在传统 SDLC 中非常懂行的初级开发者。
- 也有人构建了包含多个专门子代理（规格撰写者、领域专家、工程师、QA）的 harness 来控制行为。
质量、测试与代码臃肿
- 支持者：AI 擅长一次性工具和小型应用，能写出比人类更愿意补上的边界情况处理和测试。
- 批评者：代理会过度生成平庸或脆弱的测试，以及冗长的 CI 流水线；小改动会触及许多文件；某家公司几乎全由 AI 编写的代码库被描述为混乱且难以维护，却被管理层视为值得庆祝。
- 有人担心 RLHF 和对 token 不敏感的训练环境会推动模型走向臃肿。
不同的体验与预期
- 有些人报告称，在强约束和重构纪律的帮助下，他们在大型项目上几乎毫无摩擦地取得成功，因此无法认同那些恐怖故事。
- 另一些人则一再发现自主代理无效或浪费，更偏好手动、严格控制的工作流。
- 关于到底是营销鼓励了不现实的一次性预期，还是用户没有应用批判性思维和正确流程，争论仍在继续。