2026 年 7 月，YC CEO Garry Tan 宣称用 AI 日部署 37000 行代码，两天后就被波兰开发者公开审查拆穿：前端 6.42MB、169 次请求、生产环境带着 28 个测试文件。从翻车现场拆解 AIcoding 的质量陷阱和 Anthropic 官方推荐的多智能体模式。
2026 年 7 月 7 日，Y Combinator CEO Garry Tan 在 X 上发帖：「智能体工程绝对疯狂的一周」——他声称自己和 AI 编码代理每天在五个项目中部署 37000 行代码，连续 72 天保持发布记录。
两天后，波兰开发者 Gregorein（计算机科学硕士，13 年行业经验）打开了他的 AI 主题博客前端，用一次 Claude 会话交叉验证，然后把审查结果公开发到了 X 上。
结果是一场教科书级别的翻车。
Gregorein 的审查只覆盖浏览器可见的前端代码，不涉及后端和数据库。但光是前端已经足够触目惊心：
Gregorein 的结论很直接：「仅从 Garry 自己截图的数据来看，每次提交大致可估算为增加 2000 行、删除 450 行。」他补充，单次提交改动量如此之大时，质量会指数级下降，每一代都需要越来越多地重写才能稳定构建。
Tan 的翻车不是孤例。它暴露了当前 AI 辅助开发领域一个系统性问题：编码代理的奖励函数天然偏向产出量，而质量审查的成本仍然由人类承担。
Gregorein 在接受 Fast Company 采访时说了一句很精准的话：「现在我们正处在这样一个阶段：AI 生成代码的速度已经快到人类根本来不及审查，而像 Garry 这样的人给出的答案似乎是'那就别审查了'。这很像 Facebook 当年的'快速行动，打破常规'，而这个口号后来也被证明并不成功。」
这不是说 AI 编程工具有问题。问题出在交付流程——当代理以每次提交 ±2000 行的节奏往仓库里灌代码，而团队没有建立与之匹配的审查门禁时，质量债务会以非线性速度累积。28 个测试文件进入生产就是典型的「缺少 staging gate」症状：AI 不区分 dev 依赖和 prod 依赖，因为没有人告诉它要区分。
我们之前详细算过一笔真实账——见「AI 写代码半年，我们算了一笔真实账」。蓝曜炬辉在实际项目中观察到一个规律：单次 AI 辅助提交超过 500 行时，人工 review 的有效覆盖率会骤降——不是工程师不认真，而是认知负荷超过了人类在 5-10 分钟内能消化的上限。把提交粒度控制在 200-400 行的团队，review 发现的问题密度是 1000+ 行提交的 3 倍以上。
就在 Tan 翻车的同一天，Anthropic 的 Claude 开发者团队公开分享了他们内部高频使用的两种多智能体模式——关于这个主题，我们之前写过「Agentic Coding：当 AI 从「写代码」变成「做项目」」。这两套方案给出了「产出多且质量可控」的正确范例。
架构：Sonnet 5 作为主执行者跑循环，遇到需要高层判断的节点时，通过 tool call 调用 Fable 5 获取建议。Fable 5 每个任务大约只被调用一次，绝大多数 token 按 Sonnet 5 的低价计费。
SWE-bench Pro（482 题）实测：
| 方案 | 得分 | 成本 |
|---|---|---|
| Sonnet 5 单独 | ~75.5% | ~$0.75 |
| Sonnet 5 + Fable Advisor | ~84% | ~$1.40 |
| Fable 5 单独 | ~91.5% | ~$2.25 |
组合方案拿到 Fable 5 约 92% 的分数，只需约 63% 的价格。逻辑很朴素：把最强模型用在「纠偏定方向」上，而不是让它做所有苦力活。
架构：Fable 5 做规划，然后把任务扇出给多个 Sonnet 5 worker 并行执行。Fable 5 只负责规划阶段的高层决策，token 消耗大的实际执行全部交给 Sonnet 5。
BrowseComp 完整数据集实测：
| 方案 | 得分 | 成本 |
|---|---|---|
| 全 Sonnet 5 | 77.8% | $16.01 |
| Fable 5 编排 + Sonnet 5 workers | 86.8% | $18.53 |
| 全 Fable 5 | 90.8% | $40.56 |
编排方案拿到约 96% 的性能，只需约 46% 的价格。相比纯 Sonnet 5，准确率提升约 9 个百分点，成本仅增加约 $2.5。关于提示词层面的降本技巧，可以看「Claude Code 提示词瘦身 80% 的实战拆解」。
从 Tan 的教训和 Anthropic 的实践出发，企业引入 AI 辅助编码时需要在三个节点上做明确决策：
第一，选模型还是选流程。Tan 的问题不是模型不够强——他用的很可能是当前最顶级的模型。问题是跳过了整个质量流程。测试文件进生产、空 CSS、78 个未使用的控制器——不是 AI「写错了」，而是没人告诉它什么该进 prod、什么不该。Anthropic 的 Advisor 和 Orchestrator 本质上都在回答同一个问题：把高质量决策节点嵌入到执行流程的什么位置。
第二，提交粒度决定审查质量。Git 提交不是越「饱满」越好。当每次提交 ±2000 行时，review 在物理上变得不可能——人眼在 5-10 分钟内能有效消化的代码量有硬上限。蓝曜炬辉在多个企业项目中的经验是：AI 辅助提交控制在 200-400 行，人工 review 有效覆盖率能保持在 70% 以上；超过 1000 行，覆盖率跌到 20% 以下。
第三，AI 辅助编码本身也需要架构设计。很多人把它理解为「打开编辑器，描述需求，等代码出来」。但 Anthropic 分享的模式说明，成熟的实践需要设计：哪个模型做主执行、哪个做审核、任务怎么拆分、什么时候需要人类介入。这不是工具选择问题，是工程架构问题。更宏观的讨论见「AI 智能体正在改写软件工程——2026 年开发范式的三重转移」。
问：用 AI 写代码真的靠谱吗？
工具本身靠谱，产出质量取决于怎么用。Tan 的翻车说明：不设审查门禁、不控制提交粒度、不区分 dev 和 prod，AI 可以高效地往生产里灌垃圾。反过来，把 AI 嵌入一个有 gate 的工程流程——比如 Advisor 模式——它完全可以稳定产出高质量代码。关键变量是人设的规则，不是模型的能力。
问：Claude Code 里该选哪个模型、什么努力级别？
Anthropic 官方 2026 年 7 月的指南给了一个简单的决策框架：如果 Claude 已掌握所有相关上下文、明确尝试过但仍然出错 → 换更强模型；如果 Claude 因为跳过了文件、没运行测试、或重构中途放弃而出错 → 提高努力级别。先区分「是不懂还是没尽力」。
问：小团队能用 AI 辅助编码吗？
能，而且小团队可能是最大受益者。没有大厂的 code review 基建，但一个简单的规则——每次提交不超过 400 行、必须过人工 review——几乎零成本就能挡住 Tan 那种翻车。Anthropic 的 Advisor 模式甚至不需要自己搭多智能体架构，Claude Code 原生支持 tool call 链。
问：外包和自己做有什么区别？
自己做的优势是流程完全可控，劣势是学习曲线和试错成本。外包给已经跑通多智能体交付流程的团队，可以跳过搭建阶段的踩坑期，直接拿到可用的工程规范。核心判断标准不是「能不能写出代码」，而是「有没有一套经过验证的质量 gate 机制」。
